Currently with the leak detection you have code of the form

#if this processor
    this code
#else
    stubs
#endif

If you are re-architecting -- could you persuade you to move the file 
into a "memory leak helper.cpp" file under WIN32 etc in the same way as 
there is a timehelper,h  file that includes the true timehelper.cpp -- 
that way there is a self consistency and it is easier when adding other 
processors

Thanks
Mike Smith

Clark Gaebel wrote:
> I've looked into it some more. It doesn't seem straight forward without
> a global state - something I like to avoid. I'm not sure how to proceed
> from here. Shall I global variable/singleton it, or start
> re-architecting somehow?
>
> On 02/02/2010 4:58 PM, Clark Gaebel wrote:
>   
>> Okay, that sounds easy enough.
>>
>> I'll do it after I'm done applying for this internship...
>>
>> On 02/02/2010 2:06 PM, Sean Farrell wrote:
>>     
>>> You got the thing half right... But I was not explicit enough with my
>>> explanation.
>>>
>>> If you look at TestRunner::RunTestIf you see "int maxTestTimeInMs".
>>> Well add a boolean "detectLeaks" and you are done. This way the
>>> developer using UT++ can use any means he pleases to enable or disable
>>> leak detection. (And use boost argument parser if he wants to make it
>>> a command line switch if he likes...)
>>>
>>> Sean
>>>
>>> On Sun, Jan 31, 2010 at 11:36 PM, Clark Gaebel <cg.wowus...@gmail.com> 
>>> wrote:
>>>       
>>>> Okay, I'm done 2/3 tasks.
>>>>
>>>> 1) Make a memory leak detector. -- DONE!
>>>> 2) Add a EXPECT_LEAK(x) macro.  -- DONE!
>>>> 3) Command-line switch to override global leak detection.
>>>>
>>>> http://github.com/wowus/unittest-cpp
>>>>
>>>> On 31/01/2010 5:00 PM, Clark Gaebel wrote:
>>>>         
>>>>> UT++ doesn't even get input from the command line afaik. We'd have to
>>>>> change the params to RunAllTests.
>>>>>
>>>>> On 31/01/2010 4:57 PM, Sean Farrell wrote:
>>>>>           
>>>>>> Hold the phone...
>>>>>>
>>>>>> look at the implementation of: TestRunner::RunTest and
>>>>>> UNITTEST_TIME_CONSTRAINT? Is there not a possible way to implement it?
>>>>>>
>>>>>> For the polymorphic part... Just instantiate the class, always or once
>>>>>> for the entire run, jut don't call the methods that do the actual
>>>>>> tracking. You can also keep a boolean that can be enabled or disabled
>>>>>> in the class.
>>>>>>
>>>>>> Sean
>>>>>>
>>>>>> On Sun, Jan 31, 2010 at 10:32 PM, Clark Gaebel <cg.wowus...@gmail.com> 
>>>>>> wrote:
>>>>>>             
>>>>>>> Hm, I see what you mean, but the thing is... now I've gotta get data
>>>>>>> from the command line, filter it through the levels of abstraction that
>>>>>>> are in place, and then... finally... use a polymorphic leak detector to
>>>>>>> select the right one. I don't think I'm up to the challenge. You're
>>>>>>> welcome to try though!
>>>>>>>
>>>>>>> By the way, the test fixture design is causing me headaches, I have to
>>>>>>> have duplicate code in TEST_FIXTURE_EX and in TEST_EX.
>>>>>>>
>>>>>>> I think I'll add SetUp and TearDown methods in class Test, then the
>>>>>>> fixture can implement them with the construction and destruction of the
>>>>>>> fixture. The default TEST would just replace them with null functions.
>>>>>>>
>>>>>>> Is this even do-able? Is it smart? I sure hope so!
>>>>>>>
>>>>>>> On 31/01/2010 4:27 PM, Sean Farrell wrote:
>>>>>>>               
>>>>>>>> Here is the problem:
>>>>>>>>
>>>>>>>> You build UT++ one for release and debug. Put it up in binary form for
>>>>>>>> a dozen project to use. Not all projects and developers want leak
>>>>>>>> detection to run all the time. A runtime switch, one that is given at
>>>>>>>> RunTests like the minimum test runtime, is a good option. That option
>>>>>>>> can the be enabled or disabled with #ifndef.
>>>>>>>>
>>>>>>>> This deployment use case is a very common one. I advise against it and
>>>>>>>> tell people to use the vsproj files (or Makefile) so that build
>>>>>>>> settings are synced. But that means that they have to keep one source
>>>>>>>> tree of UT per project and that is "error prone" and "wasteful".
>>>>>>>> Sooo...
>>>>>>>>
>>>>>>>> Sean
>>>>>>>>
>>>>>>>> On Sun, Jan 31, 2010 at 10:19 PM, Clark Gaebel <cg.wowus...@gmail.com> 
>>>>>>>> wrote:
>>>>>>>>                 
>>>>>>>>> Ehhh, runtime switch? What happened to "simple as possible"?
>>>>>>>>>
>>>>>>>>> I like keeping all minor configurations like that in one header file
>>>>>>>>> called, say, config.h.
>>>>>>>>>
>>>>>>>>> I'll try out polymorphism, looks promising.
>>>>>>>>>
>>>>>>>>> On 31/01/2010 4:14 PM, Sean Farrell wrote:
>>>>>>>>>                   
>>>>>>>>>> How about you just use the same solution like TimeHelpers.*.
>>>>>>>>>> Alternatively use polymorphism: a Win32LeakDetector and a
>>>>>>>>>> NullLeakDetector class.
>>>>>>>>>>
>>>>>>>>>> Nevertheless; leak detection should be a runtime switch with no
>>>>>>>>>> overhead when off.
>>>>>>>>>>
>>>>>>>>>> Sean
>>>>>>>>>>
>>>>>>>>>> On Sun, Jan 31, 2010 at 10:08 PM, Clark Gaebel 
>>>>>>>>>> <cg.wowus...@gmail.com> wrote:
>>>>>>>>>>                     
>>>>>>>>>>> http://github.com/wowus/unittest-cpp/commit/eede1787ab28ce420ada7b74dbd969f7a59145bd
>>>>>>>>>>>
>>>>>>>>>>> A bit easier to use solution.
>>>>>>>>>>>
>>>>>>>>>>> Although the #ifdef hell going on in LeakDetector.cpp is killing 
>>>>>>>>>>> me. If
>>>>>>>>>>> anyone has a better/cleaner way to do that, by all means submit a 
>>>>>>>>>>> patch.
>>>>>>>>>>>
>>>>>>>>>>> Working on a EXPECT_LEAK macro now.
>>>>>>>>>>>
>>>>>>>>>>> On 31/01/2010 4:06 PM, Sean Farrell wrote:
>>>>>>>>>>>                       
>>>>>>>>>>>> On Sun, Jan 31, 2010 at 8:19 PM, Patrick Johnmeyer 
>>>>>>>>>>>> <pjohnme...@gmail.com> wrote:
>>>>>>>>>>>>                         
>>>>>>>>>>>>> On Sun, Jan 31, 2010 at 12:21 PM, Sean Farrell 
>>>>>>>>>>>>> <sean.farr...@rioki.org>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>                           
>>>>>>>>>>>>>> I have a better problem for you. For example you use a garbage
>>>>>>>>>>>>>> collector for C/C++ like this one:
>>>>>>>>>>>>>> http://www.hpl.hp.com/personal/Hans_Boehm/gc/ The checking code 
>>>>>>>>>>>>>> will
>>>>>>>>>>>>>> flag almost all tests as memory errors. Leak detection is really
>>>>>>>>>>>>>> useful, but It should be an option that is turned on (or off). 
>>>>>>>>>>>>>> Not
>>>>>>>>>>>>>> hard coded into the library. For example I don't use the time
>>>>>>>>>>>>>> constants at all. Since I don't care for runtime in the Tests.
>>>>>>>>>>>>>>                             
>>>>>>>>>>>>> Architecturally, instantiating an object that decorates a 
>>>>>>>>>>>>> TestRunner or
>>>>>>>>>>>>> TestReporter might be a good way to explicitly enable memory leak 
>>>>>>>>>>>>> detection
>>>>>>>>>>>>> logic.
>>>>>>>>>>>>>                           
>>>>>>>>>>>> I don't know if I can follow you. Please elaborate on your 
>>>>>>>>>>>> proposed solution...
>>>>>>>>>>>>
>>>>>>>>>>>> Sean
>>>>>>>>>>>>
>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>> The Planet: dedicated and managed hosting, cloud storage, 
>>>>>>>>>>>> colocation
>>>>>>>>>>>> Stay online with enterprise data centers and the best network in 
>>>>>>>>>>>> the business
>>>>>>>>>>>> Choose flexible plans and management services without long-term 
>>>>>>>>>>>> contracts
>>>>>>>>>>>> Personal 24x7 support from experience hosting pros just a phone 
>>>>>>>>>>>> call away.
>>>>>>>>>>>> http://p.sf.net/sfu/theplanet-com
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> unittest-cpp-devel mailing list
>>>>>>>>>>>> unittest-cpp-devel@lists.sourceforge.net
>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/unittest-cpp-devel
>>>>>>>>>>>>                         
>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>> The Planet: dedicated and managed hosting, cloud storage, colocation
>>>>>>>>>>> Stay online with enterprise data centers and the best network in 
>>>>>>>>>>> the business
>>>>>>>>>>> Choose flexible plans and management services without long-term 
>>>>>>>>>>> contracts
>>>>>>>>>>> Personal 24x7 support from experience hosting pros just a phone 
>>>>>>>>>>> call away.
>>>>>>>>>>> http://p.sf.net/sfu/theplanet-com
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> unittest-cpp-devel mailing list
>>>>>>>>>>> unittest-cpp-devel@lists.sourceforge.net
>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/unittest-cpp-devel
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> The Planet: dedicated and managed hosting, cloud storage, colocation
>>>>>>>>>> Stay online with enterprise data centers and the best network in the 
>>>>>>>>>> business
>>>>>>>>>> Choose flexible plans and management services without long-term 
>>>>>>>>>> contracts
>>>>>>>>>> Personal 24x7 support from experience hosting pros just a phone call 
>>>>>>>>>> away.
>>>>>>>>>> http://p.sf.net/sfu/theplanet-com
>>>>>>>>>> _______________________________________________
>>>>>>>>>> unittest-cpp-devel mailing list
>>>>>>>>>> unittest-cpp-devel@lists.sourceforge.net
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/unittest-cpp-devel
>>>>>>>>>>                     
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> The Planet: dedicated and managed hosting, cloud storage, colocation
>>>>>>>>> Stay online with enterprise data centers and the best network in the 
>>>>>>>>> business
>>>>>>>>> Choose flexible plans and management services without long-term 
>>>>>>>>> contracts
>>>>>>>>> Personal 24x7 support from experience hosting pros just a phone call 
>>>>>>>>> away.
>>>>>>>>> http://p.sf.net/sfu/theplanet-com
>>>>>>>>> _______________________________________________
>>>>>>>>> unittest-cpp-devel mailing list
>>>>>>>>> unittest-cpp-devel@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/unittest-cpp-devel
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> The Planet: dedicated and managed hosting, cloud storage, colocation
>>>>>>>> Stay online with enterprise data centers and the best network in the 
>>>>>>>> business
>>>>>>>> Choose flexible plans and management services without long-term 
>>>>>>>> contracts
>>>>>>>> Personal 24x7 support from experience hosting pros just a phone call 
>>>>>>>> away.
>>>>>>>> http://p.sf.net/sfu/theplanet-com
>>>>>>>> _______________________________________________
>>>>>>>> unittest-cpp-devel mailing list
>>>>>>>> unittest-cpp-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/unittest-cpp-devel
>>>>>>>>                 
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> The Planet: dedicated and managed hosting, cloud storage, colocation
>>>>>>> Stay online with enterprise data centers and the best network in the 
>>>>>>> business
>>>>>>> Choose flexible plans and management services without long-term 
>>>>>>> contracts
>>>>>>> Personal 24x7 support from experience hosting pros just a phone call 
>>>>>>> away.
>>>>>>> http://p.sf.net/sfu/theplanet-com
>>>>>>> _______________________________________________
>>>>>>> unittest-cpp-devel mailing list
>>>>>>> unittest-cpp-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/unittest-cpp-devel
>>>>>>>
>>>>>>>               
>>>>>> ------------------------------------------------------------------------------
>>>>>> The Planet: dedicated and managed hosting, cloud storage, colocation
>>>>>> Stay online with enterprise data centers and the best network in the 
>>>>>> business
>>>>>> Choose flexible plans and management services without long-term contracts
>>>>>> Personal 24x7 support from experience hosting pros just a phone call 
>>>>>> away.
>>>>>> http://p.sf.net/sfu/theplanet-com
>>>>>> _______________________________________________
>>>>>> unittest-cpp-devel mailing list
>>>>>> unittest-cpp-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/unittest-cpp-devel
>>>>>>             
>>>> ------------------------------------------------------------------------------
>>>> The Planet: dedicated and managed hosting, cloud storage, colocation
>>>> Stay online with enterprise data centers and the best network in the 
>>>> business
>>>> Choose flexible plans and management services without long-term contracts
>>>> Personal 24x7 support from experience hosting pros just a phone call away.
>>>> http://p.sf.net/sfu/theplanet-com
>>>> _______________________________________________
>>>> unittest-cpp-devel mailing list
>>>> unittest-cpp-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/unittest-cpp-devel
>>>>
>>>>         
>>> ------------------------------------------------------------------------------
>>> The Planet: dedicated and managed hosting, cloud storage, colocation
>>> Stay online with enterprise data centers and the best network in the 
>>> business
>>> Choose flexible plans and management services without long-term contracts
>>> Personal 24x7 support from experience hosting pros just a phone call away.
>>> http://p.sf.net/sfu/theplanet-com
>>> _______________________________________________
>>> unittest-cpp-devel mailing list
>>> unittest-cpp-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/unittest-cpp-devel
>>>       
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> unittest-cpp-devel mailing list
> unittest-cpp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/unittest-cpp-devel
>
>
>   

-- 
Michael Smith Ph. D.,
Professor, Department of Electrical and Computer Engineering. 
Adjunct Professor, Department of Radiology, University of Calgary.
Analog Devices University Ambassador.

Electrical and Computer Engineering,    Voice: (+1) 403-220-6142        
University of Calgary, Calgary,         Fax: (+1) 403-282-6855
Alberta, Canada T2N1N4                  Email: mike.sm...@ucalgary.ca

Experience can't be taught, experience can only be earned.


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
unittest-cpp-devel mailing list
unittest-cpp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unittest-cpp-devel

Reply via email to