Здравствуйте, Erop, Вы писали:

E>Здравствуйте, tilarids, Вы писали:

T>>Хватит обсуждать вопрос, ответ на который уже давно дан. Давайте новые вопросы

E>Изволь:
E>Какими проблемами черевато излишнее использование виртуальных методов. Когда и почему их стоит избегать?

снижение производительности (стремящееся к 0), особенно при множественном наследовании. Сложно улавливать смысл программы.

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, IROV.., Вы писали:

IRO>>буквы понял, смысл не понял

E>Плохо, что не понял. Может и с 10% погорячился.
может я просто не понял смысловую нагрузку твоего "Э-э-э-э!"?

E>Кстати, а что ты бы ответил на вопрос про виртуальные функции

Автор: Erop
Дата: 17.01.07

?
незнаю, ничего плохого нету.

E>Или, хотя бы, скажи, что ты думаешь о такм вопросе на собеседовании.
Хорошое, интерестно было бы послушать "мысли в слух".

E>Ещё интересно было бы узнать примеры "нормальных" вопросов.
E>Потому что "любимый" про ?/ и про игры на меня произвели впечатление
про игры? ну знаеш если ты делаеш игры, то вопрос про игры, конечно ну уж _очень_ странный.

Вести спор не зная предмета спора, очень благородное занятие

Здравствуйте, IROV.., Вы писали:

E>>Потому что "любимый" про ?/ и про игры на меня произвели впечатление
IRO>про игры? ну знаеш если ты делаеш игры, то вопрос про игры, конечно ну уж _очень_ странный.
Э-э-э, ты бы больше рассказывал тогда, что ли
Например у меня сложилось впечатление, что ты набирал С++ программистов, а не спецов по проектированию игр.
ИМХО спецу по проектированию игр можно простить незнание и std::map и stl вообще и уж тем более диграмм

IRO>Вести спор не зная предмета спора, очень благородное занятие
Ну вот и приведи несколько "хороших" вопросов.

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

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, IROV.., Вы писали:

E>>>Потому что "любимый" про ?/ и про игры на меня произвели впечатление
IRO>>про игры? ну знаеш если ты делаеш игры, то вопрос про игры, конечно ну уж _очень_ странный.
E>Э-э-э, ты бы больше рассказывал тогда, что ли
E>Например у меня сложилось впечатление, что ты набирал С++ программистов, а не спецов по проектированию игр.
E>ИМХО спецу по проектированию игр можно простить незнание и std::map и stl вообще и уж тем более диграмм
ИМХО, денег нету стока, что бы стока народу было, приходится совмещать.

IRO>>Вести спор не зная предмета спора, очень благородное занятие
E>Ну вот и приведи несколько "хороших" вопросов.
www.google.com — хорошие вопросы на собеседование.

E>Я, кстати, не согласен, что от неразумного использования виртуальных функций нет вреда.
от неразумного использования вред всегда есть

Здравствуйте, Erop, Вы писали:


E>>>Изволь:
E>>>Какими проблемами черевато излишнее использование виртуальных методов. Когда и почему их стоит избегать?

E>Для начала расширенный пример:

E>Вот есть у меня граф. редактор. И я вместо того, чтобы завести CPoligon, который является массивом точек, которые надо соединить, завёл абстрактный класс CPoligon с наследниками CTriangle, CQuadrangle, CPentagon, CHexagon, CHeptagon и т. д.

E>Судя по всему я что-то сделал не так. Но твоё "золотое правило" я вроде как не нарушил
Ну, для начала, моим это правило можно назвать только благодаря тому, что я его использую.
Да и оберегает оно от чрезмерного использования виртуальных функций, а не от плохой структуры классов Для того, чтобы создать хорошую структуру, уже одного правила недостаточно. Здесь нужно рассматривать ситуацию в целом, рисовать, оценивать различные структуры по многим критериям.

E>Кроме того интресно так же узнать чем так плохо увеличение размеров таблицы?
Увеличение потребления памяти, а также(ну, и вследствие предыдущего тоже) падение производительности.

Здравствуйте, tilarids, Вы писали:

E>>Кроме того интресно так же узнать чем так плохо увеличение размеров таблицы?
T>Увеличение потребления памяти, а также(ну, и вследствие предыдущего тоже) падение производительности.

Это тоже интересная тема!
Казалось бы, ну что там реально происходит? Ну добавляется лишний уровень косвенности. Типа не сразу адрес функции знаю, а читаю из адреса в регистре указатель и уже на него перехожу?
Почему же всем кажется, что виртуальные функции снижают скорость работы программы?

_>>Рекомендую Вам попытаться учесть такие факторы, как стресс, грубость и нахальность потенциального работодателя, etc.
IRO>стресс,
Хм, да будет Вам известно, что общение с потенциальным работодателем — для средне статистического человека всегда в определённой мере стресс (такова уж природа)
IRO>грубость и нахальство _работодателя_?
Покорно прошу простить, но не на это ли намекают Ваши посты? Уж, по крайней мере у меня, именно такое впечатление сложилось...

IRO>Скажу так, мне в свое время сделал такой контрольный в голову, и я задумался, и пересмотрел все то что знал. (а считал что знал все) теперь понимаю что я и 10% не знаю от С++. И у меня с трудом поворачивается язык, говорить что я знаю С++.
А не подскажите, что кроме комплекса неполноценности (возможно в малой степени, но все же) Вам это дало? Приведу аналогию: если в подворотне набьют морду и отберут деньги, то это еще не повод делать тоже самое другим только лишь для того, чтобы доказать, что не вы один не способны отбиться от гопников на 100%, лучше бы попытаться уменьшить количество таких случаев, имхо.

Кстати, если уж Вы так пытаетесь показать свою скромность то, простите, что именно позволяет Вам (по Вашим словам, далеко не эксперту) утверждать и определять "нормальность" других? Я бы не рискнул в такой ситуации, может Вам в дальнейшем стоит избегать собеседовать других на предмет знания С++, а заняться только вопросами "смотрения какой он, как человек" — знаете бывают двуэтапные собеседования (и еще могу посоветовать ставить свое первым, чтобы человек сразу знал с кем работать будет).

IRO>Ты бы помнил только это, а есть люди которые поймут что чтото не то, и надо чтото подтенуть. И прийдя в другую контору, они уже не будут надеятся на фактор случая, и на красивые глазки, а ожидая все что угодно.
Знаете, с таким подходом Вам вероятно нужно начать путь Сковороды и начать учить мир, как правильно составлять резюме и о каких своих возможностях заявлять.

Чтобы не повторяться, скажу только, что то, на что Вы рассчитываете мало поможет: как правило "кул-хацкеры" превращаются программистов или даже в именитых экспертов потом и не под влиянием унижений, а своей тяги к совершенствованию — банально, дабы мочь сделать все-таки то, про что они заявляют. Скажу Вам более, такими "кул-хацкерами" были очень многие программеры на самом раннем этапе своей карьеры (например, мой коллега на первом курсе даже думал, что сможет написать свою ОС, я на 2 курсе тоже стремился, как минимум понять всю архитектуру кернела винды). И что же, это, уважаемый, называется амбитностью — именно она толкает на дальнейшее развитие. Да, бесспорно, "кул-хацкер" не нужен компании с небольшим/малым бюджетом и инвестировать в будущее к тому же все рискнут. НО ЗАЧЕМ ЖЕ УНИЖАТЬ ЛЮДЕЙ?! Что Вам это даст? Что даст Вам то, даже, что кандидат сразу же "прозреет" и начнёт "посыпать голову пеплом"? Что даст Вам это — Вы ведь все-равно не будете его нанимать, в лучшем случаи он пойдёт изучать Стандарт, но Вам-то что с того?
Вы думаете это поможет ему — нет, он либо станет программистом (и если это случится, то заслуга будет отнюдь не Вашей — это заслуга его, его амбитности, его трудолюбия, его заинтересованности — унижение не путь к просветлению), либо найдёт себя в другой области. Например, на мою заинтересованность творчеством Страуструпа, Мейерса и Саттера, никак не повлияло то, что наш преподаватель Бондарев (ХИРЭ) не считал нас за людей и говорил, что мы не способны ничего написать, это скорее заслуга моего друга, который постоянно "донимал" меня своим мнением о том "какая все-таки классная штука STL", "как же все-таки расположен объект в памяти", "когда же все-таки применять NVI". Что же, получить на brainbench по С++ 4.87 и 4.91 по Фундаменталз, мне помог интерес к Стандарту и его "заковыкам" — и уж гарантирую, что это не было результатом какого-нибудь унижения.

IRO>Я также могу на собеседовании попросить разложить 6 сигарет так что бы они все касались друг друга. Может это тоже издевательство? пускай.
IRO>Поведение человека в экстримальных ситуациях очень важна для меня.
Что же, я возможно неправ, неправы возможно и авторы книг по управлению персоналом, также вероятно неправы коллеги из HR, проводившие связанные с этим исследования. Вас это может удивить, но программистам не нужны такие качества (или по крайней мере, они мало применимы в профессии), которые можно выявить такими тестами. С таким же успехом можно просить кандидатов раздеться и в зависимости от длины... ну скажем, пальцев ног отбирать персонал (кстати, очень рекомендую — опять же сохранит всем много времени — Вы получите наслаждение "властью", а кандидаты сразу поймут с кем имеют дело).

Кроме того, а Вы предупреждаете кандидатов, что они будут работать именно в экстремальных условиях? Я, например, очень рад, что работаю как раз в максимально удобных условиях — это положительно сказывается и на моей продуктивности и здоровье (что опять же +1 к продуктивности). Странный подход однако, Вы пытаетесь проверить то, чего нужно как можно тщательнее избегать в рабочем процессе (хотя, возможно это специфика политики Вашей компании — еще раз спасибо, "Таркос Софт" буду помнить и рекомендовать).

IRO>А ответ прост, я не говорю с человеком о компании. я лиш проверяю его знания.
Интересно, а я-то всегда думал, что собеседование потому и собеседование, а не экзамен, что позволяет обоим участникам узнать как можно больше друг о друге для того, чтобы обоим было максимально комфортно работать вместе?
Простите, не могу удержаться, а Вы нах@й под конец не посылаете? А что же — во-первых, тоже тест на так необходимую "экстремальную ситуацию", "может это издевательство? пускай".

Здравствуйте, anonim_44ax, Вы писали:

Такие сообщения пишите на irov13@mail.ru

дабы не засрамливать этот форум.

Спасибо.

IRO>дабы не засрамливать этот форум.
Хм, и в чем же "срам"? Простите, не вижу ничего плохого в этом посте...

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, tilarids, Вы писали:

E>>>Кроме того интресно так же узнать чем так плохо увеличение размеров таблицы?
T>>Увеличение потребления памяти, а также(ну, и вследствие предыдущего тоже) падение производительности.

E>Это тоже интересная тема!
E>Казалось бы, ну что там реально происходит? Ну добавляется лишний уровень косвенности. Типа не сразу адрес функции знаю, а читаю из адреса в регистре указатель и уже на него перехожу?
E>Почему же всем кажется, что виртуальные функции снижают скорость работы программы?

снижать то снижают, но настолько ли, что стоит отн их отказываться из-за этого?

Здравствуйте, Константин Л., Вы писали:

E>>Почему же всем кажется, что виртуальные функции снижают скорость работы программы?
КЛ>снижать то снижают, но настолько ли, что стоит отн их отказываться из-за этого?

1) ИМХО вред от виртуальных функций бывает разный. Самый главный -- они часто снижают поддерживаемость кода. Так как в C++ нельзя разметить виртуальные функции на тему где и как они должны быть перекрыты или изменены в случае каких-то изменений в базе, например.

2) Вопрос о потере производительности из-за виртуальных функций тоже непростой. Ведь такое мнение есть? На чём же оно основывается?

3) А вообще общий смысл такой. Что если можно обойтись без виртуальных функций не переусложняя систему, то обычно лучше обойтись
То есть когда принимается решение завести в иерархии виртуальные функции, то обоснование должно выглядеть не как: "почему их можно/нужно завести", как: "мочему без них не получится обойтись"
Но последовательный разговор сложный. Так как, ИМХО, есть несколько целей, для которых в C++ используется механизм виртуальных функций.
В рамках каждой цели вред и польза от них, вообще говоря отличаются.

Например, сравни:
Реализация COM-сервера
Реализация описанного где-то тут выше CPoligon

Здравствуйте, IROV.., Вы писали:

IRO>а потом пытаются непонятно зачем реабилитировать свою гордыню
А зачем гордыню реабилитировать? Она была незаслуженно скомпрометирована или ещё чего случилось?

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Константин Л., Вы писали:

E>>>Почему же всем кажется, что виртуальные функции снижают скорость работы программы?
КЛ>>снижать то снижают, но настолько ли, что стоит отн их отказываться из-за этого?

E>1) ИМХО вред от виртуальных функций бывает разный. Самый главный -- они часто снижают поддерживаемость кода. Так как в C++ нельзя разметить виртуальные функции на тему где и как они должны быть перекрыты или изменены в случае каких-то изменений в базе, например.
Это недостаток языка и компилятора и к виртуальны функциям отношения не имеет. Вы имеете ввиду что перегрузка виртуальных функций это зло — в общем согласен. Эту проблему можно было бы решить
1 — введя override как в жабе
2 — запретив перегрузку виртуальных функций
3 — используя Intel C++ compiler который на этот случай выдает варнинг
Недостаток именно в перегрузке виртуальных функций и ни в чем ином, а то что вы написали одинаково подходит и для любых широко используемых классов С++. С таким же успехом можно сказать что std::wstring это зло потому что если изменить его интерфейс то куча кода перестанет работать.

E>2) Вопрос о потере производительности из-за виртуальных функций тоже непростой. Ведь такое мнение есть? На чём же оно основывается?
Вопрос очень простой, само по себе разыменовывание указателя — тьфу, плюнуть и растереть, с таким же успехом можно говорить о вреде указателей или ссылок дело в другом — оптимизатор не может создать оптимальный код
Наглядный пример

std::sort(b,e,pred); //если подсунуть адрес функции то оптимизатор может и сдуться а если подсунуть struct somePred : public binary_function<....> то мы можем смело рассчитывать на оптимизацию!

E>3) А вообще общий смысл такой. Что если можно обойтись без виртуальных функций не переусложняя систему, то обычно лучше обойтись
Признайтесь вы просто не любите виртуальные функции , сделать систему максимально просто но не более это общий принцип который к ним отношения не имеет.

Здравствуйте, anonim_44ax, Вы писали:

IRO>>дабы не засрамливать этот форум.
_>Хм, и в чем же "срам"? Простите, не вижу ничего плохого в этом посте...
Мне кажется _личный_ обвинения вы бы могли писать в приватном режиме, вот я любезно и предоставил вам свой почтовый адресс, где мы с любезностью обсудим ваш поток сознания, на любую предложеную вами тему, а так я еще раз повторяю, я не люблю, и не люблю когда другие читают жолтую прессу. основаную лиш на личном мнении, я конечно не запрещаю вам делать такие выводы, но будьте любезны не провоцировать обоюдный словесный понос!

для начало задумайтесь, когда пишете подобные вещи, а всей ли информацией вы владеете?

З.Ы. скорее всего, из за этого флуда рсдн чтото у меня сегодня и барахлит. постараюсь ответить завтра почему мне не нравится ваш ответ , думаю вы вытерпете подождать. Спасибо.

Здравствуйте, rm822, Вы писали:

R>1 — введя override как в жабе
MSVC 8.0 уже это поддерживает

Здравствуйте, Erop, Вы писали:


E>2) Вопрос о потере производительности из-за виртуальных функций тоже непростой. Ведь такое мнение есть? На чём же оно основывается?

E>3) А вообще общий смысл такой. Что если можно обойтись без виртуальных функций не переусложняя систему, то обычно лучше обойтись

2) Ну, а если в примере с Cpoligon этих полигонов около 10000? Думаю, можно почувстовать.
3) Ну, в принципе-то вы повторили мое правило

Здравствуйте, IROV.., Erop и другие участники занимательной дискуссии.

Буду краток:
— Эээй! Бородатый, ты что мне дал?

Автор: Константин
Дата: 17.01.07

Здравствуйте, tilarids, Вы писали:

E>>2) Вопрос о потере производительности из-за виртуальных функций тоже непростой. Ведь такое мнение есть? На чём же оно основывается?
T>2) Ну, а если в примере с Cpoligon этих полигонов около 10000? Думаю, можно почувстовать.
Вопрос был не в том "существует ли потеря", а в том "от чего она происходит" Но правильный ответ (во всяком случае ответ, с которым я согласен ) уже дали . Основная проблема с виртуальными функциями в том, что в точке вызова недоступно определение функции, поэтому невозможна оптимизация

---

E>>3) А вообще общий смысл такой. Что если можно обойтись без виртуальных функций не переусложняя систему, то обычно лучше обойтись
T>3) Ну, в принципе-то вы повторили мое правило
Ну немного его уточнив, вроде

Здравствуйте, rm822, Вы писали:

R>Это недостаток языка и компилятора и к виртуальны функциям отношения не имеет. Вы имеете ввиду что перегрузка виртуальных функций это зло — в общем согласен. Эту проблему можно было бы решить
R>1 — введя override как в жабе
R>2 — запретив перегрузку виртуальных функций
R>3 — используя Intel C++ compiler который на этот случай выдает варнинг
R>Недостаток именно в перегрузке виртуальных функций и ни в чем ином, а то что вы написали одинаково подходит и для любых широко используемых классов С++. С таким же успехом можно сказать что std::wstring это зло потому что если изменить его интерфейс то куча кода перестанет работать.

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

Но в целом проблемы с управлением перегрузками виртуальных функций не сводятся только к тому, что их можно так сказать перегружать. (Я бы то, что происходит, когда вместо virtual void f(int) в предке появляется virtual void f(char) в наследнике словом перегрузка не называл )
Вот, например, сравним две ситуации.

Сит 1: У тебя есть класс, у которого есть много пользователей. По каким-то причинам надо какой-то метод этого класса как-то расширить, например добавить ещё один параметр, у которого возможно значение по умолчанию. А хуже, если расширить как-то сложнее.
Тогда ты или заводишь значение по умолчанию, или заводишь другой метод, который называется как-то ещё.
Тогда весь старый код или не заметит изменений, или (если старый метод пришлось таки прибить) не скомпилируется.

Сит 2: у тебя есть иерархия, в которой есть какой-то виртуальный метод, перекрываемый на нескольких уровнях иерархии. В этом методе понадобилось что-то поеменять. Например добавить параметр, у котрого возможно задать значение по умолчанию

Но в целом уже даже override сильно помогает. С этим я согласен
+1

---

R> Вопрос очень простой, само по себе разыменовывание указателя — тьфу, плюнуть и растереть, с таким же успехом можно говорить о вреде указателей или ссылок дело в другом — оптимизатор не может создать оптимальный код
Совершенно согласен! Но это знают совсем и не все.

то есть вот если кандидат расскажет то, что ты рассказал в своём предыдущем посте, то это весьма компетентный ответ, который говорит сильно в пользу такого кандидата

---

E>>3) А вообще общий смысл такой. Что если можно обойтись без виртуальных функций не переусложняя систему, то обычно лучше обойтись
R>Признайтесь вы просто не любите виртуальные функции , сделать систему максимально просто но не более это общий принцип который к ним отношения не имеет.

Почему именно виртуальные функции? Мне вообще практически всё в C++ не наравится
И с общим принципом согласен. Просто я, например, неоднократно сталкивался с таким подходом, что в какой-нибудь иерархии заводят виртуальные функции "про запас", или, что ещё хуже, заводят полиморфизм без всякой на то нужды. ИМХО нужно понимать что это плохо и избегать такой ситуации

Здравствуйте, Erop, Вы писали:



E>Ну немного его уточнив, вроде ....

Спасибо за вопрос про виртуальные функции.

Предложу очень простой вопрос(подойдет в качестве первого вопроса), который призван не завалить кандидата, а как раз заставляет его собраться. Сам по себе ответ на вопрос не учитывается.

#include <iostream>
#include <cmath>

void main()
{
    if(sin(3.14))
    {
        std::cout<<"true";
    }
    else
    {
        std::cout<<"false";
    }
    std::cin.get();
}

Что выведет на экран данная программа?