[fpc-devel] But what /is/ a string?

Graeme Geldenhuys graeme at geldenhuys.co.uk
Mon Aug 27 12:44:04 CEST 2012


On 27/08/12 09:43, Marco van de Voort wrote:
> Seriously, even if you forget compatibility, it is impossible to assess
> something like that without in-depth design (and preferably a test
> implementation).

Wouldn't something like Java's String and Character classes already be 
good in-depth reference implementation of this? Java is extremely 
successful, so we know their implementation is good too. The same can be 
said for Qt's QString class.

I had a quick 30 minute investigation into the Java String class. I 
quite like the idea of an immutable string too. This will make 
multi-threaded data access super easy - no need to worry about threads 
modifying your string instance.

In FPC terms, then String class can be a reference counted IInterface 
class, so we don't have to worry about freeing every string instance.

I also like the fact that in the Java String class implementation, there 
is nothing left to "guess work" for the developer. Methods like 
.length(), .charAt(), .codePointAt() etc are pretty self explanatory, 
and if in doubt, the documentation clearly states what those method do, 
what they return and how surrogate pairs (Java uses UTF-16 internally) 
are handled.

I must add that Java (and Qt QString) do include some compiler magic to 
make instantiation and concatenation slightly easier. But in both cases 
they clearly document how it could be used, and mention pitfalls if any.

Qt's QString also has methods like .toUTF8(), .fromUTF8(), 
.fromRawData(), .toLatin1(), .fromLatin1() - again making it super easy 
to see what is going on and what will happen - no developer guessing 
required, or having to double check the string types to see what 
conversion are going to happen.


Anyway, I did say.... "hypothetically" in my first message. :)


Regards,
   - Graeme -




More information about the fpc-devel mailing list