Quote:Original post by indigox3
In other words v is a vector of pointers, not objects
Well, pointers don't have destructors, so nothing happens to what they point to when the vector and its elements get destroyed.
STL vectors and operator delete
Well, pointers don't have destructors, so nothing happens to what they point to when the vector and its elements get destroyed.
Quote:Original post by Anonymous Poster
Wow - what a lot to say very little, still it probably felt intelligent at the time.
More simply, vectors allocate and deallocate memory as required.
If adding objects to a vector like in your example, the vector will allocate memory (on the heap using new) and make copies of your objects. Unless you're using a very old implementation of STL that contains such a bug, it's not a bug in STL. Certainly not one i've encountered anyway.
[headshake][rolleyes] what babbling off-topic rubbish are you on about? not that it is any of your business but i was trying to explain something to indigox3 in reference to this:
Quote:Original post by indigox3
Along those lines, ~vector() calls _Tidy() calls allocator::deallocate() calls delete with the pointer to the first element of the vector as an argument.
As to what was going on. The default allocator's (std::allocator) deallocate method doesn't implicitly invoke delete like people normally do because that would also destroy aswell as deallocate elements, the allocator concept separates allocation/deallocation & construction/destruction for efficiency reasons.
Author
Quote:Original post by FrunyQuote:Original post by indigox3
In other words v is a vector of pointers, not objects
Well, pointers don't have destructors, so nothing happens to what they point to when the vector and its elements get destroyed.
I'm totally confused by this. operator delete takes only pointers as arguments.
I know the destructor is being called because I am setting breakpoints up in my debugger and I am breaking in the destructor, although maybe I am not understanding you.
I even brought the code downto
class A : public B{public:A(){}~A(){}std::vector<int> mInt;};main(){A* a = new A();a->mInt.push_back(12);delete a;}and I *still* crash.... I'm totally stumped..
Oddly, if I comment out a->mInt.push_back(12) I dont get a crash
Author
B derives C, C derives D, D derives E, E derives F, F derives...ugh
I will take a closer look on monday...
thanks for the help ppl!
I will take a closer look on monday...
thanks for the help ppl!
Quote:Original post by indigox3Quote:Original post by FrunyQuote:Original post by indigox3
In other words v is a vector of pointers, not objects
Well, pointers don't have destructors, so nothing happens to what they point to when the vector and its elements get destroyed.
I'm totally confused by this. operator delete takes only pointers as arguments.
Right, but when you call delete on a pointer it deletes (and potentially calls the destructor of) the pointed to object, not the pointer. You can try to delete an actual pointer if you call delete on the address of the pointer, but the destructor of the pointer is a no-op. Ex:
#include <iostream>class Boring { public: Boring() { std::cout << "Construct me!" << std::endl; } Boring(const Boring &) { std::cout << "Construct me!" << std::endl; } ~Boring() { std::cout << "Destroy me!" << std::endl; }};int main(int, char **) { Boring ** pointer_to_pointer = new Boring *; // creates a new Boring pointer *pointer_to_pointer = new Boring; // creates a new Boring delete pointer_to_pointer; // deletes the pointer, does nothing to the Boring // and causes a mem leak return 0;}As you can see, deleting the pointer does nothing to delete the object pointed to by the pointer.
Author
Quote:Original post by SiCrane
As you can see, deleting the pointer does nothing to delete the object pointed to by the pointer.
Ah, ok I see what you mean now. I made sure I am using:
delete pointer;and not
delete pointer_to_pointer;
Author
Anyone know if there can be problems using the stl vector from a library?
The code I have is all defined in a library which is compiled to a DLL. I wrote a new class that does not inhierit from anything inside the DLL, but is still defined within the DLL.
Then, I am linking to the lib from a visual studio.net 2003 project, and doing:
Is it possible that the vector is allocating memory differently when push_back is called from the application, as opposed to the DLL?
or are there some other gotchas with using DLLs that I am unaware of?
The code I have is all defined in a library which is compiled to a DLL. I wrote a new class that does not inhierit from anything inside the DLL, but is still defined within the DLL.
class __declspec( dllexport ) A // forgot the "__declspec(dllexport)" last time!{public:A();~A();std::vector<int> aaa;void push() { aaa.push_back(1);}};Then, I am linking to the lib from a visual studio.net 2003 project, and doing:
int func(){ A* a = new A; a->aaa.push_back(1); //a->push(); // if this line is used instead of the above line no crash delete a; //crash here. }Is it possible that the vector is allocating memory differently when push_back is called from the application, as opposed to the DLL?
or are there some other gotchas with using DLLs that I am unaware of?
C++ + DLL's = Bad Mojo
There are so many different things that can go wrong when using classes from a DLL that it's not even funny. The two most likely problems with what you seem to be trying to do are: one, the DLL and the application are using different heaps. To fix that is compiler dependent, but for MSVC, you need to make sure that both the DLL and the executable are using the a DLL version of the runtime library. (Either the /MD or /MDd switch). The second possiblity is that you need to properly export the vector class. To that, see this article on using templates with DLLs.
There are so many different things that can go wrong when using classes from a DLL that it's not even funny. The two most likely problems with what you seem to be trying to do are: one, the DLL and the application are using different heaps. To fix that is compiler dependent, but for MSVC, you need to make sure that both the DLL and the executable are using the a DLL version of the runtime library. (Either the /MD or /MDd switch). The second possiblity is that you need to properly export the vector class. To that, see this article on using templates with DLLs.
Author
Quote:Original post by SiCrane
C++ + DLL's = Bad Mojo
Agreed. Right now I am wrapping the vector calls with simple Push/Size/Get/etc methods and using other methods in the DLL to handle the allocation/deallocation of memory to avoid this problem. Everything seems to be working now.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
