c++.stlsoft - String Concat
- Curtis Krauskopf (11/11) May 10 2004 Matthew,
- Matthew (26/35) May 11 2004 Thanks for that. I was pretty excited about it when I realised how it co...
- Sean Kelly (14/19) May 26 2004 Agreed. Excellent article. But I do have one nit to pick. According ...
Matthew, Congrats on your June 2004 CUJ article. I absolutely love the fast string concatenator and how seamlessly it can be integrated into existing programs. I found one mistake in the fast_string_concatenator_test.cpp. The 8 concat test is actually only concating 5 times. Line 711 should be concating eight times instead of five times. For the Borland compiler, this changes the 8 concats results as follows: trivial_string: was 24%, correct value: 22% std::basic_string: was 30.7%, correct value: 25.2% stlsoft::basic_simple_string: was 37.6%, correct value: 27%. Curtis
May 10 2004
CurtisCongrats on your June 2004 CUJ article. I absolutely love the fast string concatenator and how seamlessly it can be integrated into existing programs.Thanks for that. I was pretty excited about it when I realised how it could be done. (If you were to start referring to it as Wilson Concatenation, I would have to demur. ;) Hopefully, if you've liked that technique, you'll enjoy "Imperfect C++", which should be out in September or October, as that's just one of the gems in there. There'll be more revelations in CUJ and DDJ later in the year, hopefully to get a crescendo of slavering pragmatic C++ programmers ready with their (boss's) cheque-books.I found one mistake in the fast_string_concatenator_test.cpp. The 8 concat test is actually only concating 5 times. Line 711 should be concating eight times instead of five times.Ah, bummer. Silly me.For the Borland compiler, this changes the 8 concats results as follows: trivial_string: was 24%, correct value: 22% std::basic_string: was 30.7%, correct value: 25.2% stlsoft::basic_simple_string: was 37.6%, correct value: 27%.Cool. So it's even better than I portrayed. Thanks for the info. (It's always easier to accept favourable corrections, of course.) I guess I'd best get busy with getting STLSoft 1.7.1 ready, as I've committed to getting it onto the "Imperfect C++" CD. Not to mention having stretched the user base beyond reason. <g> Anyway, thanks again. It's always nice to hear feedback on one's writings. Cheers -- Matthew Wilson Contributing editor, C/C++ Users Journal (www.synesis.com.au/articles.html#columns) STLSoft moderator (http://www.stlsoft.org) "You can tell a Yorkshireman, but you can't tell him much!" -- Uncle Michael -------------------------------------------------------------------------------
May 11 2004
In article <c7q861$30im$1 digitaldaemon.com>, Matthew says...CurtisAgreed. Excellent article. But I do have one nit to pick. According to the C++98 standard, the data of std::string are not required to be contiguous (unlike the data in vector and valarray). So doing: memcpy( &str[0], ... ); as part of the write function relies on knowledge of a library's implementation details and is not technically legal for us normal folks. But I haven't been following the standards revisions and recent discussion--this may be something that has already been changed with respect to the next iteration of the standard? In any case, I'll likely implement this for myself. I tend to prefer the append member function over the addition operator for performance reasons, so this will be a nice change :) SeanCongrats on your June 2004 CUJ article. I absolutely love the fast string concatenator and how seamlessly it can be integrated into existing programs.Thanks for that. I was pretty excited about it when I realised how it could be done. (If you were to start referring to it as Wilson Concatenation, I would have to demur. ;)
May 26 2004
In article <c7q861$30im$1 digitaldaemon.com>, Matthew says...have to demur. ;)CurtisCongrats on your June 2004 CUJ article. I absolutely love the fast string concatenator and how seamlessly it can be integrated into existing programs.Thanks for that. I was pretty excited about it when I realised how it could be done. (If you were to start referring to it as Wilson Concatenation, I wouldAgreed. Excellent article. But I do have one nit to pick. According to the C++98 standard, the data of std::string are not required to be contiguous (unlike the data in vector and valarray). So doing: memcpy( &str[0], ... ); as part of the write function relies on knowledge of a library's implementation details and is not technically legal for us normal folks. But I haven't been following the standards revisions and recent discussion--this may be something that has already been changed with respect to the next iteration of the standard?Ouch! Well spotted. I should have had you as one of the reviewers for Imperfect C++! I shall have to make some traits to make sure this is done correctly. ;)In any case, I'll likely implement this for myself. I tend to prefer theappendmember function over the addition operator for performance reasons, so thiswillbe a nice change :)Cool. Glad to be of help.
May 26 2004
This issue is now resolved. The version of FSC in v1.8.1 of STLSoft - about to be posted in the next hour - uses std::copy() instead of memcpy(). In my tests with a few (but not all) compilers it results in identical performance savings to the memcpy() version. There's a pre-processor symbol to define if you *really* want memcpy(), which you use, naturally, at your own risk. Thanks again, Sean, for your keen eye. "Matthew" <matthew.hat stlsoft.dot.org> wrote in message news:c9397l$gua$1 digitaldaemon.com...In article <c7q861$30im$1 digitaldaemon.com>, Matthew says...have to demur. ;)CurtisCongrats on your June 2004 CUJ article. I absolutely love the fast string concatenator and how seamlessly it can be integrated into existing programs.Thanks for that. I was pretty excited about it when I realised how it could be done. (If you were to start referring to it as Wilson Concatenation, I wouldAgreed. Excellent article. But I do have one nit to pick. According to the C++98 standard, the data of std::string are not required to be contiguous (unlike the data in vector and valarray). So doing: memcpy( &str[0], ... ); as part of the write function relies on knowledge of a library's implementation details and is not technically legal for us normal folks. But I haven't been following the standards revisions and recent discussion--this may be something that has already been changed with respect to the next iteration of the standard?Ouch! Well spotted. I should have had you as one of the reviewers for Imperfect C++! I shall have to make some traits to make sure this is done correctly. ;)In any case, I'll likely implement this for myself. I tend to prefer theappendmember function over the addition operator for performance reasons, so thiswillbe a nice change :)Cool. Glad to be of help.
Sep 11 2004