Можно ли определить «виртуальную» реализацию по умолчанию для getter-setter без макросов препроцессора

Question

Можно использовать шаблон для реализации по умолчанию getter-setter.

Например - http://www.kirit.com/C%2B%2B%20killed%20the%20get%20%26%20set%20accessors/A%20simple%20meta-accessor. Самое важное, что если вы решите переопределить поведение по умолчанию такого установщика или получателя, вы можете легко сделать это без необходимости изменять «клиентский» код, потому что установщик-получательСинтаксис вызова аналогичен вызывающим методам, то есть:

an_object.an_int( 3 );
int i = an_object.an_int();

В обоих случаях an_int может быть объектом с оператором () или методом an_object.После переопределения потребуется перекомпиляция в «клиентском» коде.

Но возможно ли определить «виртуальную» реализацию по умолчанию для getter-setter без макросов препроцессора?Т.е. здесь важно то, что при переопределении перекомпиляции «клиентского» кода не требуется.Конечно, это возможно сделать с препроцессором, интересно, есть ли более элегантное решение?

Для моего знания C ++ 03 это невозможно, но, возможно, у кого-то есть какие-то идеи, или, может быть, это так.возможно в C ++ 11?

---

Ответ для "David Rodríguez - dribeas": что-то вроде этого:

#define accessor(type,name) \
virtual type name() {return m_##name;} \
type m_##name;

Может быть переопределено в производном классе без необходимости перекомпиляциикод "клиента".

Answer 1

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

Чтобы сделать это, вы вкладываете много сложности в этот «полевой» тип, который вы пишете. Эта сложность не будет обобщать хорошо. Это будет огромный беспорядок, который будет не проще в использовании, чем просто написание принадлежностей самостоятельно.

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

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

Answer 2

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