PCSX2 Documentation/WxWidgets Coding Strategies: Difference between revisions

Line 17: Line 17:
* Console logging and devel/debug messages do not need to be translated, and do not need to use <code>wxString</code> to maintain proper cross-platform unicode support. All console logging functions can use either plain <code>ASCII-Z (char*)</code> string and functions or <code>wxChar*</code>; depending on whichever is more convenient at the time.
* Console logging and devel/debug messages do not need to be translated, and do not need to use <code>wxString</code> to maintain proper cross-platform unicode support. All console logging functions can use either plain <code>ASCII-Z (char*)</code> string and functions or <code>wxChar*</code>; depending on whichever is more convenient at the time.
* Trace logging is meant to be used for ASCII/UTF8 text only, and has no support for <code>wxChar</code>or <code>wxString.</code> This is done largly for performance reasons.
* Trace logging is meant to be used for ASCII/UTF8 text only, and has no support for <code>wxChar</code>or <code>wxString.</code> This is done largly for performance reasons.
* Forego the use of <code>_T()</code> or <code>wxT()</code>, in favor of the now-standard <code>L' '</code> for denoting unicode strings. wx2.8 stores all strings in wchar_t format internally on all supported platforms, so <code>L""</code> is sufficient for full cross platform support. In the event we upgrade to wx3.0 this won't be a 'perfectly' optimal scenario in Unix builds, since wx3.0 on Linux will store strings in UTF8 format internally anyway (but provides automatic conversions, so it will still compile and run without error). The overhead is in non-critical scenarios where I'm willing to sacrifice some cpu load in favor of cleaner code.
* Forego the use of <code>_T()</code> or <code>wxT()</code>, in favor of the now-standard <code>L\''</code> for denoting unicode strings. wx2.8 stores all strings in wchar_t format internally on all supported platforms, so <code>L""</code> is sufficient for full cross platform support. In the event we upgrade to wx3.0 this won't be a 'perfectly' optimal scenario in Unix builds, since wx3.0 on Linux will store strings in UTF8 format internally anyway (but provides automatic conversions, so it will still compile and run without error). The overhead is in non-critical scenarios where I'm willing to sacrifice some cpu load in favor of cleaner code.


(any others...?)
(any others...?)
ninja
782

edits