Re: [brlcad-devel] BRL-CAD C++ Geometry Engine
Open Source Solid Modeling CAD
Brought to you by:
brlcad
From: Christopher S. M. <br...@ma...> - 2008-08-20 07:37:00
|
On Aug 5, 2008, at 7:19 PM, Manuel A. Fernandez Montecelo wrote: > I like an article about this (clicking on "print" link recommended): > http://www.ddj.com/cpp/184401608 and I use something like this for > my code in > g3d (the OpenGL GUI client that will use libged). Mm, I should have perhaps been more specific. :-) The question wasn't so much to question what's good about it from a technical perspective but more what it implies from a project management perspective. What you mentioned in a follow-up e-mail about API compatibility is one of the issues (and arguably the most important). Another is the implication of running into more run-time issues (that tend to be crash/exception-worthy). Another is potential distribution/linkage implications of rtti libraries on Windows (not my area). Technically, it's certainly a reasonable approach albeit not without tradeoffs. There can be performance implications and API complexity that is added that impacts long-term maintenance. The article uses contract programming, which is great, but which you can implement with or without rtti very easily too. The best technical counter- argument to using rtti that comes to mind is that you can usually achieve the exact same result using a data-driven model. A data- driven implementation tends to be very straight-forward and simple to implement while avoiding the issues. There are good cases on both sides, technically I think it's more a case-by-case decision that amounts to there being a strong justification (i.e., beyond syntactic sugar). My original question, though, is actually about the management, maintainability, and integration aspects more than the technical merits. > I tend to use this locally in functions, where there are several > ways where a > code can fail and have somewhat common treatment but details are > different. > Think of trying to write a new file where the source of failures > are multiple > (can't write to directory because of permissions, not enough free > space in > the filesystem, missing directories of the path provided, etc). > > So I find that doing something like this is clear and elegant: [snip] That's actually a really good example case where I'd specifically argue against using exceptions for various reasons. If used, exceptions should be for truly exceptional situations that require recovery -- not as part of regular app logic. Most I/O failures are not exceptional .. they happen a lot and easily. Your example is, though, at least locally contained and doesn't get into some of the other type-based issues exceptions can introduce, hierarchical escalations, and other flaky behaviors. On most public projects I've worked on, exceptions are not allowed for various reasons. Exceptional failures can often be caught with precondition assertions. There are good grounds for keeping branching logic simple too. Focusing on a no-throw contract design ensures that if exceptions are used, they are localized and hidden within an implementation. Strong or basic exception-safety contract design can have their place if done carefully.. which you touched on some in your follow-up comment. > I don't know if it makes sense in a mandatory way, I never found > myself > needing this badly. It's useful if [almost] all classes are known > to need > some characteristic (like class name, or serializing) but I never > found it > necessary for all classes in the projects that I worked in. Asking about single object hierarchies was a bit of a loaded question to see if there are any purists/zealots in the audience. ;-) They usually lead to a convoluted design with horrible interaction patterns (in C++). Good comments, Manuel -- thanks for sharing them, likewise to Daniel on the follow-ups. I'll summarize/spell out some of this on the wiki and in the HACKING file as development continues at least for the issues that aren't decided case-by-case. Cheers! Sean |