Re: [Boost-users] Using MPL for conditional compilation

----- Mensaje original ----- De: "Alan M. Carroll" Fecha: Martes, Agosto 23, 2005 8:52 pm Asunto: [Boost-users] Using MPL for conditional compilation

I am building a templated container class C. Normally it acts just like an stl::map. However, if the mapped_type of a container C is also a specialization of C (value1 = C) then the key types of the containers are merged in to a tuple yielding a container that acts like C< , value2 >.

Obviously the MPL has been quite useful for this but I'm not clear on the best style / usage for a particular effect.

Inside C, the insert method has two parts, the part that's the same regardless of whether C is merged container and the part that isn't. How should I arrange to have different code executed depending on whether C is a merged container or not? I have a class static const bool IS_OUTER that is set to true for merged containers and false otherwise.

[...]

5) Use traits classes keyed by IS_OUTER to provide the differing implementations.

If the *syntactic* differences between both flavors can be reduced to only different definitions for key_type and mapped_type, I'd use something like your option 5) : template class your_container { static bool const IS_OUTER=...; typedef typename boost::mpl::if_c< IS_OUTER, struct outer_tag, struct inner_tag

::type flavor;

public: typedef typename boost::mpl::if_c< IS_OUTER, boost::tuple, Key

::type key_type;

typedef typename boost::mpl::if_c< IS_OUTER, typename Value::mapped_type, Value

::type mapped_type;

// example of memfun with alternate implementations const_iterator find(const key_type& k)const { return find_impl(k,flavor()); } // shared menfuns do not need any special machinery private: // alternate implementations of find const_iterator find_impl(const key_type& k,outer_tag)const { ... } const_iterator find_impl(const key_type& k,inner_tag)const { ... } }; With this scaffolding set up, it is guaranteed that only the appropriate *_impl memfuns are compiled in each case, and the runtime penalty should be optimized away to zero. OTOH, if the number of memfuns with alternate implementations is very large with respect to shared memfuns, you might want to go for fully separated classes. HTH, Joaquín M López Muñoz Telefónica, Investigaión y Desarrollo