C++ что значит префикс m в начале приватного члена класса?

member

just google it: https://stackoverflow.com/questions/13018189/what-does-m-variable-prefix-mean

https://en.wikipedia.org/wiki/Hungarian_notation

TL;DR - member

Я с _ приватные члены класса называю…

А надо заканчивать.

Венгерская нотация! Я догадывался что не так все просто.

А надо заканчивать.

Так тоже некоторые пишут, да.

Я с _ приватные члены класса называю…

Некрасиво.

member/my

Ещё есть любители для foo(int t_bar, int t_baz) от the

Я с _ приватные члены класса называю…

Сначала писал m_, потом перешёл на _.

По аналогии с Python/JavaScript же. Там это вообще на уровне конвенций и инкапсуляция не обеспечивается. Всяко лучше ископаемой венгерской нотации, о которой только индусы ещё помнят.

Там это вообще на уровне конвенций и инкапсуляция не обеспечивается.

https://habrastorage.org/webt/lt/a4/ev/lta4evi8bfzmv_sfcyeh1hfsyt4.jpeg

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

Спорно. Эти повисшие __ в начале строк довольно ущербно смотрятся и мылят глаза.

Вот лучше вообще ничего не писать (подсветка рулит), или уж если хочется то m.

К этому привыкаешь, в дарте тоже, чтобы член был приватным, нужно _ в начале писать, и это на уровне языка сделано. Мне по началу не нравилось, а сейчас уже не обращаю внимания и уже привык к этому.

Да, программист ко всему привыкает, с этим не спорю. Просто чисто эстетически не нравятся эти мелькающие _ везде. Вкусовщина. В Scala вроде так же, вместо * сделали _.

а кроме m чтоб не мелькало? сам то как пишешь?

гдето я слышал краем уха что и одно и два подчеркивания в префиксе зарезервированы толи на уровне языка толи конпилятора...

Зарезервировано подчёркивание и следующая за ним заглавная буква. Я пишу со строчной.

сам то как пишешь?

Не пишу m или _.

В Qt Creator, IDEA и MS Visual Studio подсвечиваются поля классов.

не нравятся эти мелькающие _ везде

Зато сразу видно что это: член класса или локальная переменная метода. Для меня так проще различать, чем через цвет.

И кстати да, если это С/С++ оно может конфликтовать с кучей предопределённых дефайнов в стандартных библиотеках и фреймворках. И насколько я помнимаю, namespace’ы тут даже не разрулят. Если оно там где-то через #define, а не const.

Нет.

Компилятор и стандартная библиотека могут использовать

_Meow или __meow

_meow можно использовать свободно в своём коде и это гарантировано стандартом.

В clang-tidy есть такая проверка: https://gcc.godbolt.org/z/edYYs6

Шланг шлангом. А что насчёт стандарта то? Тут эту хрень уже обсуждали, но я не помню чем закончилось. Это точно что «_[a-z]» в префиксе ни с чем не конфликтует? Кинься пруфцом, плиз.

Ну, тоже аргумент. Но у меня как-то так выходит что редакторов пользую несколько. Так, один светит, другой нет, третий вообще ничего не светит. Вот, приходится обозначать не цветом, а символами. А еще у меня со времен пхп 4 тоже привычка сидит, там не было тогда понятия паблик приват протектед, все были публичными и вот подчеркиванием и обозначалось «не трожь! это приватная!».

Зарезервировано подчёркивание и следующая за ним заглавная буква. Я пишу со строчной.

А если поле класса – статическое и константное? Для однородности требуется что-то вроде _CONST_NAME использовать.

CONST_NAME будет тупо выбиваться из стиля, а _const_name выглядеть несуразно.

_meow можно использовать свободно в своём коде и это гарантировано стандартом.

Можно мне тоже цитатку из стандарта? Спасибо.

Компилятор и стандартная библиотека могут использовать _Meow или __meow

Подобный нейминг со всеми вот этими мелкими нюансами и визуальным засорением кода кучей подчеркиваний имеет множество «cons», но довольно мало «pros».

Я лишь одно преимущество могу отметить – в редакторе без семантической подсветки кода префикс _ действительно хорошо помогает отличать классовые поля.

https://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier

Конечно, цитаты из стандарта не гарантируют доступность _[a-z], только заявляют о резервировании подобных имён в глобальном пространстве имён.

_meow можно использовать свободно в своём коде и это гарантировано стандартом.

Спасибо за инфу. А то я тоже суффикс _ юзал.

а константы они public, а не private. Так как они константы и их никто не может изменить, нет смысла делать их private…

deep-purple

http://eel.is/c++draft/lex.name#3

In addition, some identifiers are reserved for use by C++ implementations and shall not be used otherwise; no diagnostic is required.

Each identifier that contains a double underscore __ or begins with an underscore followed by an uppercase letter is reserved to the implementation for any use.

Each identifier that begins with an underscore is reserved to the implementation for use as a name in the global namespace.

Кстати, clang-tidy это отслеживает: https://gcc.godbolt.org/z/1WcWWe (ругается на _bad как глобальную переменную)

Статические и константные поля я никак не выделяю.

member

Понятно, что это удобно при использовании IDE

Нормальная IDE умеет раскрашивать код и рисовать условные символы (замочки и т.д.) в автодополнении, например.

иде, к сожалению, в 99% не является частью языка и его стандартов. все что она умеет - заслуга сторонних васянов.

это LPSZ ересь.

а константы они public, а не private. Так как они константы и их никто не может изменить, нет смысла делать их private…

Новое слово в инкапсуляции.

Новое слово в инкапсуляции.

Много тебе ещё учить теории, если для тебя это новое слово. Ну ничего, все когда-то были недоразвитыми…

Я предпочитаю практику. А на практике – если константа касается деталей реализации, то и нефиг засорять ею публичное API. А недоразвитыми на практике обычно оказываются как раз теоретики.

То-то лучше, когда язык прибит гвоздями к IDE? Сгинь, жопа очкастая!!! ;)

https://habrastorage.org/webt/lt/a4/ev/lta4evi8bfzmv_sfcyeh1hfsyt4.jpeg

И что не так? Вам знакома атмосфера деревенской жизни? ;) Возводимой некоторыми в аксиому приватности (почти) никакой, зато полное доверие.

ущербно смотрятся

Тут уже вкусовщина начинается, можно и до того докатиться, что длинные слова вместо одного символа, как в APL, ущербно смотрятся.

мылят глаза

Чините глаза.

Чо ты выперся то кудахтать? Лучшие умы чоловечества с конпеляторами разобраться не могут — в том конпеляется а в этом нет. До ИДЕ ещё срать и срать.

В шарпе тоже решили названия приватных полей начинать с _, хотя с инкапсуляцией проблем там никаких нет

Да это вкусовщина. Выше я об этом написал.

Считаю, что код с кучей _ выглядит как говно.

А почему компилятороспецифичные штуки должны везде компиляться? ;)

а почему иде спецефичные штуки должны везде идешиться?

Это костыль для C++ чтобы вместо this->field писать mField. Вариант писать field напрямую имеет высокий риск коллизий с глобальными переменными, аргументами и локальными переменными. В Обероне и Go хорошо решена эта проблема:

PROCEDURE (a: Alien) Restore* (f: Frame; l, t, r, b: INTEGER);
	VAR u, w, h: INTEGER;
BEGIN
	u := f.dot; a.context.GetSize(w, h);
	f.DrawRect(0, 0, w, h, Ports.fill, Ports.grey25);
	f.DrawRect(0, 0, w, h, 2 * u, Ports.grey75);
	f.DrawLine(0, 0, w - u, h - u, u, Ports.grey75);
	f.DrawLine(w - u, 0, 0, h - u, u, Ports.grey75)
END Restore;

func (v Vertex) Abs() float64 {
	return math.Sqrt(v.X*v.X + v.Y*v.Y)
}

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

В Ruby/CoffeeScript ещё лучше: вместо this. тупо @.

прибить что-то гвоздями к IDE невозможно

Зато ИДЕ уже поприбивали к каким-то проектам на на каких-то ЯП. Так поприбивали, что тут довольно часто проскакивают комментаторы вида «возьми ИДЕ, а не редактор, иначе в говнокоде не разберёшься».

Ну так тут всё упирается во время ;)

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

Так это в начале имени. А принято еще ставить _ в конце имени.

Это не костыль, а удобный стиль. Никаких коллизий не будет, если понимаешь механизм работы области видимости. Если ты в классе будешь использовать некоторое имя, совпадающее с именем глобальной переменной и с именем члена класса, то естественно по умолчанию будет использоваться член класса и никакой коллизии не будет. Или если в функции-члене объявлена локальная переменная с таким же именем, что и член, то по умолчанию будет использована она и никакой коллизии. С другой стороны ты всегда волен обратиться к переменным, которые по умолчанию скрыты. Суффиксы и префиксы нужны для само-документирования кода, когда тебе сразу ясно, что перед тобой член класса. С одной стороны с современными IDE и подсветкой переменных-членов, суффиксы и префиксы превратились просто в необязательный стиль, но с другой, иногда ведь код читаешь не только в IDE, а например в какой-нибудь документации или в мини руководстве в формате Markdown, где по подсветке ты не можешь сказать, член (member) это или нет и тогда уже эти элементы имени дают +5 к читаемости кода.

Это костыль для C++ чтобы вместо this->field писать mField

О! И оно реально сначала ищет в локале, затем в глобале и только потом у тхиса? (негде щас проверить)

Блин. Ну это же совсем база. Сначала в локальной области видимости, потом в области видимости класса (если конечно в текущий момент выполняется функция-член), потом в глобальной.