> From: Rozental, Gennadiy [mailto:[EMAIL PROTECTED]
> > > I've got at least 400 mails (until it filled my mailbox several
> > > times) with it by now. I do not know proper solution. I still would
> > > like to provide
> > > email address for support. But 99% of traffic on that account are
> > > vi
> -Original Message-
> From: Gennaro Prota [mailto:[EMAIL PROTECTED]
>
> On Thu, 27 Mar 2003 14:01:12 -0500, [EMAIL PROTECTED] wrote:
>
> Well, if we are really going to discuss such quibbles, I would also
> change "zero" to "equiv" because that's the usual "term" used for
> strict weak o
> -Original Message-
> From: Michael Glassford [mailto:[EMAIL PROTECTED]
>
> As far as I can tell, the documented
> pool<>::get_requested_size() is not
> implemented.
You are correct. I will fix this.
-Steve
___
Unsubscribe & other ch
> -Original Message-
> From: Jan Langer [mailto:[EMAIL PROTECTED]
Just one other thing - instead of:
enum result { minus, zero, plus };
I would do:
enum result { minus = -1, zero, plus };
just for the sake of code readability and ease of understanding. It doesn't
change the logic at a
> -Original Message-
> From: David Abrahams [mailto:[EMAIL PROTECTED]
>
> [EMAIL PROTECTED] writes:
>
> > 3) I'd like to see a general solution for this problem using real
> > (late-bound) function objects as well, if you know what I mean. This
would
> > be a lot harder, though, so may
Hey Jan -
First off, let me say: excellent idea! Several times I've wanted just such
a class, and I would be happy to see this added to Boost.
I have a few suggestions/things to consider:
1) Instead of "operator bool", use the unspecified-bool-type discussed
elsewhere on this list; it's safer.
> -Original Message-
> From: Michael Glassford [mailto:[EMAIL PROTECTED]
>
> The "Future Directions" section of the Boost Pool Library documentation
says
> that "Another pool interface will be written: a base class for per-class
> pool allocation.". Has any progress been made in this area?
> -Original Message-
> From: Giovanni Bajo [mailto:[EMAIL PROTECTED]
>
> I have observed a strange behaviour with shared_ptr:
>
> struct A
> {
>shared_ptr ptr;
>
>operator bool()
>{ return ptr; }
> };
>
> A a;
> a.ptr.reset(new int);
> assert(a.ptr);
> assert(a);
>
> Now, t
> -Original Message-
> From: Eric Niebler [mailto:[EMAIL PROTECTED]
>
> > > The way call_traits is currently implemented,
> > > call_traits::value_type is an int&,
> > > not an int.
> >
> > This is the correct behavior. If you are storing an "int &" and want to
> > return it by value, you
> -Original Message-
> From: Eric Niebler [mailto:[EMAIL PROTECTED]
>
> The way call_traits is currently implemented,
call_traits::value_type
> is an int&, not an int.
This is the correct behavior. If you are storing an "int &" and want to
return it by value, you will return an "int &".
I've been looking through the Boost.Random docs, and the "val" template
parameter is inconsistently documented in random-generators.html. E.g., for
boost::random::linear_congruential, the synopsis of has
it, but the synopsis of random::linear_congruential does not.
Either this parameter should b
First, let me say that this looks like a good library. Secondly, let me say
that I have not looked at the implementation... Now, on to the comments :)
1) I'd like to see a short high-level document that compares Boost.Variant
with Boost.Any, showing the advantages and disadvantages of each. Thi
> You would have to have more than one "map_integral" with a different value
> name, where the values are dependent on one another and are part of the
> public interface. It isn't a complete solution, but it does work in most
> cases.
For future metaprogramming work (or intermediate values), it m
> -Original Message-
> From: Alberto Barbati [mailto:[EMAIL PROTECTED]]
>
> 1) purge_memory() does not reset the member next_size
Yes, this is in fact a bug, and it will be fixed.
> 2) the name release_memory() confuses me. It makes me think that all
> memory is being released, a task a
> Has anyone run into a comprehensive attack on these and similar exception
> class problems? Is there a better way than each Boost developer just
> hacking together individual exception classes? Could we do better with a
> Boost exception class or idiom?
I can only speak from my own personal e
> -Original Message-
> From: Geoff Leyland [mailto:geoff.leyland@;epfl.ch]
>
> Hi Steve,
>
> Thanks for the reply.
And sorry for the delay on this reply! :)
> On Lundi, novembre 11, 2002, at 06:00 , [EMAIL PROTECTED] wrote:
>
> > One possibility is to write an object type that sits bet
> -Original Message-
> From: Bohdan [mailto:warever@;mail.i.com.ua]
>
> <[EMAIL PROTECTED]> wrote in message
> news:22602E7E3B92D411969B0090273CC28B1D235F@;cecexchange.cec.je
> rviswebb.com...
> > As John pointed out, you're not going to see much benefit (if any) when
the
> > standard libr
> I'm using boost::pool for (evidently) allocating memory for a whole
> bunch of objects (thanks Stephen Cleary for pool). Most of the time the
> objects are entirely independent, however, from time to time, I'd like
> to iterate through all the allocated objects (in this case to generate
> so
> Can anybody shed light on why fast_pool_allocator benefit ratio is so
different
> for different compilers ?
It's because the malloc() and new speeds differ by compiler. If you're
really interested, there's an outdated article in WDJ April '97 that
compares malloc() and new speeds of several com
> A grep for BOOST_IS_ENUM doesn't turn up any hits other than the faulty
> Borland specific line in is_enum.hpp. Anyone know what's wrong here?
Hmmm... I don't have access to the current CVS right now, but looking at an
old copy of the sources:
BOOST_IS_ENUM (as well as BOOST_IS_CLASS, etc) are
20 matches
Mail list logo
