[C++-SIG] Submitting candidate changes to CXX
barry at scottb.demon.co.uk
Sun May 28 14:47:07 CEST 2000
> 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.
More information about the Cplusplus-sig