Re: New version of valunion and stack_allocator uploaded

From: crimsono (gregod_at_[hidden])
Date: 2002-02-28 16:38:49

--- 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?

  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.

  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        
}

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

        Doug [web interface]