[Xorp-hackers] Boost and Win32 update

[Bruce Simpson]

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