https://opennet.me/openforum/vsluhforumID3/121256.html Под лицензией MIT опубликована кросс-платформенная библиотека декодирования изображений SAIL. SAIL - это переписанный на С ребрендинг кодеков из давно не поддерживаемой программы просмотра изображений KSquirrel, но с наличием высокоуровнего абстрактного API и многочисленными улучшениями. Целевая аудитория: просмотрщики изображений, разработка игр, загрузка изображений в память для иных целей. Библиотека находится в стадии разработки, но уже пригодна для использования. Бинарная совместимость и совместимость исходного кода на данном этапе разработки не гарантируется...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53354<br> https://opennet.me/openforum/vsluhforumID3/121256.html#81 Fri, 17 Jul 2020 09:08:12 GMT Большинство известных мне реализаций new в С++ вызывают внутри себя malloc (GCC/Clang/MSVC). В случае MSVC malloc вызывает HeapAlloc или VirtualAlloc из kernel32. Чтобы избавиться от вызова &#171;стандартного&#187; malloc я компиляю (вернее линкую, но не суть) с nodefaultlib/nostdlib/nolibc и делаю свою реализацю malloc/free, как правило из заранее выделенного буфера на старте программы. Это имеет свои недостатки, например приходится самому изобретать termination handler при вызове pure virtual функции-члена или изобретать каст из float/double в int (зачем-то подобные вещи впихнуты в crt и чтобы от него избавиться приходится изобретать велосипеды, хотя самописный каст из float в int работает бысрее). <br><br>eastl внутри себя вызывает &#171;собственную&#187; реализацию глобального оператора new [], т.е. ты условно всегда должен определить при использовании что-то подобное: <br><br>void* operator new[](size_t size, const char* name, int flags, unsigned debug_flags, const char* file, int line)<br>{<br> return ::operat https://opennet.me/openforum/vsluhforumID3/121256.html#80 Thu, 16 Jul 2020 19:11:37 GMT &gt; Да, это и имел ввиду. Свой аллокатор с точки зрения пользователя библиотеки. <br><br>Ну вон там выше пример, прямо в том файле.<br> https://opennet.me/openforum/vsluhforumID3/121256.html#79 Thu, 16 Jul 2020 18:42:46 GMT Нет, скорее потому, что im не отдельная либа, а "вещь в себе". А по поводу кривого апи&#8230; В любом случае, другого софта, подобного im, нет. Наверное, ни одна программа, кроме этой, не сможет тебе даже корректно ресайзнуть изображение. Там надо ресайзить через колорспейс luv (да, я сравнивал с lab, luv много корректней), чтобы не запороть файл. Особенно бросается в глаза, когда ты ресайзишь 600dpi в ~90dpi. Ну и потом, distort resize тоже выглядит значительно лучше топорного в лоб ресайза. Насчёт глюков не скажу, насчёт тормозов, я бы хотел чтобы cuda или opencl что-нибудь ускоряли там, но они ничего не ускоряют и только добавляют артефактов. Так что уж как есть, альтернатив просто не существует в природе (да, я в курсе про форки, они ни в какое сравнение не идут).<br> https://opennet.me/openforum/vsluhforumID3/121256.html#78 Thu, 16 Jul 2020 15:00:48 GMT С С++ конечно возникает проблема, т.к. почти все объекты вызывают С функции. То есть аллокаторов нужно указывать два - для аллокаций, которые делают С++ объекты сами внутри себя, и для сишных функций, которые этими объектами дёргаются. <br><br>Да-с, ничего путного в голову не приходит чтобы решить эту проблему. Идеи? &#128512;<br> https://opennet.me/openforum/vsluhforumID3/121256.html#77 Thu, 16 Jul 2020 13:30:55 GMT Неоценимой помощью проекту будет звёздочка (star) на Github. Спасибо за отзывы и предложения, друзья.<br> https://opennet.me/openforum/vsluhforumID3/121256.html#76 Thu, 16 Jul 2020 09:31:15 GMT &gt; g_pszImagePixels ... уже пахнет плюсами<br><br>Это... (g_)Global (p)Pointer to (s)String with (z)Zero terminator ImagePixels? Это пахнет венгерской нотацией, win api и кокой-то дичью... <br> https://opennet.me/openforum/vsluhforumID3/121256.html#75 Thu, 16 Jul 2020 08:40:02 GMT Да, это и имел ввиду. Свой аллокатор с точки зрения пользователя библиотеки.<br> https://opennet.me/openforum/vsluhforumID3/121256.html#74 Thu, 16 Jul 2020 07:36:11 GMT Потому что она тормозная и глючная блотварь с кривым API?<br> https://opennet.me/openforum/vsluhforumID3/121256.html#73 Thu, 16 Jul 2020 02:05:23 GMT &gt; - свой аллокатор - тоже очевидно что рано или поздно всплывёт опять <br><br>Именно свой аллокатор? А не возможность дать юзеру оверрайднуть на свой, типа как в https://github.com/Dridi/cashpack/blob/master/lib/hpack.c сделано? В идеале иногда еще хочется либу совсем без динамической аллокации, но это специфичная хотелка и не для такой либы походу.<br>