Forge polluting global C++ namespace

[alex-mat]

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]

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]

Hello. Why are you moving it to C language?

[wolfgangfengel]

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]

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]

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]

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]

+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]

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

[darkuranium]

(necro, I know, but it's still an open issue anyway)

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?

At the language level it's fine, but it would still be easy to run into linker problems.
Remember, C symbols aren't name-mangled, so the namespace would be ignored in terms of that --- tf::initRenderer is still initRenderer (or sometimes _initRenderer, depending on system/call convention) in terms of linkage, so that causes issues.

That's ignoring any and all people who might end up using The Forge from C directly (assuming it's adequately converted in its entirety), who don't have access to namespaces.

I'm 100% with @englercj in terms of adding a prefix. And if compatibility is an issue, it would be pretty easy to make an optional (enabled or disabled with a #define, and deprecated by definition) compatibility wrapper that basically does:

#ifdef TF_DEPRECATED_USE_PREFIX_WRAPPER

#if defined(__cplusplus) && defined(TF_DEPRECATED_PREFIX_WRAPPER_NAMESPACE)
namespace TF_DEPRECATED_PREFIX_WRAPPER_NAMESPACE {   // stolen from TLaviron's proposal above
#endif

inline void initRenderer(...) { tfInitRenderer(...); }
...

#if defined(__cplusplus) && defined(TF_DEPRECATED_PREFIX_WRAPPER_NAMESPACE)
}
#endif

#endif /* TF_DEPRECATED_USE_PREFIX_WRAPPER */

(the #define names here are intentionally descriptive/long for the sake of example)