Member Functions with Generic Parameters

Someone wanted to write a C++ class member function to operate on a generic container.

His thought process was: “Since in C++14 we can use auto with lambda parameters, why not using it also for class method parameters?

class MyClass {

  // DOESN’T work in C++14!!
  void DoSomething(auto& container) {

Unfortunately, this code doesn’t compile. In fact, in C++14 “auto” is not a valid parameter type for member functions.

Visual Studio 2015 emits the following error:

error C3533: a parameter cannot have a type that contains ‘auto’

To fix that code, we can use templates. The member function with an “auto” parameter can be written as a member function template:

class MyClass {

  // Simulate:
  //   void DoSomething(auto& container)
  // using templates.
  template <typename Container>
  void DoSomething(Container& container) {

Beginner’s Bug: What’s Wrong with Brace-Init and std::vector?

Question: I have some old C++ code that creates a std::vector containing two NUL wchar_ts:

std::vector<wchar_t> v(2, L'\0');

This code works just fine. I tried to modernize it, using C++11’s brace-initialization syntax:

// Braces {} used instead of parentheses () 
// to initialize v
std::vector<wchar_t> v{2, L'\0'};

However, now I have a bug in my new C++ code! In fact, the brace-initialized vector now contains a wchar_t having code 2, and a NUL. But I wanted two NULs! What’s wrong with my code?

Answer: The problem is that the new C++11 brace initialization syntax (more precisely: direct-list-initialization) in this vector case stomps (prevails) on the initialize-with-N-copies-of-X constructor overload that was used in the original code. So, the vector gets initialized with the content of the braced initialization list: {2, L’\0’}, i.e. a wchar_t having code 2, and a NUL.

I’m sorry: to get the expected original behavior you have to stick with the classical C++98 parentheses initialization syntax.


Helper Functions to Manage Double-NUL-Terminated Strings

A double-NUL-terminated string is a data structure used in several places on the Win32 platform.

For example, the Windows registry can store double-NUL-terminated strings using the REG_MULTI_SZ type. As another example, the lpstrFilter of the Win32 OPENFILENAME structure points to a buffer containing double-NUL-terminated strings.

I’ve developed a couple of C++ helper functions to create and parse double-NUL-terminated strings: check them out here on GitHub!


Getting Write Access to CString’s Internal Buffer

In the MSDN Magazine article “Using STL Strings at Win32 API Boundaries”, I discussed how to use std::wstring with Win32 APIs.

Note: The aforementioned article focuses on std::wstring containing Unicode UTF-16 encoded text; if you are interested in how to convert between an UTF-8 std::string and an UTF-16 std::wstring, this other MSDN Magazine article “Unicode Encoding Conversions with STL Strings and Win32 APIs” can come in handy.

But if you are developing (or maintaining) Windows C++ applications using ATL, WTL or MFC, you already have a convenient string class available for use at the Win32 API boundary: CString.

CString is designed in a way to be very well integrated with Win32 APIs. For example, you can simply pass instances of CString to Win32 APIs taking input string pointers; in other words, CString is a drop-in replacement for LPCTSTR parameters.

Moreover, using CString you can easily load strings from resources (via its LoadString method), format strings in a printf-like way using Format, or in a more advanced form using FormatMessage, etc.

Of course std::wstring has other advantages, like SSO (Small String Optimization), move semantics, STL iterator semantics, working with C++11 range-for loops, good integration with Boost, etc.

If you use ATL, WTL or MFC, many Win32 C-interface APIs are wrapped in a convenient object-oriented interface, and you can simply retrieve strings in CString instances (for example, calling a proper overload of CWindow::GetWindowText).

But what if you want to get a string from a Win32 API that isn’t wrapped in a nice way by the existing ATL/WTL/MFC classes?

In this case, you may need to let the Win32 API to scribble its output in the CString’s internal string buffer. With STL’s wstring you can simply call the wstring::resize method to make enough room in the string, and then pass a pointer to that buffer, as described in the aforementioned MSDN Magazine article.

But how can you access CString’s internal buffer for writing?

Well, you can call a couple of methods of the CString class: GetBuffer and ReleaseBuffer. The usage pattern is as follows:

  1. Call CString::GetBuffer to allocate a sufficiently large internal buffer; on success, this method returns a non-const pointer to the allocated buffer, giving you write access to it.
  2. Call the Win32 API (or whatever function) passing the pointer returned by CString::GetBuffer, so the called function can write its result text in the specified buffer.
  3. Call CString::ReleaseBuffer, which releases the access to CString’s internal buffer, so that the CString object can sync its state to the new buffer content.

Note that if the called function writes a NUL-terminator at the end of the string (as most Win32 APIs usually do), you can simply call CString::ReleaseBuffer, without passing any argument. In fact, in this case, the ReleaseBuffer method will simply scan the string stored in the CString’s internal buffer, until it finds the terminating NUL.

In addition, you can specify an explicit string length value to CString::ReleaseBuffer. In this case, the string in the internal buffer will be considered for that exact length.

Note that in Unicode builds those lengths are expressed in wchar_ts (not in bytes!).

This commented C++ sample code shows CString’s GetBuffer and ReleaseBuffer in action:

CString s;

// Allocate an internal buffer for CString, 
// and get write access to it.
const int bufferSize = 100; // in wchar_ts!
wchar_t* buffer = s.GetBuffer(bufferSize);

// Scribble in the CString's internal buffer.
wcscpy_s(buffer, bufferSize, L"Connie");

// Release access to the internal buffer.
// Now the CString object synchronizes its 
// state with the content of its internal 
// buffer.
// NOTE: This assumes that the string 
// in the buffer is *NUL*-terminated!

// Avoid dangling references.
// After calling CString::ReleaseBuffer
// we cannot touch the CString's internal 
// buffer anymore.
buffer = nullptr;

// Let's check if it works!
ATLASSERT(s == L"Connie");

Note that if you explicitly pass a string length to CString::ReleaseBuffer, the string in the internal buffer is truncated at the specified position; e.g. if you call “s.ReleaseBuffer(3);” only the first three characters in the CString’s internal buffer are considered for the final CString’s text, making s == “Con” in the example above.

P.S. Pay attention when you manipulate CString’s internal buffers. For example, note that CString is not designed to store strings with embedded NULs. In fact, as stated in this MSDN documentation web page (emphasis mine):

“Although it is possible to create CStringT instances that contain embedded null characters, we recommend against it. Calling methods and operators on CStringT objects that contain embedded null characters can produce unintended results.


The Unreadable Obscure LPXYSTR Typedefs

If you write Win32 C++ code, you’ll find a lot of unreadable and apparently obscure typedefs for strings, for example: LPCTSTR, LPTSTR, LPCWSTR, etc.

What are those? What do they mean?

The key to understand those apparently obscure (but certainly unreadable!) typedefs is to split their names into smaller parts.

Let’s start with the “decoding” of LPCTSTR:

  • LP means pointer. I think it actually means something like “long pointer”, in a period (16-bit Windows?) when probably there were both “long” (far?) and “short” (near?) pointers, but this predates my experience with the C++ Windows platform, so I just don’t know for sure.
  • C means: const, constant.
  • T means: TCHAR
  • STR means: C-style NUL-terminated string.

So, putting those elements together, an “LPCTSTR” is a “pointer to a read-only (const) NUL-terminated TCHAR string”, i.e. in C and C++ code: “const TCHAR*. You can find LPCTSTR parameters in many Win32 APIs, e.g. in SetWindowText.

Now, to be honest, to me “const TCHAR*” is much more readable than “LPCTSTR”: In fact, using the former, I can clearly see all the composing elements: “const”, “TCHAR”, “pointer”. Instead, in the latter “LPCTSTR” compressed form, the components are zipped together in an obscure unreadable form.

Since I gave a friendly piece of advice to forget about the TCHAR model, let’s substitute “TCHAR” with “wchar_t” in Unicode builds, so LPCTSTR becomes “const wchar_t*”! So, we get basically a pointer to a read-only C-style NUL-terminated Unicode (UTF-16) string.

Let’s do another one: LPTSTR.

  • LP: pointer
  • T: TCHAR
  • STR: NUL-terminated string

So, this is basically like LPCTSTR, but missing the “C” (“const”). So, this is a string buffer that isn’t read-only: you can write into it; for example, think of the output string returned by GetWindowText.

In code, it’s: “TCHAR *”, which is equivalent to “wchar_t*” in Unicode builds. Let’s see: “wchar_t*” vs. “LPTSTR”. Wow! The former (“wchar_t*”) is much simpler and more readable to me!

And let’s be honest that the difference between LPCTSTR and LPTSTR is very subtle: the “C” for “const” is buried in the middle of the LPCTSTR typedef! Instead, the difference between “const wchar_t*” and “wchar_t*” is much more clear!

Finally, let’s analyze LPCWSTR.

  • LP: pointer
  • C: const
  • W: wide, i.e. WCHAR/wchar_t based
  • STR: NUL-terminated string

So, this a pointer to a read-only (const) wchar_t-based (i.e. Unicode UTF-16) NUL-terminated string; in C++ code that translates to “const wchar_t*”. Again, in my opinion the expanded form is much more readable than the obscure “LPCWSTR” typedef. You can find this typedef used e.g. in the DrawThemeTextEx Win32 API.

Let’s summarize these results in a nice table:

Win32 Obscure Typedef Expanded Equivalent Equivalent in Unicode Builds
LPCTSTR const TCHAR * const wchar_t*
LPTSTR TCHAR * wchar_t*
LPCWSTR const wchar_t* const wchar_t*

Decoding other obscure Win32 typedefs is left as an Exercise for The Reader (TM). Actually, I hope those typedefs will now be a little bit less obscure…

Note also that you may find the pointer part sometimes abbreviated using “P” instead of “LP”: Welcome to the New World of (just) pointers, without long/short/near/far pointers 🙂

And, as a coding style, I think that using the underlying C++ types (like in “const wchar_t*”) is much better (e.g. clearer, less bug-prone) than using those Win32 typedefs (like “PCWSTR”).


A Friendly Piece of Advice: The TCHAR Model? Forget About It!

I believe modern Windows Win32/C++ applications should just use Unicode builds, instead of the obsolete TCHAR model.

For example, consider some Win32/C++ code like this:

CString str;
TCHAR* buf = str.GetBuffer(maxLength);
// Write something in buf ...
buf[n] = L'\0'; // (1)

// Other code ...

TCHAR * text = /* some valid output buffer */;
swprintf_s(text, L"Something ...", ...); // (2)

// DoSomething() is declared as:
//   void DoSomething(const wchar_t* psz);
DoSomething(text); // (3)

The author of that piece of code thinks he followed the TCHAR model, probably because he used TCHAR throughout his code; but he’s wrong. For example:

  1. If buf is a TCHAR*, the correct TCHAR-model assignment should be “buf[n] = _T(‘\0’);”, i.e. use the _T or TEXT preprocessor macros instead of the L prefix.
  2. swprintf_s should be substituted with _stprintf_s, and again the L prefix should be substituted with the _T or TEXT preprocessor macros.
  3. The TCHAR string “text” should be converted to a wchar_t string before passing it to the DoSomething function, e.g. using an ATL helper like CT2W or CT2CW (e.g. “DoSomething(CT2W(text));”).

So, following the TCHAR model would actually make the code more complicated. And for what?

For being able to compile the same source code also in ANSI/MBCS? And is the whole code base properly tested for ANSI/MBCS builds? And in case of ANSI/MBCS builds, what code page(s) is(are) used for char-based strings? Are the conversions from those code pages to Unicode done properly? This can be a bug factory! And, do you (or your clients) really need an ANSI/MBCS build of your software??

So, in my opinion, the best thing to do in modern Win32 C++ applications is to just forget about the TCHAR model, and to just use Unicode UTF-16 at least at the Win32 API boundary, and just use WCHAR or wchar_t instead of TCHAR (in other words: assume that TCHAR is wchar_t), and assume that Win32 APIs that take TCHAR-strings (e.g. SetWindowText) just take Unicode UTF-16 wchar_t-strings.

In other words: Just assume Unicode builds for Win32 C++ code.

I’d rewrite the above code fragment simply assuming that TCHAR is wchar_t, like this:

CString str;
// CString stores Unicode UTF-16 text 
// in Unicode builds
wchar_t* buf = str.GetBuffer(maxLength);

// Write something in buf ...
buf[n] = L'\0';

// Other code ...

wchar_t * text = /* some valid output buffer */;
swprintf_s(text, L"Something ...", ...);

// DoSomething() is declared as:
//   void DoSomething(const wchar_t* psz);

It’s also interesting to point out that some “modern” (e.g. Vista+) Windows APIs like DrawThemeTextEx just take Unicode (UTF-16) strings; i.e. the pszText parameter of the aforementioned API is of type LPCWSTR, i.e. “const WCHAR*” (instead of LPCTSTR, i.e. “const TCHAR*”).


A Beginner’s Bug with C++11 Range-For Loops

This is an interesting bug that may affect C++11 novices. I’m proposing it in a Q&A form below.

Q. I have this old C++ code that uses a for loop to convert an ASCII string to upper-case:

std::string s = "Connie";

// Convert string to upper-case
for (size_t i = 0; i < s.length(); i++) {
  s[i] = std::toupper(s[i]);

std::cout << s << '\n';

This code works just fine and prints “CONNIE” as expected.

I tried to modernize this code, using C++11’s range-for loops. I rewrote the previous loop like this:

for (auto ch : s) {
  ch = std::toupper(ch);

Unfortunately, it doesn’t work: the output is still the original “Connie” string, not the expected upper-case version.

What’s wrong with that code?

A. The problem is in this line:

for (auto ch : s) {

Using this “auto ch” syntax, at each iteration step, the ch variable contains a copy of the original char in the string.

So, in the body of the range-for loop:

  ch = std::toupper(ch);

at every iteration step you are just converting to upper-case a temporary copy of the original string characters, not the original characters themselves!

What you really want to is iterating through the original string characters in place, instead of operating on temporary copies.

The “auto&” syntax (note the “&”) is what will make it work:

// Iterate through the string characters *in place*.
// NOTE the "&"!!
for (auto& ch : s) {
  ch = std::toupper(ch);

I wrote some simple practical advice for range-for loops in this blog post. For more details on using range-for loops, you may want to read this Q&A on StackOverflow.