Re: New version of valunion and stack_allocator uploaded

From: brianjparker (brianjparker_at_[hidden])
Date: 2002-03-04 02:57:10

--- In boost_at_y..., "crimsono" <gregod_at_c...> wrote:
> --- In boost_at_y..., "brianjparker" <brianjparker_at_h...> wrote:
> > I have uploaded the latest version of my utility classes and 
> > functions in the files section in
> > "bjp_utilities21022002.zip"
> > 
> > There are changes to the interface of valunion and 
stack_allocator 
> > and documentation improvements.
> > 
> > Cheers,
> > Brian Parker
> 
> I've finally gotten the chance to look at some of this.
> 
> First of all, I think we should add your alignment_of extension
> immediately, because it will be extremely useful in the future. My
> only complaint with the implementation is that the use of partial
> specialization makes the code unusable on several compilers. In this
> case, the partial specialization is easy to work around. 
> 
> I'm interested in valunion, but (as always) there are some nitpicks:
>   1) Again, partial specialization will break lots of compilers. 
It's
> not a requirement to be portable to broken compilers, but in this 
case
> I think it would be easy to support these broken compilers. Perhaps
> the partial specializations for < 10 arguments could just be ifdef'd
> out for broken compilers, and the primary template made to deal with
> any number of arguments?

Yes, I will add that to the implementation.

>   2) Assignment to a valunion is not at all exception safe, and it
> probably should be. I don't believe it is possible to achieve the
> strong exception guarantee, but we can give the basic guarantee and
> perhaps say that if assignment to a valunion throws, the valunion 
will
> have the 'nil' value.

Good point- I could just wrap the assignments in a try block and set 
the type to nil if an exception is thrown, as you suggest. I will add 
that too.

>   3) I don't see the reason for for_each_valunion. 
> for_each(first, last, boost::bind<void>(visit_valunion_t(), _1, f));
> 
>      where 
> 
> struct visit_valunion_t {
>   typedef void result_type;
> 
>   // operator() is just the set of visit_valunion overloads        
> }

Yes, that should work. for_each_valunion() might still be a useful, 
simpler synonym for the above construct though.

>   4) Please remind me again why valunion_cast<T>(valunion) returns 
the
> result by-value and not a reference to it.

Hmmm... I think I just made the valunion_cast analogous to 
static_cast, so if you wanted a reference you would explicitly use A& 
a = valunion_cast<A&>(u) as per static_cast.

But given that a reference can always be returned then I suppose that 
it would make sense to just always return a reference, as you 
suggest; I will change the syntax to this.

> 
> 	Doug [web interface]

Thanks for your comments,
I will upload a changed version in the near future.
Brian Parker