reworks _InputArray to be more robust with erased types
#26629
Conversation
|
@mshabunin why was the doxygen commit added here? Edit: perhaps this is a tree issue. I'll try rebasing and pushing again. Yup, was a tree issue on my end. Sorry for the ping. |
This commit refactors the `init` functions into constructors, so that the incoming `_ArrayOps` member properly initialised. We add a pointer to an `_ArrayOps` object, but don't do anything with it just yet.
|
I think I've cleared all the GCC warnings at this point. I'll look into the Windows issues if I get time later today. It looks like the Android CI needs to flip the C++17 switch before it'll pass. |
|
@cjdb, maybe you can rebase and update to our internal version? Thx |
|
@cjdb, can you please rebase? Thank you. |
|
@asmorkalov , should I backport that to 4.x? It slightly changes the API for InputArray. |
|
@vpisarev What is your opinion? |
|
RFC in clang: https://discourse.llvm.org/t/adding-a-size-based-vector-to-libc-s-unstable-abi/86306 and implementation: llvm/llvm-project#139632 |
|
The commit has been officially merged in clang |
Thanks for flagging. llvm/llvm-project#139632 has been merged, and this shouldn't affect anyone just yet (it's a prologue to the main change). llvm/llvm-project#155330 changes |
Sorry, I didn't see this until now. I'll coordinate with you on the rebasing effort. |
_InputArrayis a type-erased array wrapper that relies on casting avoid*to its original type, based on the value of an enum. C++'s strict aliasing rules don't permit this, unless the type we're casting the pointer to is the same type as what was originally erased. This is especially problematic forstd::vectorbecause the code assumes that vectors are simply a contiguous sequence of bytes, which isn't the case. (See #26289 for that discussion).This patch introduces an
_ArrayOpstype that enables virtual dispatch based on the type, which is always known at compile-time. Relying on the type system allows us to keep most of the logic constant, although a some simplifications were made possible (e.g. combining some of the matrix types into a single if-statement).Note: This is a reworking of #26423, applied to 5.x, and focuses only on
std::vector(#26423 attempted to change everything; this PR only changes what is absolutely necessary, and leaves the rest as future work). I've tested this change against the internal failing code, and it passes with these changes.Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
Patch to opencv_extra has the same branch name.