[Insight-developers] GetMacro vs GetConstMacro

Brad King brad.king@kitware.com
Tue, 20 Feb 2001 14:17:02 -0500 (EST)


> I have been struggling with this as well.  I think the solution is
> probably to have more macros.  I think of it as a matrix of options:
> 
> 1) Do I want to return a copy or a reference to a item?
> 2) Do I want the user to be able to modify the item returned, is item const?
> 3) Do I want the user to be able call the method on a const object?
> 
> There is a forth option of calling on a const object AND allowing the
> user to modify the return value but that case should be avoided.  So
> to me it seems as though there should be 3 macros.

There are other issues here in the various combinations when we return
pointers.  There are multiple levels of cv-qualifiers on a pointer:

  BigInt* GetBigInt() const { return m_BigInt; }
  const BigInt* GetBigIntAndIncrement() { return m_BigInt++; }

In the first version, the method can be const because it does not change
the value of the POINTER, which is what is actually stored in the class.  
The const qualifier in the second version tells the compiler that whatever
the pointer points TO cannot be changed.  Then it is allows to increment
the pointer value because the method itself is not const.

I think that the original purpose of the GetMacro was to quickly create a
Get method for a member where the code is trivial and the same over and
over again.  If we have all these different versions, then the code is not
the same.  Perhaps instead we should just not use the GetMacro, and
explicitly write out the Get method inlined in the headers.  IMHO, a line
like

  const String& GetName() const { return m_Name; }

is much clearer than having to know what the macro does:

  itkGetConstMacro(Name)

and allows different forms to be easily created

  int GetValue() const { return m_Value; }

A perl script could quickly change all the existing macros over.

Thoughts?
-Brad