[vtk-developers] Alternatives to vtkTemplateMacro

Jeff Baumes jeff.baumes at kitware.com
Tue Sep 15 12:00:19 EDT 2009


Tim,

Can you flesh your thoughts out in code so that I can understand your
suggestions better? In particular, what do you mean by "typelists"?

Thanks,
Jeff

On Mon, Sep 14, 2009 at 5:09 PM, Timothy M. Shead <tshead at sandia.gov> wrote:
> Moreland, Kenneth wrote:
>
>> The use case I am most worried about, because the use is very common,
>>
> is a functor that needs to take two arrays that have the same type.
> Typically this happens when you take an input array and use that data to
> construct an output array. You know they are the same type because you
> made the output array. To implement that right now, you have to pass one
> of the arrays as a field to the functor class, call the functor with the
> other array, and then do a type cast on the array. I argue that this is
> awkward to code and read. There should be a mechanism to define a
> functor that takes two typed arrays instead of one.
>>
>> Now for the difference between the two so far proposed methods
>> (which,
>
> for simplicity, I will call Tim’s method and Brad’s method). As usual,
> Brad’s solution is so clever that it takes me a long time just to
> understand all the cool magic things it does under the covers to make my
> life easier. If I understand it correctly, the “issue” with Tim’s method
> is that the functor has to implement every possible type supported by
> the Apply method. Even in Tim’s simple examples, the functor has to
> implement string versions of the function even though they are no-ops
> because they don’t do anything. In Brad’s method, you can simply
> implement the types you feel you need to support.
>>
>> The thing I don’t like about Brad’s methods is that it adds more
>> steps
>
> to the process. First you have to implement the functor (much like Tim’s
> method), then you have to create an apply_map and tell the map all the
> types your functor you support (which you have pretty much already
> specified when you declared the functor in the first place). I admit,
> mostly this is just an annoyance (remember, I like vtkTemplateMacro
> because all I need to do is define a templated function). But there is
> also an increased potential for errors. If you forget to (or
> inappropriately) define a type for a functor, then the compiler will
> give lots of nasty errors. However, if you forget to specify one of the
> types for the apply_map, then it will silently fail, perhaps some time
> later in the future because you forgot to test that type.
>>
>> I think the issue of having the functor implement types it does not
>
> really support could be addressed with Tim’s method by simply offering
> specialized versions of Apply that only work on some subset of the
> possible types. For example, a version of Apply that only downcast to
> numeric types would probably cover the majority of the cases.
>>
>> As far as the double dispatch is concerned, I’m not sure why you
>> can’t
>
> implement that by having a templated functor with an internal templated
> functor that worked with the other type. That is basically how you
> implement double dispatch with the current vtkTemplateMacro.
>
> Kudos to Brad for calling-out the double-dispatch nature of the problem.
>  That said, I agree with Ken that you could probably cover 95% of your
> use-cases with a couple of scenarios:
>
> 1) Filters that accept input arrays of any type, and produce output arrays
> of the same type.
>
> 2) Filters that accept input arrays from a set of types (say, all numeric
> array types), and produce output arrays of one specific type.
>
> To handle case 1), vtkArray already has a DeepCopy() method that can be used
> by a filter to create a new output array with the same type and contents as
> an input array.  For cases where you want to create an array with the same
> type, but avoid doing any copying, NewInstance() should do the trick.  I
> could imagine making this part of the proposed Apply() method, or part of a
> similar, related template algorithm.
>
> To handle case 2), my assumption is that a filter author is creating the
> output array that they want, so it can simply be a parameter in the caller's
> functor.
>
> That leaves the issue of explicitly specifying which concrete array types
> need to be handled in the caller's functor.  The Apply<> template could be
> parameterized using typelists to handle this, and I could imagine providing
> some preset typelists for e.g. "all types", "numeric types", "string types",
> and-so-on.  The nice thing about this approach is that callers could define
> their own typelists if they needed - "all integer types" for example.
>
> Cheers,
> Tim
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>



-- 
Jeff Baumes, Ph.D.
R&D Engineer, Kitware Inc.
(518) 881-4932
jeff.baumes at kitware.com



More information about the vtk-developers mailing list