[fpc-devel] Unicode proceedings

[DaWorm]

Perhaps a little extra compiler magic could be used?  If the base
definition of a string (the hidden stuff before the data) contains not only
a field with the encoding, but a flag indicating the disposition of the
encoding, then when a string type is aliases, that disposition could be
overridden.  I'm on my phone, so this may be hard to show an example:

type String = record
  encoding: TEncoding;
  disposition: Tdisposition;
  data: Tbytes;
end;

Disposition would have values like:

fixed - will always be in this encoding, anything assigned to a variable of
this type will be automatically converted.  Any out parameter of this type
will be initialized to an empty string of this encoding.

open - encoding only defines initial encoding.  Assigning a string of
another type will result in this string taking on that type, but NOT that
type's disposition.  Out parameters initialized to the given encoding.

strict - only compatible with other strings of the same type, period.  Try
to assign a string of a different type, compile time error.  Will force
manual conversion between encoding (possibly via typecast that calls
internal encoding translation).

Example:
type ANSIString = String encoding UTC16 disposition fixed;

Syntax is probably all wrong, but hopefully you get the idea.  If the real
lowest level is something other than String, then String itself can be an
alias that is different for each platform to match that platforms native
type.

It seems something like this would let the people who just want to use
strings in a consistent way and not worry about conversion performance to
do so, and those who want speed to have the compiler help them out by
stopping them from creating code with lots of conversions.

Or, I may be completely off base.

Jeff.
On Nov 18, 2011 6:44 AM, "Michael Schnell" <mschnell at lumino.de> wrote:

> On 11/18/2011 11:21 AM, Graeme Geldenhuys wrote:
>
>>
>> Can't we just have a single damn string type like Java and some other
>> languages. Lets just call it...ummm.... String!  ;-)
>>
> This has been discussed at any length here and in many other forums. This
> is what I tried to describe in (B). It has been turned down as it's not
> possible to implement this providing predictable performance.
>
> -Michael
> ______________________________**_________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/**mailman/listinfo/fpc-devel<http://lists.freepascal.org/mailman/listinfo/fpc-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20111118/60694ade/attachment.html>