michael.a: > A proper C++ style fix would require the introduction of new syntax rather > than tagging unions or such. The dominant ctors would have to be specified, > or unions themselves could simply be allowed ctors that override the member > ctors. Call them constructor overloads or something, no new syntax or > revolutionary semantics, just a quick and easy fix.
If all you need is one memeber that has constructors / destructors, and all other members are PODs that provide an alternate view of the contents, then I think that would make a logical extension of the transparent union extension. A transparent union as passed to functions in the same manner as its first member. You could define that a tranparent union is allowed to have as its first member a class with constructors and/or destructors, and that these constructors / destructors are then the constructors / destructors of the union. Caveat: If the union is larger or more alingned than its first member, the argument passing semantics don't make sense. This is documented in extend.texi: Second, the argument is passed to the function using the calling conventions of the first member of the transparent union, not the calling conventions of the union itself. All members of the union must have the same machine representation; this is necessary for this argument passing to work properly. There is also a syntax example for __attribute__ ((__transparent_union__)) in extend.texi. Inside the compiler, you can check if union is a transparent union using the TYPE_TRANSPARENT_UNION macro. Joe Buck: > I wouldn't object if someone implemented a clean extension. The problem > with extensions, though, is documenting how all the corner cases work, > and making sure that they all get tested. This is somewhat easier when > you're cloning someone else's extension, because the other implementation > can be used for comparison. To avoid having too many corner cases, you can keep the defined functionality small and well delineated, declare anything beyond this scope as invoking undefined behaviour (simplest for implementation - just make sure you don't ICE) or as a constraint violation (i.e. you should make sure that the compiler produces an error - the benefit is that it prevents people from accidentially starting to use accidential functionality that is not covered by the documented extension). michael.a: > Sometimes extensions just have to be quick and dirty. Microsoft is a major > influence. The facilities should be there to match MS whenever within > reason... as well as should be ever present warnings not to abuse such > facilities. If you make a quick and dirty hack, you have so be prepared for it not to be maintainable for any length of time. michael.a: > I went to compile a "tainted" build last night, but I ran into a build error > apparently related only to subversion checkouts, which might also be > particular to the target debian distribution / hardware support for some > esoteric reason according to what can be gleamed from google. So I went to > just download the release sources, but all of the mirrors were down for some > reason. > > The error is related to a bison/flex build event, which for some reason > can't be completed by autotools or something... I figure it easier to just > go with the release sources as suggested (the relevant .c files are > pregenerated in the release trees) Try contrib/gcc_update --touch after the checkout.
