"Tobias Schwinger" <tschwinger@neoscientists.org> wrote in message news:d8q4ch$dp7$1@sea.gmane.org...
Hi Andy,
thank you for your review !
No problem. Sorry I'm not more of an expert on this :-) [snip]
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).
Ok.
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 relation.
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 make 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 ;-) OTOH 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 know.
Another, more general example in this direction has been recently added to the library:
- interpreter.hpp [ http://tinyurl.com/bu5vn ]
- interpreter_example.cpp [ http://tinyurl.com/8ryt3 ]
Whoa ... This is too complicated. Can you not just isolate the function_types part? regards Andy Little