[Insight-developers] Portability Question
Hans Johnson
hans-johnson@uiowa.edu
Tue, 11 Mar 2003 10:30:48 -0600
Portability Experts,
I would like to complete my work on the MetaDataDictionary as soon as
possible. The last problem that I am encountering is in implementing a
portable mechanism for printing off some of the information that is
encompassed in a MetaDataObject.
Can you tell me what part of the specializations is not portable?
Three solutions follow:
========================================================================
========Solution #1==(Possibly non-portable, but I don't know why)=====
The idea behind the itkMetaDataObject is that it can encapsulate
anything. Because of that I made a default version of:
itk::MetaDataObject<T>
::PrintSelf(std::ostream& os, Indent indent) const
{
os << indent << "Unknown print characteristics for type: "
<< typeid( this->m_MetaDataObjectValue).name()<< std::endl;
}
Then explicit specializations of that function could be written for
cases where print self was well defined.
For example, encapsulating native C types would be done with the trivial
explicit implementations of:
#define NATIVE_TYPE_PRINTSELF(TYPE_NAME) \
itk::MetaDataObject<TYPE_NAME> \
::PrintSelf(std::ostream& os, Indent indent) const \
{ \
os << indent << this->m_MetaDataObjectValue << std::endl; \
} \
itk::MetaDataObject<const TYPE_NAME> \
::PrintSelf(std::ostream& os, Indent indent) const \
{ \
os << indent << this->m_MetaDataObjectValue << std::endl; \
}
NATIVE_TYPE_PRINTSELF(char)
NATIVE_TYPE_PRINTSELF(char *)
NATIVE_TYPE_PRINTSELF(unsigned char)
NATIVE_TYPE_PRINTSELF(short int)
NATIVE_TYPE_PRINTSELF(unsigned short int)
NATIVE_TYPE_PRINTSELF(int)
NATIVE_TYPE_PRINTSELF(unsigned int)
NATIVE_TYPE_PRINTSELF(long int)
NATIVE_TYPE_PRINTSELF(unsigned long int)
NATIVE_TYPE_PRINTSELF(float)
NATIVE_TYPE_PRINTSELF(double)
NATIVE_TYPE_PRINTSELF(std::complex<float>)
NATIVE_TYPE_PRINTSELF(std::complex<double>)
NATIVE_TYPE_PRINTSELF(std::string)
whereas encapsulating of itk::Objects would use:
itk::MetaDataObject<itk::Object>
::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;
}
Can you please tell me why this is not portable?
If you have a portable way of doing this, please let me know, and I will
implement it right away.
========================================================================
======Solution #2==(More invasive to the ITK class structure)=========
Change the current ITK Object class to include a definition for
std::ostream& operator<<(std::ostream current_stream)
{
this->PrintSelf(current_stream,0);
}
========================================================================
=======Solution #3 ===(Ugly, but it would work)========================
Remove PrintSelf from MetaDataDictionary and MetaDataObjects.
The printing functionality is not strictly needed, but it will make
using the MetaDataDictionary much more difficult to use for the most
common cases.
========================================================================
I would really appreaciate any and all comments on this.
Thanks,
Hans J. Johnson
hans-johnson@uiowa.edu
-------- Original Message --------
Subject: Re: [Insight-developers] MetaDataObject Checkins
Date: Mon, 10 Mar 2003 12:19:32 -0600
From: Hans Johnson <hjohnson@mail.psychiatry.uiowa.edu>
Reply-To: hans-johnson@uiowa.edu
Organization: The Unversity of Iowa
To: "Miller, James V (Research)" <millerjv@crd.ge.com>
CC: Insight-developers@public.kitware.com
References: <FBE90DFC240BA541B38A43F39913A16D0446105B@xmb02crdge>
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
===================================================================
--
===================================================================
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
===================================================================