I would prefer this too, but I don't believe that we can convince
libstdc++ maintainers to modify their code for this. Sadly the MS'
platform sdk defines a lot of stuff, which collides some times with
some projects. We made about this already a lot of bad experiences
... especially in context of MIDL ... defining
IN/OUT/INOUT/OPTIONAL/etc is really no clever move ...
Nevertheless it might be worth a try to ask libstdc++ people for those
__in.... A good argument (and bad one too) might be that the double
underscore symbols are reserved to compilers/system headers. And
well, C++ headers aren't really system headers, which is in general
just a POV ;)
Regards,
Kai
2017-05-11 16:32 GMT+02:00 David Grayson <davidegray...@gmail.com>:
> Oh, I thought we should just get libstdc++ to patch their project. I would
> look for __in and any other badly-named parameters, and perhaps add a third
> underscore to their names or something like that. In the long term, that
> would be nicer, because then users can have Microsoft-style code and
> libstdc++ code used in the same translation unit and they don't have to
> remember to use a guard on the include.
>
> --David
>
> On Thu, May 11, 2017 at 7:24 AM, Kai Tietz <ktiet...@googlemail.com> wrote:
>
>> Yes, that is a bit annoying ... sadly we can't do much about it.
>>
>> So I would suggest to add a guard to the include, so that it is
>> user-defined, if this header should be included, or not.
>> This might be a work-a-round for this, which should work for most.
>>
>> Regards,
>> Kai
>>
>> 2017-05-11 15:51 GMT+02:00 David Grayson <davidegray...@gmail.com>:
>> > Unfortunately, my patch seems to break several classes in libstdc++,
>> > preventing Qt from building. The problem is that driverspecs.h defines
>> > __in to be empty so we can compile Microsoft-type code that uses __in as
>> a
>> > source annotation on function parameters while GCC's libstdc++ uses __in
>> as
>> > the name of an input argument for many of its methods:
>> >
>> > $ egrep -lr '\b__in\b' /mingw32/include/
>> > /mingw32/include/c++/6.3.0/bits/basic_string.h
>> > /mingw32/include/c++/6.3.0/bits/basic_string.tcc
>> > /mingw32/include/c++/6.3.0/bits/istream.tcc
>> > /mingw32/include/c++/6.3.0/bits/locale_facets.h
>> > /mingw32/include/c++/6.3.0/ext/random.tcc
>> > /mingw32/include/c++/6.3.0/ext/vstring.tcc
>> > /mingw32/include/c++/6.3.0/istream
>> > /mingw32/include/c++/6.3.0/tr1/tuple
>> > /mingw32/include/c++/6.3.0/tr1/utility
>> > /mingw32/include/c++/6.3.0/tr2/bool_set
>> > /mingw32/include/c++/6.3.0/tr2/bool_set.tcc
>> > /mingw32/include/c++/6.3.0/tuple
>> > /mingw32/include/c++/6.3.0/utility
>> >
>> > One of the errors I get looks like this:
>> >
>> > /nix/.../include/c++/6.3.0/utility:208:57: error: no matching function
>> for
>> > call to 'move()'
>> > { return __pair_get<_Int>::__move_get(std::move(__in)); }
>> >
>> > I don't think this is necessarily a problem with mingw-w64, or a problem
>> > with that patch. Adrien Nader's attitude on this mailing list in
>> > 2015-11-03 was "Really, there's a platform and software is built on top
>> of
>> > it; it is that software that is supposed to adapt to the platform."
>> Microsoft
>> > Windows and mingw-w64 are platforms that define __in to have a special
>> > meaning. The software built on that platform (libstdc++) should adapt to
>> > the platform.
>> >
>> > One odd thing is that our __in gets defined in driverspecs.h, while
>> > Microsoft defines their __in in sal.h. But specstrings.h (for both
>> > mingw-w64 and Microsoft) includes both sal.h and driverspecs.h so that
>> > shouldn't affect when the bug appears.
>> >
>> > --David Grayson
>> >
>> > On Wed, May 10, 2017 at 9:44 AM, David Grayson <davidegray...@gmail.com>
>> > wrote:
>> >
>> >> Yeah, sorry, I only sent those patches to LH by mistake. Yes, I
>> purposely
>> >> used the same include guard name as Microsoft.
>> >>
>> >> --David
>> >>
>> >> On Wed, May 10, 2017 at 8:55 AM, Liu Hao <lh_mo...@126.com> wrote:
>> >>
>> >>>
>> >>>
>> >>>
>> >>> -------- Forwarded Message --------
>> >>> Subject: Re: [Mingw-w64-public] [PATCH] Include driverspecs.h in
>> >>> specstrings.h.
>> >>> Date: Wed, 10 May 2017 08:24:25 -0700
>> >>> From: David Grayson <davidegray...@gmail.com>
>> >>> To: Liu Hao <lh_mo...@126.com>
>> >>>
>> >>>
>> >>>
>> >>> OK, thanks. I've attached a new patch where the #include is after the
>> >>> __cplusplus stuff.
>> >>>
>> >>> I also included a second patch that will add an include guard for
>> >>> specstrings.h, since Microsoft seems to do that too.
>> >>>
>> >>> driverspecs.h is also missing an include guard but it is part of the
>> >>> React DDK so I didn't want to mess around with editing at the moment.
>> >>>
>> >>> --David
>> >>>
>> >>> On Tue, May 9, 2017 at 9:07 PM, Liu Hao <lh_mo...@126.com <mailto:
>> >>> lh_mo...@126.com>> wrote:
>> >>>
>> >>> On 2017/5/10 10:34, David Grayson wrote:
>> >>>
>> >>> This patch adds "#include <driverspecs.h>" near the end of
>> >>> specstrings.h,
>> >>> because the same is done in Microsoft's version of
>> >>> specstrings.h. With
>> >>> this patch, I am able to build Microsoft's devcon utility
>> without
>> >>> modification. Thanks!
>> >>>
>> >>> You must `#include` that header AFTER the `#ifdef __cplusplus ...
>> >>> #endif` block.
>> >>>
>> >>> Anyway, this header seems short of a header guard. I shall ask
>> >>> someone for sure.
>> >>>
>> >>> -- Best regards,
>> >>> LH_Mouse
>> >>>
>> >>>
>> >>>
>> >>> ------------------------------------------------------------
>> >>> ------------------
>> >>> Check out the vibrant tech community on one of the world's most
>> >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >>> _______________________________________________
>> >>> Mingw-w64-public mailing list
>> >>> Mingw-w64-public@lists.sourceforge.net
>> >>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>> >>>
>> >>>
>> >>
>> > ------------------------------------------------------------
>> ------------------
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > _______________________________________________
>> > Mingw-w64-public mailing list
>> > Mingw-w64-public@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
