Reply to Sascha,

> Correct me if I'm wrong, but if you want to concatenate two invariant
> strings, you have to allocate a new buffer.

yes, but the invariant part has nothing to do with it. Concatenation always copies.


> LLAP,
> Sascha

Sascha Katzner wrote:
> Correct me if I'm wrong, but if you want to concatenate two invariant strings, you have to allocate a new buffer. Isn't that a possible speed penalty compared to regular strings? Since if you use regular strings you can allocate one of the two string buffers beforehand big enough and save this allocation, with invariant strings you don't have this option.
> 
> ...or to rephrase my question, wouldn't a StringBuilder Class without invariant strings be much faster?

D doesn't *prevent* you from building a string using a mutable character array. The cases where it is faster to do so, however, tend to be modularizable. When the function is done, the result can be cast to an invariant string.

Sean Kelly wrote:
> Janice Caron wrote:
>> On 27/04/2008, Sean Kelly <sean@invisibleduck.org> wrote:
>>> what do they achieve that could not have been
>>> achieved via plain old const strings?
>>
>> In a word: (OK - in three words): Copy On Write.
>>
>> For example, one could write a function
>>
>>     string escape(string s);
>>
>> which escaped certain characters (by preceding them with '\' or
>> whatever). Because s is an array of invariant chars, if nothing needs
>> to be escaped, the function is able to return s.
> 
> So this is predicated on the idea that the optimal strategy is to assume that library functions will not actually need to make any changes the majority of the time, and that they do COW internally.  Fair enough.  I agree that this makes it a clear win for Phobos, which is designed around this assumption.
> 
> 
> Sean

And like Walter mentioned before, most modern high-level languages have invariant strings instead of mutable strings. Java and C# have it, and, if I'm not mistaken, Python and Ruby as well.


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Lars Ivar Igesund wrote:
> Sascha Katzner wrote:
> 
>> Walter Bright wrote:
>>> Most operations are slicing/concatenating, which work just fine on
>>> invariant strings.
>> Correct me if I'm wrong, but if you want to concatenate two invariant
>> strings, you have to allocate a new buffer. Isn't that a possible speed
>> penalty compared to regular strings? 
> 
> Indeed it is, and this is the main reason for Tango being so damn fast at
> text processing.

But note that Tango also is suffering from bugs now that are due to that design choice (i.e. the choice to require pre-allocation for almost all text processing functions).

http://www.dsource.org/projects/tango/ticket/787
http://www.dsource.org/projects/tango/ticket/978

--bb

Bill Baxter wrote:

> Lars Ivar Igesund wrote:
>> Sascha Katzner wrote:
>> 
>>> Walter Bright wrote:
>>>> Most operations are slicing/concatenating, which work just fine on invariant strings.
>>> Correct me if I'm wrong, but if you want to concatenate two invariant strings, you have to allocate a new buffer. Isn't that a possible speed penalty compared to regular strings?
>> 
>> Indeed it is, and this is the main reason for Tango being so damn fast at text processing.
> 
> But note that Tango also is suffering from bugs now that are due to that design choice (i.e. the choice to require pre-allocation for almost all text processing functions).

Only one of those are related to the above, the second is a different issue
(about specification).

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Lars Ivar Igesund wrote:
> Bill Baxter wrote:
> 
>> Lars Ivar Igesund wrote:
>>> Sascha Katzner wrote:
>>>
>>>> Walter Bright wrote:
>>>>> Most operations are slicing/concatenating, which work just fine on
>>>>> invariant strings.
>>>> Correct me if I'm wrong, but if you want to concatenate two invariant
>>>> strings, you have to allocate a new buffer. Isn't that a possible speed
>>>> penalty compared to regular strings?
>>> Indeed it is, and this is the main reason for Tango being so damn fast at
>>> text processing.
>> But note that Tango also is suffering from bugs now that are due to that
>> design choice (i.e. the choice to require pre-allocation for almost all
>> text processing functions).
> 
> Only one of those are related to the above, the second is a different issue
> (about specification).
> 

Ah. Ok.

-bb