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" <[email protected]> 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
