Compilerunabhängig?

[Terrance & Philipp]

Hi!

Ich habe nun mit MSVC6 mein erstes kleines Programm zusammengewurschtelt. (Konsolenanwendung) Jetzt wollte ich den Code in den Borland Builder rüberschieben, weil man da so schön einfach GUIs zusammenbasteln kann . Doch da werd ich gleich mit "tausenden" von Fehlern überhäuft. Zum Beispiel ist offensichtlich die MS string Klasse nicht mit der Borland string Klasse (ansistring?) kompatibel.

Nun meine Fragen:
- Gibt es irgenendwelche Tricks/Regeln wie ich Compilerunabhängig programmieren kann?
- Sollte man das einfach nicht tun und ein Projekt in dem Compiler beenden in dem man es angefangen hat?

Grüsse
T&P

 

[Sinac]

Naja, bei nicht so komplexen Konsolenanwendungen sollte es nicht all zu schwierig sein den Code so zu gestalten, dass auch andere Compiler ihn übersetzen können. Du musst halt drauf achten, dass die Bibliotheken auch für die anderen Compiler vorhanden sind. Da hab ich z.B. mit den ganzen Stringklassen auch immer ne Menge Spaß

Mit GUIs wirds dann schon schwierg bis unmöglich den Code auf andere Plattformen oder Umgebungen zu übersetzen.

Also ich weiß jetzt nicht welchen Umfang dein Programm hat und welche Fehlermeldungen kommen, aber ich würde meistens neu anfangen...

Greetz...
Sinac

 

[Kachelator]

Zum Beispiel ist offensichtlich die MS string Klasse nicht mit der Borland string Klasse (ansistring?) kompatibel.

Wozu gibt es eigentlich in der C++-Standard-Library den std::string?

 

[chibisuke]

Also wenn du kompiler unabhängig sein willst, dann musst du dich auf die standart APIs beschränken.

Kein ANSI-String kein CString sondern nur char[] und std::string
und schon gar kein MFC oder Borland schnickschnak...

Sobald du die möglichkeit von borland zur graphischen gestaltung von fenstern und ähnliches nutzt, verlierst du die kompatiblität! ähnlich sieht es mit dem VC++ klassen assistent aus

Außerdem musst du bei den abweichungen im syntax ein wenig aufpassen...

Mache NIEMALS das hier wenn du compilerunabhöängig sein willst:

for(int i=0;...) {.....}

sondern mach es besser so:

int i;
for(i = 0;...) {...}

Das gibt sonst unter bestimten umständen fehler, welche mit der unterschiedlichen definition von for zusammen hängen.

 

[Terrance & Philipp]

Das das mit der GUI nichtmehr kompatibel ist war mir klar.

Programmiert ihr ein Projekt soweit es geht Compilerunabhängig oder entscheidet ihr euch am Anfang?

Kann man sagen das man einen grossen Teil MFC, VCL usw. lernt und eigentlich nicht C++ an sich?

 

[Dario Linsky]

Das Problem sind wohl einfach die unterschiedlichen Klassenbibliotheken von Borland (VCL) und Microsoft (MFC). Für Konsolenanwendungen ist wie schon gesagt normales Ansi C++ zu empfehlen, das lässt sich dann auch mit GCC kompilieren. Bei Windows-Anwendungen solltest Du einfach die kleinste gemeinsame Schnittmenge - also direkt das Win32 API - benutzen, damit dürfte es kaum mehr Schwierigkeiten geben (sowohl MFC als auch VCL bauen darauf auf).

for(int i = 0;...) {...}

Nur mal aus Interesse: Wann entstehen daraus denn Probleme?

 

[Kachelator]

Zitat:

Code:

for(int i = 0;...) {...}


Nur mal aus Interesse: Wann entstehen daraus denn Probleme?

VC++ 6.0 begreift (entgegen den C++-Standard) nicht, dass i eigentlich lokal ist für den Schleifenrumpf, sondern setzt es in den äusseren Gültigkeitsbereich. Wenn man dann da zwei von diesen Schleifen hat, gibt es einen Fehler, weil i angeblich doppelt definiert ist..

 

[chibisuke]

for(int i = 0; i < 10; i++) {
 Sleep(0);
}
for(int i = 0; i < 10; i++) {
 Sleep(0);
}

Borland macht das einwandfrei...

VC++ meldet das i bereits definiert ist. denn die definition einer for schleife unterscheidet sich bei den beiden compilern.

damit VC++ es akzeptiert muss es so aussehen:

for(int i = 0; i < 10; i++) {
 Sleep(0);
}
for(i = 0; i < 10; i++) {
 Sleep(0);
}

Wenn man das for in ein while auflöst dann ergibt sich:

für VC++:

    int i = 0;
    while(i < 10) {
        i++;
    }

Bei anderen compilern ist da noch ein klammenpaar rum.

so:

{
    int i = 0;
    while(i < 10) {
        i++;
    }
}

wodurch bei VC++ die variable im übergeordneten namensraum landet, und nicht im lokalen namensraum der for schleife.

anmerkung: diese auflösung ist nur ein hilfmittel zur erklärung und hatt nichts mit den vom compiler verwendeten verfahren zu tun.

Das führt beim kompilieren oftmals zu fehlern, und kann dadurch vermieden werden, das wie in ANSI-C die zählervariable zuerst deklariert wird, bevor sie in einer schleife zum einsatz kommt.

 

[Kachelator]

War meine Erklärung zu knapp?