Извините, ничего не найдено.

Samodelkin · 01.02.2015, 21:52

Как вы думаете, насколько читабельно будет явное обращение к данным класса через указатель this?

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

Однако некоторое время назад потребовалось писать более data-oriented код. Такой подход подразумевает в том числе написание кода с наименьшим количеством возможных кеш-промахов при его выполнении. В частности, в случае объектов С++, данные объекта класса и данные на стеке вызванного метода этого же класса, находятся в разных местах и хаотичное обращение то к тем то к другим будет вызывать медленную работу программы. Таким образом, если не удается полностью разместить данные на стеке (и сделать метод static) я стараюсь хотябы более организованно обращаться в переменным. Вот тут-то я и подумал что явное использование this (с его подсветкой) может помочь лучше визуально разделять переменные двух этих категорий.

Остается только вопрос читабельности, вдруг другим программистам это непонравится. Какое ваше мнение?

impersonalis · 01.02.2015, 21:58

Привык писать this всегда, где есть обращение к полям класса.
1) Не мешает.
2) Снимает паранойю потенциального закрытия одноимённой локальной переменной поля класса.
2.1) Я так утомился от хак-стиля чужих кодов и статей, что стараюсь не уменьшать формализм, если его отсутствие может внести сумятицу и неоднозначность.
3) Удобно - IDE сразу после ввода this-> выводит список доступных вариантов.

moka · 01.02.2015, 22:12

Я считаю явное обозначение источника переменной - хороший элемент для ясности кода.
Читаешь и сразу ясно с чем имеешь дело.

Чем меньше программисту нужно прыгать по строкам чтобы обосновать выражение - тем лучше.

Mr_F_ · 01.02.2015, 22:26

я б не писал.
больше букв - плохо.

moka · 01.02.2015, 22:36

Сообщение от Mr_F_

я б не писал.
больше букв - плохо.

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

mr.DIMAS · 01.02.2015, 22:45

mFoo
mBar

this->foo
this->bar

С this слишком толсто получается, поэтому простые префиксы m (но не блядский m_ ).

http://stackoverflow.com/questions/1...s-in-c-classes

Второй ответ мне очень понравился, сейчас юзаю его.

Igor · 01.02.2015, 23:52

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

Можешь ткнуть носом в статью, где это подробно написано?
Я всегда считал, в большинстве случаев данные класса и данные на стеке будут находиться в разных линиях кеша, и не важно, сделаю я чтение из "АБАБАБ" или "АББААБ" (пусть А - обращение к this, а Б - к переменным метода)
P.S. предпочитаю писать маленькие простые классы с сокрытием всего, что можно. В них трудно напутать с переменными, this только там, где необходимо.
P.P.S. И методы тоже маленькие - не больше, чем на один экран.

Samodelkin · 01.02.2015, 23:59

Сообщение от Igor

Можешь ткнуть носом в статью, где это подробно написано?
Я всегда считал, в большинстве случаев данные класса и данные на стеке будут находиться в разных линиях кеша, и не важно, сделаю я чтение из "АБАБАБ" или "АБББАА" (пусть А - обращение к this, а Б - к переменным метода)
P.S. предпочитаю писать маленькие простые классы с сокрытием всего, что можно. В них трудно напутать с переменными, this пишу только там, где необходимо.

Ох. Сейчас я попробую найти, но нужно время.
Но переключение кеш-линий также занимает много времени. Рекомендуют данные паковать в 1 кеш линию, в 64 байта.

Igor · 02.02.2015, 00:07

Кстати, вдогонку (рассказывали на лекциях, сам не проверял): на x86 аргументы функции передаются через стек, а на x64 с помощью регистров. Если регистров не хватит (а их вроде раза в 2 больше стало, теперь 16), то непоместившееся по-старинке через стек.
Возможно, локальные переменные небольших методов в стеке вообще не окажутся, и компиляция под x64 ускорит выполнение

Samodelkin · 02.02.2015, 00:27

Сообщение от Igor

Кстати, вдогонку (рассказывали на лекциях, сам не проверял): на x86 аргументы функции передаются через стек, а на x64 с помощью регистров. Если регистров не хватит (а их вроде раза в 2 больше стало, теперь 16), то непоместившееся по-старинке через стек.
Возможно, локальные переменные небольших методов в стеке вообще не окажутся, и компиляция под x64 ускорит выполнение

Хороший вопрос.
Насчёт поведения х64 по умолчанию я незнаю -- это надо выяснить и проверить, но для х86 можно выбирать как передавать с помощью соглашения о вызовах.
По умолчанию в с++ thiscall, а в с cdecl. WinAPI используют stdcall. Но компилятору можно сообщить явно что использовать. Например fastcall передает первые два параметра через регистры. Таким образом можно сократить на вызовах коротких мат-функций (в том числе интринсик), типа сложения, там где настройка стека занимает много времени относительно выполнения самой функции. Но в компиляторе помимо соглашения вызова ещё нужно установить параметр отмены настройки стека, т. к. он ненужен если параметров два и меньше.

Вот нашёл про кеш-линии:
http://www.slideshare.net/cellperfor...d-design-and-c
Начиная с 90 слайда показан конкретный пример.

Samodelkin · 03.02.2015, 23:33

Ну чтож, на первый взгляд мнения разделились примерно пополам. Однако все кто говорил за НЕ_использование this-> не имели ввиду никак не маркировать имена переменных, а просто делать это более коротким способом. Таким образом можно сказать что писать имена переменных без маркировки впринципе плохо.

Вообще моё мнение: читабельность кода это не всегда значит более короткая запись. Конструкции языка не позволяют полностью передать смысл кода, поэтому часть смысла может передаваться ввиде правильных имен переменных и методов (это лучше чем писать комментарии). Таким образом слишком короткие имена переменных не смогут полностью раскрыть их смысл и читабельность кода станет ниже. Конечно и обратное верно -- читать строки не умещающиеся в 1920 пикселах тоже неприятно.

Высказываение что "меньше символов быстрее печатаются" я считаю вообще не имеет основания: программист в среднем читает код в 10 раз больше чем пишет, особенно это касается отладки, сопровождения и т. д., не говоря уже о том что в случае open source читать его будет много других людей. Писабельность и читабельность часто можно улучшить одновременно, но когда улучшается писабельность в ущерб читабельности это очень плохо.

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

В общем выбрать какой стиль лучше подходит для большинства программистов видимо задача очень сложная, поэтому я выберу его хотябы для себя. Выбирать по всей видимости надо между this-> и тем что предложено mr.DIMAS'ом (такой вариант я вообще часто вижу в других кодах).

* Сейчас я пользуюсь vim'ом поэтому профита от автодополнения в случае использования this-> в IDE у меня не будет.
* Сам я привык писать короче, а значит использование префиксов для меня более предпочтительно.
* Совсем необязательно использовать сразу все предложенные префиксы, можно например их вводить по мере необходимости (вот от венгерской нотации я отказался как раз из-за слишком длинных префиксов, но тот пост на stack overflow предлагает более короткий и гибкий вариант, работающий в условиях более современного С++, а не С).

* this подсвечивается, что хорошо.
* this явно есть только в С++, но если я возьму за правило писать префиксы, то по привычке буду делать это и в С, а там в частности от префикса m нет смысла.
* data-oriented подход в С++ также часто требует передавать данные через стек используя структуры, а значит префиксы m также как в С будут излишне. Подходить избирательно к каждому классу/структуре чурезчур заумно.

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

Жека · 05.02.2015, 05:35

Всё обсуждение одинаково справедливо и для java, там тоже есть this.

Ясное дело, что стиль кода каждый сам выбирает (ещё обсуждали расстановку фигурных скобок), и это нормально когда люди пробуют писать и так и сяк.

Я использую this обычно в функциях для присвоения параметров. Более редко где требуется.

Префиксы не использую.

Netbeans IDE например на полях ставит маркер "локальная переменная скрывает поле класса", это помогает избежать большинство потенциальных неувязок логики.

В книжках реально много авторов юзают стиль mVariable.

Еще я всегда замечаю, что мой стиль меняется на разных языках. Обычно пишу в стиле newValue. Но как дело доходит до php, то очень трудно удержаться от new_value.