For some analysis of GetBuffer () and ReleaseBuffer ()

First reprint a section of someone else's article

CString class of these functions, has been in use, but the total sense of understanding is not thorough enough, and sometimes also practical wrong phenomenon. Today, the time and Nico together to analyze a bit, is to pull out the mist:
GetBuffer and ReleaseBuffer is a set of functions that need to be used together, compared with getbuffersetlength, the advantage is that the allocated space is greater than the actual saved string (0 end), ReleaseBuffer will be the extra space to release the request, returned to the system; However, it is important to pay attention to the following questions: Assuming that the string to be saved is ABC (0 end), the getbuffer should be at least 3; Assuming that the content to be saved does not end with 0, for example, to read the file data, then the GetBuffer parameter is assumed to be larger than the file length, the ReleaseBuffer parameter must be the length of the file (assuming GetBuffer is the length of the file, there is no problem. ReleaseBuffer parameters can be the default-1)!
CString Csstr;

LPTSTR lpsz = csstr.getbuffer (100);

Lpsz[0] = ' a ';

Lpsz[1] = ' B ';

LPSZ[2] = '/0 ';

Csstr.releasebuffer ();

int nlength = Csstr.getlength ();

/* The value of n is 2 */

GetBufferSetLength relatively easy to understand, it applies for a specified length of space, even if the length of the string inside the last saved is less than the requested space length, will not be freed up the extra space.
CString Csstr;

LPTSTR lpsz = csstr.getbuffersetlength (100);

Lpsz[0] = ' a ';

Lpsz[1] = ' B ';

LPSZ[2] = '/0 ';

int nlength = Csstr.getlength ();

/* The value of n is still 100 */

For the red part, you do encounter this problem when you write your own code: code such as the following

CString temp;
Ulonglong dwcount = Input_file.getlength ();
UINT dwcount = (UINT) input_file.getlength ();
Input_file.read (temp. GetBuffer (dwcount), dwcount);
Temp. ReleaseBuffer (dwcount);

If temp. ReleaseBuffer () do not specify a number of parameters, run this step will encounter an error, so, similar to the file read operation, ReleaseBuffer or specify a getbuffer as the same as the number of parameters as good

Another: for

(assuming GetBuffer is a file length, there is no problem, ReleaseBuffer can be the default-1)!

I set temp. ReleaseBuffer (-1); This sentence still has an error when running, so it is better to specify the length of the file.

Next look at the other code

CString str;
Browseinfo bi;
TCHAR Name[max_path];
ZeroMemory (&bi,sizeof (browseinfo));
Bi.hwndowner = GetSafeHwnd ();
Bi.pszdisplayname = name;
Bi.lpsztitle = _t ("select Directory");
Bi.ulflags = bif_returnfsancestors;
Lpitemidlist idl = SHBrowseForFolder (&BI);
if (idl = = NULL)
Return

SHGetPathFromIDList (IDL, str. GetBuffer (MAX_PATH));

1
CString AA = str. GetBuffer (MAX_PATH);
CString bb = str; After running this sentence, str content becomes garbled
int a = AA. GetLength ();
int b = str. GetLength ();
LPTSTR cc = str. GetBuffer (MAX_PATH);
LPTSTR dd = bb. GetBuffer (MAX_PATH);
CC[1] = ' a ';

Bb. ReleaseBuffer ();

Debug parameters For example as seen in:

2
CString AA = str. GetBuffer (MAX_PATH);
int a = AA. GetLength ();
int b = str.                       GetLength (); b cannot get the length of str
LPTSTR cc = str. GetBuffer (MAX_PATH);
CC[1] = ' a ';
int e = str.                       GetLength (); E cannot get the length of str correctly, unlike 3 where Str is not releasebuffer after the blue font GetBuffer /proper practice is to releasebuffer () between two times Str.getbuffer and Str.getlength ().
Str. ReleaseBuffer ();
int d = str. GetLength ();

Debug parameters such as the following are seen:

////3
//cstring aa = str. GetBuffer (MAX_PATH);
//str. ReleaseBuffer ();
//cstring BB = str;                                  // The contents of the BB are correct
//int a = AA. GetLength ();
//int b = str. GetLength ();
//lptstr cc = str. GetBuffer (MAX_PATH);
//lptstr dd = bb. GetBuffer (MAX_PATH);
//cc[1] = ' a ';
//int d = str. GetLength ();                     //Here, although the value of STR can be obtained correctly, after GetBuffer (), it is advisable to ReleaseBuffer () once after cc[1] = ' a '.

Why no longer cc[1] = ' A ' before ReleaseBuffer: Although here Str will still become "ca/...", according to MSDN: after calling ReleaseBuffer, the address returned by GetBuffer may be invalid. Because other CString operations may cause the CString buffer to be allocated again. Assuming you haven't changed the length of this CString, the buffer will not be allocated again. The proper practice is to releasebuffer after Cc[1]

Debug parameters such as the following are seen:

4

Str. ReleaseBuffer ();                                  //   on the above SHGetPathFromIDList (IDL, str. GetBuffer (MAX_PATH));  the release action
CString AA = str. GetBuffer (MAX_PATH);
CString BB = str;                                      //After running this sentence, the value of STR does not become garbled, and the 1 analogy
int f = str. GetLength ();                            //and 1 to get the length correctly here

Str. ReleaseBuffer ();
int a = AA. GetLength ();
int b = str. GetLength ();
CString ff = str. GetBuffer (MAX_PATH);
LPTSTR dd = bb. GetBuffer (MAX_PATH);
int d = str. GetLength ();

After a CString is GetBuffer, CString before the other CString functions of the CString (especially the easy-to-ignore releasebuffer operations such as "=" "+") (although from a few pieces of code here, On the surface after getbuffer the CString operation does not cause an error at one time, but a second CString operation produces an error. In order to be safe, getbuffer need to run the CString function at the time of the operation, first ReleaseBuffer ()).

For some analysis of GetBuffer () and ReleaseBuffer ()