Сделать шаблон приемлемым для класса/класса?

Question

У меня есть шаблонный метод, который предназначен для работы с определенным набором классов. Поскольку у меня нет реальной потребности в полиморфизме во время выполнения, я решил не использовать указатели на родительский класс, но, скорее, у меня будет компилятор для всех.

Я хочу либо ограничить тип, который может быть передан шаблону, либо сделать GCC проблемными ошибками при передаче неправильного типа.

Возможно ли это?

Answer 1

Да. Это возможно с использованием нескольких различных методов в зависимости от конкретных потребностей дня. Там есть boost :: enable_if. Там MPL и static_assert ... (используйте BOOST_STATIC_ASSERT, если вы не используете компилятор C++ 0x). Есть Boost.Concepts.

Да. Возможно.

Answer 2

С другой стороны, вы также НЕ можете использовать шаблон.

Предположим, вы хотите, чтобы метод работал только на Car и Dog. Очевидно, что эти два абсолютно не связаны ... но они все еще могут двигаться.

// move.h 
#include <boost/variant.hpp> 

class Car; 
class Dog; 

typedef boost::variant<Car*,Dog*> move_type; 

void move(move_type m); 


// move.cpp 
#include <boost/apply_visitor.hpp> 

#include "car.h" 
#include "dog.h" 
#include "move.h" 

struct Mover: boost::static_visitor<> 
{ 
    void operator()(Car* c) const { c->advance(); } 
    void operator()(Dog* d) const { d->run(); } 
}; 

void move(move_type m) 
{ 
    boost::apply_visitor(Mover(), m); 
} 

И это даже лучше, чем типичный шаблон, потому что реализация находится в исходном файле :)

Answer 3

Вы можете сделать что-то вроде того, что сказал Матье, выписывать отдельные функции для каждого типа вы поддерживаете (его могут по-прежнему вызывать функцию шаблона в бэкэнд) или использовать динамический полиморфизм и наследование. Это должны быть только те варианты, которые вы должны учитывать, чтобы делать то, что хотите.

Однако вопрос, который вы задаете, заставляет меня поверить, что это неправильное понимание шаблонов и статического полиморфизма. Шаблон функции/класса налагает ограничение на типы, с которыми он может работать, посредством генерируемого фактического кода. Открытый интерфейс, который используется в таких функциях/классах, определяет ограничения на типы, которые могут быть приняты. Нет необходимости излишне налагать дополнительные ограничения на это. Почему вы хотите ограничить типы, которые шаблон типа/функции может поддерживать больше, чем уже установленные ограничения?

Предположим, вы пишете шаблон функции, который может работать только с типами, реализующими открытый интерфейс, который состоит из объекта доступа к жизни, функции уничтожения и функции питания (в основном, любого живого организма). Это ограничение, которое оно накладывает: вам не нужно ограничивать гибкость, уменьшая количество типов, которые будут работать с шаблоном функции, выходящим за рамки этого, или определите какие-либо конкретные типы организмов, которые будут работать таким образом. Шаблон уже требует, чтобы этот интерфейс живого организма был реализован.