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 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