Re: CString question
On Mon, 11 Feb 2008 12:28:54 -0800 (PST), catfish <phymtwo@gmail.com>
wrote:
Thanks much for your help.
Well, there is no /DUNICODE or /D_DUNICODE in all project settings.
strlen(str2) retunred 1. wcslen() failed.
This indicates that the code calling these functions is using an ANSI
CString.
The application first failed in the release build, then I debugged
into it and found out why.
Where does your "stored procedure" live compared to the code that calls it?
If they are in different modules, i.e. EXE and DLL or different DLLs, both
must link to the same CRT DLL in order to share C++ objects in this way.
The compiler setting is "Use multithreaded CRT in a DLL" (or something
similar), and it must be the same CRT DLL, i.e. no mixing of debug and
release modes. Again, both modules must use the same Unicode settings.
Could you please help a bit about how to
look at raw memory?
You would first get the address of the object in the debugger, and then you
would open a memory window on it. You would correlate the memory contents
with the class definition. For CString, you should be able to expand it in
the debugger "Autos" window until you get to the m_pszData member, which
contains the address of the memory you need to examine. While it's typed as
a TCHAR*, it actually points to a CStringData object, and this class is
defined in atlsimpstr.h (VC9):
struct CStringData
{
IAtlStringMgr* pStringMgr; // String manager for this CStringData
int nDataLength; // Length of currently used data in XCHARs (not
including terminating null)
int nAllocLength; // Length of allocated data in XCHARs (not including
terminating null)
long nRefs; // Reference count: negative == locked
// XCHAR data[nAllocLength+1] // A CStringData is always followed in
memory by the actual array of character data
....
};
The character data is tacked on to the end, so for Win32, it would be
located 16 bytes past the start of the object.
--
Doug Harrison
Visual C++ MVP