STL string VS ATL/MFC string

[heyrung]

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?

[Paul McKenzie]

There have been plenty of threads on this. Here is just one:

http://www.codeguru.com/forum/showthread.php?t=319932

Regards,

Paul McKenzie

[Eri523]

There have been plenty of threads on this. Here is just one:

[...]

Yes, and already post #3 from the thread you linked to (from 2004!) states:

And please do a search.. There have been oodles of threads about this in the past.

[Lindley]

std::string is standard. Unless you have some particular reason to do otherwise, it's always better to stick with the standard library.

[VictorN]

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)

[Igor Vartanov]

It always depends...

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.

std::string is standard.

...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.

[D_Drmmr]

Unless project heavily depends on STL

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.

[Igor Vartanov]

the last project I worked on that did not use STL in pretty much every compilation unit, was when I was learning C++

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 )

[Arjay]

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.

CString sPath;
GetModuleFileName( NULL, sPath.GetBuffer( MAX_PATH ), MAX_PATH );
sPath.ReleaseBuffer( );

It also is ANSI/UNICODE aware so you don't need to spend time with conversions.

[Lindley]

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 )

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.

I unfortunately have met too many "programmers" who flinch at the first sign of a functor, though, and that's just not helpful.

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.

CString sPath;
GetModuleFileName( NULL, sPath.GetBuffer( MAX_PATH ), MAX_PATH );
sPath.ReleaseBuffer( );

It also is ANSI/UNICODE aware so you don't need to spend time with conversions.

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.

[Arjay]

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.

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.

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

#include <atlstr.h>

[superbonzo]

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.

note that with the new standard std::string stores chars contiguously, so this issue has been at least mitigated now.