Created attachment 92810 [details] Patch for c_client.py to fix cpp keywords & lookup error As said in the summary, `explicit` is a C++11 keyword, which makes (at least) xkb.h fail when included in C++11 sources. Attached is a fix for this ("explicit" => "_explicit" dictionary entry in _cplusplus_annoyances). However, it's unfortunately not done with updating the dict, some lookups for `field.c_type_name` will now fail. Hence, the reverse cpp keyword lookup.
(In reply to comment #0) > Created attachment 92810 [details] > Patch for c_client.py to fix cpp keywords & lookup error > > As said in the summary, `explicit` is a C++11 keyword, which makes (at > least) xkb.h fail when included in C++11 sources. > Attached is a fix for this ("explicit" => "_explicit" dictionary entry in > _cplusplus_annoyances). > However, it's unfortunately not done with updating the dict, some lookups > for `field.c_type_name` will now fail. Hence, the reverse cpp keyword lookup. Hmm, so c++11 just suddenly stole the word 'explicit' and expected everything to work out? Unfortunately, you can't change it this way anymore, because that would break the API. What you should do is something like this: http://cgit.freedesktop.org/xorg/proto/kbproto/tree/XKBstr.h?id=5e40da736ffc87f5cafaaa67d745e20ef67a9f4a#n308 i.e. do the renaming conditionally in the header. I don't think there are any old c++ clients using this field, but if there are, hopefully you can avoid breaking them as well. I guess you can also sidestep the issue entirely by '#define explicit _explicit' or so before including xkb.h.
It's actually a keyword from the very beginning. My bad, I apologize. It is now just used for the conversion operator too [1]. I'll try to make a patch with the preprocessor fix you proposed. [1] http://en.cppreference.com/w/cpp/language/explicit
(In reply to comment #1) > (In reply to comment #0) > > Created attachment 92810 [details] > > Patch for c_client.py to fix cpp keywords & lookup error > > > > As said in the summary, `explicit` is a C++11 keyword, which makes (at > > least) xkb.h fail when included in C++11 sources. > > Attached is a fix for this ("explicit" => "_explicit" dictionary entry in > > _cplusplus_annoyances). > > However, it's unfortunately not done with updating the dict, some lookups > > for `field.c_type_name` will now fail. Hence, the reverse cpp keyword lookup. > > Hmm, so c++11 just suddenly stole the word 'explicit' and expected > everything to work out? Unfortunately, you can't change it this way anymore, > because that would break the API. What you should do is something like this: > http://cgit.freedesktop.org/xorg/proto/kbproto/tree/XKBstr. > h?id=5e40da736ffc87f5cafaaa67d745e20ef67a9f4a#n308 > i.e. do the renaming conditionally in the header. I don't think there are > any old c++ clients using this field, but if there are, hopefully you can > avoid breaking them as well. > > I guess you can also sidestep the issue entirely by '#define explicit > _explicit' or so before including xkb.h. Ran Benita, I just want to extend/amplify what Mr. Keil says. The explicit keyword for C++ constructors was in use in the '90's and standardized in C++98, the first C++ standard.
More of the same: "template" is a C++ keyword. /usr/include/xcb/xcb_renderutil.h:61:38: error: expected ',' or '...' before 'template' const xcb_render_pictforminfo_t *template, ^ Additionally, xcb_renderutil.h is missing the #ifdef __cplusplus extern "C" { #endif wrapper.
(In reply to comment #4) > More of the same: "template" is a C++ keyword. > > /usr/include/xcb/xcb_renderutil.h Not related - xcb_renderutil.h is a manually written header in the xcb/util-renderutil package, not part of libxcb, nor generated by libxcb's code generator. It's also already fixed: http://cgit.freedesktop.org/xcb/util-renderutil/commit/?id=8d15acc45a47dc4c922eee5b99885db42bc62c17
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/lib/libxcb/issues/23.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.