Joel de Guzman wrote:
Martin Wille wrote:
The collapsing views would produce a better quality output in the case of ß, but I'm not sure the behaviour of compiletime composition should differ from the behaviour of the runtime composition.
Yes, indeed. I realized that after some folks pointed that out. So collapsing to_upper/to_lower is not a good idea. But then, yes, the german: ß -> SS also implies that a universal to_lower/to_upper algorithm cannot be efficiently implemented as a mutating/in-place function (i.e. the string will have to grow/shrink). When such memory movement happens, the advantage of in-place mutation is gone.
True. I didn't intend to object to the functional model, anyway. (In fact, I like it a lot and I'd prefer it most of the time.) IMHO, the ongoing discussion highlights some fundamental disagreement on what a string is/should be. There's an immutable string with free functions group and a fat-interface string group. Either approach looks wrong to me when taken alone. String handling is the thing Java got basically right, IMHO. Java distinguishes between a string class (immutable strings) and a string builder class. Typically, immutable string classes are memory efficient because they allow for sharing instances easily and time efficient because they allows for easy passing of the strings into and out of functions. String builders focus on modifying contents and intend to save memory and execution time and to avoid memory fragmentation by avoiding repeated allocation/copy/disposal sequences (even with views, you'll sometimes need to save intermediate results and to work from there in order to gain performance). std::string tries to be both and that lead to a fat and somewhat confusing interface that is hard to implement efficiently. The proposed super string could be a nice string _builder_, while the proposed functional/view interface could operate nicely on an immutable string class, std::string and on the string builder. Once we distinguish between a string builder and a string, most of the confusing aspects of having two ways of doing the same thing go away. Offering a generic, uniform approach to string handling, free functions and views (supposedly) can work on any kind of string representation, while the string builder can focus on efficient in-place transformations. Use-cases in favor of either approach can be made. Consequently, there's room for both suggested ways of dealing with character sequences and for the libraries supporting them. What we need in order to avoid confusion is to communicate clearly what the intent of the classes or views/functions is. So if we add the suggested super string then PLEASE do not name it 'string', but 'string_builder' or 'string_buffer' in order to emphasize on the in-place modification aspect in the name. Of course, there should be a complement to string_builder: immutable_string. (ISTR there was a proposal for that, already). Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com