Жаль не могу поставить вам +1, у меня нет такой возможности.
Я libunwind вчера мельком смотрел, когда пытался родить кодец менее убогий чем я запостил.
Но безусловно, вы правы, unwinding фреймов тут необходим.
Понятно.
Приятно с вами поговорить. Ну мы просто выше не поняли друг друга. Универсальное решение я не предлагал. Наоборот, вбросил простые две копейки.
Мне вот что интересно. Вы не могли бы припомнить ситуацию с GetMem в паскале, подробнее расписать что там было.
Кажется бредом — мы просто исчерпаем и резервный буфер тоже… но на самом деле — это способ делать простые и надёжные приложения. Ибо переключение на резервный буффер просто заметить, а значит — заставить работать программу по другому.
Недостатки: резервный буфер занимает место в памяти, которое почти никогда не используется, ошибка в оценке его размера приведёт к тому, что программа может упасть.
Обсуждать несколько строк рожденных на коленке за 30 минут глупо, они того не стоят. Но я понимаю что для вас как C++ кодера это желаемо. Вы можете факультативом, разве я могу вам запретить.
Но вы, Евгений Охотников eao197, лично тоже вызвали во мне огромный интерес!
Если вы такой крутой кодер (а это представляется мне несомненным),
нельзя ли глянуть на ваш код?
Хочется глянуть на ваши труды и может быть чему-то поучиться.
Не могли бы вы отправить меня по «ссылкам гордости» на практические фреймворки вашей разработки, на ваши архитектуры, системы, в крайнем случае ваши кодовые библиотеки? Я понимаю что можно «гугл в зубы», но вы сами выделите мне свою гордость?
Ну теперь, наконец, стало понятно — почему вы ведёте так, как себя ведёте.
Наверное да.
Но и мне понятно происходящее — кто же еще может крутиться под статьями о инструменте проверяющим C++ код?
Кодеры конечно же! А им это всё… У них другие сферы понимания. И профессиональная деформация.
Умение расписывать элементарные вещи в 100500 страницах — да, очень важно. Умение замаскировать то, чего вы не знаете — тоже ценно.
А вот умение писать грамотный, надёжный, поддерживаемый код — не ценится абсолютно.
Насчет науки. У меня несколько своеобразное отношение к современному положению дел, когда гонится индекс цитирования, индекс Хирша. На мой взгляд многое сейчас пустая макулатура.
Вы немного не так восприняли мою роль в науке. Моя деятельность это параллельная «вилка» в жизни — из прикладной науки и ПО, если вам интересно. Наука отдельно. ПО отдельно, как это часто и бывает.
По поводу кода… Вы знаете, я ни в коем случае не возьму на себя роль вот так вслепую сказать что я лучше вас. Во-первых, я вас не знаю и с вашим положением дел не знаком, мне и в голову не придет заявить нечто подобное! Это будет какой-то фантазией…
Во-вторых, я давно конечно же не кодер, и ну в общем я не могу этим похвалиться.
Но я понимаю вашу похвальбу как мастерового резчика по дереву коду. Это профессиональное. Хорошо если так. Древесина, остро отточенный инструмент, хороший верстак, клей (знание языка, библиотек, особенностей компиляторов и сборки) — действительно, у мастеровых свой предмет для гордости. И нельзя отнимать у маленького человека его профессионализма, вот что важно.
Но мне показалось вы упомянули Borland Pascal 6.0 — а это же довольно старый инструмент. Так что по подсчетам лет вам должно быть немало, не менее 50-55, а то и бери больше. Можно спросить, сколько вам? Вы до сих пор, в свои годы работаете программистом?
Давайте уж разойдёмся — я не буду делать вид, что умею писать научные статьи, вы — не будете делать вид, что умеете писать грамотный код. Ничего страшного ни в первом, ни во втором нет — но вот ситуация, когда человек, не умеющий писать код пытается учить тех, кто код писать таки умеет — она смешна и глупа.
Да ну что вы, я не отнимаю этого у вас. Повторяю, я не мастер и не пытаюсь как-то претендовать на вашу мастеровую деятельность и отнять вашу прерогативу. Так сказать, охотно признаю в этом ваше преимущество. Заранее. Априори.
Вы родили во мне интерес.
Теперь мне стало очень интересно и хочется глянуть на ваши труды. Можно получить «ссылки гордости» на разработанные вами архитектуры, системы, фреймворки?
Просто захотелось прикоснуться к прекрасному.
Нет, крестами я занимался с прошлого века. Электроника, машкод, ассемблер, RTOS, микроконтроллеры — это всё моё. Как и CAD-like приложения. Но давно вырос, занимаюсь другим и сейчас просто испытываю интерес. Сейчас уже только хобби.
Профессионально я стою на несколько ступенек выше C++ кодеров.
По всему остальному вам уже все сказали, как минимум несколько раз: один, два, три и четыре.
Сказать-то сказали, да вот никакого опровержения нет.
Вы логикой-то владеете? Соображаете что такое доказательство или опровержение?
Вы считаете что побредив про библиотеки, промычав отвлеченное что вот там-то при таких условиях это нельзя, это как-то опровергает или делает невозможным указанный прием?
Я вас спрашиваю да, или нет? Вот только не надо ожидать что это должно работать всегда и везде и являться универсальной паацеей. Человек сам предположивший такое (я этого не предполагал) и кинувшийся опровергать — реальный шизик.
c xmalloc давайте спорьте, со мной не надо.
PS. Ваш страх и ужас с MALLOC_TRY и MALLOC_EXCEPT лучше никому не показывать.
Ага, не смог удержаться, поднагадил.
Как бы то ни было — для комментариев это пойдет. И это пруф. А вот вы пока что никому ничего еще не показали. Так что умойтесь.
По поводу архитекторов-астронавтов вам даже ссылку дали с объяснением, что это такое.
Я прочел. Человек серьезно воспринимающий это поток сознания — вероятно полный дурак. Просто недоразвитый. Быдлокодер с манией величия, считающий этот бред откровением. Такое бывает у дураков. И в этом, видимо вся причина происходящего, я внезапно всё понял о вс.
Вы еще дом2 почитайте, там полно таких же потоков сознания.
Есть один очень важный нюанс.
Я занимаюсь наукой и участвую в научных дискуссиях. Там — за малейшей уход в сторону от вопроса сразу же бьется по рукам, потому что нельзя отнимать живое время людей, которые участвуют в дискуссии в живую, онлайн, или читая вычитку. Просто мгновенно отбирается микрофон при уводе в сторону.
Здесь у меня топик был — это «гольный код», конструкция из двух строк — аллокация (и в оригинале проверка), а также тупенькая-тупенькая функция-обертка. По всей строгости ожидается обсуждение вот этого примитивного кода «на мысленном экране», и ни в коем случае не отход в сторону.
Ситуация равноценная следующему.
Представьте мысленно что на доске написана формула. В дискуссии спрашивают — ну а вы видите что в числителе квадрат скорости? И тут человека вместо ответа на вопрос и вместо обсуждения формулки начинает нести, и он заявляет оппоненту: «А вы покажите-ка мне свои работы! А ну-ка, напишите-ка мне формулу за пять минут. А, да вы господин теохретик у нас!»
— Вы знаете что за такое будет? На него люди посмотрят как на демагога-софиста и тут же отберут микрофон. Я к такому не привык.
Почему я и говорю и требовал всю дорогу — «смотрите на формулу» господа, и не уходите в дебри. Ну а начинать обсуждать человека… Ну это вообще сразу «расстрел». В научной среде такого обсуждающего коллег человека (или постоянно уходящего от самой сути вопроса) «банят» тем что перестают приглашать на конференции.
У меня всё.
Надеюсь я сумел дать вам понять что происходило (предложение, «формулка» на доске), что я ожидал от присутствующих, и какую грязь тут устроили. Ну да это всё уже не важно.
Я обычный, приземленный человек. Который посоветовал (в отличие от вас) дельную хорошую мысль, которой я очень советую воспользоваться тем, кто реально разрабатывает новые проекты — эта мысль достаточно проста, тривиальна но в то же время хороша. В самом генеральном смысле это перехватить самым простым образом управление памятью на себя, в самом первом базовом случае обернув вызов malloc, заменив своей функцией, своим *alloc'ом. Эта мысль, если ее выслушивает адекватный, разумный человек — безусловно заслуживает одобрения.
В мысли нет ничего особо свежего и нового, и если бы Вы были не таким высокомерным снобом то просто бы одобрили, ну максимум скептически поинтересовались бы, слушай ну а как ты конкретно предлагаешь сделать… покажи что ли… Я вроде показал в рамках своих слов. Уже дважды.
Ну разумеется это не панацея всего и вся. Не надо произвольно расширять тезис! Работает не везде. Применимо не везде, например в существующий код с этим бездумно лезть как правило не стоит. Просто мыслишка, просто один маленький ход из десятков других, причем существуют и более мощные и генеральные.
Что уникально, если вычитать первый комментарий к статье — оказывается там Александр Патраков AEP написал ровно то же самое.
Но! Вместо всего этого меня обосрали как только могли. Поэтому я говорю — это тяжелый синдром непризнанного гения. Гадить на людей, совершенно отвращая их от того чтобы общаться. Пребывая в своем высокомерии «гении» полагают что люди чего-то там «не знают», что они убоги, неразумны, не логичны, противоречат и «несут бред». Но это не так, это у «гения» глаза застило.
Гуглите и почитайте: https://www.google.com/search?q=комплекс+непризнанного+гения там прямо о том как здесь общаются.
Вы уж определитесь, хотите вы участвовать в технической дискуссии или нет. Если хотите, то будьте готовы к тому, что ваши аргументы/убеждения/заблуждения будут подвергаться сомнению. Если не хотите, то зачем вы комментарии к техническим статьям пишете?
Верно, да не всё.
Если я с чем-то не согласен, я максимально обезличенно пишу о сути дела, не затрагивая человека. Расстроившись, я намеренно стал писать слова «Вы не правы». Когда все нормально, я даже не стремлюсь сказать что оппонент не прав, я говорю что это неправильная мысль, мнение, или взгляд. Или даже максимально обезличенное — «это не так», а это вот так.
Это — уважение.
Вы посмотрите пожалуйста что тут мне писали, ладно? И в какие-то астронавты меня записали, и оскорбляли то так, то сяк.
Вы посмотрите какое высокомерие. Стремление подчеркнуть якобы мое недопонимание, «странность», «заблуждения», «оторванность от жизни». Это стремление принизить, унизить человека.
И у меня не тонкая душевная организация. Я просто требую элементарного уважения,
чтобы общаться с радостью, а не как говна поел.
Потому что вы сами себе логически противоречите. Я написал о том, что архитектурно в CPP проектах следует избегать менеджмента памяти в C стиле, да и вообще по возможности избегать менеджемента памяти, как такового. Мой тезис вы подтверждаете своими словами:
Тем более, что в C++ работа с памятью в С-шном стиле не одобряется уже лет тридцать как.
.
То есть то, что пишу я, и то что существует на практике — полностью совпадает.
Но в вашем мозгу я как будто бы:
Вы тут выступаете с очень странными заявлениями, обосновать которые в предметном разговоре просто не можете.
Однако, поскольку представления о реальности у вас какие-то очень своеобразные
Вот и сейчас. У вас в голове что-то переклинило, ввиду чего вы начинаете зачем-то (зачем?) с апломбом рассказывать мне почему в C++ проектах все еще используется аллокация памяти.
У вас комплекс непризнанного гения, который всех вокруг видит эдакими неумехами и распальсовывая пальсы хочет всем (эх, неумехи же) снисходительно все объяснить.
Все свои слова касаемо замечания Евгения я обосновал и логикой и делом — показав код.
Вы же в ответ кроме хамства и требований «Покажите мне» ничего не сумели сделать.
Это я ответил Andrey2008, но что-то пошло не так. Смысл риторического комментария был в том, что от malloc-free или new-delete по-хорошему надо бы вообще по возможности отдаляться. Ясно что он это понимает, и вы это понимаете, и мой последний оппонент понимает, да выше пример был — в Chromium функции не используются, но как риторическое замечание — почему бы и нет? Почему это надо воспринимать сразу в штыки? :)
Так что спасибо за предложение, но существует ли надобность в такой статье? Без данного материала необходимости не было. И вряд ли существует в реальности. Разве есть смысл писать статью для комментов.
Я подумаю написать статью, спасибо. Но мне кажется надо начинать с чего-то попроще.
С комментариев начал, а оно что-то в штыки вышло :) ...?
1. Я вообще за то чтобы по-возможности не одобрять в pure C++ прямые выделения/деаллокации памяти в сишном стиле и работу с памятью.
2. Можно двигаться в сторону GC — архитектур + «активных» указателей/ссылок, т.е. смартпоинтеров. У народа есть опыт написания всей 3D engine полностью на смартпоинтерах, падение производительности незначительное.
3. Можно двигаться через создание domain-specific language's. Втч возможно динамически комплируемых, (с автоматическим управлением памятью) возможно, но не обязательно с байткодом, и возможно, но не обязательно с отложенной/статической компиляцией. Сейчас пока с этим заминка, основные VM пока громоздкие и малоупотребимые, а Framework'и для создания собственных DSL слишком сложны. Но это пока. В ближайшем будущем очень вероятен взрыв Intra-CPP решений, когда внутри/параллельно C++ решения находится несколько самопальных язычков под свои задачи.
4. Парадигма вида «попросить память» — что-то сделать — «отдать память» — древняя, архаичная как г. мамонта. Это идет с майнфреймов с виртуальной памятью. Вообще с мохнатых годов существуют иные способы работы с данными, не требующие парадигмы «запрос-работа-освобождение» и вообще даже не требующие понятия «память».
Приложение может, в конце концов, заменить malloc на свою собственную реализацию (как, кстати, Chromium и делает) — никакие обёртки после этого не нужны. Но библиотеки такой роскоши себе позволить увы, не могут.
Я уверен что и «обертку» вы как-то очень специфично по-своему понимаете. А что по-вашему «обертка», как не замена malloc'а на свою собственную реализацию? Я об этом в явном виде писал.
Вариант номер три (для Windows неприменим): вынести «тяжёлую» работу в отдельный процесс. При этом вы можете в случае нехватки памяти спокойно завершить его с помощью exit (как в вашем предложении).
Преимущества: так как это, фактически, развитие вашего варианта, то вы их и сами знаете.
Общение через shared memory достаточно быстрое. Процесс будет срублен только в случае фатальных происшествий, поэтому вполне себе рабочее решение — кстати приснопамятный Chrome представляет собой именно такой набор процессов.
Однако же должен упомянуть, (сам я, а не то, как вы додумали) ни в коем случае я не предлагал исходно рубить ВООБЩЕ ЛЮБОЙ ПРОИЗВОЛЬНЫЙ процесс, с помощью exit(), это вы уже произвольно додумали наблюдая просто образец кода, в котором exit() только для иллюстрации.
Который, впрочем, на практике-то как раз, вопреки всем исходно «навешанным на меня собакам» и всем крикам — имеет право на существование и имеет место быть! В особенности с развитием парадигмы Microservices. Причем на *NIX это вполне себе устоявшаяся парадигма программирования — порождение процессов вместо потоков и рубка их в случае чего.
А вот остальное, все что вы написали КРОМЕ отсылки к замене malloc и упомянутого мной выше коллбэка — это всё очень генеральные вещи, не имеющие НЕПОСРЕДСТВЕННОГО отношения к теме автора:
А именно, к функциям аллокации памяти + проверке возвращаемого значения. Это у вас произвольный текст «на тему». Он вообще никак не противоречит и пересекается с поднятой автором и мной темой постольку-поскольку, соприкасаясь с ней некоторыми фрагментами. То есть опять произвольное «расширение». Смысл? Ну смысл есть на поболтать. Но мои тезисы это никак не опровергло.
Насчет буфера.
Я также могу сейчас как это выше устроили, устроить балаган, закуситься с криком «где это вы возьмете доп. буфера в микроконтроллере» — и из этого устроить распальцовку с криками «аааа, не понимаете! А покажите мне доп. буферов на микроконтроллере с 2кб памяти». Слава богу, у меня все в порядке с рассудком. Но вы-то сделали по сути именно так!
Если обсуждать около-темы выделения памяти, вы не упомянули самые интересные и очень действенные методы. Что ж, «распальсую пальсы»:
Это:
а) Компрессия оперативной памяти.
б) Уничтожение содержащихся в памяти данных в случае нехватки памяти и воссоздание данных, там где можно (загрузка с диска).
в) Memory-mapped files.
г) Дефрагментация памяти.
д) Вызов garbage collector (шутка) :) если используется GC-архитектура.
Но это повторяю, к тому что мы обсуждаем постольку-поскольку. Не более чем «текст на тему».
P.S.
У меня тут отпуск и весь этот «обмен распальсовками» местных уникумов у меня просто отнимает время. Особо нового я ничего не узнал. Никто мне ничего уникального не поведал. Поэтому не обессудьте если я исчезну, смысл всех этих «распальсовок» исходно стремился к нулю.
с вашего категоричного комментария, что обёртки — это то, что только и нужно использовать. Комментария к статье, где, ещё раз напоминаю, обсуждаются только и исключительно библиотеки.
Не надо видеть слова «только», там где вам угодно и выгодно их видеть. Когда человек читает только то, что ему хочется (и еще в этом начинает уверять меня!!!) — это батенька, шизофреническое расстройство восприятия.
То что вы пишете — я такого не имел в виду. Не надо произвольно расширять тезисы, ага? А то это враньё.
То что я имел в виду (и только это, без вашего произвольного расширения) — я написал выше другим людям НЕОДНОКРАТНО. Повторять это и цитировать вам уже по третьему разу — считаю будет бредово, давайте читайте сам, сам, сам. Но не расширяя тезисы как вам это угодно!
Таким образом, все что вы здесь написали (вы конечно молодец) никоим образом не противоречит сказанному мной, все что вы там себе надумали — это ваши личные проблемы.
Вы статью-то вообще читали, которую мы тут обсуждаем? И именно в этом контексте идёт всё обсуждение.
Всё что здесь обсуждается — это проблемы только и исключительно библиотек.
Обсуждаются здесь не «проблемы библиотек», как это может понять только странный человек, а проблема обязательности проверки malloc-подобных функция на результат вызова, и обоснование почему не проверять нельзя. Во-первых, автором указано что проверялся сам Chromium, но в нем не оказалось проблем, поскольку он, как это и предполагалось, имеет чисто C++ код. Всё, точка, ваша карта бита. А далее, анализируя Chromium, чтобы поиметь хоть какой-то улов, автор переходит к массе библиотек (а также вступал в диалог с автором библиотеки, да и советы дает автором библиотек), однако же делать отсюда алогичный вывод что это проблема якобы «ТОЛЬКО библиотек» — нельзя, это вывод по типу «посчитал количество слов, сделал вывод», смотрю в книгу — вижу фигу.
Ну я лично, будучи в здравом уме и твердой памяти такого вывода о ТОЛЬКО библиотеках не сделал. Речь идет о любом коде вообще, поскольку функции аллокации памяти встречаются везде где угодно.
А вот с этого момента обсуждение, собственно, и стоит начать.
То есть до этого это был с вашей стороны трёп?
Покажите пример кода, который предлагает использовать — и давайте его сравним с банальной проверкой ошибок. Не какие-то «сферические принципы в вакууме», а реальный код, который реально может захотеться засунуть в биболиотеку. Не обязательно приводить его здесь — ссылка на реализацию где-нибудь на GitHub'е тоже пойдёт.
Я-то покажу, а вот мне хотелось бы знать, с каких это щщей вы в разговоре общаетесь со мной личными повелениями — А ПОКАЖИТЕ-КА МНЕ? Вам не кажется это нахальством или троллингом?
Вас понял. Диагноз — «архитектурный астронавт, на работу не брать ни под каким соусом» принят и зафиксирован.
Нет это я вас понял, вы хам. Вы обзываетесь и наклеиваете ярлыки. Это хамство запредельных масштабов, вы с чего взяли что можете общаться в таком ключе?
Потому что отговорки подобного плана — это как раз типичный признак: говорить умные слова мы умеем, писать код — нет. И неважно даже: вы считаете, что вы «переросли» этот этап и теперь можете работать «учёной совой» и «разрабатывать стратегию» или никогда не умели… важно что сейчас вы код не пишите — иначе пример того, во что вы так свято верите не требовал бы 20 часов работы, а занял бы 5 минут копи-паста.
Её-мое. Да что же это такое тут творится?
Да какая вам вообще разница, кто я? Обсуждайте идеи, обсуждайте события, но не людей! См. высказывание Элеоноры Рузвельт: «Великие умы обсуждают идеи. Средние умы обсуждают события. Мелкие умы обсуждают людей.»
Постыдились бы!
Далее я уже второй раз привожу свой код, а вы только трепете языком и наезжаете на меня с хамством.
// main.c
#include <stdio.h>
#include <stdlib.h>
#include <setjmp.h>
#include "testmemlib.h"
static int test_function() {
const int TEST_MEM_SZ = 16;
unsigned char *mem1 = NULL;
MALLOC_TRY
mem1 = (unsigned char *) test_malloc(TEST_MEM_SZ);
MALLOC_EXCEPT {
printf("memory allocation error!\n");
return 0;
};
// some memory usage, dump contents
{
int i;
printf("memory dump: ");
for (i = 0; i < TEST_MEM_SZ; i++)
printf("%02X,", mem1[i]);
printf("\n");
}
test_free(mem1);
return 1;
}
int main() {
printf("begin test\n");
if (test_function())
printf("test completed. well done!\n");
else
printf("test failed.\n");
return 0;
}
— Это либка из двух файлов. Родил за полчаса.
Не надо придираться, ныть о частностях и о возможных ошибках, это рождено реально, только что, за полчаса, в основном под воздействием вашего зашкаливающего троллинга. Это не является панацеей, commercial quality grade code и тестировалось методом двух запусков. На большее я пойтить не могу.
Тем не менее, это вполне рабочий код, он является либой чтобы снять все притязания, демонстрирует все обсуждаемые генеральные идеи и показывает что все решаемо.
Интересно, будет ли что-нибудь практическое по существу от вас, нетривиальный вы наш?
Опять 25. Вы хоть понимаете, что библиотека, позволяющая себе подобные вольности будет просто выкинула и замена чем-то другим? Потому что ей просто нельзя пользоваться в условиях, когда памяти не хватает (а когда её заведомо хватает и атак на вашу программу не ожидается, то никакие обёртки, собственно, не нужны — можно просто вызывать malloc и «надається на лучшее»)
Я понимаю, полнолуние, но все же, с чего вы взяли что всенепременно следует говорить о библиотеке, и что вам мешает реализовать callback?
В основном, понятно, нужно обсуждать «цену» такой обёртки (дополнительную память, влияние на код и прочее) — но пока примера реализации нет
И не в виде «псевдокода в комментариях» (любимое занятие астронавтов), а виде работающего кода!
Час моей работы стоит $50 и меньше чем на 20 часов я не размениваюсь. Предоплата в столь мелких случаях 100%. Как будете оплачивать?
Что и переводит нашу проблему в практическую плоскость: как, собственно, вы собираетесь писать вашу обёртку, чтобы удовлетворить этим самоочевидным требованиям.
Нет, не переводит. Экий вы шустрик. Это можно обсудить, вот только не в комментариях, и не в той форме, в которой вы это мне всё высказываете — не в форме похабного наезда.
Пока ничего, кроме словоблудия и «махания руками» вы не предложили — а ведь это ключевой момент!
Кто вам сказал, что в комментариях под чужой тематической статьёй я вообще, должен предлагать какие-то замечательные универсальные решения? Это вы с чего взяли? От большого ума?
Врать что я ничего не предлагал не надо.
Я предложил то, что посильно сделать в комментарии — самое первейшее решение a-must-have (задел на будущее) — это не обращаться НАПРЯМУЮ к malloc-подобным функциям, предусматривая в качестве задела нечто своё. Это первое что я написал в первом же сообщении! Первый и весьма разумный шаг.
В чем проблема? С чем спорим? Это что, как-то хуже? Нет, в простейшем случае это полностью равноценное решение прямому вызову malloc'а. Но зато чуть позже (вместе с аналогичным использованием своей free) — это даст ряд «вкусностей».
Это простейшее первичное решение «обёртка», вообще говоря, ничто иное, как собственный менеджер памяти. Со всеми вытекающими. В простейшем случае, как в комментарии — он заглушка, чекающая результат malloc. Далее у него можно спросить хэндл закладки для серии аллокаций с тем чтобы выйти из ряда вызовов, освобождая цепочки аллоцированных блоков. Можно попросить free(ptr1, ptr2); — т.е. «освободи-ка разом всю память что была между аллокациями такими-то и такими-то».
Заметьте: в отличие от вас я, как раз, знаю несколько способов это сделать Вы, в отличие от меня,
Да, с ЧСВ у вас всё в порядке. Прям интересно узнать — вы это такие выводы на базе чего делаете?
Вообще, годам к 30-ти должно уже отпускать кто «лучшее», а кто нет. Кто чего там «знает». На западе я тут вообще не замечал пальцев веером.
Но раз вы обозначились, охотно верю, поведайте несколько способов это сделать. Буду ждать.
категорично заявляете, что это — единственный возможный подход, что немедленно вызывает реакцию Architecture astronautus detected, fire protocol enabled
Исходная мысль была очень проста — вообще-то, размножать повсеместно один и тот же код не следует. https://en.wikipedia.org/wiki/Don't repeat yourself
И следует подумать как от этого избавиться наиболее элегантным способом.
Чего вы хотите от комментариев?
Я привел самое простейшее и самое прямолинейное, очевидное решение. Не лучшее, просто пример. ЭТО НЕ ЗНАЧИТ ЧТО ЭТО ПАНАЦЕЯ НА ВЕКИ ВЕКОВ, ДЛЯ ВСЕХ СЛУЧАЕВ И ВОЛШЕБНОЕ РЕШЕНИЕ — кто так думает и кидается с пеной это обсуждать… ну… у меня плохие новости…
Не надо никого хватать за горло и тут же требовать волшебной панацеи, применимой всегда и везде, и причем написать это тут же, в комментах. И объяснять что это невозможно тоже не надо, надо уметь общаться на определенном уровне.
Нет, я не спорю с автором статьи, а вместо повсеместных проверок предлагаю чуть более красивое решение.
Вместо того чтобы оспаривать тот совет которому вы, в итоге, сами же следуете, вам следовало бы написать уточнение.
...
В таком случае было бы хотя бы сразу понятно что именно вы предлагаете сделать.
Прочтите мой исходный комментарий до конца.
В его конце содержится ровно то, чем вы мне пеняете. Я предлагаю сделать (цитирую конец своего комментария):
Как выглядит более корректное решение?
На мой взгляд лучше не использовать эти системные вызовы напрямую. Использовать или другие библиотечные функции, или написать свои обертки и использовать их. Основная задача — оставить в коде только семантику работы с памятью, не загромождая его ничем посторонним.
Ключевая мысль: оставить в коде только семантику работы с памятью, не загромождая его ничем посторонним.
Как и почему это «работает», какие у этого есть небольшие дополнительные преимущества, а также краткую иллюстрацию си-кодом вы найдете в этой ветке комментариев, там же я кратко выделил всю суть дела (повторно цитирую): Andrey2008 объяснил почему результат вызова malloc() проверять надо, и аргументировал это в общем случае UB в случае отказа функции вернуть память и возврата null pointer. Я на это дополнил тем, что не совсем красиво будет ставить везде проверки, и что это функцию лучше обернуть проверкой, создав условие что null pointer никогда не вернется, также как это делает xmalloc.
Разумеется, я понимаю что проверки в одном месте (в обертке) в целом изоморфны проверкам в каждом месте после вызова.
Можно добиться как полностью сходного поведения программ, так и различного, никакой автоматической «панацеей» данное решение не является.
Помимо этого иметь под «рукой» свою замену malloc (а-ля «перехваченный») очень удобно исходя из массы других соображений. У меня это must have.
Я тут внимательнее вчитался в ваш текст, Евгений eao197, вы выдали себя с потрохами.
Эта обертка будет вынуждена возвращать результат операции, в том или ином виде. И не суть важно, будет ли этот результат возвращаться в виде голого указателя (что нам придется делать, если мы находимся в чистом C) или в виде какой-то обертки, вроде std::optional или folly::Expected. Все равно мы будем вынуждены этот результат проверять.
— Обратим внимание на ваши слова, Евгений, «вынуждена возвращать результат», «будем вынуждены этот результат проверять».
Это, наверное, у Вас как раз тот случай, когда человек понимает мелочи из C++ (std::optional, итд) но не понимает самую важную суть предлагаемого в разговоре, простейшее архитектурное и алгоритмическое решение. Но при этом как надуты щеки! :)
Еще раз поясняю специально для вас Евгений, суть предложения, что и зачем делается. Читайте внимательно!
malloc() заменяется на свою функцию-обертку.
Зачем это делается? Да затем, чтобы результату её вызова доверять в своем коде ВСЕГДА. Почему это можно делать?
Обертка внутри себя проверяет результат вызова malloc(), и в случае возврата malloc()'ом значения null pointer, обертка НИКОГДА не вернет в вызвавший её код null pointer, сразу предприняв какую-то обработку, которую можно задать универсальным callback'ом или прямиком прописав в данном конкретном случае данной конкретной обертки. Она просто не вернется назад. Всё, краш, fail. Памяти нет. Отказ.
А следовательно, вам не надо каждый раз писать в коде проверку результата вызова обертки.
Вам этот код был продемонстрирован выше. Все что вам нужно было сделать — просто проанализировать и понять его выполнение, прочитав комментарии за вызовом обертки.
ПОВТОРЯЮ :)
В чем плюс? В чем смысл всего этого?
В основном в том, что null pointer в вызываемый код не вернется НИКОГДА, и соответственно, результату вызова можно всегда полностью доверять. А это значит, что его НЕ НАДО ПРОВЕРЯТЬ. Это ровно противоположно тому что вы думаете и пишете.
Тем самым проблема постоянной проверки возвращаемого значения (и каких-либо дополнительных действий) уходит. В «клиентский» код (вызывающий обертку) никогда не может вернуться null pointer, и поэтому и проверять не надо и undefined behaviour не возникнет. Всё, проблема решена. Это понятно?
Надеюсь Вы всё поняли, Евгений eao197? Потому что если это не так, это фиаско, братан! Это фиаско! :)
Как и прежде, жду от вас дельных комментариев по-существу поставленного вопроса.
eao197, Евгений Олейников, вы занимаетесь пустой демагогией и мне уже просто интересно исследовать психологию, т.е у вас реальные проблемы, или же намеренно уходите от ответа, т.е. намеренно врёте в отсутствие аргументации.
Я же вам написал — давайте теперь по существу поставленного вопроса. А вопрос у нас по существу такой: Автор статьи, Andrey2008 объяснил почему результат вызова malloc() проверять надо, и аргументировал это в общем случае UB в случае отказа функции вернуть память и возврата null pointer. Я на это (пишу раз в десятый) аргументировал тем, что не совсем красиво будет ставить везде проверки, и что это функцию лучше обернуть проверкой, создав условие что null pointer никогда не вернется, также как это делает xmalloc.
Вы начинаете уводить в сторону, вместо обсуждения вопросов Андрея и моего, рассказывать постороннее, что в общем случае нельзя реализовать универсальную обработку случая отказа выделения памяти, о чем вам было неоднократно уже сказано:
Вопрос который остался за кадром — это что делать на системном слое сразу после вызова *alloc, если память не вернулась? Все поведение malloc() в оригинале предназначалось для GE-645 с которым работали в Bell Labs и который являлся мультизадачным mainframe с виртуальной памятью. Не исключено что в оригинале можно было подождать :) пока память появится. В данном же случае можно либо завершать процесс, выводить сообщение пользователю и ждать, либо предусмотреть какое-либо другое поведение, но это уже детали.
Конечно же нельзя предусмотреть абсолютно универсальную, общую функцию для абсолютно любых случаев в жизни. Если уж на то пошло, следует реализовать callback на желаемую функцию обработки ошибки и дело в шляпе. Но это не является поставленным вопросом, это офтопик, совершенно посторонняя деталь. Вопрос тут:
а) Тема начатая автором статьи
б) Мое дополнение (см. курсив выше)
Вот их и следует обсуждать, не уводя в сторону на несущественные по смыслу детали.
В связи с чем ваша попытка ответа не засчитывается, Евгений, пытайтесь еще. Ждем ответа от Вас на поставленный вопрос по-существу (выделено выше курсивом), ответ вы пока не дали, отделавшись отпиской.
В связи с чем такая недоброжелательность? Не припомню чтобы я вас чем-то обидел.
Я libunwind вчера мельком смотрел, когда пытался родить кодец менее убогий чем я запостил.
Но безусловно, вы правы, unwinding фреймов тут необходим.
Приятно с вами поговорить. Ну мы просто выше не поняли друг друга. Универсальное решение я не предлагал. Наоборот, вбросил простые две копейки.
Мне вот что интересно. Вы не могли бы припомнить ситуацию с GetMem в паскале, подробнее расписать что там было.
Что за резервный буфер? Это самопал какой-то?
Утомился я.
Обсуждать несколько строк рожденных на коленке за 30 минут глупо, они того не стоят. Но я понимаю что для вас как C++ кодера это желаемо. Вы можете факультативом, разве я могу вам запретить.
Но вы, Евгений Охотников eao197, лично тоже вызвали во мне огромный интерес!
Если вы такой крутой кодер (а это представляется мне несомненным),
нельзя ли глянуть на ваш код?
Хочется глянуть на ваши труды и может быть чему-то поучиться.
Не могли бы вы отправить меня по «ссылкам гордости» на практические фреймворки вашей разработки, на ваши архитектуры, системы, в крайнем случае ваши кодовые библиотеки? Я понимаю что можно «гугл в зубы», но вы сами выделите мне свою гордость?
Хочется прикоснуться к прекрасному.
Наверное да.
Но и мне понятно происходящее — кто же еще может крутиться под статьями о инструменте проверяющим C++ код?
Кодеры конечно же! А им это всё… У них другие сферы понимания. И профессиональная деформация.
Насчет науки. У меня несколько своеобразное отношение к современному положению дел, когда гонится индекс цитирования, индекс Хирша. На мой взгляд многое сейчас пустая макулатура.
Вы немного не так восприняли мою роль в науке. Моя деятельность это параллельная «вилка» в жизни — из прикладной науки и ПО, если вам интересно. Наука отдельно. ПО отдельно, как это часто и бывает.
По поводу кода… Вы знаете, я ни в коем случае не возьму на себя роль вот так вслепую сказать что я лучше вас. Во-первых, я вас не знаю и с вашим положением дел не знаком, мне и в голову не придет заявить нечто подобное! Это будет какой-то фантазией…
Во-вторых, я давно конечно же не кодер, и ну в общем я не могу этим похвалиться.
Но я понимаю вашу похвальбу как мастерового резчика по
деревукоду. Это профессиональное. Хорошо если так. Древесина, остро отточенный инструмент, хороший верстак, клей (знание языка, библиотек, особенностей компиляторов и сборки) — действительно, у мастеровых свой предмет для гордости. И нельзя отнимать у маленького человека его профессионализма, вот что важно.Но мне показалось вы упомянули Borland Pascal 6.0 — а это же довольно старый инструмент. Так что по подсчетам лет вам должно быть немало, не менее 50-55, а то и бери больше. Можно спросить, сколько вам? Вы до сих пор, в свои годы работаете программистом?
Да ну что вы, я не отнимаю этого у вас. Повторяю, я не мастер и не пытаюсь как-то претендовать на вашу мастеровую деятельность и отнять вашу прерогативу. Так сказать, охотно признаю в этом ваше преимущество. Заранее. Априори.
Вы родили во мне интерес.
Теперь мне стало очень интересно и хочется глянуть на ваши труды. Можно получить «ссылки гордости» на разработанные вами архитектуры, системы, фреймворки?
Просто захотелось прикоснуться к прекрасному.
Профессионально я стою на несколько ступенек выше C++ кодеров.
Сказать-то сказали, да вот никакого опровержения нет.
Вы логикой-то владеете? Соображаете что такое доказательство или опровержение?
Вы считаете что побредив про библиотеки, промычав отвлеченное что вот там-то при таких условиях это нельзя, это как-то опровергает или делает невозможным указанный прием?
Я вас спрашиваю да, или нет? Вот только не надо ожидать что это должно работать всегда и везде и являться универсальной паацеей. Человек сам предположивший такое (я этого не предполагал) и кинувшийся опровергать — реальный шизик.
c xmalloc давайте спорьте, со мной не надо.
Ага, не смог удержаться, поднагадил.
Как бы то ни было — для комментариев это пойдет. И это пруф. А вот вы пока что никому ничего еще не показали. Так что умойтесь.
Я прочел. Человек серьезно воспринимающий это поток сознания — вероятно полный дурак. Просто недоразвитый. Быдлокодер с манией величия, считающий этот бред откровением. Такое бывает у дураков. И в этом, видимо вся причина происходящего, я внезапно всё понял о вс.
Вы еще дом2 почитайте, там полно таких же потоков сознания.
Я занимаюсь наукой и участвую в научных дискуссиях. Там — за малейшей уход в сторону от вопроса сразу же бьется по рукам, потому что нельзя отнимать живое время людей, которые участвуют в дискуссии в живую, онлайн, или читая вычитку. Просто мгновенно отбирается микрофон при уводе в сторону.
Здесь у меня топик был — это «гольный код», конструкция из двух строк — аллокация (и в оригинале проверка), а также тупенькая-тупенькая функция-обертка. По всей строгости ожидается обсуждение вот этого примитивного кода «на мысленном экране», и ни в коем случае не отход в сторону.
Ситуация равноценная следующему.
Представьте мысленно что на доске написана формула. В дискуссии спрашивают — ну а вы видите что в числителе квадрат скорости? И тут человека вместо ответа на вопрос и вместо обсуждения формулки начинает нести, и он заявляет оппоненту: «А вы покажите-ка мне свои работы! А ну-ка, напишите-ка мне формулу за пять минут. А, да вы господин теохретик у нас!»
— Вы знаете что за такое будет? На него люди посмотрят как на демагога-софиста и тут же отберут микрофон. Я к такому не привык.
Почему я и говорю и требовал всю дорогу — «смотрите на формулу» господа, и не уходите в дебри. Ну а начинать обсуждать человека… Ну это вообще сразу «расстрел». В научной среде такого обсуждающего коллег человека (или постоянно уходящего от самой сути вопроса) «банят» тем что перестают приглашать на конференции.
У меня всё.
Надеюсь я сумел дать вам понять что происходило (предложение, «формулка» на доске), что я ожидал от присутствующих, и какую грязь тут устроили. Ну да это всё уже не важно.
В мысли нет ничего особо свежего и нового, и если бы Вы были не таким высокомерным снобом то просто бы одобрили, ну максимум скептически поинтересовались бы, слушай ну а как ты конкретно предлагаешь сделать… покажи что ли… Я вроде показал в рамках своих слов. Уже дважды.
Ну разумеется это не панацея всего и вся. Не надо произвольно расширять тезис! Работает не везде. Применимо не везде, например в существующий код с этим бездумно лезть как правило не стоит. Просто мыслишка, просто один маленький ход из десятков других, причем существуют и более мощные и генеральные.
Что уникально, если вычитать первый комментарий к статье — оказывается там Александр Патраков AEP написал ровно то же самое.
Но! Вместо всего этого меня обосрали как только могли. Поэтому я говорю — это тяжелый синдром непризнанного гения. Гадить на людей, совершенно отвращая их от того чтобы общаться. Пребывая в своем высокомерии «гении» полагают что люди чего-то там «не знают», что они убоги, неразумны, не логичны, противоречат и «несут бред». Но это не так, это у «гения» глаза застило.
Гуглите и почитайте: https://www.google.com/search?q=комплекс+непризнанного+гения там прямо о том как здесь общаются.
Верно, да не всё.
Если я с чем-то не согласен, я максимально обезличенно пишу о сути дела, не затрагивая человека. Расстроившись, я намеренно стал писать слова «Вы не правы». Когда все нормально, я даже не стремлюсь сказать что оппонент не прав, я говорю что это неправильная мысль, мнение, или взгляд. Или даже максимально обезличенное — «это не так», а это вот так.
Это — уважение.
Вы посмотрите пожалуйста что тут мне писали, ладно? И в какие-то астронавты меня записали, и оскорбляли то так, то сяк.
Вы посмотрите какое высокомерие. Стремление подчеркнуть якобы мое недопонимание, «странность», «заблуждения», «оторванность от жизни». Это стремление принизить, унизить человека.
И у меня не тонкая душевная организация. Я просто требую элементарного уважения,
чтобы общаться с радостью, а не как говна поел.
Потому что вы сами себе логически противоречите. Я написал о том, что архитектурно в CPP проектах следует избегать менеджмента памяти в C стиле, да и вообще по возможности избегать менеджемента памяти, как такового. Мой тезис вы подтверждаете своими словами: .
То есть то, что пишу я, и то что существует на практике — полностью совпадает.
Но в вашем мозгу я как будто бы:
Когда 1. мои слова соответствуют реальности, и когда 2. человек сам подтверждает мои слова, но при этом считает что я чему-то © «противоречу», это называется шизофрения.
Попытка видеть то, чего актуально нет. Попытка совместить несовместимые сущности.
Вот и сейчас. У вас в голове что-то переклинило, ввиду чего вы начинаете зачем-то (зачем?) с апломбом рассказывать мне почему в C++ проектах все еще используется аллокация памяти.
У вас комплекс непризнанного гения, который всех вокруг видит эдакими неумехами и распальсовывая пальсы хочет всем (эх, неумехи же) снисходительно все объяснить.
Все свои слова касаемо замечания Евгения я обосновал и логикой и делом — показав код.
Вы же в ответ кроме хамства и требований «Покажите мне» ничего не сумели сделать.
Всё. Лечитесь. Принимайте таблетки.
Конец связи.
Это я ответил Andrey2008, но что-то пошло не так. Смысл риторического комментария был в том, что от malloc-free или new-delete по-хорошему надо бы вообще по возможности отдаляться. Ясно что он это понимает, и вы это понимаете, и мой последний оппонент понимает, да выше пример был — в Chromium функции не используются, но как риторическое замечание — почему бы и нет? Почему это надо воспринимать сразу в штыки? :)
Так что спасибо за предложение, но существует ли надобность в такой статье? Без данного материала необходимости не было. И вряд ли существует в реальности. Разве есть смысл писать статью для комментов.
Я подумаю написать статью, спасибо. Но мне кажется надо начинать с чего-то попроще.
С комментариев начал, а оно что-то в штыки вышло :) ...?
2. Можно двигаться в сторону GC — архитектур + «активных» указателей/ссылок, т.е. смартпоинтеров. У народа есть опыт написания всей 3D engine полностью на смартпоинтерах, падение производительности незначительное.
3. Можно двигаться через создание domain-specific language's. Втч возможно динамически комплируемых, (с автоматическим управлением памятью) возможно, но не обязательно с байткодом, и возможно, но не обязательно с отложенной/статической компиляцией. Сейчас пока с этим заминка, основные VM пока громоздкие и малоупотребимые, а Framework'и для создания собственных DSL слишком сложны. Но это пока. В ближайшем будущем очень вероятен взрыв Intra-CPP решений, когда внутри/параллельно C++ решения находится несколько самопальных язычков под свои задачи.
4. Парадигма вида «попросить память» — что-то сделать — «отдать память» — древняя, архаичная как г. мамонта. Это идет с майнфреймов с виртуальной памятью. Вообще с мохнатых годов существуют иные способы работы с данными, не требующие парадигмы «запрос-работа-освобождение» и вообще даже не требующие понятия «память».
Я уверен что и «обертку» вы как-то очень специфично по-своему понимаете. А что по-вашему «обертка», как не замена malloc'а на свою собственную реализацию? Я об этом в явном виде писал.
Общение через shared memory достаточно быстрое. Процесс будет срублен только в случае фатальных происшествий, поэтому вполне себе рабочее решение — кстати приснопамятный Chrome представляет собой именно такой набор процессов.
Однако же должен упомянуть, (сам я, а не то, как вы додумали) ни в коем случае я не предлагал исходно рубить ВООБЩЕ ЛЮБОЙ ПРОИЗВОЛЬНЫЙ процесс, с помощью exit(), это вы уже произвольно додумали наблюдая просто образец кода, в котором exit() только для иллюстрации.
Который, впрочем, на практике-то как раз, вопреки всем исходно «навешанным на меня собакам» и всем крикам — имеет право на существование и имеет место быть! В особенности с развитием парадигмы Microservices. Причем на *NIX это вполне себе устоявшаяся парадигма программирования — порождение процессов вместо потоков и рубка их в случае чего.
А вот остальное, все что вы написали КРОМЕ отсылки к замене malloc и упомянутого мной выше коллбэка — это всё очень генеральные вещи, не имеющие НЕПОСРЕДСТВЕННОГО отношения к теме автора:
А именно, к функциям аллокации памяти + проверке возвращаемого значения. Это у вас произвольный текст «на тему». Он вообще никак не противоречит и пересекается с поднятой автором и мной темой постольку-поскольку, соприкасаясь с ней некоторыми фрагментами. То есть опять произвольное «расширение». Смысл? Ну смысл есть на поболтать. Но мои тезисы это никак не опровергло.
Насчет буфера.
Я также могу сейчас как это выше устроили, устроить балаган, закуситься с криком «где это вы возьмете доп. буфера в микроконтроллере» — и из этого устроить распальцовку с криками «аааа, не понимаете! А покажите мне доп. буферов на микроконтроллере с 2кб памяти». Слава богу, у меня все в порядке с рассудком. Но вы-то сделали по сути именно так!
Если обсуждать около-темы выделения памяти, вы не упомянули самые интересные и очень действенные методы. Что ж, «распальсую пальсы»:
Это:
а) Компрессия оперативной памяти.
б) Уничтожение содержащихся в памяти данных в случае нехватки памяти и воссоздание данных, там где можно (загрузка с диска).
в) Memory-mapped files.
г) Дефрагментация памяти.
д) Вызов garbage collector (шутка) :) если используется GC-архитектура.
Но это повторяю, к тому что мы обсуждаем постольку-поскольку. Не более чем «текст на тему».
P.S.
У меня тут отпуск и весь этот «обмен распальсовками» местных уникумов у меня просто отнимает время. Особо нового я ничего не узнал. Никто мне ничего уникального не поведал. Поэтому не обессудьте если я исчезну, смысл всех этих «распальсовок» исходно стремился к нулю.
Не надо видеть слова «только», там где вам угодно и выгодно их видеть. Когда человек читает только то, что ему хочется (и еще в этом начинает уверять меня!!!) — это батенька, шизофреническое расстройство восприятия.
То что вы пишете — я такого не имел в виду. Не надо произвольно расширять тезисы, ага? А то это враньё.
То что я имел в виду (и только это, без вашего произвольного расширения) — я написал выше другим людям НЕОДНОКРАТНО. Повторять это и цитировать вам уже по третьему разу — считаю будет бредово, давайте читайте сам, сам, сам. Но не расширяя тезисы как вам это угодно!
Таким образом, все что вы здесь написали (вы конечно молодец) никоим образом не противоречит сказанному мной, все что вы там себе надумали — это ваши личные проблемы.
Обсуждаются здесь не «проблемы библиотек», как это может понять только странный человек, а проблема обязательности проверки malloc-подобных функция на результат вызова, и обоснование почему не проверять нельзя. Во-первых, автором указано что проверялся сам Chromium, но в нем не оказалось проблем, поскольку он, как это и предполагалось, имеет чисто C++ код. Всё, точка, ваша карта бита. А далее, анализируя Chromium, чтобы поиметь хоть какой-то улов, автор переходит к массе библиотек (а также вступал в диалог с автором библиотеки, да и советы дает автором библиотек), однако же делать отсюда алогичный вывод что это проблема якобы «ТОЛЬКО библиотек» — нельзя, это вывод по типу «посчитал количество слов, сделал вывод», смотрю в книгу — вижу фигу.
Ну я лично, будучи в здравом уме и твердой памяти такого вывода о ТОЛЬКО библиотеках не сделал. Речь идет о любом коде вообще, поскольку функции аллокации памяти встречаются везде где угодно.
То есть до этого это был с вашей стороны трёп?
Я-то покажу, а вот мне хотелось бы знать, с каких это щщей вы в разговоре общаетесь со мной личными повелениями — А ПОКАЖИТЕ-КА МНЕ? Вам не кажется это нахальством или троллингом?
Нет это я вас понял, вы хам. Вы обзываетесь и наклеиваете ярлыки. Это хамство запредельных масштабов, вы с чего взяли что можете общаться в таком ключе?
Её-мое. Да что же это такое тут творится?
Да какая вам вообще разница, кто я? Обсуждайте идеи, обсуждайте события, но не людей! См. высказывание Элеоноры Рузвельт: «Великие умы обсуждают идеи. Средние умы обсуждают события. Мелкие умы обсуждают людей.»
Постыдились бы!
Далее я уже второй раз привожу свой код, а вы только трепете языком и наезжаете на меня с хамством.
— Это либка из двух файлов. Родил за полчаса.
Не надо придираться, ныть о частностях и о возможных ошибках, это рождено реально, только что, за полчаса, в основном под воздействием вашего зашкаливающего троллинга. Это не является панацеей, commercial quality grade code и тестировалось методом двух запусков. На большее я пойтить не могу.
Тем не менее, это вполне рабочий код, он является либой чтобы снять все притязания, демонстрирует все обсуждаемые генеральные идеи и показывает что все решаемо.
Интересно, будет ли что-нибудь практическое по существу от вас, нетривиальный вы наш?
Я понимаю, полнолуние, но все же, с чего вы взяли что всенепременно следует говорить о библиотеке, и что вам мешает реализовать callback?
Час моей работы стоит $50 и меньше чем на 20 часов я не размениваюсь. Предоплата в столь мелких случаях 100%. Как будете оплачивать?
Нет, не переводит. Экий вы шустрик. Это можно обсудить, вот только не в комментариях, и не в той форме, в которой вы это мне всё высказываете — не в форме похабного наезда.
Кто вам сказал, что в комментариях под чужой тематической статьёй я вообще, должен предлагать какие-то замечательные универсальные решения? Это вы с чего взяли? От большого ума?
Врать что я ничего не предлагал не надо.
Я предложил то, что посильно сделать в комментарии — самое первейшее решение a-must-have (задел на будущее) — это не обращаться НАПРЯМУЮ к malloc-подобным функциям, предусматривая в качестве задела нечто своё. Это первое что я написал в первом же сообщении! Первый и весьма разумный шаг.
В чем проблема? С чем спорим? Это что, как-то хуже? Нет, в простейшем случае это полностью равноценное решение прямому вызову malloc'а. Но зато чуть позже (вместе с аналогичным использованием своей free) — это даст ряд «вкусностей».
Это простейшее первичное решение «обёртка», вообще говоря, ничто иное, как собственный менеджер памяти. Со всеми вытекающими. В простейшем случае, как в комментарии — он заглушка, чекающая результат malloc. Далее у него можно спросить хэндл закладки для серии аллокаций с тем чтобы выйти из ряда вызовов, освобождая цепочки аллоцированных блоков. Можно попросить free(ptr1, ptr2); — т.е. «освободи-ка разом всю память что была между аллокациями такими-то и такими-то».
Да, с ЧСВ у вас всё в порядке. Прям интересно узнать — вы это такие выводы на базе чего делаете?
Вообще, годам к 30-ти должно уже отпускать кто «лучшее», а кто нет. Кто чего там «знает». На западе я тут вообще не замечал пальцев веером.
Но раз вы обозначились, охотно верю, поведайте несколько способов это сделать. Буду ждать.
Зачем вы врёте?
Приведите ссылку на мое сообщение, где бы я © «категорично заявлял» что это единственный подход.
Исходная мысль была очень проста — вообще-то, размножать повсеместно один и тот же код не следует.
https://en.wikipedia.org/wiki/Don't repeat yourself
И следует подумать как от этого избавиться наиболее элегантным способом.
Чего вы хотите от комментариев?
Я привел самое простейшее и самое прямолинейное, очевидное решение. Не лучшее, просто пример. ЭТО НЕ ЗНАЧИТ ЧТО ЭТО ПАНАЦЕЯ НА ВЕКИ ВЕКОВ, ДЛЯ ВСЕХ СЛУЧАЕВ И ВОЛШЕБНОЕ РЕШЕНИЕ — кто так думает и кидается с пеной это обсуждать… ну… у меня плохие новости…
Не надо никого хватать за горло и тут же требовать волшебной панацеи, применимой всегда и везде, и причем написать это тут же, в комментах. И объяснять что это невозможно тоже не надо, надо уметь общаться на определенном уровне.
...
Прочтите мой исходный комментарий до конца.
В его конце содержится ровно то, чем вы мне пеняете. Я предлагаю сделать (цитирую конец своего комментария):
Ключевая мысль: оставить в коде только семантику работы с памятью, не загромождая его ничем посторонним.
Как и почему это «работает», какие у этого есть небольшие дополнительные преимущества, а также краткую иллюстрацию си-кодом вы найдете в этой ветке комментариев, там же я кратко выделил всю суть дела (повторно цитирую): Andrey2008 объяснил почему результат вызова malloc() проверять надо, и аргументировал это в общем случае UB в случае отказа функции вернуть память и возврата null pointer. Я на это дополнил тем, что не совсем красиво будет ставить везде проверки, и что это функцию лучше обернуть проверкой, создав условие что null pointer никогда не вернется, также как это делает xmalloc.
Разумеется, я понимаю что проверки в одном месте (в обертке) в целом изоморфны проверкам в каждом месте после вызова.
Можно добиться как полностью сходного поведения программ, так и различного, никакой автоматической «панацеей» данное решение не является.
Помимо этого иметь под «рукой» свою замену malloc (а-ля «перехваченный») очень удобно исходя из массы других соображений. У меня это must have.
— Обратим внимание на ваши слова, Евгений, «вынуждена возвращать результат», «будем вынуждены этот результат проверять».
Это, наверное, у Вас как раз тот случай, когда человек понимает мелочи из C++ (std::optional, итд) но не понимает самую важную суть предлагаемого в разговоре, простейшее архитектурное и алгоритмическое решение. Но при этом как надуты щеки! :)
Еще раз поясняю специально для вас Евгений, суть предложения, что и зачем делается. Читайте внимательно!
malloc() заменяется на свою функцию-обертку.
Зачем это делается? Да затем, чтобы результату её вызова доверять в своем коде ВСЕГДА. Почему это можно делать?
Обертка внутри себя проверяет результат вызова malloc(), и в случае возврата malloc()'ом значения null pointer, обертка НИКОГДА не вернет в вызвавший её код null pointer, сразу предприняв какую-то обработку, которую можно задать универсальным callback'ом или прямиком прописав в данном конкретном случае данной конкретной обертки. Она просто не вернется назад. Всё, краш, fail. Памяти нет. Отказ.
А следовательно, вам не надо каждый раз писать в коде проверку результата вызова обертки.
Вам этот код был продемонстрирован выше. Все что вам нужно было сделать — просто проанализировать и понять его выполнение, прочитав комментарии за вызовом обертки.
ПОВТОРЯЮ :)
В чем плюс? В чем смысл всего этого?
В основном в том, что null pointer в вызываемый код не вернется НИКОГДА, и соответственно, результату вызова можно всегда полностью доверять. А это значит, что его НЕ НАДО ПРОВЕРЯТЬ. Это ровно противоположно тому что вы думаете и пишете.
Тем самым проблема постоянной проверки возвращаемого значения (и каких-либо дополнительных действий) уходит. В «клиентский» код (вызывающий обертку) никогда не может вернуться null pointer, и поэтому и проверять не надо и undefined behaviour не возникнет. Всё, проблема решена. Это понятно?
Надеюсь Вы всё поняли, Евгений eao197? Потому что если это не так, это фиаско, братан! Это фиаско! :)
Как и прежде, жду от вас дельных комментариев по-существу поставленного вопроса.
Я же вам написал — давайте теперь по существу поставленного вопроса. А вопрос у нас по существу такой: Автор статьи, Andrey2008 объяснил почему результат вызова malloc() проверять надо, и аргументировал это в общем случае UB в случае отказа функции вернуть память и возврата null pointer. Я на это (пишу раз в десятый) аргументировал тем, что не совсем красиво будет ставить везде проверки, и что это функцию лучше обернуть проверкой, создав условие что null pointer никогда не вернется, также как это делает xmalloc.
Вы начинаете уводить в сторону, вместо обсуждения вопросов Андрея и моего, рассказывать постороннее, что в общем случае нельзя реализовать универсальную обработку случая отказа выделения памяти, о чем вам было неоднократно уже сказано: Конечно же нельзя предусмотреть абсолютно универсальную, общую функцию для абсолютно любых случаев в жизни. Если уж на то пошло, следует реализовать callback на желаемую функцию обработки ошибки и дело в шляпе. Но это не является поставленным вопросом, это офтопик, совершенно посторонняя деталь. Вопрос тут:
а) Тема начатая автором статьи
б) Мое дополнение (см. курсив выше)
Вот их и следует обсуждать, не уводя в сторону на несущественные по смыслу детали.
В связи с чем ваша попытка ответа не засчитывается, Евгений, пытайтесь еще. Ждем ответа от Вас на поставленный вопрос по-существу (выделено выше курсивом), ответ вы пока не дали, отделавшись отпиской.