Bruce Simpson wrote: > Hi all, > > As of today I've done refactorings for boost::noncopyable, > boost::polymorphic_cast and boost::polymorphic_downcast on the tree. >
A bit more about these things, and what they do. boost::noncopyable is a mixin class which can replace any occurrence of making the assignment operator and copy constructor private/protected for a class. It does so by supplying a mixin class which is used as a base class. Because inheritance is used to do this, without 'virtual', it should make absolutely no difference to performance or binary footprint. The reason for using this inline mixin is to make it absolutely clear, in source, that instances of the class are not copyable; and this should make for more readable code. boost::polymorphic_downcast<T>() is a function template which replaces static_cast<T>. It is used in situations where we are downcasting a pointer to a class to one of its derived classes, *without* runtime checking. What it does is quite simply to assert() on the equivalent dynamic_cast<T>, before returning the result of static_cast<T>. This lets us catch inheritance problems in debug builds, because static_cast<T> is never checked against the inheritance graph for a class at runtime. It is not suitable for use in situations where classes have overridden virtual functions; in that case, we need to use a dynamic_cast<T>. boost::polymorphic_cast<T>() is a function template which replaces the use of dynamic_cast<T> where we expect a downcast or crosscast to always succeed. If the cast fails, a std::bad_cast exception will be raised. Normally, this exception is only raised by the C++ runtime library when we perform a dynamic_cast<T> where T is a *reference*, not a pointer. The main benefit of the Boost cast is that it makes the intention clear in the source, and it also allows us to catch the exception at runtime for gracefully backing out of the operation where the cast failed. In XORP, this pattern is typically seen where we are performing a dynamic_cast<T> on an object pointer, and then XLOG_ASSERT() on the result. It is *not* suitable in the situation where dynamic_cast<T> is used to check if a pointed-to object supports a given interface or not, or where we actually depend on its return value. There are a number of places in the code where we do this, and this is a different subject. The only other change to date I've made in my private Boost branch is to replace the use of pcreposix for regular expressions, with Boost's C regex API. It has a C++ API, although when I quickly hacked in its use, it didn't function as expected, so I reverted to the C API. As code in this branch has started to use Boost concepts and utility headers, it makes sense to use Boost's regex library. It does mean we need one less third party library to ship the system with. This stuff is all in my own Hg branch for the moment, when it's time to start rolling 1.7, I'll probably export these as SVN feature branches on SF. thanks, BMS _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
