C/C++

[Shade Of Mine]

-fricky- schrieb:

wäre nicht ein fehler beim compilieren sinnvoller, als einfach das 'nächst passende' zu nehmen? vor allem passt das, angeblich nächste passende, überhaupt nicht.

ja, aber printf macht es genauso.

nur dass printf dabei abstürtzen kann und cout halt warnt dass es nicht weiss was du von ihm willst.

[-fricky-]

Shade Of Mine schrieb:

nur dass printf dabei abstürtzen kann und cout halt warnt dass es nicht weiss was du von ihm willst.

naja, bei printf kommt auch ein warning. und zwar ein ziemlich unmissverständliches:

'%d' in format string conflicts with argument 1 of type 'volatile int *

während die warnung beim 'cout':

forcing value to bool 'true' or 'false' (performance warning)

doch erstmal zum nachdenken anregt (lenkt z.b. vom eigentlichen problem ab durch den hinweis, dass die performance leiden könnte). abstürzen würden sie wohl beide, auf einem system, auf dem ein missratener lesezugriff solche auswirkungen hätte. mich erschüttert nur etwas diese konvertierung in ein 'boolean' und das damit verbundene 'aus 123 mach 1'. das könnte man schon als handfesten bug bezeichnen, der übrigens schon seit jahren drin ist. nur dass der alte MSVC dabei keinerlei warnung ausspuckte.

[Ben04]

-fricky- schrieb:

mich erschüttert nur etwas diese konvertierung in ein 'boolean' und das damit verbundene 'aus 123 mach 1'. das könnte man schon als handfesten bug bezeichnen, der übrigens schon seit jahren drin ist. nur dass der alte MSVC dabei keinerlei warnung ausspuckte.

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. Ich bin mir ganz und gar nicht sicher ob

printf("%p", (volatile int*)123);

überhaupt legaler Code ist. Bei der Übergabe dürfte eine Konvertierung volatile int* => volatile void* stattfinden. In printf wird bei va_arg jedoch void* benutzt. Ich glaube nicht, dass va_arg vom übergebenen Typ abweichen darf.

[camper]

cout versagt also wenn Machiavelli, err... -fricky- am Werk ist?
Interessiert mich das?
eher nicht.

[camper]

-fricky- schrieb:

forcing value to bool 'true' or 'false' (performance warning)

doch erstmal zum nachdenken anregt (lenkt z.b. vom eigentlichen problem ab durch den hinweis, dass die performance leiden könnte). abstürzen würden sie wohl beide, auf einem system, auf dem ein missratener lesezugriff solche auswirkungen hätte. mich erschüttert nur etwas diese konvertierung in ein 'boolean' und das damit verbundene 'aus 123 mach 1'. das könnte man schon als handfesten bug bezeichnen, der übrigens schon seit jahren drin ist. nur dass der alte MSVC dabei keinerlei warnung ausspuckte.

Offensichtlich denkst du nicht nach, sondern willst nur trollen. Wenn irgendetwas am cout Fall zum Absturz führen könnte, dann die unsägliche Initialisierung des Zeigers, die du verbrochen hast.

[-fricky-]

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.

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.

[LordJaxom]

cout konvertiert wenigstens irgendwas. printf macht es einfach nur falsch.

[Shade Of Mine]

-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

[-fricky-]

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.

[pumuckl]

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

[Don06]

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?

[Gast]

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

[-fricky-]

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.

[*john 0]

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

[-fricky-]

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

[Dravere]

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

Grüssli

[-fricky-]

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

was willst du damit sagen? doch nicht etwa, dass man auf volatile komplett verzichten kann und daher 'cout' es auch nicht kennen muss?

[Dravere]

Ich wollte unserem ehrenwerten Troll -fricky- nur etwas Bildung/Wissen schenken. Mehr hatte ich eigentlich nicht vor.

Grüssli

[sothis_]

mir ist aufgefallen, dass fricky immer als troll abgestempelt wird. wie kommt's?

[Nicht wirklich]

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.