LINUX.ORG.RU

Что отличает юниора от более продвинутого

 , скиллы


3

7

Начнем с такого вопроса: существует ли вообще такое понятие как «разработчик на C++ среднего уровня». Все знают, что есть junior и senior, но o промежуточном варианте я как-то не слышал.

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

★★★★★
Ответ на: комментарий от RazrFalcon

Тут дело не в языке. Люди спорят - не понимая нихрена ни в теме спора, ни вообще в чём-либо ещё. А по поводу языков - любой, который делает префолт. Такое я видел по моему даже в го.

Единственная причина которая спасает от падения кресты на простом заполнении вектора - это лак, а вернее эвристика в ядре. А рано или поздно это днище из ядра выпилят и что тогда начнётся. Поцаны уже потихоньку начинают пользоваться достижениями последних 20+лет и 10лет в массовом применении.

А по поводу крестов. По идее логика крестов подразумевает префолт, но почему его нет? А я тебе отвечу. Дело в том, что любой крестовик знает как расчёт каписити у вектора. И все варят в то, что какая-то там память выделяется и капасити отражает занимаемый объём памяти вектором.

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

И если в аллокатор добавить префолт - т.е. заставить new выделять столько памяти, сколько ты написал - потребление памяти твоими крестами вырастет на «50%». Такие дела.

А так получить в реальной программе бедаллок практически невозможно. На дефолтном аллокаторе ты физически его получить на блоках <4k не можешь, да и не на дефолтном скорее всего то же. На больших блоках тебе может фортануть в однопоточной среде и не фортанёт в многопоточной.

Не фортанёт в однопоточной среде тебе лишь из-за гениального решения с капасити, но тут ты словишь другие приключения. Если у тебя 32гб памяти ты попытаешься заполнить вектор до >16gb на крестах - у тебя ничего не выйдет. Ты свалишься в бедаллок.

Объясню подробнее ситуацию с «гениальным решением». Дело в том, что когда ты реалоцируешь память и начинаешь её заполнять - кто-то другой( в другом потоке/процессе) может её у тебя забрать. Дак вот это решение, которое не позволяет тебе использовать более 50%( т.е. 100% от того, что у тебя сейчас есть) твоей памяти уменьшает твои шансы на то, что у тебя кто-то отнимет эту память - т.к. ещё 16гигов свободные.

Единственная твоя возможность это сделать - изменить капасити руками, а это значит, что твоя защита ввиде 16гб исчезает. Поменяй ты капасити на 30гигов, то теперь другим процессам надо потратить всего 2+гига памяти, а не 16+, чтобы поставить раком систему.

Если ты думаешь, что это нерешаемая проблема, либо вообще какая-то проблема есть - это не так. Просто на неё забили в мире крестов и во всём остальном мире. 99% крестовиков о ней не знают, те кто знают - не верят. Им проще верить в то, что обработай они своё исключение - это им даст какие-то гарантии.

Ведь им не нужны гарантии - им нужен только трёп. А были бы нужны - они бы такую херню не несли. И жопа моя болит не из-за того, что крестовик чего-то не знает/понимает. А из-за того, что крестовик декларирует противоречащие реальности вещи. Выдавая свою бесполезную херню за решение, которое решает проблему. Он верить в неё может сколько угодно, но выдавать её за правду и требовать с других - это убого.-

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

Поэтому я и говорю, что исключения бесполезны. Всё аргументация обычно сводится к «а как обрабатывать OOM?». Да никак. Если я открываю виртуалку, и она у меня забирает больше памяти, чем у меня есть физически - то весь мой любимый линукс преспокойно падает (другие ОС тоже). И если я вдруг успею убить VM из TTY1, то я останусь с фактически нерабочими кедами, так как половина процессов преспокойно упало.

Но KDE на «убогом» Qt, как считают некоторые, а значит всё норм.

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

Поэтому я и говорю, что исключения бесполезны.

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

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

Исключения - это просто нелокальные переходы. Да в крестах из-за их крайне полезного раии они вызвают адскую жопаболь и проще забить чем пытаться свять на 100% правильно и безопасно. Но на это можно забить - я не ассоциирую язык только с его рантаймом.

Использовать в реальности исключения не особо приятнее кодов возврата - т.к. 3-4 либы и уже тебе надо городить свои прокси, которые раскидают все внешнее исключения по нужным категориям.

Если же забить на эти два пункта, то они не такие уж и плохие - мне нравится. Всё равно лучше ничего нет.

shielcody
()
Ответ на: комментарий от RazrFalcon

А как же Option/Optional и Result/Variant.

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

Поэтому не могу сказать, что нашел много мест куда могу впихнуть Optional. Но может я особо не искал, либо у меня задачи неподходящие.

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

Ну их надо либо чекать, либо реплайсить значение

Кажется, обычно их надо мапать/флэтмапать

То, что в крестах std::optional из коробки ни того, ни другого не умеет — очередной большой косяк в дизайне, из-за которого им, вероятнее всего, пользоваться в силу неудобства будут полтора анонимуса.

С другой стороны, можно поступить по аналогии с тем, как делают скалисты: написать какой-нибудь rich_optional со всем нужным и не explicit конструктором или просто понаписать non-member функций, делающих то же самое, но у этих подходов тоже хватает недостатков.

Softwayer ★★
()
Последнее исправление: Softwayer (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.