Placement new return value

1 view
Skip to first unread message

James Hopkin

unread,
Nov 9, 2004, 4:20:15 PM11/9/04
to
Dear all

Given any type T and a pointer, p, to suitably aligned memory, if I do

#include <new>
new (p) T;

is

static_cast<T*>(p)

subsequently guaranteed to be a valid pointer to the newed object? I
believe it is, but I'm not sure where to look in the standard for
confirmation.


Thanks in advance

James

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Alberto Barbati

unread,
Nov 10, 2004, 11:26:18 AM11/10/04
to
James Hopkin wrote:
> Dear all
>
> Given any type T and a pointer, p, to suitably aligned memory, if I do
>
> #include <new>
> new (p) T;
>
> is
>
> static_cast<T*>(p)
>
> subsequently guaranteed to be a valid pointer to the newed object? I
> believe it is, but I'm not sure where to look in the standard for
> confirmation.

To be precise, it's static_cast<T*>(static_cast<void*>(p)) that is
guaranteed to be a valid pointer. The cast to void* is required in case
p is a pointer to a type multiply or virtually derived from T.

The guarantee comes from §4.10/2 and the fact that that placement form
of operator new returns its argument (§18.4.1.3/2).

Alberto

Victor Bazarov

unread,
Nov 10, 2004, 11:26:44 AM11/10/04
to
James Hopkin wrote:
> Given any type T and a pointer, p, to suitably aligned memory, if I do
>
> #include <new>
> new (p) T;
>
> is
>
> static_cast<T*>(p)
>
> subsequently guaranteed to be a valid pointer to the newed object? I
> believe it is, but I'm not sure where to look in the standard for
> confirmation.

18.4.1.3

V

Ron Natalie

unread,
Nov 10, 2004, 11:28:48 AM11/10/04
to
James Hopkin wrote:
> Dear all
>
> Given any type T and a pointer, p, to suitably aligned memory, if I do
>
> #include <new>
> new (p) T;
>
> is
>
> static_cast<T*>(p)
>
> subsequently guaranteed to be a valid pointer to the newed object? I
> believe it is, but I'm not sure where to look in the standard for
> confirmation.
>
Yes, but that is not the case for
new (p) T[n];

The standard doesn't come right out and say it, but the allocator for
a scalar new gets the exact size of the requested type. The array
new is the array length times the size plus some overhead.

See 5.3.4/10 and 12

Maxim Yegorushkin

unread,
Nov 11, 2004, 6:13:37 AM11/11/04
to
On 9 Nov 2004 16:20:15 -0500, James Hopkin
<jho...@reflectionsinteractive.com> wrote:

> Given any type T and a pointer, p, to suitably aligned memory, if I do
>
> #include <new>
> new (p) T;
>
> is
>
> static_cast<T*>(p)
>
> subsequently guaranteed to be a valid pointer to the newed object? I
> believe it is, but I'm not sure where to look in the standard for
> confirmation.

Only when p has type of void*. Standard guaranties that pointer of any
type can be safely converted only to void* and back.

--
Maxim Yegorushkin

ka...@gabi-soft.fr

unread,
Nov 11, 2004, 6:15:23 AM11/11/04
to
jho...@reflectionsinteractive.com (James Hopkin) wrote in message
news:<a0368c9c.04110...@posting.google.com>...

> Given any type T and a pointer, p, to suitably aligned memory, if I do

> #include <new>
> new (p) T;

> is

> static_cast<T*>(p)

> subsequently guaranteed to be a valid pointer to the newed object?

Not if T is an array type. Otherwise, I think so, but I'm not too sure
where to look either.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Maxim Yegorushkin

unread,
Nov 11, 2004, 11:05:31 PM11/11/04
to
On 10 Nov 2004 11:28:48 -0500, Ron Natalie <r...@sensor.com> wrote:

> James Hopkin wrote:
>> Dear all
>>
>> Given any type T and a pointer, p, to suitably aligned memory, if I
do
>>
>> #include <new>
>> new (p) T;
>>
>> is
>>
>> static_cast<T*>(p)
>>
>> subsequently guaranteed to be a valid pointer to the newed object? I
>> believe it is, but I'm not sure where to look in the standard for
>> confirmation.
>>
> Yes, but that is not the case for
> new (p) T[n];

How about this:

struct T { int n; };
struct U { int m; };
struct V : U, T {};

V v, *p = &v;
new (p) T;
static_cast<T*>(p); // oops, points to (char*)p + sizeof(int) --
to
(uninitialized) T subobject of nonexistent V

--
Maxim Yegorushkin

Thomas Mang

unread,
Nov 12, 2004, 7:10:23 AM11/12/04
to

"Maxim Yegorushkin" <e-m...@yandex.ru> schrieb im Newsbeitrag
news:opsg8rv5...@devlx007.ipcb.net...

> On 9 Nov 2004 16:20:15 -0500, James Hopkin
> <jho...@reflectionsinteractive.com> wrote:
>
> > Given any type T and a pointer, p, to suitably aligned memory, if I do
> >
> > #include <new>
> > new (p) T;
> >
> > is
> >
> > static_cast<T*>(p)
> >
> > subsequently guaranteed to be a valid pointer to the newed object? I
> > believe it is, but I'm not sure where to look in the standard for
> > confirmation.
>
> Only when p has type of void*. Standard guaranties that pointer of any
> type can be safely converted only to void* and back.


If I read the Standard correctly, the conversions from base <-> derived are
also guaranteed to work.

Now take this example:


class some_class{};

int main()
{
void* Memory = new char[10 * sizeof(some_class)];
some_class * Buffer = static_cast<some_class*>(Memory);
}


The array-new expression yields a void * (a), that is then converted to a
char* (b) and then back to void* (c).
Now this void* is converted into some_class* (d).


a -> c should be fine, what about d?
From one point of view, we are only converting a void * to a some_class*
(c -> d). However, this is a subsequence of the conversion from a char* to a
some_class* (b -> d).


Is this little programm now defined or not?


Another question regarding the same idiom of allocating a buffer in a
char[]:

Is this line:

some_class * Buffer = (some_class*) new char[10 * sizeof(some_class)];

equivalent to 1)

some_class * Buffer = static_cast<some_class*>(static_cast<void*>(new
char[10 * sizeof(some_class)]));

or equivalent to 2)

some_class * Buffer = reinterpret_cast<some_class*>(new char[10 *
sizeof(some_class)]);

????

In case 1), the same issue as raised above would apply.

In case 2), the result is unspecified anyways.

Thomas

Branimir Maksimovic

unread,
Nov 12, 2004, 10:08:29 AM11/12/04
to
Ron Natalie <r...@sensor.com> wrote in message news:<41913870$0$31211$9a6e...@news.newshosting.com>...

> James Hopkin wrote:
> > Dear all
> >
> > Given any type T and a pointer, p, to suitably aligned memory, if I do
> >
> > #include <new>
> > new (p) T;
> >
> > is
> >
> > static_cast<T*>(p)
> >
> > subsequently guaranteed to be a valid pointer to the newed object? I
> > believe it is, but I'm not sure where to look in the standard for
> > confirmation.
> >
> Yes, but that is not the case for
> new (p) T[n];
>
> The standard doesn't come right out and say it, but the allocator for
> a scalar new gets the exact size of the requested type. The array
> new is the array length times the size plus some overhead.
>
> See 5.3.4/10 and 12

This rises another question.
When using
void* operator new[](size_t s)throw(std::bad_alloc);
compiler does the trick of calculating *that* overhead;
but, in case of placement version there is no portable way of knowing
how much bytes to reserve for it.
So we must supply another version of placement new in order
to avoid buffer overuns:
void* operator new[](size_t required_size,size_t real_size,void* p)
throw(std::bad_alloc)
{
if(real_size<required_size)throw std::bad_alloc();
return p;
}


This is the question:
Is placement version of array new completely useless? :)

Greetings, Bane.

Maxim Yegorushkin

unread,
Nov 14, 2004, 3:40:05 PM11/14/04
to
Thomas Mang wrote:

> > Only when p has type of void*. Standard guaranties that pointer of any
> > type can be safely converted only to void* and back.
>
>
> If I read the Standard correctly, the conversions from base <-> derived
> are also guaranteed to work.

Yes, but in the case with multiple base classes a compiler may adjust a
pointer, so that the cast result is not equal to the casted pointer.
Please, see my previous posting for a sample.

--
Maxim Yegorushkin

Thomas Richter

unread,
Nov 16, 2004, 9:13:33 PM11/16/04
to
Hi,

> When using
> void* operator new[](size_t s)throw(std::bad_alloc);
> compiler does the trick of calculating *that* overhead;
> but, in case of placement version there is no portable way of knowing
> how much bytes to reserve for it.

Right, but you don't need to. The compiler computes that, and includes it
in the size argument. Which is in bytes.

> So we must supply another version of placement new in order
> to avoid buffer overuns:
> void* operator new[](size_t required_size,size_t real_size,void* p)
> throw(std::bad_alloc)
> {
> if(real_size<required_size)throw std::bad_alloc();
> return p;
> }

No. What for? The operator new[] only provides raw memory. You ain't
supposed to know how many elements you need to reserve memory for.
Only the size of the memory is required to get it.

> This is the question:
> Is placement version of array new completely useless? :)

No.

So long,
Thomas

Branimir Maksimovic

unread,
Nov 17, 2004, 7:42:03 PM11/17/04
to
Thomas Richter <th...@cleopatra.math.tu-berlin.de> wrote in message news:<cnct35$ne1$1...@mamenchi.zrz.TU-Berlin.DE>...

> Hi,
>
> > When using
> > void* operator new[](size_t s)throw(std::bad_alloc);
> > compiler does the trick of calculating *that* overhead;
> > but, in case of placement version there is no portable way of knowing
> > how much bytes to reserve for it.
>
> Right, but you don't need to. The compiler computes that, and includes it
> in the size argument. Which is in bytes.

Of course, but I'm simply asking this:

class A{
public:
A(): puff_(0xdeadbeef)
{
}
int puff()const{ return puff_; }
~A(){std::cout<<puff_<<" D\n";}
private:
int puff_;
};

int main()
{

// Question: will this segfault on some systems?
char buf[10*sizeof(A)];
A* abuf = new ((void*)buf) A[10];
for(size_t i = 0;i<10;++i)
{
std::cout<<std::hex<<abuf[i].puff()<<'\n';
abuf[i].~A();
}

}


>
> > So we must supply another version of placement new in order
> > to avoid buffer overuns:
> > void* operator new[](size_t required_size,size_t real_size,void* p)
> > throw(std::bad_alloc)
> > {
> > if(real_size<required_size)throw std::bad_alloc();
> > return p;
> > }
>
> No. What for? The operator new[] only provides raw memory. You ain't
> supposed to know how many elements you need to reserve memory for.
> Only the size of the memory is required to get it.
>

Number of elements is not a question.
I mean this:
char buf[num_of_el*sizeof(T)];

new (sizeof(buf), (void*)buf) T[num_of_el];
// supplied version can throw std::bad_alloc

Greetings, Bane.

Thomas Richter

unread,
Nov 19, 2004, 7:57:11 AM11/19/04
to
Hi,

>> Right, but you don't need to. The compiler computes that, and includes it
>> in the size argument. Which is in bytes.

> Of course, but I'm simply asking this:

/* snip */

> // Question: will this segfault on some systems?
> char buf[10*sizeof(A)];
> A* abuf = new ((void*)buf) A[10];
> for(size_t i = 0;i<10;++i)
> {
> std::cout<<std::hex<<abuf[i].puff()<<'\n';
> abuf[i].~A();
> }

Ok, I see what you're aiming at. The point is that you cannot know the
byte size of the required memory in advance, thus you cannot use placement
array new for a placement allocation. (-; Thus, the above could really
segfault. But that doesn't render placement array new useless. It just
has other uses.

I guess the main problem is its name. Placement new can do a lot of
wonderful things besides "placing" objects into memory. It should rather
be called "new with parameters". A typical use for the placement new argument
would be that of a memory pool handle from which the memory has to be taken
for the allocation. In the above example, you wouldn't need to use placement
new in first place. Just allocating the "A" class objects one after another
at (buf + i * sizeof(A)) would also do that without the problem at hand
(keeping care of proper exception handling as well).

So long,
Thomas

Thomas Mang

unread,
Nov 19, 2004, 11:06:56 AM11/19/04
to

"Branimir Maksimovic" <bm...@volomp.com> schrieb im Newsbeitrag
news:88cdcbb3.04111...@posting.google.com...

Of course it can because it is undefined behaviour.

First, you assign a value to an int the Standard does not guarantee it can
represent.
Second, you ignore alignment.


Thomas

Branimir Maksimovic

unread,
Nov 20, 2004, 1:14:09 PM11/20/04
to
"Thomas Mang" <nos...@nospam.invalid> wrote in message
news:<419ccbb4$0$12130$3b21...@usenet.univie.ac.at>...

You got it wrong. It is not undefined behavior because of that.
First check out 4.7, it says value is implementation defined if
it cannot be represented in destination signed type.
Alse see 5.3.4/10 for explanation why alignment is not an issue here.
The other Thomas got it right. Problem is that you cannot portably know
*right* size without digging out parameter from operator new[].

Greetings, Bane.

Branimir Maksimovic

unread,
Nov 20, 2004, 1:17:19 PM11/20/04
to
"Thomas Mang" <nos...@nospam.invalid> wrote in message
news:<419ccbb4$0$12130$3b21...@usenet.univie.ac.at>...
> "Branimir Maksimovic" <bm...@volomp.com> schrieb im Newsbeitrag
> > char buf[10*sizeof(A)];

Ok, let's be strict here, theoretically there is possibility that
stand alone automatic char array wouldn't be aligned for any type of
appropriate size, (contrary to restrictrions imposed on allocation of
char arrays) so better put it this way:
char *buf = new char[10*sizeof(A)];

> > A* abuf = new ((void*)buf) A[10];

Greetings, Bane.

Branimir Maksimovic

unread,
Nov 20, 2004, 11:51:24 PM11/20/04
to
"Thomas Mang" <nos...@nospam.invalid> wrote in message news:<419ccbb4$0$12130$3b21...@usenet.univie.ac.at>...
> "Branimir Maksimovic" <bm...@volomp.com> schrieb im Newsbeitrag
> > // Question: will this segfault on some systems?
> > char buf[10*sizeof(A)];
> > A* abuf = new ((void*)buf) A[10];
.....
> Second, you ignore alignment.

Just to add another interesting thing. When calculating address
of automatic objects systems usually use some frame pointer.
Value of that pointer must have address of strictest alignment
in order to properly align anything else.
char array has weakiest alignment requirements so
char buf[3] can be placed at address (char*)frame-3.
but if you are carefull about size and aware of rules
for arrays in C++, you can be pretty sure that when writing
char buf[n*sizeof(T)];
address of buf will probably be calculated as (char*)frame-n*sizeof(T)
where frame points to most strickly aligned address.
Of course this does not hold water for dynamic allocation.
In that case expression new[] char[n] assures that array
meets most strictest alignment requirement.

Greetings, Bane.

Thomas Mang

unread,
Nov 21, 2004, 1:53:34 AM11/21/04
to

"Branimir Maksimovic" <bm...@volomp.com> schrieb im Newsbeitrag
news:88cdcbb3.0411...@posting.google.com...


I don't think 4.7 does apply (Frankly, my wording was not precise):

Types of integer literals are described in 2.13.1/2. Pay attention that is
clearly says "undefined behaviour" when the value cannot be represented as
long int. Can you point me to any guarantee that 0xdeadbeef can be
represented as long int?

> Alse see 5.3.4/10 for explanation why alignment is not an issue here.

You have already covered this yourself in your other reply.


Thomas

Thomas Mang

unread,
Nov 21, 2004, 1:54:06 AM11/21/04
to
Please let me make a correction to the other reply to you:


I found information in the C99 Standard (don't have the C90 Standard handy):

Here it follows from 5.2.4.2.1/1 that the values representable as long are
implementation defined. It seems whether the integral literal yields
undefined behaviour or not is determined by implementation defined
behaviour.


Thomas

Branimir Maksimovic

unread,
Nov 21, 2004, 6:23:31 PM11/21/04
to
"Thomas Mang" <nos...@nospam.invalid> wrote in message
news:<419fd6fc$0$12130$3b21...@usenet.univie.ac.at>...

I wrote:
> > You got it wrong. It is not undefined behavior because of that.
> > First check out 4.7, it says value is implementation defined if
> > it cannot be represented in destination signed type.
>
>
> I don't think 4.7 does apply (Frankly, my wording was not precise):
>
> Types of integer literals are described in 2.13.1/2. Pay attention that is
> clearly says "undefined behaviour" when the value cannot be represented as
> long int. Can you point me to any guarantee that 0xdeadbeef can be
> represented as long int?

Yes, you are right. If long int for target platform is less then 32 bits
that would be undefined behavior. I missed that paragraph.
One learns something new every day.

Greatings, Bane.

ka...@gabi-soft.fr

unread,
Nov 22, 2004, 4:34:51 PM11/22/04
to
bm...@volomp.com (Branimir Maksimovic) wrote in message
news:<88cdcbb3.04111...@posting.google.com>...

> "Thomas Mang" <nos...@nospam.invalid> wrote in message
> news:<419ccbb4$0$12130$3b21...@usenet.univie.ac.at>...
> > "Branimir Maksimovic" <bm...@volomp.com> schrieb im Newsbeitrag
> > > char buf[10*sizeof(A)];

> Ok, let's be strict here, theoretically there is possibility that
> stand alone automatic char array wouldn't be aligned for any type of
> appropriate size,

Not just theoretically. The compilers I've used don't bother to force
alignment of local variables any more than necessary. If this is the
only local variable, it will be aligned, because it will be the first
(and only) thing in the local stack frame, and the local stack frame is
always aligned. If it follows a single char variable, it will NOT be
aligned.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[ See http://www.gotw.ca/resources/clcm.htm for info about ]

ka...@gabi-soft.fr

unread,
Nov 22, 2004, 4:34:23 PM11/22/04
to
bm...@volomp.com (Branimir Maksimovic) wrote in message
news:<88cdcbb3.04112...@posting.google.com>...

> "Thomas Mang" <nos...@nospam.invalid> wrote in message
> news:<419fd6fc$0$12130$3b21...@usenet.univie.ac.at>...
> I wrote:
> > > You got it wrong. It is not undefined behavior because of that.
> > > First check out 4.7, it says value is implementation defined if it
> > > cannot be represented in destination signed type.

> > I don't think 4.7 does apply (Frankly, my wording was not precise):

> > Types of integer literals are described in 2.13.1/2. Pay attention
> > that is clearly says "undefined behaviour" when the value cannot be
> > represented as long int. Can you point me to any guarantee that
> > 0xdeadbeef can be represented as long int?

> Yes, you are right.

Not quite.

> If long int for target platform is less then 32 bits that would be
> undefined behavior.

A long must be at least 32 bits. But a 32 bit long will only hold a 31
bit positive value -- 0xdeadbeef would be illegal. Except that if the
constant is octal or hexadecimal (which it is in this case), the upper
limit is what can be represented in an unsigned long. So we're safe.

The original code converted this to an int. An int may be only 16 bits,
so the value may not be representable. If the value isn't
representable, the results are implementation defined. The C standard
makes it clear that an implementation may specify it by specifying that
an implementation defined signal is raised.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[ See http://www.gotw.ca/resources/clcm.htm for info about ]

Thomas Mang

unread,
Nov 23, 2004, 5:58:34 AM11/23/04
to

<ka...@gabi-soft.fr> schrieb im Newsbeitrag
news:d6652001.04112...@posting.google.com...

> bm...@volomp.com (Branimir Maksimovic) wrote in message
> news:<88cdcbb3.04112...@posting.google.com>...
> > "Thomas Mang" <nos...@nospam.invalid> wrote in message
> > news:<419fd6fc$0$12130$3b21...@usenet.univie.ac.at>...
> > I wrote:
> > > > You got it wrong. It is not undefined behavior because of that.
> > > > First check out 4.7, it says value is implementation defined if it
> > > > cannot be represented in destination signed type.
>
> > > I don't think 4.7 does apply (Frankly, my wording was not precise):
>
> > > Types of integer literals are described in 2.13.1/2. Pay attention
> > > that is clearly says "undefined behaviour" when the value cannot be
> > > represented as long int. Can you point me to any guarantee that
> > > 0xdeadbeef can be represented as long int?
>
> > Yes, you are right.
>
> Not quite.
>
> > If long int for target platform is less then 32 bits that would be
> > undefined behavior.
>
> A long must be at least 32 bits. But a 32 bit long will only hold a 31
> bit positive value -- 0xdeadbeef would be illegal. Except that if the
> constant is octal or hexadecimal (which it is in this case), the upper
> limit is what can be represented in an unsigned long. So we're safe.

Thank you for pointing out my misconception.


What's the rationale behind the different behaviour of decimal vs. ocatal /
hexadecimal integer literals?

Thomas

Thomas Richter

unread,
Nov 23, 2004, 1:45:52 PM11/23/04
to
Hi Thomas,

> What's the rationale behind the different behaviour of decimal vs. ocatal /
> hexadecimal integer literals?

As far as I can tell, the idea is that hexadecimal notation is often
used in conjunction with "bit juggling", e.g. manupulating hardware
directly. And this is the domain of the C++ unsigned types and their
guaranteed bit layout, including modulo arithmetic.

So long,

Branimir Maksimovic

unread,
Nov 23, 2004, 1:50:29 PM11/23/04
to
ka...@gabi-soft.fr wrote in message news:<d6652001.04112...@posting.google.com>...

> bm...@volomp.com (Branimir Maksimovic) wrote in message
> news:<88cdcbb3.04111...@posting.google.com>...
> > "Thomas Mang" <nos...@nospam.invalid> wrote in message
> > news:<419ccbb4$0$12130$3b21...@usenet.univie.ac.at>...
> > > "Branimir Maksimovic" <bm...@volomp.com> schrieb im Newsbeitrag
> > > > char buf[10*sizeof(A)];
>
> > Ok, let's be strict here, theoretically there is possibility that
> > stand alone automatic char array wouldn't be aligned for any type of
> > appropriate size,
>
> Not just theoretically. The compilers I've used don't bother to force
> alignment of local variables any more than necessary. If this is the
> only local variable, it will be aligned, because it will be the first
> (and only) thing in the local stack frame, and the local stack frame is
> always aligned. If it follows a single char variable, it will NOT be
> aligned.

Again, I was wrong. That is likely scenario on sparcs for example.
They can address single char but will fault for other types.
There is another interesting thing. We have alloca which is not
part of posix but it is there. In order to provide functionallity
of this function, systems usually padd every variable on stack,
but of course if they see something like:

char c; char buff[4]; // buff can be at address (char*)frame-5
// and we have a alignment problem if we want to cast
// for example, short* tmp = (short*)buff;
// we will probably get buss errors

Greetings, Bane.

David Olsen

unread,
Nov 24, 2004, 4:29:44 AM11/24/04
to
Thomas Mang wrote:
> What's the rationale behind the different behaviour of decimal vs. ocatal /
> hexadecimal integer literals?

Quoting from the original C standard rationale (which was published with
the original ANSI C standard), section 3.1.3.2:

'Unlike decimal constants, octal and hexadecimal constants too large to
be ints are typed as unsigned int (if within range of that type), since
it is more likely that thay represent bit patterns or masks, which are
generally best treated as unsigned, rather than "real" numbers.'


--
David Olsen
qg4h9...@yahoo.com

ka...@gabi-soft.fr

unread,
Nov 24, 2004, 6:56:12 PM11/24/04
to
"Thomas Mang" <nos...@pop.ucsd.edu> wrote in message
news:<41a26905$0$12646$3b21...@usenet.univie.ac.at>...

> > > Yes, you are right.

> > Not quite.

To add yet another special rule for beginners to have to learn:-) ?

Seriously, I suppose it is because when you use octal and hexadecimal
constants, you are typically interested in the bit by bit
representation, in which the sign bit is nothing special, where as when
you use a decimal constant, you are interested in the value itself.

Formally, it's still a bit awkward. For example, on most systems, there
is no way of specifying LONG_MIN as an expression using a single decimal
constant without invoking undefined behavior. (Note that all integral
literals are positive. And on a 32 bit machine, in the expression
-2147483648, the integral literal 2147483648 cannot be represented in a
long int, even though the results of the expression can be. So
formally, you have to write something like -2147483647-1. In practice,
this is one undefined behavior which in fact works as expected pretty
much everywhere.)

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[ See http://www.gotw.ca/resources/clcm.htm for info about ]

Ben Hutchings

unread,
Nov 26, 2004, 11:02:27 PM11/26/04
to
Branimir Maksimovic wrote:
<snip>

> When using
> void* operator new[](size_t s)throw(std::bad_alloc);
> compiler does the trick of calculating *that* overhead;
> but, in case of placement version there is no portable way of knowing
> how much bytes to reserve for it.
<snip>

> This is the question:
> Is placement version of array new completely useless? :)
<snip>

It's useless in portable code. I submitted a defect report about this
in September, which is now core issue 476.

--
Ben Hutchings
Q. Which is the greater problem in the world today, ignorance or apathy?
A. I don't know and I couldn't care less.

Reply all
Reply to author
Forward
0 new messages