quote:Original post by Namethatnobodyelsetook
You could always define your own ''new''s that can perform a realloc operation behind the scenes. That''s the only C++ friendly way I can think of... and having thought of it, I think I''m off to code myself up one.

Thinking about it, this ISN''T such a great idea, as the reallocing new will still call constructors for the previously existing members...

Do you have any reason not to use realloc, and placement new on each new member, or manually call destructors when shrinking? I''ve done this technique before for a dynamic array and it works perfectly.

quote:Original post by Namethatnobodyelsetook

quote:Original post by Namethatnobodyelsetook
You could always define your own ''new''s that can perform a realloc operation behind the scenes. That''s the only C++ friendly way I can think of... and having thought of it, I think I''m off to code myself up one.

Thinking about it, this ISN''T such a great idea, as the reallocing new will still call constructors for the previously existing members...

Do you have any reason not to use realloc, and placement new on each new member, or manually call destructors when shrinking? I''ve done this technique before for a dynamic array and it works perfectly.

I just don''t want to use C dynamic allocation functions. I am using C++ new and delete. I was just wondering if C++ had anything and now I know it''s no. Reason is I just wanted to use one pointer that was allocated with new for my texture loader and reallocate memory for different sizes and bit depths. =) But I am going to keep on doing what I have been each call to LoadTGA() I call new and delete it. Then if I call the function again I do it all over again. I have a Class for loading .tga files. Thanks

quote:Original post by Anonymous Poster
Anyway, I wouldn't worry about fragmentation. Realloc can't do anything more than what the library can do with a delete and a successive new. In fact, realloc needs to preserve the block contents, which may be a bit of a disadvantage (and certainly causes an unnecessary copy if you want to re-write the block).

quote:Original post by jeeky
In any event, "expanding" you array size does result in creation of a new larger buffer and copying the contents of the old one over, no matter what.

If there was no benefit of realloc over a malloc() and memcpy(), realloc wouldn't exist. In fact - try implementing your own malloc sometime, it's a really good exercise for insight into how memory management really works. Unix systems provide the sbrk() system call which is used to implement malloc. You'll see that it's quite possible to increase the size of allocated blocks.

The easiest way to find out is to confirm it yourself.

int *a = malloc(4);int *b = realloc(a, 8);return a == b;  

The "new" block has the same adress as the "old" block. Also, you shouldn't be doing this kind of stuff at all if you didn't want to keep the contents of the memory.

As such, realloc is potentially enormously more efficient than new/copy/delete, since you don't need to run a few thousand constructors/assignment operators to shift memory around.

/Stary

[edited by - Stary on September 1, 2003 8:56:52 AM]

quote:Original post by Stary

quote:Original post by Anonymous Poster
Anyway, I wouldn''t worry about fragmentation. Realloc can''t do anything more than what the library can do with a delete and a successive new. In fact, realloc needs to preserve the block contents, which may be a bit of a disadvantage (and certainly causes an unnecessary copy if you want to re-write the block).

quote:Original post by jeeky
In any event, "expanding" you array size does result in creation of a new larger buffer and copying the contents of the old one over, no matter what.

If there was no benefit of realloc over a malloc() and memcpy(), realloc wouldn''t exist. In fact - try implementing your own malloc sometime, it''s a really good exercise for insight into how memory management really works. Unix systems provide the sbrk() system call which is used to implement malloc. You''ll see that it''s quite possible to increase the size of allocated blocks.

The easiest way to find out is to confirm it yourself.

int *a = malloc(4);int *b = realloc(a, 8);return a == b;   

The "new" block has the same adress as the "old" block. Also, you shouldn''t be doing this kind of stuff at all if you didn''t want to keep the contents of the memory.

As such, realloc is potentially enormously more efficient than new/copy/delete, since you don''t need to run a few thousand constructors/assignment operators to shift memory around.

/Stary

[edited by - Stary on September 1, 2003 8:56:52 AM]

Hold on. With new and delete their is no constructor or deconstructors being called for simple variables like int, float ect... now with objets yes. Calling new or delete with int is like calling malloc or free.

Maybe you are making it hard for yourself by having a single class containing both the texture definition and the pixel data. If your data structure contains some form of header {width,height,bits,colortype} and an area for the picture data, then you could use new/delete on the header and malloc/free/realloc on the data pointer the header class would contain.