Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
wxString support in wxWidgets 3.0 problem?
ollydbg:
I have read this:
wxWidgets: wxString Class Reference
Then, I found that in wxWidgets 3.0, the wxString class will internally use different "code unit", which is utf8 under Linux like system, and utf16 under windows.
Both of them were variable length code point Unicode representation, so index reference like:
--- Code: ---wxString s;
s[20]= something;
--- End code ---
will have very low performance compared with sequence iterator.
I'm not sure what does the currently implementation, but does this will cause potential issue in the feature?
EDIT 2013-10-18:
--- Quote ---I found that in wxWidgets 3.0, the wxString class will internally use different "code unit", which is utf8 under Linux like system, and utf16 under windows.
--- End quote ---
This is not correct, now all use fixed width unit (wchar_t), see this post http://forums.codeblocks.org/index.php/topic,14421.msg126174.html#msg126174 for explanation.
Ceniza:
All I can find is that they use a bigger type (4 bytes) in order to be able to store all code points, but they also say the implementation will be around basic_string.
Calling operator [] will call method at() which will call begin() and PosToImpl() and return it through a call to DecodeChar which will return a small object wxUniCharRef which will handle the assignment by creating a wxUniChar which will be assigned to an iterator, or something along those lines.
Most, if not all, of those methods were one-liners in the header file, so there is a good chance the produced code will be decently optimized. It would be nice to actually see what the compiler can do with it before we worry too much. It also seems like the current implementation is about the same anyway.
ollydbg:
--- Quote from: Ceniza on March 27, 2011, 11:23:34 am ---All I can find is that they use a bigger type (4 bytes) in order to be able to store all code points, but they also say the implementation will be around basic_string.
Calling operator [] will call method at() which will call begin() and PosToImpl() and return it through a call to DecodeChar which will return a small object wxUniCharRef which will handle the assignment by creating a wxUniChar which will be assigned to an iterator, or something along those lines.
Most, if not all, of those methods were one-liners in the header file, so there is a good chance the produced code will be decently optimized. It would be nice to actually see what the compiler can do with it before we worry too much. It also seems like the current implementation is about the same anyway.
--- End quote ---
current implementation use the same method (4 bytes for a code point)??
PS:I received a email notifier that you have replied minutes ago on Code completion doesnt follow #include in struct, but I do not see this post on that thread, strange, did you delete this?
Ceniza:
--- Quote from: ollydbg ---current implementation use the same method (4 bytes for a code point)??
--- End quote ---
It looks like the current implementation uses either wchar_t or char depending on how you configure wxWidgets. It is kind of difficult to be completely sure of all the differences by jumping everywhere in the svn repository.
--- Quote from: ollydbg ---PS:I received a email notifier that you have replied minutes ago on Code completion doesnt follow #include in struct, but I do not see this post on that thread, strange, did you delete this?
--- End quote ---
The forum thought it was spam, but it seems to be fixed now. I do not have the powers to un-smap myself :P
P.S.: This post was considered spam too. Probably due to all links in the quotes.
JGM:
mmm I'm getting the same result, marking some of my messages as spam
Navigation
[0] Message Index
[#] Next page
Go to full version