   C++ new/delete on derived classes
  I have a base class: #include <string>using namespace std;class base{}; and a derived class:class derived : public base{public: string str;derived(const string& s){str.assign(s);}};When I execute this:base *p = new derived("string");delete p;valgrind reports some "definitely lost" memory. However if I revise it to derived *p = new derived("string");delete p;I have no memory issues. What gives? Do I actually need to go change my pointer to the correct type before I delete it? If so, somebody tell me why that isn't total BS!   
Quote:Original post by dc443Do I actually need to go change my pointer to the correct type before I delete it?No, there's nothing wrong with deleting a derived class instance through a base class pointer.   ;Quote:Original post by Driv3MeFarQuote:Original post by dc443Do I actually need to go change my pointer to the correct type before I delete it?No, there's nothing wrong with deleting a derived class instance through a base class pointer.So my question still stands. What the hell kind of black magic is going on here? once i cast my pointer to the right type, it correctly deallocates the memory. I really don't want to have to painstakingly go through and make sure I do this when I know that I'm not supposed to have to do it.   ;  maybe tryclass base{    virtual ~base(void){}};but i have really no clue why u have memory los there. Maybe your os doesn't release the memory allocated by the programm directly so that for later reuse it stays in there.;  Ok it looks like that does the trick. When deleting using base pointer I must be using virtual destructors. It just seems kinda backwards because I don't get when the regular behavior (the one in which derived destructor isn't called) is useful. I guess the designers of the language had their reasons.To anybody with similar issues, this is the rule to live by: If a method is virtual, then calling the method on an object always invokes the method as implemented by the most heavily derived class. If the method is not virtual, then it invokes the implementation corresponding to the compile-time type of the object pointer.pulled from http://blogs.msdn.com/oldnewthing/archive/2004/05/07/127826.aspx   ;Quote:Original post by dc443Ok it looks like that does the trick. When deleting using base pointer I must be using virtual destructors. It just seems kinda backwards because I don't get when the regular behavior (the one in which derived destructor isn't called) is useful. I guess the designers of the language had their reasons.Yep, if you're going to be calling delete on a base pointer (when it might point to a derived type), then the destructor should be virtual.The regular behavior is useful because you're not always writing polymorphic classes. If a class doesn't have ANY virtual functions, then the compiler doesn't have to generate a v-table for that object, making it use slightly less memory.For objects like simple (non-polymorphic) structs that are stored in an array, this can be useful.   ;  Yeah, also I was thinking about it for a bit, and if you do not declare any functions as virtual, then you can guarantee that any derived classes (created later on, perhaps by a different author) will not be able to alter the functionality of code which calls functions from the base class. That's a good enough reason to make the default behavior to be non-virtual. And having destructors not use the same semantics for the virtual keyword would just be silly.   