- So why do we have all these overloaded operator[]s? A bit of history:
- initially there was only one of them, taking size_t. Then people
- started complaining because they wanted to use ints as indices (I
- wonder why) and compilers were giving warnings about it, so we had to
- add the operator[](int). Then it became apparent that you couldn't
- write str[0] any longer because there was ambiguity between two
- overloads and so you now had to write str[0u] (or, of course, use the
- explicit casts to either int or size_t but nobody did this).
-
- Finally, someone decided to compile wxWin on an Alpha machine and got
- a surprize: str[0u] didn't compile there because it is of type
- unsigned int and size_t is unsigned _long_ on Alpha and so there was
- ambiguity between converting uint to int or ulong. To fix this one we
- now add operator[](uint) for the machines where size_t is not already
- the same as unsigned int - hopefully this fixes the problem (for some
- time)
-
- The only real fix is, of course, to remove all versions but the one
- taking size_t...
+ Note that we we must define all of the overloads below to avoid
+ ambiguity when using str[0]. Also note that for a conforming compiler we
+ don't need const version of operatorp[] at all as indexed access to
+ const string is provided by implicit conversion to "const wxChar *"
+ below and defining them would only result in ambiguities, but some other
+ compilers refuse to compile "str[0]" without them.