Который посоветовал (в отличие от вас) дельную хорошую мысль
Эта мысль, если ее выслушивает адекватный, разумный человек — безусловно заслуживает одобрения.
Со скромностью и критическим взглядом на реальность у вас все в порядке, как я погляжу.
По всему остальному вам уже все сказали, как минимум несколько раз: один, два, три и четыре.
PS. Ваш страх и ужас с MALLOC_TRY и MALLOC_EXCEPT лучше никому не показывать.
PPS. По поводу архитекторов-астронавтов вам даже ссылку дали с объяснением, что это такое.
Обсуждение выше уже показало, что вы a) не способны внимательно читать то, что пишут вам и b) не в состоянии понять то, что вам говорят. Уж не знаю, что для чего является первопричиной.
Вот и сейчас вы видите противоречия, которых нет. Показываю на пальцах:
Вы высказали четыре тезиса, которые имеют к теме статьи имеют косвенное отношение. Кроме того, три из четырех явно заслуживают того, чтобы по ним оттоптались. А первый настолько тривиален и не нов, что вообще не понятно, зачем вы его привели.
Т.е. вы написали, мягко говоря, бред. Который можно было бы весело обсудить, изложи вы его подробнее в отдельной статье.
Вы же цепляетесь всего за один тезис и пытаетесь проехаться по личности комментатора. Хотя сами до этого демонстрировали ну очень тонкую душевную организацию и повышенную чувствительность к хамству.
По поводу же:
Лечитесь. Принимайте таблетки.
Вы уж определитесь, хотите вы участвовать в технической дискуссии или нет. Если хотите, то будьте готовы к тому, что ваши аргументы/убеждения/заблуждения будут подвергаться сомнению. Если не хотите, то зачем вы комментарии к техническим статьям пишете?
С чего бы? Вы тут выступаете с очень странными заявлениями, обосновать которые в предметном разговоре просто не можете. Так что оттоптаться по вашим убеждениям можно вне зависимости от того, что работать в C++ с памятью в C-шном стиле не принято уже очень и очень давно.
Однако, поскольку представления о реальности у вас какие-то очень своеобразные, имеет смысл пояснить, почему malloc все еще в ходу и почему статья про правильное использование malloc все еще актуальна.
Во-первых, код на чистом C продолжают писать. Не говоря уже про сопровождение кода на чистом C. Поэтому для C-шников malloc — это такой же привычный инструмент, как для C++ников new или std::vector.
Во-вторых, зачастую C-шный и C++ный код смешивают в одном проекте. И если в C++ной части нужно выделить память, которая уйдет затем в C-шную часть, то не через new же ее выделять. Поэтому и в C++ном коде можно встретить malloc вместо new и это будет иметь смысл.
В-третьих, C++ сложный язык. Его и раньше знали далеко не многие. А уж теперь, когда он потерял изрядную долю своей популярности, дела с изучением C++ обстоят не очень хорошо (насколько я могу об этом судить). Поэтому на C++ многие программируют вообще не следуя рекомендациям, в том числе и очень старым. Поэтому некоторые «типа C++ники» запросто используют в своем C++ном коде malloc, не очень понимая, что для этих же целей может быть использован new.
Поэтому статья господина Andrey2008 вполне себе осмыслена и актуальна. В отличии от ваших комментариев в ней. И когда вы сюда приходите с идеями полностью отказаться от malloc-а (и других *nix-овых вызовов) или отказом от парадигмы «выделил память — освободил память», то обсуждение ваших странных, мягко говоря, идей и предложений здесь оказывается злостным офтопиком. А обсудить их могло бы иметь смысл, т.к. Хабр читает молодежь и мало ли, кто-то воспримет ваши потоки создание за результат разумных размышлений.
Вы бы статью написали с развернутыми изложением этих тезисов. Чтобы люди могли вдоволь по вашим заблуждениям оттоптаться.
Написать в комментариях к чужой статье «Я вообще за то чтобы по-возможности не одобрять в pure C++ прямые выделения/деаллокации памяти в сишном стиле и работу с памятью.» Не нужно ни большого ума, ни большого труда. Тем более, что в C++ работа с памятью в С-шном стиле не одобряется уже лет тридцать как.
А вот сделать статью и затем получить сотню комментариев с оценками степени вашей оригинальности и оторванности от жизни… Вот это совсем другое. Ну не обсуждать же "Парадигма вида «попросить память» — что-то сделать — «отдать память» — древняя, архаичная как г. мамонта." в комментариях к статье, в которой говорится, как правильно работать именно в этой парадигме.
Опять графоманские потоки вместо обсуждения технических деталей. Сильно не вяжется с приснопамятным:
Я только по технической и архитектурной части.
Скорее я тут вынужден разговаривать не с архитектором-астронавтом, а с теоретиком-графоманом.
Поскольку вы ссылаетесь еще на кого-то («я и другие люди не видим что там ВООБЩЕ можно обсуждать») то придется потратить время дабы объяснить вам и мифическому еще кому-то очевидные вещи. Очевидные для тех, кто не отмахивается посредством «это уже детали», как вы.
Итак, предложенная вами идея оберток вокруг malloc-а, во-первых, работает только тогда, когда обертка имеет возможность прервать выполнение кода после возникновения ошибки тем или иным способом. Вызовом abort/exit/terminate, или выбросом исключения, или эмуляцией исключения на подручных средствах. Или даже goto error, если «предлагаемая» вами обертка реализована в виде макроса.
Проблема здесь в том, что это не всегда работает. Безусловное прерывание программы (abort/exit/terminate) может быть приемлемым для утилит типа grep, wc или xargs, но совершенно не приемлем для библиотек вроде libxml2, zlib или libcurl. Так же это не приемлемо для больного класса приложений, скажем офисных пакетов или СУБД.
Исключения могут быть недоступны в принципе. Скажем, если мы ограничены чистым C. Или же по каким-то веским причинам исключения отключены в C++. С эмуляцией исключений может быть та же самая беда — они могут быть запрещены.
Как должна вести себя обертка вокруг malloc в условиях, когда прервать исполнение кода нельзя (например, внутри libxml2 или libcurl)?
Эта обертка будет вынуждена возвращать результат операции, в том или ином виде. И не суть важно, будет ли этот результат возвращаться в виде голого указателя (что нам придется делать, если мы находимся в чистом C) или в виде какой-то обертки, вроде std::optional или folly::Expected. Все равно мы будем вынуждены этот результат проверять. А раз так, то вопрос «нужно ли проверять коды возврата malloc?» для большого количества прикладных ниш, где применяются C/C++ превратиться в «нужно ли проверять коды возврата обертки над malloc?». Получаем то же самое, вид в профиль.
Ну и, во-вторых, как уже было сказано, наличие оберток вовсе не отменяет того, что:
в каждом случае решать что делать дальше, а это означает что придется писать дополнительный код, принимать решения, которые не всегда могут оказаться удачными или безошибочными
вашими «выводами» о иллюстративном коде, набитом за пару минут.
Так как прикажете воспринимать приведенный вами здесь код?
Как демонстрацию ваших рассуждений о слоях абстракции? Или как не имеющую отношения к теме иллюстрацию, на которую не стоит обращать внимания?
Если это всего лишь иллюстрация, то когда будет хоть какая-то конкретика, которую можно обсуждать предметно? Или обсуждать останется только вашу тонкую душевную организацию?
Я вас уже который комментарий прошу: давайте ближе к теме.
Давайте я вам напомню, как развивались события. Вы написали нечто, с чем сложно согласиться. Это заставило задать вам уточняющий вопрос. Но вместо того, чтобы на него ответить, вы завели шарманку в стиле:
Вот и подумайте, что именно предлагается, если вы, конечно, разработчик.
Далее я вас попросил говорить более предметно (т.к. и в ответах другим участникам дискуссии вы не утруждали себя конкретными примерами). На что вы продолжили играть на той же шарманке:
Мне это затратно, тратить время на вас лично.
Изучайте существующие кодовые базы, а не пользуйтесь уловкой «а вот покажите мне пальцем». В простейшем случае изучите поведение/реализацию operator new в языке c++ (на предмет проверки и exeption) или что происходит в managed-языках.
И продолжали играть до тех пор, пока из вас таки не удалось выжать хоть какой-то пример кода.
И вот когда код появился, с вами и вашими «убеждениями» все стало окончательно понятно. Ваши же рекомендации не проходят простейшей критики. Ну не подходит предложенный вами вариант checked_malloc для ряда случаев. И именно чего-то подобного я и ожидал, как только вы написали вот это:
В данном же случае можно либо завершать процесс, выводить сообщение пользователю и ждать, либо предусмотреть какое-либо другое поведение, но это уже детали.
Нежелание человека разговаривать о значимых деталях наводит на подозрение о том, что человек не является действующим разработчиком (по крайней мере действующим C или C++ разработчиком), об этих-то подозрениях и приходилось вам мягко намекать.
Огромная. Когда в тему о проблемах использования malloc в C и C++ приходят теоретики, ссылающиеся на опыт управляемых языков, то разговаривать, как правило, можно только о личностях, которые до такого додумываются.
Сошлитесь на мой фрагмент текста, который для вас непонятен
Это вы троллите? Я вам уже сказал, что до сих пор вы вообще не сказали ничего конкретного, что можно было бы предметно обсуждать. Вот только сейчас вы привели пример кода. Из которого уже видна степень вашей экспертизы.
Я только по технической и архитектурной части.
Пока что это ничем не подтверждено.
— Концепция ясна?
Более чем.
Это же сверх-тривиально, как тут что-то может быть неясно, что тут требуется иллюстрировать?
Отличная иллюстрация того, что вы не понимаете сложности и широты темы, о которой идет речь. Если такой checked_malloc будет в какой-нибудь библиотеке для парсинга хитрого формата файлов, то использовать библиотеку с подобным checked_malloc будет ой как стремно, скажем, в многооконном офисном приложении.
В легко достижимом идеале пишется код реализующий только свою задачу, не отвлекаясь на посторонние детали, такие как проверки выделения памяти, реализация exception safety, мультипоточности и проч.
Простите, а вы точно к разработке на C или C++ имеете отношение?
Зачем вы хамите, переходя на личности? Если у вас отсутствуют аргументы — это не повод к Ad hominem.
А вы начните предметно разговаривать, без воспарений в высокие абстракции на счет каких-то слоев, которые волшебным образом решают проблемы неудачных операций (хоть вызовов malloc, хоть чего другого). Тогда можно будет поговорить о решениях. Пока же есть ощущение, что вы живете не в мире реального программирования, а в какой-то параллельной вселенной, в которой легко достигается абстрагирование от многопоточности, exception safety и пр.
Другими словами: покажите, что с вами есть о чем говорить. Что вы не теоретик и архитектор-астронавт.
Построить обертку и не использовать malloc() повсеместно (т.е. на application-level уровне) — это именно то, что следует сделать. В чем тут проблема и какие тут «овраги»?
Ну так покажите, какую обертку вы предлагаете делать. Тогда можно будет сказать, где эта обертка будет работать, а где нет. Но вместо этого вы говорите про какие-то system-level и application-level. А действительно важные вещи, которые влияют и на то, и на другое, это у вас: «уже детали».
эта необходимость уменьшается. раньше ему надо было думать на каждом вызове.
теперь можно весь стек вызовов охватить одним try/catch и не париться особо.
Попробуйте сделать тот же std::vector::push_back/emplace_back с обеспечением exception safety. Посмотрим, придется вам париться или нет.
Там все происходит именно так, как это вам описано — пользователь языка генерально доверяет распределению памяти, нет проверок по месту на то что аллокация произошла/не произошла.
Хочу вас разочаровать. Когда разработчик имеет дело с исключениями вместо кодов возврата, необходимость думать и принимать решение никуда не исчезает. Там есть свои проблемы, например, позаботиться об exception safety.
Предлагается выполнить эту проверку в одном месте, сразу после вызова malloc(), оформить это как функцию/класс/макро, назначив этому функционалу обязанности «системного слоя» и далее уже писать свой application код в надежде на то что в application-level уровне абстракции память валидна всегда, не может быть ситуации когда память не возвращена, и, соответственно, UB не может возникнуть в принципе.
Уж простите мне мой французский, но какая глубокая мысль. Видимо, мосье теоретик и архитектор-астронавт?
Иначе как объяснить вот эту вот «досадную мелочь»:
В данном же случае можно либо завершать процесс, выводить сообщение пользователю и ждать, либо предусмотреть какое-либо другое поведение, но это уже детали.
Получается в точности как в народной мудрости: гладко было на бумаге, но забыли про овраги. На словах все красиво про уровни абстракции, а как доходит до практики, то «это уже детали».
Я описал как эта проблема должна быть решена наиболее универсальным и наиболее разумным способом.
Могли бы ткнуть пальцем? А то кроме пространных и абстрактных рассуждений о старости системных вызовов в unix-ах вообще и *alloc-ов в частности ничего не было. Никакой конкретики. Ну или я не видел, комментариев здесь много, за всеми не уследить.
Вот и подумайте, что именно предлагается, если вы, конечно, разработчик.
Временами еще разработчик. И вот думаю-думаю, и глубину вашей мысли не постигаю. Могли бы вы объяснить ее на примерах кода, для тех, кто «от сохи» и в абстрактной архитектуре как-то не очень?
Возможно вас это удивит, но — да.
Очень сильно удивит. А вам ведь не составит труда на примерах кода показать, как это оно?
Простите мне мой резкий тон, но мне очень жаль времени, которое я на вас вынужден тратить. Есть сильное ощущение, что к программированию (особенно на C и С++) вы никаким боком не относитесь. Может быть учитесь. Посему вам кажется, что дать ссылку на описание задачи коммивояжера — это дать постановку задачи. Боюсь вас огорчить, но это вовсе не так.
А т.к. вы к программированию имеете отношение постольку-поскольку, то предметно с вами разговаривать вряд ли возможно. Т.к. вы просто не понимаете предмета разговора. Причем как на уровне собственно программирования (тупо if-ы в коде), так и на уровне того, что хочет заказчик и что его интересует.
давайте еще раз с примером задачи с градиентным спуском поразбираемся?
Задачи, как таковой, не было. Есть что-то в вашей голове, о чем я не имею ни малейшего понятия. Было бы ТЗ, можно было бы о чем-то говорить. Но даже если вы и сможете выкатить подробное ТЗ, то у меня и без этого есть чем заняться.
то вопрос: нужно ли заморачиваться неблагоприятным сценарием?
Конечно. Я вам даже больше скажу, это вопрос дисциплины. При должной дисциплине стоимость минимальной обработки неудачных результатов совершенно невысока. Особенно, если не брать C, а ограничиваться C++ с возможностью использования исключений.
я говорю: перфекционируя — надо перфекционировать до конца: начали проверять malloc, проверяем и open (я выше писал об этом несколько раз).
Вообще-то это не перфекционизм, это нормальная, обычная работа программиста: выполнил действие, которое может завершиться неудачно, проверь результат. В зависимости от этого принимай решение о дальнейших действиях.
Другой подход к делу, т.е. программирование в расчете только на благоприятный сценарий, в мире C/С++ возможен только при написании quick-and-dirty прототипов «на выброс». Может быть где-то в мире Erlang-а, Ruby или JavaScript-а по-другому, а здесь вот так.
там где это не нужно предпочитаю не проверять. и не тольк в C/C++, но и на других языках.
Очень надеюсь, что мне не придется иметь дело с написанным вами софтом.
Самое последнее в данной задаче что Вас будет волновать — это вопрос «как будет вести себя данная программа/утилита в условиях недостатка памяти?»
Было бы очень хорошо, если бы вы не апроксимировали свои заблуждения на весь остальной мир. Нехватка памяти может ничем не отличаться от других ошибок, с которыми сталкивается программа. Например, как невозможность открыть файл.
Или вы в своих C/C++ программах результаты open/read/write так же предпочитаете не проверять?
Рекомендация загромождать код проверкой воспринимается мной как анти-паттерн, вредная рекомендация.
Это мощно.
Одной только проверки недостаточно, если уж проверять, кроме проверки придется еще и в каждом случае решать что делать дальше, а это означает что придется писать дополнительный код, принимать решения, которые не всегда могут оказаться удачными или безошибочными.
Так ведь это же программирование. Тут нужно думать, решать, обрабатывать различные варианты и т.д. Работа программиста в этом и состоит.
Или сейчас уже принято писать программы на C или C++ без всей этой отвлекающей настоящего мастера рутины?
По опыту обсуждения подобной темы складывается ощущение, что в Интернетах есть две секты. Приверженцы первой свято уверены в том, что под Linux-ом malloc никогда не возвращает NULL. Приверженцы второй свято уверены в том, что если память в программе выделить не удалось, но ничего уже в принципе сделать нельзя, нужно только падать.
Переубедить их никак нельзя. Особенно когда эти две секты пересекаются. Можно только принять это как данность. Причем не суть важно, reddit это, Хабр, LOR или еще какой профильный ресурс.
Ну так я еще раз повторюсь: параллель прослеживается, когда мы оказываемся в ситуации, когда актор достаточно большой, чтобы играть роль сервиса. Но у акторов, в принципе, гранулярность может быть и меньше. Т.е. сервис может быть образован из группы акторов. Но не наоборот.
Т.о. ваша параллель работает не всегда.
Но, опять же повторюсь, на акторах строить микросервисы достаточно просто.
По всему остальному вам уже все сказали, как минимум несколько раз: один, два, три и четыре.
PS. Ваш страх и ужас с MALLOC_TRY и MALLOC_EXCEPT лучше никому не показывать.
PPS. По поводу архитекторов-астронавтов вам даже ссылку дали с объяснением, что это такое.
Вот и сейчас вы видите противоречия, которых нет. Показываю на пальцах:
Вы высказали четыре тезиса, которые имеют к теме статьи имеют косвенное отношение. Кроме того, три из четырех явно заслуживают того, чтобы по ним оттоптались. А первый настолько тривиален и не нов, что вообще не понятно, зачем вы его привели.
Т.е. вы написали, мягко говоря, бред. Который можно было бы весело обсудить, изложи вы его подробнее в отдельной статье.
Вы же цепляетесь всего за один тезис и пытаетесь проехаться по личности комментатора. Хотя сами до этого демонстрировали ну очень тонкую душевную организацию и повышенную чувствительность к хамству.
По поводу же: Вы уж определитесь, хотите вы участвовать в технической дискуссии или нет. Если хотите, то будьте готовы к тому, что ваши аргументы/убеждения/заблуждения будут подвергаться сомнению. Если не хотите, то зачем вы комментарии к техническим статьям пишете?
Однако, поскольку представления о реальности у вас какие-то очень своеобразные, имеет смысл пояснить, почему malloc все еще в ходу и почему статья про правильное использование malloc все еще актуальна.
Во-первых, код на чистом C продолжают писать. Не говоря уже про сопровождение кода на чистом C. Поэтому для C-шников malloc — это такой же привычный инструмент, как для C++ников new или std::vector.
Во-вторых, зачастую C-шный и C++ный код смешивают в одном проекте. И если в C++ной части нужно выделить память, которая уйдет затем в C-шную часть, то не через new же ее выделять. Поэтому и в C++ном коде можно встретить malloc вместо new и это будет иметь смысл.
В-третьих, C++ сложный язык. Его и раньше знали далеко не многие. А уж теперь, когда он потерял изрядную долю своей популярности, дела с изучением C++ обстоят не очень хорошо (насколько я могу об этом судить). Поэтому на C++ многие программируют вообще не следуя рекомендациям, в том числе и очень старым. Поэтому некоторые «типа C++ники» запросто используют в своем C++ном коде malloc, не очень понимая, что для этих же целей может быть использован new.
Поэтому статья господина Andrey2008 вполне себе осмыслена и актуальна. В отличии от ваших комментариев в ней. И когда вы сюда приходите с идеями полностью отказаться от malloc-а (и других *nix-овых вызовов) или отказом от парадигмы «выделил память — освободил память», то обсуждение ваших странных, мягко говоря, идей и предложений здесь оказывается злостным офтопиком. А обсудить их могло бы иметь смысл, т.к. Хабр читает молодежь и мало ли, кто-то воспримет ваши потоки создание за результат разумных размышлений.
Написать в комментариях к чужой статье «Я вообще за то чтобы по-возможности не одобрять в pure C++ прямые выделения/деаллокации памяти в сишном стиле и работу с памятью.» Не нужно ни большого ума, ни большого труда. Тем более, что в C++ работа с памятью в С-шном стиле не одобряется уже лет тридцать как.
А вот сделать статью и затем получить сотню комментариев с оценками степени вашей оригинальности и оторванности от жизни… Вот это совсем другое. Ну не обсуждать же "Парадигма вида «попросить память» — что-то сделать — «отдать память» — древняя, архаичная как г. мамонта." в комментариях к статье, в которой говорится, как правильно работать именно в этой парадигме.
2. Вы настолько тупы, что не можете скопипастить мое имя и фамилию правильно из профиля. Это полностью объясняет проблемы с п.1.
На якобы хамство с мой стороны лучше пожаловаться сразу в ООН и Спортлотто.
Поскольку вы ссылаетесь еще на кого-то («я и другие люди не видим что там ВООБЩЕ можно обсуждать») то придется потратить время дабы объяснить вам и мифическому еще кому-то очевидные вещи. Очевидные для тех, кто не отмахивается посредством «это уже детали», как вы.
Итак, предложенная вами идея оберток вокруг malloc-а, во-первых, работает только тогда, когда обертка имеет возможность прервать выполнение кода после возникновения ошибки тем или иным способом. Вызовом abort/exit/terminate, или выбросом исключения, или эмуляцией исключения на подручных средствах. Или даже goto error, если «предлагаемая» вами обертка реализована в виде макроса.
Проблема здесь в том, что это не всегда работает. Безусловное прерывание программы (abort/exit/terminate) может быть приемлемым для утилит типа grep, wc или xargs, но совершенно не приемлем для библиотек вроде libxml2, zlib или libcurl. Так же это не приемлемо для больного класса приложений, скажем офисных пакетов или СУБД.
Исключения могут быть недоступны в принципе. Скажем, если мы ограничены чистым C. Или же по каким-то веским причинам исключения отключены в C++. С эмуляцией исключений может быть та же самая беда — они могут быть запрещены.
Как должна вести себя обертка вокруг malloc в условиях, когда прервать исполнение кода нельзя (например, внутри libxml2 или libcurl)?
Эта обертка будет вынуждена возвращать результат операции, в том или ином виде. И не суть важно, будет ли этот результат возвращаться в виде голого указателя (что нам придется делать, если мы находимся в чистом C) или в виде какой-то обертки, вроде std::optional или folly::Expected. Все равно мы будем вынуждены этот результат проверять. А раз так, то вопрос «нужно ли проверять коды возврата malloc?» для большого количества прикладных ниш, где применяются C/C++ превратиться в «нужно ли проверять коды возврата обертки над malloc?». Получаем то же самое, вид в профиль.
Ну и, во-вторых, как уже было сказано, наличие оберток вовсе не отменяет того, что:
Как демонстрацию ваших рассуждений о слоях абстракции? Или как не имеющую отношения к теме иллюстрацию, на которую не стоит обращать внимания?
Если это всего лишь иллюстрация, то когда будет хоть какая-то конкретика, которую можно обсуждать предметно? Или обсуждать останется только вашу тонкую душевную организацию?
Я вас уже который комментарий прошу: давайте ближе к теме.
Далее я вас попросил говорить более предметно (т.к. и в ответах другим участникам дискуссии вы не утруждали себя конкретными примерами). На что вы продолжили играть на той же шарманке:
И продолжали играть до тех пор, пока из вас таки не удалось выжать хоть какой-то пример кода.
И вот когда код появился, с вами и вашими «убеждениями» все стало окончательно понятно. Ваши же рекомендации не проходят простейшей критики. Ну не подходит предложенный вами вариант checked_malloc для ряда случаев. И именно чего-то подобного я и ожидал, как только вы написали вот это:
Нежелание человека разговаривать о значимых деталях наводит на подозрение о том, что человек не является действующим разработчиком (по крайней мере действующим C или C++ разработчиком), об этих-то подозрениях и приходилось вам мягко намекать.
Это вы троллите? Я вам уже сказал, что до сих пор вы вообще не сказали ничего конкретного, что можно было бы предметно обсуждать. Вот только сейчас вы привели пример кода. Из которого уже видна степень вашей экспертизы.
Пока что это ничем не подтверждено.
Более чем.
Отличная иллюстрация того, что вы не понимаете сложности и широты темы, о которой идет речь. Если такой checked_malloc будет в какой-нибудь библиотеке для парсинга хитрого формата файлов, то использовать библиотеку с подобным checked_malloc будет ой как стремно, скажем, в многооконном офисном приложении.
А вы начните предметно разговаривать, без воспарений в высокие абстракции на счет каких-то слоев, которые волшебным образом решают проблемы неудачных операций (хоть вызовов malloc, хоть чего другого). Тогда можно будет поговорить о решениях. Пока же есть ощущение, что вы живете не в мире реального программирования, а в какой-то параллельной вселенной, в которой легко достигается абстрагирование от многопоточности, exception safety и пр.
Другими словами: покажите, что с вами есть о чем говорить. Что вы не теоретик и архитектор-астронавт.
Ну так покажите, какую обертку вы предлагаете делать. Тогда можно будет сказать, где эта обертка будет работать, а где нет. Но вместо этого вы говорите про какие-то system-level и application-level. А действительно важные вещи, которые влияют и на то, и на другое, это у вас: «уже детали».
Уж простите мне мой французский, но какая глубокая мысль. Видимо, мосье теоретик и архитектор-астронавт?
Иначе как объяснить вот эту вот «досадную мелочь»:
Получается в точности как в народной мудрости: гладко было на бумаге, но забыли про овраги. На словах все красиво про уровни абстракции, а как доходит до практики, то «это уже детали».
Временами еще разработчик. И вот думаю-думаю, и глубину вашей мысли не постигаю. Могли бы вы объяснить ее на примерах кода, для тех, кто «от сохи» и в абстрактной архитектуре как-то не очень?
Очень сильно удивит. А вам ведь не составит труда на примерах кода показать, как это оно?
А т.к. вы к программированию имеете отношение постольку-поскольку, то предметно с вами разговаривать вряд ли возможно. Т.к. вы просто не понимаете предмета разговора. Причем как на уровне собственно программирования (тупо if-ы в коде), так и на уровне того, что хочет заказчик и что его интересует.
Конечно. Я вам даже больше скажу, это вопрос дисциплины. При должной дисциплине стоимость минимальной обработки неудачных результатов совершенно невысока. Особенно, если не брать C, а ограничиваться C++ с возможностью использования исключений.
Другой подход к делу, т.е. программирование в расчете только на благоприятный сценарий, в мире C/С++ возможен только при написании quick-and-dirty прототипов «на выброс». Может быть где-то в мире Erlang-а, Ruby или JavaScript-а по-другому, а здесь вот так.
Очень надеюсь, что мне не придется иметь дело с написанным вами софтом.
Или вы в своих C/C++ программах результаты open/read/write так же предпочитаете не проверять?
Так ведь это же программирование. Тут нужно думать, решать, обрабатывать различные варианты и т.д. Работа программиста в этом и состоит.
Или сейчас уже принято писать программы на C или C++ без всей этой отвлекающей настоящего мастера рутины?
Переубедить их никак нельзя. Особенно когда эти две секты пересекаются. Можно только принять это как данность. Причем не суть важно, reddit это, Хабр, LOR или еще какой профильный ресурс.
Т.о. ваша параллель работает не всегда.
Но, опять же повторюсь, на акторах строить микросервисы достаточно просто.