[Arlleex 154]

Только что, Forger сказал:

достаточно просто дополнить класс Led методами  changeBalanceRed и т.д., и в одном цикле все поменять.

Если в классе нет методов, то это как правило просто структура/union. И тогда к ней так и нужно относиться, указатели на ее поля тут точно будут лишними )

Дык это я для банальнейшего примера класс с тремя членами привел)) В реальности в классах несколько десятков переменных, которые сами являются классами и т.д. Каждая со своим именем.

[Forger 20]

4 minutes ago, Arlleex said:

Дык это я для банальнейшего примера класс с тремя членами привел)) В реальности в классах несколько десятков переменных, которые сами являются классами и т.д. Каждая со своим именем.

Значит код спроектирован не очень удачно, коли приходится идти на такие "ухищерения" (

 

Для себя я давно убедился (по личному опыту) - как только добавляю указатель где-то, то что-то коде уже требует особого внимания, вплоть до перепроектирования проблемного участка. Это как некий звоночек ))

Нет, я не боюсь указателей, просто всегда отношусь к ним с особой осторожностью. Если добавляю, то причина должна быть очень веской, а область его применения крайне узкой и ограниченной и обязательно отмечаю в этот кусок кода соотв. комментами, чтобы бросалось в глаза. Т.к. именно указатели и работа с ними доставляли больше всего хлопот (говорю за себя)

[jcxz 210]

7 минут назад, Arlleex сказал:

Неа) Указатели на мемберы - т.е. указатели на члены данных, это не обычные классические указатели.

 

Указатели на члены класса - это то же, что обычные указатели, но в адресном пространстве класса (если таковое представить). У вас же не возникает вопросов в нужности обычных указателей? Вот теперь представьте такой же случай, в котором нужны обычные указатели, но происходит это в адресном пространстве класса.

7 минут назад, razrab83 сказал:

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

Именно так.

[Arlleex 154]

22 минуты назад, jcxz сказал:

Указатели на члены класса - это то же, что обычные указатели, но в адресном пространстве класса (если таковое представить). У вас же не возникает вопросов в нужности обычных указателей? Вот теперь представьте такой же случай, в котором нужны обычные указатели, но происходит это в адресном пространстве класса.

Коллега выше представил пример класса виджетов, в котором нет указателей на члены данных класса.

Вид указателей на члены данных я представил чуть выше. У них даже внутреннее представление не такое как у обычных указателей. Может даже от ситуации к ситуации быть 8/4 байт.

[jcxz 210]

3 минуты назад, Arlleex сказал:

Коллега выше представил пример класса виджетов, в котором нет указателей на члены данных класса.

Да, он привёл неудачный пример. Может он не совсем понял о чём речь?  

[EdgeAligned 74]

2 часа назад, razrab83 сказал:

так и есть круть. 

Смотря с чем сравнивать. Я подхожу к вопросу трезво без фанатизма. Много хорошего, но и дофига сколько косяков. Даже вот этот, который разбирали прямо сейчас - вынести любые методы можно в .cpp, но если этот же метод сделан шаблонным - уже нельзя. Хотя косяк простой - в .cpp просто не видится имя шаблонного типа. Примитивный косяк, про который забыли (забили) комитетчки (комитет по языку ++).  Шаблоны в ++ это вообще один большой косяк. 
Из хорошего - nullptr - теперь официальный символ "указателя вникуда". Хотя по сути это всё тот же 0.

2 часа назад, razrab83 сказал:

если что не понятно, спрашивайте. Столько интересного

Какая из двух одинаковых конфет вкуснее?

Изменено 24 июня пользователем EdgeAligned

[Arlleex 154]

Возвращаясь к инстанцированию и специализациям.

Вот смотрите. В пределах одного файла .cpp я пишу

template<typename T>
class foo {
  T data;
};

template class foo<double>;

int main()
{
    foo<int> foo_int_object;
    
    foo<double> d;

    std::cout<<"Hello World";

    return 0;
}

Имеется шаблон класса foo. Окей, затем строчкой template class foo<double>; я создаю экземпляр шаблона foo с типом double. Т.е. я явно создал шаблон этого класса. Т.е. для строчки foo<int> foo_int_object; сначала произойдет инстанцирование (порождение) конкретного шаблона foo<int>, а затем этот тип будет использован при определении переменной foo_int_object. А вот при компиляции строчки foo<double> d; никаких телодвижений по созданию шаблона не будет, т.к. мы явно его уже создали. Тогда вопрос: а что дает такое явное инстанцирование шаблона? Т.е. как это применяется на практике? Виден ли от этого профит в пределах одной единицы трансляции?

Кажется, я разобрался

[juvf 17]

В 24.06.2024 в 19:32, EdgeAligned сказал:

Даже вот этот, который разбирали прямо сейчас - вынести любые методы можно в .cpp, но если этот же метод сделан шаблонным - уже нельзя.

и в чем тут косяк? это не баг, это фича.

[razrab83 21]

12 часов назад, Arlleex сказал:

Неа) Указатели на мемберы - т.е. указатели на члены данных/функции, это не обычные классические указатели.

я понял о чем вы говорите. теоретически понятно, предоставляют дополнительную гибкость, мощь, и можно бороздить космические просторы. Но практически, что-бы кто-то это применял!? Тем более в контексте МК. Тут с++ и std некоторые считают излишеством. Только пуреСИ. ))

[jcxz 210]

5 часов назад, razrab83 сказал:

Но практически, что-бы кто-то это применял!?

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

[razrab83 21]

9 минут назад, jcxz сказал:

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

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

[Arlleex 154]

Вот я определяю класс

class MyClass {
  public:
    void publicFunc(u8 arg) {
      privateFunc(Enum::ENUM1, arg);
    }
  
  ...
  
  private:
    enum Enum {
      ENUM1
    };
    
    void privateFunc(Enum e, u8 arg);
};

Это некий интерфейс, который я описываю в заголовочном файле. Пользователь моего класса может получать доступ только к публичным методам. "Ослиные уши" в виде определения вспомогательного Enum не будут видны. А также и приватная функция не будет доступна для явного вызова. Ее реализация будет помещена в *.cpp файл, чтобы можно было, например, вовсе скомпилировать статическую библиотеку. Так разграничивается API класса от его вспомогательной требухи.

Самое интересное в том, что я хочу как-то пометить класс как невозможным к инстанцированию любых объектов. Все функции я сделаю статическими. Но есть ли какой-то синтаксический атрибут, чтобы явно сказать компилятору, что от этого класса нельзя определять любые объекты? Только без всяких абстрактных классов, виртуальные функции мне банально не нужны и я не хочу, чтобы они даже мылили глаза, пусть даже в приватной области.

[jcxz 210]

7 минут назад, Arlleex сказал:

Самое интересное в том, что я хочу как-то пометить класс как невозможным к инстанцированию любых объектов. Все функции я сделаю статическими. Но есть ли какой-то синтаксический атрибут, чтобы явно сказать компилятору, что от этого класса нельзя определять любые объекты? Только без всяких абстрактных классов, виртуальные функции мне банально не нужны и я не хочу, чтобы они даже мылили глаза, пусть даже в приватной области.

Ну так - с помощью виртуальных функций. Которые в конце имеют =0; (забыл как называются). Если они вам не нужны, так и чего страшного? - никакой таблицы виртуальных методов и не будет раз ни один объект не будет создан.

[Forger 20]

13 minutes ago, Arlleex said:

Но есть ли какой-то синтаксический атрибут, чтобы явно сказать компилятору, что от этого класса нельзя определять любые объекты?

защита от наследования:

class MyClass final {
  public:

и сделать конструктор класса приватным

[Arlleex 154]

4 минуты назад, jcxz сказал:

Ну так - с помощью виртуальных функций. Которые в конце имеют =0; (забыл как называются). Если они вам не нужны, так и чего страшного? - никакой таблицы виртуальных методов и не будет раз ни один объект не будет создан.

Визуальный мусор, обычно я когда читаю исходник я цепляюсь глазами. И если я вижу нечто такое virtual pureFunc() = 0; я предполагаю, что где-то потенциально кто-то может унаследовать этот класс и нужно быть внимательным.

2 минуты назад, Forger сказал:

очень просто ))

class MyClass final {
  public:

 

Да? А это прям C++ или какое-то специальное расширение для компилятора?

P.S. Неа... В кейле вот не работает((