On 1 Apr 2018, at 14:06, Richard Frith-Macdonald
<richard.frith-macdon...@theengagehub.com> 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
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
