[quote name='iMalc' timestamp='1309639192' post='4830459']
You should never use realloc under any circumstances in a C++ program. In fact you shouldn't even use it in a C program as I don't think I've ever seen anyone posting using it both correctly and appropriately. Besides, realloc isn't always going to avoid copying either.

Well, although Misery was beginner, this is not beginners forum...

I have used realloc extensively in both C and C++ programs and have not had any problems. Right tool for the right job
[/quote]Then you appear to be an exception to the rule.

Of course using realloc etc was at best unnecessary, and at worst you just haven't seen the issues yet and they'll still get you one day.

[quote name='Lauris Kaplinski' timestamp='1309640193' post='4830463']
I have used realloc extensively in both C and C++ programs and have not had any problems. Right tool for the right job

How to do it properly? I will use memory pools anyway, but I need to finish that class I have begun.

And I'm not really a beginner, however I am not educated programmer, but fluid mechanics engineer, so many things for me are unclear.
I'm just an user of programming.
[/quote]
MyType *newptr = (MyType *) realloc (oldptr, newsize * sizeof (MyType));
for (size_t i = oldsize; i < newsize; i++) {
// Initialize your new data here
}

• Do not try it with non-POD types! Although there is placement new, things get ugly fast.
• Do not forget, that the block address may change - thus you should NOT keep extra pointers to it.
• Do not forget, that your old memory block may be freed and completely new one allocated. Thus you cannot keep pointers to individual objects.
• Your old objects (datablocks) will be copied bit-by-bit. If this is not the intended behaviour, do not use it.
• Your new objects (datablocks) will be uninitialized - i.e. filled with arbitrary garbage.
• If new memory block is allocated, neither destructors nor copy contructors are called
• It is better to avoid MyType constructors altogether. Then you cannot expect it to be called (it won't).

In general, there should be very good reasons to use malloc/realloc/free in C++ code. One possible cause is to reduce unnecessary pointer dereferencing - something like:

struct VectorPath {
unsigned int size;
unsigned int nelements;
Rect bbox;
float coordinates[2];
};

In this example you can construct paths of arbitrary length by allocating more memory than the size of given struct and then access coordinates >= 2. I think this may be violating C/C++ standard, but I do not think there is or will be any compiler that does not support it. But in any case such constructs require good and clean encapsulation - or they'll bite you.

My suggestion is - use new/delete and copy manually, or use vectors. Encapsulate the required behaviour into clean API and get your program working. Then you can experiment with more esoteric things ;-)

[quote name='Hodgman' timestamp='1309621495' post='4830371']
You're posting about problems stemming from errors caused by non-constructed non-pod types (a very dangerous thing to do), but are going to criticize the standard library for having strange resizable-bool-array iterator semantics?

Are you making a resizable array of bools or a resizable array of non-pod types?

vector <bool> has not only strange non-stl semantics. It also forces compiler to optimise code inproperly. If many clever ppl say: never use vector<bool> i do not use it.
And the other thing is that vectors are quite big 20 bytes for an empty vector. One more thing is that vectors reserve much more memory than needed. I know that one can use v.reserve()
but after I exceed reserved memory it will reserve again twice more than needed and so on.
In fact I need a bit array. My basic class is byte that allows me to access every bit.
[/quote]


Why not override the allocator?