[Insight-developers] Request for testing help: itkImageIOBase.cxx

[Miller, James V (GE, Research)]

Kent,

It compiles fine for me on Visual Studio .NET 2003 (7.1).

Don't know about Borland or VS7 or VS6.

Looking at it SetPixelTypeInfo() method, why is Offset handled separately from
the other pixel type?  

Another minor point is that the function name is itkCheckPType(). I would call 
itkSetPixelType() since it actually "sets" the pixel type information 
and returns false if it cannot.

As for performance, this code is not call very frequently, so I wouldn't worry 
about it.

Finally, the Dashboard is all red.  You might want to wait to check it in.

Jim


-----Original Message-----
From: insight-developers-bounces+millerjv=crd.ge.com at itk.org
[mailto:insight-developers-bounces+millerjv=crd.ge.com at itk.org]On Behalf
Of Kent Williams
Sent: Thursday, July 13, 2006 2:57 PM
To: Insight-developers (E-mail)
Subject: [Insight-developers] Request for testing help:
itkImageIOBase.cxx


Today I rewrote the big ugly macro associated with 
itk::ImageIOBase::SetPixelTypeInfo() that handles setting the 
ComponentType, PixelType, and NumberOfComponents. 

I turned the macro into a templated function which smart compilers will 
inline to pretty much the same code as the macro version;  what I need 
to know is if it will blow the mind of the Borland or Microsoft 
compilers.  So if anyone uses those as their main compilers, could you 
download the attached file into Insight/Code/IO and tell me if it causes 
problems?

I can argue pretty strongly that this is a major improvement over the 
macro.  Preprocessor macros make it nearly impossible to debug, for one 
thing.  For another, the macros make for this insult to C++ syntax:

if itkCheckPTypeMacro(char, CHAR)
else if itkCheckPTypeMacro(unsigned char, UCHAR)
else if itkCheckPTypeMacro(short, SHORT)
else if itkCheckPTypeMacro(unsigned short, USHORT)
else if itkCheckPTypeMacro(int, INT)

If no-one is willing or able to test this for me I'll check it in first 
thing tomorrow morning and see if it breaks any builds.

I'm think this code could be telescoped into something even more 
concise, but it would involve having a template specialization for every 
supported pixel data type.