[fpc-devel] cpstrrtl/unicode branch merged to trunk

[Hans-Peter Diettrich]

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