placement new called by vector<> during resizing.

[Anu]

Hi,

We have a class that has its own overloaded operator new and whose
prototype seems to correspond to the standard placement new :-
class AppClass
{
public:
operator new (size_t size, void *ctx)

......
}

The ctx is important for us. Now we find that if we have a
vector<AppClassinstance, when the vector is resized, our overloaded
operator new is called!. Here is the comment from the STL vector
implementation :-

template<class _T1,
class _T2inline
void _Construct(_T1 _FARQ *_Ptr, const _T2& _Val)
{ // construct object at _Ptr with value _Val
new ((void _FARQ *)_Ptr) _T1(_Val);
}

Is this documented somewhere in the standard? Or should we have
chosen our operator new's signature more carefully? Can I do some easy
thing to get around this issue?

Thanks in advance,
anu.

[Victor Bazarov]

Anu wrote:

We have a class that has its own overloaded operator new and whose
prototype seems to correspond to the standard placement new :-
class AppClass
{
public:
operator new (size_t size, void *ctx)

.....
}

The ctx is important for us. Now we find that if we have a
vector<AppClassinstance, when the vector is resized, our overloaded
operator new is called!. Here is the comment from the STL vector
implementation :-

template<class _T1,
class _T2inline
void _Construct(_T1 _FARQ *_Ptr, const _T2& _Val)
{ // construct object at _Ptr with value _Val
new ((void _FARQ *)_Ptr) _T1(_Val);
}

Is this documented somewhere in the standard?

No, it's an implementation detail.

Or should we have
chosen our operator new's signature more carefully?

I can't speak to that. You provided no information about the problem
you were solving by having your overloaded operator new with your
particular signature.

Can I do some easy
thing to get around this issue?

Probably.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Roland Pibinger]

On 20 Apr 2007 05:08:25 -0700, Anu wrote:

We have a class that has its own overloaded operator new and whose
prototype seems to correspond to the standard placement new :-

class AppClass
{
public:
operator new (size_t size, void *ctx)
.....
}
The ctx is important for us. Now we find that if we have a
vector<AppClassinstance, when the vector is resized, our overloaded
operator new is called!

[...]

>Or should we have
chosen our operator new's signature more carefully? Can I do some easy
thing to get around this issue?

class AppClass
{
//...
operator new (size_t size, MyPool* ctx);
};
--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

[James Kanze]

On Apr 20, 3:04 pm, "Victor Bazarov" <[e-mail]:

Anu wrote:

We have a class that has its own overloaded operator new and whose
prototype seems to correspond to the standard placement new :-

class AppClass
{
public:
operator new (size_t size, void *ctx)
.....
}

The ctx is important for us. Now we find that if we have a
vector<AppClassinstance, when the vector is resized, our overloaded
operator new is called!. Here is the comment from the STL vector
implementation :-

template<class _T1,
class _T2inline
void _Construct(_T1 _FARQ *_Ptr, const _T2& _Val)
{ // construct object at _Ptr with value _Val
new ((void _FARQ *)_Ptr) _T1(_Val);
}

Is this documented somewhere in the standard?

No, it's an implementation detail.

Not really. The standard does require that the implementation
of vector separate allocation and construction, and the only way
to call a constructor is by using placement new.

I would consider this a bug in the library; the statement in
question should be:
::new ((void _FARQ *)_Ptr) _T1(_Val);
, since this is the only way to guarantee that you get the
standard placement new. I think a bug report is justified. (On
the other hand, I'm not really too surprised about the bug.
It's the sort of thing that's easy to overlook.)

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Bo Persson]

James Kanze wrote:
:
: I would consider this a bug in the library; the statement in
: question should be:
: ::new ((void _FARQ *)_Ptr) _T1(_Val);
: , since this is the only way to guarantee that you get the
: standard placement new. I think a bug report is justified. (On
: the other hand, I'm not really too surprised about the bug.
: It's the sort of thing that's easy to overlook.)

This is the way it looks like in the current release of the library.

The OP uses an older version of the compiler.
Bo Persson