Ok so then what I think I’ll do is port the C part of my rust crate over to oiio proper, implementing just enough to add a simple round-trip test, is load an image, add an attribute to the header, write it out as an exr. Then I’ll make a PR so you can comment. Sound good?
On Wed, 21 Oct 2020 at 09:11, Larry Gritz <[email protected]> wrote: > That all sounds very reasonable to me. > > OIIO itself never throws exceptions, and in the few cases that the > underlying libraries do (OpenEXR seems fond of them), we try to catch them > as far internally as possible and relay the error conditions back out > through our own protocols of return codes and geterror() message retrieval. > So it seems to me that the C interface shouldn't need to deal with them at > all. > > -- lg > > > On Oct 20, 2020, at 12:44 PM, Anders Langlands <[email protected]> > wrote: > > The TypeDesc/ImageSpec strategy is exactly what I've done in oiio-rs, so > can confirm it works well. I actually ended up implementing overrides for > attribute_float, attribute_int etc, but I agree for the sake of simplicity > it would be better (and more C-ish) to just do the void* version and let > higher-level languages do whatever suits them best to polymorphize on top > of that. > > For null, again I wonder if we just leave the higher-level languages to > deal with it? If the C layer gets passed a null pointer it's the > higher-level layer that has the problem, not the intermediary. Yes it would > be safer to check, but that's a redundant check for languages like Rust > where you're guaranteed not to have a null pointer. > > Regarding exceptions, presumably it's possible to std::bad_alloc to still > bubble up? Not sure what the best way of handling that is - having an > exception thrown across the FFI boundary is bad news, but if it's > std::bad_alloc then the process is almost certainly just going to terminate > anyway... > > On Wed, 21 Oct 2020 at 08:22, Larry Gritz <[email protected]> wrote: > >> These are just guesses off the top of my head... >> >> >> On Oct 19, 2020, at 8:35 PM, Scott Wilson <[email protected]> wrote: >> >> - In the case of TypeDesc, we could probably have a 1:1 interface between >> C and C++. But something like ImageSpec would either have to replace the >> std::string with *char or we may need to make ImageSpec completely opaque. >> If we go for the latter, how do we want attrs such as width, height, etc to >> be exposed? >> >> >> TypeDesc should be 1:1 because it is POD and of fixed size by design. >> ustring is as well. Those things should be 1:1 if at all possible. >> >> Anything that has C++ classes inside, or needs allocation, etc., should >> probably just be an opaque pointer (everything is ImageSpec*, you never >> have a live ImageSpec in C). We'd need to add methods: ImageSpec_width(), >> ImageSpec_set_width(), etc. >> >> It doesn't make sense to have a *different* ImageSpec in C -- for example >> by having an analogous structure with char* instead std::string -- because >> how would yo pass it back to C++? Every C++ API call that takes an >> ImageSpec& would need to be wrapped in such a way that it constructs a C++ >> ImageSpec from the C ImageSpec, or vice versa, every time. No, in these >> cases, you'll just have to pass the pointers. >> >> >> - This may be a small thing, but when it comes to deleting objects, even >> if they don't have pointers/own data, do we want to always include a >> Type_delete method? For example, TypeDesc doesn't have/need a destructor. >> If we say everything has a destructor, then would there be a problem with >> that? >> >> >> I think any time you have a C++ object that you are going to tend to pass >> back and forth to C by pointer, you need an explicit C >> allocator/constructor and deallocator/destroyer, because you don't know if >> some time in the future the C++ implementation will have allocated >> internals or have ctr/dtr that do important things, and if they should >> acquire that in the future, you don't want to have to chase down every last >> use on the C side to change the calls. >> >> >> - How do we want to handle overrides? For example, if we have >> OIIO::ImageSpec.attribute("my_attr", 1.0), would we want to convert that >> into OIIO_ImageSpec_attribute_float("my_attr", 1.0)? What about with an >> unsigned integer? I'm assuming we'd want to call it >> OIIO_ImageSpec_attribute_uint(...). Also, in ImageInput, we have spec() >> with a reference to the ImageSpec, and spec(subimage, miplevel). I'm >> assuming the first will be OIIO_ImageInput_spec(), and the second will be >> OIIO_ImageInput_spec_with_subimage_miplevel(...) or something like that. >> >> >> I guess one question is whether we want to make a C API that is minimal, >> enough to do the job for language bindings, or if we want to replicate >> every last convenience function in C++, even the ones that are just trivial >> overloads for different types. >> >> For example, in C++, the important attribute call is >> >> void ImageSpec::attribute (string_view name, TypeDesc type, const >> void *value); >> >> which for C should be replaced with a const char* for the name. >> >> All the other overloads of attribute are just convenience functions to >> all you to pass a value that is a direct type and not a pointer, and in >> those cases remove the need to pass the TypeDesc. For example, >> >> attribute ("foo", my_float); >> >> is just a wrapper around >> >> attribute ("foo", TypeDesc::FLOAT, &my_float); >> >> So I think it's a judgment call about whether on the C side to just >> stick with the one core function, or also add the convenience wrappers. >> >> >> - Since we're probably going to be passing around ImageInput and ImageBuf >> as pointers (since they're a unique_ptr in C++), do we want to always >> assume that a pointer to an ImageInput/Output/Buf are not null, or add a >> check in the code for that? >> >> >> No opinion. Whatever is usual. I guess it's safer to always check. >> >> >> - Does OIIO have exceptions? Either way, probably want to make sure any >> exceptions passed from C++ don't cross over to the other side. >> >> >> We don't! Whew! >> >> -- >> Larry Gritz >> [email protected] >> >> >> >> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > > -- > Larry Gritz > [email protected] > > > > > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
