[Xorp-hackers] Boost use

[Bruce Simpson]

On 04/23/10 18:10, Mark Handley wrote:
> Regarding boost, I think how we left it on the phone call last night
> was that Bruce would write a short note saying what he believes boost
> gives us, and why it's the right thing for Xorp.  So I'd like to wait
> for that before we make a decision.
>    

I have set out many of the benefits Boost offers for XORP, in previous 
postings to this mailing list over the last 6-9 months, so I'll be as 
concise here as possible:

     * Boost is widely used by C++ projects of comparable size, and 
offer a thoroughly peer-reviewed alternative to some of what we have in 
libxorp.
     Innovations from Boost itself are becoming part of the C++0x 
language specification. It is technically very strong.
     I think it's unreasonable to expect folk to reinvent wheels which 
exist out there, and pretty much essential to stuff they're now doing; 
Boost can be considered part of the C++ state-of-the-art now, as such, 
it has project currency.

     * The Boost shared_ptr/weak_ptr idioms, are a clean solution,
       to very specific problems we see in async systems such as XORP.

     That is, where we need to cleanly separate the reference of a C++ 
object from its storage lifecycle.
     Abusing ref_ptr further is syntactically not clear at all, and I 
strongly feel we should be using Boost instead. I am opposed to further 
use of ref_ptr (with &) because the intent of it is overloaded and 
confusing, to developers who are not intimately familiar with ref_ptr.
     Far more C++ developers out there are likely to be familiar with 
Boost than libxorp.

     * The Boost.Interprocess library will enable using shared memory 
efficiently for fast-path IPC in future, something which currently slows 
down XORP *significantly* compared to other BGP designs;
     14m vs 1m for full routing table convergence.
     As I've said to Mark and others before, there are shared-memory 
versions of the list, map and other STL containers, which drop straight 
in to shared memory.
     [FWIW Ravi at XORP, Inc. was proposing doing much the same thing, 
but hand-rolled]

     * The Boost multi-index container has the potential to make large 
indexed structures, such as the RIB tables, and routing tables internal 
to most protocols, more efficient in time and space.
     [I would have used it for OLSR, but ran out of time]

     * Thrift requires Boost anyway. Despite forwarding the full 
reasoning behind my recommendation of Thrift to XORP, Inc., to replace 
much of XRL and fix the problems with it, I have still not had an 
opinion from Mark either way.

     * There are numerous other Boost refactorings possible. I did not 
finish them because life support went offline.

     * Finally: We have already had others on xorp-hackers@ come 
forward, to say that work they've been doing on XORP requires Boost. Off 
the top of my head, Luca Belforte, for marshaling compound data 
structures out of routing processes.

...

I don't buy the argument that '1 more external dependency is bad'. The 
Boost libraries as currently used, are mostly used as header files. 
However beyond regex, we don't use the runtime libraries. The use of the 
libraries, can easily be switched back over to pcre or platform regex 
(at a minimum). At the moment boost regex is just shimmed in.

My view is that this argument is rooted more in unfamiliarity with 
systems-level C++, and how to optimize it effectively, than it actually 
posing a real problem.

Boost is generally available as a binary package for the platforms 
tested by the Tinderbox.
The Boost headers don't have any cross-compilation implications, apart 
from what someone cross-compiling XORP would need to do for an embedded 
target anyway, i.e. populate the staging area.

...

I'd far rather see a release made than not, if only to regain confidence 
with an otherwise unheard-from user base.
If the use of libboost_regex is the issue, that's a point I'm willing to 
compromise on for 1.7.

But I'm not willing to do the work of backing anything out, as I firmly 
believe it's in XORP's future interests for the reasons given above.
This is view borne in experience of being the only active developer on 
the open SVN branch for well over 6 months.

For future directions, Boost is a place we very much have to visit.
It offers concrete benefits for actually improving the performance, and 
code quality, of a large C++ system such as XORP.

regards
BMS