Re: [boost] [function types] Formal Review begins today.

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

"Tobias Schwinger" <tschwinger_at_[hidden]> wrote in message
news:d8q4ch$dp7$1_at_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