Printable View
"Why are the STL classes not designed to be inherited from"
I find this inheritance useful, why not? (sure not to create its instance by new).
class Matrix : public vector<vector<double> >
{
//provide operator=()
//other operators and operator(int, int) for a[i][j]
//copy constructor
public:
double get_determinant() const;
double get_minor(int row, int col) const;
};
No I don't see what you mean, you don't understand the CRT at all, so your lack of understand leads you to this...if MyClass has a memory leak, the _CrtDumpMemoryLeaks() will show it, please understand what you are talking about before you comment on it.Quote:
Originally posted by darwen
Oh and by the way, in STL I can code, say a vector which is full of memory leaks by doing this :
If 'MyClass' has a memory leak in it, then I can't tell where the memory leak occurs, although it's perfectly valid in stl terms.Code:stl::vector<MyClass>
See what I mean yet ? STL is open to memory leaks !
In programming terms the above is not only possible, but very probable that you would do that.
Darwen.
Please try stepping through your so called 'saint' MFC code to find out what it uses, sheez, what do I need to hit you in the head a couple of more times???
11 years coding??? the horror your customers must have been put through...
EDIT: and you know what, you have ignored me and Paul M, on the memory leak issue that you hold so high up, do you know why you have??? because you DON'T understand, and you probably never will...
(Banging head on wall)Quote:
Originally posted by darwen
Oh and by the way, in STL I can code, say a vector which is full of memory leaks by doing this :
Code:stl::vector<MyClass>
The STL has no memory leaks!!!!!
The only thing that has a memory leak would by "MyClass". If MyClass is not safely copyable or assignable, i.e. the copy constructor, assignment, and destructor are not coded correctly, the problem is not vector, it is your class. Do you think a bunch of incompetent programmers coded the STL? Why would you blame STL for memory leaks and not your code?
So if MyClass is coded incorrectly, this perfectly, non-STL, super-simple program will fall flat on its face:
If your code cannot pass this simple test, then MyClass is not eligible to be placed in any container. As a matter of fact, it isn't worthy to be used in any program if MyClass is intended to be copied or assigned. If your MyClass works perfectly for the above program, then there won't be any memory leaks. It's that simple.Code:int main()
{
MyClass a;
// assign a some values...
// Now later on....
MyClass b;
a = b; // assignment
MyClass c = a; // copy construction
} // destruction
The super-simple program that I wrote above will also leak memory if MyClass is not coded correctly, and there is no STL in that program. So I guess you'll have to give up C++ programming altogether.Quote:
If 'MyClass' has a memory leak in it, then I can't tell where the memory leak occurs, although it's perfectly valid in stl terms.
See what I mean yet ? STL is open to memory leaks !
Regards,
Paul McKenzie
That's the problem. How are you going to ensure that the Matrix class will not be created dynamically? How do you know that someone won't try to derive from Matrix, and use it polymorphically? There are no virtual destructors in vector, so it is dangerous to use it the way you are trying to use it for your Matrix class.Quote:
Originally posted by AvDav
"Why are the STL classes not designed to be inherited from"
I find this inheritance useful, why not? (sure not to create its instance by new).
Regards,
Paul McKenzie
And the UNIX programmer will ask you "what the heck is a COM object and a DispInterface?"Quote:
Originally posted by darwen
Code should never, ever be released in library form. It should always take the form of COM objects or DispInterface objects.
It looks like you believe that C++ is a Microsoft language. It is a general purpose language. It is not controlled by Microsoft, so mentioning COM and DispInterface is irrelevant to the discussion w.r.t. STL
Regards,
Paul McKenzie
Maybe this handout from a class at the University of Victoria in Canada will attempt to explain this to you:Quote:
Originally posted by darwen
And again I ask the question : Why are the STL classes not designed to be inherited from ????
Why not ? Give me a concrete reason why someone in their infinite wisdom decided that these classes should not be inherited from ?
Yes they can't be inherited from. And instead of telling me why they can't be inherited from I need a reason why the originators of their design did it this way.
Darwen.
http://www.cs.uvic.ca/~vanemden/teac...ng/assts/5.txt
Again, the creators of the STL are not stupid -- the STL library has been well thought-out, developed, and peer-reviewed by the best C++ coders in the world, and then approved by ANSI.
I can safely say that the MFC containers have not gone through this process.
Regards,
Paul McKenzie
Yes, in most common case it has potential danger. And probably it's better to hold a std::container<type> as a data of a class than to inherit from that.
I guess maybe I should show you??? since your not getting it...
And as far as the vector, remember that it's dtor gets called when it goes out of scope, so there is NO memory leaks in that code other than what I imposed with new char, you want someting else? or have another point on memory leaks? post some code so I can shoot that down, mark the memory leaks off your list as well as the rest, and next time check your ego at the door, or you'll get it checked for you...Code:#include <windows.h>
#include <vector>
#include <crtdbg.h>
#ifdef _DEBUG
#define new new(_NORMAL_BLOCK, THIS_FILE, __LINE__)
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
class vl
{
public:
void al();
vl();
};
vl::vl()
{
al();
}
void vl::al()
{
char* t = new char[256];
}
using namespace std;
int main(int argc, char* argv[])
{
vector<vl> t;
vl p;
t.push_back(p);
_CrtDumpMemoryLeaks();
return 0;
}
I am sorry Please donot yield at me....I am not a professional though I got a + after that wordeof Member, I just wanted to ask someone up there a question that...If i would like to check for the memory leak caused by my mistake when coding, i just put that function right into my main function and it will automatically works fine for me or is there anything that you think i should take into consideration when doing that? now could you tell me Sir ?:)
Thank you...
I am unsure what you are asking homey, but you should post it in another thread...which function are you talking about?Quote:
Originally posted by hometown
I am sorry Please donot yield at me....I am not a professional though I got a + after that wordeof Member, I just wanted to ask someone up there a question that...If i would like to check for the memory leak caused by my mistake when coding, i just put that function right into my main function and it will automatically works fine for me or is there anything that you think i should take into consideration when doing that? now could you tell me Sir ?:)
Thank you...
_CrtDumpMemoryLeaks();Quote:
Originally posted by Mick_2002
I am unsure what you are asking homey, but you should post it in another thread...which function are you talking about?
It depends, if your using MFC(afx.h) it is automatically called for you when you exit and hit the dtor:Quote:
Originally posted by hometown
_CrtDumpMemoryLeaks();
AFX_DEBUG_STATE::~_AFX_DEBUG_STATE()
if your not using MFC/afx.h then #include <crtdbg.h> and call dumpmemoryleaks when you hit your own program exit or dtor...
But be forwarned, that some leaks, are not indeed leaks, you just have to know.
if you want to have the line output in the debug output window so you can double click then (again MFC will set this up for you if you are using it)
in your .cpp'sCode:#ifdef _DEBUG
#define new new(_NORMAL_BLOCK, THIS_FILE, __LINE__)
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
look at the _CrtXXX library, it's full of functions, that people don't use, and people take for granted because MFC wraps them, and they don't understand that. MFC's wrappers are overkill, and not very useful IMHO. Use what you need, and use it in the raw sense....
Like gsterckens signature says:
and in this thread, that is all too true.Quote:
Any person without knowledge of C++ (windows specific API's - Mick) can create a Windows application using MFC and AppWizard. Many did.
I also hope that is all too true in this thread, but i think we restart in another thread...right ?
Thank you,
So sorry to irritate, I promise not to do this again....:(
I hate to say ***, but ***. I will quote myself from some time ago in this thread.Quote:
Originally posted by darwen
And again I ask the question : Why are the STL classes not designed to be inherited from ????
Why not ? Give me a concrete reason why someone in their infinite wisdom decided that these classes should not be inherited from ?
Yes they can't be inherited from. And instead of telling me why they can't be inherited from I need a reason why the originators of their design did it this way.
Darwen.
I am sure I am only scratching the surface of this explanation.Quote:
The STL containers do not have virtual destructors because they
are designed for efficiency. Including a virtual destructor means
that there is now a vtable, vptr and inlining is effectively eliminated.
to Darwen.
If you think any class which can be Base class then you should have virtual dtor in that class. The other thing you have to consider is to properly overload assingment operator and copy ctor (i.e. calling proper base class's respective function, take a look at Effective C++ for more info on this topic).
But whenever you add virtual function in your class then vptr is added in all of the object and vtable is also made for each class. Also due to indirection of calling virtual function it become little bit slow.
Again i repeat inheritance is not the only way to do polymorphism in C++. Here i m giving you two sample program to take a look at those.
Code:// Prog 1
#include <iostream>
class Base {
public:
void NonVirtual() { VirtualFun(); }
virtual void VirtualFun() { std::cout << "Base::VirtualFun" << std::endl; }
};
class Drive : public Base
{
public:
void VirtualFun() { std::cout << "Drive::VirtualFun" << std::endl; }
};
int main()
{
Drive d;
d.NonVirtual();
return 0;
}
The output of this program is
Drive::VirtualFun
The output of this progra is alsoCode:// Prog 2
#include <iostream>
template <typename T>
class Base {
public:
void NonVirtual()
{
T* pT = static_cast<T*>(this);
pT->VirtualFun();
}
void VirtualFun() { std::cout << "Base::VirtualFun" << std::endl; }
};
class Drive : public Base<Drive>
{
public:
void VirtualFun() { std::cout << "Drive::VirtualFun" << std::endl; }
};
int main()
{
Drive d;
d.NonVirtual();
return 0;
}
Drive::VirtualFun
But the advantage of second program is that it is fast and takes less memory as compare to first one. In Prog 1 you are doing polymorphism at run time and in prog 2 you are doing it at compile time. This is the also one of the technique which ATL internaly use for fast and small code.
So why should we pay more (in term of indirection, extra memory and writing more code for copy ctor and assingment operator) when we can do the same thing with different paradigm? This is one of the reason that STL doesnt have virtual dtor.
And BTW why you want to inherit any class from STL? Tell me any case in which you have to inherit class from STL.