1

I'm currently using glLoadGen to load OpenGL functions,

there is an option like place all function pointers in namespace gl so that I can use them like gl::CreateShader( ... )

what would be the disadvantages for that feature??

It does not pollute global namespace with thoes gl** functions, or macros; but I'm afraid there are some potential disadvantages...

ehwank
  • 31
  • 1
  • 2
  • [This question](https://stackoverflow.com/questions/6670738/is-it-a-good-idea-to-wrap-an-include-in-a-namespace-block) is related. – Cory Kramer Aug 26 '16 at 15:14
  • I don't see why would you want to use this option. You'll need to type extra `::` each time and you wont be able to copy-paste GL code directly from other sources. You say that this option is good because it does not pollute global namespace, but the pollution is not a problem if all names have proper prefixes. – HolyBlackCat Aug 26 '16 at 15:21
  • 1
    @CoryKramer Related, but not closely as that's not what glLoadGen does (depending on options). – Some programmer dude Aug 26 '16 at 15:29
  • 1
    @HolyBlackCat: "*you wont be able to copy-paste GL code directly from other sources*" That sounds like a really good reason to *use it*. Copy-and-paste coding is a *bad thing*. – Nicol Bolas Aug 26 '16 at 15:30
  • @NicolBolas You're right indeed, copy-paste coding is bad. But that's not a proper reason to intentionally use unconventional function names. Also, sometimes copy-pasting may be useful: OP may want to copy and run code with GL function calls just to learn it. Or he may need to just copy ver long function name from GL docs. Surely it doesn't take too much time to add `::`, but for me this option still seems like unnecessary overcomplication. – HolyBlackCat Aug 26 '16 at 15:41
  • @HolyBlackCat I'm using auto completion in vim. actually just for a little performance, like not showing gl*** functions on every completion list – ehwank Aug 26 '16 at 15:41
  • @ehwank Sorry, now I understand why you want to use it. I guess there is no major disadvantages, only those tiny ones I've listed. – HolyBlackCat Aug 26 '16 at 15:43
  • @HolyBlackCat thanks a lot. I was worried if it could be such a disaster in future. – ehwank Aug 26 '16 at 15:50
  • If something goes wrong with it, you can always use vim (or just sed) to replace `gl::` with `gl` and reconfigure glLoadGen. – HolyBlackCat Aug 26 '16 at 16:16

1 Answers1

0

Most likely you would not want to do this because they will no longer follow the C language binding naming conventions used universally. The whole namespace problem was already solved in a language agnostic way by tacking GL_ onto the beginning of constants and gl onto the beginning of functions.

You are free to do whatever you want here, but the global namespace in a language like C or C++ is already polluted by the underlying library you linked to. For example, on Windows you have all of the functions from GL 1.1 just sitting there with the standard C language bindings for names. This is a set of about 400 functions that you get by including the platform's OpenGL header.

Andon M. Coleman
  • 42,359
  • 2
  • 81
  • 106
  • Considering the various bindings to non-C languages, I would hesitate to call this convention "used universally". LWJGL gives each OpenGL version and extension its own separate pseudo-namespace. OpenTK puts OpenGL in a `GL` class, but removes the `gl` and `GL_` prefixes that become redundant. It even renames OpenGL enumerators in accord with C# conventions. Given that there are many ways to bind OpenGL to a language, why should C++ *have to* follow C's lead? – Nicol Bolas Aug 26 '16 at 22:36
  • @NicolBolas: Don't get me wrong, I am well aware that many, many language bindings do away with this convention. My point here was actually that by including `gl/gl.h` from C or C++, you're going to have a bunch of functions dragged in with the original `gl*` convention. If the intention by segregating everything into its own namespace was simplicity, in this situation the opposite is accomplished. You would need to write your own header and ensure that no part of your software includes the platform header to avoid this. – Andon M. Coleman Aug 26 '16 at 22:40
  • "*You would need to write your own header and ensure that no part of your software includes the platform header to avoid this.*" Yes. Which is something I accounted for *when I wrote that feature* into glLoadGen. And that's a very common thing about OpenGL loaders. Virtually all of them will prevent you from including `gl/gl.h` manually, and they'll fail to work if you try to include that header *before* including theirs. Even GLEW's headers do that. This problem is already accounted for. Even the `wgl.h` issue. – Nicol Bolas Aug 26 '16 at 23:11
  • It's really not, at all. Take for example OS X. It has `gl.h` and `gl3.h`, which are intended to be mutually exclusive. The case where both headers are included can be detected, the case where only `gl.h` is included and the rest of the software uses the interfaces provided by `gl3.h` ... that's not. You can easily wind up with one module of code using the original C language bindings and another using your custom C++ bindings without ever knowing it just as the situation arises on OS X. – Andon M. Coleman Aug 26 '16 at 23:15
  • "*You can easily wind up with one module of code using the original C language bindings and another using your custom C++ bindings without ever knowing it*" Sure, that can happen. So what? One part of an app can use GLEW while another uses glBinding, while a third uses `gl.h` by itself. In the end, it all talks to C using the same functions. So where exactly is the issue? – Nicol Bolas Aug 26 '16 at 23:37
  • There's a huge one. One part of the code is dispatched through your language bindings, the rest goes through something lower-level. If they were ever to deviate because you wanted to add a debug layer / API wrapping functionality or even thread-local-storage like OpenGL32.dll uses, code that was originally functionally identical is no longer -- but the program continues to compile and link. If you cannot prevent someone from errantly including the platform's original bindings and using standard bindings, you have to write additional validation somewhere in your deployment steps. – Andon M. Coleman Aug 27 '16 at 00:15
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/121981/discussion-between-nicol-bolas-and-andon-m-coleman). – Nicol Bolas Aug 27 '16 at 01:08