Efficient implementation of bidirectional map between 64bit and 32bit unsigned integers - c++

Question

Imagine we have 2 machines named: Alice and Bob. Alice supports operations with 64 bit unsigned integers while Bob operates with 32bit unsigned integers only.
Bob sends Alice request to create a task. For each task Alice assigns unique ID that is random but unique 64bit unsigned integer. Bob can create up to 2^32 tasks.
I need to add an ability for Bob to be able to delete tasks by ID. Therefore I need to set up a proxy that will substitute 64bit units with 32bit uints when message goes from Alice to Bob and restore 64bit uint from 32bit uint when message goes in opposite direction.
The problem is that I need to make conversion very efficient, I only have ~10MB of RAM to do this.
Is there any container that already solves that issue?
Update
The community asked for a clarification and the only way to clarify it is to describe real-world situation.
So, I'm working on OpenGL translator libraries that are part of the AOSP. In summary it allows to move rendering of Android system (e.g. running inside the VM) to the host system for acceleration reasons.
It's done by streaming all OpenGL commands (forth and back) from Target (Android) to Host (i.e. Win8 64bit).
OpenGL objects are represented as handles which are of type GLuint or unsigned int. Therefore size of the object and allowed values depend on whether system is 32bit or 64bit.
Since most Android systems are 32bit and most host systems are 64bit, the problem arise: in request of creating OpenGL object from Android, Host can create handle with value that cannot be represented as 32bit value. However, Android cannot ask for more than 2^32 - 1 objects for obvious reasons.
The only solution that came to my mind is to set up the proxy that will map 64bit handles to 32bit and vice versa.
The concrete piece of code that creates problem: https://android.googlesource.com/platform/sdk/+/master/emulator/opengl/host/libs/Translator/include/GLcommon/GLutils.h line 47.
Update 2
After exploring the problem a little bit further I've found that it's not an issue of GLuint (as noted by #KillianDS). However it's still issue of OpenGL.
There are functions that return pointers, not GLuint handles. E.g. eglCreateContext.
I need to find a way to exchange pointers between 64bit Host and 32bit Target.
Update 3
Finally I figured out that this concrete crash is not related to transition of handles between 32bit and 64bit machines. It is a bug in the Target part of translator that calls wrong function (glVertexAttribPointerData) with wrong argument.

Answer 1

According to table 2.2 in the latest core OpenGL spec a uint in OpenGL should always be 32 bits in width (the spec is about the same for ES). All OpenGL names/handles are as far as I know (and you also say in your question) uint's. So, it should be 32 bit on both your host and target.
Note that it is exactly because the actual bit width of unsigned int might differ between platforms that OpenGL has its own types that should conform to the spec.
Update
If the remaining handles are really only contexts and other window-system calls I'd keep it simple because we're not talking frequent operations, nor a huge amount of handles. These kind of operations are usually not done more than once per OpenGL application per GPU, which is likely 1 on any mobile phone. I think the easiest solution of all would be to use an array. Pseudocode
class context_creator
{
std::array<EGLContext, 1000> context_map; //8KB
public:
context_creator() : context_map{} {}
uint32_t allocate(...) {
for(unsigned i = 0; i < context_map.size(); i++) {
if(!context_map[i]) {
context_map[i] = eglCreateContext(...);
return i;
}
}
}
void deallocate(uint32_t handle) {
eglDeleteContext(context_map[handle]);
context_map[handle] = 0;
}
//Has to be called in every function where a context is a parameter.
EGLContext translate(uint32_t handle) const {
return context_map[handle];
}
}
One note, this won't work if 0 is a valid name for a context. I really don't know for WGL, but probably it's not. The advantage of this is that while the allocate isn't the fastest algorithm ever, the translate is O(1) and that's what most likely will be called most often.
Of course, variations exists:
You can use a more dynamic container (e.g. vector) instead of fixed size.
You can use a hashtable (like std::map) and just generate a unique index per call. This consumes more memory as you have to store the index also (it's imlicit in an array), but it solves the problem if 0 is a valid context name.

Answer 2

The uint in OpenGL should be 4 bytes i.e. 32 bits always in width so handles/names should be 32 bit on both your target and host