Prev: some quirks of Koenig lookup rule?
Next: C++ language: Cloneable classes
From: Roman.Perepelitsa on 4 May 2008 22:09
On 1 May, 21:43, mcostalba <mcosta...(a)gmail.com> wrote:
> I have to detect if a functor type Fun has a given signature Sig, i.e.
> if Fun::operator() has a signature Sig

Take a look at is_call_possible metafunction, which was discussed
in this group before
(http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/
thread/4f7c7a96f9afbe44/e5fbc9305539f699#e5fbc9305539f699).
It seems to do what you want.

HTH,
Roman Perepelitsa.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Roman.Perepelitsa on 5 May 2008 23:21
On 6 May, 08:57, mcostalba <mcosta...(a)gmail.com> wrote:
> Thanks Roman for your link.
>
> Actually there are some good ideas in that implementation and I will
> try to borrow a few of them...
>
> Unfortunatly it does not fit the bill 100%, indeed:
>
> - Implicit argument type conversion should be avoided in my context,
> due to some ambiguites that can arise when there is more then one
> candidate among the overload set. So signature matching would be ok to
> be strict.

Alexandre Courpron modified is_call_possible to create
is_exact_call_possible. You can find implementation here:
http://groups.google.co.uk/group/comp.lang.c++.moderated/browse_thread/thread/bd047be2c70b31f8/a56a91737e3f8c7c#a56a91737e3f8c7c

> - It seems you have to add a specialization for each argument arity,
> in my implementation I would try to avoid this.

Yes, you can use variadic templates (if your compiler supports then)
or boost::preprocessor to automate generation of specializations.

> Anyhow, for interested people, many of the ideas, included overloading
> comma operator
>
> template <typename type, typename U>
> U& operator,(U&, void_exp_result<type>);
>
> to workaround void return types are also exposed in "Detecting the
> Arity of Function Objects"
>
> under the link
>
> http://boost-sandbox.sourceforge.net/libs/proto/doc/html/boost_proto/...
>
> where an equivalent solution is documented by Eric Nibler in his
> boost::proto library.

Nice one, I haven't seen it. It uses clever trick with conversion to
a function pointer.

IMHO, it would be nice if someone added is_call_possible and
is_exact_call_possible to boost.

Roman Perepelitsa.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Roman.Perepelitsa on 7 May 2008 02:04
On 6 May, 20:47, mcostalba <mcosta...(a)gmail.com> wrote:
> Anyhow here is my much simpler solution...so simple that is probably
> broken in some way, but I cannot find where:
> [cut]
> BTW it seems to work.

Seems like it does not work for functions (always returns false for
them)
and it's not that smart with regard to const objects and const
methods.

Here is how original is_call_possible works:

struct foo {
void operator()();
};
struct bar {
void operator()() const;
};

assert(is_call_possible<foo, void()>::value);
assert(!is_call_possible<const foo, void()>::value);
assert(is_call_possible<bar, void()>::value);
assert(is_call_possible<const bar, void()>::value);

But maybe you don't need this functionality...

Roman Perepelitsa.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 | 
Pages: 1
Prev: some quirks of Koenig lookup rule?
Next: C++ language: Cloneable classes