22 replies to this topic

[Misery]

Hi,

I have a problem with malloc function.
I am using mallog in the manner:

TMyClass *ClInstancePtr;

CInstancePtr=(TMyClass*) malloc(sizeof(TMyClass)*NumOfElements);

And it doesn't work properly. It behaves just lke I hadn't allocated anything.
F ex.:

ClInstance[2]=some values;
cout<<ClInstance<<endl; 
output - some random data.

What am I doing wrong?

Thanks in advance for any help.
Regards,
Misery.

PS.: When I use new[ ]/delete [ ] it works fine.

[vdaras]

Using malloc doesn't construct any object in the array, it only allocates the requested memory.

Why do you need to use malloc instead of new[]?

[Misery]

Why do you need to use malloc instead of new[]?

Because I want to have possibility to resize my data without copying it.
How to make an array in place of malloc?

[braindigitalis]

You must copy the pointers but do not need to copy through objects referenced by them. New does not provide an equivalent to realloc unfortunately :-(

[King Joffrey]

Why do you need to use malloc instead of new[]?

Because I want to have possibility to resize my data without copying it.
How to make an array in place of malloc?

Use stl containers instead, it will save you a lot of bother. However, for the sake of explanation... you'll have to copy the data over anyway as malloc will allocate memory at a DIFFERENT address to the one you got when you first called malloc, thus you will lose the data. Not only that, but it will be leaked memory as you didn't free it before reallocating new memory. Anyway, use the new and delete operators as they are the "proper way of doing things", and for good reason. To allocate and delete arrays, you use new[] and delete[] operators respectively. If you wish to resize a dynamically created array, you would allocate a temporary dynamic array of existing size and then copy the contents of your existing array across. Then you would delete the contents of your existing array and reallocate a new array of the desired size, before transferring the contents of your temporary array across. Finally, delete you would the temporary array.

[SimonForsman]

Why do you need to use malloc instead of new[]?

Because I want to have possibility to resize my data without copying it.
How to make an array in place of malloc?

why not just use a vector or list ? (std::vector or std::list)

anyway as vdaras said malloc doesn't construct the object (the constructor is never called) it only allocates memory for it. (malloc is the C way of allocating memory, C doesn't support classes so trying to use a memory block allocator to create class instances will result in some major headaches)

[vdaras]

Use std::vector and you are golden.

[Misery]

Why not stl?
Does something like vector<bool> tell You guys something?
Thats why not stl.

[King Joffrey]

Does something like vector<bool> tell You guys something?

I'm not following. You can have containers of objects, no problem.

[mrchrismnh]

Why not stl?
Does something like vector<bool> tell You guys something?
Thats why not stl.

Don't use STL because it allows you to create a resizeable bool array?

[Hodgman]

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?

[Michael N.]

Does something like vector<bool> tell You guys something?

I'm not following. You can have containers of objects, no problem.

Blind guess: He's probably referring to the overhead. Well, you also have the same with an array of bools. If you want to use only a single bit for each bool you need to use bitmasks on top of that. Still until now, there wasn't a single reason not to consider STL containers.

[Brother Bob]

Does something like vector<bool> tell You guys something?

I'm not following. You can have containers of objects, no problem.

Blind guess: He's probably referring to the overhead. Well, you also have the same with an array of bools. If you want to use only a single bit for each bool you need to use bitmasks on top of that. Still until now, there wasn't a single reason not to consider STL containers.

std::vector<bool> is a specialization that stores bools tightly packed. This is mandated by the specification.

[Misery]

I need resizable bool array with tightly packed data. i mean one bit = one bool value.
Second thing is that I will use millions of instances of this class. And vector<bool>
requires (with zero entries) 20 bytes of memory. At start. Thats too much.
Therefore I have decided to create a class that has ability to resize, contains chars, and has ability to access every bit in char.
The only last problem is how to resize this fast.

Why did You guys vote down?

[Brother Bob]

I need resizable bool array with tightly packed data. i mean one bit = one bool value.

std::vector<bool> is, as I've already said, tightly packed.

Second thing is that I will use millions of instances of this class. And vector<bool>
requires (with zero entries) 20 bytes of memory. At start. Thats too much.
Therefore I have decided to create a class that has ability to resize, contains chars, and has ability to access every bit in char.
The only last problem is how to resize this fast.

You need a minimum of three pointers or integers; one to hold your buffer; one to hold the allocated buffer size, or the end of the buffer, so you know when to resize; and one to hold the current size, or the current write location. Assuming two pointers and an integer, that adds up to 20 bytes (assuming a 64 bit system with 64 bit pointers and 32 bit integers). At most you can reduce two of those pointers to another integer, and perhaps the integers to smaller integer types if you want to limit the bit size, but you're still aiming at at least 10 bytes per vector.

Not to mention that there are already plenty of already implemented dynamic bit field classes.

Why did You guys vote down?

Perhaps because you came out as arrogant with your uninformed comment? You argued, for example, that you couldn't use the vector because you had to store your bools tightly packed, but an std::vector<bool> is already tightly packed. You also came out as it was something very obvious, which it apparently wasn't.

You could very easily just have stated your reasons without making such a statement.

[iMalc]

Why do you need to use malloc instead of new[]?

Because I want to have possibility to resize my data without copying it.
How to make an array in place of malloc?

Then the problem is that you need to stop wanting to do that. Get out of this mindset that copying is slow - It isn't. Heck here's a good read on how they modified a matrix multiply routine to copy the matrix internally leading to a more than four times speedup.


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.

[Lauris Kaplinski]

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

[SiCrane]

Assuming two pointers and an integer, that adds up to 20 bytes (assuming a 64 bit system with 64 bit pointers and 32 bit integers).

To be fair, MSVC 2010 has a 20 byte std::vector<bool> even in 32 bit release builds. Its std::vector<bool> is implement in terms of std::vector<unsigned int>; it's the size of std::vector<unsigned int> plus its own data.

[Misery]

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.

Thanks for any help.

[Misery]

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.