[Suggestion] Replace small functions instead of calling them through rayxxxx.h

[Vielfras]

Much of the functionality can be easily replicated directly in .hpp instead of calling the .h equivelent, helping the CPP compiler.

I'm still a newbie at cpp so I'll gladly accept I'm wrong, but IMO the result is much more readable, and unless there's compiler neuance I'm missing, wouldn't it also result in some optimization/permormance gain?

Is this a compatibility decision to decrease chances of changes to raylib breaking raylib-cpp?

Ex. Vector2.hpp

float Length() const {
        return Vector2Length(*this);
}

calls raymath.h

inline float Vector2Length(Vector2 v) {
    float result = sqrtf((v.x*v.x) + (v.y*v.y));

    return result;
}

Replace Length() const with:

constexpr inline float Length() const noexcept {
    return sqrtf((x * x) + (y * y));
} 

[kyomawolf]

TLDR:

1. no, actually the other way around
2. yes The idea behind calling the raylib through the wrapper is to reflect the behavior as intended by the raylib author, so its just a wrapper around the C functions and just written for convenience with C++ and allow proper C++ codning style. Doing the logic directly in the header files is possible, but if the logic changes in the original C library, it might not be catched, and the original intention is lost. It also does not really match the intention of header only library, which is to do as little logic as possible a to keep compile times low, as headers are copied over and compiled every time you use it in another file. Using just the symbol is faster for compile time. And of course, the smaller functions intention and output should be rather clear through their name, if its not, feel free to open a PR with useful comments.

[RobLoach]

Thanks for the summary, kyonawolf. Spot on. And yes, hope to keep this as similar to raylib itself as possible. While what you suggest would improve Performance, performance isn't its primary goal.