1. Read the summary.
See the history of suffering and become bothered too each time you read the lowercase() for no reason.
2. Should the event name constants use the `m_` prefix?
The Trac:CodingConventions page speaks of member variables using that, member functions using `FooBar` case. Strictly speaking, static const members are not member variables, and there are essential differences between member variables and const static members.
* (1), (2) Variables are once per class instance and are variable, static const members are invariable, created only once per program launch
* (3) (more importantly) member variables are assigned with `m_Foo = bar` and `m_Foo(bar)`, but static const members are initialized with `const T FooClass::m_Foo = bar`.
Member functions (those that aren't `std::function`) are created only once per program launch too and are invariable afaik (ignoring class inheritance).
So `const T FooClass::BarMember = value;` more resembles the member function syntax and semantics than `const T FooClass::m_BarMember = value;`.
3. Perhaps check with clang optimization report if the static const string EventNames are already created by clang.
I used `CC="clang -Rpass=inline" CXX="clang++ -Rpass=.*" make -j3` and got this for the one line I tested:
```
../../../source/ps/GameSetup/GameSetup.cpp:199:2: remark: _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED2Ev inlined into _Z23GUI_DisplayLoadProgressiPKw with (cost=10, threshold=250) [-Rpass=inline]
g_GUI->SendEventToAll(/*g_EventNameGameLoadProgress*/"GameLoadProgress", paramData);
^
../../../source/ps/GameSetup/GameSetup.cpp:199:55: remark: _ZN5CStr8C2EPKc inlined into _Z23GUI_DisplayLoadProgressiPKw with (cost=140, threshold=250) [-Rpass=inline]
g_GUI->SendEventToAll(/*g_EventNameGameLoadProgress*/"GameLoadProgress", paramData);
^
../../../source/ps/GameSetup/GameSetup.cpp:199:75: remark: _ZN2JS16HandleValueArrayC2ERKNS_16AutoVectorRooterINS_5ValueEEE inlined into _Z23GUI_DisplayLoadProgressiPKw with (cost=-40, threshold=375) [-Rpass=inline]
g_GUI->SendEventToAll(/*g_EventNameGameLoadProgress*/"GameLoadProgress", paramData);
^
../../../source/ps/GameSetup/GameSetup.cpp:199:2: remark: _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED2Ev inlined into _Z23GUI_DisplayLoadProgressiPKw with (cost=10, threshold=250) [-Rpass=inline]
g_GUI->SendEventToAll(/*g_EventNameGameLoadProgress*/"GameLoadProgress", paramData);
^
```
But even if it does optimize it, writing the code this way will **enforce** this even if the optimizer is stupid or the compiler old, and it
will allow us to reuse these static const members in other contexts (getting compile errors when adding typos).
4. Consider whether `char*` would be preferable over `CStr`.
What speaks for `CStr` is that
4.1. Trac:CodingConventions recommend using CStr over std::string, since it provides more functions, for example UTF8 conversion or lowercase.
4.2. `IGUIObject::RecurseObject` parameter pack currently complains about not receiving a refernce.
4.3. If one uses `char*` then it means one will have to create a `CStr` the moment one will need a `CStr`, whereas using `CCtr` as the const static member type means both `CStr&` and `char*` arguments can be provided without copying the string.
4.4. `CStrIntern` may be another candidate. However it does not appear to be as attractive as advertizes. When creating a `CStrIntern` it performs hashing on the string, which is the same as an std::map or std::unordered::map find with string keys, so basically the same.