[Insight-developers] Portability Question
Miller, James V (Research)
millerjv@crd.ge.com
Tue, 11 Mar 2003 12:24:05 -0500
Something similar to #1 may work. I think the original implementation
you had did not have the proper forward/extern declarations followed by
the appropriate implementations/specialization signatures.
However, #1 may not be portable because it (may) fall under the
umbrella of partial specialization. I'd have to dig around to see
this if this is the case. But since you specializing a single method
as opposed to the entire class, it might be considered partial specialization.
One solution is to provided overloaded functions (outside the class, i.e.
not member functions) that allow overload operator<<()
template<class T>
std::ostream & operator<<(std::ostream &os, const T &obj)
{
os << object << std::endl;
return os;
}
template<>
std::ostream & operator<<(std::ostream &os, const itk::Object *obj)
{
obj->PrintSelf(os,indent);
}
> -----Original Message-----
> From: Hans Johnson [mailto:hjohnson@mail.psychiatry.uiowa.edu]
> Sent: Tuesday, March 11, 2003 11:31 AM
> To: insight-developers@public.kitware.com
> Subject: [Insight-developers] Portability Question
>
>
> 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
> ===================================================================
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers
>