Was heißt das c bei cout?

Walli

otze schrieb:

"#" operator

otze

stringizing token(wurde in verschiedensten quellen als operator benannt-halt ein präprozessoroperator)

@MaSTaH:

Das ist der 'sharp'-operator. Mit ihm ist es möglich, Teile des Codes in C# zu schreiben und direkt native dann in die C++ Quelldatei einzubinden. :p

Walli

Optimizer schrieb:

@MaSTaH:

Das ist der 'sharp'-operator. Mit ihm ist es möglich, Teile des Codes in C# zu schreiben und direkt native dann in die C++ Quelldatei einzubinden. :p

*g*

otze schrieb:

stringizing token(wurde in verschiedensten quellen als operator benannt-halt ein präprozessoroperator)

Achso, habe noch nie eine Quelle gesehen in der man das als Operator bezeichnet hat.

Bashar

Ah. So wie der ++-Operator es erlaubt, C++-Code in C einzubinden? Mann bin ich heute wieder schlau

otze

MaSTaH schrieb:

otze schrieb:

stringizing token(wurde in verschiedensten quellen als operator benannt-halt ein präprozessoroperator)

Achso, habe noch nie eine Quelle gesehen in der man das als Operator bezeichnet hat.

hmm ausser meinem buch finde ich aauf die schnelle auch keine quelle mehr...naja, wie würdet ihr es denn nennen?

Walli

otze schrieb:

hmm ausser meinem buch finde ich aauf die schnelle auch keine quelle mehr...naja, wie würdet ihr es denn nennen?

Keine Ahnung. Benutze es zu selten in Gesprächen, als dass ich einen Namen dafür bräuchte .

Von der Verwendung her würde ich es auch als (unären) Operator bezeichnen.
Das dürfte schon korrekt sein. Was soll es sonst sein?

@Bashar: korrekt.

Bashar

c99 draft schrieb:

6.10.3.2 The # operator

groovemaster

Oder ISO C++

16.3.2 The # operator

Versteh nicht, warum hier einige so gegen den Präprozessor schiessen. Er ist ja nicht dafür gedacht, den Compiler zu ersetzen, sondern ihn zu unterstützen. Und Sachen wie __FILE__ oder __LINE__ sind gerade für Debugging recht nützlich, und da reicht es nicht sowas einfach in 'ne Funktion zu packen, weil sowas an Ort und Stelle ersetzt werden muss.
Und ein

#define DEBUG_LOG(text) debug::log(text, __FILE__, __LINE__)

ist doch da recht praktisch.

Ich hab's doch vorhin gesagt, für so etwas gibt es Debugger. Genau sowas ist IMHO einer der vielen Fälle, wo der Präprozessor einfach ausgedient hat und sowas kann ich auch nicht praktisch finden.
Mich stört ja ein Präprozessor nicht, insbesondere wenn man Unterscheidungen für verschiedene Plattformen einbaut, kann er in C++ durchaus nützlich sein.
Das der Präprozessor oft im schlechten Licht erscheint, ist doch logisch. Das Übersetzungsmodell in C++ suckt und weil man dafür den Präpro braucht, fällt er in der Gunst schon mal ein ganzes Stück ab.
Dann sind mal irgendwann Leute auf die Idee gekommen, dass Makros bei schlechten Compilern schneller sind, als gewöhnliche Funktionen. Über Makros vs. Funktionen weißt du sicher bescheid.
dito Konstanten. Im Grunde sind es nur fehlende Sprachmerkmale gewesen, aber mit dem Präpro hat man immer alles schön workarounden können, ein Wunderwerkzeug. Und wie alles, wird er gehasst, wenn man erstmal was besseres gefunden hat.

SideWinder

Sie sterben bloß aber einer gewissen Programmierebene, wer zu lange mit Programmiersprachen auf Lvl4 gespielt hat benötigt keinen Präprozessor mehr. Aber es gibt auch noch Leute die keine Lvl4-Sprachen benützen können, mit dem Präprozessor und nicht mit dem Interpreter Plattformunabhängigkeit erreichen(#ifdef WIN32), etc.

MfG SideWinder

Optimizer schrieb:

insbesondere wenn man Unterscheidungen für verschiedene Plattformen einbaut, kann er in C++ durchaus nützlich sein.

Außerdem bestehe ich darauf, dass du zukünftig JIT-Compiler sagst und nicht Interpreter.

SideWinder

Wir lernen Java grade in der Schule und jeder ist derart vom Speed überzeugt, dass wir uns auf Interpreter geeinigt haben, JIT-Compiler klingt so furchtbar schnell *g*

MfG SideWinder

interpreter

Optimizer schrieb:

Außerdem bestehe ich darauf, dass du zukünftig JIT-Compiler sagst und nicht Interpreter.

SideWinder schrieb:

Wir lernen Java grade in der Schule und jeder ist derart vom Speed überzeugt, dass wir uns auf Interpreter geeinigt haben, JIT-Compiler klingt so furchtbar schnell *g*

Es ist auch furchtbar schnell. Man muss halt das Männer-Java benutzen.
Diese "Überzeugungen" kommen entweder von Hörensagen oder von veralteten Java-Versionen.

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