you should not use malloc. new does everything malloc does, and more (actually new calls malloc). And you should not change the size of an array frequently, as it is a very expensive method (copying the whole array to another one). If you have to, use dynamic lists as Corrail mentioned. btw what do you want to implement?

"Knowledge is no more expensive than ignorance, and at least as satisfying." -Barrin

It''s pretty simple actually;

I am making an animation editor in which i have to load objects. For testing i had an array of type OBJ (my object class) with 50 elements (allocated in stack) with one element for each object. As the number of objects may vary from 5 to over a hundred i would like to allocate the memory needed to store the objects only when it''s needed.

I just came up with the fact that it will only cost 500 kb to allocate like 200,000 elements so that isn''t really a problem anymore . Anyway i''d like to learn how you could do it best anyway as i will certainly need it later on.

Well if the objects are big (lots of variables), then the way I do it is:

Object ** myArray;myArray = new Object * [ number ];for( unsigned int i = 0; i < number; ++i )myArray[i] = new Object;

That way resizing is only the cost of copying a few pointers instead of the whole object

[edited by - m_e_my_self on February 1, 2004 3:54:11 PM]

quote:

---

No.

new[] a bigger array, copy everything over, and delete[] the
old one.

---

No.

by doing this, you will loose the whole point of using realloc(), that is: when there is enough space to extend the current memory block to the new size, all realloc does is extend this size without copying anything. this is really fast. it reallocates a new memory block and copyes the contents of the old block into the new one only if there isn't enough space to extend the block.

quote:

---

And you should not change the size of an array frequently, as it is a very expensive method (copying the whole array to another one).

---

no, see up there...
and of course, a bad implementation of realloc will never try to extend the current block, but that's another problem

or better: code your own memory manager

[edited by - sBibi on February 1, 2004 4:09:24 PM]

quote:

---

Original post by sBibi

quote:

---

No.

new[] a bigger array, copy everything over, and delete[] the
old one.

---

No.

---

Huh? No what? That''s the *ONLY* way to make a bigger
array created by new[]. No if''s, and''s, or but''s.

quote:

---

by doing this, you will loose the whole point of using realloc(),

---

So? The array was created by new[]. What''s your point?

---

Kami no Itte ga ore ni zettai naru!

Learn std::vector before you learn dynamicly allocated arrays

Why not just use a linked-list? It's just plain stupid to completely copy/move an array every time you need to add one index. The bigger it gets, the longer it'll take to reallocate.

[edited by - the etwinox on February 1, 2004 4:46:58 PM]

So, you should not use any of this operators:
new[],delete[]
with any of these functions:
malloc,realloc,free

What i would like to know if you really can't/shouldn't use realloc in combination with new[] and delete[]. Why not ?

Thanks

EDIT: i get it, no, because the constructor won't be called then.

[edited by - Tree Penguin on February 1, 2004 4:52:32 PM]

quote:

---

Original post by The Etwinox
Why not just use a linked-list? It's just plain stupid to completely copy/move an array every time you need to add one index. The bigger it gets, the longer it'll take to reallocate.

---

Modern vectors are not that bad - they usually double the array size every time they allocate, so it's usually a constant time insert at the end (burn memory to save time). Lists also lack random access (rather, O(1) random access); they may be great if you have to iterate over the whole list, or do a lot of inserts/erases in the middle, but are terrible if you need random acces and primarily insert/erase at the end.

It's a matter of choosing the correct tool for the job; you have to know the capabilities and limitations of the tool.



[edited by - ze_jackal on February 1, 2004 4:54:57 PM]

The Etwinox: can you explain linked lists to me? I think it will not be really handy with my code, as i will have to call loading functions (or a constructor) anyway so it will take more time for sure.