On 03/06/2013 01:16 PM, Steven Watanabe wrote:

AMDG

On 03/06/2013 09:48 AM, Stefan Strasser wrote:

...

Hi,

I'm looking for a boost functionality to determine whether a given type has a member function of a given name (or name + signature). this seems to be possible using SFINAE, but all I can find is BOOST_MPL_HAS_XXX_TRAIT_DEF which only works for nested types, not functions. I could of course implement it myself using SFINAE but BOOST_MPL_HAS_XXX_TRAIT_DEF has a lot of compiler bug workarounds it seems, so I guess this will cause problems. Is there such a functionality in boost?

I want to use it to determine the defaults of a traits class, similar to C++11 pointer_traits::difference_type. But the determining factor for the default is a function in my case, not a type.

The macro you're looking for is BOOST_TTI_HAS_MEMBER_FUNCTION. However, I don't think this has been released yet. It's in the trunk, but I don't see it in the release branch.

I am fairly close to finishing my work with TTI, but it is not yet in release.

On Thu, Mar 7, 2013 at 5:44 AM, Stefan Strasser wrote:

Am 07.03.2013 04:58, schrieb Edward Diener:

...

The macro you're looking for is BOOST_TTI_HAS_MEMBER_FUNCTION.

...

However, I don't think this has been released yet. It's in the trunk, but I don't see it in the release branch.

I am fairly close to finishing my work with TTI, but it is not yet in release.

Thanks, it works as advertised.

However, it requires you to know the exact signature of the member function. I'm trying to check whether it is ok to call c.f(x), which would be satisfied by each of the following 3 signatures (and more):

struct C{ void f(X); void f(X &); void f(X const &); ... };

is there a way to check for that, or do I have to check for all (likely) signatures? there is a way to check whether a function call is ok without knowing the signature using c++11:

http://stackoverflow.com/**questions/11273184/sfinae-** member-function-existence-**test-issuehttp://stackoverflow.com/questions/11273184/sfinae-member-function-existence...

I'm not sure if you can do the same in c++03.

This, and the referenced link in Russian, might help https://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thre... - Jeff

On 3/7/2013 3:53 PM, Stefan Strasser wrote:

Am 07.03.2013 20:12, schrieb Jeffrey Lee Hellrung, Jr.:

...

The macro you're looking for is BOOST_TTI_HAS_MEMBER_FUNCTION.

...

it requires you to know the exact signature of the member function. I'm trying to check whether it is ok to call c.f(x), which would be satisfied by each of the following 3 signatures (and more):

struct C{ void f(X); void f(X &); void f(X const &); ... };

is there a way to check for that, or do I have to check for all (likely) signatures?

...

https://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thre...

Thanks! it doesn't work for me, because it uses sizeof(void) if the function call is possible.

However, it is enough to determine whether a member of a given name exists, without checking the signature. an implementation of has_member is here: http://www.rsdn.ru/forum/cpp/2720363

Edward, can this be added to TTI, for example as BOOST_TTI_HAS_MEMBER? not only does this implementation look portable to me, but boost already uses it internally: http://www.boost.org/doc/libs/1_47_0/boost/thread/locks.hpp

I agree that having a TTI metafunction to check for a member function by name with any signature might be helpful. But even in your situation above, just knowing that some 'f' exists within 'C' does not tell you it is callable by passing 'X', 'X &', or 'X const &'. Nonetheless I will look into the links presented by you and Jeffrey Hellrung, especially the last above. First I need to finish my work and get TTI into Boost. I am very near the end of making coding changes as suggested by the review and largely have some more documentation and tests on some compilers ( Intel and Sun ) to do. Gcc, clang, and VC++ are working fine so far with TTI and an occasional workaround ( VC++ and some slightly older versions of gcc ). My major concern is how much time I should spend on trying to invent workarounds for compilers whose implementations of SFINAE are insufficient in certain situations need by TTI. But I think its most important just getting TTI into Boost, documenting what does not work on certain less SFINAE deficient compilers, and then look for possible workarounds later. The vast majority of C++ programmers probably use gcc, VC++, or clang nowadays. I have also delayed much too long in getting TTI fully ready for Boost and into the release branch and just need to get it done.