Re: [Parameter] is there an interest in this template parameter expresion
I am really sorry, I sent my previous mail as answer to the Proto review. I
wanted to send it a request for interest 
.
---------------------------
Vicente Juan Botet Escriba
----- Original Message -----
From: "vicente.botet" <vicente.botet <at> wanadoo.fr>
To: <boost <at> lists.boost.org>
Sent: Sunday, March 02, 2008 8:39 PM
Subject: Re: [boost] [Parameter] is there an interest in this
templateparameter expresion
>
> Hello,
> First of all, sorry for the long post.
>
> I'm doing a Locally Unique Identifier generator library.
> The DSL grammar is quite complex (see below), so the use of optional
> parameters seams unavoidable. I have started to use the Boost.Parameter
> Library as the Boost.Flyweight does.
>
> For the recover node which can takes two optional parameters recovery_when
> and recovery_how, this results in:
>
> <code>
> template <typename Arg1=parameter::void_, typename Arg2=parameter::void_>
> struct recover : on_release_marker {
> private:
> typedef parameter::parameters<
> parameter::optional<
> parameter::deduced<recovery_when<> >,
> is_recovery_when<boost::mpl::_>
> >,
> parameter::optional<
> parameter::deduced<recovery_how<> >,
> is_recovery_how<boost::mpl::_>
> >
> > signature;
> typedef typename signature::bind<Arg1,Arg2>::type args;
> public:
> typedef typename parameter::binding<
> args,recovery_when<>,dsl::immediate<>
> >::type recovery_when;
>
> typedef typename parameter::binding<
> args,recovery_how<>,dsl::fifo<>
> >::type recovery_how;
> private:
> typedef parameter::parameters<
> parameter::optional<
> parameter::deduced<
> detail::unmatched_arg
> >,
> mpl::not_<
> mpl::or_<
> is_recovery_when<boost::mpl::_>,
> is_recovery_how<boost::mpl::_>
> >
> >
> >
> > unmatched_signature;
> typedef typename unmatched_signature::bind<
> Arg1,Arg2
> >::type unmatched_args;
> typedef typename parameter::binding<
> unmatched_args,detail::unmatched_arg,
> detail::unmatched_arg
> >::type unmatched_arg_detected;
> /* You have passed a type in the specification of a recover type that
> * could not be interpreted as a valid argument.
> */
> BOOST_STATIC_ASSERT((
> is_same<unmatched_arg_detected,detail::unmatched_arg>::value));
> };
> </code>
> There is a lot of syntactic boilerplate in the recover class which will be
> repeated for each one of the & nodes on the DSL grammar.
> I have defined a expr class which hides all this repetitive stuff. The
> recover
> class can then be defined as:
> <code>
> template <typename Arg1=parameter::void_, typename Arg2=parameter::void_>
> struct recover : on_release_marker,
> boost::dsl::expr<recover<>, mpl::vector<
> boost::dsl::optional<recovery_when<>, is_recovery_when<mpl::_>,
> immediate<> >,
> boost::dsl::optional<recovery_how<>, is_recovery_how<mpl::_>, fifo<>
> >
> >, mpl::vector<Arg1, Arg2> >
> {};
> </code>
> I would like to know if there is an interest in such a expression, and if
> it
> is the case if this could be added to the parameters library.
> As the issue here is to transform an DSL expression to another DSL I
> was wondering if the Boost.Proto which is now been review could help
> to do this kind of transformations.
> The expr.hpp file is attached. The class in not yet able to manage with a
> variable number of parameters (up to 3). I would like to know if there
> is a way to avoid preprocessor programming.
>
> I have faced some problems when trying to avoid preprocessor programming.
> The first one was doing the mapping from a vector of args to the
> parameter::parameters::bind.
>
> <code>
> template <typename Signature, typename Args>
> struct args;
>
> template <typename Signature, typename Arg0>
> struct args<Signature, mpl::vector<Arg0> > {
> typedef typename Signature::template bind<Arg0>::type type;
> };
>
> template <typename Signature, typename Arg0, typename Arg1>
> struct args<Signature, mpl::vector<Arg0, Arg1> > {
> typedef typename Signature::template bind<Arg0, Arg1>::type type;
> };
> </code>
>
> I don't know if there is a better way to do that, any hint is welcome.
>
> Any way I think that it will be easier to adapt the
> parameter::parameters::bind template to take a mpl sequence.
> See the definition of bind in boost/parameter/parameters.hpp
>
> <code>
> template <
> BOOST_PP_ENUM_BINARY_PARAMS(
> BOOST_PARAMETER_MAX_ARITY, class A, = void_ BOOST_PP_INTERCEPT
> )
> >
> struct bind
> {
> typedef typename aux::make_arg_list<
> typename BOOST_PARAMETER_build_arg_list(
> BOOST_PARAMETER_MAX_ARITY, aux::make_items, PS, A
> )::type
> , deduced_list
> , aux::tag_template_keyword_arg
> >::type result;
>
> typedef typename mpl::first<result>::type type;
> };
> </code>
>
> The second problem concern the mapping from a vector to a
> unmatched_signature, which is reduced to transform a mpl::vector to a
> mpl::or_
>
> <code>
> template <typename Param0,typename Param1>
> struct unmatched_signature<mpl::vector<Param0, Param1> >{
> typedef parameter::parameters<
> parameter::optional<
> parameter::deduced<
> detail::unmatched_arg
> >,
> mpl::not_<
> mpl::or_<
> typename Param0::pred,
> typename Param1::pred
> >
> >
> >
> > type;
> };
> </code>
>
> Is there something in boost that can simplify this mapping?
>
>
> Best Regards
>
> _______________________________________________
> Vicente Juan Botet Escriba
> _______________________________________________
>
> LUID DSL grammar
> _______________
> luidg(
> numeric_type(uint_type) ?
> & on_overflow(
> throw_on_error
> | errno_on_error
> | ignore_error
> | user_error(user_function)
> ) ?
> & on_release(
> discard
> | recover(
> recover_when?
> & recover_how?
> )
> ) ?
> & scope(
> mono_threaded
> | multi_threaded(locking? )
> | multi_process(locking? )
> ) ?
> & persistecy(
> process(
> void_pointer_type?
> & allocator_type?
> )
> | kernel(
> void_pointer_type?
> & allocator_type?
> & segment_manager_type?
> )
> | filesystem(
> void_pointer_type?
> & allocator_type?
> & segment_manager_type?
> )
> ) ?
> & optimization (
> speed
> | space
> ) ?
> & coherency (
> ensure(bitset | set | ...)?
> | ignore
> ) ?
> )
>
> recover_when (
> immediate
> | freeze
> | delay(time_traits)
> )
>
> recover_how (
> fifo
> | undefined
> )
>
> locking(
> internally(locking_traits)
> | externally(mutex_type)
> )
>
> locking_traits (
> thread_locking_traits
> | process_locking_traits
> | thread_recursive_locking_traits
> | process_recursive_locking_traits
> | ...
> )
>
> time_traits (
> posix_time_traits
> | ...
>
--------------------------------------------------------------------------------
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RSS Feed