Hallo Welt

Nach langer Arbeit an einem grösseren Projekt, das ich mit VC++ EE geschrieben habe, möchte ich das ganze auch auf Unix-Systemen laufen lassen. Dazu habe ich mir mit Oracles VirtualBox eine Ubuntu 32bit Version installiert und wollte den Code aus VC++ direkt importieren. 3 Stunden später hat auch der gcc-Compiler den Code kompiliert (Mit Code::Blocks und MinGW). So weit so gut. Nur funktioniert das Programm nicht!

Eines vorweg: Ich habe keinen Windows-spezifischen Code mehr drin (auf jeden Fall meckert der Compiler nicht). Gut, sagte ich, probieren wir das ganze mit MinGW auf Windows (Mit Dev-Cpp).
Und siehe da:
Unterschied der Dateigrösse:
- Ubuntu: 116kb
- Windows: 404kb
Ich habe zuvor sämtliche Optimierungen seitens gcc untersagt.

Was mache ich falsch (mal von einem hässlichen Programmierstil abgesehen)?

Gruss
cwriter

Hi

"Funktioniert nicht" ist keine Fehlerbeschreibung.
Was passiert?
Was findet man mit dem Debugger heraus?

Debugger: Keine Fehler
Fehler: Keine Ausgabe. Es wird nur 0x0 zurückgegeben, was der return am Ende ist. Dazwischen sollten Dateien geöffnet und geschlossen werden, doch die Eingabe (über scanf() sowie über argv[]) wird nicht gefressen und mit dem Debugger von Code::Blocks komme ich nicht richtig klar. Dennoch: Das Programm funktioniert mit den std-libraries ja auf Windows, deshalb zweifle ich an einem Fehler des Codes. Ich lade mal die Files hoch. Die sollten im selben Verzeichnis des Programms liegen.

Gruss
cwriter

Ok, wenn ich das ganze mit dem Terminal versuche, gibt's den Error, dass #incldue <string> nicht gefunden wurde. Ich dachte, der gcc steht für g++ -> c++ ?

Gruss
cwriter

Also, incldue wird sicher nicht gefunden

Und gcc steht nicht für g++. Wer sagt sowas?

Hi,
Ich habe kurz einen flüchtigen Blick in deinen Code geworfen. Aber in der main hast du keine <string> includiert. Diese ist etwas anderes als die <string.h>

Vermutlich compilierte dein Code auch nur, weil die durch die Functions.cpp inkludiert wurde, die du gerade auskommentiert hast.

Grüße

Wer sagt sowas?

Ein Windows-verwöhnter Programmierer, der neu in Linux einsteigt. Ich.
@Jennesta
Wird ja immer besser. Die Functions.cpp habe ich aber nur unter Windows direkt eingebunden, da darf man sowas
Gut, #include <string> hinzugefügt. Keine Merkbaren Veränderungen, Dateigrösse bleibt gleich.
Was nun?

/EDIT: Langsam glaube ich, dass Linux mich fertig machen will:

Code :

1	g++ Erkennung.cpp Functions.h -w

liefert keinen Fehler und die generierte a.out ist 119kb gross gegenüber den 85kb release bzw. 116kb Debug von Code::Blocks. Dennoch will das Programm nicht funktionieren.


Gruss
cwriter

Hi.

Abgesehen davon, dass es natürlich sinnfrei ist in einer Headerdatei die Implementierung gleich als erstes einzubinden und eine Headerdatei zu kompilieren (welche sowieso schon in Erkennung.cpp eingebunden wird)....

Vielleicht solltest du auch die unzähligen Warnungen nicht einfach ignorieren und den Code berichtigen?

Ansonsten, kompiliere den Code mit Debugginginformationen und führe dein Programm unter gdb aus:

Code :

1 2 3 4 5 6 7 8 9 10

> g++ -g Erkennung.cpp > gdb a.out ... gdb> break 1009 # Abbruchpunkt setzen gdb> run ... gdb> p Eingabe # Wert einer Variablen drucken ... gdb> next # Schrittweise weiter, Funktionsaufrufe überspringen. gdb> continue # Programm weiter ausführen bis zum Ende oder Abbruchpunkt oder Signal

Gruß

PS: Die mit MinGW kompilierte .exe Datei mit Debugginginformationen ist bei mir 190kB groß, ohne Dbg-Symbole 115kB.

Wie rufst du denn das Programm auf?

Die meisten Warnungen beziehen sich auf "NULL used in Arithmetic", und ich will nicht meine Zeit damit verbringen, durch diese (etwa 100) Warnungen zu scrollen oder die Konsole vollzuspammen.
Das mit gdb werde ich versuchen, sobald ich wieder ein System zur Verfügung habe.

cwriter

Zitat von cwriter

Die meisten Warnungen beziehen sich auf "NULL used in Arithmetic", und ich will nicht meine Zeit damit verbringen, durch diese (etwa 100) Warnungen zu scrollen oder die Konsole vollzuspammen.

Genau deswegen solltest du den Code einfach berichtigen. Dann gibt's auch keine Warnungen.

Und wie? Ich sehe darin keinen Fehler.

cwriter

Zitat von cwriter

Und wie? Ich sehe darin keinen Fehler.

strcmp gibt einen int zurück.

NULL wiederum ist ein void*, also ein Zeiger.

Passt ja irgendwie nicht zusammen. Komisch, oder?

Und es steht irgendwo, dass 0 NULL ist.

cwriter

Zitat von cwriter

Und es steht irgendwo, dass 0 NULL ist.

In dieser Aussage steckt soviel Unwissen drin. Ich weiß gar nicht wo ich anfangen soll...

C / C++ sind typisierte Sprachen - aus gutem Grund.

NULL ist ((void*)0).

Das ist etwas ganz anderes als int 0.

Mal abgesehen davon, das du überhaupt nicht weißt wie ein Nullzeiger im Speicher repräsentiert wird.

Lassen wir das.

---

Ich werde es wohl nicht mehr nachvollziehen können wie man so dreist sein kann, einfach alle Warnungen zu ignorieren, zu behaupten das Programm wäre fehlerfrei und trotzdem funktioniert irgendwas nicht...

Bei dieser Menge an Warnungen - oder wenn man einfach alle Warnungen ausstellt - sieht man natürlich auch nicht die eine schwerwiegende Warnung, die darin versteckt ist...

Gruß

Gut. Ich habe unter Windows mit Visual C++ Projekte mit strcmp("","") == NULL kompiliert. Unter Windows mit MinGW. Mit allem möglichen. Die Warnungen sind nie ernst zu nehmend gewesen. Alles funktioniert. Nur unter Linux geht das nicht. Das lässt durchaus den Schluss zu, dass der Code an sich nicht unbedingt fehlerfrei, wohl aber funktionsfähig ist. Meine Frage ist: Weshalb geht das unter Linux nicht?
Ich werde mal die NULLs durch 0s ersetzen, sobald ich wieder beim Computer bin.

cwriter