|
have you tried to understand mine ?
it is not because you create your own control (which is GUI part here, i conceed) that everything you do goes to that layer... maybe there are so internal treatment whih have nothing to do with rendering.
moreover, know that CMap and CArray are crap !
ps: thank you for the rate 
TOXCCT >>> GEII power
[toxcct][VisualCalc 2.20][VCalc 3.0 soon...]
|
|
|
|
|
toxcct wrote: have you tried to understand mine ?
Yes, but the question was not STL or MFC for portability, the topic is STL in MFC projects.
If my project makes usage of MFC it's not portable anymore, no matter if my container classes are portable or not.
Therefore you whole post has nothing to do with the topic.
|
|
|
|
|
Good grief. Just because you're using MFC doesn't mean you have to its inferior container classes! I use STL containers in all my MFC projects because it gets the job done faster and with less code than the MFC equivalents.
|
|
|
|
|
ABuenger wrote: If my project makes usage of MFC it's not portable anymore
yes
ABuenger wrote: no matter if my container classes are portable or not.
no.
consider the case where you do a general treatment on datas in background... these treatments have nothing to know about the GUI, whether it is mfc, owl, etc...
if you don't care about what I say, let it down. if however, you still want to understand my reasons to answer so, have a look a my VisualCalc article. you will - i hope for you - understand that i can easily interchange the user interface depending on the plateform i target my project.
so, of course MFC is not portable further than windows, but in my case, ONLY the GUI is not portable, so, i don't have to rewrite my whole code. so, i believe that's why STL is used so much... portability is an important point in software development industry, especially when you have to code very fast...
TOXCCT >>> GEII power
[toxcct][VisualCalc 2.20][VCalc 3.0 soon...]
|
|
|
|
|
toxcct wrote: consider the case where you do a general treatment on datas in background... these treatments have nothing to know about the GUI, whether it is mfc, owl, etc...
if you don't care about what I say, let it down. if however, you still want to understand my reasons to answer so, have a look a my VisualCalc article. you will - i hope for you - understand that i can easily interchange the user interface depending on the plateform i target my project.
so, of course MFC is not portable further than windows, but in my case, ONLY the GUI is not portable, so, i don't have to rewrite my whole code. so, i believe that's why STL is used so much... portability is an important point in software development industry, especially when you have to code very fast...
Ok, in that case it makes sense to use STL. But i am talking about custom MFC controls which will never be ported and aree just standalone MFC extensions.
For example CPPTooltip and CTreePropSheetEx on Code Project. These controls will never be portable, and if i derive a control from a MFC class it doesn't make sense to have a STL map in my class.
|
|
|
|
|
can you be a little more polite? 
VuNic
|
|
|
|
|
VuNic wrote: can you be a little more polite?
Same Here!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
ABuenger wrote: Are there any reasons to use the STL in a MFC project?
Many folks are opposed to the container classes in MFC.
"The greatest good you can do for another is not just to share your riches but to reveal to him his own." - Benjamin Disraeli
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
