ConfettiFX / The-Forge

The Forge Cross-Platform Rendering Framework PC Windows, Steamdeck (native), Ray Tracing, macOS / iOS, Android, XBOX, PS4, PS5, Switch, Quest 2
Apache License 2.0
4.71k stars 493 forks source link

Forge polluting global C++ namespace #177

Open alex-mat opened 4 years ago

alex-mat commented 4 years ago

Hello, I ran into a few issues where Forge clashes with my own types when integrated with my own engine, for instance math types, renderer, etc... For now my solution is to create a dummy IRenderer.h with the same types and functions enclosed in a namespace and implement functions in a source file casting everything back, eg.:

void initRenderer(const char *app_name, const RendererDesc *p_settings, Renderer **pRenderer) { ::initRenderer(app_name, (const ::RendererDesc *)p_settings, (::Renderer **)pRenderer); }

Would be nice if everything was in a Forge namespace, or at least had a prefix such as Fg :) Cheers and thank you for your work !

wolfgangfengel commented 4 years ago

Thanks for the input!

We are moving towards more C like code with the ultimate goal of running only a C codebase at some point.

Michael-Lfx commented 4 years ago

Hello. Why are you moving it to C language?

wolfgangfengel commented 3 years ago

I think C is better for team usage. It is also better to design high-performance architecture. This is more or less just going back to the roots because most game engine teams have writing guidelines that define something along the lines of "use C whenever you can". Our writing guidelines are similar. You can find them at the end of the GitHub page ...

TLaviron commented 3 years ago

May I suggest having an option to put all forge declarations in a namespace? Something like

#if defined(__cplusplus) && defined(TF_NAMESPACE)
namespace TF_NAMESPACE {
#endif
...

This would not prevent using it from C, and would give C++ users the option to isolate definitions. This also makes it possible to have multiple backends available in an application, for example having a Vulkan backend in a tfVk namespace and a D3D12 backend in a tfDX12 namespace.

makato2003 commented 3 years ago

Also, the namespace thingie. I would really like to integrate The Forge with my project; either by using the libraries (preferred) or merge the sources. But the missing namespace is a blocker.

Takarashy-URender commented 3 years ago

Same here, we were discussing that we need to create a layer on top of The-Forge for our new projects. We would love to see a The-Forge namespace 😍

englercj commented 3 years ago

+1, if the goal is to use C then a prefix works just as well. But some of the function names are very general currently and easily collide with application names. Adding tf as a prefix to all functions (e.g.: tfInitRenderer) would be great and consistent with other popular C libraries.

Takarashy-URender commented 3 years ago

Writing all code in pure C and then using a namespace will not harm performance as far as I know. Taking the best of both cakes ;) Or are there any other implications I'm not aware of?

But a prefix would also work +1