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 <gnus...@theravensnest.org> wrote:
> 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
>
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
