Brad,
Nicely put. Thank you everyone for digging into this issues and putting
careful consideration into identifying the root of the problem.
Hans
--
On 11/15/16, 9:17 AM, "Lowekamp, Bradley (NIH/NLM/LHC) [C]"
<blowek...@mail.nih.gov> wrote:
> On Nov 14, 2016, at 6:18 PM, Matt McCormick <matt.mccorm...@kitware.com>
wrote:
>
> On Mon, Nov 14, 2016 at 2:18 PM, Lowekamp, Bradley (NIH/NLM/LHC) [C]
> <blowek...@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
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Kitware offers ITK Training Courses, for more information visit:
http://kitware.com/products/protraining.php
Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/insight-developers
