Boost logo

Boost :

From: felipe (pbr_at_[hidden])
Date: 2005-08-10 03:14:22

hello and good day to all,

Well, I posted earlier about this, but yes, if you are going make a decent
"any" with stack-allocation, you should let the maximum buffer size be
variable. I didn't go into details about alignment or exceptions because
I think it's pretty much old news. (In his article "Discriminated
Unions", Andrei Alexandrescu considers all of this, however I don't
totally agree with his implementation--too hairy for the 9-to-5
programmer.) My own recommendation is that both alignment and buffer size
be adjustable. By default they should have sensible values. For example,
8 for both gives decent results on a lot of platforms, although you could
do better with the help of sizeof and alignment_of. Besides simplifying
the class definition, letting the programmer tweak alignment can be useful
for types that can benefit from extra alignment. An example might be a
character array--it only "needs" byte alignment, but maybe all of the
string operations are tweaked for 32-bit alignment.

Somebody made a rather interesting question, whether an object having size
less than void * might need alignment greater than void *. Well, about
the only maxim the C/C++ standards give is that alignment is platform
dependent. In practice, I've never seen such a strange case. I think
that sizeof(X) <= sizeof(Y) is a pretty good indicator that alignment(X)
<= alignment(Y). (But remember, "minimum-acceptable" alignment is not the
same as "optimum" alignment--my pentium lets me store and fetch a double
at 0xDEADBEEF, but these operations aren't cheap!)

Also, be careful with alignment_of: I remember it giving me some strange
values on some illegal but idiomatic structures (e.g. zero-length
arrays). If it gives you zero, put 8 or something you think is sensible.

hope this helps

On Tue, 09 Aug 2005 18:07:06 +0200, <boost-request_at_[hidden]> wrote:

> Date: Tue, 09 Aug 2005 10:17:48 -0400
> From: christopher diggins <cdiggins_at_[hidden]>
> Subject: Re: [boost] Improved boost::any
> To: boost_at_[hidden]
> Message-ID: <026101c59ced$1ee4a3d0$2b792518_at_heronnest>
> Content-Type: text/plain; format=flowed; charset=iso-8859-1;
> reply-type=original
> ----- Original Message -----
> From: "Vladimir Prus" <ghost_at_[hidden]>
>> If the trick is to use "void*" pointer to data for storing data when
>> it's
>> small, then:
>> - it's interesting to see performance comparison for any<string>, or
>> any<some_other_large_class>
> Another part of the optimization, is to avoid reallocating when
> reassigning
> any a different value with the same type.
> On a related note: several people have suggested that a buffer should be
> used with an arbitrary size set at compile time, which would help
> significantly for container types.
>> - can't this be just patch to boost::any, as opposed to completely
>> different
>> class?
> What does submitting a patch entail? Is that the way to go if the
> implementation is completely different?
> - Chriostopher Diggins

Using Opera's revolutionary e-mail client:

Boost list run by bdawes at, gregod at, cpdaniel at, john at