Re: [boost] [string] proposal

Subject: Re: [boost] [string] proposal
From: Ivan Le Lann (ivan.lelann_at_[hidden])
Date: 2011-01-27 06:00:58

Artyom wrote :
> > 
> > So you do not consider the fact the following  code compiles (and
> runs!)
> > cleanly as a painful problem?
> > 
> > std::string s  = get_utf8_string();
> > s[42] = '?';
> > 
> 
> It is fine code. Why? Because if you assign s[42] you probably
> know why you are do it and you most likely know that there is
> a some ASCII character there.
> 

I want more safety. And opacity is one way to it. I consider that 
stating "The code is OK because you know what you're doing" is an 
offense to all safety efforts put into C++ and its standard library.
Sorry for the tone, but I failed to express my views in another way. 
Non throwing failures somewhat disturb me. Especially if you can 
design a failsafe interface.

> 
> > I consider that std::string is cool  as an internal for a
> Boost.Locale
> > implementor, not as a standard API for  encoded strings that should
> be
> > used by all C++  developpers.
> > 
> 
> Seems to me you hadn't seen Boost.Locale code and what does it
> does.
> 

I've seen it and toyed with it, and it's great. I have no problem with 
Boost.Locale, I have a problem with all the mess than can be done with 
the string type it has to publicly use today.
And by the way, you're the one who stated that encoded string processing 
should be done by a domain expert library. I'm only exspecting you to 
translate this into : we need a more opaque string.

Ivan