Re: [boost] [string] proposal

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

On Wed, Jan 26, 2011 at 9:34 AM, Dean Michael Berris
<mikhailberis_at_[hidden]> wrote:
> On Wed, Jan 26, 2011 at 4:09 PM, Matus Chochlik <chochlik_at_[hidden]> wrote:
>> On Mon, Jan 24, 2011 at 12:59 PM, Dean Michael Berris
>>>
[snip/]
>
> I can say the same thing, although I'm largely concerned about
> "changing the way people think about strings" with an implementation
> that actually works and can be adapted in real-world situations rather
> than trying to support the IMO borked status quo. ;)
>
>> I don't say that the sources are statistically
>> representative or anything, but using string
>> to interact with the OS's APIs is actually one of
>> the most prevalent use-cases. I don' t think
>> it is a good idea to focus on getting the basic string
>> manipulation to be uber-efficient at the expense
>> of performance of the string in a "real-world" context.
>>
>
> Well, see here's the key phrase there that's important:
>
> Â "string manipulation"
>
> I actually want to wipe that phrase off the face of the C++ world and
> have everyone think in terms of "building strings" rather than
> manipulating them because in reality, there really is no manipulating
> something that's unique and immutable -- unless you create a new one
> from it.

OK, I  think we think the same thing :) Looking at the aforementioned
sources I found the doing things like:
mystr[i] = whatever()
was very rare, and while I used the term manipulation I didn't have
this specific case in mind. I'm completely OK, if we all agree that
what you propose is the way to go, with your idea how strings
should be manip.. - er scratch that - built.

>
>> Your program does not always look like:
>>
>> int main(void)
>> {
>> Â boost::string your_string;
>> Â do(something(really(cool(and(efficient(with(your_string)))))));
>> Â return 0;
>> }
>
> FWIW, I think programs written that way are just really ugly and broken. ;)
>
>>
>> many time you do things like:
>> a) read file, parse its contents, create instances from the data
>
> So, how does immutability change this? Why can't you create an
> immutable string from a buffer and parse that immutable string and
> create instances of other types from the data?
>
>> b) get string from a socket, manipulate it, display it in the GUI
>
> What's stopping you from building another string from an immutable
> string to be displayed in the GUI? If you need something that would be
> mutable, you don't use a string to represent it -- use a different
> data structure that implies mutability like a vector<char> or similar
> data structure, build a string from that and display that string to
> the GUI.
>
>> c) get a string from a GUI, save it into a config file
>
> So what's the problem with an immutable string in this context?
>
>> d) take a string literal, localize/translate by gettext, show it
>> etc.

The immutability *does not* have a thing with the problems
in the use-cases described above. Encoding *does*.

>>
>
> Yes (except the gettext part which I largely don't understand), so
> what's wrong with building an immutable string from a string literal?
> Or for that matter building an immutable string from gettext output?
>
>> In order for this thing to be widely adopted (which is one
>> of my goals) it has to be nice to the existing APIs and let's
>> face it, most of them expect std::string or just plain ol' char*.
>>
>
> Sure, but still I don't see why you need to add c_str() to an
> immutable string when you're fine to create an std::string from that
> immutable string and call c_str() from the std::string instance
> instead?

One word. Performance :)

BR,

Matus