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.
DoDi _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
