Re: Several useful utility classes uploaded

From: brianjparker_at_[hidden]
Date: 2001-11-03 17:46:42

--- In boost_at_y..., Douglas Gregor <gregod_at_c...> wrote:
> On Saturday 03 November 2001 03:27, you wrote:
> > Actually, I think that there is a third option which would be the
> > best long term solution.
> > The fundamental problem is that the standard disallows non-PODs in
> > unions, hence the need for creating a POD with the same alignment 
via
> > alignment_traits. The language definition could, though, be easily
> > extended to allow class types directly in union definitions 
(perhaps
> > requiring a POD as the first (initialised) member). This would 
remove
> > the need for std::aligment_traits<>::align_t.
> 
> Unfortunately, then unions need destructors. Those destructors have 
to call 
> the destructor of the currently valid member. To know which member 
is valid, 
> the size of a union has to be increased to hold a tag. We have now 
allocated 
> the storage required for a discriminated union, but we don't yet 
have the 
> syntax for checking which member is valid; so we end up extending 
the 
> language further to include that syntax. Now unions in C++ differ 
in 
> size/layout from unions in C, and we have a whole host of new C 
compatibility 
> problems cropping up.
> 
> I'm not convinced it's an easy extension.

Hmmm, good point. I actually envisaged a very minor change to the 
standard whereby class types would be allowed in union definitions to 
get the correct alignment, but the semantics of unions would be 
otherwise unchanged. 

I hadn't actually thought through the destructor issue, but words 
could be added to the standard that class type members must be 
explicitly constructed and destructed by the user and the behaviour 
is undefined otherwise (i.e. unions don't get a compiler-generated 
destructor); though maybe that would be too subtle and a source of 
bugs.

> > (In fact, I vaguely remember reading somewhere on the web that an
> > even more extensive upgrade of unions to allow class types was 
being
> > considered for the next language standard anyway. Does anyone have
> > any details on that?)
> >
> > Failing that however, I agree that a standard
> > alignment_traits<>::align_t and ::value is the best library 
solution.
> 
> I take the opposite view on this. We have unions already, and I 
think we're 
> stuck with the current semantics for the foreseeable future. 
They're not 
> typesafe and they can't deal with all C++ types, so they don't fit 
well at 
> all into a high level programming language. It seems that the 
logical step is 
> toward a higher-level construct, such as a descriminated union that 
would 
> naturally be able to handle any type and would be type safe. Should 
it be 
> implemented as a language feature or as a library component?
> 
> As a language feature, it'll most likely have a clean syntax and 
well-defined 
> semantics. A new keyword will likely be introduced for the 
construct, which 
> will break compatibility with C++98. Adoption will probably again 
be slow - 
> we can't even rely on relatively simple features being implemented 
corrected 
> (partial specialization)  3 years after we had a standard, so how 
long would 
> it be until this discriminated union construct becomes mainstream? 
When would 
> it be used, e.g., in a Boost library without workarounds? Languages 
move 
> slowly, and each feature impacts the entire language in ways that 
won't be 
> known for a long time.
> 
> As a library feature, we might have to sacrifice some syntax. 
Instead of:
> 
> variant Expression {
>   AddExpression add;
>   MulExpression mul;
>   Variable var;
> };
> 
> we might have:
> 
> typedef std::variant< tagged<Add, AddExpression>,
>                              tagged<Mul, MulExpression>,
>                              tagged<Var, Variable> > Expression;
> 
> However, we gain in many other areas. Semantics are still well-
defined, 
> adoption can be very fast (most likely, just replace "namespace 
boost" with 
> "namespace std"), and there is no impact on the language. 

Certainly, a full discriminated union class should be a library 
class. 

In fact, the valunion class I submitted in bjp_utilities28102001.zip 
is such a class and was one of the original motivations for my 
wanting to add alignment_traits<>::align_t to boost.

(BTW, The syntax for valunion is-

boost::valunion<AddExpression, MulExpression, Variable> vu;

vu = AddExpression();
assert(vu.type == 1);
AddExpression a = static_cast<AddExpression>(vu);
(or AddExpression a = vu.get<1>(); // in latest version only)

I called it valunion in analogy with valarray- I originally created 
it to give Matlab-like cell array functionality to such an array 
class.
)

> So back to alignof/alignment_traits/etc. The path of minimal impact 
would be 
> to provide alignment_traits with some language support to get 
the "value" and 
> "align_t" fields. This can't be done complete in a library, but by 
placing it 
> in the context of a library we get language support without new 
syntax or any 
> language interactions. 

Yes, so we should make this concrete and create a patch for the  
boost type traits library and email it to the type traits library 
maintainer (I believe this is John Maddock ). I will upload a first 
pass today under the name "alignment_traits_ext.zip". If you could 
look at it sometime (no hurry), and perhaps add your preferred 
align_t computation method in a conditionally compiled block, then we 
can compare the possibilities and create a final submission.

Cheers,
Brian Parker