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.