C++ property

[Bepec]

А вы в курсе что проперти это переменная с геттером и сеттером в Qt?

[AzazelloAV]

А вы в курсе что проперти это переменная с геттером и сеттером в Qt?

Я там в прошлое сообщение подкорректировал, прочитайте.
Конечно в курсе, это ж "расширение" языка, а не новый язык. По другому нельзя. Глупо было бы, если через метаданные мы могли бы значение получить, а через обычный метод нет, тем более Q_OBEJCT нужен. Да и вообще он для других целей, для доступа "извне" или через скрипты, а не программирования внутри.

[Bepec]

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

Логики не видно.

И ваше высказывание, что он "внутри" не нужен - это вы погорячились наверно

[alex312]

Вот пример
class QRect {
private:
    int x1;
    int y1;
    int x2;
    int y2;
}

Вот контр пример :

Код

C++ (Qt)
class QSignalBlocker
{
public:
    inline explicit QSignalBlocker(QObject *o);
    inline explicit QSignalBlocker(QObject &o);
    inline ~QSignalBlocker();
 
#ifdef Q_COMPILER_RVALUE_REFS
    inline QSignalBlocker(QSignalBlocker &&other);
    inline QSignalBlocker &operator=(QSignalBlocker &&other);
#endif
 
    inline void reblock();
    inline void unblock();
private:
    Q_DISABLE_COPY(QSignalBlocker)
    QObject * m_o;
    bool m_blocked;
    bool m_inhibited;
};

[AzazelloAV]

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

Логики не видно.

Ну, я как раз говорил, что нужно ввести их, чтобы они имели прямой доступ без гет к примеру.
Так пойдёт

class Color
public:
   property тип color:read mColor write setColor()
private:
   void setColor;
   тип mColor  

Во первых, мы не ищем пару гет/сет
Во вторых, мы не видем set
В третих, мы можем просто написать без set, а когда нужно добавить его.

Что такое метод гет? в 90% случаев - это inline color() const { return mColor; } или человеческим языком повышаем область видимости из приват в паблик со спецификатором const. Хорошо, пусть я предлагаю следующее

inline &color() { retrun mColor; }

color() = "red", где оператор =  перегруженный оператор, вызывающий setColor, как то так, не ругайте за псевдокод.

Давайте я вам приведу ещё пример

class Test
public:
    const QString name;
    Test(const QString n): name(n)

Правильный код с точки зрения языка, ничего не нарушено. Нейм у нас в публичном доступе т.к. константный и ничего рухнуть не может. Будет ли такой код "работать" - неа, не будет, он вызовет кучу раздражения, т.к. в с++ нет "культуры пропертей"

И ваше высказывание, что он "внутри" не нужен - это вы погорячились наверно

Почему погорячился, да нет, он для этого по сути создан. Дезигнер тому пример. Я же в общем говорю, а не сужаю задачи. Я его, к примеру, внутри использовал для сериализации своих объектов. Засунул геты/сеты в пропети и давай в хмл. Мы же большинство кода пишем  со связыванием, а здесь отвязались по причине универсальности.

[AzazelloAV]

Вот контр пример :

Мы же не соревнуемся, кто больше найдёт. Я говорю что они спокойно осознано игнорируют правила и не заморачиваются на это.
Редкая птица у них метод get  с префиксом get, вы заметили? Set - да, гет - очень редко.

[Igors]

Мы же не соревнуемся, кто больше найдёт. Я говорю что они спокойно осознано игнорируют правила и не заморачиваются на это.
Редкая птица у них метод get  с префиксом get, вы заметили? Set - да, гет - очень редко.

И еще о мозге: его емкость очень ограничена. Занимаясь фигней типа "писать get или как?" - для работы места уже не остается. Вы, батенька, бездельник 

[Bepec]

Если вы можете поддерживать тот уровень проверки кода, имеете такую же базу подписчиков ищущих баги - можете даже от сеттеров отказаться
Эта "идеология" позволяет одиночке или группе облегчить жизнь и дебажинг ценой пары строк. А вы восстаёте против неё )

Создавайте свою технологию, идеологию, внедряйте в массы - никто не запрещает. Но пока что я вижу лишь доказательства "от противного".
Т.е. ощутимых плюсов для людей/разработки/дебагинга/читаемости кода вы не описываете. Вы берёте старую идеологию и клевещите на неё

[AzazelloAV]

И еще о мозге: его емкость очень ограничена. Занимаясь фигней типа "писать get или как?" - для работы места уже не остается.

Я давно убедился, и меня никто не переубедит (и я никого не хочу переубеждать). Но самая сложная вещь в программировании, которой нужно уделять как можно больше времени (и которая его и съедает) это не какие то рекурсии, лямбды и иерархии классов. Самая сложная вещь это давать имена классам, функциям и переменным. Сложнее ничего нету и не будет.

Вы, батенька, бездельник

А вы не завидуйте.

[AzazelloAV]

Если вы можете поддерживать тот уровень проверки кода, имеете такую же базу подписчиков ищущих баги - можете даже от сеттеров отказаться
Эта "идеология" позволяет одиночке или группе облегчить жизнь и дебажинг ценой пары строк. А вы восстаёте против неё )

Создавайте свою технологию, идеологию, внедряйте в массы - никто не запрещает. Но пока что я вижу лишь доказательства "от противного".
Т.е. ощутимых плюсов для людей/разработки/дебагинга/читаемости кода вы не описываете. Вы берёте старую идеологию и клевещите на неё

Мдя. Ни на что я не клевещу. А давайте пойдём от обратного. Почему бы не сделать , ведь это никак не может отменить пару гет/сет.
Конечно от обратного я иду. Проперти дополняют гет/сет, а не заменяют его. Я же не говорю убираем геты/сеты и только проперти ставим. И никуда я не воставал. Я вообще про именование переменных писал внутри класса и что очень много догм, которые мы придерживаемся для "чтобы осталось время на творчество, а не мозги включать там где не надо".а

Да и дался вам этот дебаг. Я не вижу разницы между инлайном и проперти в плане дебага. Одно и тоже. И дебажится будет на ура.

Да и про читаемость кода я говорил, однозначно она повысится.

[Bepec]

Не видите ну и ладненько

[AzazelloAV]

Не видите ну и ладненько

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

[m_ax]

Один из положительных мометов ввода проперти мы отделяем методы работы со всем классом с методом работы с конкретной переменной класса (пусть даже она  вычисляется налету)

Если сложно выразился, то для меня в чем + - мы скрываем переменные, а выглядят они как открытые. Это первый момент.
Второй момент читаемость кода. Какая читаемость скажете вы?

Не убедительно..
Во-первых, механизм проперти легко реализуется и средствами самого языка, вот упрощённый вариант:

Код

C++ (Qt)
#include <iostream>
#include <functional>
 
template <class T, class Obj>
class property
{
public:
    typedef std::function<T(Obj*)> getter_t;
    typedef std::function<void(Obj*, const T&)> setter_t;
 
    void init(Obj* obj, getter_t get, setter_t set)
    {
        object = obj;
        getter = get;
        setter = set;
    }
 
    property& operator=(const T& val)
    {
        setter(object, val);
        return *this;
    }
 
    operator T() const { return getter(object); }
 
private:
    Obj* object;
    getter_t getter;
    setter_t setter;
};
 
 
class test
{
public:
    test()
    {
        intProperty.init(this, &test::get, &test::set);
    }
 
    property<int, test> intProperty;
 
private:
    int value;
    int get() const
    {
        std::cout << "test::get() const" << std::endl;
        return value;
    }
    void set(int val)
    {
        std::cout << "test::set(int)" << std::endl;
        value  = val;
    }
};
 
int main()
{
    test t;
    t.intProperty = 123; // здесь будет вызван метод void test::set(int)    
    int a = t.intProperty; // здесь будет вызван метод int test::get() const 
 
    return 0;
}
 

Теперь мы можем работать с проперти как с открытым членом класса (почти!), но при этом будут вызываться соответствующие сеттеры и геттеры.
Но реально, нам всё равно необходимо писать самим эти сеттеры и геттеры для каждого проперти и регистрировать их..
Число строк кода не сократилось, а напротив.. Стал ли он от этого более наглядным, читабельным?
Реально что дают проперти - это "синтаксический сахар" не больше..

Но у проперти есть и свои минусы. Предположим у нас появился соблазн (в примере выше) иметь возможность делать инкремент и декремент, например:

Код

C++ (Qt)
t.intProperty++;
 

Это уже не сработает.. Придётся в классе property реализовывать эти операторы.. Но дело в том, что не для каждого типа они имеют смысл (представьте, что property имеет тип QString или QVector или).
И это только один из примеров.





 

[AzazelloAV]

Не убедительно..

Тут не в реализации дело, а в принятии сообществом данных вещей. Заметте, принципиально не говорю про другие языки программирования, т.к. всё таки С++ стоит отдельно "от всех". Опять все повторяют о ухудшении читаемости. Это не так.

Видно идти нужно малыми шагами.
Переменная объекта. Только реад онли внешне.
Где ухудшение читаемости и увеличение кода?

class
public:
   property state read mState
private:
  mState
 

Все таки, если задуматься, вы конечно правы про ограничения. Тот же ++i. Тут сложности ещё те, может поэтому.....

[Bepec]

Вы предлагаете увеличить количество кода, сложность кода, ради "не писать геттер". А смысл?