PCSX2 Documentation/WxWidgets Coding Strategies: Difference between revisions

PCSX2 Documentation/WxWidgets Coding Strategies (view source)

Revision as of 23:19, 8 January 2015

20 bytes removed , 8 January 2015

no edit summary

Krysto

ninja

782

edits

@@ Line 3: / Line 3: @@
 This means that you should, whenever possible, use the following classes instead of other common alternatives:
-  * `wxString` instead of `std::string` or `std::wstring`.
+* `wxString` instead of `std::string` or `std::wstring`.
-  * `wxChar` instead of `TCHAR`
+* `wxChar` instead of `TCHAR`
-  * `wxString::Format` and `wxString::Printf` (available also via the shortcut `wxsFormat`) instead of `sprintf, snprintf`, or `ssprintf`.
+* `wxString::Format` and `wxString::Printf` (available also via the shortcut `wxsFormat`) instead of `sprintf, snprintf`, or `ssprintf`.
-  * `wxDateTime` instead of POSIX ctime or Windows date functions.
+* `wxDateTime` instead of POSIX ctime or Windows date functions.
-  * `wxFile` instead of `FILE` or Windows `OpenFile` (yes `wxFile` supports files over 4gb).
+* `wxFile` instead of `FILE` or Windows `OpenFile` (yes `wxFile` supports files over 4gb).
-  * Use the `wx*` alternatives for any ANSI C library function, such as `wxGetCwd, wxStrlen`, etc. (as wx should provide platform independent versions of almost everything).
+* Use the `wx*` alternatives for any ANSI C library function, such as `wxGetCwd, wxStrlen`, etc. (as wx should provide platform independent versions of almost everything).
-### There are some exceptions to this last rule:
+'''There are some exceptions to this last rule:'''
-  * We use our own internal `pxThread` class instead of `wxThread`, mostly due to the w32pthreads library being much more robust and efficient than wx's cross-platform threading. (some `wxThread` static functions are still are of use, however, such as `wxThread::IsMain()`).
+* We use our own internal `pxThread` class instead of `wxThread`, mostly due to the w32pthreads library being much more robust and efficient than wx's cross-platform threading. (some `wxThread` static functions are still are of use, however, such as `wxThread::IsMain()`).
-  * wxWidgets logging facilities are poorly designed and not at all suited to PCSX2 needs. We have our own `Console` and `SourceLog` systems instead. `Console` uses the `IConsoleWriter` interface internally and supports both Unicode and console output redirection. `SourceLog` is intended for high volume logging (trace logs of PS2 execution) and is optimized to write untranslated ASCII text to logfile.
+* wxWidgets logging facilities are poorly designed and not at all suited to PCSX2 needs. We have our own `Console` and `SourceLog` systems instead. `Console` uses the `IConsoleWriter` interface internally and supports both Unicode and console output redirection. `SourceLog` is intended for high volume logging (trace logs of PS2 execution) and is optimized to write untranslated ASCII text to logfile.
-  * Console logging and devel/debug messages do not need to be translated, and do not need to use `wxString` to maintain proper cross-platform unicode support. All console logging functions can use either plain `ASCII-Z (char*)` string and functions or `wxChar*`; 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 `wxString` to maintain proper cross-platform unicode support. All console logging functions can use either plain `ASCII-Z (char*)` string and functions or `wxChar*`; 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 `wxChar`or `wxString.` This is done largly for performance reasons.
+* Trace logging is meant to be used for ASCII/UTF8 text only, and has no support for `wxChar`or `wxString.` This is done largly for performance reasons.
-  * Forego the use of `_T()` or `wxT()`, in favor of the now-standard `L''` for denoting unicode strings. wx2.8 stores all strings in wchar_t format internally on all supported platforms, so `L""` 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 `_T()` or `wxT()`, in favor of the now-standard `L''` for denoting unicode strings. wx2.8 stores all strings in wchar_t format internally on all supported platforms, so `L""` 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...?)