It was the negative comments about CString that caught my eye:
"CStrings cannot be extended - their header file is buried within MFC"
Buried? It's a class; you can't "bury" the header file! I first subclassed CString with 1.52c. I had to make a minor change for 32-bit MFC and for the new CString classes, but other than that it's worked just fine.
"CStrings are slow. Catenating a simple value requires copying the string into a new buffer."
Again, this isn't true. CStrings are actually quite fast and your own benchmarks bear that out.
"CStrings internally call malloc/free so often that memory becomes very fragmented, and your application incurs a major performance hit."
Again, completely false. Have you even looked at the source for CString? Again, your own benchmarks contradict this remark.
"Reference counting (the ability to quickly assign one CStr to another without copying the characters) was first implemented in the MFC library accompanying Visual C++ 5. Besides, it's not that efficient."
And? It's actually quite efficient, but has been discarded in MFC 7.0 due to a fundamental, albeit rare, problem with most reference counting classes that has no real solution.
I would have enjoyed benchmarking your class, but it's no longer freely available so there is no way to test your vaunted results. (Making me sign up even if for free does not make this freely available.)
Note that I did compile the version available here and it was chock full of bugs. When I did get it to run, it was sometimes faster and sometimes slower than CString. The assignment operation was 40% slower and the concatenation degredated rapidly where 100 concatenations totally about 3k was 300% slower.
By comparison when CStr was faster than CString (for those tests that worked), CString was always within 5% the speed of CStr.
I would like to know how to convert a Cstring in a double. I have written the following simple example: in a dialog I have put three edit and the third I would like to be the sum of the values put in the first and in the secon edit (for istance in the first I put 5.8 in the second I put 2.4, in the third edit should appear 8.2). After reading your article I know how to do if the values are integers but I don't know how to do if the values are float or double. In the edit I wold like to put values of type Cstring; if the variables
associated to the edit are float or double in the edit box appear a zero and I don't want the zero appear in the edits when I execute the program.
Could you help me?
My best regards, Giacomo Moro
I loved to this source.
I inconvenience myself about 'Find' function, because of
'Find' funciton in this source which Find only one character.
So. I wish to find words in some string.
I Add to 'Extended Find function'
This function is very useful..
I'm writing the shell extension using ATL library without using MFC. Your code doesn't compile - linker error message "unresolved external symbol "void * __cdecl get_stringres(void)" is appeared. If i try to put #include "CStrMgr.cpp" to stdafx.cpp, i getting too many different "unresolved external" errors.
I see no problem with reinventing the wheel when it gains you a performance advantage. But, any good programmer realizes that a generally fast routine or class that is made for general applications will not be super-optimized for all applications.
CString has it's place. If you need to do non-intensive routines that require simple string manipulation, by all means use CString. You would have to be crazy to re-write a string class for a simple application.
On the other hand, needed to use a string class search in a database containing fields of undetermined lengths that would be inserted in alphabetical order. Had I used a List or Vector class, which I very well could have, and in fact should have had I not needed extreem speed, it would have taken way too long. Instead I wrote a specilized linked list class that could be searched with a binary search (well, a slightly modified binary search) and came up with a tremendously fast program. In that case, reinventing the wheel was useful.
There are a lot of people out there who complain about MFC and Microsoft code being too slow. Well, I'll bet your code may be slow for my applications as well. Your code is optimized (I hope) for your programs. Microsoft's code is optimized for general use, where usability and functionality tend to be thought of before lightning speed.
Re-write a string class if you want to, I say. Better, though, to optimize it for your purpose. General performance gains seem to be getting smaller and smaller these days.
I think the usefulness of this project is not for improving the CString class and instead for inventing a new string class which is similar to the CString class. So I can get away with the huge MFC library. It is also possible to make my codes better portable to other platforms (i.g. linux in the future). If someone can re-invent the MFC classes and make the source codes available to everyone, I will really appreciate him/her. Keep the great work, Kamen.