"Paul F. Dubois" <dubois1@llnl.gov> writes: [...]
Can you explain your last point? You mean I had a memory leak?
At least one of them is on purpose: when you initialize the module you have to make sure that the Module object has an infinite lifetime.
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; } 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.
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.
Thanks for helping us.
No problem. It's harder to jump in when you can't just talk about a change in the hallway. Please let me know when I'm stepping on any assumptions or procedures so I can stop. -- Steven E. Harris Primus Knowledge Solutions, Inc. http://www.primus.com