Le 07/11/12 09:18, TONGARI a écrit :
2012/11/7 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>
Le 07/11/12 06:18, TONGARI a écrit :
2012/11/7 Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung@gmail.com>
Wouldn't this fit in Boost.TypeTraits, along side the other type traits
that introspect operators?
TypeTraits is also in my consideration, so I'm not against it. So would you suggest opening up a new Functional category in that?
Hmmm, well, maybe for documentation purposes, but I think that's the only
2012/11/6 Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung@gmail.com> place that Boost.TypeTraits has a notion of category...? I would think it might be sufficient to group it with the operator type traits in the documentation, though.
Well, though conceptually reasonable, but that'd seem exotic in all of
On Tue, Nov 6, 2012 at 7:14 AM, TONGARI <tongari95@gmail.com> wrote: the others named has_xxx...
Hi,
Boost.TypeTraits has other traits as is_, ... What about is_callable_with?
Hmmm, then I'd prefer a shorter "has_call" that'd fit in Operator Type Traits better. has_ is related to something a class can have, while is_ can be applied to a class or a function. But do you think member-function ptr fits in this context? e.g.
has_call<void(X::*)(), void()>::type // mpl::true_
I don't think this fill you initial can_be_called. Do you?
I still prefer a new place if possible that I could have more control on
it.
What kind of control do you want? To rule the doc style and include hierarchy, providing specific macros for compile/preprocess, for example. Could you give some examples? Otherwise I have to follow the convention of the parent lib...
Could you say what is wrong following the parent lib? Best, Vicente