sigmaN 0 14 мая, 2018 Опубликовано 14 мая, 2018 · Жалоба Один мой товарищ( как говорится, не к ночи будет помянут сей язык, бывший PHPшник) в C++ коде для AVR8 везде лепит this-> Вот пример его кода https://pastebin.com/hqyYcQYh Аргументирует он это тем, что так якобы понятнее, что это член класса. Хотя, конечно-же, это решается нэймингом. В общем-то на C++ так никто не пишет, но хотелось бы привести весомые аргументы почему именно. Первый аргумент, который я привел: this это указатель. Используя его мы подрезаем ноги оптимизатору, который, как я понимаю, на много аккуратнее относится к оптимизации indirect access И может быть в каких-то простых случаях он этот this и упразднит, но тем не менее. Может быть у кого-то еще есть аргументы? Мне даже самому стало интересно. Уже который год эта тема у нас с ним регулярно поднимается. Прям холливар Сишника и бывшего ПХПшника Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexRayne 7 14 мая, 2018 Опубликовано 14 мая, 2018 · Жалоба Может быть у кого-то еще есть аргументы? Мне даже самому стало интересно. Уже который год эта тема у нас с ним регулярно поднимается. Прям холливар Сишника и бывшего ПХПшника тоже встречаю такой код. имхо, это подстелить соломку, дуть на воду после молока - как раз защищает от ошибочного нейминга. если объявить в функции локальное имя, перекрывающее поле класса, то получим непонятку. если класс большой, то обнаружить что локальная переменная перекрыла поле, может быть не всегда тривиально. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
novikovfb 19 14 мая, 2018 Опубликовано 14 мая, 2018 · Жалоба ИМХО, ставить везде this-> равносильно избыточному написанию скобок в выражениях: не мешает компилятору, но в случае перебора текст становится громоздким. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 141 14 мая, 2018 Опубликовано 14 мая, 2018 · Жалоба Согласен со всеми - с одной стороны защищает от сокрытия имени локальной перемеенй (последние ГЦЦ умеют ругаться по этому поводу), с другой стороны захламляет исходник как скобки в и без того очевидных местах: -- Осмелюсь доложить, господин фельдкурат взаправду не ошибся. Когда я был на действительной, меня освободили от военной службы из-за идиотизма, общепризнанного идиотизма. По этой причине отпустили из полка двоих: меня и еще одного, капитана фон Кауница. Тот, господин поручик, идя по улице, одновременно, извините за выражение, ковырял пальцем левой руки в левой ноздре, а пальцем правой руки -- в правой. На учении он каждый раз строил нас, как для церемониального марша, и говорил: "Солдаты... э-э... имейте в виду... э-э... что сегодня... среда, потому что... завтра будет четверг... э-э..." Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kabdim 0 14 мая, 2018 Опубликовано 14 мая, 2018 · Жалоба расскажите ему о (*this).something . Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 27 14 мая, 2018 Опубликовано 14 мая, 2018 · Жалоба Видать человек при переходе на С(++) походил по своим, исконным, граблям и решил их не убирать, а устранять последствия (спец-шлем this->). Сейчас и граблей уже нет, и забыто зачем это делалось. А привычка осталась. Возможно связано с тем, что в приведенном коде вся реализация класса находится в h-файле. А кода в cpp модуле с ф-ми в виде uint8_t TimeClass::GetSecond(void) { } не наблюдается. Соотв-но под вопросом информированность об операторе :: и определение области видимости вообще. Как с этим делом в PHP - не знаю, не плавал. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
tabr 0 14 мая, 2018 Опубликовано 14 мая, 2018 (изменено) · Жалоба Объясню, почему я так делаю... Код: class ClassA { public: void Set(uint8_t some_var) { //some actions } } class ClassB { public: void Set(uint8_t some_var) { //some actions } void BlaBlaBla(*ClassA var, uint8_t some_var) { if (/*something*/) { var->Set(some_var); this->Set(some_var);//вот тут правильнее в целом смотрится именно this, а не "Set(some_var);" } } } Так же если в методе я буду всё-таки вынужден использовать this для доступа к членам текущего класса, то комбинация void SomeFunction(void) { //some code } class SomeClass { void SomeFunction(void) { //some another code } void SomemethodA(void) { } void SomemethodB(void) { } void SomemethodC(void) { this->SomeFunction(); SomemethodA(); SomemethodB(); SomeFunction();//чё происходит? } } выглядит не очень. Как-то не читаемо, т.к. оно означает что где-то (НАВЕРНОЕ) есть функция с таким же названием, но это не точно. Такая ситуация может возникнуть, если оспользуешь какие-нить сишные либы, к примеру (мне неизвестные), и имя твоего метода ВНЕЗАПНО совпало с именем... ну вы поняли... ИМХО чем использовать ИНОГДА this (что я и делал сначала), я принял волевое xD решение использовать его ВСЕГДА - именно для повышения удобочитаемости кода. Изменено 14 мая, 2018 пользователем tabr Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 26 14 мая, 2018 Опубликовано 14 мая, 2018 · Жалоба © "Масло масляное" В крайне редких случаях использовал. Но потом по прошествии некоторого времени когда вижу "this->" в своем старом коде, то стараюсь исправить при первой же возможности. Другими словами с помощью "this->" я помечал костыли в своем коде. Поэтому, если весь код в итоге состоит из таких вот "костылей", то стоит задуматься, не пора ли "пациента" в конце концов вылечить и не мучаться ;) Были времена, когда поля класса помечал префиксом "_" подчеркивание. Но, к счастью, своевременно отказался, поскольку читать такой код сложно - глаза "спотыкаются" на ровном месте. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 7 14 мая, 2018 Опубликовано 14 мая, 2018 · Жалоба Может быть у кого-то еще есть аргументы? У меня два предложения. 1) поменьше думать за оптимизатор. this, не this.. Пока не доказано, что оно заметно влияет на производительность, заморачиваться не стоит. 2) Давать членам класса (да вообще, всему!) осмысленные имена, чтобы было понятно, что это, и откуда. Сам пишу без всяких this->, и очень страдаю, когда пишу self.бла-бла() :-) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Nixon 4 14 мая, 2018 Опубликовано 14 мая, 2018 · Жалоба Да какие аргументы, в первой же строчке написано почему - человек пришел из php. Вы еще кода перешедших с питона не видели :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 14 мая, 2018 Опубликовано 14 мая, 2018 · Жалоба Первый аргумент, который я привел: this это указатель. Используя его мы подрезаем ноги оптимизатору, который, как я понимаю, на много аккуратнее относится к оптимизации indirect access И может быть в каких-то простых случаях он этот this и упразднит, но тем не менее. А какая разница оптимизатору: явное указание this или его неявное подразумевание? Один фиг это косвенное обращение через указатель. Ему должно быть одинаково. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 27 14 мая, 2018 Опубликовано 14 мая, 2018 · Жалоба Код: . . . void SomeFunction(void) { ..//some code AAAA } class SomeClass { ...void SomeFunction(void) ...{ ...//some another code BBBB ...} ...void SomemethodA(void) ...{ ...} ...void SomemethodB(void) ...{ ...} ...void SomemethodC(void) ...{ .....this->SomeFunction(); .....SomemethodA(); .....SomemethodB(); .....SomeFunction();//чё происходит? - тоже, что и this->SomeFunction(); some code BBBB --------------- ::SomeFunction(); // +++ some code AAAA --------------- ...} } Y/N ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 26 14 мая, 2018 Опубликовано 14 мая, 2018 · Жалоба Если не ошибаюсь, то локальные методы/поля имеют приоритет над глобальными методами (функциями)/переменными. Другими словами: чем уже область видимости, тем больше преимущество (если тут можно применить такой термин). Речь про одинаковые названия. Но дабы не гадать как себя поведет тот или иной компилятор, стоит вообще избегать таких ситуаций. Поскольку найти потом подобные ошибки будет крайне сложно! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 15 мая, 2018 Опубликовано 15 мая, 2018 · Жалоба Если не ошибаюсь, то локальные методы/поля имеют приоритет над глобальными методами (функциями)/переменными. Другими словами: чем уже область видимости, тем больше преимущество (если тут можно применить такой термин). Очень опасно сиё. Ибо достаточно потом чуток изменить список аргументов вызова член-метода и забыть в одном из вызовов поправить этот список. И получить неожиданный эффект :biggrin: Стараюсь не делать глобальных функций и член-методов с одинаковыми именами без реальной необходимости. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 26 15 мая, 2018 Опубликовано 15 мая, 2018 · Жалоба Очень опасно сиё. А я с этим и не спорю. И потому нигде не применяю. Стараюсь не делать глобальных функций и член-методов с одинаковыми именами без реальной необходимости. А я вообще не использую ничего глобального. Одна из причин - как раз именно эта путаница в именах и никому не нужные сложности с именованием. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться