Явное использование this.
Как вы думаете, насколько читабельно будет явное обращение к данным класса через указатель this?
Раньше я всегда придерживался более минималистичного стиля написания кода и опускал явный this за исключением там где он был необходим. Однако некоторое время назад потребовалось писать более data-oriented код. Такой подход подразумевает в том числе написание кода с наименьшим количеством возможных кеш-промахов при его выполнении. В частности, в случае объектов С++, данные объекта класса и данные на стеке вызванного метода этого же класса, находятся в разных местах и хаотичное обращение то к тем то к другим будет вызывать медленную работу программы. Таким образом, если не удается полностью разместить данные на стеке (и сделать метод static) я стараюсь хотябы более организованно обращаться в переменным. Вот тут-то я и подумал что явное использование this (с его подсветкой) может помочь лучше визуально разделять переменные двух этих категорий. Остается только вопрос читабельности, вдруг другим программистам это непонравится. Какое ваше мнение? |
Ответ: Явное использование this.
Привык писать this всегда, где есть обращение к полям класса.
1) Не мешает. 2) Снимает паранойю потенциального закрытия одноимённой локальной переменной поля класса. 2.1) Я так утомился от хак-стиля чужих кодов и статей, что стараюсь не уменьшать формализм, если его отсутствие может внести сумятицу и неоднозначность. 3) Удобно - IDE сразу после ввода this-> выводит список доступных вариантов. |
Ответ: Явное использование this.
Я считаю явное обозначение источника переменной - хороший элемент для ясности кода.
Читаешь и сразу ясно с чем имеешь дело. Чем меньше программисту нужно прыгать по строкам чтобы обосновать выражение - тем лучше. |
Ответ: Явное использование this.
я б не писал.
больше букв - плохо. |
Ответ: Явное использование this.
Цитата:
|
Ответ: Явное использование this.
mFoo
mBar this->foo this->bar С this слишком толсто получается, поэтому простые префиксы m (но не блядский m_ ). http://stackoverflow.com/questions/1...s-in-c-classes Второй ответ мне очень понравился, сейчас юзаю его. |
Ответ: Явное использование this.
Цитата:
Я всегда считал, в большинстве случаев данные класса и данные на стеке будут находиться в разных линиях кеша, и не важно, сделаю я чтение из "АБАБАБ" или "АББААБ" (пусть А - обращение к this, а Б - к переменным метода) P.S. предпочитаю писать маленькие простые классы с сокрытием всего, что можно. В них трудно напутать с переменными, this только там, где необходимо. P.P.S. И методы тоже маленькие - не больше, чем на один экран. |
Ответ: Явное использование this.
Цитата:
Но переключение кеш-линий также занимает много времени. Рекомендуют данные паковать в 1 кеш линию, в 64 байта. |
Ответ: Явное использование this.
Кстати, вдогонку (рассказывали на лекциях, сам не проверял): на x86 аргументы функции передаются через стек, а на x64 с помощью регистров. Если регистров не хватит (а их вроде раза в 2 больше стало, теперь 16), то непоместившееся по-старинке через стек.
Возможно, локальные переменные небольших методов в стеке вообще не окажутся, и компиляция под x64 ускорит выполнение :) |
Ответ: Явное использование this.
Цитата:
Насчёт поведения х64 по умолчанию я незнаю -- это надо выяснить и проверить, но для х86 можно выбирать как передавать с помощью соглашения о вызовах. По умолчанию в с++ thiscall, а в с cdecl. WinAPI используют stdcall. Но компилятору можно сообщить явно что использовать. Например fastcall передает первые два параметра через регистры. Таким образом можно сократить на вызовах коротких мат-функций (в том числе интринсик), типа сложения, там где настройка стека занимает много времени относительно выполнения самой функции. Но в компиляторе помимо соглашения вызова ещё нужно установить параметр отмены настройки стека, т. к. он ненужен если параметров два и меньше. Вот нашёл про кеш-линии: http://www.slideshare.net/cellperfor...d-design-and-c Начиная с 90 слайда показан конкретный пример. |
Ответ: Явное использование this.
Ну чтож, на первый взгляд мнения разделились примерно пополам. Однако все кто говорил за НЕ_использование this-> не имели ввиду никак не маркировать имена переменных, а просто делать это более коротким способом. Таким образом можно сказать что писать имена переменных без маркировки впринципе плохо.
Вообще моё мнение: читабельность кода это не всегда значит более короткая запись. Конструкции языка не позволяют полностью передать смысл кода, поэтому часть смысла может передаваться ввиде правильных имен переменных и методов (это лучше чем писать комментарии). Таким образом слишком короткие имена переменных не смогут полностью раскрыть их смысл и читабельность кода станет ниже. Конечно и обратное верно -- читать строки не умещающиеся в 1920 пикселах тоже неприятно. Высказываение что "меньше символов быстрее печатаются" я считаю вообще не имеет основания: программист в среднем читает код в 10 раз больше чем пишет, особенно это касается отладки, сопровождения и т. д., не говоря уже о том что в случае open source читать его будет много других людей. Писабельность и читабельность часто можно улучшить одновременно, но когда улучшается писабельность в ущерб читабельности это очень плохо. В случае this ещё плохо то что это никак не влияет на поведение компилятора. Например в случае квалификатора типа const это даёт реальное преимущество, т. к. компилятор лучше понимает код и помогает отлаживать и предотвращать ошибки программиста и двусмысленное понимание кода. this же здесь может помочь разве только в случае синтаксической ошибки, когда случайно происходит перекрытие мембера параметром функции, или что-то того, но в целом на семантику кода это не влияет. Вполне возможно что принудительное использование this стандартом языка сделало бы код более надёжным, а разработку компиляторов менее сложным. В общем выбрать какой стиль лучше подходит для большинства программистов видимо задача очень сложная, поэтому я выберу его хотябы для себя. Выбирать по всей видимости надо между this-> и тем что предложено mr.DIMAS'ом (такой вариант я вообще часто вижу в других кодах). * Сейчас я пользуюсь vim'ом поэтому профита от автодополнения в случае использования this-> в IDE у меня не будет. * Сам я привык писать короче, а значит использование префиксов для меня более предпочтительно. * Совсем необязательно использовать сразу все предложенные префиксы, можно например их вводить по мере необходимости (вот от венгерской нотации я отказался как раз из-за слишком длинных префиксов, но тот пост на stack overflow предлагает более короткий и гибкий вариант, работающий в условиях более современного С++, а не С). * this подсвечивается, что хорошо. * this явно есть только в С++, но если я возьму за правило писать префиксы, то по привычке буду делать это и в С, а там в частности от префикса m нет смысла. * data-oriented подход в С++ также часто требует передавать данные через стек используя структуры, а значит префиксы m также как в С будут излишне. Подходить избирательно к каждому классу/структуре чурезчур заумно. Так что даже мне однозначно выбрать трудно, возможно даже стоит попробовать два подхода, но пока я остановлюсь на частичном использовании префиксов. |
Ответ: Явное использование this.
Всё обсуждение одинаково справедливо и для java, там тоже есть this.
Ясное дело, что стиль кода каждый сам выбирает (ещё обсуждали расстановку фигурных скобок), и это нормально когда люди пробуют писать и так и сяк. Я использую this обычно в функциях для присвоения параметров. Более редко где требуется. Префиксы не использую. Netbeans IDE например на полях ставит маркер "локальная переменная скрывает поле класса", это помогает избежать большинство потенциальных неувязок логики. В книжках реально много авторов юзают стиль mVariable. Еще я всегда замечаю, что мой стиль меняется на разных языках. Обычно пишу в стиле newValue. Но как дело доходит до php, то очень трудно удержаться от new_value. :) |
Часовой пояс GMT +4, время: 19:27. |
vBulletin® Version 3.6.5.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot