paleolimbot commented on issue #599: URL: https://github.com/apache/arrow-nanoarrow/issues/599#issuecomment-2451259020
> As far as error handling is concerned, maybe we could use C++ exceptions? I quite like exceptions although I'm vaguely aware that there's a large and vocal contingent who feel differently. There are some pretty serious performance issues that can result from using them inappropriately (e.g., one time I used them for something like StopIteration and it made the framework I'd written unusably slow), but I don't know that any of the types of errors that usually occur from a non-zero `ArrowErrorCode` fall into that category. If we did go that route we'd have a great workaround (just use the `nanoarrow/hpp/unique.hpp` header and make C library calls directly). > Are we definitely locked into C++17? Anything that we want to use in our own tests still has to be C++11 (we still have a rather important user, DuckDB, who supports C++11, so I think it's reasonable that our tests still run), but we can do things with higher standards if they are fenced with an opt-out define. I don't think we have any users interested in helpful C++ wrappers that are still using C++11 but we do have users that are specifically C++17 that might be (cudf, ADBC), and so I think anything higher than that is maybe not all that useful (but maybe possible with an opt-in define). > I wonder if it wouldn't be better to return a std::span instead of a data pointer. +1! It looks like that's our `ArrowBufferView` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
