General usage knowledge

General information

Note that RaZ is ever changing. There are always breaking changes, although I try to mark long-used functionalities as deprecated for a while before removing them permanently.

Feel free to reach out to me (preferably through discussions or issues) to ask questions or to make any suggestion. Pull requests will also be appreciated, and reviewed & accepted as soon as possible!

Useful definitions

Using CMake, some definitions are available everywhere in code.

• RAZ_PLATFORM_XXX, where XXX can be WINDOWS, LINUX, MAC, EMSCRIPTEN, CYGWIN or MSYS
• RAZ_COMPILER_XXX, where XXX can be MSVC, GCC, CLANG or CLANG_CL
• RAZ_CONFIG_XXX, where XXX can be either DEBUG (CMake's Debug build type) or RELEASE (all other build types)

This allows to have uniform checks, instead of relying on ugly platform-dependent definitions (and the always-confusing NDEBUG potential double negation).

Naming conventions

Here are referenced some coding conventions I use for RaZ, and which you should care about. As such I won't discuss about tabs vs spaces, lower/upper case or anything, but rather for example function naming that means something when using the library.

This page will be updated once in a while, when I feel necessary to explain something important.

Concerning member functions conventions:

• getXXX() means this is a simple (inlined) returning function, by value if primitive type, by [const] reference otherwise. You should not abuse of those for readability, but there won't be performance issues from this (typical example: fetching a value contained in an instance of an object).
• recoverXXX() are functions seeking for information in various places. Take care when using these, as they can potentially have a performance impact (typical example: fetching data from the graphics card).
• computeXXX() should be used by putting the result in a variable if reused frequently. These functions can do quite heavy computations and may have a huge performance impact if called several times in a row (typical example: calculation of a matrix).

These rules also allow a distinction between different functions from the same class. For example, Camera::computeProjectionMatrix() forces the calculation and returns the result, while Camera::getProjectionMatrix() simply returns the previously computed matrix.