On 01/07/2014 12:27 PM, Michael Van Canneyt wrote:
if you have use-case 1 (which I doubt, since it is not possible even today) then you're better off using unicodestring anyway.
My argumentation is driven by the experience (some myself, a huge lot by my colleagues) with doing "embedded" M2M-communication projects with multiple protocols and applications (included in the project and/or predefined by customers) and with some programs requiring sophisticated user interaction in multiple languages.
The projects originally were done (mine still are done) using old pre-Unicode Delphi.
Here, strings are used as well to handle texts as to handle byte streams (that might contain binary data or might contain text in whatever encoding).
On top of that, the embedded handling of mass-data here needs to be very fast, handling multiple TCP/IP interfaces at the same time..
Here, of course, for binary strings 8 Bit characters are the only appropriate choice, while for the multi-language text supposedly the best choice is using the encoding the underlying OS offer (e.g. UTF-16 for Windows) throughout the multiple units of the project.
So we are burned regarding the flexibility and the pitfalls of using strings in multiple encoding variants within a single project, leading to the urgent request for allowing to use any TString sibling (in own code and in the RTL) in a way that allows for using arbitrary encoding without forced re-encoding under the hood, if not absolutely necessary.
-Michael _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
