User forums > Nightly builds
The 27 November 2010 build (6863) is out.
Jenna:
--- Quote from: oBFusCATed on February 01, 2011, 11:12:06 pm ---The reason this breaks is because wxArrayString::operator[] is declared like this:
wxString& operator[](size_t nIndex) const { return Item(nIndex); }
What were they thinking :(
--- End quote ---
It's clearly stated at the top of the wxArrayString documentation.
So I think it's not a wxWidgets errror, but an incorrect use of the operator[]-function !
--- Quote from: http://docs.wxwidgets.org/stable/wx_wxarraystring.html#wxarraystring ---The references returned by Item, Last or operator[] are not constant, so the array elements may be modified in place like this
array.Last().MakeUpper();
--- End quote ---
EDIT:
By the way, it's the same for all array classes in wxWidgets !
EDIT II:
--- Quote from: oBFusCATed on February 01, 2011, 11:12:06 pm ---p.p.s. I'm talking to the wx guys about this... and until this problem is fixed I advise anyone to not use wxArrayString and to check all the code using it, because there is a chance you have hidden bugs in your code...
--- End quote ---
Use it, but read (and understand) the documentation (as always) !!
oBFusCATed:
The wx guys think the same:
--- Quote ---(00:33:31) heinz: obfuscated: it's a balance between making it harder to shoot yourself in the foot and actually saving bytes and cycles.
--- End quote ---
:shock: :? :x
But the API is broken (in my opinion) and it is really surprising way to do it, no matter if they are proud that they've save 3 bytes + 3 cycles.
--- Quote from: jens on February 02, 2011, 08:12:50 am ---Use it, but read (and understand) the documentation (as always) !!
--- End quote ---
Yeah, yeah, no one reads the docs for such things...
Jenna:
--- Quote from: oBFusCATed on February 02, 2011, 08:23:52 am ---The wx guys think the same:
--- Quote ---(00:33:31) heinz: obfuscated: it's a balance between making it harder to shoot yourself in the foot and actually saving bytes and cycles.
--- End quote ---
:shock: :? :x
But the API is broken (in my opinion) and it is really surprising way to do it, no matter if they are proud that they've save 3 bytes + 3 cycles.
--- Quote from: jens on February 02, 2011, 08:12:50 am ---Use it, but read (and understand) the documentation (as always) !!
--- End quote ---
Yeah, yeah, no one reads the docs for such things...
--- End quote ---
Why is the API broken ?
It's defined as it is, and did not change without warning.
There is no need to have a const overload of operator[], even if many API's provide it, and wxWidgets devs could do it also, without loosing anything (I think).
If a user does not read the docs, he can not blame the software !
And if operator[] would not change target[ i ] (in our case), the whole code in cc would not make any sense !!
oBFusCATed:
--- Quote from: jens on February 02, 2011, 09:09:29 am ---And if operator[] would not change target[ i ] (in our case), the whole code in cc would not make any sense !!
--- End quote ---
If you get a const object you expect that you can modify its get and you rely on the compiler to stop you from doing stupid things.
In the wxArrayString's case they allow you to do stupid things -> you can change a value you are not supposed to change.
MortenMacFly:
--- Quote from: oBFusCATed on February 02, 2011, 09:38:02 am ---If you get a const object you expect that you can modify [...]
--- End quote ---
This is true, but I have to agree with Jens: As you know declaring a member function as const tells the compiler only, that the member function will not modify the internal object's data which does not happen, indeed. So internally it's not modified thus it's externally const which is correct. So it's really our fault if we modify the reference externally. The only feasible "solution" for wxWidgets would be to add another method that returns a const wxString...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version