In our previous episode, Michael Schnell said: > > multi-encoding/multi-charsize. At the moment msestring=UnicodeString for > > FPC > > 2.4 which is perfect. I fear FPC will drop this simple solution where it > > was > > ahead of Delphi. > > Hmmm. I suppose with Linux (using utf-8 for the GUI interface to the > user programs), having the user program always use Widestring internally > and convert any GUI input and output string will feature an enormous > overhead.
The real GUI part is not the real performance dependant part. GTK2 slow performance comes from little optimizations and portability layering, much less design choices. The only problem is the db-aware part and the few other widgets that can have 100000 elements and more, like treeview. There mass conversion can hurt, e.g. when loading the data into the widget. That is probably solvable (caching, only translating at the moment of viewing etc). But in general I think codepage conversions are a different magnitude from general processing. > I feel that just handling the multi-encoding String-management record > (with "encoding"6 and "character-size", which, in the case of GUI > generated and "meant for GUI" Strings, always is equal), would not > impose much overhead over using using the plain old String management > with just "reference-counter" and "contents-pointer". Neither do I. While I think it would be best to use native encoding on all platforms as much as possible, that is an opinion. However not using native encoding for general processing is nuts. So we need the UTF8 type anyway. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
