Was heißt das c bei cout?

[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

[Gast]

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*

[Gast]

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.

[Gast]

nd 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.

Achso, das musst du mir ja dazu sagen, dass du bei ner acces violation den ganzen Stacktrace mit lokalen Variablen in ein logfile kriegst, damit kann man dann natürlich schon was anfangen.
Sag das doch gleich.
Mal im Ernst: Deine Methode setzt zwangsläufig voraus, dass du weißt, wo der Fehler auftritt, weil du schlicht nicht überall was einbauen kannst.

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

Nein, kann man nicht. Jetzt wirst du natürlich sagen, es gibt plattformunabhängige GUI-Libs für C++. Die kann ich in Java aber auch verwenden. Wir drehen uns damit im Kreis. Das führt zu gar nichts.
GUIs sind bei C++ standardmäßig _nicht_ dabei und wenn sie es bei Java sind, kannst du trotzdem nicht Java-GUIs mit C++-GUIs vergleichen. AWT ist in Java auch sauschnell, weil es die nativen Controls wrappt.

Aber seltsamerweise nimmt keiner AWT. Das ist natürlich gar nicht so seltsam, wie es auf den ersten Blick scheint. Gezeichnete GUIs wie Swing sind einfach viel mächtiger, ich kann auf nen Button ein Bild und ne DropDownList platzieren, auch wenn es das im BS-API gar nicht gibt.
Und so langsam aber sicher ist Swing performancemäßig voll ok.

Warum willst du das nicht wahrhaben?

Nein, du willst es nicht wahrhaben. Inzwischen haben ziemlich viele Leute (auch hier im Forum und auch Leute, die Ahnung haben) festgestellt, dass Java nicht oder nicht wesentlich langsamer ist.
Ich weiß auch gar nicht, warum mit dem Thema immer wieder neu angefangen werden muss. Ich weiß es wirklich nicht. Anscheinend können es einige echt nicht akzeptieren. Und Gründe oder Beweise kriege ich sowieso gar nicht erst zu hören. Die Leute, die nicht wissen, wie der GC arbeitet, sagen, der GC ist lahm. Die, die nicht wissen, dass JIT-compiliert wird, sagen das interpretieren ist lahm. Die, die nicht wissen, dass die Indexprüfung nur in nicht-trivialen Fällen nicht wegoptimiert werden kann, sagen, dass über ein Array iterieren lahm sei.
Ich höre aber nie was wirklich einleuchtendes.

[Shade Of Mine]

Optimizer schrieb:

Mal im Ernst: Deine Methode setzt zwangsläufig voraus, dass du weißt, wo der Fehler auftritt, weil du schlicht nicht überall was einbauen kannst.

In jede Funktion kommt
GUARD;
als erste Zeile rein - ist quasi kein Aufwand...

Nein, kann man nicht. Jetzt wirst du natürlich sagen, es gibt plattformunabhängige GUI-Libs für C++. Die kann ich in Java aber auch verwenden.

Tut man aber nicht. Weil dann Java keinen Sinn mehr macht - dann nehm ich gleich C++.

Java macht halt nur mit Java GUIs sinn...

Aber seltsamerweise nimmt keiner AWT. Das ist natürlich gar nicht so seltsam, wie es auf den ersten Blick scheint. Gezeichnete GUIs wie Swing sind einfach viel mächtiger, ich kann auf nen Button ein Bild und ne DropDownList platzieren, auch wenn es das im BS-API gar nicht gibt.

Die Kosten sind aber nicht gerade gering...

Und so langsam aber sicher ist Swing performancemäßig voll ok.

Langsam wird es. Aber 1.4.2 ist definitiv zu lahm. Auf meinem Notebook sind leider keine Java/Swing Apps lauffähig, weil er da immer in die Knie geht.

Nein, du willst es nicht wahrhaben. Inzwischen haben ziemlich viele Leute (auch hier im Forum und auch Leute, die Ahnung haben) festgestellt, dass Java nicht oder nicht wesentlich langsamer ist.

Habe ich behauptet dass Java wesentlich langsamer ist? Ich glaube nicht.
Ich habe gesagt dass Swing sehr langsam ist. Und das willst du doch nicht bestreiten, oder?

Ich weiß auch gar nicht, warum mit dem Thema immer wieder neu angefangen werden muss.

Weil ich deine letzten Aussagen nicht so stehen lassen konnte.

Anscheinend können es einige echt nicht akzeptieren. Und Gründe oder Beweise kriege ich sowieso gar nicht erst zu hören.

Starte mal Netbeans, Eclipse, ZendStudio, etc. Und dann starte Visual Studio. Die meisten Features hat VS und startet am schnellsten und lagt garnicht. Ist das ein Beweis dass Java GUIs langsamer sind?

Vielleicht habe ich auch nur schlecht programmierte Programme bei mir installiert, aber ich kann auf den ersten Blick sagen, ob ein Programm eine Java GUI hat, oder nicht. (Und ich habe einen 2,2GHz AMD Prozessor mit 512MB Ram - da sollte ich es echt nicht merken, oder?)

Die Leute, die nicht wissen, wie der GC arbeitet, sagen, der GC ist lahm.

Hab ich das gesagt?

Die, die nicht wissen, dass JIT-compiliert wird, sagen das interpretieren ist lahm.

Interpretieren ist lahm, jitten nicht. Aber jitten kostet halt beim starten zeit...

Die, die nicht wissen, dass die Indexprüfung nur in nicht-trivialen Fällen nicht wegoptimiert werden kann, sagen, dass über ein Array iterieren lahm sei.

Müsste ich testen, da will ich lieber nichts sagen - weil ich nicht weiss, was Java schon alles optimieren kann. Aber schleifen sind generell recht gut optimiert.

Ich höre aber nie was wirklich einleuchtendes.

Vielleicht ist das einleuchtend:
EIne GUI mit Java selber zeichnen ist im gegensatz zu Nativen Widgets lahm. Muss ich das Begründen?

uU ist SWT der richtige Ansatz, allerdings schreckt mich http://www.eclipse.org/articles/swt-design-2/swt-design-2.html schon ganz schön ab - bzw. habe ich mich beim lesen totgelacht.

Naja, die Tatsache dass Java 'lahm' ist, liegt an den GUIs - denn auch SWT (wenn ich mir Eclispe ansehe) ist nicht wirklich das gelbe vom Ei - wenn es auch besser als Swing ist.

Wenn ich mir eine .NET Anwendung ansehe - da mag der Code nicht so gut optimiert werden wie in Java, aber die GUI ist einfach verdammt schnell - wirkt wie Native, dh. ich kann den Unterschied zwischen einer .NET Anwendung und einer Nativen Anwendung nicht durch blosses Beobachten feststellen.

Eigentlich wollte ich ja garnicht auf eine "Java ist Lahm" Diskussion raus... Ich habe ja extra geschrieben, dass der Unterschied minimal ist (aber halt dennoch vorhanden).

[SideWinder]

@Shade: Wobei .NET auf anderen Plattformen als Windows sicher nicht so optimal läuft. Muss zwar zugeben noch nie ein Programm auf der Mono-Plattform ausgeführt zu haben aber hab gehört, dass es da noch erhebliche Probleme gibt

MfG SideWinder

[SirLant]

Microsoft Visual Studio.NET ist ja (afaik) ein NET Programm und das lädt einfach unglaublich schnell

[Gast]

@Shade:

In jede Funktion kommt
GUARD;
als erste Zeile rein - ist quasi kein Aufwand...

ja... irgendwo weiter oben habe ich geschrieben, dass der Präprozessor immer schon als ultimative Lösung für fehlende Sprachfeatures herhalten musste. Meine Begeisterung hält sich hier in Grenzen.

Starte mal Netbeans, Eclipse, ZendStudio, etc. Und dann starte Visual Studio. Die meisten Features hat VS und startet am schnellsten und lagt garnicht. Ist das ein Beweis dass Java GUIs langsamer sind?

Vielleicht habe ich auch nur schlecht programmierte Programme bei mir installiert, aber ich kann auf den ersten Blick sagen, ob ein Programm eine Java GUI hat, oder nicht. (Und ich habe einen 2,2GHz AMD Prozessor mit 512MB Ram - da sollte ich es echt nicht merken, oder?)

Warum z.B. Eclipse langsam startet, ist doch klar - es müssen ein paar hunderttausend Zeilen Quellcode, die bisher nur in extrem-high-level VM-Code vorliegen, übersetzt werden. Natürlich geschieht das nicht auf einmal, sondern erst bei der ersten Benutzung. Aber beim Start wird natürlich so ziemlich alles zu ersten mal aufgerufen. ;/
Aber welche Rolle spielt das? Dann startet das Ding halt langsamer. Das ist kein Beweis, dass diese IDEs langsamer sind. Gerade bei ner IDE wirst du dich sowieso schwer tun, etwas anderes zu beurteilen als die GUI.

Die Kosten sind aber nicht gerade gering..

Richtig, aber immer mehr werden sie tragbar. Gegen AWT ist performancemäßig nichts zu sagen. Da es aber auf verschiedenen Systemen laufen muss, kann es mehr oder weniger nur die Schnittstelle aller möglichen GUI-Elemente beinhalten.
Swing ist einfach verdammt viel mächtiger. Mit Swing kann man Sachen machen, von denen auch .Net nur träumen kann. Das hat seinen Preis, aber den kann man langsam aber sicher gut zahlen.

Eine GUI mit Java selber zeichnen ist im gegensatz zu Nativen Widgets lahm. Muss ich das Begründen?

Nein, aber das beweist auch nicht, dass Java langsam ist. Das ist natürlich schon typisch, dass jetzt jeder mit GUIs ankommt, was ein sehr feines Feature der stdlib von Java ist. Weil es gerade das langsamste ist muss man damit natürlich immer wieder begründen, dass das ganze Java schneckenlangsam ist.
Aber wenn du wirklich ne schnelle GUI brauchst, kannst du AWT nehmen, wenn du noch viel Funktionalität brauchst, ist vielleicht SWT nicht schlecht.
Den von dir angegebenen Artikel habe ich nur überflogen. Er scheint ziemlich nooblike geschrieben zu sein, aber was zum totlachen hab ich jetzt auch nicht gefunden.

Hab ich das gesagt?

Nein. Ist auch nur ein Beispiel von vielen kompetenten Aussagen, die man oft zu hören kriegt. Das ist jedoch ein Diskussionsthema für sich. Ein GC kann verdammt schnell sein und auch verdammt lahm, wenn man ein paar einfache Sachen nicht berücksichtigt. Besser, wir diskutieren das nicht auch noch.

Vielleicht habe ich auch nur schlecht programmierte Programme bei mir installiert, aber ich kann auf den ersten Blick sagen, ob ein Programm eine Java GUI hat, oder nicht. (Und ich habe einen 2,2GHz AMD Prozessor mit 512MB Ram - da sollte ich es echt nicht merken, oder?)

Nein, merkt man für gewöhnlich auch nicht. Java-GUIs fühlen sich heute ziemlich native an, aber (entgegen weitverbreiteter Erwartungen) nicht unbedingt in jedem Punkt Windows-like.

Naja, die Tatsache dass Java 'lahm' ist, liegt an den GUIs

Ausgezeichnet, mit dieser Aussage kann ich leben. Es steht dir selbstverständlich frei, andere Libs in Java zu benutzen. Man macht es zwar nicht, aber du kannst es trotzdem gerne tun.
Mir geht es überhaupt absolut gar nicht um GUIs, ich wollte überhaupt nie in diese Richtung, weil das nichts über Fähigkeiten der Compiler, der Sprache und VMs aussagt.

SirLant schrieb:

Microsoft Visual Studio.NET ist ja (afaik) ein NET Programm und das lädt einfach unglaublich schnell

Korrigier mich, aber ich glaube das trifft erst auf 2005 zu. Das lädt auch ein Weilchen länger, kann ist aber auch noch eine beta.
.Net hat natürlich mit seinem Native Cache ein sehr interessantes Feature um die JIT-Compilierung einzusparen. Manchmal kommt vom Hause Microsoft eben doch mal was gutes.

[groovemaster]

Optimizer schrieb:

Achso, das musst du mir ja dazu sagen, dass du bei ner acces violation den ganzen Stacktrace mit lokalen Variablen in ein logfile kriegst, damit kann man dann natürlich schon was anfangen.
Sag das doch gleich.

Was willst du denn mit lokalen Variablen? Es geht ja einfach nur darum, dass du mit Logging die Stelle im Code gezeigt bekommst, an der der Fehler auftrat und von welcher Stelle aus das ganze initiiert wurde. Wie das letztendlich realisiert wird, dafür gibts sicherlich verschiedene Ansätze. Ein Call-Stack ist ja nur eine Möglichkeit. Und wenn du mehr brauchst, kannst du auch mehr bekommen. Alles eine Frage von Aufwand und Nutzen. Und wenn der Fehler dennoch unklar bleibt, hindert dich doch niemand daran, anschliessend noch den Debugger einzusetzen. Aber blind rangehen, einfach mal auf gut Glück debuggen, ist einfach zu aufwendig und zu unproduktiv.

Optimizer schrieb:

Mal im Ernst: Deine Methode setzt zwangsläufig voraus, dass du weißt, wo der Fehler auftritt, weil du schlicht nicht überall was einbauen kannst.

Du musst auch nicht überall was einbauen. Shade hat ja schon gezeigt, wie man's trotzdem, praktisch ohne Aufwand, machen kann. Ob dir das jetzt gefällt oder nicht ist persönliche Ansichtssache und muss bei grösseren Projekten, die im Team realisiert werden, untergeordnet werden. Oder du kommst nie zum Ziel.
Wenn dir das Spass macht, kannst du Programme ohne jegliches Fehlerhandling schreiben. Letztendlich liegt da die Verantwortung beim Programmierer. Dann brauchst du dich aber auch nicht wundern, wenn die Entwicklungszeit 10 mal so lange dauert und deine changes- oder todo-Dateien länger werden als das eigentliche Programm. Solang du das als reiner Hobby-Programmierer machst, ist das unrelevant und einfach nur Spass, beruflich hört der Spass aber spätestens dort auf.
Microsoft zB hätte sich sicherlich einiges ersparen können, wenn sie konsequenter Fehlerhandling betrieben hätten, anstatt jeden Monat Updates gegen Sicherheitslücken rauszubringen (auch wenn sowas in C sicherlich etwas aufwendiger ist). Einem seriösen Programmierstil kommt sowas jedenfalls nicht zugute, was aber nicht zwangsläufig bedeuten muss, dass die Verkaufszahlen darunter leiden (wenn wir schon bei MS sind).