On 11 Oct 2011, at 04:00, Marco van de Voort wrote:
> I know that Florian and you wanted to see the default string as something of a
> dialect mode, but I never saw a way to do that practically.
How about this: a new language feature is added to the compiler that enables
defining a type alias that resolves to a different type depending on whether
{$modeswitch unicodestrings} is active in the current code. If necessary, it
could also be extended for functions/procedures (but I'd like to use it as
sparingly as possible).
E.g. (with the first statement obviously in need of being replaced with
something more legible)
type
// needs to be defined in advance with this particular syntax so that the
// compiler will write "tstringlist" as the type name in the RTTI of the
// two classes below;
// the compiler will still generate separate RTTI for both classes though
tstringlist =
FpcStringModeDifferentiatedType(tansistringlist,tunicodestringlist);
tansistringlist = class
<ansi stringlist code>
end;
tunicodestringlist = class
<unicode stringlist code>
end;
(obviously, you could also implement both types using generics, include files
and macro substitution, etc). An alternative could be to extend the syntax for
generics or specializations and incorporate such functionality there, but that
is only practical if in all cases the two different classes can be expressed
using a single generic implementation.
Such a feature would enable duplicating functionality where absolutely
necessary for compatibility reasons (e.g., inside the classes unit) without
adding the complexity of having two completely separate RTLs. And the result
should be completely compatible with both code written for an ansistring-based
and for a unicodestring-based RTL. In fact, if I'm not missing anything it
would also make combining components depending on an ansistring-based and on a
unicodestring-based RTL into a single program possible (at the expense of
including two copies of some data structures, of course, but nobody forces you
to do this; it's simply an option that's available).
Jonas_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
