[Insight-developers] MetaDataObject Checkins
Hans Johnson
hans-johnson@uiowa.edu
Mon, 10 Mar 2003 12:19:32 -0600
James,
Nothing is wrong with that as far as I am concerned, but then we would
have to modify itk::Image to work with operator<<.
When designing this class I wanted to empower application developers to
use this mechanism for doing some of the more difficult object tracking
tasks. Some of the difficult cases that I wanted to make sure worked were:
1) Be able to add an image as a dictionary element to an image (for
exmple to hold a 32x32 thumbnail icon representation of the image for
use by a gui.)
2) Make all itk objects (spatial or image) easily compatible with the
itk::MetaDataDictionary.
3) Provide a set of utilities to help the programmer in debugging the
the code. This was the whole motivation for implementing the PrintSelf
functionality of the itk::MetaDataDictionary. This is not necessary to
make the dictionary mechanism work, but it is a big help when tracking
down bugs in the code. In addition, a gui application that wants to
display the biographical information about an object could use this
function in an object viewer with 3 panes, object selector pane, object
thumbnail pane, and object bio-info pane.
4) Provide a default template class (itk::MetaDataObject<T>)
implementation that can encompass any object (itk or otherwise) without
specialization. In addition, I wanted to avoid subclassing itk objects
just to add the operator<< functionality.
I do like the idea of requiring the operator<< be defined as part of the
requirements for using that object as a template parameter to the
itk::MetaDataObject<T> class.
Is there a compile time way to enforce that operator<< works for a given
object (class and native types)?
If this is the best way to go, can we add a default operator<< to each
itk class as follows:
ostream &operator<<(ostream & currentstream)
{
this->PrintSelf(currentstream, 0);
}
Thanks for you advice,
Hans
Miller, James V (Research) wrote:
> What is wrong with relying on having operator<< defined?
>
>
>
>
>>-----Original Message-----
>>From: Hans Johnson [mailto:hjohnson@mail.psychiatry.uiowa.edu]
>>Sent: Monday, March 10, 2003 11:06 AM
>>To: Insight-developers@public.kitware.com
>>Subject: Re: [Insight-developers] MetaDataObject Checkins
>>
>>
>>Bill,
>>
>>2)-------------
>>Can you tell me what part of the specializations is not portable?
>>
>>The idea behind the itkMetaDataObject is that it can encapsulate
>>anything. Because of that I made a default
>>itk::MetaDataObject<T>::PrintSelf that just printed a string stating
>>that the type can not print itself. Then specializations of that
>>function could be written for cases where print self was well defined.
>>
>>For example, encapsulating a native C types would be done with the
>>trivial implementations of:
>>itk::MetaDataObject<int>
>>::PrintSelf(std::ostream& os, Indent indent) const
>>{
>> os << indent << this->m_MetaDataObjectValue << std::endl;
>>}
>>
>>whereas encapsulating an itk::Image would use:
>>
>>itk::MetaDataObject<int>
>>::PrintSelf(std::ostream& os, Indent indent) const
>>{
>> this->m_MetaDataObjectValue->PrintSelf(os,indent);
>>}
>>
>>and non itk-application developers could write:
>>itk::MetaDataObject<MyElephantClass>
>>::PrintSelf(std::ostream& os, Indent indent) const
>>{
>> std::cout << indent
>> << this->m_MetaDataObjectValue->GetTrunk()
>> << " "
>> << this->m_MetaDataObjectValue->GetEars()
>> << " "
>> << this->m_MetaDataObjectValue->GetTail()
>> << std::endl;
>>}
>>
>>The current implementation will have to be changed, because
>>it will work
>>only for classes that have the operator<< defined to work
>>with ostreams.
>>
>>If you or anyone else has a portable way of doing this, please let me
>>know, and I will implement it right away.
>>
>>Again, sorry about causing all these problems.
>>
>>Regards,
>>Hans J. Johnson
>>hans-johnson@uiowa.edu
>>
>>
>>
>>Lorensen, William E (Research) wrote:
>> > Hans,
>> >
>> > I corrected a couple of problems with your checkins.
>> >
>> > 1) itkMetaDataObject.txx did not have #define guards
>>around the code.
>>In itk, all .txx files must be
>> > includable on their own. To enforce this, the header test
>>generator
>>will include the .txx file if one
>> > exists. I added guards.
>> >
>> > 2) I removed the specialization of the printself methods.
>>The usage
>>was not portable, but looking
>> > into at the code it l;ooks like you don't need the
>>specialization. I
>>moved the output into the
>> > class's PrintSelf. I lalso removed all the code form the
>>itkMetaDataObject.cxx file. I did not remove
>> > that file form CMakeLists.txt file because I wasn't sure
>>if you have
>>future plans for this file.
>> >
>> > I made the changes so that we can get some clean continuous builds
>>early today. I know that Bill Hoff
>> > is ready to check in his vnl changes.
>> >
>> > Bill
>> >
>> > _______________________________________________
>> > Insight-developers mailing list
>> > Insight-developers@public.kitware.com
>> > http://public.kitware.com/mailman/listinfo/insight-developers
>>
>>
>>--
>>===================================================================
>>Hans J. Johnson W294 GH
>>hans-johnson@uiowa.edu Dept. of Psychiatry
>>http://www.psychiatry.uiowa.edu/~hjohnson The University of Iowa
>>(319) 353-8587 Iowa City, IA 52242
>>===================================================================
>>
>>
>>_______________________________________________
>>Insight-developers mailing list
>>Insight-developers@public.kitware.com
>>http://public.kitware.com/mailman/listinfo/insight-developers
>>
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers
--
===================================================================
Hans J. Johnson W294 GH
hans-johnson@uiowa.edu Dept. of Psychiatry
http://www.psychiatry.uiowa.edu/~hjohnson The University of Iowa
(319) 353-8587 Iowa City, IA 52242
===================================================================