она может архитектурно полагаться на gc

типа строки просто конкатенировать

где-то внутри

следовательно тебе снаружи нужно будет ей либо способ как-нибудь передать (аллокатор), либо что-то ещё

в любом случае без изменения кода (а может и архитектуры) не получится

а кто за этим проследит, если ты хочешь использовать либу в программе без gc?

Под совмещай я имел ввиду использовать nogc с ручным управлением памятью либы

Обратно, естественно, не получится

Под совмещай я имел ввиду использовать nogc с ручным управлением памятью либы

так вот не все либы представляют такую возможность

Вы ещё мысленно держите что GC может быть встроен в ОС

спорное решение но может быть

так вот не все либы представляют такую возможность

Придут nogc аналоги, если, конечно, они нужны будут

они могут быть хуже или лучше, вот в чём фокус

не факт что освобождать память сразу это выгодно

иногда надо или рычаги снаружи для этого оставить или gc юзать (что проще)

не факт что освобождать память сразу это выгодно

+

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

не факт что освобождать память сразу это выгодно

Конечно не факт

ну да. И как предельный случай есть GC в Java который НЕ освобождает память, а просто её заполняет, после чего приложение убивается.

для всяких контейнеров отлично подходит. Затрат на GC ноль, в обмен на память

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

GC не зло, когда: 1. Приложение использует GC правильно 2. GC написан хорошо

GC не зло, когда: 1. Приложение использует GC правильно 2. GC написан хорошо

+1

GC не может быть написан хорошо

потому что это стратегия, а она бывает разная

Короч, мы не знаем как писать эффективные программы

всё это - искусство пока ещё

Тем временем GTA5 с 17 гб данных идёт на ps3 c 256мб озу и не крешится.

Тем временем GTA5 с 17 гб данных идёт на ps3 c 256мб озу и не крешится.

игровые движки это вам не сайты на пыхе

GTA, кстати, начиная с 3 — адски глючная жесть

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

Пошел срач

Тем временем GTA5 с 17 гб данных идёт на ps3 c 256мб озу и не крешится.

Ну так она писалась не как универсальный код

железо было точно известно

а когда ты пишешь под ПиСи ты даже не знаешь сколько памяти будет и какая у неё скорость

Думаю, там только параметры движка подкручивали.

вапщет знаешь. Стим тебе дает достаточно точную инфу

ну как точную, слишком большой разброс всяких таймингов

на приставках раньше вообще не парились и синхронизирвоали игры просто подсчётом тактов

Есть пара make/dispose для размещения/удаления

Имхо это всё что нужно

Могу заблуждаться

Есть пара make/dispose для размещения/удаления

иногда выгодно блобы сбивать в кучку и перемещать

зависит от ОС

и процессора

и неба и аллаха

иногда выгодно блобы сбивать в кучку и перемещать

Ну есть всякие очень специфические запросы конечно, но это не каждому нужно.

дык в том и дело что задачи все разные

Что-то мы давно не обсуждали betterC

Я вот тут столкнулся с дилеммой. Есть у меня проектик на betterC, очень очень быстро работает и итоговый бинарник весит 35кб. А если libc слинковать статически, все ужать и почистить от лишних символов, то получится 65кб. Красотища.

И захотел я добавить в программу опцию - в командной строке указать имя файла параметром, а в программе прочитать из этого файла ip адреса и фильтровать по ним трафик. И тут оказалось что betterC сильно убог. Я начал копать на тему парсеров cli аргументов и даже писать свой велосипед, нашел getopt и getopt_long на С, но там все так по наркомански сделано. Сначала надо указать массив опций, потом результат возвращается в виде индексов заданных опций и т.д.

И тут я подумал, а так ли уж плохо использовать рантайм D. Да бинарник будет весить под мегабайт, а не 65кб ну и что. Зато я могу удобно организовать парсинг параметров командой строки и чтение ip адресов из файла буквально за 40 строк. профит!

))))

@chebotarevp надо было полезный код компилить в betterC и остальное в обычном виде, а потом слинковать

Сделать типа so ? Хорошая идея

Я думал сделать 2 сборки, одна betterc с урезанным базовым функционалом, другая полноценная со свистелками и перделками вроде задания списка ip из файла.

Получится программа а внутри у нее betterc ядро, которое работает так же быстро и является nogc

Сделать типа so ? Хорошая идея

Я последнюю неделю перед отпуском именно с этим и игрался

Идея сделать какую-то уникальную апликуху, задача которой всего-то подключать разные *.so файлы, которые указываются в конфиг файле

А все остальное уже в самих библиотеках делать

У нас на работе проект на C#, там солюшены так и сделаны. Компилируется отдельно несколько библиотек, и все они потом подключаются в маленький запускальщик.

Луп, веб сервер

У нас на работе проект на C#, там солюшены так и сделаны. Компилируется отдельно несколько библиотек, и все они потом подключаются в маленький запускальщик.

И как? Практично?

И можно пересобрать каждый отдельный солюшен независимо.

И как? Практично?

Ну вроде как да, но я особо не распробовал, на всякий случай я пересобираю все модули всегда.

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

У меня основная проблема сейчас то, что сам луп тоже в такой либе

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

ERROR: S client not available

Если, скажем, луп окажется 5м из 20ти

То первые 4 я запущу, потом запустится сам луп

А вот оставшиеся расширения уже тютю...

Вот и думаю пока над этой проблемой

А зачем стараться все вынести в библиотеки? это не самоцель. пусть луп идет как часть встроенного приложения.

А зачем стараться все вынести в библиотеки? это не самоцель. пусть луп идет как часть встроенного приложения.

Идея была такой, что ты сам можешь заменить луп на тот, что ты хочешь

Или вообще его не использовать

Скажем мне больше подходит луп на базе ЛибАсинк, а другому ЛибЕвент, ЛибЕв или что-то другое...

И с таким подходом можно либо писать как в БетпрСи режиме, так и в простом. Ну или вообще на С/С++

Или том же Паскале

у кого-нибудь есть понимание зачем засунули код на С в phobos? https://github.com/dlang/phobos/search?l=c

думаю что-бы не возиться долго с тонкими вещами типа gzip, compress и прочее такого типа

Там в коммитах комментарии про Curl Option и zlib. Было просто лень переписывать zlib на d чтобы заработал curl и решили сишную включить

да, логично

ну как-то это дно

при кросскомпиляции особенно

Ну а что деать, никто не будет переписывать zlib, а curl должен работать

хз, по идее оно может брать либы из системы

но видимо это не всюду прокатывает

у кого-нибудь есть понимание зачем засунули код на С в phobos? https://github.com/dlang/phobos/search?l=c

Там сжатие и хеш. Лень было переписывать. УЖе протестированный работающий код.

Привет всем. Кто знает как сделать исполняемую shared library в linux? Библиотека glibc может быть исполняемая. И как я заметил она ни одна, но она при запуске срабатывает, а не выдает segfault

/lib/libc-2.28.so вот файл меня заставил задаться вопросом

а все нашел

Ну а что деать, никто не будет переписывать zlib, а curl должен работать

Вот это кстати первые кандидаты на применение betterc

Да. Но это скучно поэтому никто не будет заниматься переписыванием zlib )

Да. Но это скучно поэтому никто не будет заниматься переписыванием zlib )

меня этот момент достаточно сильно раздосадовал, думал даже попробовать)

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

если бы были юнит тесты то можно попробовать коллективно портировать по кускам. А вдруг там какой то копирайт?

Тоже самое верно про ди

божечки как же достал этот twitchapid релизиться, его автор наркоман какой-то. За 2 недели сделал 18 релизов. Просто помешаный.

Кстати, с kotlin-native на днях поигрался — весьма приятный язык, оказывается)