C/C++
-
-fricky- schrieb:
warum? an der breite des zeigers ändert es nichts. nur dass das 'volatile' dabei verschwindet, könnte in seltenen fällen problematisch sein. wie gesagt: ich hätte nichts dagegen, wenn der compiler die konvertierung für 'cout' nicht akzeptiert und den compiliervorgang abbrechen würde. aber einen 'bool' daraus zu machen ist doch einfach nur mist.
Also lieber abstürtzen als warnen.
ja, das macht sinn.wenn deine trollerei wenigstens nur annäherend sinnvoll wäre. es gibt soviele sachen wo man bei c++ trollen könnte, aber du findest sie nie. furchtbar
-
LordJaxom schrieb:
cout konvertiert wenigstens irgendwas. printf macht es einfach nur falsch.
printf ist dumm und macht nur, was ihm befohlen wird. cout versucht schlau zu sein und versagt bei 'volatile int*' völlig. da ist mir printf auf jeden fall sympathischer als cout. printf macht von sich aus keine fehler. der programmierer muss die fehler schon selber machen.
Shade Of Mine schrieb:
Also lieber abstürtzen als warnen.
ja, das macht sinn.ist dir vielleicht entgangen, dass die printf-version auch warnings erzeugt?
übrigens, zum dritten mal: ich bin für 'lieber compilierung abbrechen als quatsch machen'. und nicht für abstürze.Shade Of Mine schrieb:
es gibt soviele sachen wo man bei c++ trollen könnte...
das wollen wir jetzt aber nicht. z.zt. geht es um das angeknackste 'cout' und nicht mal wieder c++ gegen den rest der welt.
-
-fricky schrieb:
camper schrieb:
cout versagt also wenn Machiavelli, err... -fricky- am Werk ist?
bei dir verhält sich cout besser? das glaube ich eher nicht. oder benutzt du 'ne eigene implementierung?
camper schrieb:
Interessiert mich das?
mich interessierts, ehrlich gesagt, auch nicht, wie kaputt 'cout' ist. ich benutze es nie. ich wollte nur mal auf den fehler hinweisen, weil mal wieder jemand meinte, dass cout ein guter ersatz für 'printf' wäre.
Es geht nicht darum wie kaputt cout deiner Meinung nach ist. camper wollte damit ausdrücken dass die Unterschiede zwischen printf und cout recht uninteressant sind, solang es nur darum geht wie der jeweilige verzweifelte Reaktionsversuch auf derartige Misshandlungen jenseits jeder Vernunft aussieht. Schließlich vergleicht man auch nicht zwei Sportwagen indem man sich damit auseinandersetzt mit welchem man besser die Heumaschine übern Acker ziehen kann.
-
Gut, cout hat ein theoretisches Problem. Aber jetzt mal ehrlich: Wann braucht ihr volatile? Wann wollt ihr den Inhalt eines volatile Zeigers als Zeichenfolge auf die Konsole ausgeben? Letzteres ergibt noch Sinn, wenn man einen Debugger schreiben würde, aber sonst?
-
volatile brauche ich ständig. Ausgeben via printf oder cout allerdings nie.
beinahe on-topic: Witzig fand ich wie die #c++-Kompetenz demletzt ein einfaches "%.2f" mit cout umsetzen wollte und laaaange suchen musste :p
-
pumuckl schrieb:
Schließlich vergleicht man auch nicht zwei Sportwagen indem man sich damit auseinandersetzt mit welchem man besser die Heumaschine übern Acker ziehen kann.
ich finde, das ausgeben von adressen ist gar nichts exotisches. und ohne 'volatile' kommt selbst cout ganz gut klar.
Don06 schrieb:
Gut, cout hat ein theoretisches Problem.
ein reales problem. die umwandlung einer adresse in einen bool'schen wert ist einfach nur totaler unsinn. ein grosser unsigned integer wert, der den gesamten adressraum abdeckt, hätte es auch getan.
Don06 schrieb:
Aber jetzt mal ehrlich: Wann braucht ihr volatile?
naja, z.b. in multitasking-systemen und bei interrupt-routinen kommt's öfter mal vor.
Don06 schrieb:
Letzteres ergibt noch Sinn, wenn man einen Debugger schreiben würde, aber sonst?
ich würde mich hüten, einen debugger zu schreiben, der ausgaben mit 'cout' macht.
-
-fricky- schrieb:
naja, z.b. in multitasking-systemen
Das wurde doch zig mal breitgetreten, daß das nur ein Seiteneffekt des Compilers ist und man sich darauf nicht verlassen darf. Solange man keine Hardware Programmierung macht, braucht man es gar nicht.
-
~john schrieb:
[Solange man keine Hardware Programmierung macht, braucht man es gar nicht.
volatile? doch, in multithreading-programmen z.b. braucht mans. wenn z.b. zwei threads auf eine variable zugreifen sollen, muss verhindert werden, dass der compiler sie in 'nem register cached. das kann man ihm mit 'volatile' verbieten.
darüber hinaus ist es kein gutes argument für eine universelle ausgabefunktion, etwas nicht zu können, nur weil es recht selten ist.
-
-fricky- schrieb:
volatile? doch, in multithreading-programmen z.b. braucht mans.
Durchlesen:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-218997-and-highlight-is-volatile+thread.htmlGrüssli
-
Dravere schrieb:
-fricky- schrieb:
volatile? doch, in multithreading-programmen z.b. braucht mans.
Durchlesen:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-218997-and-highlight-is-volatile+thread.htmlwas willst du damit sagen? doch nicht etwa, dass man auf volatile komplett verzichten kann und daher 'cout' es auch nicht kennen muss?
-
Ich wollte unserem ehrenwerten Troll -fricky- nur etwas Bildung/Wissen schenken. Mehr hatte ich eigentlich nicht vor.
Grüssli
-
mir ist aufgefallen, dass fricky immer als troll abgestempelt wird. wie kommt's?
-
sothis_ schrieb:
mir ist aufgefallen, dass fricky immer als troll abgestempelt wird. wie kommt's?
Das kann ich dir sagen. Er ist kein C++ Programmierer, höchstens C und java soweit ich weiß. Schafft es aber tatsächlich regelmäßig die unsinnigsten "Fehler" (wie hier zu sehen) darzustellen und daher C++ als schlecht darzustellen. Vllt. fängt er ja noch wieder mit der OOP in C kein Problem Sidkussion an.
-
Nicht wirklich schrieb:
sothis_ schrieb:
mir ist aufgefallen, dass fricky immer als troll abgestempelt wird. wie kommt's?
Das kann ich dir sagen. Er ist kein C++ Programmierer, höchstens C und java soweit ich weiß. Schafft es aber tatsächlich regelmäßig die unsinnigsten "Fehler" (wie hier zu sehen) darzustellen und daher C++ als schlecht darzustellen. Vllt. fängt er ja noch wieder mit der OOP in C kein Problem Sidkussion an.
also ich sehe hier nur, dass er eine durchaus valide meinung vertritt, die man teilen kann oder nicht. es fällt eben nur auf, dass dies trollargument immer fällt wenn die argumente immer dünner werden, insbesondere wenn kritik an c++ geübt wird. ähnlich wie godwins law. ich bin auch kein koch und kann mich über das schlecht gebratene steak aufregen und dass der koch nichts drauf hat, ein misanthrop bin ich deswegen noch lange nicht
-
sothis_ schrieb:
ich bin auch kein koch und kann mich über das schlecht gebratene steak aufregen und dass der koch nichts drauf hat
Ah, allerdings ist Letzteres nur eine indirekte Schlussfolgerung, und der Kritik an C++ in diesem Zusammenhang entspräche hier die Kritik an der Küchenausstattung, für die du tatsächlich nicht qualifiziert bist.
Was -fricky- zum Troll macht, ist im Übrigen die Tatsache, wann und wo er seine Argumente anbringt: nämlich vorzugsweise in Threads, die sich gerade nicht um die Vor- und Nachteile von C++ im Verhältnis zu anderen Sprachen drehen, mit anderen Worten: Thread-Hijacking.
In diesem Thread ging es um die Vor- und Nachteile der Verwendung von C-Sprachmitteln in einem C++-Programm, nicht um die Vor- und Nachteile der Wahl der Sprachwahl für das Programm an sich.
-
-fricky- schrieb:
volatile? doch, in multithreading-programmen z.b. braucht mans.
Das ist weder notwendig noch sinnvoll, da es keinerlei Garantie gibt, daß es das tut was Du von volatile erwartest. Compiler pragma wäre hier sinvoller, wenn der Compiler dies erzwingt.
darüber hinaus ist es kein gutes argument für eine universelle ausgabefunktion, etwas nicht zu können, nur weil es recht selten ist.
Du darfst gerne eine Eingabe an die Autoren der neuen ISO Norm machen und darauf hoffen, daß es als defect akzeptiert wird und nachgebessert wird.
-
-fricky- schrieb:
Ben04 schrieb:
Nur, dass dies kein Bug ist! Eine Konvertierung volatile int* => void* ist aus gutem Grund verboten. Wäre sie erlaubt, dann würde sie auch bevorzugt werden.
warum? an der breite des zeigers ändert es nichts. nur dass das 'volatile' dabei verschwindet, könnte in seltenen fällen problematisch sein. wie gesagt: ich hätte nichts dagegen, wenn der compiler die konvertierung für 'cout' nicht akzeptiert und den compiliervorgang abbrechen würde. aber einen 'bool' daraus zu machen ist doch einfach nur mist.
Type* => bool kommt doch so oft vor. Fast schon witzig greade, dass ich jetzt darauf gekommen bin.
if( pObject ) ....
-
Nicht wirklich schrieb:
Vllt. fängt er ja noch wieder mit der OOP in C kein Problem Sidkussion an.
hab ich das jemals getan? ich kann mich jedenfalls nicht daran erinnern.
~john schrieb:
...da es keinerlei Garantie gibt, daß es das tut was Du von volatile erwartest.
dann darf es standardkonforme compiler geben, die 'volatile' komplett ignorieren, oder habe ich das jetzt falsch verstanden.
~john schrieb:
Du darfst gerne eine Eingabe an die Autoren der neuen ISO Norm machen und darauf hoffen, daß es als defect akzeptiert wird und nachgebessert wird.
ach nö. wie schon gesagt: 'cout' benutze ich nie und daher sind mir seine defekte auch ziemlich egal. mir gings nur um behauptungen wie: 'cout' ist besser als 'printf' und ähnliches. was definitiv nicht stimmt.
camper schrieb:
In diesem Thread ging es um die Vor- und Nachteile der Verwendung von C-Sprachmitteln in einem C++-Programm, nicht um die Vor- und Nachteile der Wahl der Sprachwahl für das Programm an sich.
was ja wohl längst geklärt ist. und diskussionen entwickeln sich nun mal weiter. sonst könnte man ja gleich, nach der beantwortung einer frage, jeden thread schliessen.
-
-fricky- schrieb:
~john schrieb:
...da es keinerlei Garantie gibt, daß es das tut was Du von volatile erwartest.
dann darf es standardkonforme compiler geben, die 'volatile' komplett ignorieren, oder habe ich das jetzt falsch verstanden.
Ja.
-fricky- schrieb:
~john schrieb:
Du darfst gerne eine Eingabe an die Autoren der neuen ISO Norm machen und darauf hoffen, daß es als defect akzeptiert wird und nachgebessert wird.
ach nö. wie schon gesagt: 'cout' benutze ich nie und daher sind mir seine defekte auch ziemlich egal. mir gings nur um behauptungen wie: 'cout' ist besser als 'printf' und ähnliches. was definitiv nicht stimmt.
Merkwürdig nur, dass du der erste in diesem Thread bist, bei dem diese Behauptung zu finden ist. Troll
-fricky- schrieb:
was ja wohl längst geklärt ist. und diskussionen entwickeln sich nun mal weiter. sonst könnte man ja gleich, nach der beantwortung einer frage, jeden thread schliessen.
Diskussionen entwickeln sich nur, während sie stattfinden. Für neuen Themen macht neue Threads auf. Dafür sind sie da. Natürlich würde sich keiner dafür interessieren, wen du einen neuen Thread dieser Art erstellen würdest. q.e.d.
-
-fricky- schrieb:
~john schrieb:
[Solange man keine Hardware Programmierung macht, braucht man es gar nicht.
volatile? doch, in multithreading-programmen z.b. braucht mans. wenn z.b. zwei threads auf eine variable zugreifen sollen, muss verhindert werden, dass der compiler sie in 'nem register cached. das kann man ihm mit 'volatile' verbieten.
darüber hinaus ist es kein gutes argument für eine universelle ausgabefunktion, etwas nicht zu können, nur weil es recht selten ist.
Wo die CPU die Daten speichert ist für dich als Programmierer egal, die CPU kümmert sich darum, dass so etwas nie passiert.