"Jonathan David Turkanis" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> > You have read/write member functions of your source/sink/filter
concepts
> > virtual. If one went for efficiency she would stay away from virtual
> > functions. With such a design you leave a user no choic
"Aleksey Gurtovoy" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> IMO we should just stop using 'void_' for internal purposes and give it
> up to users :).
I think it would be also very nice to 'give up' the mpl::aux::type_wrapper
class. It's quite a useful class and I wonder why i
"Jonathan D. Turkanis" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I have posted a new version of my library, which has been rewritten to
> incorporate filtering as a basic construct.
> (http://groups.yahoo.com/group/boost/files/streambuf_lib.zip)
>
> In addition to allowing the
"Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Maxim Egorushkin wrote:
> [...]
> > Seems like the issue is undefined behaviour when casting away volatile.
> > Do I get it right?
>
> Yes, UB is the issue ("one of
"Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> http://google.com/groups?selm=3f01e07b%40usenet01.boi.hp.com
> (Subject: Re: Does anyone think 'volatile' is a platform-independent
> way to make variable access thread safe?)
>
> Check out this entire thread. Fol
"Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Maxim Egorushkin wrote:
> >
> > "Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> > >
> >
"Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Maxim Egorushkin wrote:
>
> [... "ala Alexandrescu" volatiles ...]
>
> http://groups.google.com/groups?threadm=3EE84807.DD00F4D0%40web.de
> http://groups.googl
"William E. Kempf" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Now, what you're describing sounds more like this:
>
> class timer
> {
> public:
>timer(boost::function on_event, int ms, bool repeat=false);
> };
>
> Which do you really want?
Yes, this is what I needed.
>
>
"William E. Kempf" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> > Speaking about the timer I ment something like that:
> >
> > typedef int milliseconds;
> >
> > class stopwatch
> > {
> > public:
> > stopwatch()
> > : started_(::GetTickCount())
> > {}
> >
> > m
"William E. Kempf" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Priorities are implemented, but still undergoing design changes, in the
> thread_dev branch. The timer, if I understand what you want, is trivial
> to implement portably with the current Boost.Threads interfaces, bu
Hello,
I've been missing a feature in the thread library: managing a thread
priority. And, BTW, the class encapsulating stopwatch functionality with a
millisecond precision would be very useful. It would help writing more
portable programs (as boost::thread is portable).
I'm aware of the fact
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> In this version of MPL, vector only supports push_front/pop_front, so
> that it's possible to write algorithms which work on both lists and
> vectors. The next version will fix that by providing list (O(1) front
> oper
Hi,
I have some difficulty with mpl::push_back<>. It's the reason for compile
time errors on Intel C++ 7 and MS VC 7.1. I had to switch to using
mpl::insert<> instead.
The error on MS VC 7.1 is:
mpl_sort.cpp(60) : error C2039: 'type' : is not a member of
'boost::mpl::push_back'
Please see the a
"Larry Evans" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I'll soon upload a commented an simplified version of marg_ostreambuf
> and maybe a templatized version to parameterize the addedState. I may
> rename it too to decorated_ostreambuf or something similar.
I think there is
"Larry Evans" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I had a brief look and it looks promising. However, I'm wondering
> if some of the complexity can be avoided. I had a hard time figuring
> out just how to get marg_ostreambuf in files/col_io/col_io.zip to work
> with bu
"Jonathan D. Turkanis" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Yes, this is very elegant. No codecvt's in sight -- just pure adaptors.
Also
> nice treatment of optional template parameters. It puts my design (and
> certain my implementation) to shame. I should have thought mo
"Jonathan D. Turkanis" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Thanks for your interest. I have posted the library at
> http://groups.yahoo.com/group/boost/files/streambuf_lib/.
>
> The implementation needs to be streamlined, but it works, and the main
ideas
> are clear enough
Doesn't Microsoft VC++ compilers starting from version 7 support member
template friends?
#if _MSC_VER <= 1310
# define BOOST_NO_MEMBER_TEMPLATE_FRIENDS
#endif
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-Original Message-
From: Vladimir Prus [mailto:[EMAIL PROTECTED]
Sent: Monday, March 24, 2003 10:25 AM
To: Boost mailing list
Subject: Re: [boost] boost::any feature request
[]
P.S. And, BTW, it would be great to see the complete code that you
propose (or
a diff to CVS HEAD).
Here are
Title: Сообщение
I think it would be great to make boost::any's
memory allocation strategy for value holder customizable. It would allow to use
not only global new operator, but any other special fast allocators like, for
example, Loki::SmallObject.
The changes are minor and would not break
20 matches
Mail list logo
