To STL or not to STL, that is the question...

I'm suprised that no one really mentioned performance in their comparison of STL vs. MFC. I've used MFC a lot and STL some. At work I've written a router. One of the areas I wanted to enhance in the router was a large packet queue. I experiemnted with queues based on a linked list I wrote back in the college days, a CList, an STL queue backed by a list, an STL queue backed by a deque, and finally, my new enhanced queue that would on work in an environment specific to my router. I have the results recorded somewhere, but off the top of my head, after my special queue, the next fastest was the STL queue that was backed by a deque. CList came next but it was a ways behind. What scared me is how close that deque came to being as fast as my special queue...

Anyways, just wanted to say that while performance programming is changing from what it used to be, there ARE situations where saving a second off processing 100,000's of transactions count, and for those types of situations, I'm not sure anything in MFC fits the bill. Just my 2 cents...

I have not been able to find any authoritative data out there on
that topic.

Wow... I missed this discussion completely. But let me sumarise some points first, in one place, for clarity...

First, I will relable the old name STL from the original library proposal to standard library containers (SLC), so to keep the topic off of other template code in the standard library (like strings, streams, etc.).

Pros of SLC:

1) Speed. The SLC gives standardised orders of complexity for nearly all operations on its containers, and by judicious use of generic programming, most implementations are about as fast as one can get portably for a given data structure type. MFC's containers lose out due to vtable indirection and the inability of the optimiser to type deduce (for possible inlining, logic restructuring, etc.).

2) Portability. Well, that's the whole point of the standardisation of the library. MFC's containers are at a major loss here, since much code that uses containers often lies within the business layer of an application that has the most potential for reuse if MFC weren't plugged in.

3) One object, one responsibility. That is just good software design. MFC's containers inherit all of the baggage of serialisation code, etc. of CObject, bloating their sizes and use specs. Bloated usage specifications translates to larger test bases required to verify proper functionality.

4) Namespace containment. Any one who has wrked on a large project using multiple libraries understands how name clashes can be quite a chore to overcome without the ability to ensure namespace integrity.

5) Iterator abstraction. That's not just a minor detail on accessing a container, it is a major advance in abstraction that allows for the reuse of algorithms across containers. Again, MFC's containers fail miserably here.

6) Allocator abstraction. If you ever need to use a container whose objects must be placed anywhere other than the free store (memory mapped files, physical hard drive files, or any serializable interface, just for some common examples) is able to extend the abilities of the SLC to work with such in a reusable and completely generic fashion. MFC is at a complete loss to deal with such needs.

7) A giant standardised library of algorithms to manipulate the contents of the containers in all of the most-used ways, with order of complexity guarantees.


versus...


Pros of MFC's containers

1) Inheritability.
2) Inheritability.
3) Some vague discussion of the use of a memory leak detection problem that has yet to be clarified.
4) Inheritability.
5) Serialisation

1,2, and 4 have already been pointed out to be very poor design. Exposing the implementation of a particular object's abilities is one of the major problems that OOD and, in this particular case, the features of c++ were introduced to solve. And there is not a single place I can think of where containment wouldn't be the much more natural design, since containment of containers says to the problem domain that the class merely holds objects of a specified type, and the particular containment requirements in that domain are free to change in response to any scalability issues that may arise. Inheritance says that you desire a particular relationship between types such that polymorphism (and consequently Liskov substitution) applies. But cases where that might be applied to a particular container are much better handled through writing generic algorithms, as such extension then applies to all containers. And MFC fails miserably in the possibilities here.

3 has yet to be responded to, where it has been shown to be a non-issue to my satisfaction. (It would have been a non-issue anyway to me, since there are plenty of much better memory leak detection possibilities through 3rd party applications such as BoundsChecker which can check actual leaks throughout an application's run in a more robust -- and professional -- manner).

5 is a non-issue in my book, because I have a long list of problems with MFC's serialisation framework anyway (another thread of discussion could go on just that point). Its hideously non-OO, it's versioning is not robust, it will not handle templates, and much, much more. Plus, my preference is that serialisation patterns should be extensible orthogonally, in a policy-like fashion. Uber-class, anyone?

Soo.. STL (my SLC) over MFC's containers? I say of course! If I were to design a library of containers today, I would come up with something very similar to the SLC (well.. excluding all those tiny little pieces of brilliance I am still ignorant of), and nothing like MFC's containers. With no really convincing arguments to the contrary, the SLC has become my friend and confidant while coding...

How can you quote advantages of a design to being of a bad design ?

Anyway I've already said if you are going to port code then by all means use STL (or SLC as you call it).

However, if you don't port code -

(1) Serialization is something you can either pick up or ignore.
(2) Optimisation : Don't you think microsoft compilers are optimised for their own code ? Or rather don't you think their code is optimised for their own compilers. Something tells me i probably is, but there you go.
(3) The STL implementation in Visual C++ is an implementation provided by microsoft in the first place.
(4) I'm working on a 1 million line + application with only 2 of us. We have yet to find a use for namespaces if your classes are named appropriately. If you have a class of the same name doesn't it therefore imply that it's a general class and should be treated as so, instead of another case of copy-and-paste code from one namespace to another just to satisfy some stupid border policy ?

I thought this thread was dead but obviously not so.

No-one here has yet given a truly commanding arguement (except for portability of code which I recognise) to use STL over MFC.

Darwen.

So code failure on updating implementation details is considered good design now?

And the idea that serialisation through a stream interface orthogonal to actual inheritance allows for cleaner hierarchy construction based on the actual design domain is not considered an advantage over uber-class design? Or that one cannot robustly serialise generic types through the MFC mechanism.

And do you mean you do not trust the actual statements of the coding team on advantages of STL in the speed area? We can do some tests, but I see no way to apply the optimisations I mentioned unless Microsoft suddenly started global optimisations and somehow was still able to keep compilation times down to under the days of previous attempts (and still, type deduction could not become enough to take out the virtual indirection on dynamically typed polymorphism or the additional size that must be copied on argument passing).

I agree you can get by without namespaces on your own projects. But if you are a developer that needs to use a socket library from some vendor or a graphics library or.... Well, I know your answer above was: use COM. Except that you are now introducing even more overhead, noncompatibility, etc. That's great if you are building a new shell or somehow working on a project domain that is Windows specific. However most product domains can be usefully ported to Linux, MacOS, etc. to add value... But we are going into portability again (except for overhead). However, if name pollution agrees with your circumstances, then I guess its fine to ignore that feature of c++. However, I see no argument against the standard library using it. Is it really that difficult to learn namespace usage?

Oh... and DinkumWare wrote the STL implementation that Microsoft includes with its compilers...

I agree with Darwen that inheritance is a wonderful thing. But you have to keep in mind that every tool is built with a different purpose in mind. Each of which have their own limitations (including MFC) and their strengths. MFC has a ton of thread dependencies that make it a real pain to use in multi-threaded programming. This is because Microsuck decided to 2store information on a thread specific basis. In doing so they created problems with creating MFC objects in one thread and using them in another. And no I am not referring to just a simple synchronization issue. In some cases you simply cannot use a class in a thread outside of the one that instantiated it.

Moving back to STL, it was designed to be portable, light, and extremely fast! And it meets all of these requirements and then some. Place virtual destructors in STL would do nothing but hurt performance because the compiler would have to generate a V-table. In most cases this performance hit might not be substantial but it would hurt the design of STL.

As for the STD:: blah blah....that's just a ridiculous comment. If you've been developing in C++ for so long than you should be using namespaces in your own applications. They are very important in large scale development projects. Of course if all you do is work on Hello World, than I could understand why namespaces aren't so important to you.

I would like to suggest to anyone that doesn’t like STL, try building an application that uses “Cstring” and one that uses “std::string” to see which one performs better. You’ll understand what I mean if you just spend the time to look at other tools. MFC is great for some things but don’t use it to build a Windows NT service and expect to get a lot of performance out it. Besides, basing an opinion of a technology on the fact that you can’t inherit from it doesn’t make any sense at all. There are a lot of factors that should go into these kinds of comparisons.

To sum this all up…STL rocks! It’s fast…efficient…and very easy to use.

If you think Microsoft's code is written in some fashion to gain optimal speed from their compiler you are WAY WRONG!!! Actually, I can't even begin to tell you how wrong that statement is.

Take some advise and download Intel's C++ compiler and build an MFC, STL, and any other application that you like using their compiler. Than compare the performance between the two. You will find that Intel's compiler kicks the crap out of Microsoft's any day.

Microsoft makes a great IDE (Visual Studio) but they don't concentrate on the compiler to the extent that Intel does. Keep in mind the Intel C++ compiler is a plug-in for Visual Studio so you can install it and switch between the two compilers with ease.

Give it a try...I promise you will never want to return the Microsoft compiler again!

I still see no reply to the iterator and allocator abstraction advantages. Particularly since the iterator abstraction gives all the same extensibility options that derivation might give, but allows such extensions to work over entire classes of iterators and containers instead of just one type as inheritance would. There is no need to access the internals of the classes as well (which would be horribly nonportable... is the data stored in _pData or _memoryBlock, what is its type, etc.). And by the encapsulation rules of Sutter and Myers, this would mean that the function should not be a member of the class anyway, but instead should be a stand-alone algorithm. These are basic good design issues that are handled perfectly with STL and very poorly or not at all with the MFC containers.

I am a firm believe in using tools to help get the job done. Which means that I use tools like BoundsChecker to capture bugs in the code instead of playing with the debug runtime settings. Don't get me wrong, the debug runtime stuff can really help but it doesn't catch all times of errors. Like when someone allocates an array on the stack and then causes a buffer overflow with strcpy() or some other function. But BoundsChecker catches just about everything. Go Numega!!! Go BoundsChecker!!! And no I don't work for Numega. LOL.

Some other really cool tools are Intel's VTune (awesome performance analyzer) and Numega's TrueTime (another cool performance analyzer).

If your company is too cheap to purchase such tools...tell them to get out of the software business. Please. :=)

Happy coding.

This discussion reminds me of other discussions -- "qsort, QSort vs. std::sort" -- or "why referencies are useless" -- or "why it is ok to return pointers to local objects". The regular members of the forums will know what I am talking about.

The original poster started this thread with an affirmation ("I hate STL") and proved that he will defend this point no matter what. This is not a discussion any more, it is a flamewar. The reason why this thread is still alive is that it provides a few usefull points of view and that the language used is reasonable.

However, reading things like "namespaces are useless", or that "a design is not really OO beacuse it doesn't use a lot of inheritance" make me want to bang my head agains the keyboard. But I know from experience that it makes no sense to quote renomed C++ specialists or to write long posts full of decent arguments in such a case.

darwen, before starting another thread like this, please think twice!

I am surprised at the lack of balance in this debate. MFC and STL were architected to meet different needs of differing communities of developers. Rather than debate which library is ‘better’, I suggest you review the strengths and weaknesses of each so that you’ll be able to identify and apply each in the proper context.

If you truly do not understand the tradeoffs (size, space, speed, flexibility, coupling, and cohesion) between subtype polymorphism (inheritance) and parametric polymorphism (templates) then I hope your impact on commercial systems is limited to “coloring inside the lines” of someone else’s design.

This is not a personal attack; simply an view honestly expressed. Like so many other domains – software engineering suffers from the tyranny of the majority. Our field is perceived by the quality of the ‘average’ product produced by the ‘average’ programmer and the quality of both of our averages is far to low.

As far as whether either MFC or STL is OO (or good OO), it simply doesn’t matter. OO is so 80’s and 90’s. What matters is generic, efficient (provably), and reusable software using all means provided to maximal achievement. Inheritance vs. Templates, Function Templates vs. Overloads, Members vs. Friends vs. Out-of-Bodies; there is no “one true way”. No single style or subset of a language is best for all occasions. If so, our languages would simply be smaller. Basic computability theory proves that for any algorithm there are an infinite number of result-equivalent implementations yet each has a unique signature in its path to a common result – meaning differences in size, space, speed, etc.

There will always be numerous ways to reach an end – whether in C++ or any other language. Programmers who grasp the language understand that each way is necessary and not in fact duplicative.

Quote:

---

Originally posted by mclark
I am surprised at the lack of balance in this debate.

---

Well, as I understand this thread, it is a comparison of MFC
containers and STL (or STC if you like). So where is the
lack of balance? Unless you mean that Darwin is off-balance in
his dogmatic refusal to accept the truth.

Quote:

---

MFC and STL were architected to meet different needs of differing communities of developers. Rather than debate which library is ‘better’, I suggest you review the strengths and weaknesses of each so that you’ll be able to identify and apply each in the proper context.

---

Well why don't you start this review? To me MFC is a GUI library that
wraps the Win32 API and adds some extensions like DOC/VIEW.
I have not been pleasantly surprised by any of the lower level
tools and try to avoid them whenever possible, either by writing my own wrappers or turning to boost or the standard.
So what community is MFC geared for? The key word here is GUI.
IMO It is for allowing people to churn out a user interface quickly
and without really knowing what is going on.

At the lower levels of my program I want things to be small and
task specific and I want control. I don't want the "evil MFC framework"
playing any role in my objects to latter come back and bite me on the a_s_s.

Quote:

---

If you truly do not understand the tradeoffs (size, space, speed, flexibility, coupling, and cohesion) between subtype polymorphism (inheritance) and parametric polymorphism (templates) then I hope your impact on commercial systems is limited to “coloring inside the lines” of someone else’s design.

---

Again, how about some details. I am not trying to be rude, it is
just that it would be nice to learn something. I don't disagree
with anything you said.
I don't know how to quite express my thoughts here. I can't
really talk about performance without just quoting someone else, so I will talk about semantics. To me a container
like a vector is a basic object. You don't inherit from it to extend
its capabilities; you write template classes which contain it or
write algorithms to manipulate it. Forgive me if everyone disagrees with this, it is just a point of view I have come to.
To me template programming represents a higher level of
abstraction than inheritance. And adding levels of abstraction
allows one to say and accomplish more with less. Don't get me
wrong, inheritance definitely has its place, but to rigidly demand it
in all situations is silly. A vector is a vector. The usual reason to want to inherit from it is, for example, to have a vector that does this or
that. I believe the proper way to think is that I have a vector that I perform this or that on, not a vector that does this or that.

Quote:

---

As far as whether either MFC or STL is OO (or good OO), it simply doesn’t matter. OO is so 80’s and 90’s.

---

It is so 90's to say it is so 80's and 90's:)

And another thing, why do people keep indicating you can't
use MFC serialization with STL containers. Of course you can.

Darwin have you read the source code for CArchive to see what it does with a MFC contianer? It is easy enough to do the same
thing if you want to use archives with c++ objects.

Very interesting discussion. Always the same arguments.
Normally this tends to be more religious than
rational. If such a narrow minded view does also apply
to other skills of you, you will (too) soon find out that the same
special work you do also can be done by indian or chinese workers as well. At a much lower cost I might add.
Perfection in programming is not the argument for job security.
You really should keep this in mind.