Hello Stefan Heinzmann,

Stefan Heinzmann schrieb:

> unions in current C++ are rather limited creatures, which others have=20
> noted before (see for example Alexandrescu's work on discriminated=20
> unions). Is there any movement towards extending the standard towards=20
> more capable unions?
>
> I would be interested in particular in unions that can hold real=20
> objects. That of course would mean to destruct the "current" member in=20
> place, and constructing another in the same memory when the "current"=20
> type gets changed. It would be particularly cute if this destruction=20
> and construction were partial if the old and the new "current" type=20
> shared common base classes. I can see interesting applications for=20
> this in hierarchical state machines, for example.
>
> This would support the notion of "in-place object mutation". A way of=20
> initiating such a mutation would be needed (another kind of cast, maybe=
).
>
> Or is there a reasonable way how this can be implemented with the=20
> current language?=20

You might consider boost::variant=20
(http://www.boost.org/doc/html/variant.html), which has been invented for
the described use case.

Greetings from Bremen,

Daniel Kr=FCgler


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 04/29/2005 01:28 AM, Daniel Kr=FCgler (ne Spangenberg) wrote:
[snip]
>=20
> You might consider boost::variant=20
> (http://www.boost.org/doc/html/variant.html), which has been invented f=
or
> the described use case.

But also realize it is not be "fully" portable, unless it has solved
the alignment problems cited by Herb Sutter here:

http://www.informit.com/articles/article.asp?p=3D360435&seqNum=3D3&rl=3D1

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Daniel Kr=FCgler (ne Spangenberg) wrote:
> Stefan Heinzmann schrieb:
>> It would be particularly cute if this destruction=20
>> and construction were partial if the old and the new "current" type=20
>> shared common base classes. I can see interesting applications for=20
>> this in hierarchical state machines, for example.

> You might consider boost::variant=20
> (http://www.boost.org/doc/html/variant.html), which has been invented f=
or
> the described use case.

While this does indeed implement discriminated unions, I am not aware of=20
any way to implement my desired behaviour with it (see text snippet=20
above). Its efficiency also appears to be less than optimal to me.

But maybe my desired semantics (aka type mutation with partial=20
destruction/construction) would be a bad idea in your opinion?

Cheers
Stefan

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hello Stefan Heinzmann,

Stefan Heinzmann schrieb:

> Daniel Kr=FCgler (ne Spangenberg) wrote:
>
>> Stefan Heinzmann schrieb:
>>
>>> It would be particularly cute if this destruction and construction=20
>>> were partial if the old and the new "current" type shared common=20
>>> base classes. I can see interesting applications for this in=20
>>> hierarchical state machines, for example.
>>
>
>> You might consider boost::variant=20
>> (http://www.boost.org/doc/html/variant.html), which has been invented=20
>> for
>> the described use case.
>
>
> While this does indeed implement discriminated unions, I am not aware=20
> of any way to implement my desired behaviour with it (see text snippet=20
> above). Its efficiency also appears to be less than optimal to me.
>
> But maybe my desired semantics (aka type mutation with partial=20
> destruction/construction) would be a bad idea in your opinion?=20

I apologize for my late respone. Which text snippet do you mean? Or do=20
you mean your question concerning the partial destruction/construction?

I don't think, that your idea is basically bad, but the devil might be=20
in the details (I don't know whether this is an internationally
understandable proverb, but at least you will understand me ;-)). The=20
reason is that your approach contradicts the usual order of=20
construction/destruction
"events". E.g. construction:

Call virtual base class c'tors, Call base class c'tors from root(s)=20
(left to right) to most derived.

Now applying your proposal to that scheme in a naive way we see obvious=20
deviations in this order which might led to unexpected results
especially in classes with virtual functions.

Concerning the point of performance: AKAIK there ist still development=20
on this utility class and this statement might be already invalid.

Greetings from Bremen,

Daniel

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]