Динамическое связывание в C++

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

typedef size_t (*CommonMethodPointerType)(const unsigned char *);
std::map<std::string, CommonMethodPointerType> functionMapping;

size_t myFunc(const std::string& functionName, const unsigned char * argument) {
    std::map<std::string, CommonMethodPointerType>::iterator functionPtrIterator
        = functionMapping.find(functionName);
    if (FunctionPtrIterator == functionMapping.end())
        return ERROR_CODE;
    return (*functionPtrIterator)(argument);
}

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

Если вы ищете «динамическое связывание», подобное разрешенному в C # или динамических языках, таких как PHP, к сожалению, вы действительно не можете этого сделать - C ++ уничтожает информацию о типе при компиляции кода.

Надеюсь, это поможет!

Возможно, вы захотите немного перефразировать вопрос, поскольку статическая и динамическая привязка действительно имеют определенное значение в C ++.

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

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

Значения параметров по умолчанию считаются статически связанными.

Скотт Мейерс обсуждает это в своей замечательной книге « Эффективный C ++ ».

HTH

Рассматривали ли вы использование комбинации boost :: bind и boost :: function? Между этими двумя утилитами вы можете легко заключить любой вызываемый C ++ объект в объект-функцию, легко сохранить их в контейнерах и, как правило, ожидать, что все это будет «просто работать». В качестве примера следующий пример кода работает именно так, как вы ожидали.

#include <boost/bind.hpp>
#include <boost/function.hpp>
#include <iostream>
using namespace std;

struct A            { virtual void hello() { cout << "Hello from A!" << endl; } };
struct B : public A { virtual void hello() { cout << "Hello from B!" << endl; } };

int main( int argc, char * argv[] )
{
    A a;
    B b;
    boost::function< void () > f1 = boost::bind( &A::hello, a );
    boost::function< void () > f2 = boost::bind( &A::hello, b );
    f1();  // prints: "Hello from A!"
    f2();  // prints: "Hello from B!"
    return 0;
}

Qt4 имеет прекрасную систему динамического связывания, которая стала возможной благодаря их «компилятору метаобъектов» (moc). Об этом есть хорошая запись на их странице объектной модели Qt .

Вот способ динамической загрузки классов из разделяемых библиотек в Linux http://www.linuxjournal.com/article/3687?page=0,0

Также существует вопрос о переполнении стека по этой динамической общей библиотеке C ++ в Linux

. То же самое можно сделать в Windows, динамически загружая функции C из библиотек DLL, а затем загружая их.

Карта становится тривиальной после того, как у вас есть решение для динамической загрузки.

В действительно хорошей книге Джеймса О. Коплиена «Расширенные идиомы и идиомы программирования на C ++» есть раздел, посвященный инкрементной загрузке

Я видел и ваш пример, и ответ на другой вопрос. Но если вы говорите о члене m_dispatcher, то ситуация совсем другая.

Что касается исходного вопроса, то нет способа итерации по методам класса. Можно только убрать повторение в add("method", T::method) с помощью макроса:

#define ADD(methodname) add(#methodname, T::methodname)

где '#' превратит имя метода в строку, как и требуется (расширьте макрос по мере необходимости). В случае одинаково названных методов это устраняет источник потенциальных опечаток, поэтому IMHO это очень желательно.

Единственный способ перечислить имена методов IMHO - это разбор вывода "nm" (в Linux, или даже в Windows через порты binutils) на таких файлах (вы можете попросить его распутать символы C++). Если вы хотите поддержать это, вы можете определить initDispatcher в отдельном исходном файле для автоматической генерации. Нет лучшего способа, чем этот, и да, он может быть уродливым или идеальным в зависимости от ваших ограничений. Кстати, это также позволяет проверить, что авторы не перегружают методы. Однако я не знаю, можно ли фильтровать публичные методы.

Отвечаю по поводу строки в конструкторе A и B. Думаю, проблему можно решить с помощью любопытно повторяющегося шаблона, примененного к Dispatchable:

template <typename T>
class Dispatchable
{
public:
    virtual ~Dispatchable() {}

    //! Dispatch the call
    void dispatch( const char *methodName )
    {
        dispatcher()->dispatch( this, methodName );
    }
protected:
    static Dispatcher<T> dispatcher() {
        return Dispatcher<T>::singleton();
        //Or otherwise, for extra optimization, using a suggestion from:
        //http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12
        static Dispatcher<T>& disp = Dispatcher<T>::singleton();
        return disp;
    }
};

Оговорка: я не смог проверить это (я вдали от компилятора). Возможно, вам потребуется переадресовать Dispatcher, но поскольку он получает аргумент шаблона, я полагаю, что аргумент-зависимый поиск делает это ненужным (я не настолько гуру C++, чтобы быть уверенным в этом).

Я добавил метод dispatcher() для удобства, если он понадобится в другом месте (в противном случае вы можете инлайнить его в dispatch()).

Причина, по которой CRTP так прост здесь и так сложен в другом потоке, заключается в том, что здесь ваш член не был статическим. Сначала я подумал сделать его статическим, потом подумал, что нет смысла сохранять результат вызова singleton() и тратить память, потом посмотрел и нашел это решение. Я сомневаюсь, что дополнительная ссылка в dispatcher() сэкономит дополнительное время. В любом случае, если бы член m_dispatcher был необходим, его можно было бы инициализировать в конструкторе Dispatchable().

Что касается вашего примера, то поскольку initDispatcher() является шаблонным методом, я откровенно сомневаюсь, что необходимо читать метод1 и метод2. A::initDispatcher(Dispatcher dispatcher) правильно добавит B::method1 в dispatcher.