On Sat, Jul 28, 2012 at 3:26 PM, Stefan Stavrev <[email protected]> wrote: > "Unfortunately C arrays don't come with a size, so you'll just have to > assume > that the user has done the right thing here." > > How about we use vector<float>? It is either that, or provide an int > for the number of elements in the float array, which would make the > API uglier. But definitely not assume the user will do the right thing. > What do you think?
It may not be ideal, but assuming the user will provide you the right buffer length is pretty standard in C. More importantly, the OIIO API does this all over the place, so it's an API design choice which is firmly settled for OIIO. Consider the "pixel" parameter to ImageBufAlgo::fill() for example: bool fill (ImageBuf &dst, const float *pixel); It's certainly possible to design an API without this perceived problem, but consider the obvious alternative (for fill() as an example): bool fill (ImageBuf &dst, const float *pixel, int pixelSize); Now the user still has to provide the correct pixel size, but this time they have to also provide it explicitly. Depending how pixel is allocated, there's several ways to get this size wrong, in which case we'll crash just as surely as if we were using the current version of the API. Not only that, but passing array lengths along everywhere comes at a huge cost in usability. (If you've ever seen code using the abomination of an API that is Microsoft's "secure" alternatives to strcpy() etc, you'll know how much of a pain this can be!) Ok, so passing an explicit size isn't so great. What about std::vector<float> or another container class? The problem with these is that they really force the user into using the particular type the API user had in mind. OTOH, float* is the lowest common denominator - you can get a float* from any sane method of packed storage. A final solution to these problems might be to template everything on the type of the container. template<typename PixelContainerT> bool fill (ImageBuf &dst, const PixelContainerT& pixel); If you really need to write an ultimately reusable library this can be an option, but let's not kid ourselves: it nearly always comes with a large cost in implementation complexity. So let's just follow the precedent from the rest of OIIO here - no explicit sizes, no std::vector, and no templates. ~Chris _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
