The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Доступна библиотека декодирования изображений SAIL, opennews (ok), 14-Июл-20, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


19. "Доступна библиотека декодирования изображений SAIL"  +/–
Сообщение от Аноним (21), 14-Июл-20, 23:10 
>API выглядит странноватым и избыточным

напиши почему именно, это можно обсудить.

Ответить | Правка | Наверх | Cообщить модератору

39. "Доступна библиотека декодирования изображений SAIL"  +3 +/–
Сообщение от Аноним (39), 15-Июл-20, 07:27 
Это все мое субъективное мнение, возможно, все нормально и хорошо, но:

Вот это   `struct sail_context *context;  SAIL_TRY(sail_init(&context));` Оно явно делает аллокации внутри себя. Как мне переопределить malloc с системного на свой? Что мне делать если я не хочу зависеть от crt? (Стоит добавить возможность «всунуть» свою реализацию alloc/free?).

`struct sail_context` Контекст нужен чтобы хранить метаинформацию о плагинах (скорее всего, исходники я не смотрел), но я знаю какие форматы изображений мне нужны, зачем мне загружать что-то в runtime -> Зачем мне плагины и этот «очередной» контекст? (Стоит добавить возможность статической линковки?).

Меня смущает SAIL_TRY, возникают вьетнамские флешбеки с SUCCEEDED и прочим win32 счастьем. Мне не нравится, когда в примерах демонстрируют обработку ошибок при помощи «внутренних» макросов, которые хз что делают, пока не посмотришь в исходники. Так же мне это говорит о том, что есть некий внутренний код ошибок. В итоге в проекте у тебя появляются sail_error_t, vata_error_t, SomeOtherErrorType, blah_error_t и они все работают по-разному.

`struct sail_image *image; unsigned char *image_pixels;` почему оно отдельно? Может стоило назвать sail_image_meta? Это вызывает у меня дискомфорт какой-то.  

Ответить | Правка | Наверх | Cообщить модератору

42. "Доступна библиотека декодирования изображений SAIL"  +/–
Сообщение от Аноним (21), 15-Июл-20, 10:04 
Дельные мысли, спасибо
Ответить | Правка | Наверх | Cообщить модератору

46. "Доступна библиотека декодирования изображений SAIL"  +/–
Сообщение от InuYasha (??), 15-Июл-20, 11:34 
>>Так же мне это говорит о том, что есть некий внутренний код ошибок.

И ничего страшного в этом нет. Для каждой библятеки заводи отдельый cpp-файл, там обрабатывай ошибки, а весь проект делай по-своему. Никто не заставляет же sail_error_t использовать повсюду.

Обычные сишные имена. Я бы назвал как-нить типа g_pszImagePixels, но это уже пахнет плюсами )

Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

54. "Доступна библиотека декодирования изображений SAIL"  +/–
Сообщение от Аноним (10), 15-Июл-20, 16:25 
А я сказал что это страшно или плохо? Мне не нравится этот подход. Если можно что-то сделать не вводя на каждый чих новые сущноности или типы, то почему этого не сделать?
Я хочу от подобных библиотек получить следующий интерфейс.

На чтение:
size_t sail_read_image(const char* path, char** buffer, plugins_list* /*Опционально: список или NULL*/);

Возвращает количество прочитанных байт, если 0 - ошибка, текст/код которой которой можно узнать вызвав условный sail_last_error();

На запись:
size_t sail_write_image(const char* path, const char* buffer, size_t buf_size, const sail_write_options* opt, plugins_list* /*Опционально: список или NULL*/);

Возвращает количество записанных байт в сжатом виде, если 0 - ошибка, текст/код которой которой можно узнать вызвав тот же sail_last_error();

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

> Для каждой библятеки заводи отдельый cpp-файл...

Спасибо, конечно, за ценный совет, а то я не знал как организовывать свои проекты (НЕТ!). Откуда такая мания давать советы, когда не просят на ровном месте.

Ответить | Правка | Наверх | Cообщить модератору

56. "Доступна библиотека декодирования изображений SAIL"  +/–
Сообщение от Аноним (21), 15-Июл-20, 17:39 
Я согласен со всем. То что можно сделать быстро, так это

- опциональный context для функций sail_read/sail_write. Эта идея уже витала, вы только её озвучили. Контекст хранит метаинформацию о плагинах, это верно! Нужен он например для получения списка поддерживаемых файловых расширений, например, чтобы сделать фильтр в диалоге выбора файлов
- функции sail_read_mem/sail_write_mem для уровня "Новичок"
- объединение sail_image и пиксельных данных - более чем очевидно что это нужно

То что сделать пока не знаю как:

- свой аллокатор - тоже очевидно что рано или поздно всплывёт опять

Что касается техники обработки ошибок, то я работал наверное с десятком из них. Такие TRY() макросы мне нравятся потому что:

- весь SAIL код, который может вернуть ошибку, выглядит унифицировано. Иначе разные функции начнут возвращать что попало как индикатор ошибки. Кто-то 0, кто-то NULL, и т.д. кто в лес, кто по дрова
- SAIL заботится об очистке памяти внутри себя при возникновении ошибки, опять же унифицировано. Макрос для этого просто называется по-другому, но код опять же выглядит унифицировано, хоть и слегка избыточно
- Макросы можно как хочешь тюнинговать. Например, чтобы проводить локальное деструктивное тестирование сделав так, чтобы макрос возвращал рандомные ошибки. Или печатать полотна бэктрейсов
- Клиентскому коду РЕКОМЕНДОВАНО использовать TRY() макросы, но вы же можете их и не использовать. Обрабатывайте результаты вызовов сами. 0 - успех, или код ошибки. Всё предельно просто.

Ответить | Правка | Наверх | Cообщить модератору

73. "Доступна библиотека декодирования изображений SAIL"  +/–
Сообщение от Аноним (-), 16-Июл-20, 05:05 
> - свой аллокатор - тоже очевидно что рано или поздно всплывёт опять

Именно свой аллокатор? А не возможность дать юзеру оверрайднуть на свой, типа как в https://github.com/Dridi/cashpack/blob/master/lib/hpack.c сделано? В идеале иногда еще хочется либу совсем без динамической аллокации, но это специфичная хотелка и не для такой либы походу.

Ответить | Правка | Наверх | Cообщить модератору

75. "Доступна библиотека декодирования изображений SAIL"  +/–
Сообщение от Аноним (75), 16-Июл-20, 11:40 
Да, это и имел ввиду. Свой аллокатор с точки зрения пользователя библиотеки.
Ответить | Правка | Наверх | Cообщить модератору

80. "Доступна библиотека декодирования изображений SAIL"  +/–
Сообщение от Аноним (80), 16-Июл-20, 22:11 
> Да, это и имел ввиду. Свой аллокатор с точки зрения пользователя библиотеки.

Ну вон там выше пример, прямо в том файле.

Ответить | Правка | Наверх | Cообщить модератору

58. "Доступна библиотека декодирования изображений SAIL"  +/–
Сообщение от Аноним (75), 15-Июл-20, 18:57 
Покажи пожалуйста если есть пример как ты используешь собственный аллокатор совместно с какой-то либоц. Можно в псевдокоде
Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

72. "Доступна библиотека декодирования изображений SAIL"  +/–
Сообщение от Аноним (39), 16-Июл-20, 02:17 
Эх… Мне откровенно лень делать полноценные примеры.

Просто скажу, как могло бы быть на мой взгляд.
Для С:

Некий внутренний макрос к alloc/free/realloc (https://github.com/nothings/stb/blob/b42009b3b9d4ca35bc703f5...)

Структура со стабами для пользовательских alloc/free/realloc. Судя по примерам, есть что-то подобное для seek/tell/flush/sync и т.д.

У себя я использую что-то вроде:
#define PUSH_TYPE(mem_arena, type, ...) (type *)push_mem__(mem_arena, sizeof(type), ## __VA_ARGS__)

#define PUSH_ARRAY(mem_arena, size, type, ...) (type *) push_mem__(mem_arena, (size)*sizeof(type), ## __VA_ARGS__)
И т.д.

Для C++ мне нравится подход eastl (https://github.com/electronicarts/EASTL).


Ответить | Правка | Наверх | Cообщить модератору

78. "Доступна библиотека декодирования изображений SAIL"  +/–
Сообщение от Аноним (75), 16-Июл-20, 18:00 
С С++ конечно возникает проблема, т.к. почти все объекты вызывают С функции. То есть аллокаторов нужно указывать два - для аллокаций, которые делают С++ объекты сами внутри себя, и для сишных функций, которые этими объектами дёргаются.

Да-с, ничего путного в голову не приходит чтобы решить эту проблему. Идеи? 😀

Ответить | Правка | Наверх | Cообщить модератору

81. "Доступна библиотека декодирования изображений SAIL"  +/–
Сообщение от Аноним (81), 17-Июл-20, 12:08 
Большинство известных мне реализаций new в С++ вызывают внутри себя malloc (GCC/Clang/MSVC). В случае MSVC malloc вызывает HeapAlloc или VirtualAlloc из kernel32. Чтобы избавиться от вызова «стандартного» malloc я компиляю (вернее линкую, но не суть) с nodefaultlib/nostdlib/nolibc и делаю свою реализацю malloc/free, как правило из заранее выделенного буфера на старте программы.  Это имеет свои недостатки, например приходится самому изобретать termination handler при вызове pure virtual функции-члена или изобретать каст из float/double в int (зачем-то подобные вещи впихнуты в crt и чтобы от него избавиться приходится изобретать велосипеды, хотя самописный каст из float в int работает бысрее).

eastl внутри себя вызывает «собственную» реализацию глобального оператора new [], т.е. ты условно всегда должен определить при использовании что-то подобное:  

void* operator new[](size_t size, const char* name, int flags, unsigned debug_flags, const char* file, int line)
{
    return ::operator new[](size);
}

void* operator new[](size_t size, size_t alignment, size_t alignment_offset, const char* name, int flags, unsigned debug_flags, const char* file, int line)
{
    return ::operator new[](size);
}

Т.е. если ты внутри своей библиотеки используешь new, ты можешь пользоваться своей реализацией оператора, и поставлять что-то подобное при компиляции по «умолчанию» при соответствующем флаге в CMake. Если пользователь захочет заменить, флаг ему в руки, пусть только переопределит твой глобальный new. Если ты не используешь нигде new, то черт с ним, макросов/стабов для alloc/free вполне хватит.  

Ответить | Правка | Наверх | Cообщить модератору

76. "Доступна библиотека декодирования изображений SAIL"  +1 +/–
Сообщение от Аноним (39), 16-Июл-20, 12:31 
> g_pszImagePixels ... уже пахнет плюсами

Это... (g_)Global (p)Pointer to (s)String with (z)Zero terminator ImagePixels? Это пахнет венгерской нотацией, win api и кокой-то дичью...  

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру