I have just one point to add:
The CString's equality operator is very uncomfortable...
I think that NO (absolutely NO) professional programmer compares two strings without making them lower! Okay, for some purpose you MAY do so (cheap pwd protection etc.)...
I just tried to override the CString provided by .NET, then I thought about downgrading to VC6 again... This ATL-**** sucks balls!
Please, if anyone has a nice CMyString class, please email me... I just wanted to get rid of this idea :D
I have a question about heap usage with the CString class. The sample application is a debug build and the 64/128/... allocation buffers are not used. The buffer is allocated to the necessary size of the string. (BTW, the problem described below doesn't go away in the release build)
I have a test application (non-unicode) with a class containing an array of 40 CStrings. I then allocate 10,000 of those classes. When I look at the heap usage before and after this operation, there is a consumption of 4 bytes / string. That is what is expected.
Next, I set the value of each string to "A". Now my heap usage jumps up to 92 bytes / string! This exact same usage is seen for string values up to a 20 character string. At that point, usage jumps up to 108 bytes / string.
If I go into the test application and change the array of 40 CStrings to an array of 40 char, I see exactly 32 bytes per string in all cases with the test application.
Can you offer any suggestions as to why CStrings are consuming so much RAM?
I had a release-build library that yielded unresolved
extern against my release task. No problem with debug-
Since unresolved extern was _AfxPchNil I was able to
search on that term, find your article, and infer that
an uninitiliazed CString (which occurs only in the
library) was not being linked successfully to the
empty string Kahuna.
Life being short, I simply intialize the string
explicitly and problem gone. Thanks.
Passing a CString by const reference will be faster, and take less code, than passing it by value.
This is mainly because the reference-counting code is out-of-line. (It is also fairly complex, with various tests for special cases etc.) Think about it: when you call:
void func( CString copy );
the compiler starts by calling the string's copy constructor, which is like:
CString::CString( const CString &rhs );
which necessarily passes by reference. So every pass by value has a pass by reference included. So it will be slower.
Reference counting means the difference isn't much. However, pass-by-const-reference is the norm for large objects. There is no reason to treat CString any differently to the norm. If you think pass-by-value is a worth-while optimisation, you're wrong: it's a pessimisation.
I was looking for information on the use of the CString class and how it works. I thought "CString in a Nutshell" to be a fitting title for a page with such information. How wrong I was.
This page provides practically no information on how one would start using CString. It doesn't even mention the include calls which need to be made to use it! I was disappointed upon seeing this, and am saddened that I was so misguided. I'd like to see a REAL explaination of CString as opposed to someone trying to simply show the usefulness of it.