|
DavidCrow wrote: Many folks are opposed to the container classes in MFC.
But why? The implementation is better than the STL in my eyes. And if i already use a framework which has container classes, why should i bloat my executable with an other library?
To me it seems like many C++ programmers don't know the MFC very well (see above post) and therefore use the STL.
|
|
|
|
|
ABuenger wrote: The implementation is better than the STL in my eyes
At this level, it is personal tastes, IMO. But I really prefer STL's.
ABuenger wrote: To me it seems like many C++ programmers don't know the MFC very well (see above post) and therefore use the STL.
I think you do not know the STL very well then, and therefor stick to the slow and not so practical MFC containers... 
~RaGE();
|
|
|
|
|
Rage wrote: At this level, it is personal tastes, IMO. But I really prefer STL's.
Ok, at the end both container classes makes the same. Also STL is not STL, there are many different implementations. IMO at least the STL that ships with VC6 isn't as good as the MFC container classes.
But that's personal taste.
I just don't like it if libraries are used mixed.
|
|
|
|
|
It is true that the STL that ships with VC6 is rubbish. However, you can rectify this by downloading STLPort - it's free and the implementation is very highly praised.
If you are sticking to one library because you don't want to "mix" code, then you are, in my opinion, shooting yourself in the foot. Really, what difference does it make? A few extra KB on your EXE? Big deal!
|
|
|
|
|
Robert Edward Caldecott wrote: It is true that the STL that ships with VC6 is rubbish. However, you can rectify this by downloading STLPort - it's free and the implementation is very highly praised.
There is an other reason not to use STL, it's not available for many CE devices.
Robert Edward Caldecott wrote: If you are sticking to one library because you don't want to "mix" code, then you are, in my opinion, shooting yourself in the foot. Really, what difference does it make? A few extra KB on your EXE? Big deal!
It makes the code more readable if i stick to one library. Also there is often a performance penality. std::string -> char* -> CString conversions are pretty common.
Please also read this post: http://www.codeproject.com/script/comments/forums.asp?forumid=1647&select=1369083&df=100&fr=13.5#xx1369083xx[^]
|
|
|
|
|
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?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
