Поля класса доступные по имени с setter и getter в C++

Мне кажется, что основная «эстетическая» проблема тут — отсутствие видимой декларации геттеров и сеттров. Это рвет шаблон.

А насчет макросов не негодуйте. Макросы — зло, их развивать никто не будет. Это даже хорошо, что нет перегрузки. Представьте какой зоопрак был бы.

Какая-то жуткая смесь Си, C++ и С++0x с регулярным эксплуатированием багов компилятора студии. Гигантские макросы, которые разворачиваются в шаблоны, которые инстанциируются для классов, которые в свою очередь сгенерированы препроцессором. Мечта для любителей отладки.

А причина появления статьи просто гениальна: «в C++ нет средства описания полей класса с контролируемым доступом, как например property в C#». Конец объяснений (к слову, в прошлой статье то же самое). Опять же, полный игнор комментариев к предыдущей статье. Извините, но это совсем не fun.

Искусство ради искусства.

Интересно получилось. Как автор предыдущей статьи скажу, что у вас получилось гораздо красивее с точки зрения синтаксиса. Я, кстати, на той статье не остановился и немного развил идею . Красивее не стало, зато теперь намного безопаснее. К ваше реализации есть пара претензий:
1) Использование чисто майкрософтовских «фич», которые нарушают кроссплатформенность. В студии и так есть свои проперти.
3) Неявное задание сеттеров и геттеров, которое ещё и обязывает по-вашему называть методы.
2) Не смог до конца разобраться, но как создать readonly свойство?

У меня сейчас бродят идеи реализации на основе новшеств C++11. Лямбды вместе с std::function помогут сделать обьяления методов доступа красивее, а возможность вызывать конструкторы друг из друга — выделить инициализацию свойств в отдельный конструктор.

Зачем!?

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

На сколько я знаю, с помощью boost preprocessor'а можно указать параметр с любым количеством параметров или что-то похожее. Перегрузить конечно макрос нельзя, но можно вроде обойтись листом параметров. Вот небольшая тема как реализовать подобное на gcc без boost'а.

>«Например поле типа int с именем «x». Нас вполне устроит такая запись: field(int,x);»
«отучаемся говорить за всех»©FIDO
меня устроит запись get_x() и set_x(v)

То есть, мы забили на все плюшки статической типизации, и сделали странный, кривой и неустойчивый динамический сеттер/геттер. А в чем профит?

По-моему, достаточно просто заполнить map<string, T>, и добавить к этому T &operator()(string). А в конструкторе заполнить мапу известными полями. Тогда такая запись:
obj("fieldName") = value; // имеет место быть

Ну вы хотя бы из любви к рациональности заюзали в базовом классе хеш-таблицу вместо вектора с линейным поиском и сравнением строк на каждой итерации.
К слову, нечто отдаленно похожее реализовано в .NET Framework в классе DependencyObject. Но там цель всего этого заключалась в том, что бы можно было описывать граф распространения значений свойств набора объектов, как набор других объектов, строить цепочки связанных свойств. Проще говоря, для организации Data Binding'а.

Касаемо перегрузки макросов, есть такая штука как variadic macro.

Полного решения проблемы это не даёт, но можно через этот variadic macro сделать вызов разных перегруженных методов. Я это использовал в своей библиотеке журналирования для Qt, о которой пока не успел написать на Хабре.

Выглядит это примерно так:

#define LOG_DEBUG(...)   Logger::write(Logger::Debug, __FILE__, __LINE__, Q_FUNC_INFO, ##__VA_ARGS__)

...

class Logger
{
  public:
    ...
    static void write(LogLevel logLevel, const char* file, int line, const char* function,
                                                                     const QString& message);
    static void write(LogLevel logLevel, const char* file, int line, const char* function,
                                                                     const char* message);
    static QDebug write(LogLevel logLevel, const char* file, int line, const char* function);
    ...
}

В вызываемом коде:

LOG_DEBUG("Test1");
LOG_DEBUG(tr("Test2")); // QObject::tr() возвращает QString
LOG_DEBUG() << "Test 3:" << testValue; // У объекта QDebug есть перегруженный operator<<

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

Очередной костыль для С++. Ради чуть лучшей читаемости наворотили чёрти-чего и сбоку бантик. Зачем? С++ прекрасен и без этих конструкций.

Может пора пересесть на C#? Или на Delphi? Там это лет 15 назад уже было.

PS: Впрочем, как академические упражнения в написании макросов и шаблонов, довольно занимательно.

У майкрософта есть своя версия

В одном из своих проектов использую такой вариант:

class FullStrategyMapScene : public QGraphicsScene
{
Q_OBJECT;
public:
// Инициализируем свойства
FullStrategyMapScene() : properties(this) {;}
~FullStrategyMapScene();

// Объявляем свойства
PROPERTIES(FullStrategyMapScene,
// Простое свойство
PROPERTY(QSize, CellSize)
// Простое свойство с инициализацией
PROPERTY_I(Unit const*, CurrentUnit, NULL)
// Свойство с геттером и сеттером
RW_PROPERTY(QPoint, CursorPos, GetCursorPos, SetCursorPos)
// Свойство с сеттером
WO_PROPERTY(IPlanet const*, Planet, SetPlanet)
RO_PROPERTY(ISurfaceMap const*, SurfaceMap, GetSurfaceMap)
);

private:
void SetPlanet(IPlanet const* planet);
QPoint const& GetCursorPos() const;
void SetCursorPos(QPoint const& pos);
ISurfaceMap const* GetSurfaceMap() const;
};


Тоже не бог весть что, но позволяет достигнуть желаемого эффекта («описания полей класса с контролируемым доступом»).