Re: [boost] Re: Compiler status for GCC 3.3

On Friday, July 04, 2003 12:38 AM [GMT+1=CET], David Abrahams <[EMAIL PROTECTED]> wrote: >> On the other hand if your native compiler is GCC and your system was >> not configured with that setting, then you may get into trouble -- >> since you'll be mixing translation units with different ABIs. >

[boost] Filtered stream-buffer, part 3

For the past few weeks, some posters were talking about streambufs that can decorate another stream buffer. I wrote up a third version at . The differences from the previous version is that is actually implements filtering for the ma

Re: [boost] New Iterator Adapters - filter_iterator

Thomas Witt <[EMAIL PROTECTED]> writes: > Dave, > > On Thursday 03 July 2003 09:32, David Abrahams wrote: >> Thomas Witt <[EMAIL PROTECTED]> writes: >> > I've checked in a fix for this. Static asserts make the instantiation of >> > iterator_adaptors members fail depending on the iterator category.

[boost] Re: New Iterator Adapters - filter_iterator

Thomas Witt <[EMAIL PROTECTED]> writes: > John, > > John R. Bandela wrote: >> Should filter_iterator use iterator_facade as its base instead of >> iterator_adapter? It seems the iterator_adapter is incorrectly implementing >> advance. > > I wouldn't say that it is incorrectly implementing advance.

[boost] Re: Compiler status for GCC 3.3

Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > | I'm not sure about this. Paul C. Leopardi and Guillaume Melquiond already > | reported the issue, Paul also analyzed it here > | http://groups.yahoo.com/group/ublas-dev/message/676 > | > | In essence: setting -fabi-version=0 should solve the proble

[boost] Re: New Iterator Adapters - filter_iterator

"David Abrahams" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >> I was under the impression that Dave is gonna move it to >> the main >> trunk real soon, so keeping it on your local disk for a >> few more >> days might be the easiest solution. Dave? > > I'm on vacation until the 6th

[boost] Re: why is config not part of the public boost interface ?

Ulrich Eckhardt <[EMAIL PROTECTED]> writes: > Hi! > > I'm talking about http://boost.org/libs/config/config.htm. In > http://boost.org/libs/libraries.htm#workarounds it says 'not intended for > library users'. Why not ? I just don't think we want to be bothered to field support requests on the

[boost] Re: Review request: enable_if

Markus Werle <[EMAIL PROTECTED]> writes: >> Dear Boosters, >> >> The enable_if library defines the enable_if and disable_if templates, >> which are tools for controlling which function templates are included >> in the overload resolution set based on the properties of the argument >> types. >> >

Re: [boost] New Iterator Adapters - filter_iterator

Dave, On Thursday 03 July 2003 09:32, David Abrahams wrote: > Thomas Witt <[EMAIL PROTECTED]> writes: > > I've checked in a fix for this. Static asserts make the instantiation of > > iterator_adaptors members fail depending on the iterator category. You > > may want to try it, though I don't have

Re: [boost] New Iterator Adapters - filter_iterator

Thomas Witt <[EMAIL PROTECTED]> writes: > John, > > On Wednesday 02 July 2003 02:34, John R. Bandela wrote: >> I was playing with the new iterator adapters in the sandbox. As I was >> looking at filter_iterator, I found that it allows user code to increment >> it like a random access iterator. Her

[boost] Re: Boost::thread feature request: thread priority

"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

Re: [boost] why no strict ownership smart pointer in boost

On Thursday, July 3, 2003, at 11:05 AM, Schoenborn, Oliver wrote: I could sure use some feedback about how the technique stands to generic algorithms. I'm not sure how this will work with your library, but the below example is meant to illustrate the kind of accidental ownership transfer I am

Re: [boost] why is config not part of the public boost interface ?

At 08:07 AM 7/3/2003, Ulrich Eckhardt wrote: >Hi! > >I'm talking about http://boost.org/libs/config/config.htm. In >http://boost.org/libs/libraries.htm#workarounds it says 'not intended for >library users'. Why not ? The Boost config system primarily addresses issues that are affecting Boost co

RE: [boost] why no strict ownership smart pointer in boost

> Are you transferring ownership (moving) with copy syntax > within the containers in order to satisfy the container's copyable > requirement? No, transient shared ownership. > If so, is there not a danger that ownership will get > accidently transferred out of the container, especially if t

[boost] Re: Review request: enable_if

In our last exciting episode Markus Werle wrote: > With enable_if this can be reduced to say it once and for all times: > Users just have to specialize a traits class > template struct DaixtroseTraits > { > enum { use_default_ops = false }; > }; > and I change my operators to > template en

[boost] [thread] bugfix + possible deadlock

Boost 1.30, Windows. libs/thread/src/once.cpp, function call_once(), CreateMutex() should be replaced with CreateMutexA() in one place. Looking into the code, I have question: if the 'called once' function throws, it leaves (under Win32) opened mutex and this can deadlock the app (if there are m

[boost] why is config not part of the public boost interface ?

Hi! I'm talking about http://boost.org/libs/config/config.htm. In http://boost.org/libs/libraries.htm#workarounds it says 'not intended for library users'. Why not ? I just stumbled across this some time ago and was very surprised because I use exactly that in quite some code that doesn't oth

[boost] Re: Review request: enable_if

Jaakko Jarvi wrote: > Dear Boosters, > > The enable_if library defines the enable_if and disable_if templates, > which are tools for controlling which function templates are included > in the overload resolution set based on the properties of the argument > types. > > The following example demon

Re: [boost] Re: Interest in multiindex_set? (again)

Arkadiy Vertleyb ha escrito: [...] > > The reason we are interested in the multiindex_set is that we want to > provide a more efficient implementation for our table, that is currently > implemented with std::vector, although Ed Brey already suggested an > alternative with std::set(that we need