The one annoying aspect about this program is that it does not handle partial/complete transparency very well. Right now every pixel is displayed regardless of whether it is meant to be transparent or not. In other words each picture is displayed as though it has no transparency regardless of whether or not this is actually the case.

template 
bool GetSharedMemoryAs(
    int shared_memory_id,
    int shared_memory_offset,
    size_t size,
    T* pointer) {
  *pointer = GetSharedMemory(
      shared_memory_id,
      shared_memory_offset,
      size);

   return *pointer != NULL;
}

Or something along those lines. That would actually make it less typing and easier to use since you don’t have to specify the type. Then you can just do

int* some_ints;
mem_sys->GetSharedMemoryAs(id, offset, size, &some_ints);

Personally I’d make “pointer* a reference to a pointer if it was up to me but my company doesn’t allow non-const references.

With all these small allocations, might it not better to add a heap manager, ie. a malloc-style heap management? I can see reasons to NOT do that with shared memory (eg. process A shares memory with process B and process C, but doesn’t want process B and C to see the each others data).

Compile times over safety? Mmmmm, what’s the cost? In this case, the template function is no more safe (and not even less typing) than the original, so nothing is gained. But I’m being picky. There’s nothing really wrong with your function – its one of the best uses of templates IMHO.

As for it being bad design, the function argument clearly says “page size” and is therefore auto documented so the API user is not going to use bytes by accident. You instantly know you have to look up the page size whether it’s a constant or from a function. That’s much better than having no idea. I could certainly see improving it by naming the function, AllocatePagesOfSharedMemory or AllocateSharedMemoryPages which would make it even clearer.

As someone who had to debug and fix code because an API designer choose the “number of bytes” solution and the client code saw “number of bytes” and was allocating lots of small amounts that way I’m going on empirical evidence. I’m also not the only one to run into this. A 40% increase in speed was recently had by one of the teams at my company finding out they were using a similar API inefficiently by allocating lots of small pieces of memory when internally it was allocating pages and therefore filling memory and ending up paging the app.

Hiding something that important is the wrong API design. A good design helps you write code that uses the API the way it was intended to be used. Bad API design puts all the burden of figuring out both how to use it at all and how to use it efficiently on the shoulders of the API user.

As for compile times, I hope you’re not saying you’d choose compile times over safety.

I’ll have to try those out. Funny how Googling for a reconcile solution didn’t bring up any (at the time I wrote the script)

Even p4’s blog doesn’t list your simple solution

http://blog.perforce.com/blog/?p=25

p4 diff -sd … | p4 -x – delete

p4 diff -se … | p4 -x – edit

dir/s/b/a-d | p4 -x – add

Now what happens if the page size changes? Or I add a second page size? At the very least I would have to recompile all client code – a major fail for an API. At the very least, you should be passing some kind of page size or page size enum.

Also, the intention of the original API seems to be to hide the page size from the application programmer. I agree that “Asserting” is a major fail, but the original API might be trying to hide the page size for a very good reason.

On your second example, I think you are missing the difference between an “API” and “Helper functions”. To me, a good API provides basic functionality, whilst helper functions group a series of commonly used functions together. I think your final example is a helper function, not an API function.

Oh, and my compile times might not thank you for adding templates into your header file, but I guess its just one (inline – please add inline!) function