1. 1 ITK Lecture 2 A brief C++ review Methods in Image Analysis CMU Robotics Institute 16-725 U. Pitt Bioengineering 2630 Spring Term, 2006 Methods in Image Analysis CMU Robotics Institute 16-725 U. Pitt Bioengineering 2630 Spring Term, 2006

2. 2 Goals for this lecture  Review of object oriented programming  Public / private / protected derivation  Review of generic programming  templates  templated classes  specialization  typedef & typename keywords  Review of object oriented programming  Public / private / protected derivation  Review of generic programming  templates  templated classes  specialization  typedef & typename keywords

3. 3 Disclaimer  Many of you know more about object oriented programming than what I will present (or what I know)  We will not discuss the more esoteric inheritance methods, such as friend classes  Many of you know more about object oriented programming than what I will present (or what I know)  We will not discuss the more esoteric inheritance methods, such as friend classes

4. 4 George recommends  C++ How to Program - Deitel & Deitel  Using the STL: The C++ Standard Template Library - Robson  Design Patterns; Elements of Reusable Object-Oriented Software - Gamma et al.  C++ How to Program - Deitel & Deitel  Using the STL: The C++ Standard Template Library - Robson  Design Patterns; Elements of Reusable Object-Oriented Software - Gamma et al.

5. 5 I also like…  Teach Yourself C++ in 21 Days - Liberty  The OpenGL Superbible - Wright & Sweet  Teach Yourself C++ in 21 Days - Liberty  The OpenGL Superbible - Wright & Sweet

6. 6 Formatting note  In general, I will try to format code as follows: this->IsSome(code);  However, not all code that I will present could actually be executed (the above, for instance)  In general, I will try to format code as follows: this->IsSome(code);  However, not all code that I will present could actually be executed (the above, for instance)

7. 7 Namespaces  Namespaces solve the problem of classes that have the same name  E.g., ITK contains an Array class, perhaps your favorite add-on toolkit does too  You can avoid conflicts by creating your own namespace around code namespace itk { code }  Namespaces solve the problem of classes that have the same name  E.g., ITK contains an Array class, perhaps your favorite add-on toolkit does too  You can avoid conflicts by creating your own namespace around code namespace itk { code }

8. 8 Namespaces, cont.  Within a given namespace, you refer to other classes in the same namespace by their name only, e.g. inside the itk namespace Array means “use the ITK array”  Outside of the namespace, you use the itk:: prefix, e.g. itk::Array  Only code which is part of the toolkit should be inside the itk namespace  At minimum, you’re always in the global namespace  Within a given namespace, you refer to other classes in the same namespace by their name only, e.g. inside the itk namespace Array means “use the ITK array”  Outside of the namespace, you use the itk:: prefix, e.g. itk::Array  Only code which is part of the toolkit should be inside the itk namespace  At minimum, you’re always in the global namespace

9. 9 Namespaces, cont.  Note that code within the itk namespace should refer to code outside of the namespace explicitly  E.g. use std::cout instead of cout  Note that code within the itk namespace should refer to code outside of the namespace explicitly  E.g. use std::cout instead of cout

10. 10 Object-oriented programming  Identify functional units in your design  Write classes to implement these functional units  Separate functionality as much as possible to promote code re-use  Identify functional units in your design  Write classes to implement these functional units  Separate functionality as much as possible to promote code re-use

11. 11 Class membership  Classes have member variables and methods  ITK names class member variables with the “m_” prefix, as in “m_VariableName”  Class members are 1 of 3 types  Public  Private  Protected  Classes have member variables and methods  ITK names class member variables with the “m_” prefix, as in “m_VariableName”  Class members are 1 of 3 types  Public  Private  Protected

12. 12 Public membership  Everyone can access the member  The rest of the world  The class itself  Child classes  You should avoid making member variables public, in order to prevent undesired modification  Everyone can access the member  The rest of the world  The class itself  Child classes  You should avoid making member variables public, in order to prevent undesired modification

13. 13 Private membership  Only the class itself can access the member  It’s not visible to the rest of the world  Child classes can’t access it either  Only the class itself can access the member  It’s not visible to the rest of the world  Child classes can’t access it either

14. 14 Protected membership  The middle ground between public and private  The outside world can’t access it… but derived classes can  The middle ground between public and private  The outside world can’t access it… but derived classes can

15. 15 ITK and membership  In ITK, member variables are almost always private  There are public accessor functions that allow the rest of the world to get and set the value of the private member  This ensures that the class knows when the value of a variable changes  In ITK, member variables are almost always private  There are public accessor functions that allow the rest of the world to get and set the value of the private member  This ensures that the class knows when the value of a variable changes

16. 16 Why do it this way?  Consider a filter class - if someone changes a variable in the filter, it should re-run itself the next time the user asks for output  If nothing has changed, it doesn’t waste time running again  Accessor functions set a “modified flag” to notify the framework when things have changed  More on this in coming weeks  Consider a filter class - if someone changes a variable in the filter, it should re-run itself the next time the user asks for output  If nothing has changed, it doesn’t waste time running again  Accessor functions set a “modified flag” to notify the framework when things have changed  More on this in coming weeks

17. 17 Inheritance in a nutshell  Pull common functionality into a base class  Implement specific functionality in derived classes  Don’t re-invent the wheel!  Base classes = parents  Derived classes = children  Pull common functionality into a base class  Implement specific functionality in derived classes  Don’t re-invent the wheel!  Base classes = parents  Derived classes = children

18. 18 Overloading  If a child class re-implements a function from the base class, it “overloads” the function  You can use this to change the behavior of a function in the child class, while preserving the global interface  If a child class re-implements a function from the base class, it “overloads” the function  You can use this to change the behavior of a function in the child class, while preserving the global interface

19. 19 An example of ITK inheritance itk::DataObject itk::ImageBase itk::Image itk::DataObject itk::ImageBase itk::Image

20. 20 Virtual functions  Virtual functions allow you to declare functions that “might” or “must” be in child classes  You can specify (and use) a virtual function without knowing how it will be implemented in child classes  Virtual functions allow you to declare functions that “might” or “must” be in child classes  You can specify (and use) a virtual function without knowing how it will be implemented in child classes

21. 21 Virtual functions, cont.  The “=0” declaration means that the function must be implemented in a child class  For example: virtual void DrawSelf() = 0;  The “=0” declaration means that the function must be implemented in a child class  For example: virtual void DrawSelf() = 0;

22. 22 Generic programming  Generic programming encourages:  Writing code without reference to a specific data type (float, int, etc.)  Designing code in the most “abstract” manner possible  Why?  Trades a little extra design time for greatly improved re-usability  Generic programming encourages:  Writing code without reference to a specific data type (float, int, etc.)  Designing code in the most “abstract” manner possible  Why?  Trades a little extra design time for greatly improved re-usability

23. 23 Image example  Images are usually stored as arrays of a particular data type  e.g. unsigned char[256*256]  It’s convenient to wrap this array inside an image class (good object oriented design)  Allowing the user to change the image size is easy with dynamically allocated arrays  Images are usually stored as arrays of a particular data type  e.g. unsigned char[256*256]  It’s convenient to wrap this array inside an image class (good object oriented design)  Allowing the user to change the image size is easy with dynamically allocated arrays

24. 24 Image example, cont.  Unfortunately, changing the data type is not so easy  Typically you make a design choice and live with it (most common)  Or, you’re forced to implement a double class, a float class, an int class, and so on (less common, complicated)  Unfortunately, changing the data type is not so easy  Typically you make a design choice and live with it (most common)  Or, you’re forced to implement a double class, a float class, an int class, and so on (less common, complicated)

25. 25 Templates to the rescue  Templates provide a way out of the data type quandary  If you’re familiar with macros, you can think of templates as macros on steroids  With templates, you design classes to handle an arbitrary “type”  Templates provide a way out of the data type quandary  If you’re familiar with macros, you can think of templates as macros on steroids  With templates, you design classes to handle an arbitrary “type”

26. 26 Anatomy of a templated class template class ITK_EXPORT Image : public ImageBase template class ITK_EXPORT Image : public ImageBase Template keyword, the ’s enclose template parameters

27. 27 TPixel is a class (of some sort) Anatomy of a templated class template class ITK_EXPORT Image : public ImageBase template class ITK_EXPORT Image : public ImageBase

28. 28 VImageDimension is an unsigned int, with a default value of 2 template class ITK_EXPORT Image : public ImageBase template class ITK_EXPORT Image : public ImageBase Anatomy of a templated class

29. 29 Image is the name of this class template class ITK_EXPORT Image : public ImageBase template class ITK_EXPORT Image : public ImageBase Anatomy of a templated class

30. 30 Image is derived from ImageBase in a public manner template class ITK_EXPORT Image : public ImageBase template class ITK_EXPORT Image : public ImageBase Anatomy of a templated class

31. 31 Specialization  When you specify all of the template parameters, you “fully specialize” the class  In the previous example, ImageBase specializes the base class by specifying its template parameter. Note that the VImageDimension parameter is actually “passed through” from Image’s template parameters  When you specify all of the template parameters, you “fully specialize” the class  In the previous example, ImageBase specializes the base class by specifying its template parameter. Note that the VImageDimension parameter is actually “passed through” from Image’s template parameters

32. 32 Derivation from templated classes  You must specify all template parameters of the base class  The template parameters of the base class may or may not be linked to template parameters of the derived class  You can derive a non-templated class from a templated one if you want to if you (by hard coding all of the template parameters)  You must specify all template parameters of the base class  The template parameters of the base class may or may not be linked to template parameters of the derived class  You can derive a non-templated class from a templated one if you want to if you (by hard coding all of the template parameters)

33. 33 Templated class instances  To create an instance of a templated class, you must fully specialize it  E.g. itk::Image myImage; Creates a 3D image of integers (not quite true, but we can pretend it does until we cover smart pointers)  To create an instance of a templated class, you must fully specialize it  E.g. itk::Image myImage; Creates a 3D image of integers (not quite true, but we can pretend it does until we cover smart pointers)

34. 34 Alas…  C++ actually allows partial specialization  For example, you write an Image class that must be 3D, but still templates the pixel type (or vice-versa)  Unfortunately, not all compilers support this (VS.net 2003+ does, newer GCCs too)  C++ actually allows partial specialization  For example, you write an Image class that must be 3D, but still templates the pixel type (or vice-versa)  Unfortunately, not all compilers support this (VS.net 2003+ does, newer GCCs too)

35. 35 Typedefs  One consequence of templates is that the names of a fully defined type may be quite long  E.g. itk::Image, 3> might be a legal type  One consequence of templates is that the names of a fully defined type may be quite long  E.g. itk::Image, 3> might be a legal type

36. 36 Typedefs cont.  You can create a user-defined type by using the typedef keyword typedef itk::Image 3DIntImageType; 3DIntImageType myImage; 3DIntImageType anotherImage;  You can create a user-defined type by using the typedef keyword typedef itk::Image 3DIntImageType; 3DIntImageType myImage; 3DIntImageType anotherImage;

37. 37 Fun with typedefs  Typedefs can be global members of classes and accessed as such typedef itk::Image ImageType; ImageType::Pointer im = myFilter.GetOutput();  In template classes, member typedefs are often defined in terms of template parameters - no problem! This is actually quite handy.  Typedefs can be global members of classes and accessed as such typedef itk::Image ImageType; ImageType::Pointer im = myFilter.GetOutput();  In template classes, member typedefs are often defined in terms of template parameters - no problem! This is actually quite handy.

38. 38 Naming of templates and typedefs  ITK uses the following conventions:  Template parameters are indicated by T (for type) or V (for value). E.g. TPixel means “the type of the pixel” and VImageDimension means “value template parameter image dimension”  Defined types are named as FooType. E.g. CharImage5DType  ITK uses the following conventions:  Template parameters are indicated by T (for type) or V (for value). E.g. TPixel means “the type of the pixel” and VImageDimension means “value template parameter image dimension”  Defined types are named as FooType. E.g. CharImage5DType

39. 39 Be careful  If you’re careless in naming classes, template arguments, typedefs, and member variables (with the “m_” prefix) it can be quite difficult to tell them apart! Don’t write a new language using typedefs.  Remember to comment well and don’t use obscure names; e.g. BPType is bad, BoundaryPointType is good  If you’re careless in naming classes, template arguments, typedefs, and member variables (with the “m_” prefix) it can be quite difficult to tell them apart! Don’t write a new language using typedefs.  Remember to comment well and don’t use obscure names; e.g. BPType is bad, BoundaryPointType is good

40. 40 Typenames  typename is a keyword you will learn to dislike  Different compilers handle it differently  In general, you can take it to mean that its target is “some sort of type, but you’re not sure what kind”  typename is a keyword you will learn to dislike  Different compilers handle it differently  In general, you can take it to mean that its target is “some sort of type, but you’re not sure what kind”

41. 41 Typenames, cont. For example: typename SomeType typeInstance; “typename” tells the compiler that SomeType is the name of a valid type, and not just a nonsense word For example: typename SomeType typeInstance; “typename” tells the compiler that SomeType is the name of a valid type, and not just a nonsense word

42. 42 Typenames, cont.  Mac and Windows seem to largely ignore typenames - in fact, the Mac compiler insists they’re “deprecated”  On Linux, you need to preface template parameter types with typename  My advice: try adding typename if something looks correct and won’t compile  Mac and Windows seem to largely ignore typenames - in fact, the Mac compiler insists they’re “deprecated”  On Linux, you need to preface template parameter types with typename  My advice: try adding typename if something looks correct and won’t compile

43. 43 For more on “typename”  http://blogs.msdn.com/slippman/archive/ 2004/08/11/212768.aspx

44. 44.txx,.cxx,.h  ITK uses three standard file extensions: .h files indicate a class header file .cxx indicates either a) executable code (an example, test, demo, etc.) b) a non-templated class implementation .txx indicates a templated class implementation  ITK uses three standard file extensions: .h files indicate a class header file .cxx indicates either a) executable code (an example, test, demo, etc.) b) a non-templated class implementation .txx indicates a templated class implementation

45. 45 Final advice  If you run across something in ITK you don’t understand, don’t panic  Be careful not to confuse typedefs with classes  Error messages can be quite long with templates and will take time to get used to  Email for help sooner rather than later  Learning the style of C++ used by ITK is at least half of the battle  If you run across something in ITK you don’t understand, don’t panic  Be careful not to confuse typedefs with classes  Error messages can be quite long with templates and will take time to get used to  Email for help sooner rather than later  Learning the style of C++ used by ITK is at least half of the battle