[fpc-devel] cpstrrtl/unicode branch merged to trunk
DrDiettrich1 at aol.com
Fri Sep 6 15:59:48 CEST 2013
Michael Schnell schrieb:
> Of course I need to jump in here ...
Of course ;-)
> While I don't exactly know what you are up to, you might want to read
> some recent posts of mine where I pointed out that using a fully
> dynamically encoding auto-converting String type (which does not seem to
> exist in Delphi) for Objects (and other things) that should not
> predefine a certain encoding in their interface (making the thingy
> useful for other Strings while avoiding unnecessary (auto-) conversion)
> will not impose any noticeable performance degradation, provided some
> appropriate compiler magic is implemented.
I know your point.
> Of course I might be wrong with this analysis, but I _did_ some decent
> thinking on that.
You defer the problem from the interface to the implementation. When a
procedure has an string parameter of an unknown encoding, the
implementation must check every time the *current* encoding of the
parameter, and proceed as appropriate. I.e. *all* possible encodings
must be handled (implemented) inside the procedure, what's almost
impossible. That's why a concrete implementation only can check for a
number of cases, which can be implemented in specialized code, and
handles all remaining cases in the general (Unicode) way.
With already specialized (overloaded) versions of a routine there exists
no reason for checks and different handling. What can be handled in
existing specializations is determined at compile time, and all
unhandled cases are passed immediately to the universal (Unicode) version.
More information about the fpc-devel