[Insight-developers] STYLE: Un-necessary use of static_cast -- should we care?

[Bill Lorensen]

At this point, anything that slows down ITK should be avoided.

On Monday, July 23, 2012, Matt McCormick <matt.mccormick at kitware.com> wrote:
> On Mon, Jul 23, 2012 at 9:22 PM, Williams, Norman K
> <norman-k-williams at uiowa.edu> wrote:
>> RE unnecessary casts: Personally, I think casts uglify code and should
>> only be there as a way for the programmer to communicate intention to the
>> compiler.
>>
>>
>> RE adding dynamic casts: I don't know what the real overhead of a
>> dynamic_cast vs a static_cast entails, and I suspect it varies depending
>> on what compiler you use. Determining if it is logically impossible for
>> dynamic_cast to fail isn't easy; and not all filters are written in such
a
>> way that prevent assigning bad inputs, like adding an Image where a Mesh
>> is expected.
>>
>> I like Sean McBride's idea of a debug-only assert.  In fact it might be
>> useful to use static_cast for release and dynamic_cast + assert(rval !=
0)
>> for debug builds.
>
> Keep in mind that static_cast is done at compile time and dynamic_cast
> is done during runtime.  My understanding is that dynamic_cast can be
> "expensive", and an assert is not saving anything relative to the cost
> of the dynamic_cast.
>
> Some performance numbers:
>
>   http://tinodidriksen.com/2010/04/14/cpp-dynamic-cast-performance/
>
> Thanks,
> Matt
>
>>
>> On 7/23/12 3:58 PM, "Matt McCormick" <matt.mccormick at kitware.com> wrote:
>>
>>>>
>>>> So the question is this: do we keep static_cast where they aren't
>>>>needed?
>>>
>>>Since it is a matter of human-readability, something consistent is
>>>preferred, whatever that may be...
>>>
>>>> and should we add dynamic_cast in the frequent case where an input or
>>>> output of a filter is assumed to be of a particular type?
>>>>
>>>
>>>If it is not logically possible in the code for the dynamic_cast to
>>>fail, and given the GetInput/GetOutput consequences, avoiding
>>>unnecessary overhead seems best.
>>
>>
>>
>> ________________________________
>> Notice: This UI Health Care e-mail (including attachments) is covered by
the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is
confidential and may be legally privileged.  If you are not the intended
recipient, you are hereby notified that any retention, dissemination,
distribution, or copying of this communication is strictly prohibited.
 Please reply to the sender that you have received the message in error,
then delete it.  Thank you.
>> ________________________________
>> _______________________________________________
>> 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://www.itk.org/mailman/listinfo/insight-developers
> _______________________________________________
> 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://www.itk.org/mailman/listinfo/insight-developers
>

-- 
Unpaid intern in BillsBasement at noware dot com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-developers/attachments/20120723/f596b580/attachment.htm>