Перейти к содержанию
    

razrab83

Участник
  • Постов

    383
  • Зарегистрирован

  • Посещение

  • Победитель дней

    3

razrab83 стал победителем дня 30 января

razrab83 имел наиболее популярный контент!

Репутация

21 Очень хороший

Информация о razrab83

  • Звание
    Местный
    Местный

Посетители профиля

2 023 просмотра профиля
  1. я знаю что такое протектед и для чего он используется. Поэтому я его не использую ни для членов, ни для функций. Это источник проблем. По сути это тот же паблик, только среди ограниченного круга. Это ваш личный холодильник на этаже в общежитии/комуналке. Кроме Вас, к нему имеют доступ все жители общяги, но ни кто "чужой" не сможет туда попасть )). Если писать для всех закрытые библиотеки в виде файлов типа .a, то да. А если писать для всех срр или работать в команде.... хороший пример "для всех" всякие ротос (кернел, фриртос, сцм), Qt, Qwt, LVGL (ой, это же не всё ++), boost, .... и все с исходниками без.
  2. я использую иерархию классов. наследование и прочие плюшки ООП. Не использую protected ни для членов, ни для методов. Для меня, если кроме меня кто-то может использовать мой метод (или мои данные) - это тоже что кто попало. Я не настаиваю на правильности моего подхода. Делайте как вам удобно. Я про себя говорю. Отучили меня от протектед. Очень полезно.
  3. если значки не нравятся, то Communication() : Module("Communication"){} - а в конструкторе Module значки, как и в setName
  4. ну если только для такой вкусовщины, типа такой Communication() { setName("Communication"); } если по нормальному так, как обычно делают как я предложил, то протектед методы не нужны и не оправданы.
  5. а какого рожна class Communication изменяет члены класса Module без гетера на прямую? не вы ли тут с пеной у рта про доступ до членов только через гетеры? Скажете: name - это protected. Меня учили писать без protected. Вернее, как я только его ставил - били по рукам. В контексте наследников от Module, protected - этот тоже самое что public. Т.е. вся родня может менять name. Ну у меня 160 родственников(наследников) и 2 чужака в деревне. 160 жителей могут залезть мне в кошелёк, а 2 нет. Это тоже самое, что все могут. поэтому вместо protected меня приучили определиться, где должен быть name и закрыть его гетерами. Или же, если разрешил соседям жэну кому-то менять снаружи name ... то переноси его паблик. убрать его в конструктор. Но Module.h всё равно - выньдапаложь со всем потрахами )) class Communication : public Module { public: Communication() : Module(const_cast<char*>("Communication")) {}; // код };
  6. Это ваш кеил - просто оболочка )) я не про это. в Eclipse, в визарде создания класса есть эти фичи. От компилятора визрад эклипса не зависит. Можно гуями все эти delete, приваты и final-ы настроить, В визарде QtCreator этого нет. в VSCode я тоже не замечал. в Кейле не знаю.
  7. присоединяюсь к вопросу. сущность класса - наследование, полиморфизм. Если его зафиналить и закупорить, все методы в статик - то можно всё сделать без класса. данные, функции... для нэймспейсинга использовать namespace. не очень хорошая идея. это "неявное". Когда ЯВНО указан private - это явно указан private . а когда его нет - он явно не указан или его забыли?
  8. если среди горсть визуального мусора нету какого нибудь др. конструтора, например MyClass(int index);
  9. class A final { public: A() = delete; // Удаляем конструктор по умолчанию private: int a; }
  10. Не надо мне приписывать того, чего я не говорил. Я ни где не сказал, что "не применяет никто".
  11. я понял о чем вы говорите. теоретически понятно, предоставляют дополнительную гибкость, мощь, и можно бороздить космические просторы. Но практически, что-бы кто-то это применял!? Тем более в контексте МК. Тут с++ и std некоторые считают излишеством. Только пуреСИ. ))
  12. да конечно... вся графика через такой механизм. а можно передать событие, например кликнули мышкой. А там перекрывается несколько виджетов др. над другом.
  13. class MyWidget { public: MyWidget(MyWidget *parent_ = nullptr) { next = nullptr; child = nullptr; prev = nullptr; if(parent_) { parent = parent_; parent->addChild(this); } } virtual void paint() { //код рисования самого себя? т.е. MyWidget-а { } if(child != nullptr) child->paint(); if(next != nullptr) next->paint(); } /*private: много писанины с приватом, пусть будет протект*/ protect: MyWidget *next; MyWidget *child; MyWidget *prev; MyWidget *parent; } //ну и наследуемся class Label : public MyWidget { public: Label(MyWidget *parent_ = nullptr) :MyWidget(nullptr) void paint() override { //код рисования самого себя? т.е. Label-а { } MyWidget::paint(); } } не очень понял что занчит "мемберы" и "обычные указатели". Но мой пример - это не то?
  14. понятно А разве всякие GUI - это не конкретный пример. Например Qt состоит обычно GUI состоит чуть менее, чем полностью из членов-указателей. Указатель на парент, указатель на child. В GUI указатели на всякие next, prev, .... у главного окна может быть массив детей (массив указателей на Widget), и надо всем дать команду отрисовки - по массиву указателей всех перебрал. А может на главном окне 2 кнопоки и 2 лейбы, у главного окна только один указатель на child (пусть будет кнопка1), а у этой кнопки1 указатель next на кнопку2, у кнопки 2 указатель next на лейбу1, у лейбы1 next указывает на лейбу2, у лейбы2 next =0; Главное окно вызывает у child->repaint(), т.е. у кнопки1, кнопка1 в своем методе вызовит repaint у своего child, а потом проверит, если next != 0, то вызовит next->repaint(); И так произойдет repaint всех детей главного окна включая внуков, правнуков и все родовое дерево до последнего младенца. тоже самое при удалении (о чем говорил jcxz). Так же можно открепить чаилда (созданого динамически в какойнить фабрике) и передать другому родителю.... это с указателями это делается.
×
×
  • Создать...