Show Posts
16
Feature requests / Re: Image saving
« on: July 02, 2019, 05:39:32 pm »
Well, SFML uses void now because everywhere the buffer size is known and 'big enough'.
This can't happen with std::vector so a different API would have to be made to allow user to alloc a buffer and handle failure nicely, something like:
Where return bool would say if there was enough space to write it all out or not and outsize would always contain how much bytes would be written if there was enough space. Some C, POSIX and WinAPI functions do it that or similar way (like some signed size type as return and -1 there as error), even allowing calling with NULL ptr and 0 size to get just the output size but that's starting to get too un-SFML-like (and kind of cumbersome to use, I always wrap these myself to just do right thing with dynamic allocation in C and C++ when I need them or make sure the buffer is way bigger than required so they can't fail).
With std::vector (which I don't mind since it solves the size problem and SFML already uses STL a lot and isn't some tight no-lib-side-mem-alloc-ever low-level hardcore library) either char or uchar are fine. Either choice will have someone preferring the other one, since both have decent reasons for being used (char is 'default' byte type to use, and uchar has the nice property of being unsigned so no sign and sign extensions shenanigans take place).
Alternatively a callback function or class could be used and use a const void ptr there but that still leaves a sort of gap in API where reading can be done from 3 source (stream, file, memory) and writing to 2 (file, stream) with memory missing/part of stream (while for reading there is memory input stream but also outright loadFromMemory call that takes just const void ptr and size).
This can't happen with std::vector so a different API would have to be made to allow user to alloc a buffer and handle failure nicely, something like:
bool sf::Image::saveToMemory(void * buff, std::size_t size, std::size_t& outsize);
Where return bool would say if there was enough space to write it all out or not and outsize would always contain how much bytes would be written if there was enough space. Some C, POSIX and WinAPI functions do it that or similar way (like some signed size type as return and -1 there as error), even allowing calling with NULL ptr and 0 size to get just the output size but that's starting to get too un-SFML-like (and kind of cumbersome to use, I always wrap these myself to just do right thing with dynamic allocation in C and C++ when I need them or make sure the buffer is way bigger than required so they can't fail).
With std::vector (which I don't mind since it solves the size problem and SFML already uses STL a lot and isn't some tight no-lib-side-mem-alloc-ever low-level hardcore library) either char or uchar are fine. Either choice will have someone preferring the other one, since both have decent reasons for being used (char is 'default' byte type to use, and uchar has the nice property of being unsigned so no sign and sign extensions shenanigans take place).
Alternatively a callback function or class could be used and use a const void ptr there but that still leaves a sort of gap in API where reading can be done from 3 source (stream, file, memory) and writing to 2 (file, stream) with memory missing/part of stream (while for reading there is memory input stream but also outright loadFromMemory call that takes just const void ptr and size).
