gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New ABI NSConstantString


From: David Chisnall
Subject: Re: New ABI NSConstantString
Date: Thu, 5 Apr 2018 16:24:38 +0100

On 1 Apr 2018, at 14:06, Richard Frith-Macdonald <address@hidden> wrote:
> 
> 
> I wasn't aware of that ... it would make sense for your new ABI, when 
> individual bits, to have them specified as particular bits rather than as a 
> bitfield, avoiding the possibility of problems with different compilers.
> 
> I don't think you should feel constrained to follow the current layout ... 
> IMO the current one is good for years yet but probably not for decades.
> However, I do think that it's more sensible to have pointer, count, hash, and 
> flags similar to the current GNUstep layout than to follow Apple (and to bear 
> in mind that its convenient for mutable strings to share a layout with 
> constant ones).

How about this:

struct {
        // Class pointer
        id isa;
        // Pointer to the buffer.  ro_data section, so immutable.  
NULL-terminated
        const char *data;
        // Number of characters, not including the null terminator
        long count;
        // Number of bytes in the encoding, not including the null terminator.
        long length;
        // Murmur 3 hash
        uint32_t hash
        // Flags bitfield:
        // Low 2 bits, enum with values:
        //   0: ASCII string
        //   1: UTF-8 but not ASCII string
        //   2: UTF-16 string
        //   3: Reserved for future encodings
        // (1<<2): has mumur3 hash
        // (1<<3) to (1<<15): Reserved for future compiler-defined flags
        // (1<<16) to (1<<31): Reserved for use by the constant string class
}

I think that this should give everything that we need, plus room for easy 
future expansion.

David




reply via email to

[Prev in Thread] Current Thread [Next in Thread]