0

I am working on a small game engine for some of my friends, and I am using OpenGL (and GLFW and GLEW and all of that stuff) for rendering. As you may know, OpenGL is a C library and therefore does not contain classes. Now, I don't want my friends (or myself for that matter) seeing all of that gobbledygook from glfw3.h and glew.h, and I was wondering if there is an easy way to hide stuff like that from users.

I understand that in many cases, one might try pimpl in this case, but the problem is, all I have is functions. I could put them all in a static class or a namespace that is then included by necessary classes, but that still really wouldn't hide those functions from the user. The only thing off the top of my head would be something weird and cumbersome with function pointers, but I'm going to be using these functions so often that it would slow development.

In the end, I guess it wouldn't be TERRIBLE if scary things like glVertexAttribPointer were visible, but its just something that I would like. Thanks in advance.

Machavity
  • 28,730
  • 25
  • 78
  • 91
Uncle Fungus
  • 93
  • 1
  • 10
  • 2
    Have you tried just not including `GL.h` from your library's header files? – Dolda2000 Mar 13 '16 at 04:02
  • @Dolda2000 Well, that would work, if I were actually using `gl.h`, but all of those functions come in `glfw3.h`, types from which I often use as private members in my classes. However, that is an interesting and obvious point I didn't think about at all. I just don't know how to separate OpenGL-related functions in `glfw3.h` from GLFW-related functions. – Uncle Fungus Mar 13 '16 at 04:09
  • Use the PIMPL idiom: http://stackoverflow.com/questions/60570/why-should-the-pimpl-idiom-be-used . Basically hide the stuff using the GL headers from the user's sight as well. – user4581301 Mar 13 '16 at 04:42
  • @user4581301 This would also work if glfw/opengl weren't a darn C library. Anyways, that would disable the user's use of handy classes like, for example, an `engine::Window` because that class needs a `GLFWwindow` member, which is in `glfw3.h`, where all of the OpenGL functions also are. I suppose I could edit the header file, but thats not exactly the best idea... Thanks for the suggestion though. A `gl` class combined with pimpl could work; it would just be a bit of a pain – Uncle Fungus Mar 13 '16 at 05:15
  • Doesn't matter if it's a C library. The client only sees a forward defined PIMPL class that isn't defined in the header and a pointer to the forward defined PIMPL class. The implementation of this PIMPL class is stashed away out of public view inside in a CPP file and wrapps all of the needed C functionality. Only the CPP file needs to include the C header and know anything about the C library. All of your other classes call the PIMPL class, perhaps using forward defines and a header that isn't exposed to the client. – user4581301 Mar 13 '16 at 05:49
  • Ah. That makes since. Thank you! – Uncle Fungus Mar 13 '16 at 14:17

1 Answers1

0

Did it never occur to you, to actually look into glfw3.h and see how GLFWwindow is defined?

/*! @brief Opaque window object.
 *
 *  Opaque window object.
 *
 *  @see @ref window_object
 *
 *  @since Added in version 3.0.
 *
 *  @ingroup window
 */
typedef struct GLFWwindow GLFWwindow;

It's too bad you can't emphase words in markdown code sections. There's an important little word in there: opaque

GLFWwindow has been written in the header as only a forward struct declaration. Which means you can only create pointer variables of it.

So in your class, it's perfectly fine and an accepted pattern, if you need only a pointer, to add an identical forward declaration, before defining your class, i.e.

typedef struct GLFWwindow GLFWwindow;

class whatever {
    /* ... */
    GLFWwindow *wnd;
    /* ... */
};

You can then include glfw3.h in the C++ compilation unit source files.

But why do you even care? For all you know, whoever is going to use your library may be including the OpenGL headers intentionally. You're including GLFW and GLFW is including OpenGL headers. So whoever is going to use your library is going to depend on the nested type definitions.

There's rarely something good coming from trying too hard to "hide" things. As long as you don't pollute the namespace just accept it.

Alas, there's one good reason for compartmentization: Speeding up compile times: The less header to include the better.

datenwolf
  • 149,702
  • 12
  • 167
  • 273
  • https://www.reddit.com/r/learnprogramming/comments/2yhjwe/why_are_experienced_programmers_so_hostile_toward/ ;) I love u too mate – Uncle Fungus Mar 13 '16 at 20:57
  • @Naerion: Actually it wasn't meant hostile or to put you down. On the contrary: I was trying to encourage you not to spend too much thought into it and encourage you "take a bold move" (either by "cheating" in doing a forward declaration) or by don't giving an eff at all. – datenwolf Mar 14 '16 at 08:13
  • fair enough. sorry for misinterpretation – Uncle Fungus Mar 14 '16 at 18:18