Re: [boost] [string] proposal

Subject: Re: [boost] [string] proposal
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2011-01-27 10:09:15

On Thu, Jan 27, 2011 at 2:55 PM, Dean Michael Berris
<mikhailberis_at_[hidden]> wrote:
> On Thu, Jan 27, 2011 at 8:45 PM, Matus Chochlik <chochlik_at_[hidden]> wrote:
>> On Thu, Jan 27, 2011 at 12:09 PM, Dean Michael Berris
>> <mikhailberis_at_[hidden]> wrote:
>>>
[snip/]
>
> Usability of what, the type? Any type is as usable as any other the
> way I see it -- they're all just types. So aside from
> aesthetic/cosmetic differences, what's the point?

I don't want to sound like an advertisment but ..
aesthetic matters .. to many people. Unless we want
to turn even the completely basic things into rocket
science.

>
>>>
>>> So what's wrong with:
>>>
>>> view<some_encoding_0> x = get_x();
>>> view<some_encoding_1> y = get_y();
>>> view<some_encoding_3> z = x+y;
>>> float w = log(as<acme_float_encoding>(z));
>>
>> Unnecessary verbosity.
>>
>
> What verbosity?

Like in having to say to much (view<some_encoding_3>)
to express a very simple thing (string/text)?

>
> We deal with that through typedefs and descriptive names. Heck C++0x
> has auto so I don't know what 'verbosity' you're referring to.
>
> And if you really wanted to know the encoding of the data from the
> type, how else would you do it?
>
>> Do you really want all the people that now do:
>>
>> struct person
>> {
>> Â  Â std::string name;
>> Â  Â std::string middle_name;
>> Â  Â std::string family_name;
>> Â  Â // .. etc.
>> };
>>
>> to do this ?
>>
>> struct person
>> {
>> Â  Â boost::view<some_encoding_tag> name;
>> Â  Â boost::view<some_encoding_tag> middle_name;
>> Â  Â boost::view<some_encoding_tag> family_name;
>> Â  Â // .. etc.
>> };
>>
>
> Well:
>
> typedef boost::strings::view<boost::strings::utf8_encoding> utf8_string;

This (well not exactly utf8_string, but that was a completely
different discussion) is what I was suggesting all along :)

>
> struct person {
> Â utf8_string name, middle_name, family_name;
> };
>
> Where's the verbosity in that?

Chop away the utf8_ part and I will be happy and quiet.

[snip/]
>>>
>>> Right, what I meant to say is that it hardly has any bearing when
>>> we're talking about engineering solutions. So your circumstances and
>>> mine may very well be different, but that doesn't change that we're
>>> trying to solve the same problem. :)
>>>
>>
>> If along solving your problem (all the completely valid points
>> that you had about the performance) we also solve my and
>> other's problem (completely valid points about the encoding)
>> and we think about the acceptability and "adoptability",
>
> I don't know what "acceptability" and "adoptability" mean in this context.

It is the "sex-appeal" of your class. It is basically about if
the people would be willing to take your class and use it
instead of std::string in their code and this includes
doing all the necessary changes in their code.

>
> Both of these are a matter of taste and not of technical merit.
>
>> we provide a backward compatible interface for people who
>> do not have the time to re-implement all their string-related
>> code at once and try really hard to get it into the standard
>> than I do not have a thing against it.
>
> Backward compatibility to a broken implementation hardly seems like a
> worthy goal. Deprecation is a better route IMHO.

OK, so what do you propose your string is going
to be called in the standard? Because calling
it std::string is not deprecation. Deprecation would
be calling it std::someotherstring and having them
both in the standard for a certain period of time.

>
> Even if it does become std::string, it will be a deprecation of the
> original definition. Deprecation *is* an option.
>

OK, if it is called std::string how do you imagine this would
work? The (old) std::string would be deprecated for a certain
period of time and then it would be replaced by (new) std::string ?

If this is what you have in mind then I need to change my
view on what that word means.

Matus