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" <mschn...@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@lists.freepascal.org > http://lists.freepascal.org/**mailman/listinfo/fpc-devel<http://lists.freepascal.org/mailman/listinfo/fpc-devel> >
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
