Well, the compiler "might" ignore __inline, while forceinline is "usually" honored, at least when it can be. Ignoring __inline doesn't mean the compiler won't inline, though; rather it will use it's optimization heuristics to determine whether to inline or not. I believe VC++ lets you select how to treat inline and the like, there's a compiler switch somewhere.

But you're right, #define can be a better solution - however, doing it as functions allows me to set a breakpoint on halloc or hfree or whatever. (And with some `#ifdef DEBUG', it can be implemented as defines anyway).

A single global variable is not bad, as long as you can avoid name/scope problems. "static HANDLE ghHeap;" in halloc.cpp, if you only need the handle there. I usually keep it global though, so I can avoid GetProcessHeap calls elsewhere.

I usually only do this for "raw win32 api" style programs; when I do "real" programs, I tend to use the libc runtime, and in debug builds, paul nettles memory leak tracking wrapper solution stuff (my name for it, not his ;)). It makes leaks and buffer over/underruns *so* much easier tracking...
Posted on 2002-08-02 14:07:43 by f0dder
I think there is an advantage of the function over #define though... it will appear in codeaware/intellisense/codecompletion while I don't think the #define will... but that is not a "code-level" argument... and a inline function will appear in codeaware...
My policy is usually to #define when the code isn't more one line long and to inline when it is more longer... as functions are much more readable than multi-lines #defines...

I will play with __inline and forceinline a bit more and compare the results with the assembly listing output.

Thanks for the answers. ;)
Posted on 2002-08-03 06:15:57 by JCP