Joe Buck wrote:
>
> On Sat, Jun 16, 2007 at 12:08:40PM -0700, michael.a wrote:
>> As for "placement new", from what I can find, it is unsafe to use with
>> any
>> memory that isn't part of the heap.
>
> You do have to concern yourself with alignment. But often an allocator
> that hands out memory that is filled in by placement new doesn't use the
> heap at all. Using a union for the storage that's filled by the placement
> new call is one way to assure correct alignment.
>
>> As for the discussion of unions, placement new is way too much overhead.
>
> Placement new has *no* overhead, it pretty much invokes the constructor
> directly, and if the constructor is inline, there isn't even a function
> call. I'm sorry that you are not open to learning about it, and that you
> seem to believe many things about it that are not true. It does require
> you to worry about lower-level details, like assuring correct alignment.
>
>> 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.
>
> Not if you want the gcc developers to accept it. Accepting the extension
> is a commitment to maintain it pretty much indefinitely. Also, if the gcc
> extension doesn't do everything the Microsoft extension does, your code
> might not work even if it compiles: it might leak memory or crash if
> the constructor/destructor behavior differs.
>
> But I'm puzzled that you'd rather try to hack the compiler than
> investigate a way to make your program portable C++. Or do you think you
> can talk others into hacking the compiler for you? I doubt that it will
> work.
>
I've thought about every conceivable way of a more portable solution
obviously. I will do whatever is required to get my code to compile for the
time being. If I am able to inspire someone who is qualified to draw out and
implement some proper extension specs, then all the merrier (and the world
would be a better place)
I wouldn't expect such an extension to necessarily be fully compatible
across compilers, but simple preprocessor management should suffice to make
up the differences. The rest would be up to programmers, which should be
aware of the any cons the extension would have to offer.
You are of course free to demonstrate how placement new could circumnavigate
the need of unions. The most obvious solution to such a problem is to simply
make all of the union members accessible by simple functional access. That
is like rect.origin().x, rather than rect.origin.x for example. Of course
this means going through the entire code base and changing every such
instance of origin, and call me nitpicky but its not as clear and is
generally uglier with the parentheses.
I can think of ways to use placement new which would be about as convenient
as not in lexical terms, but it would still require minor altercations
throughout the codebase at this point.
--
View this message in context:
http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11159694
Sent from the gcc - Dev mailing list archive at Nabble.com.
