CARVIEW |
Navigation Menu
-
-
Notifications
You must be signed in to change notification settings - Fork 56.2k
G-API: GAPI introduce compile guard for some types for gin/gout params passing #21041
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if we need to develop a new tagging mechanism here, it will oblige us to add these tags for every new g-type. We can check GTypeTraits::shape to define a g-type, this will automate this gin/gout prohibition for newly added types. For special types (own::Mat) we can simply have a list of prohibited types and check it too
Now tags are part of
Additional Personally I would prefer tagging mechanism here because it do-not-broke-anything and simple-in-use... BUT current implementation is quite far from my initial intention due to failing Python compilation and I need to recycle GtypeTraits here anyway.. So maybe you right and reusing Let's reuse |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, just minor cosmetics
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks!
#define GAPI_OWN_TYPES_LIST cv::gapi::own::Rect, \ | ||
cv::gapi::own::Size, \ | ||
cv::gapi::own::Point, \ | ||
cv::gapi::own::Point2f, \ | ||
cv::gapi::own::Scalar, \ | ||
cv::gapi::own::Mat |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why use macro here and not an enumeration via tuple?
Macros seem old-fashioned (and sometimes dangerous) now when we have variadic templates
@dmatveev about MACRO, it's quite usable sometimes, for example In current code this MACRO does declare list for variadic params in |
@alalek Could you merge it please ? |
G-API: GAPI introduce compile guard for some types for gin/gout params passing * Initial for taged solution * Move out tags to gtags.hpp & add protection for own::Mat * Add compile guard to proper place * Fix MACRO concat * Add unit tests * Remove class MACRO injection due to Python3 * Revert back unproper changes * Apply comments: reuse shape from traits * Throw away unused gtags * Apply comments * Handle own::* * Fix test * Fix test(1) * Fix unix build * Try on type list * Apply comments * Apply comments * Fix warning
Problem is cv::gin()/gout() accept types like cv::GMat and cv::gapi::own::Mat
But when passed, objects of this type become {{OpaqueRef}}s and our underlying image-based operations never expect that.
Need to restrict the generic type T when wrapping the "host" data to types NOT known to G-API, and fail if there is an own::Mat(???) or some of the G*-types passed.
Add static check for field GTypeTraits::shaped or placement type into GAPI_OWN_TYPES_LIST by itself. Either condition will fail compilation if enabled.
And produces compilation error like
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.