I have a problem about pointer and standard library use.
Let's create a new class
class Graph
{
std::vector<Edge> *edge_list;
//another way is
//std::vector<Edge> edge_list;
}
I already thought two reasons why I use pointer:
It's easy to manipulate the memory using new and delete
It can be passed by parameters easily.
However, we can pass by reference if we use vector.Then Reason 2 doesn't count.
So, Is it true if I am not strict with memory allocation, I don't need to use pointer to vector and other std container?
The implementation of std::vector contains 2 pointers:
The beginning of the allocated array
1 element after the end of the allocated array
Essentially, when you declare a vector it has no space allocated in the heap, but as you add elements this changes.
Note that std::vector manages the memory it uses, so there is no need for you to worry about new and delete (unnecessary complexity). As soon as it goes out of scope, it deallocates its memory (stack and heap).
As you said, a vector can be passed very easily by reference, which works the same way as a pointer for machine code, and it's more clear.
Related
In C++ the delete[] is supposed to be used with arrays created by new. You can pass arrays into functions like this: void method_with_array(int* array). How can you tell if an array created this way was created with new, so you can delete it properly.
You can't, so better not pass around pointers to things created with new or new[]. Use for example std::vector or if you really really really need a dynamically allocated array, std::unique_ptr<T[]>.
Usually a good rule is that whoever takes care of the allocation of an object should take care of releasing the object.
That said, if you are allocating and deleting the memory for an object in the same object/container/manager, you know what you are dealing with. In case the same pointer is used for one or multiple elements, you have different options:
keep a variable that tells you which kind of int* member you have allocated
allocate all the times an array, eventually of size 1
use an std::vector even for storing a single element, as above.
I have a series of questions to ask.
What is the correct way to destroy a vector of pointers?
I know the vector class has the default destroyer but I do not know if the pointers change something.
An array containing object pointers in its destruction requires the simple command: Delete [] pointname?
Or do I have to do some other operation first on pointers?
A list or vector of object pointers to be emptied requires a simple command: list_name / vector_name.clear (); Or do some other operations on the pointers first?
1) What is the correct way to destroy a vector of pointers? I know the vector class has the default destroyer but I do not know if the pointers change something.
If you have manually allocated the pointers in the vector and you want to delete (deallocate and destroy) them when the vector is destroyed, you should automate it with std::unique_ptrs
{
std::vector<std::unique_ptr<int>> vec;
vec.push_back(std::make_unique<int>(1));
vec.push_back(std::make_unique<int>(2));
}
when the vector is destroyed, the integers will be destroyed as well. If you are curious as to how this works and are not familiar with code like this, read up on RAII
2) An array containing object pointers in its destruction requires the simple command: Delete [] pointname? Or do I have to do some other operation first on pointers?
If you have allocated that array with new[] then you can call delete[] on that array. Keep in mind that this will not call delete on the integers individually, it will just deallocate the memory allocated for the array. If you want to deallocate the integers as well use unique_ptr as in the above example
3) A list or vector of object pointers to be emptied requires a simple command: list_name / vector_name.clear (); Or do some other operations on the pointers first?
This will clear the container but not free the pointers. See the above two points.
In answer to your second question, using delete[] and then the name of your array of pointers is satisfactory with no additional steps. delete[] just takes the array of pointers and causes the kernel to 'realise' the memory locations they point to so other operations can 'use' (write-over the data previously in) those locations. This is all you need to do. Now other operations can request memory and the kernel is free to 'give away' those locations.
Before I start, I have already looked at these questions:
Memory consumption of a pointer to vector of pointers
Pointer to vector vs vector of pointers vs pointer to vector of pointers
And they both do not answer my question.
I am working on a project where it involves millions of instances to work with.
The data structure I am using is a bit complicated to look at for the first time, the structure itself isn't really of any importance for this question.
Now, if I had the following:
vector<object*> *myVector;
Everything goes to the heap.
However, what happens if I used this:
vector<object*> myVector;
Does the vector itself get stored on the stack? And its contents are then stored on the heap? For example, if the vector had 10 million instances, would I have 10 million references on the stack for 10 million objects on the heap? Or am I missing something?
Moreover, if I used this:
vector<object> *myVector;
Where do the contents of the vector go? Does everything go on the heap? If yes, then does it work recursively? For example:
vector<vector<vector<int>>> *myVector;
Are all the inner vectors then stored on the heap? If yes, then it should be enough deleting myVector in the destructor, without worrying on anything else?
Anyway, I am assuming all the answers that apply to vector would also apply to unordered_map. Please tell me if I am wrong.
Thanks in advance.
In general, elements of a std::vector will always be dynamically allocated on the heap. For most implementations, a std::vector<T> foo, where T could be a pointer or not, there will always be three pointers on the stack that describe the vector itself, but not the elements. For a std::vector<T> *bar, there is one pointer, bar, on stack. The three vector pointers as well as the vector elements are on the heap.
Similarly, for an std::unordered_map, the elements itself will always be dynamically allocated on the heap. Generally, any std type that has a Allocator template parameter, or any type that contains a variable amount of data, will have it's data dynamically allocated on the heap.
Now there are special cases, like custom allocators, weird optimizations, specifics of terminology, but for practical purposes, this is what you should know.
The next thing that you might want to learn about, are smart pointers, e.g. std::unique_ptr, and std::shared_ptr, ownership semantics and RAII. That is actually more important to know in order to write correct code (What do I need to delete and worry about?).
I've looked around trying to figure out if I should return a 2D array in C++, but got mixed answers.
Some of the answers say no because the data is local to the function and when it returns, the array points to "junk data" (as it can be overwritten at any time). However, some said "yes, return it like a normal array."
So, to my dilemma:
I have a 2D array that holds pointers to Tile objects
Tile* map[128][128];
Should I return the array in a function? Why or why not? If the answer is yes, how would I do that?
EDIT: I was unclear. I want to make a getter method to return the map variable and be able to use the pointers in the array in another function.
You could do that... the problem is that your caller is now responsible for freeing the memory. And he might not know how you allocated it. Should he call free()? delete[]? A free routine provided by the OS? Or one provided by some other memory caching system in your app?
Two common ways around this are:
Have the caller allocate the memory and your function merely populates it
Use a C++ array class; here you might have a std::vector containing a std::vector of Tile*. This is great as it absolves you of manually dealing with the memory allocation/deallocation.
But then... who's going to free the Tile* instances? And with what API? So perhaps you need a vector of vectors of Tile, rather than Tile*.
vector<vector<Tile>> map;
The 2 answers you are getting is due to the two different ways this is possible.
Stack based - local memory, deallocated and the pointer returned is invalid
typedef int *(*TileGrid)[128];
Tile* map[128][128];
....
TileGrid GetTiles(){
return map;
}
Heap Allocated - allocated on heap and not deallocated after the function ends, up to caller of this function to deallocate - safe.
typedef int *(*TileGrid)[128];
TileGrid map = new Tile*[128][128];
....
TileGrid GetTiles(){
return map;
}
Recommended - C++ way - array instead of vector since size is compile time constant (true C++ way would be to use std::unique_ptr<Tile> instead of Tile*, but 1 issue at a time. These containers automatically manage the memory for you, and std::array can be used as if it is a regular array.
typedef std::array<std::array<Tile*,128>,128> TileGrid;
TileGrid map ;
...
TileGrid& GetTiles(){
return map;
}
Return by reference to prevent an expensive copy, and because the function is just a getter and the object maintains ownership of the map.
Edit: fixed for a getter function
C/C++ has two types of memory - stack and heap. Usually variables are allocated on the stack which is temporary storage and is marked for re-use whenever you exit the current scope - like when you end a loop or return from a function.
When you use new it will allocate heap memory which will stay around until you use delete but you have to be careful that you match up all the new and delete calls so that you don't get a memory leak. There are many strategies for managing this situation in C++. You can google for 'memory management in C++' to learn more.
In your simple case, I would recommend avoiding pointers but using an stl container to build your array of tiles. For example a std::vector like vector< vector<Tile> > map. You can use the same square brackets syntax to access the map e.g. map[x][y] = Tile(); That way the memory allocation and management of the array is handled in the vector class.
I am writing an application using openFrameworks, but my question is not specific to just oF; rather, it is a general question about C++ vectors in general.
I wanted to create a class that contains multiple instances of another class, but also provides an intuitive interface for interacting with those objects. Internally, my class used a vector of the class, but when I tried to manipulate an object using vector.at(), the program would compile but not work properly (in my case, it would not display a video).
// instantiate object dynamically, do something, then append to vector
vector<ofVideoPlayer> videos;
ofVideoPlayer *video = new ofVideoPlayer;
video->loadMovie(filename);
videos.push_back(*video);
// access object in vector and do something; compiles but does not work properly
// without going into specific openFrameworks details, the problem was that the video would
// not draw to screen
videos.at(0)->draw();
Somewhere, it was suggested that I make a vector of pointers to objects of that class instead of a vector of those objects themselves. I implemented this and indeed it worked like a charm.
vector<ofVideoPlayer*> videos;
ofVideoPlayer * video = new ofVideoPlayer;
video->loadMovie(filename);
videos.push_back(video);
// now dereference pointer to object and call draw
videos.at(0)->draw();
I was allocating memory for the objects dynamically, i.e. ofVideoPlayer = new ofVideoPlayer;
My question is simple: why did using a vector of pointers work, and when would you create a vector of objects versus a vector of pointers to those objects?
What you have to know about vectors in c++ is that they have to use the copy operator of the class of your objects to be able to enter them into the vector. If you had memory allocation in these objects that was automatically deallocated when the destructor was called, that could explain your problems: your object was copied into the vector then destroyed.
If you have, in your object class, a pointer that points towards a buffer allocated, a copy of this object will point towards the same buffer (if you use the default copy operator). If the destructor deallocates the buffer, when the copy destructor will be called, the original buffer will be deallocated, therefore your data won't be available anymore.
This problem doesn't happen if you use pointers, because you control the life of your elements via new/destroy, and the vector functions only copy pointer towards your elements.
My question is simple: why did using a
vector of pointers work, and when
would you create a vector of objects
versus a vector of pointers to those
objects?
std::vector is like a raw array allocated with new and reallocated when you try to push in more elements than its current size.
So, if it contains A pointers, it's like if you were manipulating an array of A*.
When it needs to resize (you push_back() an element while it's already filled to its current capacity), it will create another A* array and copy in the array of A* from the previous vector.
If it contains A objects, then it's like you were manipulating an array of A, so A should be default-constructible if there are automatic reallocations occuring. In this case, the whole A objects get copied too in another array.
See the difference? The A objects in std::vector<A> can change address if you do some manipulations that requires the resizing of the internal array. That's where most problems with containing objects in std::vector comes from.
A way to use std::vector without having such problems is to allocate a large enough array from the start. The keyword here is "capacity". The std::vector capacity is the real size of the memory buffer in which it will put the objects. So, to setup the capacity, you have two choices:
1) size your std::vector on construction to build all the object from the start , with maximum number of objects - that will call constructors of each objects.
2) once the std::vector is constructed (but has nothing in it), use its reserve() function : the vector will then allocate a large enough buffer (you provide the maximum size of the vector). The vector will set the capacity. If you push_back() objects in this vector or resize() under the limit of the size you've provided in the reserve() call, it will never reallocate the internal buffer and your objects will not change location in memory, making pointers to those objects always valid (some assertions to check that change of capacity never occurs is an excellent practice).
If you are allocating memory for the objects using new, you are allocating it on the heap. In this case, you should use pointers. However, in C++, the convention is generally to create all objects on the stack and pass copies of those objects around instead of passing pointers to objects on the heap.
Why is this better? It is because C++ does not have garbage collection, so memory for objects on the heap will not be reclaimed unless you specifically delete the object. However, objects on the stack are always destroyed when they leave scope. If you create objects on the stack instead of the heap, you minimize your risk of memory leaks.
If you do use the stack instead of the heap, you will need to write good copy constructors and destructors. Badly written copy constructors or destructors can lead to either memory leaks or double frees.
If your objects are too large to be efficiently copied, then it is acceptable to use pointers. However, you should use reference-counting smart pointers (either the C++0x auto_ptr or one the Boost library pointers) to avoid memory leaks.
vector addition and internal housekeeping use copies of the original object - if taking a copy is very expensive or impossible, then using a pointer is preferable.
If you make the vector member a pointer, use a smart pointer to simplify your code and minimize the risk of leaks.
Maybe your class does not do proper (ie. deep) copy construction/assignment? If so, pointers would work but not object instances as the vector member.
Usually I don't store classes directly in std::vector. The reason is simple: you would not know if the class is derived or not.
E.g.:
In headers:
class base
{
public:
virtual base * clone() { new base(*this); };
virtual ~base(){};
};
class derived : public base
{
public:
virtual base * clone() { new derived(*this); };
};
void some_code(void);
void work_on_some_class( base &_arg );
In source:
void some_code(void)
{
...
derived instance;
work_on_some_class(derived instance);
...
}
void work_on_some_class( base &_arg )
{
vector<base> store;
...
store.push_back(*_arg.clone());
// Issue!
// get derived * from clone -> the size of the object would greater than size of base
}
So I prefer to use shared_ptr:
void work_on_some_class( base &_arg )
{
vector<shared_ptr<base> > store;
...
store.push_back(_arg.clone());
// no issue :)
}
The main idea of using vector is to store objects in a continue space, when using pointer or smart pointer that won't happen
Here also need to keep in mind the performance of memory usage by CPU.
std::vector vector guarantees(not sure) that the mem block is
continuous.
std::vectorstd::unique_ptr<Object> will keep smart-pointers in continuous memory, but real memory blocks for objects can be placed in different positions in RAM.
So I can guess that std::vector will be faster for cases when the size of the vector is reserved and known. However, std::vectorstd::unique_ptr<Object> will be faster if we don't know the planned size or we have plans to change the order of objects.