A gentle critque..

[Ben Cooley]

In article <e4eenc$18j6$1 at digitaldaemon.com>, dennis luehring says...
>
>> D uses __VectorInt, which was the point of providing the cpptype {} keyword in
>> the first place.  The code within the braces is not parsed by D, but placed in
>> an external cpp file which is compiled by a Cpp compiler into a standard Cpp
>> class that D CAN use.
>
>due to the missing standart abi in c++ (there is no official and STABLE 
>convention) - what is a "standart" cpp class that D CAN use? and even if
>we can make one cpp class a "standart" how do we link to your current 
>object code... (does there the magic thing happen)
>
>if I don't get the point - can someone send me the c++ abi for some vc++ 
>versions (5-2005) and borland/bcb c++ (3-2006)...
>
>because im involved in an projects which uses vc5, vc2005 and bcb4
>it would be nice to link them together without preparing them (using 
>dlls, COM interface,...)

The format for OBJ files (OMF I believe) is on microsoft's msdn site. I don't
know how current it is. However, I'm talking only about gcc's object file
format.

>> Likewise, a complex functional macro can be placed in the Cpp file and wrapped
>> with a standard c function:
>
>how to detect functional macros?, what means complex to you?
>can you help me convert this macro into an function
>
>#define DEFINT(varname,value)\
>##varname int = value;\

cppdecl { DEFINT(MyVar, 100) } int MyVar;

Basically, as long as you know what the C linkage of a particular construct will
be, you can simply push it over into the generated cpp file for a standard Cpp
compiler (i.e. GCC) to figure out.  In this case you would have the following
code added to your generated file:

extern "C" {
DEFINT(MyVar,100)
}

..and an implicit..

extern (C) int MyVar; 

. as if you manually wrote that code yourself.  Taking snippets of Cpp code and
placing them over in the generated Cpp file, and adding the proper D C extern
linkages is not particularly difficult.

>> I don't know.. is this a joke?  Let me ask you, do you find yourself personally
>> offended by these ideas?
>
>not offended but amused about your ideas (your first posts sounded like 
>21years of c/c++, your last posts becoming more and more 2.1 years of 
>c/c++ or vb style...)

Hmmmm...

>> Compared to what?  A multi-year project to convert the C Windows API to D so
>> that Windows software can finally be written?
>
>compared to what - a multi-year c++-to-D interface wrapper/compiler 
>which wont ever become stable (because there is no stable abi)

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.

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.  

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.

>in the pure source code world c++ is nice and nearly vendor unspezific
>but c++ object code comes out of the hell...
>
>btw: the winapi project is just a (yes manualy made) conversion of the 
>headers - because D can directly link c object code
>
>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.

>> 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.

>> 21 years.  I've actually used to own a copy of Zortech.  
>ok then your familar with assembler (me too)
>
>can you please write a small class (template), compile your code with 
>vc,gcc,bcb,bc (at least 2-3 different compilers)
>and then try to use it in assembler (maybe all objectcodes together)
>
>or try to find some good how-to-link-manuals

Uh.. why would I want to do that?

>* Name mangling
>In C++, names are mangled to encode the type of the symbol and allow
>overloading.  So it may be called `MerryCallMe__voidfn__void' or
>something equally cryptic.  You may have to look at the assembly to find
>out what it is.
>(vendor specific)

I'm only interested in GCC.  Those other vendors can fend for themselves.

>* Calling conventions
>Member functions are often passed an invisible argument, which is (I
>think) their `this'.  I think it's the first argument under GCC, but may
>be wrong.  You'll have to pass it appropriately.
>(vendor specific)
>
>> How about you?
>just 17 years

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.