string is rarely useful as a function argument

[Gor Gyolchanyan]

oops. I accidentally made a recursive call in the setter. scratch
that, it should change the attribute.

On Thu, Dec 29, 2011 at 6:58 PM, Gor Gyolchanyan
<gor.f.gyolchanyan at gmail.com> wrote:
> What if the string converted itself from utf-8 to utf-32 back and
> forth as necessary (utf-8 for storing and utf-32 for processing):
>
> struct String
> {
> public:
>    bool encoded() @property const
>    {
>        return _encoded;
>    }
>
>    bool encoded(bool should) @property
>    {
>        if(should)
>            if(!encoded)
>            {
>                _utf8 = to!string(_utf32);
>                encoded = true;
>            }
>        else
>            if(encoded)
>            {
>                _utf32 = to!dstring(_utf8);
>                encoded = false;
>            }
>    }
>
>    // Here goes the part where you get to use the string
>
> private:
>    bool _encoded;
>    union
>    {
>        string _utf8;
>        dstring _utf32;
>    }
> }
>
> This has a lot of drawbacks and is purely a curiosity. The idea of
> expressing the encoding of string as a property of strings, rather,
> then a difference between separate types of strings.
>
> On Thu, Dec 29, 2011 at 1:02 PM, Walter Bright
> <newshound2 at digitalmars.com> wrote:
>> On 12/29/2011 12:12 AM, Gor Gyolchanyan wrote:
>>>
>>> This a a great idea! In this case the default string will be a
>>> random-access range, not a bidirectional range. Also, processing
>>> dstring is faster, then string, because no encoding needs to be done.
>>> Processing power is more expensive, then memory. utf-8 is valuable
>>> only to pass it as an ASCII string (which is not too common) and to
>>> store large chunks of it. Both these cases are much less common then
>>> all the rest of string processing.
>>
>>
>> dstring consumes 4x the memory, and this can easily cause perf degradations
>> due to thrashing and poor cache locality.
>
>
>
> --
> Bye,
> Gor Gyolchanyan.



-- 
Bye,
Gor Gyolchanyan.