Статическая проверка статического интерфейса в статическом c++

Как статически проверить что у наследника есть нужная функция?

Тебе нужен виртуальный метод. Если нужно гарантировать его наличие у наследника - абстрактный виртуальный метод.

std::string (Heir::* tmp)() = 

Лишнее.

Тебе нужен виртуальный метод.

Нет.

http://en.wikipedia.org/wiki/Curiously_recurring_template_pattern#Static_poly...

http://stackoverflow.com/q/257288

Как-то так?

#include <type_traits>

template <typename Heir>
class SToString {
public:
    std::string toString() {
        static_assert(std::is_member_function_pointer<decltype(&Heir::toStringImpl)>::value, "class derived from SToString should implement toStringImpl()");
        return static_cast<Heir*>(this)->toStringImpl();
    }
};

class Foo : public SToString<Foo> {
public:
    std::string toStringImpl() {
        return "Foo";
    }
};

В отсутствие реализации toStringImpl будет срабатывать кшна не assert, а ошибка no member named 'toStringImpl', но ошибка укажет на строку с assert где будет виден текст сообщения. Лишних варнингов также нет.

Ничего вообще не проверяет, даже если конструктор вызвать.

http://ideone.com/Z5UmQZ

Конструктор тут не при чём - чтобы увидеть ошибку нужно звать toString.

В ОП посте достаточно конструктора.

Посмотри здесь.

Странно, но не работает.

#include <iostream>
#include <array>
#include <type_traits>

template <typename T>
constexpr bool has_to_string(decltype(&T::toStringImpl)) {
	return true;
}

template <typename T>
constexpr bool has_to_string(...) {
	return false;
}

template <typename Heir>
class SToString {
public:
	SToString () {
		std::string (Heir::* tmp)() = &Heir::toStringImpl;
	}

	std::string toString() {
		return static_cast<Heir*>(this)->toStringImpl();
	}
	
	static_assert(has_to_string<Heir>(0), ""); // всегда срабатывает, даже когда функция есть
};


class Foo : public SToString<Foo> {
public:
	std::string toStringImpl() {
		return "Foo";
	}
	static void foo() {}
};

static_assert(has_to_string<Foo>(0), ""); // работает как надо

Что значит достаточно? У моего варианта требований меньше - не нужен ничего пихать в конструктор, в то же время static_cast защищён статической проверкой, но только если он реально используется.

Что значит достаточно?

Значить достаточно вызвать конструктор, что бы проверить правильно ли написан класс-наследник. Если проверку убрать, то всегда, даже в самых тривиальных случаях, где-нибудь в тестах, нужно будет отдельно вызывать все функции нужные для статических интерфейсов, просто что бы проверить что нет опечаток.

И static_assert там не нужен. Можно его оставить, только ради аннотации: http://ideone.com/TkwuPi

Што? Ты либо используешь (в тех же тестах) toString, тогда у тебя есть статическая проверка. Либо не используешь никак - тогда тебе и проверка не нужна.

Статическая проверка статического интерфейса в статическом c++ (комментарий)

Вообщем-то это норм. Но оно не работает, если проверка находится до объявления проверяемого класса, при этом еще ошибки генерит как на не пройденную проверку, в сыром виде гиморно использовать.

Думаю, на основе этого, обмазывать и интерфейс и реализацию препроцессором, оно хоть и коряво, но работает.

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

#include <type_traits>
template <typename T> struct A { A() { static_assert(std::is_member_function_pointer<decltype(&T::g)>::value, "..."); } };
struct B : A<B> { int g () { return 42; } };
template struct A<B>;

man explicit instantiation.

Точно, полущ для костыляторства на препроцессоре.

Хотя, почти ничем не отличается от вызова конструктора (но ворнингов таки нет). static_assert там не нужен, без него тоже работает.

Ещё extern template struct A<B>, чтобы в бинарник лишнего не писал.

А вот тут уже и макросы не помогут.

template <typename T>
class Foo : public SToString<Foo> {
public:
	std::string toStringImpl() {
		return "Foo";
	}
};

template class SToString<Foo< ??? >>; // ???

???

Любой T удовлетворяющий соответствующему концепту (void в простейшем случае). И тогда уже без extern. Ну и class Foo : public SToString<Foo<T>>. Но это при условии, что все возможные специализации одинаково содержат метод или нет, иначе можно проверить SToString<Foo<A>> при инстанциации, но иметь специализацию SToString<Foo<B>> без метода, так что ошибка (компиляции) возникнет только при инстанцировании SToString<Foo<B>> (если его тоже явно не инстанцировать вызвав тем самым проверку).

Нет

Да. просто ты пытаешься решить задачу через жопу.

Угу, оставил костыль из ОП-поста и добавляю инстанциации по вкусу.

Использовать C++

Выбирать простые, но не оптимальные решения.

/0

Использовать C++
Выбирать простые, но не оптимальные решения.

man преждевременная оптимизация