Boost logo

Boost :

From: Andy Little (andy_at_[hidden])
Date: 2005-06-17 06:38:16

"Tobias Schwinger" <tschwinger_at_[hidden]> wrote in message
> Hi Andy,
> thank you for your review !

No problem. Sorry I'm not more of an expert on this :-)


> Looking closer at the type synthesis part we would end up with lots of
> functions
> that do exactly the same thing. E.g:
> function_pointer<Seq>
> defaultcall_function_pointer<Seq>
> non_variadic_function_pointer<Seq>
> non_variadic_defaultcall_function_pointer<Seq>

> or we would only use the "most concrete" (the one at the bottom of the list --
> I
> guess its name is already enough reason not to seriously consider this) or we
> would drop the symmetry of sythesis and decomposition (imposing a huge ammount
> of irregularity on the user).


>> OTOH why not do it the other way round eg
>> template<typename F, typename Tag = any_function>
>> struct is_function_type;
> I found it appealing to have the tag next to ("extend") the identifier.

I prefer the 'policy' at the end ... whatever.

>> eg giving is_function_type<F> for what I guess is the most usual case.
> Don't think so. I don't see a reasonable default, here.
>> I know this overlaps type_traits, but therefore is this any_function
>> necessary?
> In fact, this particular case doesn't (at least not exactly), but it can be
> modeled with TypeTraits, if this is what you mean. It will look somewhat like
> this (untested freehand code):
> mpl::or_<
> is_function<
> typename remove_reference<typename remove_pointer<T>::type>::type
> >
> , is_member_function_pointer<T> >

OK...something else to mention in the documentation IMO. Would be nice to show

>> Does providing non functions-types to eg function_type_arity<F> give a
>> compile
>> time assertion? Cos I think it should!
> It gives you a compile error at the point you try to access '::value'
> ("function_type_arity<Blah blah blah> does not have a member named value").
> 'BOOST_STATIC_ASSERT' or 'BOOST_MPL_ASSERT*' are not used for this, because
> this
> would trigger an error inside the library, instead of where the actual problem
> in client code is.

Ok .. hmmm.... I reckon compiler error messages are output upside down. They
it easy for the libarray author, rather than the user.
A switch to print error messages in reverse order would be nice :-)

>> I would really like an accessible example right at the start.
>> What is this library useful for? The example source files seem to have little
>> regard for anyone reading them.
> You're right - it's missing.

Yes and something regarding decomposing a function and then doing the reverse
...synthesising it (if thats the correct use of 'synthesis') from the
decomposed bits.

>> The closure example looks interesting
>> (though I'm not sure what a closure is) but
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> There is a brief introduction in the header, if it doesn't work for you, try
> Wikipedia or alike.

Ok I guess it would make sense if I found a use for it ;-)


I have been mucking about with the library, because I'm sure there are uses.(I
may be reinventing the wheel. If so sorry); In attached file( for no concrete
purpose ) I tried to 'normalise' functions of arbitrary args into a function
taking a tuple of args.
Though I dont know much about Functional Programming this feels like the type
of thing that might be useful.. quiz the arguments to see if their functions
with a tuple of args etc, though quite how you would proceed with that I dont

> Another, more general example in this direction has been recently added to the
> library:
> - interpreter.hpp
> [ ]
> - interpreter_example.cpp
> [ ]

Whoa ... This is too complicated. Can you not just isolate the function_types

Andy Little

Boost list run by bdawes at, gregod at, cpdaniel at, john at