всем доброго времени суток.

к примеру, имеем такой класс:


далее, есть некоторый магический макрос который используется так:


цель - развернуть этот макрос и в нечто подобное static_assert(has_member<&type1::m1>::value);

т.е. нужна проверка на предмет того, что юзер перечислил правильные имена методов.

для этой цели подходит SFINAE. но каждый такой шаблон нужно генерировать для проверки только одного метода. а это не удобно, и удваивает вероятность ошибки.

какие варианты?

Добавлено @ 21:44
смотрю на boost.enable_if. вроде то, но и не могу понять как его использовать для конкретной задачи...

Это сообщение отредактировал(а) boostcoder - 22.7.2011, 21:50

имелся ввиду абстрактный класс ? 

да. интерфейс.

a зачем такая акцептация внимания на классе как на интерфейсе ?  так еще с кучей опечаток.. 
по сути, как я понял, Вам нужна проверка на наличие метода для любого произвольного метода, без принуждения задавать для каждого имени индивидуальный "тестер".. но тут опять не понятно, Вам важно наличие метода с определенным именем, или ж еще и с определенной  сигнатурой ? 

а что не так? не понял...


ну извините. время позднее. моцг спать хочет.


не уверен что правильно понял.


с определенным именем.

=0 может быть только у виртуальных методов, а у вас обычные, да и наследования нет, но это можно списать на опечатки, 
но вводит в заблуждение то, что без этих "=0" писанины меньше, а пример обхватывал большую область.. 
т.е. непонятно зачем в пример приведен абстрактный, а не простой класс 
хотя уже понятно :

так и есть.

а по поводу топика, есть предложения?

ну классический вариант это создание двух макросов :
DEFINE_MEMFN_DETECTOR и DETECT_MEMFN
я так понимаю Вас этот вариант не устраивает ?

Добавлено через 1 минуту и 21 секунду
тогда моими другими предложениями будет пересмотреть архитектуру задумки 

нет.
цель - уменьшить вероятность ошибки при указании пользователем имен методов. если использовать еще и генерирующий SFINAE-шаблон макрос, то вероятность удвоится.

Добавлено через 2 минуты и 45 секунд

вот и я думаю, плюнуть на все попытки реализовать introspection+reflection языковыми средствами и макросами, и написать плагин для gcc+mingw, у которого возможностей и информации гораздо больше чем у меня при использовании макросов и шаблонов...

без отражения метода на что нибудь,  его имя нельзя применить к любому классу, а значит полюбому придется делать "лишний" генератор..

Добавлено через 2 минуты и 5 секунд

давно на это намекаю 


Это сообщение отредактировал(а) mes - 23.7.2011, 14:10

я это тоже понимаю. но была надежда на то, что возможно я не все понимаю 


ну я только недавно нашел документацию по реализации плагинов для gcc+mingw... надо пробовать..

другой вариант .. ммм.. как бы это назвать.. это построение именного интерфейса.. 
уже где то приводился пример.. чуть позже напишу поподробней.. 

ок. спасибо.

вот условный пример : http://liveworkspace.org/code/8bbe21936af6...38a69bca6078890