Rescope raylib.h into raylib::impl namespace

Algias commented 4 years ago

Currently, the following code is included outside of namespace raylib, which pollutes the global namespace with raylib functions and types which can occasionally cause collisions. Is it possible to move this include into the raylib namespace? Many of the scope operators will have to be adjusted but I think this might result in some cleaner code. Also, I believe that the __cplusplus guards are not necessary when directly including a c header. I think this is typically used around C code that can be compiled by both a c & c++ compiler. The extern "C" is definitely still necessary though. Apologies if I am missing something. https://isocpp.org/wiki/faq/mixing-c-and-cpp#include-c-hdrs-system

#ifdef __cplusplus
    extern "C" {
#endif
#include "raylib.h"
#ifdef __cplusplus
    }
#endif

Edit: extern "C" guards are in raylib.h already. It does not appear that it is necessary to include it in raylib-cpp

RobLoach commented 4 years ago

Mind submitting a PR as a demonstration of what you're suggesting? Seems like a neat idea.

Algias commented 4 years ago

Mind submitting a PR as a demonstration of what you're suggesting? Seems like a neat idea.

Please see #46. A quick example showing what I mean. As I mention in the pr, its really a matter of design preference. Ultimately what I would personally like to see is a complete c++ wrapper around the c functionality so that it can be fully object-oriented. If that is not how you guys want to handle it, totally understand and I am more than happy to work with it as is.

RobLoach commented 3 years ago

@marinedalek said.... I'd tend to agree with Algias's suggestion here. If raylib-cpp is to be an "idiomatic" C++ wrapper, then it ought not to transitively dump names into the global namespace when included. My opinion is that changing how people (i.e. C++ users) use Raylib is the whole point of such a wrapper. Any and all functionality should be presented in the raylib:: namespace and the choice of whether to expose that in the global namespace left up to the consumer of the header.

My own preference would be for the low-level C raylib functions to be present in a nested namespace, perhaps raylib::impl:: , to signal to users that they should be using the high-level OOP/RAII constructs rather than the C underpinning. Even then, a determined user would be able to use the header in the current "mixed" mode by adding using namespace raylib::impl; to their source file, while everyone else enjoyed a clean, unpolluted global namespace.

Some concerns I have with rescoping the C library....

raylib will include other header files, which will be moved into the namespace. glfw, for example, doesn't expect to have any namespaces.
As you mentioned, it does change how people expect to use raylib. raylib-cpp doesn't aim to change the way people interact with raylib, however. raylib-cpp hopes to add on top of it to improve the experience, not explicitly change it.

We could introduce a #define to allow the rescope, but I'm not sure the benefits outweigh the potential harm it may cause.

thar0x29a commented 2 years ago

So ... why not putting the cpp version into its own namespace then? That would at least make the --allow-multiple-definition flag obsolete. And I consider it as pretty dangerous to be active in my projects..

RobLoach commented 1 year ago

So ... why not putting the cpp version into its own namespace then? That would at least make the --allow-multiple-definition flag obsolete. And I consider it as pretty dangerous to be active in my projects..

To avoid conflicts. When you use...

Vector4 vec

Are using raylib's Vector4 struct? Or are referencing raylib-cpp's Vector4 class?

There are the shorthand aliases available, however...

RVector4
RMatrix
RTexture

... etc.

RobLoach / raylib-cpp

Rescope raylib.h into raylib::impl namespace #45