On Thu, Jan 27, 2011 at 2:55 PM, Dean Michael Berris <mikhailberis@gmail.com> wrote:
On Thu, Jan 27, 2011 at 8:45 PM, Matus Chochlik <chochlik@gmail.com> wrote:
On Thu, Jan 27, 2011 at 12:09 PM, Dean Michael Berris <mikhailberis@gmail.com> 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