CString and char* type conversion

CString is a very useful type of data. They largely simplify many of the operations in MFC, making it much easier for MFC to do string manipulation. In any case, there are a lot of special techniques for using CString, especially for programmers who come out of the pure C background.

1, CString into char* (1)--forcing type conversion to LPCTSTR

This is a slightly rigid conversion, and we first need to understand that CString is a very special C + + object that contains three values: A pointer to a data buffer, a valid character count in the buffer, and a buffer length. The number of valid characters can be any number from 0 to the buffer maximum length value minus 1 (because there is a null character at the end of the string). Character counts and buffer lengths are cleverly hidden.

Unless you do something special, you can't know the length of the buffer allocated to the CString object. This way, even if you get the address of the buffer, you can't change the content, you can't truncate the string, and there's absolutely no way to increase its content, otherwise you'll see the overflow in the first time.

The LPCTSTR operator (or, more specifically, the TCHAR * operator) is overloaded in the CString class, which is defined as the address of the return buffer, so if you need a string pointer to the CString, you can do this:

CString s ("Graycat");

LPCTSTR p = s;

It can run correctly. This is achieved by the mandatory type conversion rules of C language. C + + rules allow this choice when forced type conversions are required. For example, you can define (floating-point numbers) to return only the first floating-point number (that is, the fact part) of a complex number (with a pair of floating-point numbers) after a cast type conversion. It can be as follows:

Complex C (1.2f, 4.8f);

float Realpart = c;

If the (float) operator is defined correctly, the value of the real part should be 1.2.

This coercion is appropriate for all cases, for example, any function with the LPCTSTR type parameter will enforce this conversion. So you might have a function (perhaps in a DLL you bought):

BOOL Dosomethingcool (LPCTSTR s);

You call it as follows:

CString file ("C:\\myfiles\\coolstuff")

BOOL result = Dosomethingcool (file);

It works correctly. Because the Dosomethingcool function has explained the need for a LPCTSTR type of argument, LPCTSTR is applied to the parameter, which is the returned string address in MFC.

What if you want to format strings?

CString graycat ("Graycat");

CString s;

S.format ("mew! I Love%s ", Graycat);

Note Because the value in the variable argument list (represented by "..." in the description of the function) does not imply a mandatory type conversion operator. What results will you get?

A surprising result, we get the actual result string is:

"Mew! I Love Graycat ".

Because the designers of MFC are very careful when designing CString data types, CString type expressions are evaluated and point to strings, so there is no forced type conversion in Format or sprintf, and you can still get the right behavior. The additional data describing the CString is actually after CString the nominal address.

One thing you can't do is to modify the string. For example, you might try to use "," instead of "." (Don't do this, if you care about internationalization issues, you should use the decimal conversion National Language Support feature) below is a simple example:

CString V ("1.00"); Monetary amount, two decimal places

LPCTSTR p = v;

P[lstrlen (P)-3] = ', ';

The compiler will then give an error because you have assigned a constant string. If you try the following, the compiler will also be wrong:

Strcat (P, "each");

Because the first parameter of strcat should be LPTSTR type of data, and you give a LPCTSTR.

Don't try to drill the horns of this wrong message, it will only get you into trouble!

The reason is that the buffer has a count, it is not accessible (it is located in a hidden area below the CString address), and if you change the string, the character count in the buffer does not reflect the modification. In addition, if the string length is exactly the length of the physical limit of the string, then extending the string will overwrite any data other than the buffer, which is the memory you do not have permission to write, and you will destroy the memory that is not yours. This is the actual death prescription for the application.