This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: I'm sorry, but this is unacceptable (union members and ctors)
Joe Buck wrote:
>
> On Fri, Jun 15, 2007 at 08:00:24PM -0700, michael.a wrote:
>> 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)
>
> I disagree; placement new is much more flexible than that, and can be used
> to construct an object inside a static, automatic, or global object. It
> can be used to implement generalized unions, or as a way to control
> placement of memory-mapped objects. Furthermore, you've almost certainly
> used it without knowing it, since the STL uses it a lot. But if you
> really
> want your existing code to work, you'd need to extend the compiler. If
> your code is modular, and doesn't expose all over the place the particular
> use of unions you described, it wouldn't be hard to switch to a
> placement-new implementation. Otherwise it could be a hopeless task.
>
>
No, the infringing code is left out of the modular interfaces, but necessary
for everything to work. If any portability issues were in the interfaces,
they can be removed harmlessly.
As for "placement new", from what I can find, it is unsafe to use with any
memory that isn't part of the heap. I believe I've seen it before, in
documentation pertaining to overloading the "new" operator. But if I'd
realized it can be used to reinitialize heap objects, I would've seen the
utility of it immediately. Incidentally, I don't believe it is useful (or at
least required) for much else. I can definitely use it in my custom heap
code, whereas before special initialization functions were required to be
defined.
As for the discussion of unions, placement new is way too much overhead. I'm
mostly interested in automatic objects, like vectors for math routines etc.
I could hack it maybe I think, with a placement new style factory in place
of ctors, but it would make inline optimizations virtually impossible and
the only way I could do it would be with a round robin style heap array
which you would always risk overwriting should the demand for autos exceed
the buffer capacity.
>
> I wouldn't object if someone implemented a clean extension. The problem
> with extensions, though, is documenting how all the corner cases work,
> and making sure that they all get tested. This is somewhat easier when
> you're cloning someone else's extension, because the other implementation
> can be used for comparison.
>
>
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.
--
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11157188
Sent from the gcc - Dev mailing list archive at Nabble.com.