Boost logo

Boost :

From: Joel de Guzman (joel_at_[hidden])
Date: 2004-02-19 10:46:48


Joel de Guzman wrote:

> Anyway... I'm trying to get into the code and docs whenever I could
> steal some time. So, my comments may be fragmented. Pardon me.
>

Here's another:

    BOOST_FCPP_DEFER_DEFINITIONS
    Setting this flag makes all the functoids get declared as "extern"
    variables, but not defined. You then need to link against a separate
    object file with the definitions. Use this when you are using FC++
    in mutiple translation units, and you do not want each TU to have its
    own copy of all the functoids.

Why is this needed? Why not just make them const and forget about
linker errors with multiple translation units?

I see code such as:

     namespace impl {
     struct XPlus {
        template <class T, class U> struct sig;

        template <class T>
        struct sig<T,T> : public fun_type<T> {};

        template <class T>
        T operator()( const T& x, const T& y ) const {
           return std::plus<T>()( x, y );
        }
     };
     }
     typedef full2<impl::XPlus> plus_type;
     /** open namespace...**/
     plus_type plus;
     /** close namespace...**/

which, when BOOST_FCPP_DEFER_DEFINITIONS is defined:

     plus_type plus;

IMO, this is not necessary. You can simply write:

     plus_type const plus;

and get rid of linker errors on multiple translation units.

<<BTW, mutiple is a typo>>

Oh, and BTW, there's a significant disadvantage of FC++'s definition
of plus compared to LL (and Phoenix). I notice that there is no
return type deduction and both arguments are of the same type.
Hence, it's not very friendly to C++'s rich set of types (numeric
and others). IMO,

     T operator()( const T& x, const T& y ) const

is simplistic and wrong. It should be:

     result_of_plus<X, Y>::type
     operator()(const X& x, const Y& y) const

Cheers,

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk