Неужели все так плохо, как сказано.

Неужели это правда и свою учебную ценность тот пример давно утратил? :3

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

Ну да, хотя, я вроде где-то видел, что тот товарищ упоминал, о том, что пример вообще не скомпилируется в авторском варианте.

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

Поддерживаю, код специфичный, но далеко не самый худший. Если разобраться о чём в нём идёт речь, то код станет довольно понятен. На самом деле malloc часто выглядит подобным образом просто в силу тех операций, что ему необходимо выполнить для выделения памяти.

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

Ну да, хотя, я вроде где-то видел, что тот товарищ упоминал, о том, что пример вообще не скомпилируется в авторском варианте.

Тот товарищ упорот. Специально открыл книгу и там нету этих ошибок, их, видимо, допустил тот, кто набирал вопрос.

В каких исходниках можно посмотреть современную реализацию IRL?

Real-life реализации довольно сложные. Может быть проще поискать код с каких-нибудь университетских курсов, если хочется альтернативных вариантов.

В каких исходниках можно посмотреть современную реализацию IRL?

В исходниках newlib можно найти две реализации, очень простую для малых устройств и почти оптимальную для больших. А по поводу книги, то я бы не принимал там все на веру буквально, потому что k&r c и ansi c всетаки разные языки и не всегда совместимы между собой.

Автор ответа понтуется. Большая часть - вкусовщина, плюс некоторые моменты совсем спорны.

Значится мы это так и запишем :-)

Спасибо.

Уметь писать кастомный аллокатор надо.

Какая-то школота там...

4) Assignment inside conditions is dangerous and hard to read.

7) Always uses braces after every statement. Not doing so will lead to bugs bugs bugs.

начётчики буквально.

В той книге, что читал я (кажись второе издание) как раз ansi c описывают, а не k&r.

В каких исходниках можно посмотреть современную реализацию IRL?

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

7-й пункт — дельфизм/шарпизм

4-й — распространённое мнение

Во всех свежих языках (rust, go, swift) 7ой пункт обязателен, без фигурных скобок написать if не получится. И это не потому что все авторы упоролись, а потому что это действительно предотвращает ошибки.

7-й пункт — дельфизм/шарпизм

А вот в delphi и C# можно писать как хочешь, и не соблюдать 7ой пункт, так что я не вижу тут никакой связи.

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

Упорлись. Как можно ошибиться в:

doSomething();

if(condition)
  doSomethingElse();

doOneMoreThing();

Ты же не пишешь в арифметическом выражении: (3*4)+5 ?!

Ты же не пишешь в арифметическом выражении: (3*4)+5

Конечно пишу %) A если 3, 4 и 5 длинные, то можно вообще разделить на два выражения.

Упорлись

Как говорится в басне про обезьян и печатные машинки, если взять 100 программистов, то среди них обязательно найдутся те кто «быть клиническим дебилом» и сделают тут ошибку. Например такую:

if (cond)
  foo();
  bar();

if (cond)
  // comment
  // foo();
bar();

В математике считается признаком дурного тона ставить лишние скобки и писать лишние символы.

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

в C# точно нельзя

if(x) y++;

даже не скомпилится

, а в Дельфи, как минимум, не принято

Это всё конкретный кодинг стайл конкретной команды обезьян. В таких случаях обычно весь кодинг стайл стандартизируют, где пробелы ставить перед скобками, где фигурные, где комментарии и прочую пунктуацию, любые нарушения отрезаются автоматом на стадии коммита. Как раз в этих случаях в первую очередь уделяют внимание исключению ошибок первого рода. Подом это уже идёт на review внутри команды и взрослыми дядями, и только потом попадает в дерево. В этих делах каждый своё болото хвалит. Но от этого оно не перестаёт быть вкусовщиной. Мне лишние кодовые блоки мешают нормально читать код, я трачу на него времени больше, чем если бы их не было. Другие наоборот их любят. Одни любят короткий, лаконичный код, другие - графоманский (зато понятный даже тому, который мимо проходил). У некоторых вообще не больше 1 видимой извне йункции на файл, у других функция не должна превышать 20 строк исключая комментарии. Все изголяются по своему.

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

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

ну и таки да - требования к подготовке рядового кодовой службы делает бюджетней.

if(x) y++;
даже не скомпилится

Хоть бы проверил перед тем как писать такую чушь

как минимум, не принято

«не принято» не запрещает людям писать как кто хочет

Если вспомнить тему топика, то можно заметить, что автор 7ого пункта на so исправил вот такой код:

if (a)
  b();
else {
  c();
  d();
}

if (a) {
  b();
} else {
  c();
  d();
}

Зачем ты оправдываешь свои убоги потуги брехнёй?

     if (p->s.size == nunits)           /* exactly */
      {
        prevp->s.ptr = p->s.ptr;
      }
      else                               /* allocate tail end */
      {
        p->s.size -= nunits;
        p += p->s.size;
        p->s.size = nunits
      }

Неужели кому-то первый вариант нравится больше?

Всем вменяемым людям. Зачем мне захламлять код лишними символами?

Это из разряда if(p != NULL) вместо нормального if(p) и прочил хлсных потуг.

Да и к тому же это с else, а без него будет просрана строка.

P.S. он ставит открывающие скобки на новую строку, так что количество строк всетаки увеличилось, но аргумент остается.

А, дак ты понял, что набрехал, но

автор 7ого пункта на so исправил вот такой код

Не исправил - показательно.

Конечно пишу %) A если 3, 4 и 5 длинные, то можно вообще разделить на два выражения.

Скобки и так разделяют на подвыражения. Для этого в коде так же используются пустые строки, чтобы разбить портянку на отдельные блоки.

К неосиляторству идиотами синтаксиса это никакого отношения не имеет.

Например такую:

Это никогда так не отформатируется.

У меня это превращается в

  if(cond)
    foo();

  bar();

  if(cond)
    // comment
    // foo();
    bar();

Две лишних скобочки небольшая плата за гарантию отсутствия целого класса ошибок в коде.

Таких ошибок не существует, а идиоту ничего не поможет.

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

А еще такие ошибки можно получить и без «дебила» в команде, например после auto merge.

Он сам по себе произошел? Нет, благодаря дебилам.

У меня это превращается

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

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

Таких ошибок не существует

Только если ты пишешь код один.

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

Ну дак с чего вдруг идиот стал писать код? Его призвание мести улицу - пусть метёт. Хотя да, это мир такой, что тот, кто ещё буквально 30лет назад мыл бы полы сейчас «программист».

Гораздо практичнее привести весь код к общему знаменателю

Гораздо практичнее отправить все, что призван в этот ми мыть мыло - мыть полы. И тогда всё будет отлично.

Давай вообще жрать/срать/спать - ведь что-то делать опасно. Переведём себя к общему знаменателю с обезьяной, хотя 98% и не отводили себя от неё.

запретить спорные конструкции и не создавать проблем ни себе ни другим. Хотя, конечно, админу локалхоста не понять.

Для идиотов есть языки для идиотов. Если ты не можешь писать код - не пиши - мой полы, либо вперёд в пхп.

Хотя, конечно, админу локалхоста не понять.

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

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

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

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

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

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

Царь залогинься!

Пока цари исходятся на форумах, кто-то должен решать реальные задачи.

Самое забавное в этом то, что большинство разработчиков покруче «царя» будут :)

А если не один, то вводится code review и публичный линчинг за такие ошибки. Мозг погромисту дан чтобы пользоваться, а не чтобы отмазываться. Не зря джуниоров старшие собрятья бьют - они учатся, и подрастают, и перестают по тупому косячить, начинают по умному, чтобы всем отделом 2 недели без выходных баг искать. А подстраивать всю команду под слабое звено - неэффективно. Так как вы избавляетесь так от самого простого класса ошибок, который виден при беглом просмотре за 5 минут, создаете себе кучу лишних заморочек и всё равно у вас косяки на том же уровне (или на худшем) чем у команды с традиционным стилем кода.

вводится code review

Coding style вводится.

А вообще нормальный разработчик должен уметь «делать, как вокруг».

традиционным

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

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

Кто хотел аллокаторы? Их есть у меня:

Легендарный: https://github.com/OpenMusicKontrollers/Tjost/tree/master/tlsf-3.0

И популярный https://github.com/ennorehling/dlmalloc

А так же молодой, но подающий надежды https://github.com/dimonomid/umm_malloc

Я!

Спасибо, посмотрю.

Если ты параллельно пишешь на питоне - то можно.

PS Лушчий выход тут, конечно, не писать на питоне.

Вот тут ещё бенчмарк аллокаторов:

http://webkit.sed.hu/blog/20100324/war-allocators-tlsf-action

P.S.: Не все смотрят в удаленное.

Вот-вот. Лучше не писать на питоне. Язык в котором логика операций зависит от отступов - весьма сомнительный инструмент.

вот это занятно. хотя... бенчмарки - дело довольно тонкое. слишком много критериев. но в общем интересно.

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

Фредерик Пол. Эпоха нерешительности.

оба на - оба - два

https://books.google.ru/books?id=lJa6CwAAQBAJ&pg=PT210&lpg=PT210&...

Я не могу понять твоей логики. Вариант со скобками преимущества имеет (пусть и спорные, да), а какие преимущества у варианта без скобок? Кажется очевидным, что из двух вариантов при прочих равных следует выбирать тот, что имеет (пусть спорные) преимущества.

Ну там для Веба оценивали, в других приложениях ситуация может измениться, да.

микроконтроллерах динамику тщательно избегают.

Уже нет, причем довольно давно:

• FreeRTOS — без динамики никуда, нет, я конечно знаю про «закрытые» форки FreeRTOS без динамического выделения памяти, но оно не совместимо по API с родителем...
• ChibiOS тоже умеет в динамику: http://chibios.sourceforge.net/docs3/rt/group__memory.html
• LWIP использует собственный аллокатор с пулом.

Я вот задумался над добавлением c11 threads API в BuguRTOS, тоже аллокатор нужен...

Josh Triplett - Porting Python to run without an OS - PyCon 2015

вообще забавно что первые Lisp(и даже ipl"55"(ipl-58 точно))-системы на ibm704 имели памяти меньше чем ща доступно на «обычном» микроконтролере

а вот любовь к ручному управлению памяти - это всёж профдеформация(иного полезная чё уж там)

Это не профдеформация, это отраслевой стандарт.

линк на?

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

так и с полной динимикой-кучей. - есть практика и достаточность решений. и таки дарвин прав.