CString class in non-MFC static library

Quote:

---

Originally Posted by Arjay

I think if you are only targeting windows

---

What do you mean by that?

My advice is general. Always prefer standard C++.

Quote:

---

Originally Posted by tiliavirga

What do you mean by that?

My advice is general. Always prefer standard C++.

---

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.

Quote:

---

Originally Posted by tiliavirga

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

Quote:

---

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:

1. write platform-independent part using cross-patform code (STL and boost);
2. write platform-dependent part (user interface, system specific, etc) using native frameworks.
3. 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. :)

Quote:

---

Originally Posted by tiliavirga

My advice is general. Always prefer standard C++.

---

I always am afraid of general advices. In their most those are useless.

Quote:

---

Originally Posted by tiliavirga

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.

"MFC has been around for 20 years or so, and is very reliable".
Totally agree !

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;
}

...somewhere else:
MyStruct ms;
ms.cstr=_T("Hello");//OK

but as soon as CString is used as a function parameter, then the linker suffers indigestion:D

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

Quote:

---

Originally Posted by Prandr

but as soon as CString is used as a function parameter, then the linker suffers indigestion:D

---

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.