On 09/10/2013 02:25 AM, [email protected] wrote:
i agree... ANSIstrings should be ANSI only... UTF8string and
UTF16string should be available and used where necessary,
And the "NewStrings" that can (defined statically and - if compiler
magic is done accordingly - dynamically) be used with any encoding,
should have a decent name. That is why I call them "NewStrings", but
this of course is a transient and not a decent denomination.
Do we indeed need to always use the sometimes silly that are suggested
by Embarcadero ?
IMHO... this would seemingly allow for better control as well as
string conversion where necessary...
After some initial concern and some researching, I feel that the
Delphi-like way to implement this kind of strings ("quasi-dynamically"
encoded strings, each containing definitions for code-word width (1, 2,
4 - and extensible to 8 - Bytes) and encoding id (ANSI Code page and
special values for other schemes such as UTF) is a really good idea, and
auto-conversion can be implemented in a rather user-friendly manner.
Only - as pointed out in the other mail -, the Delphi compiler magic is
lacking support for fully dynamically encoded String which IMHO is
doable without any change to the (complex and critical) library and
without a noticeable performance degradation, making the use of these
beasts a lot more flexible - which is much more important with fpc than
with Delphi itself.
Especially providing TStrings and friend (or in fact any library
function) with an interface featuring a predefined encoding, IMHO, is
not a desirable way to go for a system that is supposed to support
multiple OSes and environments.
-Michael
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
