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

First let me say that my experience with MFC is limited. Most of my systems use commercial or proprietary RTOSes. So my insight into MFC is far from definitive. STL on the other hand I have significant practical experience with and David Musser (one of the founding authors of STL) was a professor of mine during my undergraduate work at RPI. Yes, you would think that this would unfairly bias me towards STL but the opposite is true. Early versions of STL (including those that morphed into the HP version) were horrendous to use. I spent many years since avoiding STL where possible. It has been a hard road back to recognize STL’s true genius.

But from my limited view I don't think your analysis of MFC as...

Quote:

---

... MFC is a GUI library that wraps the Win32 API and adds some extensions like DOC/VIEW.

---

is that far off. It does seem as though its primary purpose is to provide an OO interface to the WIN32 API. This is of course very useful. How many times have we looked on in disgust at a beautifully crafted object that is forced to embed an OS C system call (ala POSIX or WIN32)?

STL on the other hand was intended to provide a library of ‘generic’ containers and efficient algorithms for operating on containers. In STL the term ‘generic’ does not simply mean reusable but relying on only the most basic of semantic relationships as forwarded by the ‘generic programming’ sub-discipline. In STL the generic philosophy can be seen manifest in the relationship between containers, interators and algorithms. Iterators provide the access and operations for containers as required by algorithms so allowing algorithms to interoperate with any number of differing types of containers. Since a container need only provide the correct iterator to be useable by an algorithm – no inheritance (IS-A, refinement) relationship need exist between containers. This in turn allows each container’s interface to be unique to its intent and capability and eliminates performance and design coupling associated with virtual functions. The tradeoff is that the type of the container (or actually the iterator’s type) must be determinable at compilation time.

If types truly cannot be ‘known’ at compilation time then inheritance is required though it is often useful even when the types are known to control the code-bloat associated with templates which would have to be instantiated on a large number of types.

Everyone knows that you can use STL containers on polymorphic data but since you cannot inherit (safely) from STL types, people assume that you cannot have run-time polymorphic STL objects (ie. Run-time determination of what container type you are passing into an algorithm). This can easily be achieved though a customer iterator type that contains a polymorphic member. In this way, the exterior iterator type (your custom iterator) passed to the algorithm is static, yet the iterator forwards operations to a polymorphic member whose type is run-time dependent.

Quote:

---

Again, how about some details. I am not trying to be rude, it is just that it would be nice to learn something.

---

I know, I know. Its just hard in a busy schedule to find the time to whip up meaningful example code for a discussion forum. The polymorphic member approach is heavily used in policy-based libraries like LOKI from A. Alexandrescu's "Modern C++ Design: Generic Programming and Design Patterns Applied" (a most mis-titled book) but not for STL. If someone is very VERY intrested I will put together the code for polymorphic iterators.

A virtual function call is always more expensive than a normal function call unless the compiler can determine the type – but since we are assuming that inheritance was dictated by at least one instance where the type is ‘unknowable’ it is fair to say that overall it is more expensive. But it is the only way. If you really need run-time polymorphism (either because types are unknowable or instantiation of templates on all required types is to great) then you must pay for it. Nothing including polymorphism is free.

The real difference on the inheritance vs. templates in MFC and STL is that STL does not require you to pay for something unless you use it. If you want run-time polymorphism of STL objects (not just STL objects containing polymorphic data) then you have to pay for it using run-time polymorphic members within your own iterator type.

As far as the single-rooted hierarchy style of MFC – there are a number of papers/books critiquing this design style. Given MFC’s focus on GUI construction, the single-rooted approach is of no surprise since there is a strong history of single-rooted hierarchies in OO GUI tool-kits.

Quote:

---

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.

---

We are in violent agreement.

STL is ok upto a point
Anybody tried building DLL using the STL? It's difficult as you have to export the derived templated STL class.
Even worse some won't even export, map for example.

I have resorted to implementing my own simple collection classes CVoidMap and CMultiList.

Aha MultiList.

CMultList maintains many lists and moves entries from one list to another without re-allocating memory (deletes move entries to a free list). Usefull if you want to avoid memory fragmentation. The object pointed to by the multi list entry remains where it was allocated.
E.G. So you have 2 lists - Active and Inactive. When an object becomes active move it to the active list. When inactive move it back again. Only pointers to list entries are updated.

Want it ?

e-mail [email protected]

Quote:

---

Originally posted by Bob Sheep
STL is ok upto a point
Anybody tried building DLL using the STL? It's difficult as you have to export the derived templated STL class.
Even worse some won't even export, map for example.

---

That is a deficiency of DLL's not handling C++ templates. DLL's were not made to handle C++ templates nicely or correctly (note that this is with all template classes, not just STL classes).

Regards,

Paul McKenzie

Interesting topic....so of coarse I've got to throw my 2 cents in :)

First I didn't know people were still using STL in production code.
One of the first rules about coding, at least for me, is that all code I write or use must be easily debugable. Meaning, if I have to run around in a whole bunch of badly written STL lines of code to find a problem, I'm losing time, and as we all know, time costs money...

Another rule, all code must be easily reusable. While STL is indeed reusable, when you get to complex container use, its gets overly confusing and very hard to reuse (nevermind insane to debug). Which makes STL great for the one time slap a 'int' container together program. Otherwise known as a homework assignment....

In my many years of programming, I've seen that most professional programmers write their own code and expand it to complete all that is missing in other peoples code.

An example for MFC is CString... I haven't used CString in years. I have since written my own class which does everything CString does in full binary and a whole bunch more like full token parsing, file parsing, easy indexing, page development, and easy to pass around between dlls and processes with out memory leaks or MFC boundry issues....Nevermind its ease to use it in any container class. CString and MFC are great for the casual programmer, but in the real world when you're writing a million dollar piece of software, you don't have time to write the odd function here and odd function there to compensate for MFC's or STL's badly designed code...you need something that you can trust to work and wont change no matter what system you drop it on or what program you need to create. Less time you spend, more profit for you :D

The only MFC class I use is CWnd and that's so I don't have to mess around with the API when creating my own controls. This is another example of where you want a control to look the same on all Windows systems, so you draw the thing yourself. Yes, it takes a little extra time, but over the years you build your own library of code that you can trust and makes it easier for you to create programs. Which is why I can slap entire applications together in minutes that would take someone in MFC or STL hours to do...

So the moral of the story is:
You like STL or MFC? Cool, learn from it...write your own templates and classes...expand it....but don't use that crap in a professional program unless you like being unemployed…

You should have your own libraries full of code you know how to use and know that works, and have added lots of wonderful and useful things to, that will make your job very easy in future projects.

Don't believe me? I have time to write this cause my boss gave me an hour to write a program that uses a drag-n-drop listctrl to convert our proprietary formats to any common image type, I did it all using only CWnd in MFC as a base class for my ctrls and dialog, and everything else was my own code...it took me 15 minutes... (I've always meant to go back and replace CWnd...but it works great and with ease...so eventually...)

So which is better? Neither, they both suck, write your own code :)

Back to work!

Quote:

---

You should have your own libraries full of code you know how to use and know that works, and have added lots of wonderful and useful things to, that will make your job very easy in future projects.

---

The personal 'everything and the kitchen sink' library might work very well on the desktop but not all environments are so forgiving.

There are other domains where every cycle, every byte and every bug count. Balancing functionality, standardization, performance and trust is not always as easy as 'roll your own'.

Quote:

---

Originally posted by oktronic
So the moral of the story is:
You like STL or MFC? Cool, learn from it...write your own templates and classes...expand it....but don't use that crap in a professional program unless you like being unemployed…

---

I've been employed for over 20 years, and I use STL all the time. Using your method is the fastest way of being unemployed, if not, unemployable.

Quote:

---

You should have your own libraries full of code you know how to use and know that works, and have added lots of wonderful and useful things to, that will make your job very easy in future projects.

---

And this is what STL provides. I know how to use it, I know how it works, and I've added lots of wonderful and useful things to it by using the algorithm classes.

Your method will make the job of the next programmer who has to maintain your code less enjoyable. When there is a bug or something needs to be added, the programmer that is hired to look at your code now has to work doubly hard to understand what you are doing, and where to add this functionality (if the functionality can be added).

You may work as a sole-programmer, but when it comes down to brass tacks, your method is the one that will lose time and money, not the other way around. In most professional environment, your home-made code would be tossed in the trash bin -- it may be the greatest code you've ever written, it doesn't matter. It will be removed in favor of standard components. Why?

a) maintenance
b) cost of training someone to use your home-made library.
c) thousands of programmers have tested and used them
d) documentation can be easily found on any of the standard components.

Quote:

---

So which is better? Neither, they both suck, write your own code :)

---

I guess you are a 'C' programmer who learned C++ later, right? Usually it is these programmers who want to write everything themselves (but for some reason, they never feel compelled to right their own FILE* functions or strcpy(), or memcpy(). I wonder why?).

The STL classes are written by some of the best C++ programmers in the world. They are not fly-by-night programmers who made up these classes, as your last paragraph suggests.

Also, you don't choose a technology because a certain debugger doesn't show you the data that you want. Really, that is a naive approach to programming -- depending on how fancy the debugger shows you data. If the next version of VC++ has the greatest debugger in the world that shows you everything, will you then use the STL classes?

Regards,

Paul McKenzie

indeed mclark,
Design, design, design....
I'm a huge fan of encapsulation. Everything is broken up in nice modules, static libraries and dlls. Depending on what it is and how its useful...
I'm 99% windows, but things that can be used elsewhere are set up to be.

Sorry Paul, didn't notice your response, guess you posted as I did...

Shall we begin...

QUOTE]I guess you are a 'C' programmer who learned C++ later, right?[/QUOTE]

Most of us senior programmers are, Paul. This might comes as a shock, but C came before C++. There were a whole bunch of languages before C++ surprisingly....

Quote:

---

I've been employed for over 20 years, and I use STL all the time

---

Nothing personal, but I kind of doubt this...maybe 10...besides the most obvious reason that STL isn't that old and wasn't used in a commercial compiler until mid to late 90's, there is this:
You see Paul, every professional C programmer when they migrated to C++, and I stretch the term migrated, took their existing code and libraries and converted it to be object orientated...well, those of us who liked the idea of C++ anyways.... So we programmers, who have actually programmed for 20 years+, would have converted or kept our existing C or C++ containers...why? Because what works, works...there's no need to take a class which is new and replace bug free, fully functional code that has withstood the test of time....many companies wouldn't even allow C++ when it came out to be used for this very reason...

Quote:

---

You may work as a sole-programmer, but when it comes down to brass tacks, your method is the one that will lose time and money, not the other way around.

---

This is another example of what I was talking about above about the inexperience.
In my experience as an employee and as a consultant, companies prefer non-dependant code to SDK libraries that are subject to change. Generally when you supply your own code to a project, a company, when you leave, will buy the rights, if you have any, or purchase use of your code for a nice fee.
I've held many contracts in my hand that do not allow the use of STL or MFC, since both are subject to change. At some point the program will need to be compiled again, or MFC will change and then a new bug may be introduced into the system. When your program is required to run for years with out any problem at all, which is the work I do the most, you can not afford the liability of code stopping to work because of an update.

Quote:

---

And this is what STL provides. I know how to use it, I know how it works, and I've added lots of wonderful and useful things to it by using the algorithm classes

---

First, there are no algorithm classes, they're all template functions, so unless you are talking about something else then the STL algorithm functions, I'm confused....and if you are talking about the functions, then your statement loses weight.

Quote:

---

a) maintenance
b) cost of training someone to use your home-made library.
c) thousands of programmers have tested and used them
d) documentation can be easily found on any of the standard components.

---

a) well designed code doesn't require maintenance.
b) if you have to train a C++ programmer to read C++, C, or function documentation, then you've hired the wrong guy.
c) you mean thousands of buggy college programs?
d) MSDN does have documentation, its hardly understandable for even the average C++ programmer. Sadly, the technical writer and the programmers who explained it didn't quite understand it, so they used a lot of the original documentation, which is why MSDN is so vague, the original writers didn’t think it would go far enough to need further explanation. That’s why it reads like R&D notes.

Quote:

---

The STL classes are written by some of the best C++ programmers in the world

---

I'd love to tell you all about this, but instead I'm just going to laugh real hard...

Quote:

---

They are not fly-by-night programmers who made up these classes

---

Guess you never opened one of the header files....

Quote:

---

Also, you don't choose a technology because a certain debugger doesn't show you the data that you want

---

Yes you do. Again, time is money. If you're paying a programmer $15/hr, then no, you loss is minimal if he has to spend an additional hour sifting badly written code to find a problem.
However, when you pay $200/hr to $10000/day, then you can't afford to spend time screwing around. So yes, you can reject a technology for costing you unnecessary money.

So Paul, I hope I've covered everything for you. No disrespect is intended by this, simply clarification.

Regards,
Oktronic

Well I haven't even been programming for a year and a half and
I have enough sense to know what you are saying is BS.

Standardization

Oh boy, this has been running for a long time since I started it !

Right, addressing a few points :

(1) Writing all you own code from scratch.
Are you mad ? Don't you ever think of moving companies ? If you do you'll have to do it all again otherwise face those nasty people called lawyers.
Never mind the fact that it makes your code unreadable to everyone else because no-one knows your class hierarchy. True you can say that your own code has to be interpreted by others anyway but if it's based on MFC (and when I say MFC I'm not refering to the GUI classes, I'm refering to things like CMapStringToPtr and CMapStringToOb and CDWordArray and CString etc etc) or STL at least people have half a chance of understanding the basics of it.

If you use your own set of base classes it'll make your project's learning curve for anyone else having to maintain it massive.

(2) Standardization.

Yep good point. But MFC has been around for at least as long as STL and in some compilers (ok mainly microsoft) longer so it's about as close to standard as you can get. So I would argue if you're not looking at cross platform support then MFC is just as standard as STL to the Windows programmer.

(3) Yep I'm a senior programmer, and no I still don't like STL.

Look, it's just my personal preference as I have said here before so I don't expect flames.

Not being able to debug STL (or rather track down memory leaks) is a major disadvantage in my opinion. This is because DEBUG_NEW doesn't work with STL.

However, I just don't like the way it LOOKS. All the templated <> blah blah make the code look really messy. And I can't tidy this up easily by inheriting from stl classes to make them more readable.

Someone has said that inheritance is a bad thing. Why is it in object oriented design then ??!! Actually its a very fundamental part of object oriented design. Are you saying that the C++ standard is wrong now ?

In actual fact my opinion is that its really nice we're having this discussion at all. The fact that C++ is so flexible (ok not particularly type safe) that we can choose which way we prefer to do things is lovely. So long as we adhere to good design and implementation standards the sky's the limit. And we can do this either with STL or MFC and both methods are equally as valid.

Darwen.

Quote:

---

Originally posted by oktronic
Most of us senior programmers are, Paul. This might comes as a shock, but C came before C++. There were a whole bunch of languages before C++ surprisingly....

---

I'm not talking about the language, but the mindset. Most C programmers who do not know to use C++ properly bring over the C coding habits. This can lead to disastrous results.

Quote:

---

Nothing personal, but I kind of doubt this...maybe 10

---

Hmm. You doubt my experience -- I guess this is your tactic to try and bolster your argument.

Quote:

---

...besides the most obvious reason that STL isn't that old and wasn't used in a commercial compiler until mid to late 90's, there is this:

---

I said I have been programming for 20 years. Please read carefully.

Quote:

---

You see Paul, every professional C programmer when they migrated to C++, and I stretch the term migrated, took their existing code and libraries and converted it to be object orientated...well, those of us who liked the idea of C++ anyways.... So we programmers, who have actually programmed for 20 years+, would have converted or kept our existing C or C++ containers...why? Because what works, works...there's no need to take a class which is new and replace bug free, fully functional code that has withstood the test of time....many companies wouldn't even allow C++ when it came out to be used for this very reason...

---

Well, many companies have thrown away their old code with the full knowledge that the standard classes today are fully functional, debugged, standard, and yes, dare I say, superior to what was done previously. When C++ first came around, there were no standard classes, so I can see where the need to create your own needed to be done. Now that is no longer the case.

Quote:

---

This is another example of what I was talking about above about the inexperience.
In my experience as an employee and as a consultant, companies prefer non-dependant code to SDK libraries

---

The STL is not an SDK library, it is part of the language library. Why do you still insist that STL is something external, when it is part of the core language library? Again, do you consider the stdio functions, the C-string functions, the C time and date functions, etc. "SDK libraries"? If not, why not? Do you consider <complex> and <iostream> part of the language library, or an "SDK library"? Neither are STL. I think you are confused.

Quote:

---

that are subject to change

---

Maybe you are confused. First, I'm strictly talking about the STL language library, already standardised by ANSI. I am not talking about MFC or any other GUI library that are not standardized.

Quote:

---

Generally when you supply your own code to a project, a company, when you leave, will buy the rights, if you have any, or purchase use of your code for a nice fee.

---

When I supply my code to a project, if it contains home-made code that is already been done via the standard library, I get the code thrown back at me to fix it.

Quote:

---

I've held many contracts in my hand that do not allow the use of STL or MFC, since both are subject to change.

---

For STL, it is already standardized by ANSI. I can't believe you are stating what you stating when it comes to STL. Come to think of it, I can't believe you're saying this about MFC.

Quote:

---

At some point the program will need to be compiled again, or MFC will change and then a new bug may be introduced into the system. When your program is required to run for years with out any problem at all, which is the work I do the most, you can not afford the liability of code stopping to work because of an update

---

Total nonsense. Again STL is standardized by ANSI.

Quote:

---

First, there are no algorithm classes, they're all template functions, so unless you are talking about something else then the STL algorithm functions, I'm confused....and if you are talking about the functions, then your statement loses weight.

---

OK. The algorithm functions. What do you have to say about them?

Quote:

---

a) well designed code doesn't require maintenance.

---

Incredible. So this is the way you prove your argument -- pretend that maintenance doesn't exist?

Quote:

---

b) if you have to train a C++ programmer to read C++, C, or function documentation, then you've hired the wrong guy.

---

No. The programmer is not just "reading C++". They need to understand what the internals of your code is doing. If there is a change to be made, you are compromising the code that has already been written every time a line is removed or added. This is the reason to use standard components.

Quote:

---

c) you mean thousands of buggy college programs?

---

Again, using the "demean the implementation" argument to prove your point. I am currently maintaining various commercial libraries, and commercial systems that make heavy use of the standard libraries. There has yet been a bug attributed to the usage of the standard libraries.

Quote:

---

d) MSDN does have documentation, its hardly understandable for even the average C++ programmer. Sadly, the technical writer and the programmers who explained it didn't quite understand it, so they used a lot of the original documentation, which is why MSDN is so vague, the original writers didn’t think it would go far enough to need further explanation. That’s why it reads like R&D notes.

---

You rely on MSDN? How about books? "The C++ Standard Library" by Nicolai Josuttis, for example.

Quote:

---

Guess you never opened one of the header files....

---

I don't know what you're talking about. Are you saying that the programmers who designed the standard libraries are fly-by-night programmers? Just this statement alone invalidates everything you've said so far.

Regards,

Paul McKenzie

Quote:

---

Originally posted by souldog
Well I haven't even been programming for a year and a half and
I have enough sense to know what you are saying is BS.

---

Hopefully, you are referring to oktronic's hilarious diatribe against the C++ library.

Quote:

---

Standardization

---

Yes, that's the main point. The current C++ library is standardized as of 1998. It isn't going to change in terms of breaking existing code. If anything, features and more classes / functions are being added, and they will be up for standardization at the next ANSI/ISO committee meeting (I believe this is next year).

But it is interesting that oktronic and others who think like that never doubt that the C-function library may have a bug or be "poorly written" -- they use these functions all the time without a second thought. Their bias is always against the C++ classes and functions.

Regards,

Paul McKenzie

I could not resist joining the discussion :)

Paul does have a point indeed.

I guess, this discussion went into a bit 'personal' mode, though as of what oktronic said, true is that standard headers _are_ sometimes sloppy (e.g., the worst C++ code I ever saw is Windows XP DDK).

Apparently, Microsoft has developed its own programming language called "C++", which includes Hungarian notation, custom types (LPVOID, LPCSTR, BOOL), dummy macros (IN, OUT).

STL way of thinking is not compatible to Microsoft's, so I guess MFC programmers get mad each time they do not see class name beginning with capital C.

STL library was awaited for quite a long time, and was included in the standard in 1998.

Apparently, mixing STL and MFC doesn't give a good result. Though I do it all the time, as I find easier to use STL than digging MSDN (which indeed IS the worst kind of a documentation) to seek what exactly did MS developers mean.

Those who do not like C++, normally should go programming Oberon.

Oberon resembles Pascal, while being totally different in the conception. It is interesting topic to study and discuss, indeed as for present time (2003) it is still inapplicable for the serious tasks.

There are two interesting articles said "Oberon vs C++" and "Oberon2 vs C++".

http://www.modulaware.com/mdlt49.htm
http://www.amadeus-3.com/main_files/oberon2vsCPP.php

Don't bash me, I'm myself a hardcore C++ programmer, but take a look anyway. :)

Thanks,
George.

There is a syndrome called "NIH" (Not Invented Here). Check out this page -- it describes to a tee the mindset of some programmers who are afraid or do not use standard components.

http://c2.com/cgi/wiki?NotInventedHere

Regards,

Paul McKenzie

I've seen it written here by both proponents and opponents of the STL alike, that STL classes aren't supposed to be derived. The proponents of STL see this as an asset, and the opponents, a liability.

I've used MFC a lot, and STL a little, and I've recently written an application which is going to be portable to other OS's so I did the entire back end of the application in STL.

Now, I don't have a lot of experience in STL yet (but I like it), maybe it's my straight-C mindset, and/or maybe I'm nuts, but I did, in fact, derive several of my classes from STL containers. I've never before heard that this is a Bad Thing.

I don't seem to have any problems with this. Everything works as it should. And there are no bugs or leaks or whatever.

Basically what I did was:

Code:

---

class string_vector : public vector< mystring >
{
public:
    string_vector() {}
    string_vector( const string_vector& sv ) { ... }
    virtual ~string_vector() {}

    string_vector operator=( const string_vector& sv ) {...}
    string_vector operator += ( mystring str ) { ... }

    load( ifstream& in ) { ... }
    save( oftream& out ) { ... }

};

---

And it works.

It works like a champ.

The load and save functions are the reason I derived the class - I wanted to add serializable functionality to my vector class. And I derived several classes from vector<> which provides various functionalities. (I could have templatized my class, I suppose, but that's beside the point).

It seems like everyone on both sides of the fence do agree that this is not the proper usage of STL.


Why? Is it just bad form? Is there something deeper that I'm missing? I'm not having any problems, and I don't expect to.