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

Curtis

> Congrats 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

-------------------------------------------------------------------------------

In article <c7q861$30im$1@digitaldaemon.com>, Matthew says...
>
>Curtis
>
>> Congrats 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. ;)

Agreed.  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 :)


Sean

> In article <c7q861$30im$1@digitaldaemon.com>, Matthew says...
> >
> >Curtis
> >
> >> Congrats 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. ;)
>
> Agreed.  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 the
append
> member function over the addition operator for performance reasons, so this
will
> be a nice change :)

Cool. Glad to be of help.

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...
> > >
> > >Curtis
> > >
> > >> Congrats 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. ;)
> >
> > Agreed.  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 the
> append
> > member function over the addition operator for performance reasons, so this
> will
> > be a nice change :)
>
> Cool. Glad to be of help.
>
>
>
>