Автоматическая генерация операторов сравнения структур в C++

Понимаю. Просто, дело в том, что если класс уже отлажен, то в него нельзя добавлять новые поля. Иначе, он автоматически становится неотлаженным. А для неотлаженных классов существует процесс тестирования. Если меняешь оттестированный код — протестируй его заново, я следую этому принципу, и у меня не может возникнуть описанной вами ситуации, отсюда мое недоумение.

Нда, не пишите так больше.
Даже не говоря о том, что будет если в структуре встретится к примеру что-нибудь типа std::string.
Это нарушает все нормы языка, и имеет кучую сайд эфектов.

Порядок получается нестественный.

Понимаете, вы «заставляете» каждый класс дополнительно нести кучу информации о его членах, а сама функция сравнения стала настолько сложной, что оптимизировать её компилятору уже невозможно (пройтись по динамическому массиву указателей на функции и вызвать их все — ни у какого компилятора AI не хватит).

Мой же вариант будет требовать нулевые накладные расходы: нет никаких дополнительных полей в классе, как следствие — нет дополнительных расходов на работу с ними в конструкторе/деструкторе. Кроме того, информация о типах полей известна компилятору — оператор сравнения будет сгенерирован очень эффективным для простых (базовых) типов.

Сравните то, что получается у вас для, к примеру, массива из тысячи элементов вида

struct point_type {
  int x, y;
};

— сколько ваше решение потребует выделений/освобождений памяти.

И сравните с тем, что должно быть в идеале:

struct point_type {
  int x, y;

  bool operator==(const point_type& other) {
    return x==other.x && y==other.y;
  }
};

За счет того, что в классе CValue были переопределены оператор преобразования к типу шаблонного параметра, а также оператор присвоения, к переменной класса CValue можно обращаться с применением стандартного синтаксиса через оператор "." либо "->".

template<typename T>
class CValue : public IValue
{
public:
    CValue& operator=(const T& rhs)
    {
        m_value = rhs;
        return *this;
    }
    operator T()const
    {
        return m_value;
    }
};

Несколько интересней другой момент.

В моей реализации объекты класса CValue являются членами класса-структуры, которая в свою очередь содержит вектор указателей на базовый интерфейс IValue. И каждый класс CValue, при создании, должен себя регистрировать в этом векторе.
Но по законам C++ члены класса не имеют доступа к указателю на класс, в котором они содержаться.
А передавать в каждый член указатель на класс-контейнер не хотелось, т.к. каждый член пришлось бы писать дважды (при объявлении и в списке инициализации).

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

std::map<DWORD, CStructBase*> g_mapByThreadId;
CCriticalSection              g_cs;

class IValue
{};

class CStructBase
{
public:
    CStructBase()
    {
        CScopeLock scopeLock(g_cs);
        g_mapByThreadId[GetCurrentThreadId()] = this;
    }
    static void RegisterValue(IValue* value)
    {
        CScopeLock scopeLock(g_cs);
        g_mapByThreadId[GetCurrentThreadId()]->m_values.push_back(value);
    }
private:
    std::vector<IValue*> m_values;
};

class CValue : public IValue
{
public:
    CValue()
    {
        CStructBase::RegisterValue(this);
    }
};

Делалось все это ради простоты описания структуры, которое выглядит примерно так:

class CMyStruct : public CStructBase
{
public:
    CValue<int>          id;
    CValue<std::string>  name;
};

За счет того, что вначале отрабатывает конструктор базового класса, указатель на CStructBase* сохраняется в глобальной переменной, для текущего потока. Затем поочередно конструируются члены класса CMyStruct, и каждый из них регистрирует себя в списке m_values.

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

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