nicht angemeldet
Hi!
#include <iostream.h>
int main()
{
cout << "Hello World!" << endl;
return 0;
}
AFAIK ist endl (schon ewig nix mehr mit iostream gemacht) eine Konstante, die je nach OS anders definiert ist. (UNIX: \n, Windows: \r\n, MAC: entweder \r oder \n\r - erinnere mich nicht mehr so genau)
Naja, aber ohne endl bekomme ich eine Fehlermeldung, das verstehe ich halt nicht!
cout << "Hello World!" << ;
gibt einen Fehler vor ";" zurück,
cout << "Hello World!" << endl; funktioniert dagegen prima.
Was heißt das denn genau die "cygwin-API nutzen"? Für das bekloppte Script oben, wie kann es sein dass ich da ne eigene DLL brauche? Vermutlich sind die Standard-Windows DLLs doch mächtig genug um "Hello World" über die Standardausgabe auszugeben, oder?
Die cygwin-API brauchst Du dann, wenn Du über ANSI-C++ und Win32 hinaus gehst. (also POSIX) Dein Skript daoben braucht keine _zusätzlichen_ DLLs, aber _jedes_ Programm unter Windows braucht AFAIK mindestens user.exe (ist eine "Art" DLL) und kernel32.dll.
Dachte ich mir, aber wie schaffe ich es, dass ich das Programm kompiliere so dass es auf die Windows DLL zurückgreift?
Ich hab es mit
gcc -mno-cygwin -o test hallo.cpp
versucht, aber das will nmicht funktionieren, da bekomme ich 100 Fehler wie "undefined reference to cout", "undefined reference to ostream::operator<<<int>"...
Brauche ich dann vielleicht einen anderen Header und andere Befehler?
Aber was braucht man für "Hello World" großartiges? Ich will nur irgendwie "Hello World" in der Win-Shell ausgeben lassen, ohne eine extra DLL zu benötigen. Lizenzen sind wie gesagt egal, es geht erstmal um die Funktionalität!
iostream.h ist Teil von Ansi-C++. Daher brauchst Du keine weiteren Bibliotheken und kannst auf Cygwin verzichten.
Aber ich muß es ja mit cygwin kompilieren, bzw. mit gcc, aber das läuft wohl nicht direkt unter windows.
Naja - fürs Gedächtnis gibt's mehrere Möglichkeiten. Du kannst natürlich immer in eigenen Dateien Daten ablegen. Unter Windows gibts da 2 Varianten: .ini-Files und die Registry. Unter UNIX werden die Daten meinstens unter dem Homedir als .<programmname>rc oder als .<programmname>/<dateiname> abgelegt.
Das wäre ja weiter so eine Art Session, aber machen das alle Programme so? Ich meine, wenn ich ein programm öffne, udn ich verändere einstellungen bleibt das machmal nur zur Laufzeit. Also wie ich das sehe gibt s 3 Stufen
1. conf-Datein/Registry um grundlegende Dinge fest zu speichern
2. was weiß ich um Information für die Laufzeit eines Programmes zu speichern
3. Informatioenn in Variablen für die LAufzeit eines Scriptes zu speichern.
Das Problem bei 2. besteht darin, dass ein Programm ja oft aus mehreren Datein oder mehreren Fenstern besteht besteht, wo die Informationen alle irgendwie gespeichert werden müssen, udn nach Ende wieder weg sind.
Wie ist das denn unter Unix? Vermutlich gibt es da doch keine DLLs, oder?
Nicht ganz. Es gibt sog. "Shared Objects", die ähnlich funktionieren.
Worauf greift das Programm dann zurück? Kann ich das auf Linux standardmäßig mit einem C-Compiler kompilieren und dass dann auf jedem Unix als "Programm" starten, so wie Tools wie "gzip"...?
Nein. Die Programme brauchen alle mindestens die Libc-Bibliothek. (/lib/libc6*.so) Desweiteren brauchen Sie u.U. noch weitere Bibliotheken. Die libc setzt direkt auf den Linux-Kernel auf. Weitere Bibliotheken setzen meistens auf die libc auf, aber u.U. auch auf den Kernel. Man kann die (alle oder auch nur bestimmte) Bibliotheken theoretisch statisch einkompilieren, aber unter Linux kompilierte Programme sind höchstens in einem Emulator unter anderen UNIX-Derivaten lauffähig, Quellcode-Kompatibilität (d.h. dass man den Quelltext nur noch unter dem anderen System neu übersetzen muss) ist dagegen einfacher: Sie müssen "nur" POSIX-Konform sein.
Ach ja! Auf Linux wird ja alles immer extra kompiliert, daher das ganze Gehampel mit dem Source-Code! Aber unter Windows ist das ja anders, das wird einmal (vor?)-kompiliert, und läuft dann auf sämtlichen Versionen von 95-XP, oder? Die Unterschiede die bei Linux durch das jeweils verschiedene Compilierenausgeglichen werden, werden bei Windows wohl durch den jeweiligen Installer ausgeglichen, der je nachdem verschiedene VErsionen einiger kompilierter Dateien "installert" oder habe ich das falsch vestanden?
Viele Grüße
Andreas