R>get- и set-методы можно сделать аргументами шаблона.
R>Тогда размер свойства уменьшится в 3раза.

Да, такая идея интересна, так как использует статическое программирование на этапе компиляции. Если методы доступа известны на этапе компиляции, то зачем это делать во время выполнения (передавать указатели при каждом конструировании). Так что, я полностью согласен с предыдущим оратором.

Но я озадачился другим. Можно ли не хранить вообще никаких дополнительных указателей? То есть может ли класс свойства самостоятельно вычислить указатель на класс-носитель свойства. Эта задача (применительно к подходу из статьи) эквивалентна задаче восстановления указателя на объемлющий объект-композит. То есть если у нас есть композит A, то его поле данных типа B может восстановить указатель на свой контейнер (при условии знания структуры А):

class A
{
public:
  class B
  {
  public:
    inline A * Container() 
    {
      // вычисляем смещение поля b_ внутри A
      B A::*pB = &A::b;
      // базируемся относительно своего this
      return (A*) ( size_t(this) - *((size_t *)&pB) );
    }
    //...
  }
  B b_;
  //...
}

A a;
cout << ( & A == A.b_.Container() );

Очевилно, что это вычисление не статическое и происходит во время выполнения программы.

У меня вопрос к аудитории:
Можно ли более элегантно решить именно такую задачу?