DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2505 Version: 1.3-current Quite right, the gist of it is that it converts the encoding to wchar_t to exploit the side effect of sanitizing the string. For the issues: 1. Dynamic arrays I'll have a look at this and post an updated patch. 2. sizeof() checks Yeah, I'm not particularly proud of this one. The basic problem is that wchar_t is not well defined when it comes to size, so there needed to be something. Preferably I'd have a preprocessor check, but I didn't have any defines to work with. Things can be improved by adding a check in configure for this. 3. Performance As you say, the performance hit is already there for Windows so as far as the project goes, it has been deemed acceptable. Improvements might be possible, but I suspect they're small. The conversion from UTF-8 to UCS-4 is a fairly simple one, and the extra cycles needed compared to only parsing and validating the UTF-8 string are probably negligable. The big performance hog will most likely be the malloc(). But let's not kid ourselves. This is C++, so there are stray malloc():s hidden all over the place when objects get flung around. So unless someone can show me numbers that this is causing any tangible slowdown, I'd consider this a case of premature optimization. :) Link: http://www.fltk.org/str.php?L2505 Version: 1.3-current _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
