Passing address of stack memory to placement new operator

[mangesh]

This code is from c++ faq in section 11 :

void someCode()
{
char memory[sizeof(Fred)];
void* p = memory;
Fred* f = new(p) Fred();
f->~Fred(); // Explicitly call the destructor for the placed
object
}

Here we r passing address of stack memory to new .
New is used to allocate memory on heap . Then how can we pass address
of
stack memory to new operator . It is confusing .

Regards ,
Mangesh .

[mlimber]

Alf P. Steinbach wrote:

* Frederick Gotham:

Alf P. Steinbach posted:

Fred* f = new(p) Fred();
Should be

Fred* f = ::new(p) Fred();

Could you please explain that?

Unqualified placement new might invoke a custom Fred allocation function
instead of the basic placement new.

But if there is a custom placement new operator defined for Fred,
presumably it is meant to be used. Leaving it unqualified seems fine to
me.

Cheers! --M

[Alf P. Steinbach]

* Frederick Gotham:

Alf P. Steinbach posted:

* Frederick Gotham:

Alf P. Steinbach posted:
> Fred* f = new(p) Fred();
Should be

Fred* f = ::new(p) Fred();
Could you please explain that?

Unqualified placement new might invoke a custom Fred allocation

function

instead of the basic placement new.

When you want to use "placement new", would it be wise to always use:

::new(p) Type();

(I realise it won't make a difference with intrinsic types, but it's
consistent nonetheless for dealing with class types).

Yes, that's good advice when you want the in-place construction
behavior, not a custom allocator: let's update FAQ item [11.10]... ;-)

CC: Marshall Cline

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Alf P. Steinbach]

* mlimber:

Alf P. Steinbach wrote:

* Frederick Gotham:

Alf P. Steinbach posted:
> Fred* f = new(p) Fred();
Should be

Fred* f = ::new(p) Fred();
Could you please explain that? Unqualified placement new might invoke a custom Fred allocation function
instead of the basic placement new.

But if there is a custom placement new operator defined for Fred,
presumably it is meant to be used.

Depends what you want. If you want to leave the decision of how to
allocate the memory to class Fred, use 'new'. If you want to take
charge, saying Here Should Be Placement Construction, use '::new'.

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?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[mlimber]

Alf P. Steinbach wrote:

* mlimber:

Alf P. Steinbach wrote:

* Frederick Gotham:
Alf P. Steinbach posted:
>> Fred* f = new(p) Fred();
> Should be
>
> Fred* f = ::new(p) Fred();
Could you please explain that?
Unqualified placement new might invoke a custom Fred allocation function
instead of the basic placement new.

But if there is a custom placement new operator defined for Fred,
presumably it is meant to be used.

Depends what you want. If you want to leave the decision of how to
allocate the memory to class Fred, use 'new'. If you want to take
charge, saying Here Should Be Placement Construction, use '::new'.

In either case, we're using placement new and allocation is done
outside the new operator itself. (If the custom placement new does
something different, it has changed the semantics of that operator and
is no different than changing the semantics of other overloaded
operators, which is generally considered evil as in FAQ 13.9.)

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, how likely is it that we
want to use the global one? Also, Sutter and Alexandrescu note, "If a
class defines any overload of operator new, it should provide overloads
of all three of plain, in-place, and non-throwing operator new. If you
don't, they'll be hidden and unavailable to users of your class." (_C++
Coding Standards_, Item 46).

Cheers! --M

[Alf P. Steinbach]

* mlimber:

Alf P. Steinbach wrote:

* mlimber:

Alf P. Steinbach wrote:
* Frederick Gotham:
> Alf P. Steinbach posted:
>>> Fred* f = new(p) Fred();
>> Should be
>>
>> Fred* f = ::new(p) Fred();
> Could you please explain that?
Unqualified placement new might invoke a custom Fred allocation function
instead of the basic placement new.
But if there is a custom placement new operator defined for Fred,
presumably it is meant to be used. Depends what you want. If you want to leave the decision of how to
allocate the memory to class Fred, use 'new'. If you want to take
charge, saying Here Should Be Placement Construction, use '::new'.

In either case, we're using placement new and allocation is done
outside the new operator itself.

Yes.

(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').

and
is no different than changing the semantics of other overloaded
operators, which is generally considered evil as in FAQ 13.9.)
Yes.

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.

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<Fre d> 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).

Also, Sutter and Alexandrescu note, "If a
class defines any overload of operator new, it should provide overloads
of all three of plain, in-place, and non-throwing operator new. If you
don't, they'll be hidden and unavailable to users of your class." (_C++
Coding Standards_, Item 46).

Yes.

However, blaming the designer of class Fred is just that, assigning
blame: instead one should IMO make sure that there is no blame to
assign, by the simple expedient of using code that does what one wants
regardless of the class in question.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[mlimber]

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<Fre d> 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