2012/6/12 Jared Maddox <absinthdraco@...>:
>> Date: Mon, 11 Jun 2012 19:33:18 +0200
>> From: Kai Tietz <ktietz70@...>
>> Subject: Re: [Mingw-users] MinGW GCC 4.7.0 released
>> To: MinGW Users List <mingw-users@...>
>> Content-Type: text/plain; charset=ISO-8859-1
>> 2012/6/11 Ross Ridge <rridge@...>:
>>> Kai Tietz writes:
>>> The reality is though worse than that, all you have actually done
>>> is create your own unique ABI that's only compatible with itself.
>>> The next patch you apply to "fix" some other apsect of Microsoft's C++
>>> ABI that you happen to find convienent will define yet another unique
>>> ABI and require C++ users to recompile everything again.
>> We don't have any different situation as we had before. Just the ABI
>> gets more near to that one it should be. Nothing more, nothing less.
> As both a C++ user, and someone slowly implementing a custom compiler,
> I firmly disagree with this sentiment. C ABIs should be as near to
> each other as is possible, the thiscall change is fine, as it's a
> performance issue, but attempting to directly implement
> cross-compatibility is something that I don't support. Historically
> there was little to no cross-compatibility between the C++ compiler
> families, because C is intended to be the C++ compatibility bridge.
If I got misunderstood here, I want to correct this. I didn't mean to
clone everything aspect of MS' C++ ABI into g++. There is no big earn
by that, but some aspects are worth to be treated in an compatible
way. Especially of interest is here the exception-model. But of
course the underlying mechanism itself won't be 100% equivalent to
msc's variant. Nevertheless it would be desirable to have a way to
catch in g++ code an exception thrown in msc's compiled code. Of
course the other way around would be desirable, too.
The vtable issue is of less interest IMHO, nevertheless the sorting
change would be interesting, as it would be possible then to do DCOM
with c++ classes instead of using C-wrapper layer. It is more a
question of comfort.
> you're really so worried about interoperability then just implement
> some glue logic to do conversions at run-time. It's already known that
> MS C++ objects are based on MS COM, and that MS COM objects are
> expressible in pure C (I've seen it demonstrated), so piping the data
> through a properly enriched GNU IDL compiler would provide everything
> needed (though GUIDs with a C-ish interface would certainly be nice as
> a general-purpose addition, I mention this because I've never seen a
> sign that GCC natively implements them).
We on mingw-w64's side have already a work-around for the GUID issue
of DCOM. It might be possible to improve GUID support handling by
gcc-compiler directly (I posted for that once a patch), but well,
again it isn't really urgent IMHO, as there exists already a
work-a-round for it.
> Seriously, what are you going to do next, Managed C++? C++/CLI?
> COMinterop (which belongs in Mono/Portable.Net, not in g++)? C++/CX?
For sure not. Nevertheless having the ability in binutils to link CLR
stuff would be for users an improvement, as they would have the chance
to link msc compiled object-code by ld. But well, again this is for
sure nothing really important IMHO, but again a question of comfort.
> Glue code (some compile-time, some run-time) is all that we
> realistically need or want in C++ interoperability (especially since
> the new standard has std::exception_ptr). I do not consider direct
> interoperability on this issue to be important, OR desirable. C++ ABIs
> should NOT be considered standard on most platforms (not even
> Microsoft ones), C ABIs should be.
Agreed. AFAIK even MS thinks about to change exception-mechanism for
C++. So it might be just a question of time this ABI part changes
So I wanted just to point out that this "all or nothing" approach
requested by Ross leads nowhere. First development needs time - as
there are not much people working for windows native targets on gcc -
and secondly not all ABI-compatibility is desired nor sensible.
>>> Do you really think this plan is a good one? ?Who do you think can
>>> actually benefit from this half-assed incremental approach?
>> IMHO the user can benefit by this. The thiscall-convention for C++
>> has also some impact on runtime-speed of C++, as default-argument
>> "this" gets passed in register and not on stack.
> Yes, that has a point & is fine.
>> Also it allows in some scenarios to import and
>> use msc compiled c++-code.
> This isn't. Once again, a properly-enriched GNU IDL compiler + some
> glue code is the superior option.
We on mingw-w64 are using Wine's IDL compiler to generate idl-based
headers. So you don't tell us something new here. Nevertheless the
users might be interested to use DCOM as C++ class definitions over
the C-API (which works in general great). Only thing required to
achieve this goal is to have the proper virtual-table sorting. This
doesn't make the C++ ABI model fully compatible, but at least it would
allow users to use C++ interfaces.
>> There is still a long road to achieve more compatiblity for c++ case,
>> but each step on that brings us near. Ross, this attitude was in the
>> past exactly the reason why things got stuck and nothing moved
>> anymore. No progress means death.
> To put it bluntly, I don't think most of us are interested in most of
> these changes in the first place. The C changes need to happen (C is
> the compatibility language), the thiscall change makes sense, MSVC++
> compatibility is raising everyone's hackles. Are you going to adopt
> the byzantine size quirks of Microsoft's member-function pointers? We
> don't want this.
Hmm, no. I don't want to implement the selector-pointers in
vbtable/vtable. I don't think anybody really needs that.