Как пройти собеседование?

[OtherSide]

a* prt;
ptr++;

1) выдаст ошибку т.к. переменная ptr не объявлена.
2) если все же prt++ то формально указатель сдвинется вперед на размер типа а - но проблема в том что в prt лежит мусор и сдвиг может увести указатель куда-нибудь не туда, вызвав exception

1) Вы же видите, что это описка..
2) Никакого эксепшина не произойдет, с чего бы, мы же его не разименовываем

[Dweller]

a* prt;
ptr++;
1) выдаст ошибку т.к. переменная ptr не объявлена.
2) если все же prt++ то формально указатель сдвинется вперед на размер типа а - но проблема в том что в prt лежит мусор и сдвиг может увести указатель куда-нибудь не туда, вызвав exception

1) Вы же видите, что это описка..
2) Никакого эксепшина не произойдет, с чего бы, мы же его не разименовываем

Ну, не разыменовываем щас, так придется это делать потом Тогда другой ответ, что ptr++ бессмысленно т.к. оперирует мусором.

Не вижу подвоха в задачке. Скорее всего там была еще одна описка, т.е.
a* prt;
*prt++;

(С++ последний раз я использовал очень давно)

[OtherSide]

Не вижу подвоха в задачке. Скорее всего там была еще одна описка, т.е.
a* prt;
*prt++;

(С++ последний раз я использовал очень давно)

Вот задача целиком:

class A {
public:
A operator++(int) {
cout << "2" << endl;
return A();
}
void method() {
cout << "1" << endl;
}
};

int main(int argc, char** argv) {
A* obj;
obj->method();
obj++;
}

Сказать что будет на экране, и доказать что не упадет. Отдельным вопросом было на сколько увеличится obj

[Medium-rare]

Что называется "поведение не определено", главное зло от неинициализированных переменных.

[Boriskin]

Имхо, в релизе может упасть, а может и не упасть; в дебаге упадет...

[OtherSide]

Имхо, в релизе может упасть, а может и не упасть; в дебаге упадет...

Ну я так и ответил, что упадет и ошибка. Когда спросили почему - ответить не смог, по логике причин для падения нет, т.к. вызов метода берется не из указателя. Оно так и есть - по опыту - падает, но падение искуственное, форсированное самой Студией.
Зачем знать такие подробности для реальной работы - не понимаю. На интервью экзаменаторы всем своим видом показали, что 10 лет опыта я себе приписал или занимался неизвестно чем.

[Dweller]

Наверное это тонкий способ понять приходилось ли за 10 лет фиксить разнообразный чужой код в С++.
Плохой чужой код - рассадник подобных задач.

[Medium-rare]

Имхо, в релизе может упасть, а может и не упасть; в дебаге упадет...

Ну я так и ответил, что упадет и ошибка. Когда спросили почему - ответить не смог, по логике причин для падения нет, т.к. вызов метода берется не из указателя. Оно так и есть - по опыту - падает, но падение искуственное, форсированное самой Студией.
Зачем знать такие подробности для реальной работы - не понимаю. На интервью экзаменаторы всем своим видом показали, что 10 лет опыта я себе приписал или занимался неизвестно чем.

Зачем знать и уметь рассказать, "почему оно упадёт" на интервью? О! Вначале казалось, что они к вам несправедливы. Конечно, когда точно неизвестно почему именно упадёт, то вопрос как-бы тухлый. Но имея в виду, что отвечаешь тоже человеку, а не роботу, можно версий накидать.

Как-то, Unitialized variable causes non-deterministic program code behavior.
1) If the garbage pointer variable points to the memory mapped for this process (in the OS), we can never know what type of data there, so we don't know how the code behaves when it accesses the data by that address.

2) If the garbage pointer variable does not point to the memory mapped for this process and the code accesses the data by that address we have some Page Exception Fault or General Protection Fault, that executes standard OS process crash procedure.

Тут можно порассуждать, как возбуждается GPF в OS, как Kernel вступает. Это всё очень прямые свидетельства качества системного программиста. C/C++ программеры должны это знать и понимать.

[OtherSide]

Зачем знать и уметь рассказать, "почему оно упадёт" на интервью? О! Вначале казалось, что они к вам несправедливы. Конечно, когда точно неизвестно почему именно упадёт, то вопрос как-бы тухлый. Но имея в виду, что отвечаешь тоже человеку, а не роботу, можно версий накидать.

Как-то, Unitialized variable causes non-deterministic program code behavior.
1) If the garbage pointer variable points to the memory mapped for this process (in the OS), we can never know what type of data there, so we don't know how the code behaves.

2) If the garbage pointer variable does not point to the memory mapped for this process we have some Page Exception Fault or General Protection Fault, that executes standard OS process crash procedure.

Тут можно порассуждать, как возбуждается GPF в OS, как Kernel вступает. Это всё очень прямые свидетельства качества системного программиста. C/C++ программеры должны это знать и понимать.

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

Вообще же поднатаскатся на таких задачах проблем не вижу - кол-во каверзных вопросов ограниченно, и еще чуть подготовившись можно быстро отвечать на все. Но что же делать с MFC, COM, WinAPI и прочим? Каждая из книг по этим технологиям занимает страниц 900. И если к кавернзным вопросам по С++ еще можно подготовится, то от мысли о том, что нужно зубрить эти фолианты мне становится совсем дурно.

[Medium-rare]

Типа отбрехаться знанием страшных слов?

У вас неправильное отношение к интервью. Это практический вполне вопрос. Если бы вы имели опыт написания, скажем, драйверов, или работы с железками то "отбрехаться знанием страшных слов" звучало бы просто как ответ сисадмина на серьёзный вопрос низкоуровневого программирования. Потому надо понимать, что там физически происходит.

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

[OtherSide]

Плюс еще вопрос мотивации: когда в 17 лет я писал утилиты, которая ворует кнопочки из MS WORD - то чувствовал себя кул хацкером. Сейчас же уже подобные эксперименты не являются для меня столь захватывающими и учебник по MFC уже не читается захватывающе.

[Medium-rare]

Сейчас всё больше сокращется для нас рынок, C/C++, если про Windу. Есть более менее стабильные области за пределами Windы и кросс-платформенное либо железячное программирование. Все области, где надо хорошо понимать связь между архитектурой процессора / ОS / вашего кода.

[OtherSide]

Типа отбрехаться знанием страшных слов?

У вас неправильное отношение к интервью. Это практический вполне вопрос. Если бы вы имели опыт написания, скажем, драйверов, или работы с железками то "отбрехаться знанием страшных слов" звучало бы просто как ответ сисадмина на серьёзный вопрос низкоуровневого программирования. Потому надо понимать, что там физически происходит.

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

Ну знаете, это как то несерьезно на вопрос почему упадет, говорить что упадет из-за GPF. Это-то понятно.

[Medium-rare]

:смайлик, стучащийся лбом об стену:

[OtherSide]

Сейчас всё больше сокращется для нас рынок, C/C++, если про Windу. Есть более менее стабильные области за пределами Windы и кросс-платформенное либо железячное программирование. Все области, где надо хорошо понимать связь между архитектурой процессора / ОS / вашего кода.

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