On Mon, Jul 23, 2012 at 9:22 PM, Williams, Norman K <[email protected]> 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" <[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 _______________________________________________ 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
