gnustep-dev
[Top][All Lists]
Advanced

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

Re: New ABI NSConstantString


From: Ivan Vučica
Subject: Re: New ABI NSConstantString
Date: Thu, 05 Apr 2018 16:01:36 +0000

Layman question: does it make sense to optimize for space, too, and have a smaller structure for tiny constant strings?

For 32bit ptrs and longs, this would be 20 bytes without the string itself. I don't think that's a lot, but I thought I'd ask.

On Thu, Apr 5, 2018, 16:25 David Chisnall <address@hidden> wrote:
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


_______________________________________________
Gnustep-dev mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/gnustep-dev

reply via email to

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