when do you choose to use STL string and when do you choose to use ATL or MFC string? What's the pro's and con's of STL and ATL/MFC String?
Printable View
when do you choose to use STL string and when do you choose to use ATL or MFC string? What's the pro's and con's of STL and ATL/MFC String?
There have been plenty of threads on this. Here is just one:
http://www.codeguru.com/forum/showthread.php?t=319932
Regards,
Paul McKenzie
Yes, and already post #3 from the thread you linked to (from 2004!) states:Quote:
Originally Posted by Paul McKenzie
:cool:Quote:
Originally Posted by wien
std::string is standard. Unless you have some particular reason to do otherwise, it's always better to stick with the standard library.
It always depends...
If working with MFC application then IMHO using CString is better (more easy and convenient for MFC classes and Windows API as well)
Very true. Even with plain Win API I prefer to deal with ATL::CString. Unless project heavily depends on STL, or there is a direct requirement on the project to use std:string strings.Quote:
It always depends...
...which really matters for contemporary cross-platform projects. In its turn, CString strings had been considered "standard-like" in Windows world long before STL became a standard.Quote:
std::string is standard.
Not sure how you qualify heavily, but the last project I worked on that did not use STL in pretty much every compilation unit, was when I was learning C++ and nobody had bothered to teach me about STL yet. ;)Quote:
Originally Posted by Igor Vartanov
Well then you gonna be surprised about how other teams are still able to ignore STL stuff and rely on their own/third party experience/libraries. Because of lots of reasons I really respect. :) (You know, the word 'standard' never made me thrill :D)Quote:
the last project I worked on that did not use STL in pretty much every compilation unit, was when I was learning C++
For one thing, if you aren't stuck on using VC6, ATL::CString and MFC::CString are one and the same.
If you are coding in Windows and aren't concerned about cross platform compatibility, use CString. Why? because it has additional methods and constructors that are useful on Windows.
For example, CString has GetBuffer.
It also is ANSI/UNICODE aware so you don't need to spend time with conversions.Code:CString sPath;
GetModuleFileName( NULL, sPath.GetBuffer( MAX_PATH ), MAX_PATH );
sPath.ReleaseBuffer( );
If they have a really good toolset which is well-known by the team, then that's cool. Everyone develops their own toolset as they go if they're smart.Quote:
Originally Posted by Igor Vartanov
I unfortunately have met too many "programmers" who flinch at the first sign of a functor, though, and that's just not helpful.
Personally I find UTF-8 a lot more intuitive to deal with than UTF-16, and std::string is good enough for that. The stuff with GetBuffer can of course be done with std::vector<char>, although I'll grant it would be nice if it were available in the std::string class.Quote:
Originally Posted by Arjay
The nice thing about CString is that it automatically handles ANSI and UNICODE when calling Windows api's, whereas std::string doesn't work so well when building in unicode. There are other methods that are helpful too like the BSTR methods when working with COM.Quote:
Originally Posted by Lindley
Many folks mistakenly tie CString to MFC and think they need to include MFC dlls.
This hasn't been the case in quite a while. All that is needed now is
Code:#include <atlstr.h>
note that with the new standard std::string stores chars contiguously, so this issue has been at least mitigated now.Quote:
Originally Posted by Lindley