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

C++ доступ к членам класса через this->

Один мой товарищ( как говорится, не к ночи будет помянут сей язык, бывший PHPшник) в C++ коде для AVR8 везде лепит this->

 

Вот пример его кода https://pastebin.com/hqyYcQYh

 

Аргументирует он это тем, что так якобы понятнее, что это член класса.

Хотя, конечно-же, это решается нэймингом.

 

В общем-то на C++ так никто не пишет, но хотелось бы привести весомые аргументы почему именно.

 

Первый аргумент, который я привел: this это указатель. Используя его мы подрезаем ноги оптимизатору, который, как я понимаю, на много аккуратнее относится к оптимизации indirect access

И может быть в каких-то простых случаях он этот this и упразднит, но тем не менее.

 

Может быть у кого-то еще есть аргументы? Мне даже самому стало интересно. Уже который год эта тема у нас с ним регулярно поднимается. Прям холливар Сишника и бывшего ПХПшника :biggrin:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Может быть у кого-то еще есть аргументы? Мне даже самому стало интересно. Уже который год эта тема у нас с ним регулярно поднимается. Прям холливар Сишника и бывшего ПХПшника :biggrin:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

ИМХО, ставить везде this-> равносильно избыточному написанию скобок в выражениях: не мешает компилятору, но в случае перебора текст становится громоздким.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Согласен со всеми - с одной стороны защищает от сокрытия имени локальной перемеенй (последние ГЦЦ умеют ругаться по этому поводу), с другой стороны захламляет исходник как скобки в и без того очевидных местах:

-- Осмелюсь доложить, господин фельдкурат взаправду не

ошибся. Когда я был на действительной, меня освободили от

военной службы из-за идиотизма, общепризнанного идиотизма. По

этой причине отпустили из полка двоих: меня и еще одного,

капитана фон Кауница. Тот, господин поручик, идя по улице,

одновременно, извините за выражение, ковырял пальцем левой руки

в левой ноздре, а пальцем правой руки -- в правой. На учении он

каждый раз строил нас, как для церемониального марша, и

говорил: "Солдаты... э-э... имейте в виду... э-э... что

сегодня... среда, потому что... завтра будет четверг... э-э..."

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Видать человек при переходе на С(++) походил по своим, исконным, граблям и решил их не убирать, а устранять последствия (спец-шлем this->).

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

 

Возможно связано с тем, что в приведенном коде вся реализация класса находится в h-файле.

А кода в cpp модуле с ф-ми в виде

uint8_t TimeClass::GetSecond(void) {  }

не наблюдается. Соотв-но под вопросом информированность об операторе :: и

определение области видимости вообще. Как с этим делом в PHP - не знаю, не плавал.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Объясню, почему я так делаю...

Код:

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 решение использовать его ВСЕГДА - именно для повышения удобочитаемости кода.

Изменено пользователем tabr

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

© "Масло масляное"

 

В крайне редких случаях использовал.

Но потом по прошествии некоторого времени когда вижу "this->" в своем старом коде, то стараюсь исправить при первой же возможности.

Другими словами с помощью "this->" я помечал костыли в своем коде.

 

Поэтому, если весь код в итоге состоит из таких вот "костылей", то стоит задуматься, не пора ли "пациента" в конце концов вылечить и не мучаться ;)

 

Были времена, когда поля класса помечал префиксом "_" подчеркивание. Но, к счастью, своевременно отказался, поскольку читать такой код сложно - глаза "спотыкаются" на ровном месте.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Может быть у кого-то еще есть аргументы?

 

У меня два предложения.

1) поменьше думать за оптимизатор. this, не this.. Пока не доказано, что оно заметно влияет на производительность, заморачиваться не стоит.

2) Давать членам класса (да вообще, всему!) осмысленные имена, чтобы было понятно, что это, и откуда.

 

Сам пишу без всяких this->, и очень страдаю, когда пишу self.бла-бла() :-)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Да какие аргументы, в первой же строчке написано почему - человек пришел из php. Вы еще кода перешедших с питона не видели :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Первый аргумент, который я привел: this это указатель. Используя его мы подрезаем ноги оптимизатору, который, как я понимаю, на много аккуратнее относится к оптимизации indirect access

И может быть в каких-то простых случаях он этот this и упразднит, но тем не менее.

А какая разница оптимизатору: явное указание this или его неявное подразумевание? Один фиг это косвенное обращение через указатель. Ему должно быть одинаково.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Код: . . .

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 ?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если не ошибаюсь, то локальные методы/поля имеют приоритет над глобальными методами (функциями)/переменными.

Другими словами: чем уже область видимости, тем больше преимущество (если тут можно применить такой термин).

Речь про одинаковые названия.

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

Поскольку найти потом подобные ошибки будет крайне сложно!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если не ошибаюсь, то локальные методы/поля имеют приоритет над глобальными методами (функциями)/переменными.

Другими словами: чем уже область видимости, тем больше преимущество (если тут можно применить такой термин).

Очень опасно сиё. Ибо достаточно потом чуток изменить список аргументов вызова член-метода и забыть в одном из вызовов поправить этот список. И получить неожиданный эффект :biggrin:

Стараюсь не делать глобальных функций и член-методов с одинаковыми именами без реальной необходимости.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Очень опасно сиё.

А я с этим и не спорю. И потому нигде не применяю.

 

Стараюсь не делать глобальных функций и член-методов с одинаковыми именами без реальной необходимости.

А я вообще не использую ничего глобального. Одна из причин - как раз именно эта путаница в именах и никому не нужные сложности с именованием.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...