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

Williams, Norman K norman-k-williams at uiowa.edu
Mon Jul 23 17:22:53 EDT 2012


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.

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.
________________________________


More information about the Insight-developers mailing list