Re: Passing address of stack memory to placement new operator
Alf P. Steinbach wrote:
* mlimber:
In either case, we're using placement new and allocation is done
outside the new operator itself.
[snip]
(If the custom placement new does
something different, it has changed the semantics of that operator
No (it's a circular argument: assuming that 'new' invokes some standard
semantics for the allocation function, then arguing that if it doesn't
the semantics have been changed, but the only standard semantics is for
'::new').
I don't follow you here. Please clarify.
Leaving it unqualified seems fine to me.
If you want to leave the choice of allocation scheme to class Fred, yes,
but given that you've declared a buffer to put the object in, how likely
is that?
By the same logic I think we could justly say that if we've overridden
the placement new operator for this class,
No.
No what? I hadn't even finished my thought yet! :-P
how likely is it that we want to use the global one?
Very. E.g., consider implementing something like a std::vector. Should
a std::vector<Fred> use Fred's placement allocation function if one is
defined? With MSVC 7.1 it does. With g++ 3.4.4 it doesn't. When that
function is inaccessible the code doesn't compile with MSVC 7.1, and I
don't see accessibility of that function as a requirement for standard
container elements (so I think that compiler is wrong). With g++ 3.4.4
the code compiles (which I think is correct, and anyway, it is IMO how a
properly designed & implemented class should work, no surprises).
Sutter and Alexandrescu do note in the same item cited previously that
"you should always avoid hiding in-place new because STL containers use
it extensively." However, it seems to me that this is more of a
quality-of-implementation issue (since having the STL use in-place new
is not required by the standard, right?) or a defect in the standard
(the STL containers should have that requirement).
Cheers! --M