• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 54 subscribers
  • Views 1229 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

override the operator new[](size_t size)

hu matt
Prodigy 80 points
Other Parts Discussed in Thread: SYSBIOS

Hi,

I override the operator new[](size_t size) in my application and monitor the memory allocation and release.

However, I found a strange thing (environment: CCS5, C28346 evaluation board):

For built-in type (e.g. int,) , size is transferred in operator new[]() is correct.

For no explicit constructor class, the size is also correct for operator new[]().

For "normal" class with constructor, the size is transferred into operator new[]() is: sizeof(Class)*numberOfClass + 4 (why does compiler to insert this extra 4 words?)

e.g.   

class SimpleClass

{

public:
SimpleClass(){

}
private:
int i;

};


if new SimpleClass[1], the size in operator new[]() is 5 (4+1) ,  the MAU is word(16bits).


Looking forward to your response.

Thank you.

Matt

  • 0
    Prodigy 80 points

    BTW,

    As far as "void* operator new(size_t size)" is concerned, it works fine for all cases.

  • 0
    TI__Guru* 84285 points

    The extra space is to store the size of the array, for use during operator[].  I don't recall all of the details at the moment.

  • 0 in reply to Archaeologist
    Prodigy 80 points

    Thanks.

    But in case of compiler synthesized constructor/desctrutor (no explicit constructor and destructor by users),  new XXX[2] does NOT need this space for array??

  • 0 in reply to Archaeologist
    Prodigy 80 points

    On the generic C++ application (e.g. Eclipse CDT project), the size of new[] always equals  SizeOfObject*NumberOfObjects, no extra space for array.

    Seems this being specific tactic for TI compiler?

  • 0 in reply to hu matt
    TI__Guru* 84285 points

    Such things are inherently compiler-specific.  Is there some reason your function needs to be aware of the details?

  • 0 in reply to Archaeologist
    Prodigy 80 points

    Background:

    My application needs dynamic memory management (allocate and free).

    The memory is based on ti.sysbios.heaps.HeapMem and generic memory API (Memory_allocate() and Memory_free())

    The Memory_free() api requires the size of to-be-freed memory.

    Therefore, I need to know the exact size of memory allocated and freed.

    Thanks.

     

  • 0 in reply to hu matt
    TI__Guru* 84285 points

    It is the responsibility of operator new[]() to keep track of the actual allocation size somewhere.  You could do this by increasing the requested size to include space for header information directly in the allocated block, or keep some sort of separate data structure.

    Even when the caller of operator new[]() asks for extra space to store the size of the array, you can't use this to determine the size of the allocated block; this size represents the number of entries in the array for an array of classes with non-trivial destructors.  The idea is that delete[] needs to know how many times to call the destructor.

  • 0 in reply to Archaeologist
    Prodigy 80 points

    In case of normal cases (new[] and delete[]), compiler can handle this size properly. This is understood.

    Also, I verified this by overriding them with standard C malloc&free.

    My question is: for sysbios/XDC memory API (Memory_allocate/Memory_free), both of them required explicit size of memory to allocate and free.

    You know, the operator delete[](void*) doesn't explicit "size" parameter, and this operator is invoked by "delete[]" operation.

    Anyway, two observations to this question:

    1. TI compiler insert extra space for operator new[](size), than standard C++ compiler.

    2. It is no way to use Memory_allocate/Memory_free to override operator delete[](void*), and malloc&free should be used instead.