Was heißt das c bei cout?

SideWinder

Muss zwar zugeben, dass wir hier noch nicht die 1.5er haben, aber die 1.4.2 ist ja sowieso noch weit vorne was Useranzahl betrifft.

Was genau Männerjava ist hab ich noch nicht rausgefunden bin erst bei StringTokenizer, Strings, System und I/O und neben der zwar tollen aber ebenfalls langsamen Entwicklungsumgebung Eclipse kommen mir die Programme auch nicht viel schneller vor - und die sehen nicht unoptimiert aus.

Kann aber auch mit unseren Schulrechnern zu tun haben, auf jeden Fall ist jedes c++-programm schneller fertig. Aber darum gehts ja auch bei Java gar nicht, scheint mehr eine Sprache für tolle GUI-Programme sein bei denen es auf eine Sekunde auf oder ab auch nicht ankommt.

MfG SideWinder

groovemaster

Optimizer schrieb:

Ich hab's doch vorhin gesagt, für so etwas gibt es Debugger.

Du kannst aber Ausgaben (zB in eine Log-Datei) nicht mit manuellem Debuggen vergleichen. Stell dir vor, du hast in deinem Programm einen Buffer-Overflow. Während der Realisierung und dem anschliessenden Test tritt dadurch nie ein Fehler auf, weil das Überschreiben des fremden Speichers keine Auswirkungen zeigt. Du hast also nie einen Grund, den Debugger anzuwerfen. Ausgerechnet bei der Kundenpräsentation, kommts dadurch zum Crash. Das wirft nicht unbedingt ein gutes Licht auf dich, oder?
Wenn du aber zur Laufzeit solche Fehler erkennst (das kann man ja wunderbar in einer std::vector ähnlichen Klasse kapseln), kannst du sofort aus der Log-Datei ablesen was wo falsch gelaufen ist und korrigieren.
Also für gewisse Dinge, zugegeben sehr wenige, hat der Präprozessor noch lange nicht ausgedient. (ich stell mir da gerade vor, eine komplexe Anwendung ohne #include zu schreiben )

@Sidewinder: Java ist faktisch nicht grundsätzlich langsam, da liegst du falsch. Es gibt natürlich einen einmaligen Overhead beim starten der Programme, weil sie erst compiliert werden müssen. Deshalb ist ein C++ Programm natürlich schneller "fertig".
Das Eclipse langsam ist (was ich eigentlich nicht nachvollziehen kann), liegt auch nicht an Java, sondern am GUI-API. Natürlich ist SWT nicht so performant wie direkt auf der der WinAPI zu coden, dafür ist es relativ Plattformunabhängig.
Aber wir können natürlich mal die GUI-APIs von C++ und Java vergleichen:

Java:
Swing: absolut plattformunabhängig, wird gezeichnet, deshalb bisschen lahm
AWT: nicht wirklich schön, aber recht performant
SWT (Eclipse): recht performant, relativ plattformunabhängig

C++:
hat kein GUI-API

Erkennst du den Unterschied? Ich kann über das Java Native Interface auch die WinAPI nutzen, aber selbstverständlich bin ich nicht so blöd und mach das wirklich.
Aber wenn ihr alle so "überzeugt" seid, bitte. Mir ist das eigentlich nicht so wichtig, hier den Apostel zu spielen.

groovemaster schrieb:

Stell dir vor, du hast in deinem Programm einen Buffer-Overflow. Während der Realisierung und dem anschliessenden Test tritt dadurch nie ein Fehler auf, weil das Überschreiben des fremden Speichers keine Auswirkungen zeigt. Du hast also nie einen Grund, den Debugger anzuwerfen. Ausgerechnet bei der Kundenpräsentation, kommts dadurch zum Crash. Das wirft nicht unbedingt ein gutes Licht auf dich, oder?
Wenn du aber zur Laufzeit solche Fehler erkennst (das kann man ja wunderbar in einer std::vector ähnlichen Klasse kapseln), kannst du sofort aus der Log-Datei ablesen was wo falsch gelaufen ist und korrigieren.

Ok, ich stell mir das also mal vor. In diesem Fall würde ich mich erschießen, wenn im std::vector::operator[] in ein logfile schreibe, anstatt ein assert oder eine Exception zu werfen und mir gute Debug-Möglichkeiten dadurch entgehen lasse.
Mir vollkommen rätselhaft, was jetzt deine Geschichte mit dem Präprozessor zu tun hat, nichts hindert mich daran, Bufferoverflows zu debuggen, da komm ich dem Fehler auch sicher schneller auf die Spur.

Jester

Wie kommst Du mit Deinem Debugger nicht reproduzierbaren Bugs auf die Spur?
Da sind Logs einfach Klasse. Du kannst nachvollziehen, was zu einem Zeitpunkt im System geschah und versuchen rauszufinden was schief gegangen ist. Mit dem Debugger kannst Du immer nur den aktuellen Zustand betrachten. Und wenn der Fehler nur unregelmäßig auftritt, dann mußte ne ganze Weile warten.

MfG Jester

SideWinder

C++ hat keine GUI-API im Sprachstandard, was aber nicht heißt, dass keine vorhanden sind.

MfG SideWinder

SideWinder schrieb:

C++ hat keine GUI-API im Sprachstandard, was aber nicht heißt, dass keine vorhanden sind.

MfG SideWinder

Versteh doch den Unterschied. Du vergleichst hier
1. die plattformübergreifende Standardblibliothek einer Sprache
mit
2. der Nutzung eines plattformabhängigen Betriebssystem-APIs.

Mir steht in Java selbstverständlich auch die hochperformante, wunderschöne WinAPI zur Verfügung.

Jester schrieb:

Wie kommst Du mit Deinem Debugger nicht reproduzierbaren Bugs auf die Spur?
Da sind Logs einfach Klasse. Du kannst nachvollziehen, was zu einem Zeitpunkt im System geschah und versuchen rauszufinden was schief gegangen ist. Mit dem Debugger kannst Du immer nur den aktuellen Zustand betrachten. Und wenn der Fehler nur unregelmäßig auftritt, dann mußte ne ganze Weile warten.

MfG Jester

groovemasters Geschichte hörte sich so an:

Während der Realisierung und dem anschliessenden Test tritt dadurch nie ein Fehler auf, weil das Überschreiben des fremden Speichers keine Auswirkungen zeigt.

Funktioniert also nicht. Ich erkenn ja den Fehler nicht. Also kann ich nicht debuggen.

Wenn du aber zur Laufzeit solche Fehler erkennst (das kann man ja wunderbar in einer std::vector ähnlichen Klasse kapseln), kannst du sofort aus der Log-Datei ablesen was wo falsch gelaufen ist und korrigieren.

Jetzt bau ich auf einmal eine Prüfung in den vector ein und kann in die logfile schreiben - WOW. Dass ich damit aber auch debuggen könnte scheint völlig ausgeschlossen zu sein.
Besonders der Punkt "wo was falsch gelaufen ist" ist ja wohl auch nicht ganz passend. Oder krieg ich irgendwie mit Standard C++ den kompletten Stack Trace in das logfile mit allen lokalen Variablen?

Bufferoverflows sind IMHO keine Fehler die geloggt gehören, sondern die behoben gehören. Loggen würde ich z.B. "Konnte nicht in Datei schreiben", "Der Grafikmodus wird nicht unterstützt", Sachen halt, die ich nicht verhindern kann.

SideWinder

Es gibt in C++ auch plattformunabhängige APIs und nicht bloß betriebssystemspzefische.

MfG SideWinder

Die kannst du in Java genauso nutzen. Die gibt es nämlich nicht in C++ sondern für C++ und mit dem Java Native Interface ist das gar kein Problem.
Du kommst so kein Stück weiter.

Um es mal zu übertreiben: Irgendwie sagst du "Die Bibliothek xyz ist schneller als Java", obwohl du damit zwei völlig verschiedene Sachen vergleichst.

Außerdem hat das auch schon gar nichts mehr damit zu tun, dass Java angeblich langsam ist. Aber du wirst dich eh schwer tun, dass zu beweisen.

Shade Of Mine

Optimizer schrieb:

Aber wir können natürlich mal die GUI-APIs von C++ und Java vergleichen:

Java:
Swing: absolut plattformunabhängig, wird gezeichnet, deshalb bisschen lahm
AWT: nicht wirklich schön, aber recht performant
SWT (Eclipse): recht performant, relativ plattformunabhängig

C++:
hat kein GUI-API

AWT und Swing: ja
SWT: nein

Odert ist SWT in Java integriert? Zumindest auf java.sun.com finde ich keine Doku...

Und du scheinst nicht zu verstehen: C++ ist eine Sprache, mehr nicht. Java ist eine Vollständige Plattform.

In Java hat man zB Standardisierte Datenbankanbindungen - in C++ geht man einen anderen Weg und sagt: wir wissen nicht genug über Datenbanken, bzw. fürchten, dass sich alles sehr schnell ändern kann. Wir wollen nicht dauernd einen neuen C++ Standard rausgeben nur weil ODBC oder ähnliches veraltet ist. Folglich verwenden wir einfach 3rd Party Libraries und gut ist.

Funktioniert übrigens super

Erkennst du den Unterschied? Ich kann über das Java Native Interface auch die WinAPI nutzen, aber selbstverständlich bin ich nicht so blöd und mach das wirklich.

Kann ich in C++ genauso - aber ich kann auch Plattformunabhängige Libraries verwenden.

Aber wenn ihr alle so "überzeugt" seid, bitte. Mir ist das eigentlich nicht so wichtig, hier den Apostel zu spielen.

Du solltest dir mal langsam merken, dass Java eine Plattform ist.

Mir vollkommen rätselhaft, was jetzt deine Geschichte mit dem Präprozessor zu tun hat, nichts hindert mich daran, Bufferoverflows zu debuggen, da komm ich dem Fehler auch sicher schneller auf die Spur.

Weil du ignorant bist, deshalb.
Es geht darum, dass es einen Bug gibt, den man nicht reproduzieren kann. Wie willst du da vernünftig debuggen? Da helfen nur log ausgaben. Oder willst du 100mal durch die gesamte Anwendung steppen um dann festzustellen, dass du den Bug nicht reproduziert hast. Oder willst du lieber ordentliches Logging einbauen und die Betatester die Anwendung testen lassen (und somit auch gleich andere Bugs, Usability Probleme, etc. finden)?

Weiters braucht man einen Präprozessor (oder ähnliches) um zB verschiedene versionen einer Software zu erstellen (wo man dann einfach features deaktiviert). Oder um das Debuggen zu erleichtern - weil man jeder Exception die Zeile und Datei in der sie geworfen wurde mitgibt - klar, das kann Java und auch komplette Stacktraces. Aber das tolle am Präprozessor ist, dass ich diese Sachen abschalten kann, wenn ich sie nicht mehr brauche und keine zusatzkosten mehr zahle

Oder aber auch um spezielle Optimierungen einzuschalten - zB wenn diese Anwendung auf einem MMX fähigen Rechner kompiliert wird, verwende ich überall MMX

Wozu man das braucht: weil C++ nunmal nicht Java ist. In Java hat man diese Möglichkeiten nicht. Das heisst aber nicht, dass man sie nicht braucht.

Diese Arroganz: was wir(Java) nicht haben, brauchen wir nicht - nervt.
Bei C++ ist es so, dass wir gerne mehr sachen hätten, als wir haben. In Java ist das anders - da braucht man keine Templates, keine Enums,... - hey, warte mal: Templates und Enums gibt es in Java 5 schon. Aber ich kann mich sehr gut an Diskussionen errinnnern wo Javaianer strikt dagegen waren - weil diese Sachen den Code nur kompilizierter machen...

Kannst du mir das erklären?

interpreter

Der OP wollte nur wissen, was das "c" in cout bedeutet und es endet (mal wieder) in der Java/C++ Thematik. Sehr amüsant

google**

habe den fred auch genüsslich verschlungen

interpreter

Wenn wir jetzt noch umschwenken auf Windows/Linux könnten wir ihn in die FAQ packen

Shade Of Mine schrieb:

Und du scheinst nicht zu verstehen: C++ ist eine Sprache, mehr nicht. Java ist eine Vollständige Plattform.

Du solltest dir mal langsam merken, dass Java eine Plattform ist.

Ähm ich verstehe das sehr wohl. Oder bin ich derjenige, der feststellt, dass vielleicht die GUI träge ist und daraus folgert das Java lahm ist? Ich finde ich das komisch, dass du diese Meinung von mir hast.
Diese Auflistung habe ich gemacht um zu zeigen, dass hier Äpfel mit Birnen verglichen werden. Auf der einen Seite steht etwas, was Java in sich hat und auf der anderen etwas, was C++ nicht in sich hat.

Kann ich in C++ genauso - aber ich kann auch Plattformunabhängige Libraries verwenden.

Selbstverständlich. Und wenn deine GUI dann langsam sein sollte, sage ich dann, dass C++ eine langsame Sprache ist? Nein, natürlich nicht. Um nichts anderes ging es mir hier.

Weil du ignorant bist, deshalb. Es geht darum, dass es einen Bug gibt, den man nicht reproduzieren kann. Wie willst du da vernünftig debuggen? Da helfen nur log ausgaben.

Na proma. Ich habe das Beispiel mit dem Bufferoverflow nicht gebracht, wieso bin ich jetzt der ignorante? Ich habe kein Problem damit, das auf einer abstrakteren Ebene zu betrachten, aber wenn die Rede von Bufferoverflows ist, halte ich logfiles nicht für eine geeignete Methode um den Bug zu beheben. Nichts anderes habe ich gesagt.
Aber mir dann Ignoranz zu unterstellen, obwohl ich nur auf eine konkrete Aussage reagiere, finde ich nicht in Ordnung.
Findest du es besser, bei einem Overflow in ein logfile zu schreiben, anstatt zu debuggen? Worum geht es dir jetzt überhaupt?

Oder um das Debuggen zu erleichtern - weil man jeder Exception die Zeile und Datei in der sie geworfen wurde mitgibt - klar, das kann Java und auch komplette Stacktraces. Aber das tolle am Präprozessor ist, dass ich diese Sachen abschalten kann, wenn ich sie nicht mehr brauche und keine zusatzkosten mehr zahle

Zahlst du in Java genauso wenig, wenn die Exception nicht geworfen wird.
Was "zahlst" du denn bitte krasses, wenn du den Stacktrace sammelst wenn (und nur wenn) eine Exception geworfen wird? Du beendest doch nicht regelmäßig irgendwelche for-Schleifen mit Exceptions.
Ich halte es sogar für möglich, dass in Java, im Gegensatz zu C++ selbst der Ein-/ und Austritt in try umsonst ist, also das reine Vorhandensein von Exceptionbehandlung nichts kostet. Kann ich aber nicht garantieren.

Oder aber auch um spezielle Optimierungen einzuschalten - zB wenn diese Anwendung auf einem MMX fähigen Rechner kompiliert wird, verwende ich überall MMX

Ich habe zweimal erwähnt, dass ich einen Präprozessor in C++ gut finde, um für verschiedene Plattformen zu kompilieren. Zweimal das zu sagen muss reichen um zu erkennen, dass ich dieses Argument verstanden habe und genauso sehe. Es ging auch jetzt ausschließlich ums Debuggen.
Ich habe _niemals_ gesagt, dass man in C++ auf den Präprozessor vollständig verzichten kann.

Diese Arroganz: was wir(Java) nicht haben, brauchen wir nicht - nervt.
Bei C++ ist es so, dass wir gerne mehr sachen hätten, als wir haben. In Java ist das anders - da braucht man keine Templates, keine Enums,... - hey, warte mal: Templates und Enums gibt es in Java 5 schon. Aber ich kann mich sehr gut an Diskussionen errinnnern wo Javaianer strikt dagegen waren - weil diese Sachen den Code nur kompilizierter machen...

Kannst du mir das erklären?

Nein, kann ich nicht. Weil ich enums und Templates schon immer vermisst habe. Man sollte vielleicht auch nicht immer annehmen, dass der größte Teil der Java-Programmierer diese Ansicht vertritt. Es gibt sicher auch C++-Programmierer, die meinen, dass man bestimmte Sachen nicht braucht.

CarstenJ

interpreter schrieb:

Der OP wollte nur wissen, was das "c" in cout bedeutet und es endet (mal wieder) in der Java/C++ Thematik. Sehr amüsant

Jo, spannender und vor allem billiger als Kino

Jester

@Optimizer: Kannste Dich dann mal entscheiden, ob die GUIs jetzt zu Java dazugehören oder nicht?

Walli

*popcorn-hol*

Selbstverständlich gehören die GUI-APIs zu Java dazu. Allerdings finde ich es ziemlich billig, mir daraus einen Strick zu drehen und zu sagen "Swing ist langsam also ist Java langsam".
Vor allem zu sagen, dass Java langsamer als C++ ist, obwohl C++ nichts vergleichbares bietet, ist völlig falsch.

Da kann ja dann jeder daher kommen, "C++ ist schneller als Java, weil die Reflection in Java ist ja voll lahm".

So, die Kino-Vorstellung ist beendet.

SideWinder

Hmm, sag ich ja nicht. Hab noch kein einziges Fensterchen programmmiert und trotzdem kann man die Zeit die ein Programm zur Ausführung benötigt schon deutlich merken - StartUp fast alles eben, aber immerhin.

Bzgl. Java vs. C++ kann man sowieso wenig sagen weil das zwei Sprachen auf unterschiedlichen Ebenen sind. Java ist eine Plattform bei der zwischen OS und der Sprache noch ein Modul läuft. C++ ist eine Stufe darunter und greift direkt auf das OS zu. Das das natürlich schneller ist, und somit geeignet für rechenintensive Anwendungen, Spiele, hardwarenahe Anwendungen ist verständlich. Java hat offenbar gute integrierte plattformunabhängige GUI-Libraries und ist somit für Fenster-Programme sicher sehr geeignet. Aber wenns um Speed geht würde ich trotzdem kein Java heranziehen. Warum wollen die Java-Programmierer immer genau das mir nahelegen?

MfG SideWinder

Shade Of Mine

Optimizer schrieb:

Vor allem zu sagen, dass Java langsamer als C++ ist, obwohl C++ nichts vergleichbares bietet, ist völlig falsch.

Und das wäre? Reflection? Darum geht es aber nicht... GUIs kann man in C++ sehr wohl machen.

Da kann ja dann jeder daher kommen, "C++ ist schneller als Java, weil die Reflection in Java ist ja voll lahm".

C++ ist schneller, weil Java langsamer ist.
Wollen wir Benchmarks machen? Hatten wir schon öfters hier im Forum: resultat war: Java ist langsamer (nicht viel, aber doch).

Warum willst du das nicht wahrhaben?

Und Swing (die meisten Java GUIs sind nunmal in Swing geschrieben) ist wirklich zu langsam. Wenn ich Swing Anwendungen starte, dann merke ich das sogar auf meinem AMD 2,2GHz Rechner - und das darf einfach nicht der Fall sein.

groovemaster

Optimizer schrieb:

Besonders der Punkt "wo was falsch gelaufen ist" ist ja wohl auch nicht ganz passend. Oder krieg ich irgendwie mit Standard C++ den kompletten Stack Trace in das logfile mit allen lokalen Variablen?

Keine Ahnung, hab aber schon Programme gesehen, die sowas anbieten. Aber oft reicht ein __FILE__ und __LINE__ da schon aus.

Optimizer schrieb:

Na proma. Ich habe das Beispiel mit dem Bufferoverflow nicht gebracht, wieso bin ich jetzt der ignorante?

Weil du behauptest, Logs sind für sowas unsinnig und mit Debuggen findest du den Fehler schneller.

Optimizer schrieb:

Findest du es besser, bei einem Overflow in ein logfile zu schreiben, anstatt zu debuggen? Worum geht es dir jetzt überhaupt?

Dann erklär mir doch mal, wie du das anstellen willst. Du siehst einfach nur, dein Programm stürzt an einer bestimmten Stelle ab. Damit kann man ja eventuell noch den betroffenen Code eingrenzen. Und dann? 3 Stunden debuggen, nur um festzustellen, dass der Fehler nicht reproduzierbar ist? Nein, danke. Da schau ich in mein Log-File und seh ganz genau an welcher Stelle der Fehler auftrat.
Du musst auch mal bedenken, dass während einer Testphase nicht immer wünschenswert ist, wenn ein Programm mit 'ner Exception beendet wird und die Programmierer den Fehler sofort beheben. Erst recht nicht wenn man den Kunden als Testkandidat "missbraucht". Da sammel ich einfach alles was so anfällt, und nicht zwangsläufig die Beendigung des Programms erfordert, in einem Log-File.