current community

your communities

more stack exchange communities

Stack Exchange
tour help
careers 2.0
Take the 2-minute tour ×
Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.
up vote 7 down vote favorite

Using C++ with MFC. Coming from a C# background I typically just use string for all, well, strings. I use them for class members, method parameters, and method return values.

Now in C++ I've got std::string, CString, char *, LPCTSTR, and more. As I design my data members, method parameters, and method return values which type(s) should I be using? Ease of use is important and CString seems to offer that but my instinct is toward portable standards although portability is pretty low on my list of priorities (now). Also, I don't like the c semantics of creating string buffers and passing them into methods and functions.

I think from an immediate ease of coding perspective CStrings probably have the edge. But, overall, what is the "high code quality" way to do this?

EDIT:

I'm especially concerned about the interface points in my code (i.e. method parameters and return values). E.g.:

Shape::SetCaption(const char *caption) {...}

Shape::SetCaption(CString caption) {...}

Shape::SetCaption(std::string caption) {...}

Shape::SetCaption(std::wstring caption) {...}
share|improve this question
2  
How can somebody migrate from C#/.NET to MFC, are you a masochist? Not that I'm a fan of .NET, but MFC is the complete opposite regarding useability and flexibility. If you want to do GUI with C++, consider using Qt. Sorry for the off-topic comment. –  Christian Rau May 24 '11 at 23:17
 
@Christian: Writing a plugin for a platform that is implemented in MFC and must integrate tightly with it. I tried to go down the Qt path but Qt/MFC integration was an uphill battle. If it were an option I would choose C#. –  User May 24 '11 at 23:24
add comment

4 Answers

up vote 7 down vote accepted

I usually prefer to adapt my coding style to the framework I'm working in to be consistent with it. So when I work with MFC (which i haven't for a long time), I prefer the use of CString (and LPCTSTR as function arguments in public interface methods). When working with Qt I prefer QString and Qt's containers over STL containers and for everything not directly related to such a framework I use std::string as it's the standard C++ way of handling strings.

It doesn't make such a huge difference, since they all offer more or less equal functionality (and are easily convertible into each other) and when code is written for a certain framework, it depends on it anyway, so portability is not such a huge concern.

Just don't bother with plain char arrays! And by the way, try to pass objects by const reference (const std::string &caption) and not by value, as in C++ variables are not automatically references and copying a string can get quite expensive.

share|improve this answer
 
I sometimes use plain char arrays when I need a temporary buffer for something, although I've had good luck with vector<char> too. –  Mark Ransom May 24 '11 at 22:46
 
Makes sense, but would you use CString even in a static library you build to be used by your MFC project? –  User Jun 3 '11 at 20:33
 
@User If the library itself doesn't use or depend on MFC and could possibly be used with another project, then definitely not. But if it is bound to your project anyway, I'm not quite sure. I would use std::string in everything not directly realted to MFC for better code reuse and flexibility. –  Christian Rau Jun 4 '11 at 11:50
add comment
up vote 5 down vote

MFC was written with the expectation that you'd use CString. This is especially apparent when a function uses a parameter to return a string. For example, compare these two calls to GetWindowText:

CString s1;
wnd.GetWindowText(s1);

std::wstring s2(SOME_MAX, 0);
int len = wnd.GetWindowText(&s2[0], s2.size());
s2.resize(len);

Converting between the two isn't bad though, so you might compromise by using std::wstring for most things and a temporary CString when necessary.

CString s3 = s2.c_str();
std::wstring s4 = s1;

Edit: There may be a way to automate the temporary CString. Fair warning, this is a complete hack. I haven't tried this, so no guarantees - you'll probably get warnings about binding a temporary to a non-const reference, but you can turn those off.

class PopString : public CString
{
public:
    PopString(std::wstring & final) : m_final(final)
    {
    }

    ~PopString()
    {
        m_final = (PCTSTR) *this;
    }
private:
    PopString(const PopString &) {}  // private copy constructor to prevent copying
    PopString & operator=(const PopString &) {}  // private copy operator

    std::wstring & m_final;
};

std::wstring s5;
wnd.GetWindowText(PopString(s5));
share|improve this answer
add comment
up vote 2 down vote

If you care for portability and you're using C++ use std::string. No point going low-level with char arrays if you don't need to. If you don't care for portability and the platform-provided strings provide more of the features you need, by all means, use them. They might actually be more optimized for the platform.

share|improve this answer
1  
Technically, use std::basic_string<>, not just std::string. I.e., on Windows it's much more likely that std::wstring is desired. –  ildjarn May 24 '11 at 21:50
 
@ildjarn, did you mean to say std::basic_string<TCHAR>? –  Mark Ransom May 24 '11 at 22:33
 
@MarkRansom : No, I meant the std::basic_string<> class template as a whole, as opposed to the std::basic_string<char> specialization (a.k.a. std::string) specifically. –  ildjarn May 24 '11 at 22:35
4  
"Portable" + "mfc" = oxymoron –  John Dibling May 24 '11 at 23:10
add comment
up vote 2 down vote

Do not use CString. It uses a COW implementation which is very vulnerable to things like threading. Do not use char* or LPCTSTR (which is just const char* or const wchar_t* under a different name), as they do not manage their own memory. Use a std::string for 8-bit codepoints or std::wstring for 16-bit codepoints on Windows (32bit for Unix).

share|improve this answer
 
It's LPCTSTR, and char const* or wchar_t const* respectively. –  ildjarn May 24 '11 at 23:03
4  
Its not like std string is threadsafe. But -1 because when using mfc CString is usually the way to go. –  John Dibling May 24 '11 at 23:12
2  
@John Dibling: std::string is thread-safe in a way that CString isn't. If you have two independent std::string, you can guarantee that they're safe to use on two threads. The same cannot be said of CString. –  DeadMG May 25 '11 at 9:01
 
@DeadMG I thought, that's what you cannot guarantee, as STL implementers are free to use implicit sharing for strings. But I've heard the new C++0x standard removes this freedom and therefore guarantees really threadsafe std::strings. –  Christian Rau May 25 '11 at 16:45
 
@ChristianRau : The problem is only fixed officially, in the standard, as of C++11, but the problem was formally acknowledged in Defect Report 530 over five years ago and has been implemented in every major standard library implementation since then (if not earlier). –  ildjarn May 26 '11 at 7:14
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.