From 0becbf33e6f4cea9acc2c05c3f9583c8cddba406 Mon Sep 17 00:00:00 2001 From: arcum42 Date: Thu, 25 Nov 2021 21:12:06 -0800 Subject: [PATCH] As we'd like to move away from wx at some point in future, no longer recommend using it in code that doesn't need it. --- Code-Formatting-Guidelines.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Code-Formatting-Guidelines.md b/Code-Formatting-Guidelines.md index b1f0218..0335499 100644 --- a/Code-Formatting-Guidelines.md +++ b/Code-Formatting-Guidelines.md @@ -14,9 +14,9 @@ Besides being obscenely ugly, this naming convention is totally impractical for **Just don't do it. _Ever._** -## Topic 2: Using PCSX2 and wxWidgets base types instead of C/C++ atomic types. +## Topic 2: Using PCSX2 base types instead of C/C++ atomic types. -Most of the time you want to use either PCSX2 or wxWidgets cross-platform types in the place of C++ atomic types. Most of the common types are: +Most of the time you want to use either PCSX2 cross-platform types in the place of C++ atomic types. Most of the common types are: ```C++ u8, s8, u16, s16, u32, s32, u64, s64, u128, s128, uptr, sptr ``` @@ -26,6 +26,8 @@ Note that using the C++ atomic types `float` and `double` are acceptable, and th **Special note:** PCSX2-specific types `uptr` and `sptr` are meant to be integer-typed containers for pointer addresses, and should be used in situations where pointer arithmetic is needed. `uptr/sptr` definitions are not type safe and `void*` or `u8*` should be used for parameter passing instead, when possible. +wxWidgets base types are no longer preferred, and should be avoided when possible, though they can be used as needed when dealing with gui code. + ## Topic 3: Do not use `private` class members; use `protected` instead. There is no justifiable reason for any class in PCSX2 to use private variable members. Private members are only useful in the context of _dynamically shared core libraries_, and only hinder the object extensibility of non-shared application code. Use `protected` for all non-public members instead, as it protects members from unwanted public access while still allowing the object to be extended into a derived class without having to waste a lot of silly effort to dance around private mess.