"Jesper Wolf Jespersen" <spam.jwj@ehuset.com.spam> wrote in message
news:ZXaz7.28$8Z.951@news.get2net.dk...
>
> Jeg er bange for at du benytter et forkert ord, selv om du sansynligvis
> mener noget rigtigt
> Et ABI er et binært interface til operativsystemet !!.
Nej, det du snakker om er et API - Application Programming Interface.
Hvis du er i tvivl om at jeg har ret så se f.eks.
http://developer.intel.com/design/Itanium/Downloads/245370.htm
eller kig i noget af dokumentationen til gcc
> Denne kompatibilitet har vi på Windows sammenhæng, WIN32 kode kan køres på
> alt fra Windows-95 til Windows-XP og Windows2000, selvfølgeligt er der
> forskelle på hvilket subset de forskellige afarter supporterer, men det er
> der også under de andre ABI'er.
>
Nej, det hedder Win32 API.
> Det der er problemet her er forskellige filformater i objekt og lib filer,
> forskellig name mangling i forbindelse med C++ og endeligt forskellig måde
> at gemme debug informationen i objektfilen.
> Disse problemer har såmænd også udbredelse udenfor Windows verdenen, COFF,
> ELF, a.out, OMF og så videre er alle begreber der blandt andet er kendt
fra
> linux.
>
Nej, som jeg sagde, er der langt flere problemer en filformatet og
name-mangling.
Når f.eks. "long double" har forskellige størrelser mellem compilere,
hvordan skal de så kunne blive kompatible ?
Der er ingen grund til at tro at dit binære layout for f.eks. "std::string",
"std::map" eller "std::ofstream" er identisk mellem Borland C++Builder (som
bruger RougeWave implementation) og Microsoft Visual C++ (som bruger
Dinkumware implementation).
Jeg sagde jo at jeg har været der!
>
> Det drejer sig om et tredieparts produkt der interfacer med borland C++
> builder. Produktet hedder DOA (Direct Oracle Access) og genererer Delphi
> klasser ud fra database pakker, ligesom der er et Delphi baseret interface
> til databasen.
Ok.
Den typiske måde som jeg gør det, er at skrive et mellem DLL med et
C-funktions interface med WINAPI kaldekonvention, med den compiler som
tredieparts produktet understøtter, og så bruge det (via et source-kode
interface, der svarer til det oprindelige tredieparts produkts interface) i
den anden compiler.
Det er ikke så svært.
> Delphi kode kan håndteres direkte af C++ builderen, men C++ builderen er
> vist så langt fra at være en standard C++ som man kan komme.
Det er objektivt forkert.
Det er rigtigt at VCL benytter sprogudvidelser, og at der bruges
sprogudvidelser til at interface Delphi og C++Builder.
> Mange af udvidelserne er smarte set ud fra produktivitetskriterier, men
der
> er meget nyt at lære hvis man vælger at gøre alt i C++ builderen, ligesom
> man så er låst til dette produkt for tid og evighed. Ikke kun vil den kode
> man skriver kun kunne køre her, men for eksempel exception håndtering er
en
> noget anden affære i borlands compiler end i andre C++ implementationer,
så
> programøren kommer til at tænke i borland termer og vil have svært ved at
> hoppe frem og tilbage mellem værktøjerne.
Der er fuld understøttelse for ISO C++ exceptions.
Desuden er der understøttelse for Windows structured exception og exception
som er compatible med Delphi.
Hvad mere kan man ønske ?
Det er programmørens ansvar at bruge de features som man ønsker.
Den væsentligste del af min kode er bestemt ikke låst til C++Builder, selv
om det er min primære compiler.
Mit primære programmeringssprog er ISO C++.
>
> Afdelingens andre produkter er skrevet i Visual C/C++ og holder sig meget
> tæt op af standarden for portabilitet, vi kan godt acceptere at enkelte
> moduler af projektet laves i andre værktøjer hvis der er en produktivitets
> gevindst ved at gøre det. Hvis skidtet skal porteres til en anden platform
> kan disse moduler omskrives på den anden platform.
Jeg har normalt ingen problemer med at skrive ISO C++ i C++Builder (lang
færre end når jeg bruger Visual C++).
Min kode kan typisk frit flyttes mellem til f.eks. Visual C++, Intel C++ og
gcc.
VCL baseret kode kan ikke flyttes til andre compilere.
Hvis din afdelings kode er skrevet meget tæt på C++ Standarden, burde det
ikke give nævneværdige problemer at compilere det med C++Builder.
>
> Modulerne her er basale database tilgangsrutiner som vi før har skrevet i
> Oracle Pro*C, men hvis vi kan mobilisere mulighederne i DOA uden at det
> bliver alt for bøvlet så ville det være dejligt.
>
Det er muligt.
>
> Jeg har aldrig helt fattet hvorfor Borland opfandt sine egne fil formater.
> Der er gået Hejlsberg i lortet
>
Det primære problem er ikke filformatet. Men det har jeg allerede sagt.
>
> > > Hvis jeg ikke kan interface mellem de to systemer på dette niveau kan
> det
> > > blive nødvendigt at lave en dll fil.
> >
> > Ja.
> >
> > > For at kunne bruge en dll skal man vel have en objektfil med
information
> om
> > > hvad der er i dll filen eller kan linkeren direkte bruge dll filen ?
> >
> > Du skal blot linke import libraryet fra DLL med.
> > Begge compilere har værktøjer til at generere et import library ud fra
et
> DLL.
> > Til Borland C++Builder er det "implib.exe" og til Visual C++ er det
> linkeren
>
> Tak skal du have for den information, så er det bare med at finde de
rigtige
> reserverede ord og pragmaer at putte i en header fil der definerer
> kaldeinterfacet så de to compilere er enige
Som jeg siger
>
> Jeg vil stadigt meget gerne høre fra folk der har praktiske erfaringer med
> at linke Borland objekter ind i Visual C applikationer.
>
Du er velkommen til at _tro_ at jeg ikke har _praktisk_ erfaring!
Venlig hilsen
Mogens Hansen