<source>:24:11: error: 'print' is a private member of 'Child'
24 | child.print(10);
| ^
<source>:15:18: note: implicitly declared private here
15 | virtual void print(int x, int y)
| ^
<source>:24:11: error: too few arguments to function call, expected 2, have 1; did you mean 'Parent::print'?
24 | child.print(10);
| ^~~~~
| Parent::print
<source>:6:18: note: 'Parent::print' declared here
6 | virtual void print(int x)
| ^
2 errors generated.
Compiler returned: 1
Здравствуйте, sushko, Вы писали:
S>Visual C++ 2010. Компилятор ругается на вызов child.print(10) в _tmain: ему не хватает аргументов.
S>Скажите, что я делаю не так?
S>
Не факт, что в Visual C++ 2010 есть такой using. Я в Visual C++ 2005 обходился вставкой прототипов всех версий print. Хотя, может, using и тогда уже так умел, а я просто не знал.
Здравствуйте, rg45, Вы писали:
R>Добавь в Child using декларацию:
Заработало. Спасибо!
R>Child::print не оверрайдит (override), а скрывает (hide) Parent::print.
Странно мне это. Мне казалось, что по логике родительский print должен был "становиться рядом" с дочерним. Поскольку набор аргументов разный, то дескрипторы (если я правильно понимаю этот термин) функций не должны пересекаться...
Здравствуйте, sushko, Вы писали:
S>Странно мне это. Мне казалось, что по логике родительский print должен был "становиться рядом" с дочерним. Поскольку набор аргументов разный, то дескрипторы (если я правильно понимаю этот термин) функций не должны пересекаться...
Нет, имя print перекрывает все перегрузки из базового класса
Здравствуйте, sushko, Вы писали:
S>Странно мне это. Мне казалось, что по логике родительский print должен был "становиться рядом" с дочерним. Поскольку набор аргументов разный, то дескрипторы (если я правильно понимаю этот термин) функций не должны пересекаться...
Так происходит, когда перегруженные функции находятся в одном классе. А одноименные функции производных классов скрывают функции базового класса. Так было, начиная с C++98. И даже раньше. И логика тут простая — производный класс может объявить повторно любой из членов базового класса, в т.ч. и функцию-член — с идентичными параметрами и модификаторами. И это не будет вызывать ошибок компиляции.
Собственно, с пространствами имен ведь ровно то же самое.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, rg45, Вы писали:
R>одноименные функции производных классов скрывают функции базового класса.
Я бы предпочел, чтобы это правило было менее радикальным, и одноименную функцию дочернего класса с другой сигнатурой можно было бы просто добавить к наследуемым функциям базового, не выписывая тупых переходников для базовой функции и всех ее перегрузок.
Вполне ж банальная ситуация, когда базовый класс определяет несколько одноименных функций с разными наборами параметров, а дочерний класс хочет расширить этот набор аналогичными своими.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Я бы предпочел, чтобы это правило было менее радикальным, и одноименную функцию дочернего класса с другой сигнатурой можно было бы просто добавить к наследуемым функциям базового, не выписывая тупых переходников для базовой функции и всех ее перегрузок.
ЕМ>Вполне ж банальная ситуация, когда базовый класс определяет несколько одноименных функций с разными наборами параметров, а дочерний класс хочет расширить этот набор аналогичными своими.
Ну ты написал уже письмо Деду Морозу?
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Я бы предпочел, чтобы это правило было менее радикальным, и одноименную функцию дочернего класса с другой сигнатурой можно было бы просто добавить к наследуемым функциям базового, не выписывая тупых переходников для базовой функции и всех ее перегрузок.
Расскажи, где ты здесь перетрудился, "выписывая тупые переходники для базовой функции и всех ее перегрузок"?
Здравствуйте, rg45, Вы писали:
R>где ты здесь перетрудился, "выписывая тупые переходники для базовой функции и всех ее перегрузок"?
Когда-то давно мне впервые понадобилось в потомке расширить набор перегруженных функций предка, и тогда это можно было сделать только через определение одноименных переходников. Возможно, тогда еще не было using. Когда он появился, его применение акцентировалось главным образом на членах с той же сигнатурой — возможно, поэтому я и упустил возможность его использования для перегрузок.
R>Где здесь вообще какие-нибудь "переходники"?
Теперь вижу, что для такой задачи тоже годится, спасибо!
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Когда-то давно мне впервые понадобилось в потомке расширить набор перегруженных функций предка, и тогда это можно было сделать только через определение одноименных переходников. Возможно, тогда еще не было using. Когда он появился, его применение акцентировалось главным образом на членах с той же сигнатурой — возможно, поэтому я и упустил возможность его использования для перегрузок.
Когда не было using? В 2003 студии он был уже точно (в том виде, который в примере). Вот был ли он раньше — на счёт этого я не уверен.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Когда-то давно мне впервые понадобилось в потомке расширить набор перегруженных функций предка, и тогда это можно было сделать только через определение одноименных переходников. Возможно, тогда еще не было using. Когда он появился, его применение акцентировалось главным образом на членах с той же сигнатурой — возможно, поэтому я и упустил возможность его использования для перегрузок.
Я заглянул в стандарт 98-го года и вижу, что пункт "7.3.3 The using declaration" там есть, практически в том же виде, что и в стандарте C++03. Сам я этого не помню уже, но уверен на 99%, что в компиляторах msvc using директивы и using объявления присутствовали изначально. Так что, все беды от незнания, как ни крути.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Так я ж начал использовать C++ года с 93-го, с Turbo C++ 2.0,
А Borland C++? Пропустил?
ЕМ>потом — MS VC++ 4.0.
Ну а в msvc-4.0 это уже было, скорее всего. Я почти уверен в этом.
Ну и что, с 93-го года у тебя ни разу не возникло предположения, что в языке могло что-то измениться? Почему в 2025-м ты пишешь посты, как-будто до сих пор находишься в 1993-м?
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, rg45, Вы писали:
R>А Borland C++? Пропустил?
Ага. TC++ 2.0 мне категорически не понравился, а дальше был уже нужен компилятор под винду. 32-разрядный VC++ был неплох, а BC++ еще какое-то время сохранял рудименты 16-разрядного кода.
R>с 93-го года у тебя ни разу не возникло предположения, что в языке могло что-то измениться? Почему в 2025-м ты пишешь посты, как-будто до сих пор находишься в 1993-м?
Да все мы периодически открываем для себя то, что другим уже давно очевидно. Не хватает ресурсов мозга следить за всем. Я ж не фанат C++, как Вы, не жду с нетерпением очередного стандарта, не собеседую новичков на знание тонкостей и т.п.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Когда-то давно мне впервые понадобилось в потомке расширить набор перегруженных функций предка, и тогда это можно было сделать только через определение одноименных переходников. Возможно, тогда еще не было using. Когда он появился, его применение акцентировалось главным образом на членах с той же сигнатурой — возможно, поэтому я и упустил возможность его использования для перегрузок.
Ерунда какая-то, зачем делать using для членов с той же сигнатурой, если ты эту сигнатуру как раз перегружаешь. Более того, в using никакой сигнатуры нет, using на все перегрузки имени работает