ability to add userdata to wgl context

OpenGL
1

so I can keep a pointer to my own device class with the context itself.

2

Why don’t you keep the context in the device class?
Because of threads and multiple windows?
With multiple windows it should be no problem - you just keep one active device class per window.
With threads it’s a different story but I usually avoid accessing libraries like OpenGL from more than one thread - it’s one GPU anyway and accessing it from multiple threads can cause performance issues.

You could also use hash map to map a pointer to a device class for each context. If you wish to have it this way.

3

it would just be more convenient. I have various generic systems that end up calling graphical methods at some point down the chain. It’s impractical to pass the device pointer to that point.
An alternative is to have my own thread-id indexed hash table, but it occurred to me that GL already maintains a thread-id indexed object which I should be able to use.

4

I’ve found that a static member of the device class works nicely for this sort of thing:

class my_device
{
public:
  my_device() { ... m_instance = this; ... }
  ...
  static my_device* instance() { return m_instance; } const;
  ...
private:
  static my_device* m_instance;
  ...
};

During your setup, you create your device class, and instead of passing it around, you just call my_device::instance() whenever you need the pointer. I’d also tend to inline it to get rid of the performance penalty.

5

Yeah, but this doesn’t solve the “current device” problem when working with threads.
I guess that hashmap addressed by thread id is the only reasonable way. Note that this hash map doesn’t have to contain all threads - only those meant for working with rendering context - so it’s gonna be small and thus fast.

6

I guess that hashmap addressed by thread id is the only reasonable way.
Wouldn’t it be easier to just have some thread-local memory allocated that you can get a pointer to? Unless you’re trying to access another thread’s context, this makes a lot more sense.

7

Adding on Korval reply.

you can use the TLS (thread local storage) TlsAlloc,TlsFree … (under windows) to store specific thread data.

Ido

8

…or they could just add:
void wglSetCurrentContextUserData(void*)
and
void* wglGetCurrentContextUserData()

Just as a hwnd can have userdata attached to it so the programmer can maintain a two way link between the OS object and the application object.

To argue against this is the same as arguing against any userdata system. I think back pointers are an elegant solution for any API object-based system. I would even suggest that every object in longs peak should have a back pointer attribute.

9

you could even toss in an id

wglSetContextUserData(uint id, void* data)

if one really got a hair…

10

…or they could just add:
void wglSetCurrentContextUserData(void*)
and
void* wglGetCurrentContextUserData()
Why don’t you add it then? :slight_smile:

It will of course be implemented using hash map but API would still be the same.

11

http://gcc.gnu.org/onlinedocs/gcc-4.2.0/gcc/Thread_002dLocal.html#Thread_002dLocal

That’s even standard ANSI/ISO C++ :stuck_out_tongue:

12

interesting, thought it was win32 specific.
I still think all GL objects should have a userdata attribute - it just completes the object model.

13

gcc’s __thread is definitely not ANSI/ISO C++; it’s a gcc extension, and even gcc doesn’t support it for all targets. (If nothing else the clue’s in the name; any identifier containing a double-underscore is reserved for implementation specifics by the C++ standard.)

There’s a good chance it’ll be standardized in C++0x if you don’t mind waiting a few years; if you’re in a hurry and want portability, Boost is probably your best bet.

14

C++0x looks like a crazy C++ / C# 3.0 mutant.

Lambda expressions?