Portability is not a huge issue for these builds actually as the plan is to
distribute binaries for the time being, with open source modules, or module
plugins rather, as the system itself is a suite of modules. Also only
operating system with nestable and mutually dependent shared library support
can be accommodated. 

I've actually never seen "placement new" before I think. Its a useful way to
"reconstruct" heaped memory, but not useful in anyway in the situation I
described (which is really broader than any single fix)

PS: I did receive another response by mail, but I'm not seeing it in the
thread. Perhaps it was a private response only somehow. In any case it
suggested that nonstandard extensions to GCC cut against its philosophy. I
do believe GCC supports the standard "for loop scope" extension (which seems
so practical, that many compilers default to it) ...likewise, permitting
ctored structs in a union seems equally, if not more so practical, and the
omission just as absurd. It would seem like a natural nonstandard inclusion,
at least until the c++ specs are amended to include it. 

In the meantime I'm perfectly prepared to hack away at GCC. If anyone has
suggestions, I would appreciate it. GCC should strive to support extensions
within reasonable limits such as this. Not doing so makes porting code more
difficult, if not impossible, and that is just bad for the community at
large. This seems like a simple enough artifact to remedy, at least to
sufficient extent in some fashion. I'm just hoping someone with GCC dev
experience would weigh in on the matter.
-- 
View this message in context: 
http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11150629
Sent from the gcc - Dev mailing list archive at Nabble.com.

Reply via email to