I'm sorry, but this is unacceptable (union members and ctors)

["michael.a" <wild dot eyed dot boy dot from dot freecloud at gmail dot com>]

Salutations everyone,

I'm afraid I have a fairly major project which requires a Linux port. The
problem is, development has been put off for a while because GCC lacks any
means or work around which permits nesting ctors inside a union. 

The effort is mature enough that it needs a public release, but it can't be
released without a Linux distribution... because it doesn't need to look
like a total Microsoft tool. Linux has always been the ideal platform, but
the nature of the project is rather untailored for Linux development. 

Bottom line is, Windows(msvc) has a work around which alleviates this issue,
though I'm not entirely impressed with it. Linux(gcc) however does not. 

If it isn't clear from the subject, the issue is the C++ specs, specifically
where it says union members can't have ctors. Windows lets you wrap a ctored
member inside an anonymous struct, without a ctor (though the ctor still
appears to be called -- apparently Windows allows this as a sort of half ass
concession... precisely because this spec is sooo regressive) 

It makes no sense to arbitrarily exclude structs with ctors from unions. And
it makes perfect sense in a million powerful ways to permit them. The reason
ctors are not possible in the specs is a pure technicality... because it
would sort of gum up other specs around construction. 

Still one can see from a simple example the power of such a feature...

For instance, say you need to impliment a GUI, so you have yourself a
rectangle struct which consists of four floating point values (the origin
and difference between the opposite corner) ...Now you want those four
values, but you also have a 2D vector struct. So it seems obvious to union
the scalars over the two vectors. Why? Because it makes the code much more
intelligible then it would be to always access the corners from the vectors
(which would be the only alternative outside of sacrificing the
functionality of the vector class) 

Same can be said for embedding 4D vectors in a 4x4 matrix, form a transform
matrix / orthogonal axes coordinate system and translation vector. Of course
the benefits transcend graphics, but that is the simplest example, and the
intensive reuse of graphics primitives and the hairy code they tend to
generate, only further serves to drive the point home.

I use graphics primitives throughout all of my code, even when completely
unrelated to graphics. And I've found myself in a position where I refuse to
sacrifice my handy dandy vector libraries. I can't modify them to suit GCC,
and I can't remove their constructors for obvious reasons (automatic
instantiation, conversion operators, etc)

So I find myself here... I pretty much have to make a case, and beg for a
GCC workaround of some type. GCC doesn't have to conform to for loop scope
spec, so I see no reason why a similar compiler option can't be permitted to
get at this issue. Windows permits it, and it is not an uncommon dilemma.

There is no error code, but the basic errors look like this:

...struct>::xyÃ?T with constructor not allowed in union
...struct>::xyÃ?T with copy assignment operator not allowed in union

I'm prepared to try to hack GCC myself if I must. I have to wonder what
would happen if the error was simply ignored. My intuition tells me there
would likely be no technical ramifications. A more thorough solution would
of course be preferred. I won't dull out possible scenarios, but it should
appear obvious, that it seems especially cruel, to arbitrarily deny structs
with ctors inclusion in unions.

So in closing, I'm interested in any ideas / advice, but compromising the
existing codebase is completely out of the question. You have my
appreciation in advance naturally...

sincerely,

michael





-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11149318
Sent from the gcc - Dev mailing list archive at Nabble.com.