Hi Guys,

I am encountering the following issue :

void* pMemory = m_Allocator.allocate( uiSize * sizeof( T ) );
m_atData = new( pMemory ) T[m_uiSize];

Debug.vc8.scurc.exe!`eh vector constructor iterator'(void *
ptr=0x00514b9c, unsigned int size=12, int count=12, void (void *)*
pCtor=0x00414537, void (void *)* pDtor=0x00414523) + 0x5e bytes C++

Do I need to code my own construct_n( ) ? I am ok with it but I just
want to know why there is an offset between m_atData and pMemory.

Technically I believe the m_atData should point to the same location
as pMemory after placement new is done. However this is turning out to
be false. The address of m_atData is addressof pMemory + 4. Iam
puzzled as this does not happen all the time. For some classes it
works fine and for others it dont.

I might be naive on this although I have tried debugging most of the
trivial stuff. Could someone please ?

Thanks in advance
Venkatesh.SC

On Dec 26, 11:06 am, sparc <sc.venkat...@gmail.com> wrote:
> Hi Guys,
>
> I am encountering the following issue :
>
> void* pMemory = m_Allocator.allocate( uiSize * sizeof( T ) );
> m_atData = new( pMemory ) T[m_uiSize];
>
> Debug.vc8.scurc.exe!`eh vector constructor iterator'(void *
> ptr=0x00514b9c, unsigned int size=12, int count=12, void (void *)*
> pCtor=0x00414537, void (void *)* pDtor=0x00414523) + 0x5e bytes C++
>
> Do I need to code my own construct_n( ) ? I am ok with it but I just
> want to know why there is an offset between m_atData and pMemory.
>
> Technically I believe the m_atData should point to the same location
> as pMemory after placement new is done. However this is turning out to
> be false. The address of m_atData is addressof pMemory + 4. Iam
> puzzled as this does not happen all the time. For some classes it
> works fine and for others it dont.
>
> I might be naive on this although I have tried debugging most of the
> trivial stuff. Could someone please ?
>
> Thanks in advance
> Venkatesh.SC

read:
[11.10] What is "placement new" and why would I use it?
http://www.parashift.com/c++-faq-lit...html#faq-11.10

and pay carefull attention to the sections labelled ADVICE and DANGER
(its your responsability to insure that alignment of allocation area
and the object type concur)

Consider showing a compileable code snippet to illustrate the problem.
You don't need to post 1000 lines, a minimal test case will do.

Hi,


Thanks for the quick reply. I believe it probably is an issue with
the alignment although I haven't really digged deeper. I wrote my own
vector construtor iterator which works well anyway (which would work
in most platforms).

Thanks again,
Venkatesh.SC

sparc wrote:
> Hi,
>
>
> Thanks for the quick reply. I believe it probably is an issue with
> the alignment although I haven't really digged deeper. I wrote my own
> vector construtor iterator which works well anyway (which would work
> in most platforms).
>
> Thanks again,
> Venkatesh.SC

The size that new[] needs from the allocator is M + n*sizeof(T)
where T is the type being allocated, n is the number of elements
in the array and M is some unspecified overhead value (typically
it's sizeof(size_t) or somethine like that).

On Dec 28, 8:35am, Ron Natalie <r...@spamcop.net> wrote:
> sparc wrote:
> > Hi,
>
> > Thanks for the quick reply. I believe it probably is an issue with
> > the alignment although I haven't really digged deeper. I wrote my own
> > vector construtor iterator which works well anyway (which would work
> > in most platforms).
>
> > Thanks again,
> > Venkatesh.SC
>
> The size that new[] needs from the allocator is M + n*sizeof(T)
> where T is the type being allocated, n is the number of elements
> in the array and M is some unspecified overhead value (typically
> it's sizeof(size_t) or somethine like that).

Hi,

Thanks. Yes. That is right. But I am just wondering why it adds for
certain
classes. I dont think a constructor iterator would need this overhead
due to inheritance as it does occur even for base types.

Btw, any idea why this overhead is added? Just curious. Thanks again
for the reply.

Venkatesh.SC

On 2007-12-29 14:06:59 -0600, sparc <sc.venkatesh@gmail.com> said:

> On Dec 28, 8:35am, Ron Natalie <r...@spamcop.net> wrote:
>> sparc wrote:
>>> Hi,
>>
>>> Thanks for the quick reply. I believe it probably is an issue with
>>> the alignment although I haven't really digged deeper. I wrote my own
>>> vector construtor iterator which works well anyway (which would work
>>> in most platforms).
>>
>>> Thanks again,
>>> Venkatesh.SC
>>
>> The size that new[] needs from the allocator is M + n*sizeof(T)
>> where T is the type being allocated, n is the number of elements
>> in the array and M is some unspecified overhead value (typically
>> it's sizeof(size_t) or somethine like that).
>
> Hi,
>
> Thanks. Yes. That is right. But I am just wondering why it adds for
> certain
> classes. I dont think a constructor iterator would need this overhead
> due to inheritance as it does occur even for base types.
>
> Btw, any idea why this overhead is added? Just curious. Thanks again
> for the reply.

Think about what information must be available when you delete[] the array...

-dr

sparc wrote:

>
> Thanks. Yes. That is right. But I am just wondering why it adds for
> certain
> classes.

Well, the details are "magic" but the truth of the matter is that the
C++ allocation functions are designed to be as completely stupid as
the C malloc/free ones (as a matter of fact they are trivially
implemented as direct calls to those).

As a result you have the same stupidities that malloc suffers from.
There is no external interface to tell what size the allocation is
(even though the internal arena manipulation obviously has to know
this). So, in the case of an array of classes that have destructors,
the code needs to squirrel away the number of objects so it knows
how many objects to invoke destructors on.