[ITK-dev] [slicer-devel] Workaround for dynamic_cast on Mac OSX

[Lowekamp, Bradley (NIH/NLM/LHC) [C]]

> On Nov 14, 2016, at 6:18 PM, Matt McCormick <matt.mccormick at kitware.com> wrote:
> 
> On Mon, Nov 14, 2016 at 2:18 PM, Lowekamp, Bradley (NIH/NLM/LHC) [C]
> <blowekamp at mail.nih.gov> wrote:
>> Matt,
>> 
>> I believe that GCC 4.1 also had a very similar problem to what is occurring in with Apple Clang now.
> 
> Thanks to the GCC version dashboard builds that you maintain, we
> should be able to see if other GCC's have that issue, too :-).
> 

Based on the good information Isaiah has referenced: It may be that the prior gcc 4.1 behavior was due to the version of libstdc++ that was distributed with gcc 4.1, so with the dashboard system using gcc4.1 with libstdc++.so.6.0.19 at runtime may have different behavior.

> 
>> It’s interesting to note that Slicer CLI interface does not contain ITK templated objects. Does Slicer use ITK objects any where in it’s public API’s?
> 
> Note that this issue becomes predominantly problematic when ITK
> templated objects are not in the ABI but used internally (as in the
> test case).
> 
> 
> Thanks,
> Matt

I’m not sure what the right term is. Yes, in the test case the templated object is not explicitly in the ABI/API of the library, but the method exposes private templated objects by producing objects which are intended to be “cast" to the templated object. So by documentation and behavior instances of private templated object are exposed in the API of the test case?

So my point? I think that developing a clean interface without excessive multiple instances as well as not exposing private instance is important and should be the first approach. If there are places remaining in Slicer or ITK which “expose” private symbols I would like to help to directly address them.

I also acknowledge that some interfaces were not designed with this in mind and are limited in their ability to meet these best practices and therefor need the “SafeDownCast” work around.

I think I have gone past my 2 cents on this issue.

HTH,
Brad