Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Forge polluting global C++ namespace #177

Open
alex-mat opened this issue Jun 19, 2020 · 8 comments
Open

Forge polluting global C++ namespace #177

alex-mat opened this issue Jun 19, 2020 · 8 comments

Comments

@alex-mat
Copy link

alex-mat commented Jun 19, 2020

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
Copy link
Contributor

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
Copy link

Hello. Why are you moving it to C language?

@wolfgangfengel
Copy link
Contributor

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
Copy link

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
Copy link

makato2003 commented Mar 11, 2021

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
Copy link

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
Copy link

englercj commented Mar 12, 2021

+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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants