In our previous episode, Sven Barth said: > > The difference is more that I don't think it will solve as much as people > > think, and using this to stitch together code from different origins will > > fail miserably or be unworkable. > > For non-inheritance-related code that is encoding-agnostic this should > be not that much of a big problem, because the compiler will add > conversions then.
That's fine as a temporary solution. But keep in mind that such conversions are different from calling e.g. a RTL function (except string functions) that also forces a conversion. This because whatever the RTL does will most likely be relatively slow, while redundant conversions between businesscode->(some fcl class) -> (base classes) can hurt horribly. They are fine for the transition period, but long term you want to get rid of unnecessary conversions. > The problametic parts - as you yourself metioned - > will be inheritance (when you need to "guess" the correct string for > your override to work) and - I assume - loading and saving of resources > (DFM/LFM). And var parameters, procedure/function types with string parameters used across units etc. And that is just from memory, when testing probably more will be found. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
