> std::string unicode_string;

> std::string::const_iterator it,

> for(it = s.begin(); it != s.end(); ++it)
> {
>    unicode_string.push_back(*it);
>    unicode_string.push_back('\0');
> }

> The above for loop would make unicode_string look like this:

> "e null a null s null y null"

> std::string unicode_string;

> std::string::const_iterator it,

> for(it = s.begin(); it != s.end(); ++it)
> {
>    unicode_string.push_back(*it);
>    unicode_string.push_back('\0');
> }

> The above for loop would make unicode_string look like this:

> "e null a null s null y null"

> Is there a faster way to do this... in place maybe?

> Or better yet, resize() to final size, assign the non-null characters
> in a backwards loop and set a couple of chars to zero:

>     void sillify(string&  io)
>     {
>        size_t len1 = io.size();
>        io.resize(len1*2,'\0');
>        for (size_t k=len1; k-->1;)
>           io[k*2] = io[k];
>        for (size_t k=1; k<len1; k+=2)
>           io[k] = '\0';
>     }

> > Or better yet, resize() to final size, assign the non-null characters
> > in a backwards loop and set a couple of chars to zero:

> >     void sillify(string&  io)
> >     {
> >        size_t len1 = io.size();
> >        io.resize(len1*2,'\0');
> >        for (size_t k=len1; k-->1;)
> >           io[k*2] = io[k];
> >        for (size_t k=1; k<len1; k+=2)
> >           io[k] = '\0';
> >     }

> Define "better".

>      void smartify(string& s) {
>          for(int i = 1, e = s.size()*2; i < e; i+=2) {
>              s.insert(i, 1, '\0');
>          }
>      }

>>> Or better yet, resize() to final size, assign the non-null characters
>>> in a backwards loop and set a couple of chars to zero:

>>>      void sillify(string&    io)
>>>      {
>>>         size_t len1 = io.size();
>>>         io.resize(len1*2,'\0');
>>>         for (size_t k=len1; k-->1;)
>>>            io[k*2] = io[k];
>>>         for (size_t k=1; k<len1; k+=2)
>>>            io[k] = '\0';
>>>      }

>> Define "better".

>>       void smartify(string&  s) {
>>           for(int i = 1, e = s.size()*2; i<  e; i+=2) {
>>               s.insert(i, 1, '\0');
>>           }
>>       }

> Faster. SG's code has linear complexity and yours is quadratic.
> Readability is something else...

>> On 5 sep, 19:27, "Francesco S. Carta"<entul...@gmail.com> wrote:
>>> SG<s.gesem...@gmail.com>, on 05/09/2010 10:17:37, wrote:
>>>> On 5 Sep., 19:05, "Francesco S. Carta" wrote:
>>>>> in place, yes: use the
>>>>> std::string::insert() method.

>>>> Or better yet, resize() to final size, assign the non-null characters
>>>> in a backwards loop and set a couple of chars to zero:

>>>> void sillify(string& io)
>>>> {
>>>> size_t len1 = io.size();
>>>> io.resize(len1*2,'\0');
>>>> for (size_t k=len1; k-->1;)
>>>> io[k*2] = io[k];
>>>> for (size_t k=1; k<len1; k+=2)
>>>> io[k] = '\0';
>>>> }

>>> Define "better".

>>> void smartify(string& s) {
>>> for(int i = 1, e = s.size()*2; i< e; i+=2) {
>>> s.insert(i, 1, '\0');
>>> }
>>> }

>> Faster. SG's code has linear complexity and yours is quadratic.
>> Readability is something else...

> Exactly. So neither is better than the other unless we associate
> "better" to "more readable" or to "faster" ;-)

>> std::string unicode_string;

>> std::string::const_iterator it,

>> for(it = s.begin(); it != s.end(); ++it)
>> {
>>       unicode_string.push_back(*it);
>>       unicode_string.push_back('\0');
>> }

>> The above for loop would make unicode_string look like this:

>> "e null a null s null y null"

>> Is there a faster way to do this... in place maybe?

> Depends what you want.

> It /seems/ that you're assuming a little-endian architecture

>>> std::string unicode_string;

>>> std::string::const_iterator it,

>>> for(it = s.begin(); it != s.end(); ++it)
>>> {
>>>        unicode_string.push_back(*it);
>>>        unicode_string.push_back('\0');
>>> }

>>> The above for loop would make unicode_string look like this:

>>> "e null a null s null y null"

>>> Is there a faster way to do this... in place maybe?

>> Depends what you want.

>> It /seems/ that you're assuming a little-endian architecture

>    No, he isn't. He is making the string UTF16LE, not assuming that the
> architecture is little-endian.

> See the original post:

>    "...Is there a faster way to do this..."

>std::string unicode_string;

>std::string::const_iterator it,

>for(it = s.begin(); it != s.end(); ++it)
>{
>    unicode_string.push_back(*it);
>    unicode_string.push_back('\0');
>}

>The above for loop would make unicode_string look like this:

>"e null a null s null y null"

>Is there a faster way to do this... in place maybe?

>Thanks for any tips,

>Brad

>>std::string s = "easy";

>>std::string unicode_string;

>>std::string::const_iterator it,

>>for(it = s.begin(); it != s.end(); ++it)
>>{
>>        unicode_string.push_back(*it);
>>        unicode_string.push_back('\0');
>>}

>>The above for loop would make unicode_string look like this:

>>"e null a null s null y null"

>>Is there a faster way to do this... in place maybe?

>>Thanks for any tips,

>>Brad

>Are you really trying to insert null after each character or are you looking for
>a way to convert std::string into std::wstring?

>> Faster. SG's code has linear complexity and yours is quadratic.
>> Readability is something else...

> Exactly. So neither is better than the other unless we associate
> "better" to "more readable" or to "faster" ;-)

>>> Faster. SG's code has linear complexity and yours is quadratic.
>>> Readability is something else...

>> Exactly. So neither is better than the other unless we associate
>> "better" to "more readable" or to "faster" ;-)

> Unnecessary quadratic code is a bug (unless you have guarantees on the
> input size).

>> On 2010-09-05 20:04, Francesco S. Carta wrote:

>>>> Faster. SG's code has linear complexity and yours is quadratic.
>>>> Readability is something else...

>>> Exactly. So neither is better than the other unless we associate
>>> "better" to "more readable" or to "faster" ;-)

>> Unnecessary quadratic code is a bug (unless you have guarantees on the
>> input size).

> That was a deliberately slow implementation - see all the other posts.

>>> On 2010-09-05 20:04, Francesco S. Carta wrote:

>>>>> Faster. SG's code has linear complexity and yours is quadratic.
>>>>> Readability is something else...

>>>> Exactly. So neither is better than the other unless we associate
>>>> "better" to "more readable" or to "faster" ;-)

>>> Unnecessary quadratic code is a bug (unless you have guarantees on the
>>> input size).

>> That was a deliberately slow implementation - see all the other posts.

> My point isn't that the implementation is a bit slower, it's wrong and
> should never be used. There is no question whether one of the two is
> better.

> Feed your quadratic implementation a 10MB string and it will literally
> run for hours.

> std::string unicode_string;

> std::string::const_iterator it,

> for(it = s.begin(); it != s.end(); ++it)
> {
>         unicode_string.push_back(*it);
>         unicode_string.push_back('\0');

> }

> The above for loop would make unicode_string look like this:

> "e null a null s null y null"

> Is there a faster way to do this... in place maybe?

>> Guys, aren't you a bit misleading with iterators and big-O and
>> stuff? ;-)

> My bad. I intentionally posted a wrong suggestion without clearly
> marking it as such - I thought I was going to be castigated immediately,
> but since the punishment didn't come at once, I kept it on to see what
> was going to happen... now I realize that it wasn't all that fun for the
> others, so I present my apologies to the group for the wasted time.

>>> Guys, aren't you a bit misleading with iterators and big-O and
>>> stuff? ;-)

>> My bad. I intentionally posted a wrong suggestion without clearly
>> marking it as such - I thought I was going to be castigated immediately,
>> but since the punishment didn't come at once, I kept it on to see what
>> was going to happen... now I realize that it wasn't all that fun for the
>> others, so I present my apologies to the group for the wasted time.

> The sad thing is, I've seen quadratic stuff like that far too often in
> production code. There certainly are more than enough (clueless) people
> who wouldn't consider it a joke.

> > On 2010-09-06 10:56, Francesco S. Carta wrote:
> >> tni <t...@example.invalid>, on 06/09/2010 10:37:08, wrote:

> >>> On 2010-09-05 20:04, Francesco S. Carta wrote:

> >>>>> Faster. SG's code has linear complexity and yours is quadratic.
> >>>>> Readability is something else...

> >>>> Exactly. So neither is better than the other unless we associate
> >>>> "better" to "more readable" or to "faster" ;-)

> >>> Unnecessary quadratic code is a bug (unless you have guarantees on the
> >>> input size).

> >> That was a deliberately slow implementation - see all the other posts.

> > My point isn't that the implementation is a bit slower, it's wrong and
> > should never be used. There is no question whether one of the two is
> > better.

> > Feed your quadratic implementation a 10MB string and it will literally
> > run for hours.

> You're right, of course, and finally somebody posted the correct,
> explicit objection to the first response of mine, which was
> over-zealously half-snipped by SG:

> "Faster, I don't know (measure it), in place, yes: use the
> std::string::insert() method."

> My purpose was to push the OP to make all the tests and the reasonings.

> But the OP disappeared and the group took circa ten posts to come down
> to this, I won't post any bait like this anymore, just to save my time :-)

>>> On 2010-09-06 10:56, Francesco S. Carta wrote:
>>>> tni<t...@example.invalid>, on 06/09/2010 10:37:08, wrote:

>>>>> On 2010-09-05 20:04, Francesco S. Carta wrote:

>>>>>>> Faster. SG's code has linear complexity and yours is quadratic.
>>>>>>> Readability is something else...

>>>>>> Exactly. So neither is better than the other unless we associate
>>>>>> "better" to "more readable" or to "faster" ;-)

>>>>> Unnecessary quadratic code is a bug (unless you have guarantees on the
>>>>> input size).

>>>> That was a deliberately slow implementation - see all the other posts.

>>> My point isn't that the implementation is a bit slower, it's wrong and
>>> should never be used. There is no question whether one of the two is
>>> better.

>>> Feed your quadratic implementation a 10MB string and it will literally
>>> run for hours.

>> You're right, of course, and finally somebody posted the correct,
>> explicit objection to the first response of mine, which was
>> over-zealously half-snipped by SG:

>> "Faster, I don't know (measure it), in place, yes: use the
>> std::string::insert() method."

>> My purpose was to push the OP to make all the tests and the reasonings.

>> But the OP disappeared and the group took circa ten posts to come down
>> to this, I won't post any bait like this anymore, just to save my time :-)

> Busy weekend. Thanks for the replies (all of you).

> Why do such a thing?

> Over simplified, but here is why: A Microsoft NT hash is a string
> (encoded as I described (utf-16le)) with MD4 then applied. In short,
> that produces an NT hash. So if I wanted to create an NT hash for the
> word "easy" and I had a std::string the process would look something
> like this:

> std::string NTHash = MD4(utf-16le_encode(std::string));

> My initial post confused the issue by using the term "unicode" in a
> variable name (although this is a form of unicode (utf-16le)
> encoding). And no, by default wstring doesn't magically do this.

> --------------------------------------

> insert works fine for in place. Faster than my for loop? Does not seem
> so. I'm not sure it needs to be any faster. I was just wondering.
> Maybe my approach is slow. Obviously, the encoding is an additional
> step to perform (plain MD4 on std::string is faster than encode
> std::string then MD4... but not a whole lot). BTW, these strings would
> never be 10 megs ;)

> That's about it. Thanks again.

> Busy weekend. Thanks for the replies (all of you).

> Why do such a thing?

> Over simplified, but here is why: A Microsoft NT hash is a string
> (encoded as I described (utf-16le)) with MD4 then applied. In short,
> that produces an NT hash. So if I wanted to create an NT hash for the
> word "easy" and I had a std::string the process would look something
> like this:

> std::string NTHash = MD4(utf-16le_encode(std::string));

> My initial post confused the issue by using the term "unicode" in a
> variable name (although this is a form of unicode (utf-16le)
> encoding). And no, by default wstring doesn't magically do this.