PCSX2 Documentation/WxWidgets Coding Strategies: Difference between revisions

Jump to navigation Jump to search
Line 89: Line 89:
==Guidelines when Using Windows/Linux Specific Code==
==Guidelines when Using Windows/Linux Specific Code==


The simple rule is to not use any windows or linux specific code unless absolutely necessary. Most of the time _wxWidgets_ provisions us with cross-platform alternatives for most tasks, so always make sure to check the wx documentation first. But, of course, there are still cases of advanced coding that wx doesn't cover, and these will need platform specific implementations. For example, there is no direct Linux equivalent of Windows Structured Exception Handling (SEH), and PCSX2 code that uses SEH must either be coded to use Linux signals (if possible) or `#ifdef`'d out under Linux.
The simple rule is to not use any windows or linux specific code unless absolutely necessary. Most of the time ''wxWidgets'' provisions us with cross-platform alternatives for most tasks, so always make sure to check the wx documentation first. But, of course, there are still cases of advanced coding that wx doesn't cover, and these will need platform specific implementations. For example, there is no direct Linux equivalent of Windows Structured Exception Handling (SEH), and PCSX2 code that uses SEH must either be coded to use Linux signals (if possible) or <code>#ifdef</code>'d out under Linux.


===There are two ways to handle separate Windows and Linux implementations===
===There are two ways to handle separate Windows and Linux implementations===


* Create two separate files, one under /Windows and one under /Linux, that each implement a function as according to the platform needs. _(preferred)_
* Create two separate files, one under /Windows and one under /Linux, that each implement a function as according to the platform needs. ''(preferred)''
* Use inline #ifdefs to separate behavior. _(useful for very simple/short differences)_
* Use inline #ifdefs to separate behavior. ''(useful for very simple/short differences)''


As noted, it's generally preferred to create implementations in platform specific files over using `#ifdef`. This helps keep code much cleaner and saner, and is more friendly toward code editors/IDEs as well (most editors handle `#ifdef` poorly, either failing to gray out the unused defines, or by enforcing an ugly tabbing layout that is only suited to function-level codeblock removal). When using platform specific files it's usually preferred to have each filename assigned the platform's tag. Example:
As noted, it's generally preferred to create implementations in platform specific files over using <code>#ifdef</code>. This helps keep code much cleaner and saner, and is more friendly toward code editors/IDEs as well (most editors handle <code>#ifdef</code> poorly, either failing to gray out the unused defines, or by enforcing an ugly tabbing layout that is only suited to function-level codeblock removal). When using platform specific files it's usually preferred to have each filename assigned the platform's tag. Example:
```
<nowiki>
     /Windows/WinSpecific.cpp
     /Windows/WinSpecific.cpp
     /Linux/LnxSpecific.cpp
     /Linux/LnxSpecific.cpp
```
</nowiki>
... as this provides a clear identifier to cross-platform programmers which files they're looking at when they use things like Find-in-Files and other global search tools.
... as this provides a clear identifier to cross-platform programmers which files they're looking at when they use things like Find-in-Files and other global search tools.