PCH-less compilation fix

[wxWidgets.git] / docs / doxygen / overviews / unicode.h

diff --git a/docs/doxygen/overviews/unicode.h b/docs/doxygen/overviews/unicode.h
index 3261b6d793aca482ae5634309e6148e38c3394c4..e9bc453939e5d182987a948796799b88dda0ce14 100644 (file)
--- a/docs/doxygen/overviews/unicode.h
+++ b/docs/doxygen/overviews/unicode.h
@@ -101,11 +101,12 @@ in the current locale encoding, so writing
 wxMessageBox("Salut à toi!");
 @endcode
 wouldn't work if the encoding used on the user system is incompatible with
-ISO-8859-1. In particular, the most common encoding used under modern Unix
-systems is UTF-8 and as the string above is not a valid UTF-8 byte sequence,
-nothing would be displayed at all in this case. Thus it is important to never
-use 8 bit characters directly in the program source but use wide strings or,
-alternatively, write
+ISO-8859-1 (or even if the sources were compiled under different locale
+in the case of gcc). In particular, the most common encoding used under
+modern Unix systems is UTF-8 and as the string above is not a valid UTF-8 byte
+sequence, nothing would be displayed at all in this case. Thus it is important
+to never use 8 bit characters directly in the program source but use wide
+strings or, alternatively, write
 @code
 wxMessageBox(wxString::FromUTF8("Salut \xc3\xa0 toi!"));
 @endcode
@@ -170,7 +171,7 @@ problems:
     of @c c_str(), it is not needed at all with wxWidgets functions)
   - Compatible with wxWidgets 2.8: @code wxPrintf("Hello, %s", s.c_str()) @endcode
   - Using an explicit conversion to narrow, multibyte, string:
-    @code printf("Hello, %s", s.mb_str()) @endcode
+    @code printf("Hello, %s", (const char *)s.mb_str()) @endcode
   - Using a cast to force the issue (listed only for completeness):
     @code printf("Hello, %s", (const char *)s.c_str()) @endcode
 
@@ -231,11 +232,12 @@ internal representation and this implies that it can't guarantee constant-time
 access to N-th element of the string any longer as to find the position of this
 character in the string we have to examine all the preceding ones. Usually this
 doesn't matter much because most algorithms used on the strings examine them
-sequentially anyhow, but it can have serious consequences for the algorithms
-using indexed access to string elements as they typically acquire O(N^2) time
+sequentially anyhow and because wxString implements a cache for iterating over
+the string by index but it can have serious consequences for algorithms
+using random access to string elements as they typically acquire O(N^2) time
 complexity instead of O(N) where N is the length of the string.
 
-To return to the linear complexity, indexed access should be replaced with
+Even despite caching the index, indexed access should be replaced with
 sequential access using string iterators. For example a typical loop:
 @code
 wxString s("hello");