What I mean if you are coding for Windows desktop applications (such as an MFC app) and never need to code for cross platform, then CString provides benefits over std::string or std::wstring.
[...]
Only rely on third party libraries, like MFC and ATL, when you absolutely have to and then use them as little as you absolutely can.
[...]
"Third party"? Prefer saying MFC and ATL are C++ wrapper libraries over native Windows API.
Originally Posted by tiliavirga
[...]
My advice is general. Always prefer standard C++.
Probably, in a parallel world and a future life, we'll have a standard C++ supporting all native OS's stuff.
Most of complex applications deal with native. E.g. the better way to keep settings in Windows is to use registry while Mac OS X applications use p-lists. User experience on Mac is pretty different to user experience on Windows. That means, prefer writing the GUI part for Windows using MFC/ATL/WTL and for Mac OSX using Cocoa framework.
Of course, can and it's good to isolate a cross-platform part of the project (e.g. the communication module) which can be written in "pure" standard C++, completing with boost stuff where necessary.
My advice based on some experience in desktop applications targeting multiple platforms is:
write platform-independent part using cross-patform code (STL and boost);
write platform-dependent part (user interface, system specific, etc) using native frameworks.
isolate as much as possible the code from #1 and #2; do not mix them.
Returning to our sheep and copleting what Arjay already said: once a given code uses MFC/ATL is preferable to use CString and not std::string/std::wstring inside it, as well as if uses Cocoa is preferable to deal with Cocoa's NSString.
See also the quote from my signature.
Last edited by ovidiucucu; November 14th, 2015 at 07:55 AM.
A much better solution is to always use standard C++ as much as possible.
Only rely on third party libraries, like MFC and ATL, when you absolutely have to and then use them as little as you absolutely can.
I know my suggestion comes too late for many who have already fallen into the honey trap and they may benefit from your suggestion of course.
This is a Visual Studio forum and MFC is part of Visual Studio. I'd hate to have to write a Windows app without MFC. MFC has been around for 20 years or so, and is very reliable. For many of us, multi-platform or multi-character set code just isn't an issue that's ever going to come up.
It turns out I celebrated too early, now I made my own expierence with it. The pitfall is that it works f you use it inside a data structure like
struct MyStruct
{
CString cstr;
}
but as soon as CString is used as a function parameter, then the linker suffers indigestion
On the other hand I remembered, that I have an application (incomplete and frozen for a while) that uses CString exactly in this manner, so it may require further invistigation
Last edited by Prandr; December 21st, 2015 at 04:17 PM.
but as soon as CString is used as a function parameter, then the linker suffers indigestion
You may use CString inside your library, but you must not let it in or out of the one. Use LPCTSTR in function prototypes and take care of underlaying CString lifecycle.
Last edited by Igor Vartanov; December 22nd, 2015 at 06:48 AM.
* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.