Почему имя параметра может совпадать с именем члена класса?

Question

[Вова]

Всем привет!
Часто вижу код следующего вида:

struct MyStruct {
  MyStruct(QString name, Qt::SortOrder order)
    : name(std::move(name)), order(order) {}

  QString name;
}

И в этом коде имя параметра (name) совпадает с именем поля (name).
Вопрос: как это вообще работает? Как плюсы понимают, что с одной стороны параметр, а с другой - член класса?
Что-то я так и не смог вспомнить, какой хотя бы раздел учебника по плюсам мне стоит освежить :(

Comments

[Dmitrii]

https://stackoverflow.com/questions/268587/can-i-u...

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

int a;
{
    int a;
}

Насколько я понимаю, компилятор решает эти "проблемы" одинаково, пытаясь найти на локальном уровне переменную с соответствующими именем, а затем переходе по скоупу выше (лишь предположение о том как работает данный алгоритм)

[Adamos]

Но делать так в принципе не стоит, потому что это ухудшает читаемость кода и может послужить причиной проблем, если вам понадобится переместить инициализацию члена из списка над конструктором в его тело.
Тогда фокус не пройдет, и вам все равно нужно будет переименовывать аргумент.
Вообще,в Крестах слишком легко перепутать члены класса с другими переменными, и им не зря любят добавлять префиксы типа m или _. Самому же легче читать и отлаживать потом... Ну, и вот такие вопросы снимаются автоматически.

[Вова]

Dmitrii, Ага, понятно. Стековерфлоу - это здорово!

Пасиб!

[res2001]

В данном примере в списке инициализации могут присутствовать только члены класса, так что первый name - это однозначно член класса.
Параметр name перекрывает видимость члена класса name, поэтому во втором случае используется параметр name.

[Евгений Шатунов]

Adamos, все верно. Но, справедливости ради, при одинаковых именах параметра и поля можно обратиться к имени поля и из тела метода. Для этого достаточно квалифицировать имя.
MyStruct::name = name; из примера автора. И это является качественным примером, т.к. переключение между UNL и QNL является одним из приемов качественного кода. Не в случае кода у автора, но в огромном наборе других случаев.

[Adamos]

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

[Евгений Шатунов]

Adamos, видимо, очевидно и затрудняют такие примеры тоже по высосанным из пальца принципам? :)

[Adamos]

Евгений Шатунов, да ладно. Когда в коде две переменных с одним и тем же именем - программист при чтении кода просто обязан напрячься и задуматься, которая имеется в виду. Иначе он хреновый программист.
И это никак не зависит от того, насколько аккуратно и грамотно они разведены уточнениями.
Потому что отладка, занимающая больше времени, чем собственно написание кода, приучает к тому, что если написано просто name и есть варианты, которая name тут имеется в виду - то предполагать один из вариантов, даже со стопроцентной уверенностью, не стоит. Стоит проверить.
И на хрена создавать эти сложности на ровном месте, когда можно просто иначе назвать параметр и больше ни разу об это место не спотыкаться?

[Евгений Шатунов]

Adamos, если написано просто name и есть варианты, которая name тут имеется в виду - то предполагать один из вариантов, даже со стопроцентной уверенностью, не стоит.
Стоит знать стандарт. Предполагать, гадать на кофейной гуще, проверять выдачу у транслятора конкретной платформы - это все одно и то же.

Не знаешь стандарт? Гадать - это все что остается. Подчиненная позиция.
Ровно такие же проблемы ты получишь и на разных именах. Даже на полностью разных. Просто потому что не понимаешь поведения написанного тобой же кода в виду незнания стандарта.

[Adamos]

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

[Евгений Шатунов]

Adamos, да не. :) Реальность иная. О том и речь. Я и работаю с разными ребятами, и общаюсь тоже с разными. И ведь ты тоже работаешь на своей ключевой позиции и общаешься с самыми разными людьми.
У тебя есть даже свой богатый бекграунд для твоей позиции. И я ни разу не скажу что твои принципы могут быть надуманны или высосаны из пальца.

[Adamos]

Евгений Шатунов, не общаюсь я с людьми, работаю одиночкой.
Поэтому могу отстаивать позицию с горячностью неофита и гиперболизировать формулировки ;)

Answer 1

[Сергей Соловьев]

Как плюсы понимают, что с одной стороны параметр, а с другой - член класса?

Это называется семантический разбор. На вход компилятору подается исходный текст, на выходе - дерево выражений (очень грубо говоря).
Существуют правила, по которым эти деревья строятся. Например, БНФ.
Вот в них и описывается что и где может находиться. В данном случае, в списке инициализации могут находиться только члены класса, но ты передаешь еще и параметры. В этот момент компилятор сходит с ума, т.к. нарушаются эти правила .
P.S. чтобы подобных проблем не было, то для полей классов используй префикс подчеркивания

Comments

[Вова]

Эмммм...
Почему-то всегда думал, что результатом синтаксического разбора является дерево, в котором просто написано "это идентификатор со значением name, это присваивание, а это ещё один идентификатор со значением name".
Но за идею спасибо, пойду ещё раз голову дракона полистаю.
Вроде там что-то было про попытку отличить локальные переменные друг от друга. Может и про параметры где-то было, только я пропустил.

[Сергей Соловьев]

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

[Mikhail Osher]

Я вебдев, чуток баловался с плюсами в рамках изучения Unreal Engine. Там везде писали поля класса с префиксом m_, например m_Name. Быстрое гугление тогда же подсказало, что это чуть ли не универсальный стандарт объявления свойств класса среди разрабов на плюсах.

[Сергей Соловьев]

Mikhail Osher, это называется Венгерская нотация, и по хорошему считается сегодня дурным нотом - мало кто это использует, т.к. IDE и так дает подсказки. Но совет по поводу нижнего подчеркивания для приватных полей - актуален

[Mikhail Osher]

Сергей Соловьев, буду знать, спасибо!

[Вова]

Сергей Соловьев, В принципе, приватные поля могут по разному именоваться. В Borland C++ Builder использовалась буква F: FWidth (например). Хотя за те 15 лет, что я в билдер не заглядывал, могло что-то поменяться.

[Сергей Соловьев]

Вова, я и не говорил, что нижнее подчеркивание единственный правильный способ - каждый *** как хочет. Просто я использую такой подход, т.к. он наиболее производительный - сразу понятная разница и не надо много думать.
Насчет буквы F в Borland - не знал, но как по мне выглядит не очень, т.к. эта буква может мешать обнаружению/пониманию полей и логики. Но это на первый взгляд

Answer 2

[Mercury13]

Это НЕ синтаксический разбор, а семантика языка.
В большинстве случаев играет роль ближайший идентификатор. Но в инициализаторах снаружи скобок поле объекта (больше ничего там быть не может, только поле)

#include <iostream>

class Obj {
public:
    Obj(std::string x)
        : x(std::move(x))
        // 1. Поле, больше ничего быть не может
        // 2. Параметр, как ближайший идентификатор
    {
        std::cout << '[' << x << ']' << '\n';  // Параметр, как ближайший идентификатор
    }
private:
    std::string x;
};

int main()
{
    Obj obj("Habr");
    return 0;
}

Comments

[Вова]

Я не уверен, что это семантика.
Очень уж характерный вид вызова:
init -> id ( id )
Вполне можно разобрать синтаксическим анализатором.

[Mercury13]

Вова, За это синтаксический анализатор не отвечает. Он говорит, что инициализируем поле x выражением std::move(x) — а за то, существует ли поле x, по порядку ли и вправе ли мы его инициализировать, отвечает семантика.

[Mercury13]

Вова, На самом деле init → id initializer; initializer → { braced-initializer } | ( param-list ) — в общем, сложно. Я не уверен, что так оно в официальной бэкусовской форме. Да, у языка есть официальная бэкусовская форма, и потому разные реализации крайне редко лажают с синтаксисом, зато с семантикой вечно что-то не так.

[Вова]

Mercury13, "а за то, существует ли поле x, ....., отвечает семантика."
Возможно. Но уже на момент лексического анализа составляется таблица символов. И в синтаксический анализатор попадает, собственно, не "поле икс", а "некий идентификатор с номером 123 из таблицы символов". В какой момент идентификатор признаётся полем я не знаю. Скорее всего в тот момент, когда синтаксический анализатор накладывает структуру класса на входной поток токенов. Условно, синтаксический анализатор видит слова "class", ID, "{", ID (тип данных), ID... И где-то в этот момент понимает, что ID это какая-то переменная того типа, что стоит слева. Наверное где-то в этот же момент синтаксический анализатор может сообразить, что всё ещё идёт процесс разбора класса, и признать переменную полем.
Но я не настоящий сварщик, просто книжку пару раз прочитал ;))

[Mercury13]

Вова, Да, лексика, синтаксис и семантика работают условно-параллельно, но это разные слои разбора текста. Когда видим «class ID», мы объявляем: у нас недоопределённый класс ID, и мы без вопросов можем принимать типы вроде ID*.

Параллельная работа может идти вразрез с другими задачами: скажем, в моём примере поле x определено после конструктора. Это требует дополнительных телодвижений от компилятора — отложить семантический анализ или его часть. Зато упрощает жизнь программисту.