memory - How to Assign a Variable Name in a #define (Boost related Mem Leak)? -

i've ran memory validator on application we're developing, , i've found macro expressions we've defined @ root of 90% of leaks. #define o_set.

now, our macros defined follows:

#define o_set_value(valuetype, value) boost::shared_ptr<valuetype>(new valuetype(value)) . . #define o_set o_set_value 

however, according boost web site (at: http://www.boost.org/doc/libs/1_46_1/libs/smart_ptr/shared_ptr.htm):

a simple guideline eliminates possibility of memory leaks is: use named smart pointer variable hold result of new. every occurence of new keyword in code should have form: shared_ptr p(new y); is, of course, acceptable use smart pointer in place of shared_ptr above; having t , y same type, or passing arguments y's constructor ok.

if observe guideline, naturally follows have no explicit deletes; try/catch constructs rare.

this leads me believe indeed major cause of our memory leaks. or being naive or out of depth here?

question is, there way work around mentioned issue, above macro #defines?

update: i'm using them, example, this:

return o_set(int, 1); _time_stamp(o_set(to_datetime, to_datetime())) (_time_stamp member of class)

i'm working in windows , used memoryvalidator tracking memory leaks - according there leaks - state, root of of (according stack traces) come down macro #define.

smart pointers tricky. first thing check code 'new' statement isn't inside either macro.

then have think how pointers being used; if pass smart pointer reference, reference counter isn't increased, example.

another thing check instances of '.get()', big problem if working legacy code base or other developers don't understand point of using smart pointers! (this more preventing random crashes memory links persé, worth checking)

also, might want consider why using macro smart pointer creation. boost supply different smart pointers different purposes. there isn't 1 size fits solution. old std::auto_ptr fine uses, except storing in standard containers, knew already.

the obvious , overlooked aspect is, really need 'new' something. c++ isn't java, if can avoid creating dynamic objects better off doing so.

if lucky enough working *nix platform (you don't mention, sorry) try leak checking tool valgrind. it's useful. there similar tools available windows, using you're software skilz best.

good luck.