std::tstring

In This Topic

The std::tstring class

The tstring class used within the generated code is just the stl basic_string templated class.
The tstring is just a typedef (wstring for unicode builds and string for non unicode builds).
Use the stl basic_string for reference.

namespace std
{
    #ifdef _UNICODE
        typedef wstring tstring;
    #else
        typedef string tstring;
    #endif
};

Common Problems

GPF when using stl string

Description
Because std::tstring is just the standard stl string hiding behind a typedef, we get the problems that you get when using stl string, this problem is quite common, and not immediately obvious what the cause is.

It is possible to get an Unhandled exception 0xC0000005 when using stl string objects returned from generated objects. The problem is typically noticed when using printf, wprintf, fprintf, fwprintf, sprintf, swprintf, _snprintf, _snwprintf, _vscprintf, _vscwprintf family of instructions e.g.

printf("DVD Title = %s\n", dvd->GetTitle());

where dvd->GetTitle() returns an stl string.

The Problem
The stl string class does not have a const char* cast operator, so it can't be used as if it were a C++ string. Because of this when it is used within printf (or a similar function), the printf function attempts to treat it as a const char* (which it is not), and this causes problems that lead to a GPF (typically in output.c).

The Solution
A reference to a const char * can be obtained from a stl string using the c_str() method. Use this method whenever you expect the stl string to be treated as a const char * (i.e. when used in printf etc.).

printf("DVD Title = %s\n", dvd->GetTitle().c_str());

GPF when using strings

Description
When using generated objects within a C++ application, you may get an assert failing from the Heap allocation functions (typically _CrtIsValidHeapPointer).

HEAP[Usage1.exe]: Invalid Address specified to RtlValidateHeap( 8e0000, 8c3510 )
Unhandled exception at 0x77fa144b in Usage1.exe: User breakpoint.

The Problem
In debug, all memory allocations are tracked within the debug version of the CRT (C runtime libraries). They keep track of all the allocations, and then tick them off as there de-allocated. When you are using 2 libraries that link different versions (or instances) of the CRT, then you have 2 lists of allocated objects. This may not sound like a problem, but it is posible (and likley) that memory will be allocated against one, and de-allocated against another. It is under these circumstances that you see this problem. More on this can be found on the Microsoft site Q190799, CRT Reference.

The Solution
Change the way the projects are linked (See linking).

E.g. Visual Studio 6.0 - change from Debug Multithreaded (/MTd) to Debug Multithreaded DLL (/MDd):

E.g. Visual Studio .Net (version 7.0) - change from Multi-threaded Debug (/MTd) to Multi-threaded Debug DLL (/MDd):

Send Feedback