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.
