dynamic memory allocation using malloc keyword in c++ [duplicate] - c++

I have a question wrt malloc/realloc memory that will contain an array of class/struct (i tried both struct and class the issue remains) members that include std vectors. I know I can circumvent the problem by using new and std array container class. However, I'd like to better understand why the following little code crashes when I use realloc instead of malloc (as I encountered this problem in the context of transitioning a larger code project from C to C++). It also seems that I cannot necessarily set an initial size of a vector in a class/struct (some compilers allow some don't ..)- so what is a vector in a class - a comfortable pointer?
Thanks,
Kai
#include <stdlib.h>
#include <limits.h>
#include <float.h>
#include <stdio.h>
#include <math.h>
#include <string.h>
#include <sys/types.h>
#include <vector>
/* mpic++ -O3 -ffast-math -pedantic vec-alloc.cpp -o vec-alloc */
using namespace std;
class float_vector{
public:
double x;
double y;
double z;
float_vector() : x(0), y(0), z(0) {};
};
class voxel{
public:
float_vector x;
vector<double> y;
voxel() : x() {};
};
int main(){
int i;
double d =1.111;
voxel v0, *Comp, *Comp2;
/* dynamically allocate memory */
Comp= (voxel*)malloc(10*sizeof(voxel));
for(i=0;i<10;++i) Comp[i] = v0;
printf("malloc done\n");
/* dynamically re-allocate memory */
Comp2= (voxel*)malloc(sizeof(voxel));
printf("realloc done\n");
for(i=0;i<10;++i){
Comp2 =(voxel*)realloc(&Comp2[0], (i+1)*sizeof(voxel));
Comp2[i] = v0;
}
printf("realloc done\n");
for(i=0;i<10;++i) Comp[i].y.push_back(d);
for(i=0;i<10;++i) printf("%lf\n",Comp[i].y[0]);
for(i=0;i<10;++i) Comp2[i].y.push_back(d); // this crashes
for(i=0;i<10;++i) printf("%lf\n",Comp2[i].y[0]);
return 1;
}

If you use malloc() with non-POD classes, you must call constructors (via placement new) and destructors manually.
Using an object which was not constructed properly results in undefined behavior, which often means a crash when it comes to pointers.
Obviously, freeing a memory for object without a proper destruction of it causes UB too.
Your code must look like this:
MyClass *arr = (MyClass *) malloc(10 * sizeof (MyClass));
for (int i = 0; i < 10; i++)
new (arr + i) MyClass; // This line calls constructors
// Do something with the array here
for (int i = 0; i < 10; i++)
arr[i].~MyClass(); // This line calls destructors.
free(arr);
This requirement also means that you can't use realloc() with non-POD types, because it wont call destructors for the old array and contructors for the new one for you.
Manual reallocation code might look like this:
MyClass *new_ptr = (MyClass *) malloc(new_size * sizeof (MyClass));
for (int i = 0; i < new_size; i++)
new (new_ptr + i) MyClass((MyClass &&) old_ptr[i]);
for (int i = new_size; i < old_size; i++)
new (new_ptr + i) MyClass;
for (int i = 0; i < old_size; i++)
old_ptr[i].~MyClass();
free(old_ptr);
And please keep in mind that above code is not really exception-safe. If a constructor throws an exception and you catch it, then you want to be sure that you properly destruct objects which were constructed. Thanks #SteveJessop.
Now when you understand why malloc()/free() usually should be avoided in C++, I hope you'll return to a lot more safe new/delete, which do all that construction and destruction for you.

It's probably nothing to do with the realloc. Your code already has undefined behaviour when you do this near the start:
for(i=0;i<10;++i) Comp[i] = v0;
Comp[0] has never been initialized (since malloc returns uninitialized memory -- it cannot know what type you intend to use it for and so could not possibly initialize it even if it wanted to). Then your code attempts to assign to it. This is not permitted for complex types like vector.
Why is it not permitted? In the case of vector, because when you assign to a vector that already holds data, it needs to free the old data. If there's nothing to free then it would free nothing. But uninitialized memory might have any values at all, so it may well appear to vector that there is something which should be freed, that in fact is not a freeable pointer at all, let alone something that vector should be freeing as a consequence of that assignment. Without initialization, some class invariant along the lines of "this pointer data member is always either a null pointer or else is the address of some memory that is the vector's responsibility" is violated and so the vector code does not work.
Supposing that your code somehow makes it past this point, you still can't realloc memory containing a vector. From the point of view of the standard, this is because vector<double> is not a POD type, and so byte-by-byte copies of it (including that done by realloc) result in undefined behavior.
From the point of view of a particular implementation, we might ask ourselves what code the implementer might write, which would go wrong in the case that vectors are copied byte-for-byte. One hypothetical answer is that in some circumstances the vector could contain a pointer into its own body (as part of a so-called small vector optimization) [Edit: actually, I think a small vector optimization isn't possible within the standard for other reasons, but my general point is that because vectors are not POD, the implementer is free to use their creativity]. If the vector is relocated then this pointer no longer points into the vector's own body and so the class invariants are not satisfied, and the code no longer works. To give implementers freedom to write code like this, your freedom as a user of the class is limited, and you are not permitted to relocate a vector (or in general any non-POD type) by byte-wise copying.

/* dynamically allocate memory */
Comp= (voxel*)malloc(10*sizeof(voxel));
Comp is now a pointer to uninitialized memory.
for(i=0;i<10;++i) Comp[i] = v0;
This attempts to call Comp[i].operator=(v0), but Comp[i] is not a valid, initialized object. In a simple test/debug case, we may get lucky but in practice we'll get garbage and the vector will either try to free/use an invalid pointer.
That doesn't just mean you have to calloc() the memory instead, you can't make assumptions about what values an initialized object expects to find.
/* dynamically re-allocate memory */
Comp2= (voxel*)malloc(sizeof(voxel));
printf("realloc done\n");
Comp2 is now a pointer to a single voxel, and no "realloc" was done.
for(i=0;i<10;++i){
Comp2 =(voxel*)realloc(&Comp2[0], (i+1)*sizeof(voxel));
Comp2[i] = v0;
}
This is just bizzare. It starts with Comp2 pointing to a single voxel. Then you for some reason take the address of the first element (&Comp2[0]) rather than just using the address of the first element (Comp2), and you reallocate it to the same size. You then copy-assign v0 into the uninitialized memory at the last-but-one position:
Comp2 = [...uninit...]
for (i = 0
realloc(i + 1 == 1)
Comp2 = [...uninit...]
^-- v0
i++
realloc(i+1 == 2)
Comp2 = [.....v0.....][...uninit...]
^--v0
Short: You can't use malloc or calloc or realloc with non-pod objects. You might get away with it occasionally, but you are basically pointing a loaded shotgun at your foot.
It also seems that I cannot necessarily set an initial size of a vector in a class/struct
You can easily set the default size of a vector in a class, C++11 required (-std=c++11 or greater for gnu/clang compilers, VS2013 or higher)
#include <iostream>
#include <vector>
struct A {
std::vector<int> v = { 1, 2, 3 }; // default population
};
struct B {
std::vector<int> v;
B() : v(4) {}
};
int main() {
A a;
B b;
std::cout << a.v.size() << ", " << b.v.size() << "\n";
std::cout << "\n";
for (int v : a.v) { std::cout << v << "\n"; }
std::cout << "\n";
for (int v : b.v) { std::cout << v << "\n"; }
}
http://ideone.com/KA9fWB

Related

"Moving" sequential containers to pointers

I'm building a buffer for network connections where you can explicitly allocate memory or you can supply it on your own via some sequential container(eg.:std::vector,std::array)these memory chunks are stored in a list what we use later for read/write operations. (the chunks are needed for handle multiple read/write requests)
I have a question about the last part, I want to make a pointer to the container's data and then tell the container to not care about it's data anymore.
So something like move semantics.
std::vector<int> v = {9,8,7,6,5,4,3,2,1,0};
std::vector<int> _v(std::move(v));
Where _v has all the values of v and v left in a safe state.
The problem is if I just make a pointer for v.data() after the lifetime of the container ends, the data pointed by the pointer releases with the container.
For example:
// I would use span to make sure It's a sequential container
// but for simplicity i use a raw pointer
// gsl::span<int> s;
int *p;
{
std::vector<int> v = {9,8,7,6,5,4,3,2,1,0};
// s = gsl::make_span(v);
p = v.data();
}
for(int i = 0; i < 10; ++i)
std::cout << p[i] << " ";
std::cout << std::endl;
Now p contains some memory trash and i would need the memory previously owned by the vector.
I also tried v.data() = nullptr but v.data() is rvalue so it's not possible to assign it. Do you have any suggestions, or is this possible?
edit.:
To make it more clear what i'm trying to achieve:
class readbuf_type
{
struct item_type // representation of a chunk
{
uint8_t * const data;
size_t size;
inline item_type(size_t psize)
: size(psize)
, data(new uint8_t[psize])
{}
template <std::ptrdiff_t tExtent = gsl::dynamic_extent>
inline item_type(gsl::span<uint8_t,tExtent> s)
: size(s.size())
, data(s.data())
{}
inline ~item_type()
{ delete[] data; }
};
std::list<item_type> queue; // contains the memory
public:
inline size_t read(uint8_t *buffer, size_t size); // read from queue
inline size_t write(const uint8_t *buffer, size_t size); // write to queue
inline void *get_chunk(size_t size)
{
queue.emplace_back(size);
return queue.back().data;
}
template <std::ptrdiff_t tExtent = gsl::dynamic_extent>
inline void put_chunk(gsl::span<uint8_t,tExtent> arr)
{
queue.emplace_back(arr);
}
} readbuf;
I have the get_chunkfunction what basically just allocates memory with the size, and I have put_chunk what I'm struggling with, the reason i need this because before you can write to this queue you need to allocate memory and then copy all the elements from the buffer(vector,array) you're trying to write from to the queue.
Something like:
std::vector<int> v = {9,8,7,6,5,4,3,2,1,0};
// instead of this
readbuf.get_chunk(v.size);
readbuf.write(v.data(), v.size());
// we want this
readbuf.put_chunk({v});
Since we're developing for distributed systems memory is crucial and that's why we want to avoid the unnecessary allocation, copying.
ps.This is my first post, so sorry if i wasn't precise in the first place..
No, it is not possible to "steal" the buffer of the standard vector in the manner that you suggest - or any other standard container for that matter.
You've already shown one solution: Move the buffer into another vector, instead of merely taking the address (or another non-owning reference) of the buffer. Moving from the vector transfers the ownership of the internal buffer.
It would be possible to implement such custom vector class, whose buffer could be stolen, but there is a reason why vector doesn't make it possible. It can be quite difficult to prove the correctness of your program if you release resources willy-nilly. Have you considered how to prevent the data from leaking? The solution above is much simpler and easier to verify for correctness.
Another approach is to re-structure your program in such way that no references to the data of your container outlive the container itself (or any invalidating operation).
Unfortunately the memory area of the vector cannot be detached from the std::vector object. The memory area can be deleted even if you insert some data to the std::vector object. Therefore use of this memory area later is not safe, unless you are sure that this particular std::vector object exists and is not modified.
The solution to this problem is to allocate a new memory area and copy the content of the vector to this newly allocated memory area. The newly allocated memory area can be safely accessed without worrying about the state of the std::vector object.
std::vector<int> v = {1, 2, 3, 4};
int* p = new int[v.size()];
memcpy(p, v.data(), sizeof(int) * v.size());
Don't forget to delete the memory area after you are finished using this memory area.
delete [] p;
Your mistake is in thinking that the pointer "contains" memory. It doesn't contain anything, trash or ints or otherwise. It is a pointer. It points to stuff. You have deleted that stuff and not transferred it anywhere else, so it can't work any more.
In general, you will need a container to put this information in, be it another vector, or even your own hand-made array. Just having a pointer to data does not mean you have data.
Furthermore, since it is impossible to ask a vector to relinquish its buffer to a non-vector thing, a vector is really your only chance in this particular case. It's not quite clear why that's not a good enough solution for you. :)
Not sure what you try to achieve but I would use moving semantic like this:
#include <iostream>
#include <memory>
#include <vector>
int main() {
std::unique_ptr<std::vector<int>> p;
{
std::vector<int> v = {9,8,7,6,5,4,3,2,1,0};
p = std::move(make_unique<std::vector<int>>(v));
}
for(int i = 0; i < 10; ++i)
std::cout << (*p)[i] << " ";
std::cout << std::endl;
return 0;
}

How to deallocate a portion of a continuous memory block?

let's assume I have a structure MyStruct and i want to allocate a "big" chunk of memory like this:
std::size_t memory_chunk_1_size = 10;
MyStruct * memory_chunk_1 = reinterpret_cast <MyStruct *> (new char[memory_chunk_1_size * sizeof(MyStruct)]);
and because of the "arbitrary reasons" I would like to "split" this chunk of memory into two smaller chunks without; moving data, resizing the "dynamic array", deallocating/allocating/reallocating memory, etc.
so I am doing this:
std::size_t memory_chunk_2_size = 5; // to remember how many elements there are in this chunk;
MyStruct * memory_chunk_2 = &memory_chunk_1[5]; // points to the 6th element of memory_chunk_1;
memory_chunk_1_size = 5; // to remember how many elements there are in this chunk;
memory_chunk_1 = memory_chunk_1; // nothing changes still points to the 1st element.
Unfortunately, when I try to deallocate the memory, I'm encountering an error:
// release memory from the 2nd chunk
for (int i = 0; i < memory_chunk_2_size ; i++)
{
memory_chunk_2[i].~MyStruct();
}
delete[] reinterpret_cast <char *> (memory_chunk_2); // deallocates memory from both "memory_chunk_2" and "memory_chunk_1"
// release memory from the 1st chunk
for (int i = 0; i < memory_chunk_1_size ; i++)
{
memory_chunk_1[i].~MyStruct(); // Throws exception.
}
delete[] reinterpret_cast <char *> (memory_chunk_1); // Throws exception. This part of the memory was already dealocated.
How can I delete only a selected number of elements (to solve this error)?
Compilable example:
#include <iostream>
using namespace std;
struct MyStruct
{
int first;
int * second;
void print()
{
cout << "- first: " << first << endl;
cout << "- second: " << *second << endl;
cout << endl;
}
MyStruct() :
first(-1), second(new int(-1))
{
cout << "constructor #1" << endl;
print();
}
MyStruct(int ini_first, int ini_second) :
first(ini_first), second(new int(ini_second))
{
cout << "constructor #2" << endl;
print();
}
~MyStruct()
{
cout << "destructor" << endl;
print();
delete second;
}
};
int main()
{
// memory chunk #1:
std::size_t memory_chunk_1_size = 10;
MyStruct * memory_chunk_1 = reinterpret_cast <MyStruct *> (new char[memory_chunk_1_size * sizeof(MyStruct)]);
// initialize:
for (int i = 0; i < memory_chunk_1_size; i++)
{
new (&memory_chunk_1[i]) MyStruct(i,i);
}
// ...
// Somewhere here I decided I want to have two smaller chunks of memory instead of one big,
// but i don't want to move data nor reallocate the memory:
std::size_t memory_chunk_2_size = 5; // to remember how many elements there are in this chunk;
MyStruct * memory_chunk_2 = &memory_chunk_1[5]; // points to the 6th element of memory_chunk_1;
memory_chunk_1_size = 5; // to remember how many elements there are in this chunk;
memory_chunk_1 = memory_chunk_1; // nothing changes still points to the 1st element.
// ...
// some time later i want to free memory:
// release memory from the 2nd chunk
for (int i = 0; i < memory_chunk_2_size ; i++)
{
memory_chunk_2[i].~MyStruct();
}
delete[] reinterpret_cast <char *> (memory_chunk_2); // deallocates memory from both "memory_chunk_2" and "memory_chunk_1"
// release memory from the 1st chunk
for (int i = 0; i < memory_chunk_1_size ; i++)
{
memory_chunk_1[i].~MyStruct(); // Throws exception.
}
delete[] reinterpret_cast <char *> (memory_chunk_1); // Throws exception. This part of the memory was already dealocated.
// exit:
return 0;
}
This kind of selective deallocation is not supported by the C++ programming language, and is probably never going to be supported.
If you intend to deallocate individual portions of memory, those individual portions need to be individually allocated in the first place.
It is possible that a specific OS or platform might support this kind of behavior, but it would be with OS-specific system calls, not through C++ standard language syntax.
Memory allocated with malloc or new cannot be partially deallocate. Many heaps use bins of different sized allocations for performance and to prevent fragmentation so allowing partial frees would make such a strategy impossible.
That of course does not prevent you writing your own allocator.
The simplest way I could think of by means of standard c++ would follow this idiomatic code:
std::vector<int> v1(1000);
auto block_start = v1.begin() + 400;
auto block_end = v1.begin() + 500;
std::vector<int> v2(block_start,block_end);
v1.erase(block_start,block_end);
v1.shrink_to_fit();
If a compiler is intelligent enough to translate such pattern to the most efficient low level OS and CPU memory management operations, is an implementation detail.
Here's the working example.
Let's be honest: this is a very bad practice ! Trying to cast new and delete and in addition call yourself destructor between the two is an evidence of low-level manual memory management.
Alternatives
The proper way to manage dynamic memory structures in contiguous blocks in C++ is to use std::vector instead of manual arrays or manual memory management, and let the library proceed. You can resize() a vector to delete the unneeded elements. You can shrink_to_fit() to say that you no longer need the extra free capacity, although it's not guaranteed that unneeded memory is released.
The use of C memory allocation functions and in particular realloc() is to be avoided, as it is very error prone, and it works only with trivially copiable objects.
Edit: Your own container
If you want to implement your own special container and must allows this kind of dynamic behaviour, due to unusual special constraints, then you should consider writing your own memory management function that would manage a kind of "private heap".
Heap management is often implement via a linked list of free chunks.
One strategy could be to allocate a new chunk when there's no sufficient contiguous memory left in your private heap. You could then offer a more permissive myfree() function that reinserts a freed or partially freed chunk into that linked list. Of course, this requires to iterate through the linked list to find if the released memory is contiguous to any other chunk of free memory in the private heap, and merge the blocks if adjacent.
I see that MyStruct is very small. Another approach could then be to write a special allocation function optimised for small fixed size blocks. There is an example in Loki's small object library that is described in depth in "Modern C++ Design".
Finally, you could perhaps have a look at the Pool library of Boost, which also offers a chunk based approach.

How to write a destructor for a class which includes a map<int,*double> member?

I have a class like:
class CPR_data{
public:
/*some functions*/
private:
map<int,double*> data; //saving data
};
In the file main.cpp, I add data into the class as following:
double *data_ = new double[n_var];
auto insert_flag = data.insert(make_pair(n,data_));
I used the default destructor but it seems a Memory Leak. Do I need to delete all the arrays manually in the destructor?
You loop through your map and call delete[] on every element.
~CPR_data()
{
for(auto& elem : data)
{
delete[] elem.second;
}
}
Note that you now also have to write your own copy constructor and copy assignment operator.
However, the real solution is to use std::map<int, std::vector<double>> instead so you won't have to do any bookkeeping and any questioning about who owns what pointer etc. There's a good chance it'll be as fast as your dynamic allocation method.
You really shouldn't be using any dynamic allocation in C++11 since everything nowadays has a better alternative unless you're writing a standard library implementation or some other exotic piece of code.
#include <iostream>
#include <map>
#include <vector>
using namespace std;
int main()
{
map<int, vector<double>> data;
vector<double> data_ = { 1.0, 2.0, 3.0, 4.0, 5.0 };
auto insert_flag = data.insert(make_pair(1, data_));
vector<double> data_2 = { 1.1, 2.2, 3.3, 4.4 };
insert_flag = data.insert(make_pair(2, data_2));
for(const auto& val : data[2])
cout << val << '\n';
return 0;
}
You don't need to implement your own destructor just for that case. The only thing you have to ensure is to make the double* get deleted when your object is destroyed.
Implementing a destructor that will run through all items is one option, but you can also (as others said) switch to using some other element type. vector is one option, but surely that's not an array.
If you need to stick with raw dynamic arrays, you can always wrap the raw pointer into a smart pointer that will keep track of it and will delete it appropriately.
#include <iostream>
#include <map>
#include <boost/scoped_array.hpp>
int main()
{
std::map<int,boost::scoped_array<double>> data;
int n = 250;
double* data_ = new double[n]; // POTENTIAL LEAK
data_[249] = -1; // POTENTIAL LEAK
/* ... */ // POTENTIAL LEAK
auto insert_flag = data.insert(std::make_pair(n,data_));
std::cout << insert_flag.first->first << " " << insert_flag.second << std::endl;
std::cout << data[250][249] << std::endl;
}
Please be careful with smart pointer type - here I'm using scoped_array as opposed to typical scoped_ptr which is appropriate only for pointers to single object. For dynamic arrays, scoped_array is needed.
Nevertheless, as you can see above, using smart pointer is very similar to using raw pointer. Smart pointers were designed to be as much similar in use as possible. They come with their own destructors, so when the (default) destructor of your object kicks in, it destroys the map, which in turn destroys its elements - and now the elements are smart-pointer - so they will deallocate the arrays.
Actually, I still would encourage you to use vector or whatever else than raw pointers. With raw dynamic allocations you have to be extra careful because even in my example above, there is a tiny possibility of a memory leak - if anything interrupts the code (i.e. exception) between new'ing the raw pointer and packing the pointer into scoped one - nothing will deallocate the raw dynamic array. For that reason, it's best to wrap them as soon as possible and ensure, as hard as it can be, that nothing can interrupt the flow before the raw pointer starts being managed by smart pointer object.
And, as last line - be sure to check out the difference between scoped and shared smart pointers. I used scoped here, because it seems fit. However, it's worth knowing about both types.

Using malloc/realloc for array of classes/structs including std vector

I have a question wrt malloc/realloc memory that will contain an array of class/struct (i tried both struct and class the issue remains) members that include std vectors. I know I can circumvent the problem by using new and std array container class. However, I'd like to better understand why the following little code crashes when I use realloc instead of malloc (as I encountered this problem in the context of transitioning a larger code project from C to C++). It also seems that I cannot necessarily set an initial size of a vector in a class/struct (some compilers allow some don't ..)- so what is a vector in a class - a comfortable pointer?
Thanks,
Kai
#include <stdlib.h>
#include <limits.h>
#include <float.h>
#include <stdio.h>
#include <math.h>
#include <string.h>
#include <sys/types.h>
#include <vector>
/* mpic++ -O3 -ffast-math -pedantic vec-alloc.cpp -o vec-alloc */
using namespace std;
class float_vector{
public:
double x;
double y;
double z;
float_vector() : x(0), y(0), z(0) {};
};
class voxel{
public:
float_vector x;
vector<double> y;
voxel() : x() {};
};
int main(){
int i;
double d =1.111;
voxel v0, *Comp, *Comp2;
/* dynamically allocate memory */
Comp= (voxel*)malloc(10*sizeof(voxel));
for(i=0;i<10;++i) Comp[i] = v0;
printf("malloc done\n");
/* dynamically re-allocate memory */
Comp2= (voxel*)malloc(sizeof(voxel));
printf("realloc done\n");
for(i=0;i<10;++i){
Comp2 =(voxel*)realloc(&Comp2[0], (i+1)*sizeof(voxel));
Comp2[i] = v0;
}
printf("realloc done\n");
for(i=0;i<10;++i) Comp[i].y.push_back(d);
for(i=0;i<10;++i) printf("%lf\n",Comp[i].y[0]);
for(i=0;i<10;++i) Comp2[i].y.push_back(d); // this crashes
for(i=0;i<10;++i) printf("%lf\n",Comp2[i].y[0]);
return 1;
}
If you use malloc() with non-POD classes, you must call constructors (via placement new) and destructors manually.
Using an object which was not constructed properly results in undefined behavior, which often means a crash when it comes to pointers.
Obviously, freeing a memory for object without a proper destruction of it causes UB too.
Your code must look like this:
MyClass *arr = (MyClass *) malloc(10 * sizeof (MyClass));
for (int i = 0; i < 10; i++)
new (arr + i) MyClass; // This line calls constructors
// Do something with the array here
for (int i = 0; i < 10; i++)
arr[i].~MyClass(); // This line calls destructors.
free(arr);
This requirement also means that you can't use realloc() with non-POD types, because it wont call destructors for the old array and contructors for the new one for you.
Manual reallocation code might look like this:
MyClass *new_ptr = (MyClass *) malloc(new_size * sizeof (MyClass));
for (int i = 0; i < new_size; i++)
new (new_ptr + i) MyClass((MyClass &&) old_ptr[i]);
for (int i = new_size; i < old_size; i++)
new (new_ptr + i) MyClass;
for (int i = 0; i < old_size; i++)
old_ptr[i].~MyClass();
free(old_ptr);
And please keep in mind that above code is not really exception-safe. If a constructor throws an exception and you catch it, then you want to be sure that you properly destruct objects which were constructed. Thanks #SteveJessop.
Now when you understand why malloc()/free() usually should be avoided in C++, I hope you'll return to a lot more safe new/delete, which do all that construction and destruction for you.
It's probably nothing to do with the realloc. Your code already has undefined behaviour when you do this near the start:
for(i=0;i<10;++i) Comp[i] = v0;
Comp[0] has never been initialized (since malloc returns uninitialized memory -- it cannot know what type you intend to use it for and so could not possibly initialize it even if it wanted to). Then your code attempts to assign to it. This is not permitted for complex types like vector.
Why is it not permitted? In the case of vector, because when you assign to a vector that already holds data, it needs to free the old data. If there's nothing to free then it would free nothing. But uninitialized memory might have any values at all, so it may well appear to vector that there is something which should be freed, that in fact is not a freeable pointer at all, let alone something that vector should be freeing as a consequence of that assignment. Without initialization, some class invariant along the lines of "this pointer data member is always either a null pointer or else is the address of some memory that is the vector's responsibility" is violated and so the vector code does not work.
Supposing that your code somehow makes it past this point, you still can't realloc memory containing a vector. From the point of view of the standard, this is because vector<double> is not a POD type, and so byte-by-byte copies of it (including that done by realloc) result in undefined behavior.
From the point of view of a particular implementation, we might ask ourselves what code the implementer might write, which would go wrong in the case that vectors are copied byte-for-byte. One hypothetical answer is that in some circumstances the vector could contain a pointer into its own body (as part of a so-called small vector optimization) [Edit: actually, I think a small vector optimization isn't possible within the standard for other reasons, but my general point is that because vectors are not POD, the implementer is free to use their creativity]. If the vector is relocated then this pointer no longer points into the vector's own body and so the class invariants are not satisfied, and the code no longer works. To give implementers freedom to write code like this, your freedom as a user of the class is limited, and you are not permitted to relocate a vector (or in general any non-POD type) by byte-wise copying.
/* dynamically allocate memory */
Comp= (voxel*)malloc(10*sizeof(voxel));
Comp is now a pointer to uninitialized memory.
for(i=0;i<10;++i) Comp[i] = v0;
This attempts to call Comp[i].operator=(v0), but Comp[i] is not a valid, initialized object. In a simple test/debug case, we may get lucky but in practice we'll get garbage and the vector will either try to free/use an invalid pointer.
That doesn't just mean you have to calloc() the memory instead, you can't make assumptions about what values an initialized object expects to find.
/* dynamically re-allocate memory */
Comp2= (voxel*)malloc(sizeof(voxel));
printf("realloc done\n");
Comp2 is now a pointer to a single voxel, and no "realloc" was done.
for(i=0;i<10;++i){
Comp2 =(voxel*)realloc(&Comp2[0], (i+1)*sizeof(voxel));
Comp2[i] = v0;
}
This is just bizzare. It starts with Comp2 pointing to a single voxel. Then you for some reason take the address of the first element (&Comp2[0]) rather than just using the address of the first element (Comp2), and you reallocate it to the same size. You then copy-assign v0 into the uninitialized memory at the last-but-one position:
Comp2 = [...uninit...]
for (i = 0
realloc(i + 1 == 1)
Comp2 = [...uninit...]
^-- v0
i++
realloc(i+1 == 2)
Comp2 = [.....v0.....][...uninit...]
^--v0
Short: You can't use malloc or calloc or realloc with non-pod objects. You might get away with it occasionally, but you are basically pointing a loaded shotgun at your foot.
It also seems that I cannot necessarily set an initial size of a vector in a class/struct
You can easily set the default size of a vector in a class, C++11 required (-std=c++11 or greater for gnu/clang compilers, VS2013 or higher)
#include <iostream>
#include <vector>
struct A {
std::vector<int> v = { 1, 2, 3 }; // default population
};
struct B {
std::vector<int> v;
B() : v(4) {}
};
int main() {
A a;
B b;
std::cout << a.v.size() << ", " << b.v.size() << "\n";
std::cout << "\n";
for (int v : a.v) { std::cout << v << "\n"; }
std::cout << "\n";
for (int v : b.v) { std::cout << v << "\n"; }
}
http://ideone.com/KA9fWB

How does an allocator create and destroy an array?

How does an allocator create and destroy and array, for example
int* someInt = someAllocator(3);
Where without the allocator it would just be
int* someInt = new int[3];
Where the allocator is responsible for create each element and ensuring the constructor will be called.
How is the internals for an allocator written without the use of new? Could someone provide and example of the function?
I do not want to just use std::vector as I am trying to learn how an allocator will create an array.
The problem of general memory allocation is a surprisingly tricky one. Some consider it solved and some unsolvable ;) If you are interested in internals, start by taking a look at Doug Lea's malloc.
The specialized memory allocators are typically much simpler - they trade the generality (e.g. by making the size fixed) for simplicity and performance. Be careful though, using general memory allocation is usually better than a hodge-podge of special allocators in realistic programs.
Once a block of memory is allocated through the "magic" of the memory allocator, it can be initialized at container's pleasure using placement new.
--- EDIT ---
The placement new is not useful for "normal" programming - you'd only need it when implementing your own container to separate memory allocation from object construction. That being said, here is a slightly contrived example for using placement new:
#include <new> // For placement new.
#include <cassert>
#include <iostream>
class A {
public:
A(int x) : X(x) {
std::cout << "A" << std::endl;
}
~A() {
std::cout << "~A" << std::endl;
}
int X;
};
int main() {
// Allocate a "dummy" block of memory large enough for A.
// Here, we simply use stack, but this could be returned from some allocator.
char memory_block[sizeof(A)];
// Construct A in that memory using placement new.
A* a = new(memory_block) A(33);
// Yup, it really is constructed!
assert(a->X == 33);
// Destroy the object, wihout freeing the underlying memory
// (which would be disaster in this case, since it is on stack).
a->~A();
return 0;
}
This prints:
A
~A
--- EDIT 2 ---
OK, here is how you do it for the array:
int main() {
// Number of objects in the array.
const size_t count = 3;
// Block of memory big enough to fit 'count' objects.
char memory_block[sizeof(A) * count];
// To make pointer arithmetic slightly easier.
A* arr = reinterpret_cast<A*>(memory_block);
// Construct all 3 elements, each with different parameter.
// We could have just as easily skipped some elements (e.g. if we
// allocated more memory than is needed to fit the actual objects).
for (int i = 0; i < count; ++i)
new(arr + i) A(i * 10);
// Yup, all of them are constructed!
for (int i = 0; i < count; ++i) {
assert(arr[i].X == i * 10);
}
// Destroy them all, without freeing the memory.
for (int i = 0; i < count; ++i)
arr[i].~A();
return 0;
}
BTW, if A had a default constructor, you could try call it on all elements like this...
new(arr) A[count];
...but this would open a can of worms you really wouldn't want to deal with.
I've written about it in my second example here:
How to create an array while potentially using placement new
The difference is that the t_allocator::t_array_record would be managed by the allocator rather than the client.