Re: [boost] [string] proposal

Subject: Re: [boost] [string] proposal
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2011-01-26 08:04:05

On Wed, Jan 26, 2011 at 12:42 PM, Yakov Galka <ybungalobill_at_[hidden]> wrote:
> On Wed, Jan 26, 2011 at 11:54, Matus Chochlik <chochlik_at_[hidden]> wrote:
[snip/]
>>
>> I'm fairly neutral on the immutability issue, I do not oppose it if
>> someone shows why it is a superior design, Â provided it does not
>> break everything horribly (from the backward compatibility perspective).
>>
>
> Me too, but it definitely will break existing code:
> string.resize(91);

This is just one of the examples. The append/prepend/etc.
are others. The question is: do we allow them for the
sake of the backward compatibility and implement them
by using the immutable-semantic. Even resize could be
implemented this way. Another matter is whether it makes
sense.

[snip/]
>
> My point is that 'Unicode-functionality' should be separate from the string
> implementation. This code
> for(char32_t cp : codepoints(my_string));
> should work with any type of my_string whose encoding is known.

If you need just this, then why not use std::string as
it is now for my_string and use any of the Unicode libraries
around. What I would like is a string with which I *can* forget
that there ever was anything like other encodings than Unicode
except for those cases where it is completely impossible.

And even in those cases, like when calling a OS API function
I don't want to specify exactly what encoding I want but just
to say: Give me a representation (or "view" if you like) of the string
that is in the "native" encoding of the currently selected locale
for the desired character type.

Something like this:

whatever_the_string_class_name_will_be cmd = init();
system(cmd.native<char>().c_str());
ShellExecute(..., cmd.native<TCHAR>().c_str(), ...);
ShellExecuteW(..., cmd.native<wchar_t>().c_str(), ...);
wxExecute(cmd.native<wxChar>());

or

whatever_the_string_class_name_will_be caption = get_non_ascii_string();
new wxFrame(parent, wxID_ANY, caption.native<wxChar>(), ...);

In many cases the above could be a no-op, depending on the
*internal* encoding used by this string class. It could be
UTF-8 by default and maybe UTF-16 on Windows.

Specifying *exactly* (like with iso_8859_2_cp_tag, or utf32_cp_tag, ...)
which encoding I want, should be done only when absolutely
necessary and *not* every time when I want to do something
with the string.

Also, there should be iterators allowing you to do this, again
without specifying what encoding you want exactly:

// cp_begin returning a "code-point-iterator"
auto i = str.cp_begin(), e = str.cp_end();
if(i != e && *i == code_point(0x0123)) do_something();

or even (if this is possible):

// cr_begin returning a character iterator
auto i = str.cr_begin(), e = str.cr_end();
// if the first character is A with acute ...
if(i != e && *i == unicode_character({0x0041, 0x0301}))
    do_something();
>
> I'm not against adding convenience functions into the string. It makes the
> code more readable when you concatenate operations. However, it violates
> this:
> http://www.drdobbs.com/184401197

I do not want to overuse the "breaking"
of the encapsulation by adding new non-static or friend
functions. If we can take an advantage in the implementation
of say trim(str) we may but we don't have to. This is an
implementation detail (if we decide that the usage is
trim(str) and not str.trim());

>
>
>> >
[snip/]
>> I that is to succeed it has to be (backward)compatible with the existing
>> APIs,
>> however borked they seem to us (me included). There are lots of strings
>> implementations that are *cool* but unusable by anything except algorithms
>> specifically designed for them.
>>
>> I can't exactly understand what has to be backward compatible with what...
> Can you please provide a few code snippets that mustn't break so I could
> think about that?
>

Maybe you have something different in mind, but what I was talking
about is that you cannot pass an iterator_range *directly* to
a WINAPI (or any other OS API that I know of) call.

BR,

Matus