Re: [TSVN] CString vs std::string

At 12:52 22/12/2004 +0100, you wrote:

>I always had the impression that STL is usually faster than MFC/ATL,
>especially the string class

I think that depends on what you're doing. For example, the current STL
string doesn't do ref-counting copies, so copying a string which
subsequently doesn't get modified is much faster with CString.

The std::string has a small-string optimisation, which means that strings
under about 14 (?) bytes long get stored in the std::string object instead
of on another heap allocation - that's much faster for small strings, but
is merely a space overhead if all your strings are longer than that.

Like everything else in optimisation, you have to measure rather than say
"ATL slow, STL fast".

>(and of course map, vector, ...).

Well, they have a different growth strategy to the MFC arrays, and they get
the benefit of all the <algorithm> stuff, which you don't have as much of
in MFC.

>And if I
>recall correctly, you just optimized TortoiseMerge by replacing the
>'text file class' there with an STL version.

I replaced the arrays, not the strings. And I did that because I'd seen a
perf problem with CArray which I knew would be fixed by std::vector.

>So what advantages would we have by switching to ATL?

We would clean-up the code, so that there weren't situations like there are
at the moment where strings go from CString to char* and then into std::string.

If I was to do my unified Path class, I would have to choose a string type
for that (which would probably be CString), and it would be good if that
didn't have to get converted to stdstring in the SVN interface layer.

Cheers,

Will

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Dec 22 13:13:08 2004