[Insight-developers] Get/SetMacro

[Damion Shelton]

Yup... Get/Set seems to be working with itk::Array now. Thanks.

-Damion-

--On Tuesday, December 04, 2001 2:50 PM -0500 Will Schroeder 
<will.schroeder@kitware.com> wrote:

> Hi Damion-
>
> At 02:33 PM 12/4/2001 -0500, Damion Shelton wrote:
>> Thanks, I'll have to check on that tommorrow (at a different lab today).
>>
>> A few other questions... I noticed in browsing some other code that
>> there  are two other macros:
>>
>> itkGetVectorMacro
>> itkSetVectorMacro
>>
>> If the normal gets/sets work correctly with Arrays and Vectors after
>> your  change, is there any distinction between a Get and a GetVector?
>> Also, are  the != and == operators sufficient for an object to be parsed
>> by Get/Set;  i.e., if I create some random object that implements != and
>> ==, will a  Get/SetMacro work on it?
>
> I'm thinking the same way you are...I'm not sure the vector macros make
> sense...have to think this over some more. Although there are many
> classes that have data members that are arrays of native type. So unless
> these are all converted to itk::Array members, we should leave the
> SetVector macros in. Set/Get also depends on the type supporting the
> Modified() method as well GetDebug() methods (in general, things that are
> a subclass of itk::Object).
>
>
>> I'm assuming (without) looking at the code that != and == are used to
>> determine whether or not to set the object-modified flag or not. It was
>> mentioned at the NLM meeting, that in general (aside from Get/Set
>> macros),  we should manually set the modified flag when setting
>> parameters in our  own functions. If it's not clear (or difficult to
>> tell) if an object has  actually changed in a Set function - for
>> example, if it does not implement  == or !=, or if a comparison would
>> involve a complex recursive comparison  (I'm thinking blox structures) -
>> should we just assume that it has?
>
> If it turns out that its hard to determine whether something has been
> modified, often you can do some simple checks to find the obvious
> situations, but beyond that its safer to send a Modified() than to ignore
> it. At least then the pipeline will be up to date, even if it does
> execute too often.
>
> Will
>