[C++-SIG] Submitting candidate changes to CXX

[Steve Harris]

"Paul F. Dubois" <dubois1 at 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