Re: Most needed/desired features in C++

From: brianjparker (brianjparker_at_[hidden])
Date: 2002-02-19 09:51:07

--- In boost_at_y..., "Herb Sutter" <hsutter_at_a...> wrote:
> Hi folks,
> 
> Pardon if this has already been discussed on the list, but I'd like 
your
> feedback on this question: "What are the most needed or desired 
features in
> C++ for modern library writing in general and Boost in particular?"
> 
> Two usual suspects:
>  - typedef templates
>  - typeof (with gcc semantics?)
> 
> What else should be on the list? For example, is there language 
support that
> would assist type traits?

One little pure extension that I have found the need for several 
times is to allow non-POD types to be members of *anonymous* unions 
(possibly with the restriction that the first member is a POD). The 
semantics would otherwise be unchanged, and in particular it would be 
up to the containing class to construct and destroy non-pod members 
appropriately.

The reason this extension is needed is to portably align memory for 
both POD and non-POD types using the usual C idiom of a union of the 
set of types to align, e.g.-

template<class A, class B, class C>
class my_union {

  //... constructors, assignment etc do placement construction and 
destruction into buffer

  union {
   char buffer[MAX_SIZE_OF_A_B_C];  // aligned memory
   A a;
   B b;
   C c;
 };
};

Note that there is no completely portable way to achieve the same 
effect in the current language definition. (One can however devise a 
non-portable kludge solution that returns a POD type with the same 
alignment as a class (see alignment_of in "bjp_utilities*.zip" in the 
files section)).

Note that this proposal is restricted to anonymous unions as they 
must be members of a class which can then maintain a discriminant 
field to ensure correct, safe access to the data e.g. see valunion in 
the files section. This proposal would be dangerous if extended to 
named unions as these can be used independently of a containing class 
and so the correct construction and destruction of non-POD members 
could not be guaranteed.

(see valunion and the allocators in the files section 
in "bjp_utilities*.zip for examples where this would be useful).

,Brian Parker