Можешь сделать видео на тему: чем занимается junior c++, какие его задачи и типичные задания для джуна. Может с примерами из своего опыта

Очень полезный контент, спасибо большое за труды, очень интересно наблюдать за процессом, подмечая для себя много нужных вещей. Еще раз спасибо, продолжай в том же духе!

Спасибо большое Дмитрию и Евгению за видео!) Евгений большой молодец!!!

Огромное спасибо, то что нужно сейчас. Не останавливайся. Ты главное делай, хоть иногда...)

Спасибо за очень интересный диалог.Ещё бы несколько раз бы пересмотрел!

крутая тема контекта) продолжай и дальше) спасибо)

Спасибо за контент

Спасибо тебе за все что ты делашь, это очень полезный контент как для начинающего разработчика. Я сам уже давно ищу работу на позицию Junior C++ и был на многих собеседованиях. Это очень полезные видео, как для меня так точно. Жду в будущем стримов по разбору каких-нибудь легких и сложных задач с реализацией самой простой семантической сложности задач. Это было бы очень полезно.

@user-bq7zb2oj2m

Жыл бұрын

На какую зп рассчитываешь?

@drowndream7761

Жыл бұрын

@@user-bq7zb2oj2m 30-50к. Но на самом деле хоть бесплатно готов работать, очень нужен опыт работы для дальнейшей более песпективной зарплаты, но собеседования на которые я ходил предлагали 30-40 к

@user-de8fm3hx5i

Жыл бұрын

@@drowndream7761 ну как? нашёл ?

@user-db2mk5dq3k

7 ай бұрын

Как успехи?

@nirvandgupshob5476

3 ай бұрын

смог?

Спасибо обоим! Сложное интервью было конечно… Молодцы. Хорошо отвечал и вопросы хорошие 👍 Отличная идея с добавлением статей в описание, очень упрощает поиск!

28:34 - шта? Велосипед, реализующий поиск максимального элемента, будет компактнее max_element?

Я изучал С++ 15 лет назад и почти все забыл, так как перешел на PHP, но все равно посмотреть это видео было интересно ))

Жду ещё роликов

Спасибо

Про POD типы спросите сеньоров, удивитесь :)

36:40 Догадался чуть раньше, но ситуации "что имел в виду интервьювер/экзаменатор" всё же часто вводят в ступор. Общий ответ: "создать вторую исключающую ситуацию" порождает бесчисленное множество правильных, но частных ответов. Так можно перебрать тысячи вариантов, все из которых будут правильными, но не предполагаемыми второй стороной. Помню, давным-давно сдавал медицину, как дополнительный вопрос получил "признаки желтухи", из которых важнейшим экзаменатор посчитал цвет дерьма и поставил 4.

@ambushedraccoon6408

10 ай бұрын

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

Предлагаю дополнительно вводить 1-2 задачки с литкода

Задача с поиском максимума описана не полностью, тут важно понимать - это ошибка использования или не корректные извне данные. В первом случае должен быть assert на размер массива, во втором случае должна быть проверка в вызывающем коде

9:21 Вы не правы - все public и protected поля базового класса, от которого наследуются через private, становятся private в дочернем классе, и доступны в его методах. P.S. Много полезного узнал из ваших роликов, спасибо.

@ambushedraccoon6408

2 ай бұрын

Здравствуйте! Все верно по поводу наследования, спасибо за информацию. Спасибо за отзыв)

В случае выброса исключения из деструктора произойдет утечка памяти, в случае удаления динамического объекта. Исключение вызовет разрыв цепи действий, которые нельзя разрывать. Вызов деструктора и освобождение памяти , если в деструкторе вылетит исключение, память останется не освобождённой. По этому всё деструкторы по умолчанию noexcept

@billjohnes9380

Жыл бұрын

Это случится только для неисправного компилятора, то есть, не соответствующего стандарту. #include #include #include #include struct S { S() { std::cout

@s.g.7213

Жыл бұрын

@@billjohnes9380 Круто. Но суть в том что тезис правдив, ибо имя им легион тех кто пишет по MS. GCC тоже не ясно с какой версии исправен. В ходу можно и 4 встретить ещё. Иными словами , не дёргай смерть за усы, и не делай исключений в деструкторах , тем более что язык на это явно намекает, что так делать не нужно.

@billjohnes9380

Жыл бұрын

@@s.g.7213 Да пусть хоть вся Вселенная пишет, используя неисправный компилятор, -- это имеет строго нулевое значение. Тем более, что теперь есть исправная альтернатива (а раньше не было). Язык не намекает ни на какие смертельные усы, язык -- это стандарт, который ни на что не намекает. Более того, предоставляет средства для определения того, когда исключение безопасно выбросить, а когда -- нет. Стандарт и не может намекать, ибо программист -- царь и бог, и только он решает, что выбрать и как поступить. Возможно, вы слишком долго находились под властью Windows, и поэтому считаете нормальным, когда вам указывают, что выбрать. Это -- не нормально: только вы должны решать, и никто не может вас ограничивать в свободе выбора. Стандарт же задаёт рамки (описывает модель), в пределах которых вы можете решать.

@s.g.7213

Жыл бұрын

@@billjohnes9380 Я никогда не писал под windows и более того никогда не имел его на домашнем компе. Тут мы приходим к философской теме, мы программируем для получения результата, то есть исправно работающей 24/7 программы, пусть даже собранной неисправным компилятором, или мы программируем ради программирования. В коммерческом коде не прокатит отмазка " у меня всё по стандарту, у вас компилятор неправильный" , никто не будет под разработчика менять компилятор, тем более в разработке встраиваемых решений . Мнение, что программист "царь и бог" ошибочно и применимо только в домашних проектах, "царь и бог" это coding standart. Сделаешь хитрый и интересный баг, найдём всей командой , и получим опыт. Навортишь лапшу с метками и исключениями в деструкторах , мотивируя что ты "царь и бог" , которая "внезапно" не всегда работает как ты задумал, получишь выговор , не поймешь , пойдешь искать работу.

@billjohnes9380

Жыл бұрын

​@@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 не будет вызван?

виндертон решил реально заняться программированием

Собеседуемый junior: "знаю 11, 14 стандарт 100%, 17й отчасти... всякие новые фишки по типу any..." Сеньоры в крупной корпорации работующие с древним проектом, куда постучался 11й стандарт, но добрая половина кода использует malloc(), а треть new: "Oo", "Нифига себе, круто" Теорию Евгений ответил на отлично, даже больше чем на уровень junior. Если в компании будут спрашивать теорию по плюсам, то этот этап он пройдет. Хотя всегда остается рандом, из-за того, что соискатель случайно не угадает, какой ответ от него хотят слышать, телепатия ведь не всем дана. Только вот спрашивать скорее будут не только теорию по плюсам, а еще и по смежным технологиям. Ну какой смысл продолжать спрашивать по C++, когда понятно что человек выучил, знает, и при том есть еще десяток инструментов и технологий с которыми команда работает. Естественно попытаться узнать, работал ли человек с ними, может он на подобном стеке собаку сьел, и нужно срочно его нанимать, не любой ценой конечно, но нужно.

@mrbibis7229

Жыл бұрын

а я вот очень скептически отношусь к людям, которые будут утверждать что знают хоть какой-то стандарт плюсов на 100%, уж тем более 11-й и будучи Джуном. Возможно имелось в виду STL библиотека дополняемая в этих стандартах, но все-равно это странно звучит...

@Nandarion

Жыл бұрын

@@mrbibis7229 Знание стандарта, это как знание теории - это хорошо. Человек, знающий теорию легче осваивает практику, да и не тратит время на теорию.

@mrbibis7229

Жыл бұрын

@@Nandarion знание стандарта новичку точно не нужно, это оверзубреш какой-то. Зачем ему знать новые виды UB в 23 стандарте, например?

Сколько раз в реальном коде Вы видели protected наследование? И на 17:57 - парень сказал верно, в данном случае (как и для всех контейнеров стандартной библиотеки) будет итератор. POD на джуна 😂

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 пойнтеры - это ж как раз для того чтобы shared пойнтер не держал память. По определению.

@user-cb8nc5to4z

Жыл бұрын

@@victorkrasnov5576 ​ Это по какому-такому определению?) У нас тут одно определение - это плюсовый стандарт) Нет, weak-поинтер не для этого. А для того, чтобы позволить объекту под шаредом быть уничтоженным (вызов деструктора), когда все шареды выйдут из области видимости, он для этого. Вообще, Мейерса исключительно рекомендую.

@billjohnes9380

Жыл бұрын

> Просто по сути как-то и не логично пытаться достучаться до класса B, если мы его приватим. Здесь приватим, здесь сразу же френдим. Для одной функции же только friend'им, не для всех. > А именно своим этим эффектом по выделению памяти единым куском он по сути будет удерживать всю память от освобождения до уничтожения всех weak-поинтеров. Иногда лучше самому выяснять такие вещи с помощью экспериментов, тогда будет понятно, что когда выгодно. Если поэкспериментировать с make_shared для классов различного размера и посмотреть, что происходит, станет понятнее, о чём я. Подавляющее большинство не проходили этот путь, поэтому принимают, в общем случае, неверный ответ, сами не понимая деталей, одну из которых вы упомянули.

Не видно нихера, что написано в этом CodeShare (((

16:48. Здравствуйте, а почему у Child нет круглых скобок? B* b = new Child;

@ambushedraccoon6408

7 ай бұрын

Это допустимый синтаксис, если конструктор по умолчанию или без параметров. Такой синтаксический сахар.

Здравствуйте, не могу дождаться стрима, хочу задать вопрос. Вы говорили, что при трудоустройстве в Европе, позарез нужен диплом, так вот вопрос, а насколько котируются дипломы Среднего Профессионального Образования (колледжи и т.п., не вышка)?

@ambushedraccoon6408

Жыл бұрын

Здравствуйте. Сложный вопрос. У каждой страны свои законы, квоты и прочее. Надо изучать страны отдельно.

@user-tr9rx9zp2o

Жыл бұрын

Наши дипломы не котируются.

Позавите на собес по плюсам пж, пж, пж, пж)

видео долго стояло на паузе, перед тем как начал смотреть и я думал что пареньку лет 16, а потом он начал говорить

А смотреть в шпоры это норм на собеседовании? Если все слепые или разрешают такое то это гуд

@aidanhouk

Жыл бұрын

Это норм

)) пошел учить html)).

@user-jr1qc5je6f

7 ай бұрын

Написал python на html

22:46 лучше вернуть std::optional и возвращать в случае отстутствия nullopt. И очень странно,что не рассматривается никак concurrency хотя бы базовые понятия, проблемы многопоточный синхронизации( deadlock,datarace,race condition, starvation, raii, conditional variable ). А так автор молодец,как и собеседуемый. Интересно собеседование middle c++)

@Nandarion

Жыл бұрын

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

Дмитрий на оксимирона похож)

я думал ему 15

а прошел он нет?

ну чувак подкован

@TurboGamasek228

Ай бұрын

не сказал бы, я собесов ни разу не проходил и только учу, но все это знаю и отвечаю быстрее, хотя понятно, что он жестко нервничал, аж запинался, я бы тоже тупил наверное

ему 15 лет?

@ambushedraccoon6408

Жыл бұрын

Это имеет какое-то значение? У меня на канале нет возрастного ограничения, любой человек может попробовать пройти собеседование, хоть в 5 лет, хоть в 105. Евгению 21 год и он показал отличный результат.

Какой же пассивно агрессивный собеседующий. Надеюсь он не проводит секции, это ужасно

@FULLlouich

Жыл бұрын

вы серьёзно?

@user-ih4ne2zx2i

Жыл бұрын

Это либо сарказм, либо вы не встречались с агрессивными собеседующими.

@nikitafamily5341

Жыл бұрын

Он приятный и понимающий. Посмотри его другие собеседования, здесь может так кажется, я тоже заметил немного напряжения в нём, но я бы не назвал это пассивно-агрессивным поведением, у него могут быть свои трудности 😣. Он не грубил, был вежлив. Где-то подводил. Это очень профессионально. Особенно учитывая, что волнуются оба, то ведёт себя по человечески. Лично у меня он вызывает уважение. Приятно посмотреть. Я недавно проходил собеседование так там HR пассивно-агрессивно шутил, почти под каждым моим высказыванием. А тимлид вообще с надменным выражением лица сидел, а потом пошутил с улыбочкой на лице «ждите повестку» Может быть у каждого своё понимание «пассивной-агрессии». Но как по мне он очень хорош

@mrbibis7229

Жыл бұрын

хз почему тебе так показалось, мб у него просто лицо серьезное и тебе так показалось. Вообще без духоты собесы у него

"знаю 11, 14 стандарт 100%" какой самоуверенный кандидат 9:18 Он же говорит про публичные и защищенные поля базового класса, при приватном наследовании у дочернего класса конечно же будет доступ к этим полям. Приватными они станут на уровне дочернего класса. В противном случае в таком наследовании не было бы никакого смысла, ведь дочерний класс не смог бы даже конструктор своего родителя вызвать. 17:34 ̶К̶а̶к̶о̶й̶ ̶c̶o̶n̶s̶t̶.̶ ̶Г̶р̶у̶б̶а̶я̶ ̶о̶ш̶и̶б̶к̶а̶.̶ ̶К̶о̶д̶ ̶н̶е̶ ̶с̶к̶о̶м̶п̶и̶л̶и̶р̶у̶е̶т̶с̶я̶. Все нормально. 32:10 Деление на ноль не бросает исключение на уровне языка.

@iSammax

Жыл бұрын

С чего бы это const на 17:34 не скомпилируется?

@VoiCedml

Жыл бұрын

Да, он все же скомпилируется. Мне представлялось, что 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)

@decltruft2882

Жыл бұрын

@@VoiCedml сигнатура функции подразумевает, что внутри её теле рассматриваемый вектор будет lvalue, да и передают в нее аргумент через const lvalue reference

Почему Карпов собеседует джуниоров?)

@decltruft2882

Жыл бұрын

Или все таки Оксимирон?

Из садика подключился?

@GOEchAWI

Жыл бұрын

аххахах

@astkh4381

Жыл бұрын

🤡🤡🤡🤡🤡🤡

Можно конечно написать свои "велосипеды" и использовать их вместо стандартных алгоритмов в случае если нужно много поточное выполнение к примеру того же поиска. Гораздо быстрее будет написать функцию обертку которая внутри себя создаст несколько потоков и разобьет тот же массив на к примеру на пять потоков, найдет в них максимум (к примеру), и из этих пяти значений найти также максимум и вернуть. Это так на вскидку для чего можно писать "велосипеды". так сказать многопоточный std::find или std::min