Ну и да, это всё сахар, хидер должен читаться легко, вот самое главное. Тот же go-to-definition решает все проблеммы, и есть в любом, уважающем себя инструменте.

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

Ну и алыверды:) Как минимум можно разбить условно на libname-types.h и libname.h

Как минимум можно разбить условно на libname-types.h и libname.h

Сто раз уже это разбито:

./base:
smlbase.c  smlbase.h  smlconsts.h

./engine:
smltheme.c  smltheme.h

./events:
smlevents.c  smlevents.h

./graph:
smlgradient.c  smlimage.c  smlraster.c           smlraster.h
smlgradient.h  smlimage.h

./local:
smlcheck.h     smlhandlers.h  smlprofiler.h   smlwarehouse.h
smlhandlers.c  smllocal.h     smlwarehouse.c

./math:
smlgeometry.c  smlgeometry.h  smlmath.c  smlmath.h

./parser:
smldio.c  smldio.h  smlparser.c  smlparser.h  smlstrings.c  smlstrings.h

./screen:
smlbuttons.c  smlfonts.c  smlscreen.c  smlwindows.c
smlbuttons.h  smlfonts.h  smlscreen.h  smlwindows.h

./templ:
smllistsd.c  smllistsd.h  smllistss.c  smllistss.h

./time:
smltime.c  smltime.h

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

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

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

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

Повторюсь - важен не обьём кода, модуль в nк строк может легко и непринуждённо читаться при условии, что речь в нём идёт об одной и той же сущности.

Ну это на самом делё всё так - моё тухлое имхо.

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

код сворачивай, и будет тебе щастье.

ЗЫЖ юзаю вим.

ЗЗЫЖ

Юзаю QtCreator для plain-си проекта. Он тоже notepad.exe?

открой для себя kDevelop

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

Ну да, нам же с кодом надо работать, да с объектами живыми, а не строчки править в файлах каких-то.

literate programming?

но 1875я строка мне говорит, что надо бы файл немного того

Тогокать файлы — для слабых духом.

• https://github.com/blaenk/jediacademy/blob/master/codemp/ui/ui_main.c
• https://github.com/mojolingo/asterisk/blob/ab490db709efbca7e4766bc7e5c368039c...
• https://github.com/laurynasl/Libxml2/blob/master/parser.c

Жесть.

Про sqlite сразу подумал при виде таких простыней(:

Наркоман что ли?

На glibc посмотри, вот уж где норкоманы порезвились.

glibc — цветочки. Истинные наркоманы написали glib.

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

Кстати, в статической библиотеке обязательно должно быть "файл == 1 функция", иначе библиотека будет очень жирной. А так тупо из архива выдернется функция — вуаля!

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

Если бы программисты работали не спустя рукава, а хоть чуточку ответственно, такого беспредела не было бы! И современные операционные системы не требовали бы 1-2ГБ оперативы тупо чтобы работать...

Все претензии к тем уродам, которые пишут линкеры.

А что, разве целиком вся динамическая библиотека в память запихивается? Я думал, что точно так же, как в статической, распаковывается лишь файл с нужной функцией...

Как страшен мир!

Кстати, в статической библиотеке обязательно должно быть «файл == 1 функция», иначе библиотека будет очень жирной. А так тупо из архива выдернется функция — вуаля!

Пойди про -ffunction-sections почитай, что ли.

А что, разве целиком вся динамическая библиотека в память запихивается?

Она целиком mmap-ится. Реально в память попадут только используемые страницы.

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

Вон, выше i-rinat про это намекал. Только я что-то не встречал этих флагов (кроме разве что embedded) в обычном софте...

А ведь это должно быть поведением gcc по умолчанию!

А ведь это должно быть поведением gcc по умолчанию!

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

Сфигали это увеличит потребление памяти, если будет использоваться лишь то, что нужно?

Бинарники больше станут.

Сфигали? Как раз-таки меньше (при статической линковке, а при динамической пофиг).

Капец

Ламерье, никогда не создававшее статических библиотек, детектится сразу.

Потому что принцип «одна функция на один .c-файл» — это как раз оттуда. Из каждого исходника получается объектник, и линкер дёрнет из библиотеки только те, в которых есть используемые функции. А если лепить по несколько функций в один исходник — в екзешник попадут и те, что не вызываются ни разу. (Да, нынешние оптимизаторы могут и их выкидывать в некоторых случаях, но есть нюансы.)

Как раз-таки меньше (при статической линковке, а при динамической пофиг).

Разве что на программах типа «hello world», где всё равно пофиг, сколько занимает бинарник, 10 kB или 300 kB.

10 kB
hello world

Это наркоманство! Хелловорлду максимум байт 100 надо!

Хелловорлду максимум байт 100 надо!

А сваргань что-нибудь зашибатое в пару-тройку сотен байт?

Я надеюсь, хоть тестами оно покрыто?

Я надеюсь, хоть тестами оно покрыто?

libxml2 — да. Даже утечки памяти проверяются. Но это не мешает ловить от неё сюрпризы.