Очень полезный контент, спасибо большое за труды, очень интересно наблюдать за процессом, подмечая для себя много нужных вещей. Еще раз спасибо, продолжай в том же духе!
"знаю 11, 14 стандарт 100%" какой самоуверенный кандидат 9:18 Он же говорит про публичные и защищенные поля базового класса, при приватном наследовании у дочернего класса конечно же будет доступ к этим полям. Приватными они станут на уровне дочернего класса. В противном случае в таком наследовании не было бы никакого смысла, ведь дочерний класс не смог бы даже конструктор своего родителя вызвать. 17:34 ̶К̶а̶к̶о̶й̶ ̶c̶o̶n̶s̶t̶.̶ ̶Г̶р̶у̶б̶а̶я̶ ̶о̶ш̶и̶б̶к̶а̶.̶ ̶К̶о̶д̶ ̶н̶е̶ ̶с̶к̶о̶м̶п̶и̶л̶и̶р̶у̶е̶т̶с̶я̶. Все нормально. 32:10 Деление на ноль не бросает исключение на уровне языка.
Да, он все же скомпилируется. Мне представлялось, что range-for в данном случае развернется в такую конструкцию const auto& __begin = arr.begin() ; const auto& __end = arr.end() ; for ( ; __begin != __end; ++__begin) { const auto& it = *__begin; //loop-statement } Что очевидно не скомпилировалось бы, но с const для __begin и __end я погорячился, их не будет у них все же. Тем не менее практичней использовать запись for(auto&& it : arr)
@@VoiCedml сигнатура функции подразумевает, что внутри её теле рассматриваемый вектор будет lvalue, да и передают в нее аргумент через const lvalue reference
Это имеет какое-то значение? У меня на канале нет возрастного ограничения, любой человек может попробовать пройти собеседование, хоть в 5 лет, хоть в 105. Евгению 21 год и он показал отличный результат.
Он приятный и понимающий. Посмотри его другие собеседования, здесь может так кажется, я тоже заметил немного напряжения в нём, но я бы не назвал это пассивно-агрессивным поведением, у него могут быть свои трудности 😣. Он не грубил, был вежлив. Где-то подводил. Это очень профессионально. Особенно учитывая, что волнуются оба, то ведёт себя по человечески. Лично у меня он вызывает уважение. Приятно посмотреть. Я недавно проходил собеседование так там HR пассивно-агрессивно шутил, почти под каждым моим высказыванием. А тимлид вообще с надменным выражением лица сидел, а потом пошутил с улыбочкой на лице «ждите повестку» Может быть у каждого своё понимание «пассивной-агрессии». Но как по мне он очень хорош
Спасибо тебе за все что ты делашь, это очень полезный контент как для начинающего разработчика. Я сам уже давно ищу работу на позицию Junior C++ и был на многих собеседованиях. Это очень полезные видео, как для меня так точно. Жду в будущем стримов по разбору каких-нибудь легких и сложных задач с реализацией самой простой семантической сложности задач. Это было бы очень полезно.
@@НиколайЕвтушенко-д1ю 30-50к. Но на самом деле хоть бесплатно готов работать, очень нужен опыт работы для дальнейшей более песпективной зарплаты, но собеседования на которые я ходил предлагали 30-40 к
9:22 Какая-то путаница. Внутри методов дочернего класса будут видны поля и методы базового, но только public и protected. Т.е. private - наследование сделало все private из базового класса, но только для пользователя дочернего класса. Т.е. снаружи их не будет не видно. Самому дочернему классу будет видно все, что не в private-секции базового. Ну иначе тогда вообще смысла нет в таком наследовании) 16:20 Я понимаю, что собеседующий, видимо, хотел услышать про friend. Но кажется, что более логично организовать публичный конструктор для Child и юзать уже тип Child в клиентском коде. Да, чтобы обойтись без ошибки компиляции приведения типов, надо создавать объект типа Child, а не B. Просто по сути как-то и не логично пытаться достучаться до класса B, если мы его приватим. Здесь приватим, здесь сразу же френдим. 41:21 Спасибо. Освежил в памяти POD-типы. 50:22 По make_shared докину еще пять копеек, кому интересно. Можно почитать Мейерса про это дело: "Эффективный и современный С++". Где он рассказывает, почему make_shared не только хорош, но и плох. А именно своим этим эффектом по выделению памяти единым куском он по сути будет удерживать всю память от освобождения до уничтожения всех weak-поинтеров. Как говорится, все недостатки - это логическое продолжение достоинств) А в целом огромное спасибо за ролик, за потраченные силы. Недавно начал посматривать ваш канал, многому учусь) Очень познавательно и интересно. Парни, это очень важная работа и крайне полезный контент для специалистов и начинающих. Искренне желаю всяческих успехов авторам канала. Евгений - молодец. Уверен, что все у него сложится, как надо.
@@victorkrasnov5576 Это по какому-такому определению?) У нас тут одно определение - это плюсовый стандарт)
Нет, weak-поинтер не для этого. А для того, чтобы позволить объекту под шаредом быть уничтоженным (вызов деструктора), когда все шареды выйдут из области видимости, он для этого. Вообще, Мейерса исключительно рекомендую.
> Просто по сути как-то и не логично пытаться достучаться до класса B, если мы его приватим. Здесь приватим, здесь сразу же френдим. Для одной функции же только friend'им, не для всех. > А именно своим этим эффектом по выделению памяти единым куском он по сути будет удерживать всю память от освобождения до уничтожения всех weak-поинтеров. Иногда лучше самому выяснять такие вещи с помощью экспериментов, тогда будет понятно, что когда выгодно. Если поэкспериментировать с make_shared для классов различного размера и посмотреть, что происходит, станет понятнее, о чём я. Подавляющее большинство не проходили этот путь, поэтому принимают, в общем случае, неверный ответ, сами не понимая деталей, одну из которых вы упомянули.
9:21 Вы не правы - все public и protected поля базового класса, от которого наследуются через private, становятся private в дочернем классе, и доступны в его методах. P.S. Много полезного узнал из ваших роликов, спасибо.
36:40 Догадался чуть раньше, но ситуации "что имел в виду интервьювер/экзаменатор" всё же часто вводят в ступор. Общий ответ: "создать вторую исключающую ситуацию" порождает бесчисленное множество правильных, но частных ответов. Так можно перебрать тысячи вариантов, все из которых будут правильными, но не предполагаемыми второй стороной. Помню, давным-давно сдавал медицину, как дополнительный вопрос получил "признаки желтухи", из которых важнейшим экзаменатор посчитал цвет дерьма и поставил 4.
Ну, бывают такие ситуации, мне же не исключать какой-то вопрос только потому, что на него может быть несколько вариантов ответа. Ну и четверки я тут никому не ставлю) Был отличный уровень продемонстрирован.
В случае выброса исключения из деструктора произойдет утечка памяти, в случае удаления динамического объекта. Исключение вызовет разрыв цепи действий, которые нельзя разрывать. Вызов деструктора и освобождение памяти , если в деструкторе вылетит исключение, память останется не освобождённой. По этому всё деструкторы по умолчанию noexcept
Это случится только для неисправного компилятора, то есть, не соответствующего стандарту. #include #include #include #include struct S { S() { std::cout
@@billjohnes9380 Круто. Но суть в том что тезис правдив, ибо имя им легион тех кто пишет по MS. GCC тоже не ясно с какой версии исправен. В ходу можно и 4 встретить ещё. Иными словами , не дёргай смерть за усы, и не делай исключений в деструкторах , тем более что язык на это явно намекает, что так делать не нужно.
@@s.g.7213 Да пусть хоть вся Вселенная пишет, используя неисправный компилятор, -- это имеет строго нулевое значение. Тем более, что теперь есть исправная альтернатива (а раньше не было). Язык не намекает ни на какие смертельные усы, язык -- это стандарт, который ни на что не намекает. Более того, предоставляет средства для определения того, когда исключение безопасно выбросить, а когда -- нет. Стандарт и не может намекать, ибо программист -- царь и бог, и только он решает, что выбрать и как поступить. Возможно, вы слишком долго находились под властью Windows, и поэтому считаете нормальным, когда вам указывают, что выбрать. Это -- не нормально: только вы должны решать, и никто не может вас ограничивать в свободе выбора. Стандарт же задаёт рамки (описывает модель), в пределах которых вы можете решать.
@@billjohnes9380 Я никогда не писал под windows и более того никогда не имел его на домашнем компе. Тут мы приходим к философской теме, мы программируем для получения результата, то есть исправно работающей 24/7 программы, пусть даже собранной неисправным компилятором, или мы программируем ради программирования. В коммерческом коде не прокатит отмазка " у меня всё по стандарту, у вас компилятор неправильный" , никто не будет под разработчика менять компилятор, тем более в разработке встраиваемых решений . Мнение, что программист "царь и бог" ошибочно и применимо только в домашних проектах, "царь и бог" это coding standart. Сделаешь хитрый и интересный баг, найдём всей командой , и получим опыт. Навортишь лапшу с метками и исключениями в деструкторах , мотивируя что ты "царь и бог" , которая "внезапно" не всегда работает как ты задумал, получишь выговор , не поймешь , пойдешь искать работу.
@@s.g.7213 Значит, что-то другое вместо Windows оказало на вас аналогичное влияние. Если под Windows вы не программируете, то почти наверняка используете gcc или нечто производное. В крайнем случае -- clang и очень маловероятно, что Intel'овский icpc. Если не используете Intel'овский компилятор, то проблем в этом месте у вас не должно быть: gcc и clang в это месте исправны. Разве можно быть уверенным в результате, полученном путём использования неисправного компилятора? Если кто-то не будет менять компилятор при наличии веских причин его поменять, -- зачем с этим кем-то работать? Зачем плодить bug'и и "лапшу", да ещё и с какими-то метками? Coding standard -- вещь изменчивая, а стандарт языка определённой версии -- незыблемая, причём ещё и являющаяся единственным первоисточником. Над стандартом языка в течение многих лет работают сотни людей, весьма искушённых в C++, а кем пишутся coding standard'ы? Тот же Google так опростоволосился со своим coding standard'ом, запретив использовать исключения в C++, что это ещё не каждый так сумеет. Страх отступать от "проверенных решений" по причине того, что можно "нарваться", может быть вызван недостаточно глубоким знанием языка. Согласен, первые 10-15 лет с C++ трудно, и всё может работать не так как ожидается, но потом с этим становится уже явно легче. И в дальнейшем понимание, что новые решения следует сначала очень глубоко прорабатывать, прежде чем использовать, формируется автоматически. Апелляции к интересам бизнеса бессмысленны, это не имеет отношения ни к языку, ни к программированию. Бизнес способен уничтожить всё, к чему прикасается, ничего удивительного здесь нет. Кстати, какое у вас отношение к выбросу исключения в конструкторе применительно к случаю динамического массива? То есть, через new[] выделяется массив из N объектов, и все объекты, кроме последнего, конструируются успешно. А при конструировании последнего объекта из конструктора выбрасывается исключение. Вы тоже думаете, что здесь будет утечка? Если вернуться к деструкторам и рассмотреть следующий случай: имеется базовый класс A и производный B, который унаследован от A. Где-то как-то был создан экземпляр класса B и в данный момент он уничтожается, что приводит к вызову деструкторов, сначала класса B, а затем класса A. Если в деструкторе класса B выбрасывается исключение, -- вы считаете, что здесь тоже произойдёт разрыв цепи действий, и деструктор A не будет вызван?
Сколько раз в реальном коде Вы видели protected наследование? И на 17:57 - парень сказал верно, в данном случае (как и для всех контейнеров стандартной библиотеки) будет итератор. POD на джуна 😂
Задача с поиском максимума описана не полностью, тут важно понимать - это ошибка использования или не корректные извне данные. В первом случае должен быть assert на размер массива, во втором случае должна быть проверка в вызывающем коде
Такой вопрос попадается на собеседованиях. Показывает эрудицию кандидата в теме ООП. Плюс можно понаблюдать как человек думает, какие ассоциации строит, какие параллели проводит при ответе на данный вопрос.
Спасибо обоим! Сложное интервью было конечно… Молодцы. Хорошо отвечал и вопросы хорошие 👍 Отличная идея с добавлением статей в описание, очень упрощает поиск!
22:46 лучше вернуть std::optional и возвращать в случае отстутствия nullopt. И очень странно,что не рассматривается никак concurrency хотя бы базовые понятия, проблемы многопоточный синхронизации( deadlock,datarace,race condition, starvation, raii, conditional variable ). А так автор молодец,как и собеседуемый. Интересно собеседование middle c++)
Здравствуйте, не могу дождаться стрима, хочу задать вопрос. Вы говорили, что при трудоустройстве в Европе, позарез нужен диплом, так вот вопрос, а насколько котируются дипломы Среднего Профессионального Образования (колледжи и т.п., не вышка)?
не сказал бы, я собесов ни разу не проходил и только учу, но все это знаю и отвечаю быстрее, хотя понятно, что он жестко нервничал, аж запинался, я бы тоже тупил наверное
Можно конечно написать свои "велосипеды" и использовать их вместо стандартных алгоритмов в случае если нужно много поточное выполнение к примеру того же поиска. Гораздо быстрее будет написать функцию обертку которая внутри себя создаст несколько потоков и разобьет тот же массив на к примеру на пять потоков, найдет в них максимум (к примеру), и из этих пяти значений найти также максимум и вернуть. Это так на вскидку для чего можно писать "велосипеды". так сказать многопоточный std::find или std::min
Можешь сделать видео на тему: чем занимается junior c++, какие его задачи и типичные задания для джуна. Может с примерами из своего опыта
Очень полезный контент, спасибо большое за труды, очень интересно наблюдать за процессом, подмечая для себя много нужных вещей. Еще раз спасибо, продолжай в том же духе!
Ничего себе, Оксимирон перестал писать песни, пошёл в программисты и собиседует кашу
Огромное спасибо, то что нужно сейчас. Не останавливайся. Ты главное делай, хоть иногда...)
Я изучал С++ 15 лет назад и почти все забыл, так как перешел на PHP, но все равно посмотреть это видео было интересно ))
Спасибо за контент
Позавите на собес по плюсам пж, пж, пж, пж)
"знаю 11, 14 стандарт 100%"
какой самоуверенный кандидат
9:18
Он же говорит про публичные и защищенные поля базового класса, при приватном наследовании у дочернего класса конечно же будет доступ к этим полям. Приватными они станут на уровне дочернего класса. В противном случае в таком наследовании не было бы никакого смысла, ведь дочерний класс не смог бы даже конструктор своего родителя вызвать.
17:34
̶К̶а̶к̶о̶й̶ ̶c̶o̶n̶s̶t̶.̶ ̶Г̶р̶у̶б̶а̶я̶ ̶о̶ш̶и̶б̶к̶а̶.̶ ̶К̶о̶д̶ ̶н̶е̶ ̶с̶к̶о̶м̶п̶и̶л̶и̶р̶у̶е̶т̶с̶я̶. Все нормально.
32:10
Деление на ноль не бросает исключение на уровне языка.
С чего бы это const на 17:34 не скомпилируется?
Да, он все же скомпилируется. Мне представлялось, что range-for в данном случае развернется в такую конструкцию
const auto& __begin = arr.begin() ;
const auto& __end = arr.end() ;
for ( ; __begin != __end; ++__begin) {
const auto& it = *__begin;
//loop-statement
}
Что очевидно не скомпилировалось бы, но с const для __begin и __end я погорячился, их не будет у них все же.
Тем не менее практичней использовать запись for(auto&& it : arr)
@@VoiCedml сигнатура функции подразумевает, что внутри её теле рассматриваемый вектор будет lvalue, да и передают в нее аргумент через const lvalue reference
А смотреть в шпоры это норм на собеседовании? Если все слепые или разрешают такое то это гуд
Это норм
Не видно нихера, что написано в этом CodeShare (((
ему 15 лет?
Это имеет какое-то значение? У меня на канале нет возрастного ограничения, любой человек может попробовать пройти собеседование, хоть в 5 лет, хоть в 105. Евгению 21 год и он показал отличный результат.
Какой же пассивно агрессивный собеседующий. Надеюсь он не проводит секции, это ужасно
вы серьёзно?
Это либо сарказм, либо вы не встречались с агрессивными собеседующими.
Он приятный и понимающий. Посмотри его другие собеседования, здесь может так кажется, я тоже заметил немного напряжения в нём, но я бы не назвал это пассивно-агрессивным поведением, у него могут быть свои трудности 😣. Он не грубил, был вежлив. Где-то подводил. Это очень профессионально. Особенно учитывая, что волнуются оба, то ведёт себя по человечески.
Лично у меня он вызывает уважение. Приятно посмотреть.
Я недавно проходил собеседование так там HR пассивно-агрессивно шутил, почти под каждым моим высказыванием. А тимлид вообще с надменным выражением лица сидел, а потом пошутил с улыбочкой на лице «ждите повестку»
Может быть у каждого своё понимание «пассивной-агрессии». Но как по мне он очень хорош
хз почему тебе так показалось, мб у него просто лицо серьезное и тебе так показалось. Вообще без духоты собесы у него
Из садика подключился?
аххахах
🤡🤡🤡🤡🤡🤡
Спасибо тебе за все что ты делашь, это очень полезный контент как для начинающего разработчика. Я сам уже давно ищу работу на позицию Junior C++ и был на многих собеседованиях. Это очень полезные видео, как для меня так точно. Жду в будущем стримов по разбору каких-нибудь легких и сложных задач с реализацией самой простой семантической сложности задач. Это было бы очень полезно.
На какую зп рассчитываешь?
@@НиколайЕвтушенко-д1ю 30-50к. Но на самом деле хоть бесплатно готов работать, очень нужен опыт работы для дальнейшей более песпективной зарплаты, но собеседования на которые я ходил предлагали 30-40 к
@@drowndream7761 ну как? нашёл ?
Как успехи?
смог?
28:34 - шта? Велосипед, реализующий поиск максимального элемента, будет компактнее max_element?
9:22 Какая-то путаница. Внутри методов дочернего класса будут видны поля и методы базового, но только public и protected. Т.е. private - наследование сделало все private из базового класса, но только для пользователя дочернего класса. Т.е. снаружи их не будет не видно. Самому дочернему классу будет видно все, что не в private-секции базового. Ну иначе тогда вообще смысла нет в таком наследовании)
16:20 Я понимаю, что собеседующий, видимо, хотел услышать про friend. Но кажется, что более логично организовать публичный конструктор для Child и юзать уже тип Child в клиентском коде. Да, чтобы обойтись без ошибки компиляции приведения типов, надо создавать объект типа Child, а не B. Просто по сути как-то и не логично пытаться достучаться до класса B, если мы его приватим. Здесь приватим, здесь сразу же френдим.
41:21 Спасибо. Освежил в памяти POD-типы.
50:22 По make_shared докину еще пять копеек, кому интересно. Можно почитать Мейерса про это дело: "Эффективный и современный С++". Где он рассказывает, почему make_shared не только хорош, но и плох. А именно своим этим эффектом по выделению памяти единым куском он по сути будет удерживать всю память от освобождения до уничтожения всех weak-поинтеров. Как говорится, все недостатки - это логическое продолжение достоинств)
А в целом огромное спасибо за ролик, за потраченные силы. Недавно начал посматривать ваш канал, многому учусь) Очень познавательно и интересно. Парни, это очень важная работа и крайне полезный контент для специалистов и начинающих. Искренне желаю всяческих успехов авторам канала.
Евгений - молодец. Уверен, что все у него сложится, как надо.
weak пойнтеры - это ж как раз для того чтобы shared пойнтер не держал память. По определению.
@@victorkrasnov5576 Это по какому-такому определению?) У нас тут одно определение - это плюсовый стандарт)
Нет, weak-поинтер не для этого. А для того, чтобы позволить объекту под шаредом быть уничтоженным (вызов деструктора), когда все шареды выйдут из области видимости, он для этого. Вообще, Мейерса исключительно рекомендую.
> Просто по сути как-то и не логично пытаться достучаться до класса B, если мы его приватим. Здесь приватим, здесь сразу же френдим.
Для одной функции же только friend'им, не для всех.
> А именно своим этим эффектом по выделению памяти единым куском он по сути будет удерживать всю память от освобождения до уничтожения всех weak-поинтеров.
Иногда лучше самому выяснять такие вещи с помощью экспериментов, тогда будет понятно, что когда выгодно.
Если поэкспериментировать с make_shared для классов различного размера и посмотреть, что происходит, станет понятнее, о чём я.
Подавляющее большинство не проходили этот путь, поэтому принимают, в общем случае, неверный ответ, сами не понимая деталей, одну из которых вы упомянули.
Про POD типы спросите сеньоров, удивитесь :)
9:21 Вы не правы - все public и protected поля базового класса, от которого наследуются через private, становятся private в дочернем классе, и доступны в его методах.
P.S. Много полезного узнал из ваших роликов, спасибо.
Здравствуйте! Все верно по поводу наследования, спасибо за информацию.
Спасибо за отзыв)
Эта часть ужасна конечно и вся аргументация в этой секции неправильная
36:40 Догадался чуть раньше, но ситуации "что имел в виду интервьювер/экзаменатор" всё же часто вводят в ступор. Общий ответ: "создать вторую исключающую ситуацию" порождает бесчисленное множество правильных, но частных ответов. Так можно перебрать тысячи вариантов, все из которых будут правильными, но не предполагаемыми второй стороной. Помню, давным-давно сдавал медицину, как дополнительный вопрос получил "признаки желтухи", из которых важнейшим экзаменатор посчитал цвет дерьма и поставил 4.
Ну, бывают такие ситуации, мне же не исключать какой-то вопрос только потому, что на него может быть несколько вариантов ответа.
Ну и четверки я тут никому не ставлю) Был отличный уровень продемонстрирован.
Спасибо большое Дмитрию и Евгению за видео!)
Евгений большой молодец!!!
Предлагаю дополнительно вводить 1-2 задачки с литкода
я думал ему 15
В случае выброса исключения из деструктора произойдет утечка памяти, в случае удаления динамического объекта. Исключение вызовет разрыв цепи действий, которые нельзя разрывать. Вызов деструктора и освобождение памяти , если в деструкторе вылетит исключение, память останется не освобождённой.
По этому всё деструкторы по умолчанию noexcept
Это случится только для неисправного компилятора, то есть, не соответствующего стандарту.
#include
#include
#include
#include
struct S {
S() {
std::cout
@@billjohnes9380 Круто.
Но суть в том что тезис правдив, ибо имя им легион тех кто пишет по MS.
GCC тоже не ясно с какой версии исправен. В ходу можно и 4 встретить ещё.
Иными словами , не дёргай смерть за усы, и не делай исключений в деструкторах , тем более что язык на это явно намекает, что так делать не нужно.
@@s.g.7213 Да пусть хоть вся Вселенная пишет, используя неисправный компилятор, -- это имеет строго нулевое значение.
Тем более, что теперь есть исправная альтернатива (а раньше не было).
Язык не намекает ни на какие смертельные усы, язык -- это стандарт, который ни на что не намекает.
Более того, предоставляет средства для определения того, когда исключение безопасно выбросить, а когда -- нет.
Стандарт и не может намекать, ибо программист -- царь и бог, и только он решает, что выбрать и как поступить.
Возможно, вы слишком долго находились под властью Windows, и поэтому считаете нормальным, когда вам указывают, что выбрать.
Это -- не нормально: только вы должны решать, и никто не может вас ограничивать в свободе выбора.
Стандарт же задаёт рамки (описывает модель), в пределах которых вы можете решать.
@@billjohnes9380 Я никогда не писал под windows и более того никогда не имел его на домашнем компе.
Тут мы приходим к философской теме, мы программируем для получения результата, то есть исправно работающей 24/7 программы, пусть даже собранной неисправным компилятором, или мы программируем ради программирования.
В коммерческом коде не прокатит отмазка " у меня всё по стандарту, у вас компилятор неправильный" , никто не будет под разработчика менять компилятор, тем более в разработке встраиваемых решений .
Мнение, что программист "царь и бог" ошибочно и применимо только в домашних проектах, "царь и бог" это coding standart. Сделаешь хитрый и интересный баг, найдём всей командой , и получим опыт. Навортишь лапшу с метками и исключениями в деструкторах , мотивируя что ты "царь и бог" , которая "внезапно" не всегда работает как ты задумал, получишь выговор , не поймешь , пойдешь искать работу.
@@s.g.7213 Значит, что-то другое вместо Windows оказало на вас аналогичное влияние.
Если под Windows вы не программируете, то почти наверняка используете gcc или нечто производное.
В крайнем случае -- clang и очень маловероятно, что Intel'овский icpc.
Если не используете Intel'овский компилятор, то проблем в этом месте у вас не должно быть: gcc и clang в это месте исправны.
Разве можно быть уверенным в результате, полученном путём использования неисправного компилятора?
Если кто-то не будет менять компилятор при наличии веских причин его поменять, -- зачем с этим кем-то работать?
Зачем плодить bug'и и "лапшу", да ещё и с какими-то метками?
Coding standard -- вещь изменчивая, а стандарт языка определённой версии -- незыблемая, причём ещё и являющаяся единственным первоисточником.
Над стандартом языка в течение многих лет работают сотни людей, весьма искушённых в C++, а кем пишутся coding standard'ы?
Тот же Google так опростоволосился со своим coding standard'ом, запретив использовать исключения в C++, что это ещё не каждый так сумеет.
Страх отступать от "проверенных решений" по причине того, что можно "нарваться", может быть вызван недостаточно глубоким знанием языка.
Согласен, первые 10-15 лет с C++ трудно, и всё может работать не так как ожидается, но потом с этим становится уже явно легче.
И в дальнейшем понимание, что новые решения следует сначала очень глубоко прорабатывать, прежде чем использовать, формируется автоматически.
Апелляции к интересам бизнеса бессмысленны, это не имеет отношения ни к языку, ни к программированию.
Бизнес способен уничтожить всё, к чему прикасается, ничего удивительного здесь нет.
Кстати, какое у вас отношение к выбросу исключения в конструкторе применительно к случаю динамического массива?
То есть, через new[] выделяется массив из N объектов, и все объекты, кроме последнего, конструируются успешно.
А при конструировании последнего объекта из конструктора выбрасывается исключение.
Вы тоже думаете, что здесь будет утечка?
Если вернуться к деструкторам и рассмотреть следующий случай: имеется базовый класс A и производный B, который унаследован от A.
Где-то как-то был создан экземпляр класса B и в данный момент он уничтожается, что приводит к вызову деструкторов, сначала класса B, а затем класса A.
Если в деструкторе класса B выбрасывается исключение, -- вы считаете, что здесь тоже произойдёт разрыв цепи действий, и деструктор A не будет вызван?
видео долго стояло на паузе, перед тем как начал смотреть и я думал что пареньку лет 16, а потом он начал говорить
Сколько раз в реальном коде Вы видели protected наследование? И на 17:57 - парень сказал верно, в данном случае (как и для всех контейнеров стандартной библиотеки) будет итератор. POD на джуна 😂
16:48. Здравствуйте, а почему у Child нет круглых скобок? B* b = new Child;
Это допустимый синтаксис, если конструктор по умолчанию или без параметров. Такой синтаксический сахар.
Дмитрий на оксимирона похож)
виндертон решил реально заняться программированием
41:00 я бы ответил, что в классе CD конструктор constexpr и noexcept аннотирован
Задача с поиском максимума описана не полностью, тут важно понимать - это ошибка использования или не корректные извне данные. В первом случае должен быть assert на размер массива, во втором случае должна быть проверка в вызывающем коде
)) пошел учить html)).
Написал python на html
Спасибо за очень интересный диалог.Ещё бы несколько раз бы пересмотрел!
Зачем нужны вопросы про неоткрытое наследование? Что они говорят о кандидате?
Такой вопрос попадается на собеседованиях. Показывает эрудицию кандидата в теме ООП. Плюс можно понаблюдать как человек думает, какие ассоциации строит, какие параллели проводит при ответе на данный вопрос.
крутая тема контекта) продолжай и дальше) спасибо)
Спасибо обоим! Сложное интервью было конечно… Молодцы. Хорошо отвечал и вопросы хорошие 👍
Отличная идея с добавлением статей в описание, очень упрощает поиск!
Спасибо
а прошел он нет?
Это же тестовое, человек пришел себя проверить) Получается, что в любом случае прошел.
Результат хороший.
Жду ещё роликов
22:46 лучше вернуть std::optional и возвращать в случае отстутствия nullopt. И очень странно,что не рассматривается никак concurrency хотя бы базовые понятия, проблемы многопоточный синхронизации( deadlock,datarace,race condition, starvation, raii, conditional variable ). А так автор молодец,как и собеседуемый. Интересно собеседование middle c++)
Здравствуйте, не могу дождаться стрима, хочу задать вопрос. Вы говорили, что при трудоустройстве в Европе, позарез нужен диплом, так вот вопрос, а насколько котируются дипломы Среднего Профессионального Образования (колледжи и т.п., не вышка)?
Здравствуйте. Сложный вопрос. У каждой страны свои законы, квоты и прочее. Надо изучать страны отдельно.
Наши дипломы не котируются.
ну чувак подкован
не сказал бы, я собесов ни разу не проходил и только учу, но все это знаю и отвечаю быстрее, хотя понятно, что он жестко нервничал, аж запинался, я бы тоже тупил наверное
Почему Карпов собеседует джуниоров?)
Или все таки Оксимирон?
Можно конечно написать свои "велосипеды" и использовать их вместо стандартных алгоритмов в случае если нужно много поточное выполнение к примеру того же поиска.
Гораздо быстрее будет написать функцию обертку которая внутри себя создаст несколько потоков и разобьет тот же массив на к примеру на пять потоков, найдет в них максимум (к примеру), и из этих пяти значений найти также максимум и вернуть. Это так на вскидку для чего можно писать "велосипеды". так сказать многопоточный std::find или std::min