Arlleex 154 24 июня Опубликовано 24 июня · Жалоба Только что, Forger сказал: достаточно просто дополнить класс Led методами changeBalanceRed и т.д., и в одном цикле все поменять. Если в классе нет методов, то это как правило просто структура/union. И тогда к ней так и нужно относиться, указатели на ее поля тут точно будут лишними ) Дык это я для банальнейшего примера класс с тремя членами привел)) В реальности в классах несколько десятков переменных, которые сами являются классами и т.д. Каждая со своим именем. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 20 24 июня Опубликовано 24 июня · Жалоба 4 minutes ago, Arlleex said: Дык это я для банальнейшего примера класс с тремя членами привел)) В реальности в классах несколько десятков переменных, которые сами являются классами и т.д. Каждая со своим именем. Значит код спроектирован не очень удачно, коли приходится идти на такие "ухищерения" ( Для себя я давно убедился (по личному опыту) - как только добавляю указатель где-то, то что-то коде уже требует особого внимания, вплоть до перепроектирования проблемного участка. Это как некий звоночек )) Нет, я не боюсь указателей, просто всегда отношусь к ним с особой осторожностью. Если добавляю, то причина должна быть очень веской, а область его применения крайне узкой и ограниченной и обязательно отмечаю в этот кусок кода соотв. комментами, чтобы бросалось в глаза. Т.к. именно указатели и работа с ними доставляли больше всего хлопот (говорю за себя) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 210 24 июня Опубликовано 24 июня · Жалоба 7 минут назад, Arlleex сказал: Неа) Указатели на мемберы - т.е. указатели на члены данных, это не обычные классические указатели. Указатели на члены класса - это то же, что обычные указатели, но в адресном пространстве класса (если таковое представить). У вас же не возникает вопросов в нужности обычных указателей? Вот теперь представьте такой же случай, в котором нужны обычные указатели, но происходит это в адресном пространстве класса. 7 минут назад, razrab83 сказал: да конечно... вся графика через такой механизм. а можно передать событие, например кликнули мышкой. А там перекрывается несколько виджетов др. над другом. Именно так. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 154 24 июня Опубликовано 24 июня · Жалоба 22 минуты назад, jcxz сказал: Указатели на члены класса - это то же, что обычные указатели, но в адресном пространстве класса (если таковое представить). У вас же не возникает вопросов в нужности обычных указателей? Вот теперь представьте такой же случай, в котором нужны обычные указатели, но происходит это в адресном пространстве класса. Коллега выше представил пример класса виджетов, в котором нет указателей на члены данных класса. Вид указателей на члены данных я представил чуть выше. У них даже внутреннее представление не такое как у обычных указателей. Может даже от ситуации к ситуации быть 8/4 байт. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 210 24 июня Опубликовано 24 июня · Жалоба 3 минуты назад, Arlleex сказал: Коллега выше представил пример класса виджетов, в котором нет указателей на члены данных класса. Да, он привёл неудачный пример. Может он не совсем понял о чём речь? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
EdgeAligned 74 24 июня Опубликовано 24 июня (изменено) · Жалоба 2 часа назад, razrab83 сказал: так и есть круть. Смотря с чем сравнивать. Я подхожу к вопросу трезво без фанатизма. Много хорошего, но и дофига сколько косяков. Даже вот этот, который разбирали прямо сейчас - вынести любые методы можно в .cpp, но если этот же метод сделан шаблонным - уже нельзя. Хотя косяк простой - в .cpp просто не видится имя шаблонного типа. Примитивный косяк, про который забыли (забили) комитетчки (комитет по языку ++). Шаблоны в ++ это вообще один большой косяк. Из хорошего - nullptr - теперь официальный символ "указателя вникуда". Хотя по сути это всё тот же 0. 2 часа назад, razrab83 сказал: если что не понятно, спрашивайте. Столько интересного Какая из двух одинаковых конфет вкуснее? Изменено 24 июня пользователем EdgeAligned Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 154 24 июня Опубликовано 24 июня · Жалоба Возвращаясь к инстанцированию и специализациям. Вот смотрите. В пределах одного файла .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 25 июня Опубликовано 25 июня · Жалоба В 24.06.2024 в 19:32, EdgeAligned сказал: Даже вот этот, который разбирали прямо сейчас - вынести любые методы можно в .cpp, но если этот же метод сделан шаблонным - уже нельзя. и в чем тут косяк? это не баг, это фича. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
razrab83 21 25 июня Опубликовано 25 июня · Жалоба 12 часов назад, Arlleex сказал: Неа) Указатели на мемберы - т.е. указатели на члены данных/функции, это не обычные классические указатели. я понял о чем вы говорите. теоретически понятно, предоставляют дополнительную гибкость, мощь, и можно бороздить космические просторы. Но практически, что-бы кто-то это применял!? Тем более в контексте МК. Тут с++ и std некоторые считают излишеством. Только пуреСИ. )) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 210 25 июня Опубликовано 25 июня · Жалоба 5 часов назад, razrab83 сказал: Но практически, что-бы кто-то это применял!? Если это не применяете лично вы, то из этого не нужно делать выводы, что не применяет никто. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
razrab83 21 25 июня Опубликовано 25 июня · Жалоба 9 минут назад, jcxz сказал: Если это не применяете лично вы, то из этого не нужно делать выводы, что не применяет никто. Не надо мне приписывать того, чего я не говорил. Я ни где не сказал, что "не применяет никто". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 154 25 июня Опубликовано 25 июня · Жалоба Вот я определяю класс 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 25 июня Опубликовано 25 июня · Жалоба 7 минут назад, Arlleex сказал: Самое интересное в том, что я хочу как-то пометить класс как невозможным к инстанцированию любых объектов. Все функции я сделаю статическими. Но есть ли какой-то синтаксический атрибут, чтобы явно сказать компилятору, что от этого класса нельзя определять любые объекты? Только без всяких абстрактных классов, виртуальные функции мне банально не нужны и я не хочу, чтобы они даже мылили глаза, пусть даже в приватной области. Ну так - с помощью виртуальных функций. Которые в конце имеют =0; (забыл как называются). Если они вам не нужны, так и чего страшного? - никакой таблицы виртуальных методов и не будет раз ни один объект не будет создан. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 20 25 июня Опубликовано 25 июня · Жалоба 13 minutes ago, Arlleex said: Но есть ли какой-то синтаксический атрибут, чтобы явно сказать компилятору, что от этого класса нельзя определять любые объекты? защита от наследования: class MyClass final { public: и сделать конструктор класса приватным 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 154 25 июня Опубликовано 25 июня · Жалоба 4 минуты назад, jcxz сказал: Ну так - с помощью виртуальных функций. Которые в конце имеют =0; (забыл как называются). Если они вам не нужны, так и чего страшного? - никакой таблицы виртуальных методов и не будет раз ни один объект не будет создан. Визуальный мусор, обычно я когда читаю исходник я цепляюсь глазами. И если я вижу нечто такое virtual pureFunc() = 0; я предполагаю, что где-то потенциально кто-то может унаследовать этот класс и нужно быть внимательным. 2 минуты назад, Forger сказал: очень просто )) class MyClass final { public: Да? А это прям C++ или какое-то специальное расширение для компилятора? P.S. Неа... В кейле вот не работает(( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться