Ну вот как же задалбывают горе-программисты, которые проповедуют вот такие взгляды:
Ошибки аллокации достаточно бесполезно ловить в пользовательской программе.
Во-первых, почти вся стандартная библиотека опирается на аллокатор, но если добавить тип ошибки в возвращаемые значения всех функций, которые выделяют память, пользоваться этим будет совершенно невозможно.
Во-вторых, как минимум на десктопных Linux по умолчанию включён overcommit, который делает невозможной локальную обработку ошибки выделения памяти.
В-третьих, если вы пишете прикладную программу, близкую к системной в плане управления ресурсами (веб-сервер, сервер БД), то у вас и так весьма особенные нужды в выделении памяти. Часто используются пулы, маппинг файлов/анонимной памяти прямо от системы. Куча в первую очередь интересна "совсем прикладным" программам, которым нехватка ресурсов неинтересна.
Уже столько раз эта тема поднималась, в том числе и мной в этом блоге (пример), что уже нет сил расписывать контраргументы в очередной раз.
Хотелось бы надеяться, что чем больше будет таких криворуких говнокодеров, тем больше будет спрос затем на услуги тех, кто более ответственно подходит к написанию кода. Но, что-то практика показывает, что слова про качество -- это одно, а как дело доходит до обсуждения конкретных работ, так начинается "а что так долго, а что так дорого"...
Так что особого энтузиазма по поводу светлого будущего софтостроения я не питаю :(
1 комментарий:
> Так что особого энтузиазма по поводу светлого будущего софтостроения я не питаю :(
Отсюда: https://herbsutter.com/2018/07/02/trip-report-summer-iso-c-standards-meeting-rapperswil/
> Step 3 is to consider handling heap exhaustion (out-of-memory, OOM)
> differently from other errors ... bla-bla-bla ... it’s already fully
> supported in C++ today because you can already change the new_handler to
> terminate today with a single line of code (std::set_new_handler([]{terminate();});)
Ґґґґ
Отправить комментарий