PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Wie in der Konsole Quelltext kompilieren und ausführen?



Hannibal19xx
13-01-2005, 12:12
Hallo

Habe eine
Datei main.cpp, welche unter Windows erstellt wurde...
Wie kompiliere ich diese unter Linux und führe die Datei aus?

locus vivendi
13-01-2005, 12:38
Bitte in die Dokumentation zum GCC gucken. Z.b "info gcc" eingeben oder online unter gcc.gnu.org schauen. Zum Compilieren von C++ Programmen den Compiler am besten als "g++" oder "c++" aufrufen.

Hannibal19xx
13-01-2005, 15:27
Das kompilieren hat nun mit einer Warnung geendet, was kann ich unter ihr verstehen?



linux:/home/dennis/Documents/Schule/PRG/Projekt # g++ main.c
main.c:180:1: warning: no newline at end of file
linux:/home/dennis/Documents/Schule/PRG/Projekt #

Boron
13-01-2005, 15:37
Das heißt ganz einfach, dass in deiner Quelldatei keine Leerzeile am Ende ist.

Bevor du jetzt fragst, warum der Compiler das will suche erst mal im Forum. Denn diese Frage wurde vor einiger Zeit diskutiert.

Hannibal19xx
13-01-2005, 15:44
Naja, dann füge ich diese einfach aus :-P
Wie kann ich die kompilierte Datei denn nun ausführen?
Find mich in den FAQ's irgendwie nicht zurecht :(

Edit:

Trotz Leerzeilen kommt diese Meldung...
Hier der Quelltext:


/*Projekt 2004/2005
DnS GmbH
Daniels / Schwarz
Kontaktmanager Deluxe 2005
Beta v0.1
Releasetermin: 1. Quartal 2005*/

#include <stdio.h>
//#include <conio.h>
//#include <process.h>
#include <string.h>



int eingabe,eingabe2,x=0;
FILE *Datei;
FILE *laden;
char weiter='j',Menue=0;


int Version ()

{
printf("Kontaktmanager Deluxe 2005\n");
printf("Version Beta 0.1\n");
printf("DnS GmbH\n");
printf("Bitte Taste druecken...");
//getch();
return 0;
}



int menu ()

{
printf("\ec");
printf("(1) Kontakte anzeigen\n");
printf("(2) Kontakte hinzufuegen\n");
printf("(3) Terminplaner starten *under construction*\n");
printf("(4) Kontakte loeschen\n");
scanf("%d",&eingabe);
return 0;
}

int Terminplaner ()

{
printf("\ec");
printf("(1) Kalendar anzeigen\n");
printf("(2) Termine hinzufuegen\n");
scanf("%d",&eingabe2);
return 0;
}

int main ()


{

struct KONTAKT
{
char nachname [20];
char Vorname [20];
char Strasse [20];
char Hausnummer [4];
char Ort [20];
char PLZ [5];
char ICQ [10];
char E_Mail [30];
char Telefon [20];
};

KONTAKT kontakt[30],test[30];

Version();
do
{
menu();

switch (eingabe)
{
case 1:
unsigned long bytes;

x=0;
Datei =fopen("Kontakte.txt","r");
if (!Datei)
break;

while (weiter=='j')
{

bytes = fread(&test[x], sizeof(KONTAKT), 1, Datei);
if (bytes > 0)
{
printf("Kontakt Nr. %d\n",x+1);
printf("Vorname: ");
printf("%s\n",test[x].Vorname);
printf("Nachname: ");
printf("%s\n",test[x].nachname);
printf("Strasse: ");
printf("%s\n",test[x].Strasse);
printf("Hausnummer: ");
printf("%s\n",test[x].Hausnummer);
printf("PLZ: ");
printf("%s\n",test[x].PLZ);
printf("Ort: ");
printf("%s\n",test[x].Ort);
printf("Telefon: ");
printf("%s\n",test[x].Telefon);
printf("E-Mail: ");
printf("%s\n",test[x].E_Mail);
printf("Weiter?(j/n)");
scanf("%s",&weiter);
x++;
}
else
{
printf("\n\nEnde der Datei :-(\n");
break;
}
}

fclose(Datei);

break;

case 2:





do
{

Datei = fopen("Kontakte.txt","a+");
printf("Kontakt Nr. %d\n",x+1);
printf("Nachname: ");
scanf("%s",&kontakt[x].nachname);
printf("\nVorname: ");
scanf("%s",&kontakt[x].Vorname);
printf("\nStrasse: ");
scanf("%s",&kontakt[x].Strasse);
printf("\nHausnummer: ");
scanf("%s",&kontakt[x].Hausnummer);
printf("\nPLZ: ");
scanf("%s",&kontakt[x].PLZ);
printf("\nOrt: ");
scanf("%s",&kontakt[x].Ort);
printf("\nTelefon: ");
scanf("%s",&kontakt[x].Telefon);
printf("\nE-Mail: ");
scanf("%s",&kontakt[x].E_Mail);
fwrite(&kontakt[x],sizeof(KONTAKT),1,Datei);
fclose(Datei);
printf("Weitere Kontakte hinzufuegen?(j/n)");
scanf("%s",&weiter);
x++;

}
while (weiter=='j');break;


case 3: Terminplaner();break;
case 4: remove("Kontakte.txt");break;

}

printf("0 = Hautpmenue\n");
printf("1 = Beenden\n");
fflush(stdin);
scanf("%uc",&Menue);
}
while (Menue==0);
return 0;

}

Boron
13-01-2005, 16:18
In deinem Fall mit dem Befehl ./a.out

kompilierst du mit g++ main.cpp -o progname dann führst du mit ./progname aus.

BeS
13-01-2005, 16:20
Also das Programm compiliert bei mir ohne Fehler.

PS: Wenn ich mir dein Quellcode so ansehe frage ich mich, ob du wirklich C++ programmieren willst/wolltest?

Hannibal19xx
13-01-2005, 16:28
Naja, ist eben ein Projekt aus der Schule...soll wohl c sein^^

THX, geht jetzt :)

BeS
13-01-2005, 16:38
Naja, ist eben ein Projekt aus der Schule...soll wohl c sein^^

THX, geht jetzt :)

wobei es auch kein sauberes C ist...
Kannst ja mal versuchen ihn mit dem gcc zu kompilieren, da brauchst du aber 2-3 kleine Änderungen am Quellcode damit es funktioniert.
Aber dann ist es wenigstens sauberes C, als C++ kann man das ja kaum verkaufen. ;)

Hannibal19xx
13-01-2005, 16:55
Wir proggen auch c, von daher passt das...hauptsache die note stimmt nachher :rolleyes:
Nur das Auslesen aus der Textdatei klappt nicht, ne Ahnung wieso?

BeS
13-01-2005, 16:59
Wir proggen auch c, von daher passt das...hauptsache die note stimmt nachher :rolleyes:


Ach das soll C sein. Dann kompiliere es mal mit einem c compiler (das wird wahrscheinlich auch dein Lehrer machen) Du hast da nämlich ein paar Fehler drin, wenn es wirklich C sein soll.

PS: und die Dateien sollten dann auch .c heißen.

sticky bit
13-01-2005, 19:58
Wenn das von nem Windows kommt evtl. mal ein dos2unix oder Äquivalentes drüber laufen lassen, damit die Windows Newline in Unix Newlines umgewandelt werden. C Kompiler sind da zwar im Grossen und Ganzen recht robust aber vielleicht bekommste dann die Warnung wegen der fehlenden Leer-Zeile am Ende weg...

Hannibal19xx
14-01-2005, 12:37
Gibt es nicht die Möglichkeit eine Windows-Umgebung zu simulieren, damit ich nicht alles ändern muss, und das dann wieder nicht unter win richtig läuft?

BeS
14-01-2005, 14:55
Wenn du Standard ANSI-C programmierst, dann laufen deine Programme überall und das ist auch das was du machen solltest.
Momentan hast du ein C Programm mit ein paar kleinen syntax Änderungen die es in der Form nur in C++ gibt, weswegen dein Programm mit einem C++ kompilier übersetzt wird mit einem C kompiler aber nicht.
Es sind nur 2-3 kleine änderungen die du in einer Minute gemacht hast (mußt dich eigentlich nur an die Fehlermeldungen halten).

1. vor KONTAKT muß immer ein struct stehen.
2. du mußt die Blöcke in case klammern ({})

nobody0
14-01-2005, 16:35
Wenn du Standard ANSI-C programmierst, dann laufen deine Programme überall und das ist auch das was du machen solltest.

Das stimmt nicht; ein Programm für Mikrocontroller A wird zu 99,9 % nicht auf B laufen, auch wenn er dafür fehlerfrei compiliert wurde. Es liegt beispielsweise an der Endianess.
Es ist auch normal, dass wenn man nur für Mikrocontroller A programmiert das Programm nicht mehr richtig funktioniert, wenn man statt Compiler X den Compiler Y verwendet. ANSI-C läßt ziemlich viele Freiheiten und bei Details, beispielsweise ob eine Funktion reentrant ist oder nicht, häufig mehrdeutig.
Man kann Code schreiben, der sowohl mit X als auch Y richtig funktioniert, aber das machen 99,9 % der Programmierer nicht; statt int16_t schreiben die int, was natürlich nicht portabel ist, denn int kann 8, 16, 24, 32 oder 64 Bit (oder noch andere Werte) haben.

Leider benutzen die meisten nicht einmal einen Prettyprinter wie z. B. indent, so dass schon die Formattierung des Quelltextes fehlerhaft bzw. chaotisch ist und das trägt nicht zur Fehlerreduktion bei.

wraith
14-01-2005, 17:48
Das stimmt nicht; ein Programm für Mikrocontroller A wird zu 99,9 % nicht auf B laufen, auch wenn er dafür fehlerfrei compiliert wurde. Es liegt beispielsweise an der Endianess.
Wenn ein Programm strictly conforming ist, dann wird es unter jeder standardkonformen Umgebung die gleiche 'Ausgabe' erzeugen (das gleiche tun).
Microcontroller sind ein schlechtes Beispiel, um mit denen ein produktives arbeiten ermöglichen zu können, müssen sich die (Compiler)-Entwickler auf den Pfad von undefined behavior bewegen (Zusatzlibs, Extension, ...).
Zumal sich auch die Programme für Microcontroller oft mit wilden Hacks am Rande des Wahnsinns bewegen.
Endianess ist noch ein schlechtes Beispiel, gute geschriebene Programme sind unabhängig von der Endianess.


Man kann Code schreiben, der sowohl mit X als auch Y richtig funktioniert, aber das machen 99,9 % der Programmierer nicht;
Ja, weil die Menge der strictly conforming C-Programme sehr klein ist, und man zu wenig damit anfangen kann.
Du gehörst ja auch zu den 99.9 %, also mecker nicht rum ;).


statt int16_t schreiben die int, was natürlich nicht portabel ist, denn int kann 8, 16, 24, 32 oder 64 Bit (oder noch andere Werte) haben.
int hat mind. 16 Bit, und in den meisten Fällen (Schleifen, Fehlerwertrückgabe,...) wird dieser Wertebereich nichtmal ausgeschöpft.
int16_t hingegen ist ein optionaler Typ (int_least16_t wäre ein unterstützter Typ), den zu benutzen ist also nicht portabel.
Außerdem verwenden viele keinen C99-Compiler, oder wollen/müssen für eine möglichst große Bandbreite von Compilerumgebungen schreiben, und müssen sich daher auf den kleinsten gemeinsamen Nenner zurückziehen.
Der Tenor in comp.lang.c und comp.std.c ist daher auch weiterhin bei int und Co. zu bleiben (erstmal).

Außerdem ist der Kommentar von BeS im Lichte einer Portierung Linux<->Windows des Programms vom OP zusehen, denn das war sein Problem.

nobody0
14-01-2005, 20:41
Wenn ein Programm strictly conforming ist, dann wird es unter jeder standardkonformen Umgebung die gleiche 'Ausgabe' erzeugen (das gleiche tun).

Ja, aber außer sowas einfaches wie

void main
{
int a=1, b=2;
a += b;
return;
}

kann man nicht machen, denn für ein Hello-World-Programm braucht man eine Ausgabe und die ist IMMER implementations-Abhängig.
Mit einem strict conforming Programm kann man praktisch nichts machen und ein Programm, mit dem man etwas machen kann, ist nie strict conforming.
Beispielsweise kann ein Compiler alle Variblen als volatile behandeln (kommerzielle Mikrocontroller-Compiler machen das), muß es aber nicht (z. B. gcc) und entsprechend hängt vieles vom Compiler ab.




int16_t hingegen ist ein optionaler Typ (int_least16_t wäre ein unterstützter Typ), den zu benutzen ist also nicht portabel.


Falsch, denn stdint.h muß selbst bei freestanding implementations vorhanden sein, so wie stdbool.h.
Im Standard steht stdint.h mit int16_t und vielen anderen drinn. Bei www.ansi.org gibt's den für unter 15 EUR und in Minuten, wenn man online mit Kreditkarte zahlt :)




Außerdem verwenden viele keinen C99-Compiler, oder wollen/müssen für eine möglichst große Bandbreite von Compilerumgebungen schreiben, und müssen sich daher auf den kleinsten gemeinsamen Nenner zurückziehen.


Das stimmt nicht, denn K&R-C verhält sich völlig anders als ANSI-C und selbst das ANSI-C hat sich mit jedem neuen Standard geändert.
Zudem werden nur die wenigsten die Unterschiede wissen. Beispielsweise ist bei K&R-C
b=-3;
äquivalent
b -= 3;
.
Außerdem ist das C99 inzwischen 6 Jahre alt und da jeder neue ANSI-Standard alle vorherigen nicht nur ersetzt sondern auch für ungültig erklärt, sollte man nur den verwenden.

wraith
14-01-2005, 21:26
Oh Mann, wenn du den Standard zu hause hast, warum liest du ihn nicht?

int hat Minimum 16 Bit, das steht im Standard (ja nicht so direkt, such' es), es ist mir völlig egal was irgend welche MC-Compiler machen.Dann sind die ebend nicht konform, Punkt.

int16_t ist ein optionaler Typ, das steht im Standard, lies ihn (das entsprechende Wort ist 'optional').

Auch wenn es dir nicht gefällt, das Standard "Hello World" ist strictly conforming.Damit nicht wieder Nachfragen und "Falsch"-Rufe kommen (auf die ich nicht eingehen will und werde), Douglas A. Gwyn sagt: The "Hello, world" program is meant to be s.c..Wenn du weißt wer Douglas A. Gwyn ist, bist du schon einen Schritt weiter.

Was aber z.b nicht mehr strictly conforming ist folgendes Programm (es ist aber standard conform)


#include <stdio.h>
#include <limits.h>

int main(void)
{
printf("%d\n",INT_MAX);
return 0;
}


Weiterhin sollte *jedem* klar sein, daß mit "Kleinstem gemeinsamen Nenner" _nicht_ K&R-C gemeint war.Was gemeint war kannst du dir selber mal überlegen.

Nochwas, wann glaubst du kommt der nächste C Standard?Es wird nicht 2009 werden, und warum?Weil die Verantwortlichen selber erkannt haben, das es kaum einen Compiler gibt der überhaupt C99 konform ist (erwähne nicht gcc du machst dich lächerlich), und kein Schwein C99 benutzt.Es ist die Realität.

Noch zwei Hinweise:
Compiler sind nicht der Standard, und besonders MC-Compiler erlauben sich weit mehr Freiheiten, wie der Standard zu läßt.Daher begründe deine Meinung, was der Standard meint nicht mit Aussagen wie: "aber mein Compiler macht das so, darum ..."

Und zweitens, der Standard wurde nicht für Leute wie dich umd mich geschrieben, darum ist vieles nicht immer sehr verständlich, daher ist ein regelmäßiges Studium der einschlägigen Newgroups sehr hilfreich.Da werden viele Kleinigkeiten lang und breit erklärt, damit auch du und ich das verstehen.

Ich werde hier auch nichts mehr zu schreiben, es würde nur dazu führen, daß ich mich immer wieder wiederholen müßte.

nobody0
15-01-2005, 01:28
Kauf' den Standard und sieh nach unter 4. nach wegen stdint.h, wenn Du mir nicht glaubst.

Dass da steht, dass int mind. 16 Bit hat, weiß ich selber; das steht in 5.2.4.2.1.