LINUX.ORG.RU

Вопрос новичку на тему C++

 


0

6

Допустим, окончили вы мега-курсы, и приходите устраиваться C++-программистом. Написали «C++» в списке знаний и навыков в резюме, и с гордо поднятой головой шагаете на интервью.

И вот, вам дают такой вопросик. Скажите, что произойдёт при выполнении данного кода (код, разумеется, бредовый, иначе как проверить знание секретов C++?):

#include <iostream>

struct T
{
    int iVal = 0;
    void printValue() const
    {
        std::cout << "Value is " << iVal << std::endl;
    }
    void destruct()
    {
        delete this;
    }
};

int main()
{
    T x{9};
    x.destruct();
    x.iVal = 11;
    x.printValue();
}

Какой правильный ответ, и почему?

★★★★★

Последнее исправление: seiken (всего исправлений: 1)
Ответ на: комментарий от KivApple

} так, кстати, тоже не освобождает физически. Просто сдвигает указатель, забывает смещения. Пока физически не заменятся данные, они будут все еще там, только найти их – проблема.

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

Спасибо, я как раз думал о том а как же тут сместить указатель на верхушку стека так чтоб отдельные объекты как бы удалились. Но теперь понятно что никак, только выход из скоупа или функции.

P.S. А есть предположения почему gcc у ТС вызвает сегфолты?

Aber ★★★★★
()
Последнее исправление: Aber (всего исправлений: 2)
Ответ на: комментарий от Kroz

Это проверка на честность?

Нет. Это попытка перевести разговор в нормальное русло.

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

Или кто-то видел что-то другое?

Ну вот Яндекс выкатил свой userver. Думаю, что разработчики userver вряд ли сказали бы, что в своей работе имеют дело с подобным говнокодом.

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

Да, разумеется, интервью - это калька с английского.

Да я понимаю. Просто мне ухо режет. Я, вроде, и не против англицизмов: компьютер вычислителем не называю, но тут что-то сродни викэнда, вместо выходных или барбикю вместо шашлыков. Хотя за каким-то бесом, интервью, особенно в айти – это стало маст хев, белив ми

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

Ну я не в курсе че и как, но кмк delete говорит менеджеру памяти - освободи память прописанную в таблице по этому адресу. А записи такой нет. Что ему ещё делать кроме как упасть?

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

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

Это называется (в зависимости от ситуации) code review или troubleshooting.

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

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

Никто не идеален. Во многих практических ситуациях способность дать ответ на вопрос «а что будет если …» критически важна.

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

Во многих практических ситуациях способность дать ответ на вопрос «а что будет если …» критически важна.

Не припомню такого. Обычно встречается ситуация «у нас тут неведомая хрень, как исправить?»

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

Не припомню такого.

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

bugfixer ★★★★★
()

Неопределенное поведение произойдет, как выше правильно сказали.

По теме вопроса:

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

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

автопилотами занимаетесь, и от их поведения в нештатных ситуациях зависят жизни сотен пассажиров

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

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

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

Идея таких заданий в том, что даже если человек не знает точного ответа, он может поразмышлять о возможных вариантах. Это позволяет понять, на сколько хорошо он знает C++, даже если непосредственно данный ответ неправильный, это позволяет лучше понять, как человек мыслит. Понятно, что ревью в реальной системе такой код не должен пройти.

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

Эта техника настолько сложная

Не боги обжигают горшки, знаете ли. И здесь мы возвращаемся к моему предыдущему посылу что никто не идеален. И самолёты таки падают: все мы помним печальную историю с Боингами примерно 5ти летней давности…

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

тогда за год он очень неплохо прокачается

Ну, это Вы загнули конечно.

А вот всякие полухакеры и олимпиадники последователи экстремального программирования

Позволю себе не согласиться: как показывает практика среди олимпиадников самые талантливые ребята и находятся, да и в экстремальном программировании в классическом его определении ничего плохого нет. Проверено электроникой (c).

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

тогда за год он очень неплохо прокачается

Ну, это Вы загнули конечно.

Если человек год ежедневно пишет код под присмотром ментора, то он точно хорошо прокачается. Но речь, конечно, не о computer science, а только о стиле, синтаксисе, паттернах и всяких фич.

А вот всякие полухакеры и олимпиадники последователи экстремального программирования

Позволю себе не согласиться: как показывает практика среди олимпиадников самые талантливые ребята и находятся, да и в экстремальном программировании в классическом его определении ничего плохого нет. Проверено электроникой (c).

Я не про всех говорил, просто есть ребята, которые на этом остановились и дальше никак не пошли, потому как они и так самые умные, кто эти профессора такие, чтобы их учить?

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

Хотя за каким-то бесом, интервью, особенно в айти – это стало маст хев, белив ми

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

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

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

Т.е. я занимаюсь автопилотом и размышляю о том, что будет если:

  • вызову delete для размещенного на стеке объекта?
  • вызову метод для объекта, который уже был удален?
  • будет вызван деструктор для уже разрушенного объекта?

O_o

Мне думается, что занимаясь ПО с высокими требованиями к надежности мне придется озадачиваться вопросами из категории «будет ли здесь UB, если я напишу вот так? Всегда или при определенных условиях? В рамках какого стандарта?» и пр.

Если в коде уже посажен UB (и не один), то вопрос «что получится» должен быть снят с повестки дня в принципе.

Я утрирую

Да. Чрезмерно.

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

Идея таких заданий в том, что даже если человек не знает точного ответа, он может поразмышлять о возможных вариантах.

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

Если хочется порассуждать и понять, насколько человек разбирается в языке, спросите его так: «что вы думаете о таком коде?»

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

Если хочется порассуждать и понять, насколько человек разбирается в языке, спросите его так: «что вы думаете о таком коде?»

Да, без этой части вопрос не имеет особого смысла. Поэтому рядом также есть вопрос «почему».

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

Если в коде уже посажен UB (и не один)

Это не вопрос «if», это практически гарантия для любого достаточно большого проекта.

то вопрос «что получится» должен быть снят с повестки дня в принципе.

Глубочайшее заблуждение. Это самый главный вопрос который приходится себе задавать. Постоянно.

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

Глубочайшее заблуждение.

Глубочайшее заблуждение – это отвергать вопросы «что получится», если в коде есть UB?

Ну OK. Я тогда лучше в своей вселенной поживу. Тут все как-то логичнее, по домашнему, лампово.

eao197 ★★★★★
()

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

Какой смысл такое спрашивать у новичка не очень понимаю. Или под «новичком C++» подразумевается сразу 10 лет опыта и борода минимум до груди? Раскройте тему чтоли.

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

это отвергать вопросы «что получится», если в коде есть UB?

Мне кажется - Вы узко мыслите. Не всё сводится к UB как оно определяется языком / стандартом. Имеют место быть ваши собственные логические ошибки (очень вероятно, практически гарантировано), имеют место быть «operator errors» (вероятно), имеют место быть compiler / OS / env bugs (вероятно, но выстреливают обычно с низкой вероятностью). И вот при всём этом в худо-бедно работающую систему приходится вносить изменения. Как в процессе не задаваться вопросом «а что вот это конкретно взятое изменение может сломать и как с этим жить / где подстелить соломки» - для меня загадка. Допускаю что мой мир не настолько няшный и ламповый как Ваш, это да…

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

Не всё сводится к UB как оно определяется языком / стандартом

А я о конкретных вещах говорю, а именно о попытках узнать у собеседника что произойдет при выполнении кода, в котором есть явный UB (и не один). Ибо если довелось хотя бы однажды хотя бы поверхностно попробовать познакомиться с этой темой, то должно быть понятно, что произойти может все, что угодно. Вплоть до вызова «rm -rf /».

Имеют место быть ваши собственные логические ошибки (очень вероятно, практически гарантировано), имеют место быть «operator errors» (вероятно), имеют место быть compiler / OS / env bugs (вероятно, но выстреливают обычно с низкой вероятностью).

Это уже совсем другая история. Которая должна рассматриваться через призму «как программировать на C++, чтобы a) не отстреливать себе ноги, b) обходить грабли предметной области, с) подстилать соломку на случай ошибок в compiler/OS и т.д.»

Грубо говоря, мы в приложении читаем данные из сети и доверять этим данным не можем. Как мы будем программировать, чтобы нас не взломали, отправив заведомо некорректный PDU?

Однако, если мы что-то в этой области навыдумываем, но подсадим в реализацию UB, то доверия к тому, что мы навыдумывали не должно быть.

Но, имхо, это все уже находится далеко за рамками обсуждаемого сабжа.

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

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

Давайте сойдемся на том что для конкретной комбинации компилятора / OS / env ответ вполне себе детерминирован? И мысль которую я пытаюсь донести - полезно его таки знать, или по крайней мере иметь чёткую оценку рисков.

Но, имхо, это все уже находится далеко за рамками обсуждаемого сабжа.

Это правда.

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

в котором есть явный UB

ПыСы: как Вы проводите грань между UB и логическими ошибками в своём коде? С практической точки зрения - я фундаментальной разницы не вижу.

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

Давайте сойдемся на том что для конкретной комбинации компилятора / OS / env ответ вполне себе детерминирован?

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

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

ПыСы: как Вы проводите грань между UB и логическими ошибками в своём коде?

О ё, ну и вопросы вы под вечер задаете :(

/Или здесь должен быть веселый смайлик?/

Тут в пору кандидатскую диссертацию писать.

С одной стороны, вы правы. Большинство UB – это следствие ошибок. Начиная от разыменования повисшего указателя и заканчивая целочисленным знаковым переполнением.

С другой стороны, в C++ есть тонкие моменты, которые закрываются введением в язык каких-нибудь std::launder или std::start_lifetime_as. Вот, скажем, получаем мы адрес в shared-memory. И мы точно знаем, что там лежит объект POD-типа T. И что этот объект имеет точно такой же лайаут, как и у нас в процессе (потому что это все собирается одним компилятором в одном режиме). Как нам получить валидный указатель на этот объект у себя в программе? В рамках C++14? В рамках C++17? В рамках C++20?

Вот здесь уже не так однозначно можно провести грань: я ошибся и поэтому здесь UB :(

eao197 ★★★★★
()

код, разумеется, бредовый, иначе как проверить знание секретов C++?

Единственный правильный ответ тут: если такой код у вас проходит code review, то нам с вами не о чем разговаривать.

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

в котором есть явный UB

ПыСы: как Вы проводите грань между UB и логическими ошибками в своём коде? С практической точки зрения - я фундаментальной разницы не вижу.

Фундаментальная разница: UB определено стандартом языка. Наличие UB в коде означает, что компилятор не даёт никаких гарантий насчёт поведения выданного бинарника.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)

А давайте попробуем представить подобную дичь в любой, буквально любой другой профессии.
Что будет, если водитель на ходу покинет транспортное средство?
Что будет, если хирург зальет в разрез ртуть?
Что будет, если сантехник вырежет 27 миллиметров из полотенцесушителя?

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

Фундаментальная разница: UB определено стандартом языка. Наличие UB в коде означает, что компилятор не даёт никаких гарантий насчёт поведения выданного бинарника.

Вот есть у Вас, допустим, 10 MLOC, и они даже как-то работают в Вашей текущей сборке Вашим «любимым» компилятором на Вашем текущем железе. Как Вы планируете там UB искать? «Глазками»? Или, может быть - «static analysis» какой? И сколько человеко-часов на это уйдёт? И при всех этих затратах - откуда возьмётся уверенность что Вы их таки найдёте все? А когда реальная проблема себя проявит (смена компилятора, входные данные которых до этого не было etc) - что именно даст Вам post-factum знание «это результат UB» vs «мы таки серьёзно лоханулись в логике»? Править-то придётся при любом раскладе (и хорошо если ещё останется кому править, и ради чего)…

Или, вот ещё пример: пусть там никакого UB и не было, и код Ваш полностью корректен и standard-compliant (сказка же!), но вот удалось таки словить в проде баг компилятора. Вам легче будет от того что Вы пальчиком в разрабов компилятора сможете тыркать «они, мол - заднеприводные, а мы белые и пушистые» - условный «самолёт» то уже потерян? Риски всё равно на Вас, и лучше их осознавать / уметь оценивать, что однозначно мгновенно приводит к вопросу «а что будет если XXX», даже если XXX «полное Г» и «делать так никогда не надо».

Вот я о чём.

bugfixer ★★★★★
()
Последнее исправление: bugfixer (всего исправлений: 2)