[Insight-developers] Enhanced logging mechanism
Hans Johnson
hans-johnson at uiowa.edu
Wed Nov 9 14:42:42 EST 2005
Bill,
Thanks for the notification on the GCC2.95 compiler. I've committed a
solution. It seems to have the same problem as the VS6 compilers.
Also, thanks for the information about the borland compiler.
Regards,
Hans
PS: From what I have read, and from the error messages on the
dashboard, I am not 100% convinced that the VS7 compilers were having
the same problem as the VS6 compilers with using a temple parameter for
the public superclass. I agree that I never had a working version of
the code for VS7, but I think it is due to other errors.
Lorensen, William E (Research) wrote:
>Hans,
>I added that test back in last night thinking that the problem was fixed for the MS compilers. I'll back that out (BTW, the test driver needs to ignore that test also).
>
>There still is a problem with the gcc2.95 compiler.
>
>Also, don't buy a borland compipler. The commercial compiler will not compile itk I believe. You need to get the free borland compiler.
>
>Also, although the MS compilers are legacy, three of them don't build. It's not just VS6.
>
>Bill
>
>
>
>-----Original Message-----
>From: insight-developers-bounces+lorensen=crd.ge.com at itk.org
>[mailto:insight-developers-bounces+lorensen=crd.ge.com at itk.org]On Behalf
>Of Hans Johnson
>Sent: Wednesday, November 09, 2005 10:20 AM
>To: Lorensen, William E (Research); insight-developers at itk.org
>Subject: Re: [Insight-developers] Enhanced logging mechanism
>
>
>Bill,
>
>FIRST: The only part that I can see is still failing is the new test
>module that I designed to stress the outter limits of what the new
>mechanism should be able to do. I have removed this test since ITK does
>not yet need this functionality, and some of the legacy compilers can't
>handle it. If this final attempt does not work, I will roll back all
>changes after 9:00pm tonight.
>
>SECOND: The "tricky" solution given in the previous message about using
>the loki hacks was not going to work (upon further review, it was just
>a complete re-write of the code).
>
>THIRD: Here is the situation and problem that I was trying to solve:
>
>1) The Logger mechanism in itk had all the "message handling" features
>that I needed
>2) The Logger mechanism had the "message format" hard coded to force a
>50 character preamble prior to delivering the message (I could not live
>with that part)
>3) I wanted to maintain complete compatibility with the existing API
>including the LoggerManager which is also hardwired to the Logger and
>the ThreadLogger(the ThreadLogger derives from Logger).
>
>I identified that the core logging functionality can be divided as follows:
>
>1) A base class called Logger that defined the interface that defines:
> a) The different acceptable logging levels
> b) The basic member functions that all loggers must also contain
> c) Messaging format was hard coded.
>2) A ThreadLogger class that was hard coded as subclass of Logger that
>defines:
> a) Thread safe queuing mechanism to wrap around the base
>class by overloading each of the basic member functions
>
>My solution was to push the Logger class up to an abstract base class
>(i.e. LoggerBase) with a default implementation exactly like the old
>code. I then templated the ThreadLogger as a wrapper around any class
>that meets the LoggerBase specifications (LoggerThreadWrapper).
>Finally, I created typedef's to generate specializations of this
>generalized framework to meet the old API.
>
>I sent the code to the list for review, and discussed the changes with
>several people on the weekly telecom call. I wrote a test suite for the
>enhanced capabilities, and tested the classes on gcc 3.2, 3.4, 4.0,
>linux, mac, and SGI MipsPro before committing it.
>
>FINALLY: We are setting up a set of windows machines and are attempting
>to purchase MSVS 6, borland, and MSVS 7. So that we may attempt to
>avoid these problems in the future.
>
>
>
>Hans
>
>
>
>
>
>Lorensen, William E (Research) wrote:
>
>
>
>>Hans,
>>There are still several issues with the logger changes. Not just windows. The gcc2.95 compiler is also having trouble.
>>
>>I'm not sure whay so many changes were required to meet your needs. I haven't looked at the logger mechanism in detail. Could there have been a less "tricky" way to get what you wanted?
>>
>>If you can't come up with a portable solution in the next couple of days, I think you should back out all of your changes until after the release. I'm afraind that this much disruption so close to the release is not good.
>>
>>Bill
>>
>>-----Original Message-----
>>From: Hans Johnson [mailto:hans-johnson at uiowa.edu]
>>Sent: Sunday, November 06, 2005 10:02 AM
>>To: Lorensen, William E (Research)
>>Cc: ITK
>>Subject: Re: [Insight-developers] Enhanced logging mechanism
>>
>>
>>Bill,
>>
>>I was just looking at this. I surely thought this was a correct syntax.
>>
>>Well.... It appears that VS6sp5 does not support this strucuture, VS7 is
>>supposed to support it. Since I don't have either VS6 or VS7, I'll need to
>>use the dashboard to test the changes. I've got a quickfix that I will be
>>submitting shortly.
>>
>>There is a more complete work around descrirbed the loki toolkit,
>>loki/MSVC/1200/MSVC6Helpers.h:
>>
>>============================================================================
>>////////////////////////////////////////////////////////////////////////////
>>////
>>// class template ApplyImpl1
>>// Invocation: ApplyImpl1<T>::template Result<T1>
>>// T must be a nontemplate type with a nested class template named In.
>>// The class template is a helper for the Apply1-Template
>>////////////////////////////////////////////////////////////////////////////
>>////
>> template <class TypeWithNestedTemplate>
>> struct ApplyImpl1
>> {
>> template<bool flag>
>> struct VC_WORKAROUND : public TypeWithNestedTemplate {};
>>
>> struct VC_WORKAROUND<true>
>> { template<class> struct In; };
>>
>> template< typename T1 > struct Result : public
>> VC_WORKAROUND<
>>::Loki::Private::AlwaysFalse<TypeWithNestedTemplate>::value >::template
>>In<T1>
>> {
>> typedef VC_WORKAROUND<
>>::Loki::Private::AlwaysFalse<TypeWithNestedTemplate>::value >::template
>>In<T1> Base;
>>
>> };
>> };
>>============================================================================
>>
>>The loki/MSVC/1300/ version of the code does not seem to require these work
>>arounds.
>>
>>Hans
>>
>>PS: Could we please make a retirement plan for all compilers?
>>gcc4 to be retired between 2008 and 2016
>>gcc3 to be retired between 2007 and 2013
>>VS7 to be retired between 2007 and 2010
>>VS6 to be retired between 2005 and 2006
>>
>>On 11/6/05 7:31 AM, "Lorensen, William E (Research)" <lorensen at crd.ge.com>
>>wrote:
>>
>>
>>
>>
>>
>>>Hans,
>>>
>>>Looks like the microsoft compilers don't like your code. I see that
>>>LoggerThreadWrapper is a subclass of its template parameter. Is this OK?
>>>
>>>Bill
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>_______________________________________________
>Insight-developers mailing list
>Insight-developers at itk.org
>http://www.itk.org/mailman/listinfo/insight-developers
>
>
>
More information about the Insight-developers
mailing list