There are a few static methods that take the same basic shape, such as Py::ExtensionModule::methods(). In the CVS version, it keeps a static pointer which is initially null. In each call, it checks to see if the pointer is still null. If so, it heap allocates a method_map_t variable and returns that variable by reference. But how and when would that pointer ever get deleted? My candidate replacement takes this form:

static method_map_t &methods(void) { static method_map_t map_of_methods; return map_of_methods; }

I think the problem is that this change will not work as the c'tor will not be called on all platforms (which is a compiler/RTL/ way-python-is built bug). As the memory will be in use from the moment the module is loaded until process exit its not a performance issue.

Since map_of_methods is a static local variable, it's guaranteed to be cleaned up eventually. We know that an exiting process will likely clean up most heap-allocated memory, but the above form seems more trustworthy unless you're deliberately trying to control _when_ the variable gets deleted.

The OS simply returns all resources used by a process to the OS free resources. Nothing in the OS bothers to look at the heap in an intelligent way. There may be malloc debug code loaded.

...

It shouldn't be necessary to eliminate temporaries; any good compiler will do this. There are some in the tests that look like temporaries but in fact are doing Python-type checking and for debugging purposes I did things in steps.

Okay. Perhaps you can then veto some of the changes. Maybe it's just a style thing. I always think of Scott Meyers' "Item" on named temporary variables: the compiler can't take as much liberty in eliminating them. I'll let you be the judge.

I place intermediate values in named varables to allow me to debug the logic of an algorithm. I've found that this works well to allow me maintain code. BArry