Shadowing member variable

А разве это проблема? AFAIK так и должно быть

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

Только это семантическая ошибка / ошибка программирования.

Это вы про что? Про переменную с таким же именем в производном классе?

Ошбка максимум потенциальная, т. е. неквалифицированное обращение к base::i по невнимательности. Из решений только КО

-Wshadow-field в Clang с пятой версии.

Это вы про что? Про переменную с таким же именем в производном классе?

Именно

ммм.. а в gcc ещё не завезли получается.

Это не ошибка, как и в случае с:

void foo() {
  int i = 0;
  ...
  if(something) {
    int i = 0;
    ...
  }
}

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

Например #1. Вы пользуетесь чужим классом Base, в котором Base::i не было. Вы сделали Derived::i. Прошло какое-то время и Base доработали, добавив туда Base::i. Захотите ли вы менять свой Derived?

Например #2. Шаблоны и наследование.

class Base {
protected:
  int i_;
...
};
class Derived : public Base {
  ...
};
class Mixin {
protected:
  int i_;
...
};
template<typename M>
class MegaDerived : public Derived, public M {
  ...
};
...
MegaDerived<Mixin> d; // oops!

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

Из разряда «мне не надо, значит никому не надо». Возможны случаи, в которых такое предупреждение может помочь. Это уже достаточный повод добавить его, хотя бы в каком-то своём внутреннем инструменте.

Вот в Clang, например, есть такое предупреждение, но оно не включается ни в -Wall, ни даже в -Wextra. Позреваю, что примерно по тем же соображениям — большое количество ложных срабатываний.

Это не ошибка

Кстати, по ссылке на SO, приведённой ТСом, просят предупреждение, а не сообщение об ошибке. Все в курсе, что это не является ошибкой.

Мне тут подсказали, что можно накатать небольшую программку с помощью libclang и просто сравнить список членов.. хоть что-то будет

Это не ошибка, как и в случае с:

Между ошибка и семантическая ошибка есть большая разница

Кстати, по ссылке на SO, приведённой ТСом, просят предупреждение, а не сообщение об ошибке. Все в курсе, что это не является ошибкой.

+, мне это и надо, не больше

Возможны случаи, в которых такое предупреждение может помочь.

Я до сих пор нахожусь в недоумении от того, где в подобных сценариях ТС видит ошибку (хоть «семантическую», хоть «программирования»). Собственно, отсюда и появились мои комментарии.

То, что пересечение имен может быть чревато, так это очевидно.

Я до сих пор нахожусь в недоумении от того, где в подобных сценариях ТС видит ошибку

==>

То, что пересечение имен может быть чревато, так это очевидно.

Было бы здорово, если бы часть проверок можно было автоматизировать. Понятное дело, что нельзя полностью заменить человека на ревью. Но если дать ему больше инструментов, станет лучше. Ведь так?

Скачал пятый шланг и попробовал натравить анализатор, в итоге меня ударили по морде вот этим https://bugs.llvm.org/show_bug.cgi?id=33550

Раз уже потестили код gcc и сlang, решил для полноты картины проверить код имеющимися под руками анализаторами и компиляторами:

Потестил код MSVC2017 и PVS Studio и cppcheck

PVS Studio выдаёт:

V703 It is odd that the 'i' field in derived class 'Child' overwrites field in base class 'Mother'. Check lines: main.cpp:19, main.cpp:10. main.cpp 19

MSVC 2017 не выдаёт предупреждений насчёт этого (хотя просто предупреждения об обычном затенении выдаются)

Cppcheck выдаёт:

Id: duplInheritedMember
Summary: The class 'Child' defines member variable with name 'i' also defined in its parent class 'Mother'.
Message: The class 'Child' defines member variable with name 'i' also defined in its parent class 'Mother'.

Скачал пятый шланг

http://wandbox.org и можно не качать ;)

То, что пересечение имен может быть чревато, так это очевидно.

Лол :-) Чего тут удивляться? :-) В мире программирования полным полно шлангов, которые любят нарываться на неприятности :-) Особенно, это касается цепепе :-) Так, есть любители делать в классах члены данных без префиксов и суффиксов, либо определять члены данных открытыми, либо определять функции доступа к данным через макросы или ещё какую-нибудь задницу :-) Уж где где, а в цепепе таких возможностей масса :-) Печально только тем, у кого отношение к коду не как к параше, а как к произведению :-) Остальным плевать, даже когда их компилятор заваливает всевозможными варнингами :-) Но самое удивительное, что такого закрытого кода, который ещё и работает и приносит прибыль великое множество :-) А вот это уже не так очевидно и вообще является феноменом :-)

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

И таки что в этом плохого?

и можно не качать

Вместо этого закачать весь свой или не совсем свой код к ним? Сомнительная идея.

Дык, я согласен с тем, что иметь подобное опциональное сообщение было бы полезно. Но вот по поводу того, что это «семантическая ошибка» я до сих пор недоумеваю.

Тем более, что вот такой прием:

struct default_policy {
  using mutex_type = std::mutex;
  ...
};

struct my_custom_policy : public default_policy {
  using mutex_type = some_custom_nonportable_mutex;
};

И таки что в этом плохого?

Лол :-) Я же говорю, вас много таких :-)

над именем геттеров, в случае их присутствия, приходится задуматься

Привет, смайлофаг. Не просто много - почти все

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

И таки что в этом плохого?

Лол :-) Я же говорю, вас много таких :-)

Да, нас таких пруд пруди! Не пораженных ООПГМ.

Вместо этого закачать весь свой или не совсем свой код к ним?
Сомнительная идея.

С такой точки зрения — да. А вот просто испытать проблемный фрагмент кода — ляпота.

Узнал анонима по количеству используемых смайлов

PVS Studio выдаёт:

Бялть, больше не показывай этот «английский».

PVS Studio неграмотно выдаёт предупреждение о возможной ошибке?

А в clang/cppcheck предупреждения лучше?

Вот кстати что выдаёт clang:

warning: non-static data member 'i' of 'Child' shadows member inherited from type 'Mother' [-Wshadow-field]

вот, кстати, спасибо за напоминание. Чё-т cppcheck как раз вылетел из головы. Думаю, то что нужно.

Неконстантные члены класса за пределами private секции - большая ошибка. Если это исправить, то проблем не будет.

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

Изврат. В джавке живут же как-то без макросов и дефайнов и ничего. Тут дело не крестах. Это всё из-за тяжёлого детства, проведённого вместе с компилятором сишечки.

Согласен, если класс смотрит наружу. А так это private-реализация (читай d-pointer в qt).