> The format for OBJ files (OMF I believe) is on microsoft's msdn site. I don't
> know how current it is. 

the obj file format is just one part of the way - i don't found any vc related abi descriptions? have microsoft ever released an offical c++ abi description?

> However, I'm talking only about gcc's object file
> format.

g++ has the most unstable c++ abi in the hole c++ compiler world
the gcc c++ abi changes from version to version - i think ~100 times :-) since 2.9xxx
the abi for the 4.x seem to become a "little bit" more stable

> GDC and GCC are tightly linked.  When the abi of one changes, so does the other,
> likewise with GCC-XML.  Any CPP which can be parsed by GCC can be output to
> GCC-XML.

so you saiy walter should "follow" this permanent abi changes? for at least 3 compiler-vendors (micorsoft, borland(which i need), gcc) with the chances of never getting to the point of having an full-out-of-the-box-working version?
what do you think will other no so gentle developers like us will say if D do it this way?

you can use c-style D in C (bidirectional)

why do think is there no c++ compiler out there whos speaking other c++ abi's then its own?

> As far as the Windows C++ abi, it hasn't changed in years as far as I know.  My
> MSVC 6 code still works with MSVC 8.  There have been changes to the heap
> allocator, but not the way vtables are implemented or registers are used.  

the vc6 object code isn't realy compatible with vc8 version (on what level?)
the microsofts c++ abi changed another time... (where are the documents? can anyone help with an link?)

> But since the D windows compiler isn't open source anyway.. it doesn't matter?
> You'd either use an OMF compatible version of GCC/GCD, or recompile your windows
> code with MinGW, or not use D at all.

i will never start to use another compiler in parts(or hole) of some of my years living projects - they are stable under development and i don't have the time and "power" to try out how far such a D feature is capable of link with my code wihtout any error (im afraid of hidden errors - found then months later...)

will you port parts of your project over if needed to mingw or something else only to get in contact with D?

in my company the vc and bc compiler is in use for years - because they are stable and under heavy use by mio. other developers - im not allowed to change the compilerbase!

>> but yours is header conversion AND the linkage problem - the winapi port will be finished long, long time before
> Wanna bet?  In any case, I only have to finish my system once and I'm finished.
> You're never going to be finished porting the Windows API headers.

why don't have you posted such message into the mingw forum years ago :-)

>>> I would suggest if you don't like it, then don't feel that you have to use it.
>> the problem is i would give it a try, but i don't think it would ever happen to exist...
> Of course not.  It is, after all, impossible as many people have explained to me
> in vauge detail.  Why would somebody ever even consider such a crazy idea, and
> who would want it anyway.

i want it

> Uh.. why would I want to do that?

just to get near to the problems with the linking

> Sure, Cpp calls also often pass silent return argument parameters in some cases.
> There are a number of details to consider.. but it's certainly not impossible,
> or improbably difficult as some of the people here would have you believe.

your right - its not impossible - but why should walter try to implement such an linkable feature into D with no stable abis around while he's building an next genration language?

i need a description of
current c++ abi of vc(6,7,8), bc(5.x,...) and gcc(3.2 to 4.x)


cioa dennis

On Wed, 17 May 2006, dennis luehring wrote:

> > The format for OBJ files (OMF I believe) is on microsoft's msdn site. I
> > don't
> > know how current it is.
> 
> the obj file format is just one part of the way - i don't found any vc related abi descriptions? have microsoft ever released an offical c++ abi description?
> 
> > However, I'm talking only about gcc's object file
> > format.
> 
> g++ has the most unstable c++ abi in the hole c++ compiler world
> the gcc c++ abi changes from version to version - i think ~100 times :-) since
> 2.9xxx
> the abi for the 4.x seem to become a "little bit" more stable

Since gcc 3.0 that's not been true.  The abi adopted with gcc 3.0 and beyond is based on a spec that's been agreed upon by all the major unix compiler vendors.  There's been a few fixes primarily in 3.2 and 3.3 (if I remember right) to fix some corner cases.  Since 3.4 there haven't been any major abi changes that I can recall.  The same can be said of the hp, sun, ibm, etc compilers.. their first releases of the new abi weren't perfect either.  For the last several years, each has been stable and compatible.

The only major vendor today that _doesn't_ support this abi is microsoft (and borland if you want to count them).

Later,
Brad

Brad Roberts schrieb:
> On Wed, 17 May 2006, dennis luehring wrote:
>>> However, I'm talking only about gcc's object file
>>> format.
>> g++ has the most unstable c++ abi in the hole c++ compiler world
>> the gcc c++ abi changes from version to version - i think ~100 times :-) since
>> 2.9xxx
>> the abi for the 4.x seem to become a "little bit" more stable
> Since gcc 3.0 that's not been true.  The abi adopted with gcc 3.0 and beyond is based on a spec that's been agreed upon by all the major unix compiler vendors.  There's been a few fixes primarily in 3.2 and 3.3 (if I remember right) to fix some corner cases.  Since 3.4 there haven't been any major abi changes that I can recall.  The same can be said of the hp, sun, ibm, etc compilers.. their first releases of the new abi weren't perfect either.  For the last several years, each has been stable and compatible.

ok, ok ("~100 times" was a joke) but there are enough small changes in the last years to call the (*nix) c++ abi still unstable - do you think the abi is nowerdays stable enough to become integrated into the D linker?

> The only major vendor today that _doesn't_ support this abi is microsoft (and borland if you want to count them).

a D features to link c++ code without these two major vendors makes absolutly no sens (to me) - where can i find docs about there abis

ciao dennis

In article <e4gvun$hg2$1@digitaldaemon.com>, dennis luehring says...
>
>Brad Roberts schrieb:
>> On Wed, 17 May 2006, dennis luehring wrote:
>>>> However, I'm talking only about gcc's object file
>>>> format.
>>> g++ has the most unstable c++ abi in the hole c++ compiler world
>>> the gcc c++ abi changes from version to version - i think ~100 times :-) since
>>> 2.9xxx
>>> the abi for the 4.x seem to become a "little bit" more stable
>> Since gcc 3.0 that's not been true.  The abi adopted with gcc 3.0 and beyond is based on a spec that's been agreed upon by all the major unix compiler vendors.  There's been a few fixes primarily in 3.2 and 3.3 (if I remember right) to fix some corner cases.  Since 3.4 there haven't been any major abi changes that I can recall.  The same can be said of the hp, sun, ibm, etc compilers.. their first releases of the new abi weren't perfect either.  For the last several years, each has been stable and compatible.
>
>ok, ok ("~100 times" was a joke) but there are enough small changes in the last years to call the (*nix) c++ abi still unstable - do you think the abi is nowerdays stable enough to become integrated into the D linker?
>
>> The only major vendor today that _doesn't_ support this abi is microsoft (and borland if you want to count them).
>
>a D features to link c++ code without these two major vendors makes absolutly no sens (to me) - where can i find docs about there abis

Interesting that you would say that.  Not being able to use any existing C or Cpp at all makes even less sense to me.

The point is that I can write software in D on any platform supported by GDC and use any C or Cpp library that can be compiled by GCC on Windows, Linux, or OSX. How many usage scenarios do you think that would cover?

As far as the original D compiler Walter wrote.. it won't be compatible with projects written for GDC code which used Cpp interop.

"Ben Cooley" <Ben_member@pathlink.com> wrote in message news:e4it0v$3p9$1@digitaldaemon.com...

> Not being able to use any existing C or
> Cpp at all makes even less sense to me.

YOU!

CAN!

LINK!

TO!

C!

CODE!

NATIVELY!

IN!

D!

Did you miss that somewhere?

Jarrett Billingsley wrote:
> "Ben Cooley" <Ben_member@pathlink.com> wrote in message news:e4it0v$3p9$1@digitaldaemon.com...
> 
>> Not being able to use any existing C or
>> Cpp at all makes even less sense to me.
> 
> YOU!
> 
> CAN!
> 
> LINK!
> 
> TO!
> 
> C!
> 
> CODE!
> 
> NATIVELY!
> 
> IN!
> 
> D!
> 
> Did you miss that somewhere? 
> 
> 

Seriously, this has been pounded back at you (Ben) for many posts. Listen to what we are saying.

-- 
Kyle Furlong // Physics Undergrad, UCSB

"D is going wherever the D community wants it to go." - Walter Bright

In article <e4ji0l$hcl$1@digitaldaemon.com>, Kyle Furlong says...
>
>Jarrett Billingsley wrote:
>> "Ben Cooley" <Ben_member@pathlink.com> wrote in message news:e4it0v$3p9$1@digitaldaemon.com...
>> 
>>> Not being able to use any existing C or
>>> Cpp at all makes even less sense to me.
>> 
>> YOU!
>> 
>> CAN!
>> 
>> LINK!
>>...
>> 
>> Did you miss that somewhere?
>> 
>> 
>
>Seriously, this has been pounded back at you (Ben) for many posts. Listen to what we are saying.

I think Ben gets that point just fine.  Yes, you can link with C.  *But* you need to rewrite the header in D first.  Which isn't quite the same as being able to "use existing C".  Granted the manual labor to use C from D is less than for using it from Java or Python, but still, there's some manual labor involved. Anyway, if you've been reading his posts closely I think it's pretty clear that he's primarily concerned with C++, anyway, and not so much C.  But if his grand plan for C++ via GCC-XML works out, then C will be taken care of too as a by-product.

Anyway, there's no reason to jump all over the guy for wanting to make D interoperate better with C and C++.

My impression, though, is that what Ben wants to do is still pretty similar to what SWIG already does.  It's generating wrappers.  In SWIG's case it generates say a Python API plus some supporting Python and C++ glue code.  In Ben's case he's talking about generating a D API with D and C++ glue code (and maybe a little assembly thrown in to manipulate vtables and such), but they're wrappers nonetheless.  So to me it makes most sense to either A) leverage SWIG and add the necessary functionality it or B) start over from scratch with a completely new wrapper generator tool based on GCC-XML.  But if you're going spend all that time making a new wrapper generator that's better than SWIG, why limit it to only wrapping D?  If you

By the way a search for "GCCXML wrapper generator" turns up this as the first
link:
http://www.digitalmars.com/d/archives/digitalmars/D/announce/113.html
The site for that is here: http://remy.moueza.free.fr/
Sounds like it was abandoned, but at he's got some experience on the problem,
and is likely to know where the really tricky parts are.

Cheers!

Bill Baxter