Какой должен быть тест на базовые знания C++?

Тот факт, что вы проигнорировали приведенный мной довод

какое еще довод? единственно, что похоже на «довод» -

Во-вторых, да, в пользу исключений есть очень веский довод: их нельзя просто так проигнорировать, при этом happy path не замусоривается лишними проверками.

то есть классика пурги на исключениях вида - это не замусоривание лишними проверками??? некий пседокод

try {
  auto lfile0 = open_file("abc.txt")
}
catch (file_exception fe) {

}

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

опять псевдокод

auto lfile = open_file(...)
if (not lfile.is_valid()) {...}

какое еще довод?

Вот этот: «их нельзя просто так проигнорировать, при этом happy path не замусоривается лишними проверками.»

Вы его явно видели, но явно не поняли.

то есть классика пурги на исключениях вида - это не замусоривание лишними проверками???

Простите, а вы что хотите обсудить: говнокод или нормальное использование исключений?

Так же я жду определения для «вернуть код ошибки регулярным образом». Без него, к сожалению, продолжить невозможно.

А ваша неспособность его дать лишь кладет дополнительный груз на чашу весов с надписью «малолетний дебил» (с)

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

любой на ваш вкус. варианты:

• ошибка ассоциирована с самим обьектом и имеет семантику - «обьект находится в невалидном состоянии».

• ошибка есть результат операции, которая(операция) тем или иным способ возвращает обьект некой вашей стандартной ошибки, например вида

struct ErrorBase {
  int _code; ///internal error code
  std::string _info; ///some readible text representation
}

надеюсь, как вернуть ошибку из функции - вам фантазии хватит.

• ну и совсем гибко:

«стек ошибок» - есть стек ошибок модуля или приложения. куда толкаются ошибки и вы можете проверить этот стек на непустоту, и обработать все ошибки оттуда.

Можеть быть пример кода, где с исключениями получится короче:

// Проверка возвращаемого значения
if (!f0()) {
    // ...
    return 1;
}

if (!f1()) {
    // ...
    return 1;
}

if (!f2()) {
    // ...
    return 1;
}

if (!f3()) {
    // ...
    return 1;
}

// исключения
try {
    f0();
    f1();
    f2();
    f3();
} catch (Exception& e) {
    // ...
}

Простите, а вы что хотите обсудить: говнокод или нормальное использование исключений?

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

тока думать о том кто там столбец а кто строка и кого надо транспонировать.

Не могу поверить, что в физике никогда не бывает <вектор столбец>*<вектор строка> = <матрица>

А для скалярного произведения есть a.dot(b) и тут уже всё равно, что там вектор строка, а что столбик.

Можеть быть пример кода, где с исключениями получится короче:

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

любой на ваш вкус

На мой вкус – это std::expected и поддержка паттерн-матчинга в языке, но ПМ пока в C++ не завезли :(

Но список так себе, очень сильно попахивает известной субстанцией.

Однако, уже понятно, что у вас каша в голове.

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

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

Теперь к примерам.

Случай первый. Перегруженные операторы. Допустим, у нас есть класс safe_signed_int32, который позволяет делать операции над int32 с проверкой на переполнение. И для него будет определен operator+, который принимает два safe_signed_int32, возвращает новый safe_signed_int32 или порождает исключение в случае переполнения.

Случай второй. Есть класс с несколькими вложенными объектами:

class demo {
  first_complex_type first_;
  second_complex_type second_;
  third_complex_type third_;
  ...
};

В конструктор demo передаются параметры для инициализации first_, second_ и third_. Если в этих параметрах что-то не то, что инициализация должна прерваться. А если что-то уже было инициализировано (например, first_ и second_), то это нужно откатить. Грубо говоря, есть списки инициализаций:

demo::demo(
  first_initialization_params first_params,
  second_initialization_params second_params,
  third_initialization_params third_params)
  : first_(first_params)
  , second_(second_params)
  , third_params(third_params)
{}

это оптический обман зрения. случаи неэквивалентны. представьте что возвращать вы будете не 1 везде

А вот не фига. Родительский тип исключений может быть и общий или даже сам тип исключений может быть общий. Так что вполне эквивалентны. И случай, когда нужно последовательно вызывать несколько функций с условием успешного вызова предыдущей - как раз будет короче с исключениями.

когда без исключений задача нерешаема

Это манипуляция. Разумеется нет такого. Исключения - не для решения нерешаемых случаев, а для удобства.

Не могу поверить, что в физике никогда не бывает <вектор столбец>*<вектор строка> = <матрица>

Разумеется бывает, но очень редко - а вот скалярное произведение на каждом шаге. И когда численная схема занимает несколько листов А4 арабской вязи, то очень важно что бы в коде обозначения совпадали с обозначениями на бумаге, иначе фиг потом ошибку найдешь. В этом смысле a.dot(b) смотрится куда хуже чем a*b.

Операций в плюсах мало, перегружать их для таких вещей надо хорошо подумав, иначе потом работать неудобно будет. В эйгене вот неудобно сделали (ну мне). Скажем % часто перегружают как векторное произведение, это удобно.

И для него будет определен operator+, который принимает два safe_signed_int32, возвращает новый safe_signed_int32 или порождает исключение в случае переполнения.

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

В конструктор demo передаются параметры для инициализации first_, second_ и third_. Если в этих параметрах что-то не то, что инициализация должна прерваться. А если что-то уже было инициализировано (например, first_ и second_), то это нужно откатить.

опять вопрос - вы не можете сконструировать нужный вам обьект, тогда вы решаете откатить и что? опять его конструировать?

я вам уже приводил формулировку Хоара по исключениям - «исключение это ситуация когда предусловия выполнены, а постусловия выполнены быть не могут». это СТРОГО говорит о коде, который невалиден и должен быть или исправлен руками, или вы попали(типа я писал на диск критические данные, а он взорвался).

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

Например, ввести с клавиатуры пару строка-число и отсортировать сначала по строке, а потом по числу. Если человек использует scanf(), printf(), char *, массивы/веторы не из STL, и вручную пишет сортировку - сразу указывать на дверь. Потому что такие потом наплодят memory leak’ов и будут говорить что С++ виноват.

А если scanf с printf оставить, а во всем остальном STL, RAII и далее по списку, то тоже на дверь укажете?

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

Да просто за

#include <math.h>

увольнять одним днем без выходного пособия с публичным спусканием с лестницы! Только

#include <cmath>

и никаких там .h;-)

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

Могу ничего не делать. Можно просто в main сделать catch(const std::exception &) и в нем напечатать только «ну не шмогла». И для целой кучи контекстов (предметных областей) это будет именно то, что нужно.

любое решение должно иметь свой практический смысл.

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

Это такой практический смысл, который всем смыслам смысл.

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

опять вопрос - вы не можете сконструировать нужный вам обьект, тогда вы решаете откатить и что?

Все, что угодно.

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

«исключение это ситуация когда предусловия выполнены, а постусловия выполнены быть не могут»

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

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

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

И тут я в очередной раз задаюсь вопросом: а у вас опыт разработки программ есть вообще?

Мне правда стало интересно, может быть, была какая-то реальная проблема из-за printf/scanf, которую пропустил компилятор, ведь современные gcc и clang даже лезут в эту форматную строку и проверяют соответствие типов данных. А что до STL, ну вот возьмем, например, std::string. Получаем тот же сишный небезопасный указатель (a в С других не бывает) через std::string::data и вперед, разыменовывать астральные дали.

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

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

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

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

Получаем тот же сишный небезопасный указатель (a в С других не бывает) через std::string::data и вперед

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

Безопасность должна быть безопасной!

Если серьезно, то мы как раз и любим С++ за то что в нем можно делать адищенскую смесь из низкоуровневой фигни вроде обычных пойнтеров с какими то высокоуровневыми извращениями. Если низкоуровневая фигня запрещена, то наверно надо взять какой то другой ЯП где ее от рождения нет?

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

и почему это так «дорого и непредсказуемо» вам неинтересно. спросите у разрабов с++ умеют ли они програмировать вообще, ибо должно быть дешево и предсказуемо, а у них - дорого и непредсказуемо.

Там только одну часть из условных трех я бы отнес к условной наркоманской. Первая часть - нормальные вопросы на базовое понимание (то, что понятно после «c++ за 21 день», ну или слегонца свыше того). Вторая часть - это такой микс из условных наркоманских текстов (смесь некорректно составленных заданий, а ля забыли синтаксис чекером свой код проверить) и того, что можно быстренько проверить на компе и дать верный ответ. Третья часть ближе к «вот вам постановка задачи, вот вам код, а теперь исправьте его», т.е. то, что требует более 5 минут. И я сомневаюсь, что результаты где-то хранятся, чтобы какие-то выводы можно было сделать. Это во-первых. А во-вторых, вот это " есть шанс, что средний уровень со временем дотянется до уровня тестируемого" совершенно не факт. Наоборот, рынок для такого человека найдет соответствующее место, где его уровень никогда не достигнет высот. Т.е. все зависит только от самого тестируемого. А он получает, например, ответ «прошел», и это ему ни о чем не говорит. А сдругой стороны, свои слабые стороны он и сам после прохождения теста знает, как впрочем и без всякого теста.

это даже близко не исключение.

Это сильно зависит от задачи и ее условий, ваш К.О.

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

Welcome to the real World! В программах случаются ошибки, эти ошибки нужно диагностировать так, чтобы диагностику нельзя было проигнорировать. Пока что лучше исключений для этих целей в C++ ничего не завезли.

и почему это так «дорого и непредсказуемо» вам неинтересно.

Распарсил все слова смысл предложения не понял.

спросите у разрабов с++ умеют ли они програмировать вообще

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

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

Не ошибается только тот, кто ничего не делает. Когда исключения в C++ завозили года эдак 33 назад предложений от Саттера по zero cost exceptions не было. А чтобы появилось, нужно было накопить опыт. В первую очередь в C++, но и не только в C++.

ибо должно быть дешево и предсказуемо

нет, это не про ПО, а м.б. про железо. Да и то, надо все посчитать, сколько было потрачено в сумме на индустрию. ПО - это про «ошибся быстрее, исправил быстрее», предсказуемость тут ортогональна, или вообще обратно-пропорциональна быстроте. Если только не понимать под «предсказуемостью» предсказуемость наличия ошибок в продукте.

Welcome to the real World! В программах случаются ошибки, эти ошибки нужно диагностировать так, чтобы диагностику нельзя было проигнорировать. Пока что лучше исключений для этих целей в C++ ничего не завезли.

в программах, которые я писать не умею, операции имеют таймаут(если возмиожен выход по таймауту) и такой выход легален (то есть выполняет постусловия). такой вариант выхода естессно проверяется, и по нему предпринимаются некие действия. и никаких исключений тут не происходит.и все проиходит «недорого и предсказуемо».

вот пример как работать с таймаутами, а не исключения кидать https://en.cppreference.com/w/cpp/thread/timed_mutex/try_lock_for

вот вам и добро пожаловать.

операции имеют таймаут(если возмиожен выход по таймауту) и такой выход легален (то есть выполняет постусловия)

Мне вот интересно, как это у вас получается. Я пишу «Это сильно зависит от задачи и ее условий», вы мне в ответ типа возражаете с оговорками (если возможен, если выполняет). Суть ваших возражений в чем?

вот пример как работать с таймаутами, а не исключения кидать https://en.cppreference.com/w/cpp/thread/timed_mutex/try_lock_for

А я где-то говорил, что исключения должны использоваться всегда и везде?

Покажите, плиз.

Да и еще: примеры приведенных мной случаев, но написанных без исключений, будут?

Распарсил все слова смысл предложения не понял.

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

в состоянии когда все инварианты сохранены и предусловия выполняются - невозможно

Это вы мощно задвинули, внушаить (c)

Осталось бы понять откуда в вас столько категоричности. В одиночку софт разрабатываете (если вообще разрабатываете)?

Да и еще: примеры приведенных мной случаев, но написанных без исключений, будут?

Я бы немножко «приправил» пример с интами: INT_MIN отводится под эквивалент nan, любое переполнение приводит к nan, любая операция над nan приводит к взрыву :)

Вот только не дождётесь Вы ответов на свои прямо заданные вопросы (особенно про опыт): господин отвечает только на то что ему удобно, и больше специалист по «языком почесать».

Да и еще: примеры приведенных мной случаев, но написанных без исключений, будут?

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

«облом в конструкторе» - типичная ошибка «толстых конструкторов», конструктор обламываться не должен, иначе как системным исключением типа - нехватка памяти. не надо в конструкторах открывать файлы, которых нет на диске или пытаться соединяться с сервером.

то есть оба случая - неверная реализация.

случай с таймаутом - вопиюще недекватное представление о роли таймаутов в асинхроне.

пришел черед уже спросить - чем вы вообще там занимаетесь-то?

легко.

Ануткать. Пока что усиленное газифицирование луж.

случай с таймаутом - вопиюще недекватное представление о роли таймаутов в асинхроне.

Более вероятно то, что вы не поняли о чем вам говорят.

пришел черед уже спросить - чем вы вообще там занимаетесь-то?

Чтобы черед пришел надо бы вам ответить на мои вопросы.

Но мне не жалко. Часть времени пишу либы, которые используются другими людьми. Часть времени пишу софт (иногда даже с использованием собственных же либ). В последние несколько лет, в основном, либо в одиночку, либо в составе совсем маленьких распределенных команд (2-3 человека).

Более вероятно то, что вы не поняли о чем вам говорят.

ну так обьясните почему истечение таймаута это исключение.

весь из себя асинхронный и распределенный голанг на исключения вообще забил, а гугл в отсуствии опыта асинхронности не упрекнешь, так ведь?

гугл так и сказал - идите вы в ж. со своми исключениями, это и нельзя реализовать корректно и куча накладных расходов, потому мы будем строго возвращать ошибку как результат функции и проигнорировать ее можно только явно. обрабатывайте ошибку как можно ближе к точке возникновения (что есть принцип нераспространения ошибки) и живите долго.

ну так обьясните почему истечение таймаута это исключение.

Не раньше, чем вы соизволите ответить хотя бы на часть заданных вам вопросов.

весь из себя асинхронный и распределенный голанг на исключения вообще забил

И сделал паники.

гугл так и сказал - идите вы в ж. со своми исключениями

Пилять, да когда те, кто ссылаются на Google C++ Coding Styleguide хотя бы краем глаза на этот самый Coding Styleguide посмотрят:

On their face, the benefits of using exceptions outweigh the costs, especially in new projects.

тыц

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

Не потому, что исключения – это ай-ай-ай-плохо. А потому, что в конце 1990-х в Гугле писали без исключений.

Пилять, да когда те, кто ссылаются на Google C++ Coding Styleguide хотя бы краем глаза на этот самый Coding Styleguide посмотрят:

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

если сопоставить их списки за и против эксепшенов - вообще непонятно, как они сделали такой вывод.

я про голанг говорил

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

я это делаю в твердой убежденности ненужности лишних сущностей

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

И сделал паники.

так паника и есть наиболее правильный способ трактовки исключений. как раз то что я и говорю.

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

и гугл со мной согласен. гы

так паника и есть наиболее правильный способ трактовки исключений.

Отличий го-шной паники от C++ных исключений не так уж и много. Кроме того, тема про C++, в C++ исключения пока что только вот такие.

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

как раз то что я и говорю.

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

b) в голову вам взбредает какая-то муть.

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

Можно их и не использовать. И даже призывать ломать руки за применение

это не я. это гугл. тыц.

We do not use C++ exceptions.

Вы настолько плохи, что за разговором не следите?

Здесь, в самом конце, с цитатами и ссылками:

Какой должен быть тест на базовые знания C++? (комментарий)

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

это бизнес, дорогуша, и большой бизнес. Больше чем у вас. и потому, не смотрите что они говорят, смотрите что они делают.

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

вы ставите слова выше фактов. вы схоласт.

Ну вот вы опять утратили канву разговора. Зарабатывание денег – это вообще отдельная тема, которая к языкам программирования (и правилам их использования) имеет далеко не прямое отношение.

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

вы ставите слова выше фактов

А вы факты очень странно трактуете.

вы схоласт

Зато вы, исходя из того, что успели наговорить, «малолетний дебил» (с) И мне пофиг что мне за такие высказывания будет.

Большой бизнес - так себе аргумент. Ты слишком идеализируешь его. Ты работал в крупных международных компаниях? Тут правят балом менеджеры. Часто решения принимаются весьма сомнительные с точки зрения разработчика и инженерии вообще. Распил бабла между высшими руководителями - думаешь это только в Рф? Ха-ха. Кроме того, вот гугл и что? Да у них фигова гора проектов - это те, что они когда-то купили.

Зато вы, исходя из того, что успели наговорить, «малолетний дебил» (с)

надо же, я думал это сугубо наше с bugfixer восприятие данного индивида, а оно вона как… у меня вот такая пометка стоит

alysnix ★★ (30.03.23 16:15:44 MSK) упорот вхлам. Клиника. Не трогать из соображений гуманности.

Но иногда очень сложно удержаться;-(

Часто решения принимаются весьма сомнительные с точки зрения разработчика и инженерии вообще.

Да не в этом дело даже. Сколько у них там - сотни (если не тысячи) MLOC на плюсах, часть из которого - legacy. И всё это худо-бедно но работает. Никто в здравом уме не возьмёт на себя ответственность за риски это поломать. Всё правильно делают, и к самодурству / распилам менеджмента это очень мало имеет отношения.

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

можно сказать про легаси код с исключениями

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

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

std:: filesystem так и делает. там два варианта функций - без эксепшена и с эксепшеном. и понятно, что тот, что с эксепшеном, просто обертка над первым.

типа вот https://en.cppreference.com/w/cpp/filesystem/create_directory

ps.

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

STL неплох для «набросать рабочий прототип за день». Для остального обычно его не хватает или не оптимален. В итоге часто финальному оптимизированному коду хватает фич на уровне C.

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

В итоге лапша вроде std::vector<std::vector<u32>> adj; превращается в 2 вектора с объединёнными списками и оффсетами к ним. И всё, конец безопасности. А иначе жрёт память и страдает кеш промахами. Далее нужно было пометить 2 ребра для каждой вершины после обхода дерева. И тут оказалось, что дешевле swap-ать элементы в начало списка, а не хранить отдельно дополнительные индексы – полетел const метода. И тд, включая написание рекурсии руками, чтобы не зависеть от размера стека, не тратить место на frame pointers и иметь возможность заглянуть «на n уровней выше по стеку».

Короче, синтаксический сахар часто мешает писать хороший код, а не помогает.

И мне пофиг что мне за такие высказывания будет.

https://en.cppreference.com/w/cpp/filesystem/create_directory

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

и волки сыты и овцы целы. понятно, что в 90 процентов случаев будут брать обычный вариант функций и проверять ошибку. но особо упертые могут и развертывать конфетку блоком try сatch, и тащиться от «лучших кодовых практик».

Вопросы всегда должны быть немного выше уровня ЦА.

Принцессы ждущие принца на белом коне всегда оказываются с сантехником у разбитого корыта. Палехчи там на собеседованиях с вопросиками ;-)

И часто ты олимпиадные задачи в продакшене делаешь? Что именно ты этим доказал? Что при реализации чего то из спортивного интереса пишешь низкоуровнево?