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

Не расстраивайся! Лучше выпей чайку!
Регистрация
Справка
Календарь

Вернуться   forum.boolean.name > Программирование игр для компьютеров > C++

Ответ
 
Опции темы
Старый 01.02.2015, 21:52   #1
Samodelkin
Мастер
 
Регистрация: 12.01.2009
Сообщений: 979
Написано 388 полезных сообщений
(для 631 пользователей)
Явное использование this.

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

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

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

Остается только вопрос читабельности, вдруг другим программистам это непонравится. Какое ваше мнение?
(Offline)
 
Ответить с цитированием
Старый 01.02.2015, 21:58   #2
impersonalis
Зануда с интернетом
 
Аватар для impersonalis
 
Регистрация: 04.09.2005
Сообщений: 14,014
Написано 6,798 полезных сообщений
(для 20,935 пользователей)
Ответ: Явное использование this.

Привык писать this всегда, где есть обращение к полям класса.
1) Не мешает.
2) Снимает паранойю потенциального закрытия одноимённой локальной переменной поля класса.
2.1) Я так утомился от хак-стиля чужих кодов и статей, что стараюсь не уменьшать формализм, если его отсутствие может внести сумятицу и неоднозначность.
3) Удобно - IDE сразу после ввода this-> выводит список доступных вариантов.
__________________
http://nabatchikov.com
Мир нужно делать лучше и чище. Иначе, зачем мы живем? tormoz
А я растила сына на преданьях
о принцах, троллях, потайных свиданьях,
погонях, похищениях невест.
Да кто же знал, что сказка душу съест?
(Offline)
 
Ответить с цитированием
Эти 2 пользователя(ей) сказали Спасибо impersonalis за это полезное сообщение:
Randomize (02.02.2015), Samodelkin (01.02.2015)
Старый 01.02.2015, 22:12   #3
moka
.
 
Регистрация: 05.08.2006
Сообщений: 10,429
Написано 3,454 полезных сообщений
(для 6,863 пользователей)
Ответ: Явное использование this.

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

Чем меньше программисту нужно прыгать по строкам чтобы обосновать выражение - тем лучше.
(Offline)
 
Ответить с цитированием
Сообщение было полезно следующим пользователям:
Samodelkin (01.02.2015)
Старый 01.02.2015, 22:26   #4
Mr_F_
Терабайт исходников
 
Аватар для Mr_F_
 
Регистрация: 13.09.2008
Сообщений: 3,947
Написано 2,189 полезных сообщений
(для 6,051 пользователей)
Ответ: Явное использование this.

я б не писал.
больше букв - плохо.
__________________
бложик | geom.io | твиттер | faded | демо 1 2 | роботы | лайтмаппер
(Offline)
 
Ответить с цитированием
Эти 3 пользователя(ей) сказали Спасибо Mr_F_ за это полезное сообщение:
h1dd3n (02.02.2015), mr.DIMAS (01.02.2015), Samodelkin (01.02.2015)
Старый 01.02.2015, 22:36   #5
moka
.
 
Регистрация: 05.08.2006
Сообщений: 10,429
Написано 3,454 полезных сообщений
(для 6,863 пользователей)
Ответ: Явное использование this.

Сообщение от Mr_F_ Посмотреть сообщение
я б не писал.
больше букв - плохо.
Но тогда тому кто читает нужно будет бегать по структуре кода чтобы определить что это за переменная..
(Offline)
 
Ответить с цитированием
Старый 01.02.2015, 22:45   #6
mr.DIMAS
Дэвелопер
 
Аватар для mr.DIMAS
 
Регистрация: 26.12.2006
Адрес: Санкт-Петербург
Сообщений: 1,572
Написано 547 полезных сообщений
(для 1,540 пользователей)
Ответ: Явное использование this.

mFoo
mBar

this->foo
this->bar

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

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

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

(Offline)
 
Ответить с цитированием
Сообщение было полезно следующим пользователям:
Samodelkin (01.02.2015)
Старый 01.02.2015, 23:52   #7
Igor
Мастер
 
Аватар для Igor
 
Регистрация: 03.05.2010
Адрес: Подмосковье
Сообщений: 1,218
Написано 438 полезных сообщений
(для 790 пользователей)
Ответ: Явное использование this.

данные объекта класса и данные на стеке вызванного метода этого же класса, находятся в разных местах и хаотичное обращение то к тем то к другим будет вызывать медленную работу программы.
Можешь ткнуть носом в статью, где это подробно написано?
Я всегда считал, в большинстве случаев данные класса и данные на стеке будут находиться в разных линиях кеша, и не важно, сделаю я чтение из "АБАБАБ" или "АББААБ" (пусть А - обращение к this, а Б - к переменным метода)
P.S. предпочитаю писать маленькие простые классы с сокрытием всего, что можно. В них трудно напутать с переменными, this только там, где необходимо.
P.P.S. И методы тоже маленькие - не больше, чем на один экран.
__________________
О¯О ¡¡¡ʁɔvʎнdǝʚǝdǝu dиW
(Offline)
 
Ответить с цитированием
Сообщение было полезно следующим пользователям:
Samodelkin (01.02.2015)
Старый 01.02.2015, 23:59   #8
Samodelkin
Мастер
 
Регистрация: 12.01.2009
Сообщений: 979
Написано 388 полезных сообщений
(для 631 пользователей)
Ответ: Явное использование this.

Сообщение от Igor Посмотреть сообщение
Можешь ткнуть носом в статью, где это подробно написано?
Я всегда считал, в большинстве случаев данные класса и данные на стеке будут находиться в разных линиях кеша, и не важно, сделаю я чтение из "АБАБАБ" или "АБББАА" (пусть А - обращение к this, а Б - к переменным метода)
P.S. предпочитаю писать маленькие простые классы с сокрытием всего, что можно. В них трудно напутать с переменными, this пишу только там, где необходимо.
Ох. Сейчас я попробую найти, но нужно время.
Но переключение кеш-линий также занимает много времени. Рекомендуют данные паковать в 1 кеш линию, в 64 байта.
(Offline)
 
Ответить с цитированием
Старый 02.02.2015, 00:07   #9
Igor
Мастер
 
Аватар для Igor
 
Регистрация: 03.05.2010
Адрес: Подмосковье
Сообщений: 1,218
Написано 438 полезных сообщений
(для 790 пользователей)
Ответ: Явное использование this.

Кстати, вдогонку (рассказывали на лекциях, сам не проверял): на x86 аргументы функции передаются через стек, а на x64 с помощью регистров. Если регистров не хватит (а их вроде раза в 2 больше стало, теперь 16), то непоместившееся по-старинке через стек.
Возможно, локальные переменные небольших методов в стеке вообще не окажутся, и компиляция под x64 ускорит выполнение
__________________
О¯О ¡¡¡ʁɔvʎнdǝʚǝdǝu dиW
(Offline)
 
Ответить с цитированием
Сообщение было полезно следующим пользователям:
Samodelkin (02.02.2015)
Старый 02.02.2015, 00:27   #10
Samodelkin
Мастер
 
Регистрация: 12.01.2009
Сообщений: 979
Написано 388 полезных сообщений
(для 631 пользователей)
Ответ: Явное использование this.

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

Вот нашёл про кеш-линии:
http://www.slideshare.net/cellperfor...d-design-and-c
Начиная с 90 слайда показан конкретный пример.
(Offline)
 
Ответить с цитированием
Эти 2 пользователя(ей) сказали Спасибо Samodelkin за это полезное сообщение:
Igor (02.02.2015), St_AnGer (02.02.2015)
Старый 03.02.2015, 23:33   #11
Samodelkin
Мастер
 
Регистрация: 12.01.2009
Сообщений: 979
Написано 388 полезных сообщений
(для 631 пользователей)
Ответ: Явное использование this.

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

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

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

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

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

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

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

Так что даже мне однозначно выбрать трудно, возможно даже стоит попробовать два подхода, но пока я остановлюсь на частичном использовании префиксов.
(Offline)
 
Ответить с цитированием
Старый 05.02.2015, 05:35   #12
Жека
Дэвелопер
 
Регистрация: 04.09.2005
Адрес: Красноярск
Сообщений: 1,376
Написано 491 полезных сообщений
(для 886 пользователей)
Ответ: Явное использование this.

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

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

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

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

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

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

Еще я всегда замечаю, что мой стиль меняется на разных языках. Обычно пишу в стиле newValue. Но как дело доходит до php, то очень трудно удержаться от new_value.
(Offline)
 
Ответить с цитированием
Эти 2 пользователя(ей) сказали Спасибо Жека за это полезное сообщение:
impersonalis (05.02.2015), Samodelkin (05.02.2015)
Ответ


Опции темы

Ваши права в разделе
Вы не можете создавать темы
Вы не можете отвечать на сообщения
Вы не можете прикреплять файлы
Вы не можете редактировать сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


Часовой пояс GMT +4, время: 16:15.


vBulletin® Version 3.6.5.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot
Style crйe par Allan - vBulletin-Ressources.com