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

Generate C++ code #31

Closed
tombsar opened this issue Feb 17, 2016 · 4 comments
Closed

Generate C++ code #31

tombsar opened this issue Feb 17, 2016 · 4 comments

Comments

@tombsar
Copy link
Collaborator

tombsar commented Feb 17, 2016

I've tried modifying gl3w to output C++ instead of C code (mostly adding namespaces), and it seems to work for my purposes. Is this something that would be merged upstream? Would you prefer the existing gl3w_gen.py script to output both versions (i.e. gl3w.c and gl3w.cc), or have a separate generator script for C and C++? Would you rather I fork and create a separate repository for the C++ version?

@skaslev
Copy link
Owner

skaslev commented Feb 18, 2016

I'm guessing that different gl3w.hpp file would need to be generated too (with namespaces and no macros), or if gl3w.h is to be shared between the C and C++ version, it would be #ifdef __cplusplus-ed (but that is probably is not a good idea since gl3w.h will provide different interfaces for C and C++ users)

I can't think of any advantages of having the generated code be in C++ instead of C. I would merge it, depending on the size of the patch. Prior to seeing the patch my opinion is that gl3w doesn't need that extra complexity and a fork might be a good idea.

@tombsar
Copy link
Collaborator Author

tombsar commented Feb 18, 2016

The way I coded it generates gl3w.cc and gl3w.hh in addition to the .c and .h. You're right that there's probably no real benefit... I just liked the idea of having everything neatly contained inside a gl3w namespace.

@Kos
Copy link

Kos commented Feb 19, 2016

I remember back in the day that the IDE would give me completions for functions but not for macros defined as functions. Years have passed, not sure how relevant this is nowadays.

@tombsar
Copy link
Collaborator Author

tombsar commented Jun 20, 2018

On reflection I think sticking to C is best for this library, so I'm going to close this as a WONTFIX.

@tombsar tombsar closed this as completed Jun 20, 2018
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

3 participants