|
ABuenger wrote: There is an other reason not to use STL, it's not available for many CE devices.
True, but when I target CE, I wouldn't use bloated MFC either. My last PocketPC app was written in ATL/WTL. The less dependencies the better when it comes to CE.
|
|
|
|
|
Robert Edward Caldecott wrote: True, but when I target CE, I wouldn't use bloated MFC either.
But that bloated MFC dll is already pre-installed on the target 
The topic is also not "Should i use ATL/WTL or MFC for my CE project". I just don't understand why people use STL in MFC projects when there is no need to do so.
If i only want to map a string to an object, CMap handles this very well.
|
|
|
|
|
ABuenger wrote: But that bloated MFC dll is already pre-installed on the target
Not if you're using VS 2005 it isn't (MFC8)!
|
|
|
|
|
ABuenger wrote: There is an other reason not to use STL, it's not available for many CE devices.
are you on drugs ?
STL is provided with any C++ compilers !!! that's what i expect from a "standard library" of any language 
TOXCCT >>> GEII power
[toxcct][VisualCalc 2.20][VCalc 3.0 soon...]
|
|
|
|
|
toxcct wrote: are you on drugs ?
STL is provided with any C++ compilers !!! that's what i expect from a "standard library" of any language
Ever tried to compile a project that uses STL with eVC 3.0 or eVC 4.0?
|
|
|
|
|
> Ever tried to compile a project that uses STL with eVC 3.0 or eVC 4.0?
I'm not sure if you're trolling or not, but I've been using STL in my current eVC 3.0 project since 2002. MS does not ship one with the compiler, but there's plenty to choose from, with varying degree of support for the standard library, ie Dinkumware's unabridged library.
I believe eVC4 ships with a version of the standard library, so I guess you haven't tried it either.
---
"Man will never be free until the last king is strangled with the entrails of the last priest". -- Denis Diderot
|
|
|
|
|
Jonas Larsson wrote: I'm not sure if you're trolling or not, but I've been using STL in my current eVC 3.0 project since 2002. MS does not ship one with the compiler, but there's plenty to choose from, with varying degree of support for the standard library, ie Dinkumware's unabridged library.
I believe eVC4 ships with a version of the standard library, so I guess you haven't tried it either.
eVC 3.0 does not ship with STL, eVC 4.0 has also not a full implementation of the STL. And Dinkumware's unabridged library is not free. And i haven't found a 100% standard implementation of the STL which is free for the eVC.
|
|
|
|
|
STL containers are MUCH more flexible than the MFC equivalents, primarily because:
* Iterators are more flexible than POSITIONs. Once you have the iterator, you have direct access to the value - no messing about with the CList GetNext/GetPrev functions.
* STL containers can be used with powerful STL functions (the humble std::sort for example). How would you sort a CArray for example? There is no CArray::Sort method. I also like using for_each with a function object to iterate through a container, processing each entry.
* STL comes with some other, very useful templates - I use std::pair a lot (often a container of pairs).
I think that many C++ programmers use MFC containers because they don't know STL very well. 
|
|
|
|
|
Robert Edward Caldecott wrote: I think that many C++ programmers use MFC containers because they don't know STL very well.
My opinion exactly. Maybe because I was using MFC containers only before I learned STL
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
So was I, and I got sick of writing code to sort CArrays! Plus I want more portable code, and I probably won't be on the Windows teat forever...
|
|
|
|
|
Robert Edward Caldecott wrote:
So was I, and I got sick of writing code to sort CArrays!
qsort() was not doing it for you?
"The greatest good you can do for another is not just to share your riches but to reveal to him his own." - Benjamin Disraeli
|
|
|
|
|
Nope - not when I wanted to sort a CArray of custom objects, where the sort key is a member variable of said object. Making qsort work with CArrays is asking for trouble IMHO - it relies on how the MFC CArray is implemented internally, and it feels like a hack. The std::sort doesn't have this problem.
|
|
|
|
|
Robert Edward Caldecott wrote:
Nope - not when I wanted to sort a CArray of custom objects, where the sort key is a member variable of said object.
How would that stipulation make it not work?
Robert Edward Caldecott wrote: Making qsort work with CArrays is asking for trouble IMHO - it relies on how the MFC CArray is implemented internally, and it feels like a hack.
Since CArray has not changed since its creation, I'm not sure a "hack" is a fair representation. Doesn't std::sort() also require a comparison routine?
"The greatest good you can do for another is not just to share your riches but to reveal to him his own." - Benjamin Disraeli
|
|
|
|
|
Robert Edward Caldecott wrote: Iterators are more flexible than POSITIONs. Once you have the iterator, you have direct access to the value - no messing about with the CList GetNext/GetPrev functions.
How is an iterator more flexible than the methods of the MFC container classes? Do you really like the it->second syntax?
Robert Edward Caldecott wrote: STL containers can be used with powerful STL functions (the humble std::sort for example). How would you sort a CArray for example? There is no CArray::Sort method. I also like using for_each with a function object to iterate through a container, processing each entry.
You can sort a CArray easily with qsort. qsort is already in the C-Runtime, so no need for an other library to do the same job.
Robert Edward Caldecott wrote: I think that many C++ programmers use MFC containers because they don't know STL very well.
That may be true, but if you have the MFC containers, why should you bother with an other set of containers? Or do you think a .net programmer would use MFC classes in his app if he could?
|
|
|
|
|
ABuenger wrote: How is an iterator more flexible than the methods of the MFC container classes? Do you really like the it->second syntax?
Yes, I do. It is much nicer than GetNext/GetPrev! The whole iterator idea is inspired.
ABuenger wrote: You can sort a CArray easily with qsort. qsort is already in the C-Runtime, so no need for an other library to do the same job.
Actually, you are relying on how a CArray works internally for qsort to work - if MS ever changes the internal representation of CArray, you're in trouble. Also, how about a custom sort? What if you have a CArray of custom classes and you want to sort on one member in particular? Easy in STL, not so using qsort. One reason I first looked at STL containers was because I was sick of writing custom sort handlers for different sorts of CArrays.
ABuenger wrote: but if you have the MFC containers, why should you bother with an other set of containers?
Because STL containers are better. Using the right tools for the job is surely the best way to code is it not?
|
|
|
|
|
Robert Edward Caldecott wrote: ABuenger wrote:
You can sort a CArray easily with qsort. qsort is already in the C-Runtime, so no need for an other library to do the same job.
Actually, you are relying on how a CArray works internally for qsort to work - if MS ever changes the internal representation of CArray, you're in trouble. Also, how about a custom sort? What if you have a CArray of custom classes and you want to sort on one member in particular? Easy in STL, not so using qsort
Also, std::sort is much faster[^] than qsort, and typesafe.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
ABuenger wrote: why should i bloat my executable with an other library?
I don't think that the STL is located in a Lib, since all code is in a header file which is included in your application (at least anly the classes/functions that are called/needed).
Whereas the CMap and the other MFC variants are located in a lib hence need to be loaded through a dll at startup. Therefore resulting in a larger memory footprint.
BTW... I use both so don't shoot me
codito ergo sum
|
|
|
|
|
BadKarma wrote: I don't think that the STL is located in a Lib, since all code is in a header file which is included in your application (at least anly the classes/functions that are called/needed).
The STL activates RTTI, expects exception handling to be active and its iterators are not always properly inlined by compilers.
That bloats the code by 50%.
|
|
|
|
|
ABuenger wrote: That bloats the code by 50%
Do you have an example of this "50%" bloat?
|
|
|
|
|
BTW, I just built an MFC app (statically linked) that using a CList/CArray and a std::vector/std::list - without STL the EXE is 308KB. With STL it is 308KB. No RTTI. No exception handling. And certainly no 50% code bloat - where _did_ you get that figure?
|
|
|
|
|
Just focusing on the containers alone when rating the STL architecture is to miss the most important aspect of STL - The separation of the containers from the algorithms which operate on them via the use of iterators. This is an extremely powerful concept. It's in a different league to the MFC container architecture in this respect. For example you can use the std::binary_search algorithm on std::vector, std::deque or even a plain C array. In short, STL kicks ass!
Steve
|
|
|
|
|
|
ABuenger wrote: Everytime i wonder why someone do this, there are equivalent classes in the MFC.
There are *some* equivalent classes, but nowhere near STL. More importantly, there is no equivalent for STL algorithms. Finally, many 3rd party libraries (Boost, for instance, but also WinSTL[^]) are designed to work with STL.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
IMO the only reason to use the MFC containers is so you can get ASSERTs in the debug version. But the performance is superior with STL...
Now it is clear that there is a snobbery about the use of STL: it is really easy to make something very powerful in 2 lines... but absolutely undecypherable - not sure about the spelling there  . But that's a C tradition!
And yes (as stated above) the implementation of CMap is poor. And I could be wrong, but I seem to remember that when you iterate thorugh a map, the values are not sorted...
|
|
|
|
|
BadJerry wrote: And yes (as stated above) the implementation of CMap is poor. And I could be wrong, but I seem to remember that when you iterate thorugh a map, the values are not sorted...
CMap is based on a hash, not a sort. While it's possible, what would be a reason for iterating a CMap object? I've only ever used them to store and lookup items based on a key.
"The greatest good you can do for another is not just to share your riches but to reveal to him his own." - Benjamin Disraeli
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
