LINUX.ORG.RU

Ответ на: комментарий от UVV

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

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

eao197 ★★★★★ ()
Ответ на: комментарий от UVV

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

Deleted ()
Ответ на: комментарий от i-rinat

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

UVV ★★★★★ ()
Ответ на: комментарий от UVV

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

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!

eao197 ★★★★★ ()
Ответ на: комментарий от eao197

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

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

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

Это не ошибка

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

i-rinat ★★★★★ ()
Последнее исправление: i-rinat (всего исправлений: 1)
Ответ на: комментарий от i-rinat

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

UVV ★★★★★ ()
Ответ на: комментарий от eao197

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

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

UVV ★★★★★ ()
Ответ на: комментарий от i-rinat

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

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

UVV ★★★★★ ()
Ответ на: комментарий от i-rinat

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

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

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

eao197 ★★★★★ ()
Ответ на: комментарий от eao197

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

==>

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

UVV ★★★★★ ()
Ответ на: комментарий от eao197

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

i-rinat ★★★★★ ()

Раз уже потестили код 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'.

fsb4000 ★★★★ ()
Ответ на: комментарий от eao197

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

Crocodoom ★★★★ ()
Ответ на: комментарий от i-rinat

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

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

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

struct my_custom_policy : public default_policy {
  using mutex_type = some_custom_nonportable_mutex;
};
используется широко и базируется на той же самой возможности. Но проблем, как правило, не вызывает.

eao197 ★★★★★ ()
Ответ на: комментарий от Crocodoom

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

Deleted ()
Ответ на: комментарий от anonymous

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

Deleted ()
Ответ на: комментарий от anonymous

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

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

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

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

Crocodoom ★★★★ ()
Ответ на: комментарий от i-rinat

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

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

KennyMinigun ★★★★★ ()
Ответ на: комментарий от anonymous

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

UVV ★★★★★ ()
Ответ на: комментарий от utf8nowhere

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

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

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

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

fsb4000 ★★★★ ()
Ответ на: комментарий от fsb4000

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

UVV ★★★★★ ()

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

trex6 ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

ox55ff ★★★★ ()
Ответ на: комментарий от trex6

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

UVV ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.