[boost] bugs in boost progress_timer?
hi boosters: I just found that boost::progress_timer behaviors different from win32 to posix. This is because the clock function's return is not same on these two platformes. Do you all think this is a bug, or a intented featuer? man 3 clock DESCRIPTION The clock() function determines the amount of processor time used since ~~ the invocation of the calling process, measured in CLOCKS_PER_SECs of a second. MSDN April 2003 Calculates the wall-clock time used by the calling process. ~~~ clock_t clock( void ); -- <[EMAIL PROTECTED]> ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0: lexical_cast.hpp broken under Mac OS X/gcc3.2.2
>From: "Beman Dawes" <[EMAIL PROTECTED]> > At 07:40 PM 3/12/2003, Ralf W. Grosse-Kunstleve wrote: > > >The recent patch to lexical_cast.hpp causes problems under Mac OS X/gcc > >3.2.2. > >The error message appears at the top of: > > > >http://cci.lbl.gov/boost/results/1047512220/dailylog_coral_test > > > >.../boost/boost/lexical_cast.hpp:92: `wstring' > > undeclared in namespace `std' > > > >This worked before: > > > >http://cci.lbl.gov/boost/results/1047490620/dailylog_coral_test > > > >(There are some other unrelated problems on this platform.) > > The same code also caused problems for Win32 GCC, Intel, and VC++ 6.0. > I'veadded a quick fix for lexical_cast.hpp line 92, which cleared a lot of > the > problems, but not all of them. > > See > http://boost.sourceforge.net/regression-logs/cs-win32-RC_1_30_0-diff.html > AFAIK, all the new fails are because of lexical_cast.hpp use. A word on the lexical_cast_test.cpp: everything will be ok if you commented all tests about std::wstring and wchar_t with #ifndef BOOST_NO_STD_WSTRING #endif This new version of lexical_cast seems OK to me, it compiles with both gcc 3.2.2(winxp, mingw 2) and vc 7.1(final beta). ;-) > I've already privately emailed Kevlin and Terje, but given time zone > differences they may not see the messages right away. > > This sort of last minute snafu reinforces Ralf's earlier message; it > really > isn't good software development practice to sit on changes for months, and > then try to get them working after a branch for release. -- <[EMAIL PROTECTED]> ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost::lambda::call_xxx, right or wrong?
I use the header file instead of
by mistake. Thanks for your help.
On Mon, 9 Dec 2002 13:16:38 -0500 (EST)
Jaakko Jarvi <[EMAIL PROTECTED]> wrote:
> The algorithm.hpp header is badly broken in 1.29 (wrong file
> in the wrong place at the wrong time). This is fixed in the cvs main
> trunk.
>
> The following program compiles and runs fine (with gcc3.2).
>
> Cheers, Jaakko
>
>
> // --
> #include
> #include
> #include
>
> #include
> #include
>
> using namespace boost::lambda;
>
> int main() {
>
> std::vector b1;
> b1.push_back(1); b1.push_back(2);
>
> std::vector b2;
> b2.push_back(3); b2.push_back(4); b2.push_back(5);
>
> std::vector > a;
> a.push_back(b1);
> a.push_back(b2);
>
> int sum = 0;
> std::for_each(a.begin(), a.end(),
> bind(ll::for_each(),
> bind(call_begin(), _1), bind(call_end(), _1),
> protect(sum += _1)));
>
> std::cout << "sum = " << sum << "\n";
> }
> // --
>
>
>
>
> On Tue, 10 Dec 2002, Robin.Hu wrote:
>
> > Hi Boosters:
> >
> >In the document of boost::lambda (ar01s05.html#sect:nested_stl_algorithms),
> > it says:
> > -->cited begin<---
> >Some aid for common special cases can be provided though. The BLL defines two
> >helper function object classes, call_begin and call_end, which wrap a
> >call to the begin and, respectively, end functions of a container,
> >and return the const_iterator type of the container. With these
> >helper templates, the above code becomes:
> >
> >std::for_each(a.begin(), a.end(),
> > bind(ll::for_each(),
> > bind(call_begin(), _1), bind(call_end(), _1),
> > protect(sum += _1)));
> > --->cited end<-
> >
> >But I failed to compile this example with gcc 3.2 and vc 2003 beta.
> > I think the problem is, both struct call_begin and struct call_end dont
> > provide a result_type.
> >
> > [lambda/algorithm.hpp]
> > --->cited begin<---
> > #define CALL_MEMBER(X) \
> > struct call_##X { \
> > template \
> > struct sig { \
> > typedef typename boost::remove_const< \
> > typename boost::tuples::element<1, Args>::type \
> > >::type::const_iterator type; \
> > }; \
> >\
> > template\
> > typename T::const_iterator \
> > operator()(const T& t) const \
> > {\
> > return t.X(); \
> > }\
> > };
> > --->cited end<-
> >
> > Is there anything I missed? And is there a possibel way to make these
> > call_xxx run?
> >
> >
>
> --
> --
> -- Jaakko Järvi email: [EMAIL PROTECTED]
> -- Post Doctoral Fellow phone: +1 (812) 855-3608
> -- Pervasive Technology Labs fax: +1 (812) 855-4829
> -- Indiana University, Bloomington
>
>
> ___
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
--
<[EMAIL PROTECTED]>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Boost::lambda::call_xxx, right or wrong?
Hi Boosters:
In the document of boost::lambda (ar01s05.html#sect:nested_stl_algorithms),
it says:
-->cited begin<---
Some aid for common special cases can be provided though. The BLL defines two
helper function object classes, call_begin and call_end, which wrap a
call to the begin and, respectively, end functions of a container,
and return the const_iterator type of the container. With these
helper templates, the above code becomes:
std::for_each(a.begin(), a.end(),
bind(ll::for_each(),
bind(call_begin(), _1), bind(call_end(), _1),
protect(sum += _1)));
--->cited end<-
But I failed to compile this example with gcc 3.2 and vc 2003 beta.
I think the problem is, both struct call_begin and struct call_end dont
provide a result_type.
[lambda/algorithm.hpp]
--->cited begin<---
#define CALL_MEMBER(X) \
struct call_##X { \
template \
struct sig { \
typedef typename boost::remove_const< \
typename boost::tuples::element<1, Args>::type \
>::type::const_iterator type; \
}; \
\
template\
typename T::const_iterator \
operator()(const T& t) const \
{\
return t.X(); \
}\
};
--->cited end<-
Is there anything I missed? And is there a possibel way to make these
call_xxx run?
--
<[EMAIL PROTECTED]>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] About the next version of boost::thread.
Hi, I want to know if these features will be added to the next version of boost::thread, or not. Process shared mutex and condition var. Thread cancellation. Thanks -- <[EMAIL PROTECTED]> ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost release compressed by bzip2
Bzip2 is widely spreaded with GNU software. It is available to all *nix platforms those are available to me, include linux, *bsd, solaris, etc... IMHO, using tar.bz2 instead of tar.gz is a good idea. On Sun, 01 Dec 2002 19:35:35 -0500 Beman Dawes <[EMAIL PROTECTED]> wrote: > At 03:05 PM 11/29/2002, Pavel Vozenilek wrote: > > >Bandwith and time of those with dialup can be saved by compressing Boost > >release by BZIP2 compressor (http://sources.redhat.com/bzip2/). > > > >For example boost_1_29_0.tar.gz has size 5 272 kB, tared and compressed > by > >bzip2 size is 4 282 kB (down to 81%). > > > >Boost size will grow (Spirit lib has over 600kB) and bzip2 can reduce the > > >growth a bit. Bzip2 is available on many platforms, free to use, stable > and > >quite used. > > The .tar.gz format was chosen because a number of users of UNIX-like > systems said that was their preference. > > While there are obvious benefits to switching to a format which yields a > file so much smaller, I'd like to hear from other UNIX/etc users that this > is an acceptable format for them. > > Regardless, thanks for bringing it up. I've been wondering if bzip2 was > becoming a commonplace format. > > --Beman > > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- <[EMAIL PROTECTED]> ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Socket Multiplexing
On Wed, 27 Nov 2002 21:40:14 +0100 "Johan Nilsson" <[EMAIL PROTECTED]> wrote: > > >"Darryl Green" <[EMAIL PROTECTED]> skrev i meddelandet > >[EMAIL PROTECTED]">news:[EMAIL PROTECTED] > ... > > [snip] > > > Note man says "regular files" - there are lots of interesting special > files that don't always > > report ready - I/O devices, pipes etc. Also, I think it would be a bad > idea to assume > > that select is the be all and end all of how the socket/file/whatever > ready to handler > > dispatching can be implemented. It ought to be possible to replace a > select based > > dispatcher with one based on async I/O or some other exotic scheme. > > Just adding some comments here. > > Being able to queue _true_ async read/writes on multiple devices (socket, > files, serial devices, pipes, ...), and then wait for any of them to > complete has been absolutely essential to me - much, much more than > non-blocking (which I personally don't like at all), and also more than > multiplexing (select). That's probably why I'm not doing linux programming > if I can avoid it (no flames please). I started out to implement > cross-platform async I/O for NT/linux/VMS, and got a bit on the way before > having to drop the multiplatform support (at least currently) due to > resource limitations (time, mostly). Anyway, one can always fake async i/o > on linux using i/o multiplexing. I also made some attempts on using libaio, > but it didn't seem very mature at the time - maybe one will have to wait for > kernel aio support. Under VMS as well as under NT, the i/o subsystems are > designed as asynchronous, so there are less work there (even though VMS I/O > is not as 'polymorhic' as NT's). > > Regards // Johan The biggest problem is portablity, but it worth a try. ;-) > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- <[EMAIL PROTECTED]> ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
