[Insight-developers] GetMacro vs GetConstMacro

[Miller, James V (CRD)]

Currently, we use the GetMacros to "force" consistency in these implementations. We also have some
standard "debug" information in these macros.  It is probably the debug message that is the biggest
concern with removing the macros. Before smart pointers, we used the GetObjectMacro to enforce
reference counting.  But it doesn't look as though we need that now.

There is also a lot of code that does not use the GetMacros: either because the code was so simple,
or because the method needed to be virtual, etc.

The SetMacros, on the other hand, are more relevant since they compare the values and call Modified()
if needed.




-----Original Message-----
From: Brad King [mailto:brad.king@kitware.com]
Sent: Tuesday, February 20, 2001 2:17 PM
To: Insight Developers
Subject: RE: [Insight-developers] GetMacro vs GetConstMacro


> 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



_______________________________________________
Insight-developers mailing list
Insight-developers@public.kitware.com
http://public.kitware.com/mailman/listinfo/insight-developers