views:

159

answers:

4

I'm already experienced with C++ (C, OOP, the STL, et al.), and I'm looking to start delving into the Boost libraries. What are some common mishaps you've seen? Pitfalls you've been snagged by? Things you wish someone would have told you or pointed out?

+2  A: 

Getting carried away with the functional programming style using Boost::Lambda only to notice that the result is unreadable. Not that you should avoid Boost::Lambda altogether; only that it shouldn`t be blindly applied everywhere.

Laurynas Biveinis
+2  A: 

Using Boost.MPL

for any serious application w/o a full knowledge of what exactly you are doing. This goes for Boost.Spirit too. It would apply to Boost.StateChart, except you really only have to know that mpl::list<...> is magic that allows more than 1 thing (child state, transition, etc) so long as you are happy using the constructs StateChart provides.

MPL is HARD and most people who try to use it fail utterly because they can't wrap their mind around compile time programming.

KitsuneYMG
A: 

Do not use BOOST_STATIC_ASSERT

Use BOOST_MPL_ASSERT family instead. Specifically BOOST_MPL_ASSERT_MSG as it gives easy to see and read errors.

Ex.

template< typename T > struct my
{
    // ...
    BOOST_MPL_ASSERT_MSG(
          is_integral<T>::value
        , NON_INTEGRAL_TYPES_ARE_NOT_ALLOWED
        , (T)
        );
};
my<void*> test;

// In instantiation of `my<void*>':
//   instantiated from here
// conversion from `
//   mpl_::failed************(my<void*>::
//   NON_INTEGRAL_TYPES_ARE_NOT_ALLOWED::************)(void*)
//   ' to non-scalar type `mpl_::assert<false>' requested
KitsuneYMG
+1  A: 

Watch out for cyclical dependencies when using boost::shared_ptr. Otherwise you get memory leaks. If you need cyclic consider making one of the links a boost::weak_ptr instead.

Michael Anderson