wow man...i am definetly goin to learn more of STL....:) :cool:
Printable View
wow man...i am definetly goin to learn more of STL....:) :cool:
Quote:
Oh, or of course you couldn't derive from std::vector and add them
to a linked list because there's no virtual destructors.
Why would you need inheritance for this ? The following works just fineCode:list<vector<T> > list_of_vectors;
Why ?????Quote:
Oh and as to sorting stuff - you still have to write your own
code to sort lists which means it isn't any better than MFC.
Code:list<int> li;
//
//
li.sort();
Not according to microsoft ...Quote:
Its performance does not seem to anyway better than equivalent than MFC.
see http://msdn.microsoft.com/chats/vstu...dio_022703.asp
Quote:
Host: Jon (Microsoft)
Q: srinadh : How efficient are MS ISO standard implementations compared to MFC
based implementations?
A: In general the STL containers are more efficient that the MFC containers ...
but as always it depends on your application.
Host: Jon (Microsoft)
Q: srinadh : Q:Can you eloborate on how what kind MFC containers are efficient for what kind of applications compared ofcourse to STL containers?
A: Not really this dependents on the performance characteristics of your progam ... but we use STL inside the compiler and we have not problems with their performance.
Well lets discuss this topic in another point of view. In C++ you can do polymorphism in 4 different ways.
1. Overloading
2. Template
3. Inheritance
4. Type conversion
Multi-Paradigm Design for C++ by James O Coplien Page 22.
The only thing which we can compare about MFC and STL is containers, because you cant make UI with only STL. So Our first discussion is on Container.
Here MFC and STL are different from design, but i must say different paradigm. STL is use template for polymorphism i.e. Generic Programming, on the other hand MFC use inheritance (i.e. virtual function) to do polymorphism.
So these are two different ways of programming. In Template you will do polymorphism at compile time and MFC you will get polymorphism at run time.
It is look like compare apple with oranges, i.e. you are going to compare Generic Programming with Object Oriened Programming. Both have some advantage and disadvantages over other.
Well by taking close look at their design, in STL almost all the operations (like sort, find, replace etc) are not member of class and same is true in case of MFC container classes. Till now the situation is almost equal except the different programming style.
But STL is not only container. STL has some other very good concepts which MFC doesnt have like itertor, algorithm, allocator, binder etc. To take a close look a this almost all the operation on STL containter are done in template function called algorithm. But how those algorithm knows about the container? The answer of this question is iterator. So you can say something like this
Algorithm works on container with the help of container.
The beauty of STL is its extensibility. Most of new C++ Programmer thought that you can do extensibility only with the help of Inheritance. I suggest those to take a look at Herb Suter article "Use and Abuse of Inheritance" in
More C++ Gems by Robert C Martin
The only valid cases of inheritance are
1. When you want to access proteced data of base class
2. When you want to override virtual function
3. When you want to implement kind of relation ship (although sometimes you implement it with aggragation instead of inheritance e.g. take a look at Stack, Queue and Priority Queue classes of STL)
There can be another thread of discusison on this too where to use inheritance and aggregation.
Well STL is very extensible and you extend it without inheritance. But how?
Suppose you want to add one new algorithm in STL. Then you can write this algorithm in the form of template function which take iterator as an input. Now all classes which have those iterator can use that algorithm without any problem. You can do it in MFC but you have to wirte the same algorithm for each and every container.
And in the same way, when you want to make you own container like single link list (some libraries already have this) then you make iterator in those container then all of your existing algorithm start working on this. In MFC you have to write code (in the form of member function) and repeat the logic of all the algorithms on your new container to work with your new class.
In the same way you can make your own allocator (memory manager) and plug it into any continer to use it.
This is the beauty of STL to extend it orthogonaly even without see the source code of existing library. And this is the beauty i like and i never think to work with MFC container classes. To be very honest from the first day of my MFC Programming i m using STL containter wherever i need and i couldnt find a signle case where STL is not enough and i have to switch MFC container classes.
Take a look at some good STL books and do some experiment on it, hopefully you like its design and extensibility. Here are some of my suggestions.
1. The C++ Standard Library: A Tutorial and Reference by Nicolai M Josuttis
2. STL Tutorial and reference Guide Second Edition by David R Musser, Gilmer J Derge Atul Saini
3. Generic Programming and the STL: Using and Extending the C++ Standard Template Library by Matthew H Austern
4. Effective STL: 50 Specific ways to Improve Your use of the Standard Template Library by Scott Meyers.
In last i read of of MS guys interview (sorry i forgot the name) he mention that MS internaly use STL for its own VC Compiler.
What are you talking about?Quote:
Originally posted by darwen
Oh and as to sorting stuff - you still have to write your own code to sort lists which means it isn't any better than MFC.
If you're going to talk about something, at least know the topic well enough to comment.Code:#include <list>
std::list<int> IntList;
IntList.sort();
And what function will you use when you need to sort your CStringArray?Quote:
At any rate you can still use the function ::sort if you wish.
I'm not talking about performance -- I'm talking about usefullness. Once you derive from CObject, your class has immediately become uncopyable and unassignable. When I code a class, I want to know exactly the impact of what I'm deriving from, not only performance, but also programming-wise.Quote:
Overhead of CObject from what I've seen is very, very small. I've never had any performance hits from it.
What do you think makes STL not work with DEBUG_NEW? Is it the fact that it uses an overloaded operator new? But overloading operator new is part of C++, not necesarily STL. Have you ever overloaded operator new? How about placement new? I would think that someone who needs DEBUG_NEW so much would investigate why STL "does not work" (whatever that means) with DEBUG_NEW. STL is just C++ code, the same code that someone else could write without introducing any STL.Quote:
I've also in my 10 or so years of programming windows have never come across anything except for the STL that won't work with DEBUG_NEW. Please give an example.
What if you now want CServerNames to be derived from CList? You now have to tell all your clients that the server names are stored in a CList and they have to change all of their source code to reflect the fact you changed to a linked list. To a C++ programmer, that would tick them off to no end. What you're doing is exposing the client to the data structure that you happen to be using now, but if you decide to change the structure later, the client has to now change all of their code.Quote:
And in your example of using a list the trouble with that is you either have to expose the member so you have
Code:CServerNames asNames;
asNames.GetList(). blah
which is ugly in my opinion, or you have to override all the members of the list as members of your class.
With inheritance you don't need to.
It is much better (even if you were to derive from CStringArray or CList) to provide GetNames and SetNames functions, so that the type of structure that you are storing this information is invisible to the client. If you decide to change from CStringArray to CList, this change will not impact the client. Therefore in the end, inheritance really didn't buy you anything -- you might have just used composition -- have a CStringArray member instead of deriving from CStringArray.
Those are templates. They are part of C++. It looks like you are confusing basic C++ concepts with STL. You can use templates without using STL. If I wrote a template class, is it ugly?Quote:
I know std:: is a namespace. A bit nit-picky arguing about it if you ask me.
Never mind that the stuff like
looks really ugly and horrid in my opinion.Code:std::vector<std::string> AllMyNames;
Darwen.
There is absolutely *no* STL in the code I wrote. Your remark of "ugliness" has nothing to do with STL, but with templates and namespaces in general. If there are various parts of C++ that you do not like to use (or use at all), just say so. From here, it looks like you don't like namespaces and templates.Code:namespace MyLib
{
template <class T>
class MyClass
{
public:
T x;
T GetT() const { return x; }
};
}
int main()
{
MyLib::MyClass<int> MC;
MC.GetT();
}
Regards,
Paul McKenzie
what about finding or print code in mfc? I would like to see you write one line to print out your mfc container:
std::copy( someList.begin(), someList.end(), std::ostream_iterator( someFile, "," ) );
or searching, with 1-2 lines of code in stl you can easily search a container using custom comparisons, not just equals.
I know this is off topic, but does anyone see a pattern here?Quote:
Originally posted by Philip Nicoletti
Not according to microsoft ...
see http://msdn.microsoft.com/chats/vstu...2703.asp<br />
quote:
--------------------------------------------------------------------------------
Host: Jon (Microsoft)
Q: srinadh : How efficient are MS ISO standard implementations compared to MFC
based implementations?
A: In general the STL containers are more efficient that the MFC containers ...
but as always it depends on your application.
Host: Jon (Microsoft)
Q: srinadh : Q:Can you eloborate on how what kind MFC containers are efficient for what kind of applications compared ofcourse to STL containers?
A: Not really this dependents on the performance characteristics of your progam ... but we use STL inside the compiler and we have not problems with their performance.
--------------------------------------------------------------------------------
Quote:
Host: JeffPeil (Microsoft)
Q: souldog asks "There is a very common prejudice out there that the MFC socket classes CSocket and CAsyncSocket are buggy and poorly designed. Could you address if this prejudice is justified and if problems do exist whether they have been fixed in the new versions of VC++
A: It is important to remember that these classes have a long legacy dating back to the Win 3.1 flavor of Winsock which was a very different beast. Our flexibility here is certainly limited due to this legacy. The classes aren't buggy, but I wouldn't recommend using them in places where you aren't already using them as there are certainly better ways to do programming with sockets.
Host: JeffPeil (Microsoft)
Q: souldog asks "Are there any plans to produce some updated wrapper classes for the socket API in MFC?"
A: Network programming is not really core to MFC, there are many other areas of MFC where we believe we can deliver more value.
hmm the wait and see if we can incorporate (see buy) some other technologies to augment our own deficiencies? Do I get a cookie or a gold star?
BTW: MickeySoft isn't the only one, as usual I'll plug my GE is evil and do the same such thing...GE we bring such good things to darkness...
Firstly, to Zeeshan :
My point, as has always been my point is that if the originators of the STL put virtual destructors into their classes then you could safely inherit from them, templated or not.
Does anyone know why they did not do this ? Can anyone here tell me why ?
Darwen.
To souldog :
Templated classes are ugly in my opinion. But yes they are a very, very useful part of C++ and I use them all the time.
All I was saying was : if you could inherit from STL classes then you could remove the ugliness altogether.
Darwen.
Oh, and to be quite honest I don't like namespaces. I see no need whatsoever - the browser in VC will point you at definition of a class.
I believe that namespaces have been introduced so you know where classes are defined. But with a decent browser option why bother ?
There are two of us at work (including myself) dealing with 1,000,000 lines of code and we don't use namespaces - why ? The browser always tells us where things are.
Also with proper naming of shared header files again why bother ?
It's like static_cast<> etc.
All of these things are designed to hide problems, not show them up. A GPF shows you far more of a problem than one which is hidden by these operations.
And again, if you write stable code you want to be shown problems so you solve them, not handle them.
This is going on, and on and on....
Darwen.
Namespaces were introduced so that there is no clash between classes, structs and variables that may share the same name. If Joe called his class "String", and you are using Jack's library that uses "String", and you happen to be using both Joe's and Jack's classes in your application, which version of "String" is used when you compile a module that includes both classes? That's why namespaces were introduced, to resolve name conflicts, not because it makes things easier to find.Quote:
Originally posted by darwen
Oh, and to be quite honest I don't like namespaces. I see no need whatsoever - the browser in VC will point you at definition of a class.
I believe that namespaces have been introduced so you know where classes are defined. But with a decent browser option why bother ?
What does this have to do with whether namespaces are or are not necessary? Libraries are not written and language rules are not developed assuming two people are developing the application using the VC++ class browser. What if the organization has 20 developers? What if there are third-party libraries used?Quote:
There are two of us at work (including myself) dealing with 1,000,000 lines of code and we don't use namespaces - why ? The browser always tells us where things are.
See above. What if you decide to share your code with others, and one of your potential clients have already written a 10,000,000 line application? What are you going to say to them when one of their names clashes with one of your class names? Modern C++ code that is distributed as third-party code should always use namespaces, and you never know how (in the future) your code will be used with other codebases.Quote:
Also with proper naming of shared header files again why bother ?
And the more code you write, the more potential there is for problems to crop up. Read your previous posts where you admit you have to write extra code to extend the MFC container functionality. You are contradicting your point of having stable code by writing more code that has to be tested, maintained, and possibly fixed.Quote:
It's like static_cast<> etc.
All of these things are designed to hide problems, not show them up.
I will repeat what I wrote in the thread that was closed.
And they have not been peer-reviewed by ANSI, so why should any of us use them? How do we know your classes aren't full of bugs? Are you now saying that Joseph (the OP) should start using your classes (or code his own)? You are talking about the merits of MFC, and then you state that you still need to write your own functions -- more code to maintain, more potential bugs.Quote:
Originally posted by darwen But I have my own classes to do all of that anyway and they are all derived from MFC.
Also, I highly doubt that the number of functions you have written come anywhere close to what is provided by the STL container and algorithm functions.
As I stated before, the problem that you are having doesn't seem to be STL, but template syntax in general. You can code a non-STL application, and it will look messy to you since it may use templates.Quote:
So in my opinion disadvantages of STL -
(1) It doesn't look very nice (if you look at STL-code and the equivalent non-STL then the STL looks really messy).
Why would you need memory tracking for the STL containers? The containers already work. The only memory tracking you would need would be on your own classes.Quote:
(2) Can't do memory tracking etc on it.
I don't know what you mean by "going around the house". Ever hear of generic programming? You don't accomplish that by inheritance, but by template programming.Quote:
(3) Can't inherit which means going around the houses most of the time.
Sorting is just one example. Have you seen the list of algorithm functions? How about searching? How about calling a function on all elements of the container? MFC has no such functions. Have you ever used iterators? I think you need to take a look at STL in its entirety.Quote:
Advantages of STL :
(1) Sorting.
This has been rehashed time and again on different forums. MFC (in terms of the container classes) has always been deemed inferior to STL by most, if not all, C++ professionals who have name recognition. Sorry, but that's the consensus.Quote:
Sorry, I didn't intend for this to turn into a flaming match. I meant for it to be a real discussion of the pros and cons of STL Vs MFC
Regards,
Paul McKenzie
If you did derive the STL classes, you have to provide your own operator =, since you do not automatically inherit the assignment operator from the base class. More code to write, more code to maintain, more code that can go wrong.Quote:
Originally posted by darwen
Firstly, to Zeeshan :
My point, as has always been my point is that if the originators of the STL put virtual destructors into their classes then you could safely inherit from them, templated or not.
Because the STL classes were not designed to be inherited from. If the class is not designed for inheritance, you just don't slap on a virtual destructor "just for the heck of it". The STL classes are designed for generic programming (as Zeeshan pointed out), and not providing a virtual destructor enforces this paradigm. Note that there are no virtual functions in the STL container classes. Again, there is no reason for a virtual destructor if the class is not designed for inheritance and there are no virtual functions.Quote:
Does anyone know why they did not do this ? Can anyone here tell me why ?
Darwen.
The MFC classes were designed with inheritance, since there are a lot of things that you cannot do with the MFC container classes (like copying and assigning) that requires inheritance.
Regards,
Paul McKenzie
Code should never, ever be released in library form. It should always take the form of COM objects or DispInterface objects.
Libraries are nasty little beasts because they are so heavily dependent on which platform or even which version of Visual C++/C# or VB you are using.
The only way of truly giving a functional library is to use COM objects etc.
Why do you think that Microsoft does this with DirectX etc ?
In which case : namespaces are again useless.
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.
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.