C/C++

[camper]

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.

[*john 0]

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

[Zeus]

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

[-fricky-]

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.

[camper]

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

[Tippgeber]

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

[Gast]

Tippgeber schrieb:

Wo die CPU die Daten speichert ist für dich als Programmierer egal, die CPU kümmert sich darum, dass so etwas nie passiert.

Dann erklär mir doch bitte mal wofür es das Schlüsselwort volatile gibt, wenn es mir als Programmierer ja egal sein kann wo die Daten denn liegen, weil ja die CPU sich um "alles" kümmert.

[Tippgeber]

Tim schrieb:

Tippgeber schrieb:

Wo die CPU die Daten speichert ist für dich als Programmierer egal, die CPU kümmert sich darum, dass so etwas nie passiert.

Dann erklär mir doch bitte mal wofür es das Schlüsselwort volatile gibt, wenn es mir als Programmierer ja egal sein kann wo die Daten denn liegen, weil ja die CPU sich um "alles" kümmert.

Da mag ich jetzt nicht antworten, weil camper das besser kann.

Aber das Caching ist für den Programmierer transparent. Die CPU(s) kümmern sich darum, dass das nie ein Problem ist (insofern diese keine Bugs enthalten).

[Gast]

Tippgeber schrieb:

Tim schrieb:

Tippgeber schrieb:

Wo die CPU die Daten speichert ist für dich als Programmierer egal, die CPU kümmert sich darum, dass so etwas nie passiert.

Dann erklär mir doch bitte mal wofür es das Schlüsselwort volatile gibt, wenn es mir als Programmierer ja egal sein kann wo die Daten denn liegen, weil ja die CPU sich um "alles" kümmert.

Da mag ich jetzt nicht antworten, weil camper das besser kann.

Read as: Du hast keine Ahnung.

[sothis_]

also jetzt fällt mir hier gar nichts mehr zu ein. als wenn jede gotterdenkliche CPU deine erwartungen erfüllt. es gibt noch ein wenig mehr als intel pentium 4 und amd opteron.

edit: bezieht sich auf tippgeber's kommentar, ich war zu langsam

[Tippgeber]

sothis_ schrieb:

also jetzt fällt mir hier gar nichts mehr zu ein. als wenn jede gotterdenkliche CPU deine erwartungen erfüllt. es gibt noch ein wenig mehr als intel pentium 4 und amd opteron.

edit: bezieht sich auf tippgeber's kommentar, ich war zu langsam

Ich hatte in der Tat x86 im Hinterkopf, aber es ist für mich auch nur schwer vorstellbar, dass eine CPU Caching unterstützt, aber dieses auf den Programmierer abwälzt. Da stellt sich für mich überhaupt die Frage wie man das im Programm managen will

Aber wenn du das sagst, so will ich dir mal glauben.

[-fricky-]

camper schrieb:

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

bereits im zweiten beitrag dieses threads wird empfohlen, 'cout' printf vorzuziehen. und der ist *nicht* von mir.

Tim schrieb:

Dann erklär mir doch bitte mal wofür es das Schlüsselwort volatile gibt,

ich hab' gestern noch was in 'nem add-on zum C-standard gefunden. der hauptgrund für die existenz von volatile ist, dass man mit C memory-mapped I/O machen kann. d.h. beim lesen und schreiben eines volatile-objekts muss immer ein physikalischer zugriff auf die speicherzellen bzw. den I/O-bereich stattfinden. es dürfen keine zwischengespeicherten kopien, etwa registerinhalte usw. benutzt werden. und zum ignorieren von volatile: tatsächlich darf ein compiler 'volatile' ignorieren, aber nur, wenn er sowieso immer code erzeugt, der mit den originaldaten arbeitet. in dem fall muss er 'volatile' zwar als keyword hinnehmen, aber muss nicht drauf reagieren.

[camper]

-fricky- schrieb:

camper schrieb:

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

bereits im zweiten beitrag dieses threads wird empfohlen, 'cout' printf vorzuziehen. und der ist *nicht* von mir.

Aber ja, in diesem Zusammenhang. Wie darauf kommst, dass das bedeuten soll, cout wäre kategorisch 'besser' als cout, entzieht sich meinem Verständnis. Es ist eben so, das in der Mehrzahl aller Fälle - wenn man nur die Wahl zwischen printf und cout hat - cout der Vorzug zu geben sein wird. Das heißt gleichzeitig, dass es durchaus Fälle gibt, in denen printf vorzuziehen ist. Diese Klärung dürfte aber den Rahemen des Threads sprengen, zumal diese Sonderfälle im Allgemeinen für Anfänger nicht relevant sein werden.
Zudem ist die Prämisse, volatile foo* -> bool wäre sinnlos, ohnehin nicht haltbar, worauf Zeus richtig hingewiesen hat. Ginge es nach mir, gäbe es nicht einmal die Überladung für const void*. Die Ausgabe von Adressen ist inhärent plattformabhängig, wer sich darauf einlassen möchte, kann genauso gut reinterpret_cast einsetzen.
Als Nächstes wird noch Unterstützung für die Ausgabe von Funktionszeigern und Zeigern auf Member gefordert. Ach Moment, Funktionszeiger können wir gar nicht so behandeln, weil manche Zeiger als Manipulatoren dienen. Duh.

Natürlich hat all das nichts mit printf zu tun. printf funktioniert in den betrachten Fällen sowieso nicht. Gratulation also, dass du es mal wieder geschafft hast, diesen Thread um weitere 5 überflüssige Seiten zu verlängern.

[*john 0]

-fricky- schrieb:

dann darf es standardkonforme compiler geben, die 'volatile' komplett ignorieren, oder habe ich das jetzt falsch verstanden.

Die ISO Normen für C und C++ tätigen keinerlei Aussage über Multithreading. Daher ist die Unterstützung von Multithreading Programmierung Sache der jeweiligen Plattform und des betreffenden Compilers. Auf einigen Plattformen ist die Verwendung von "volatile" eben nicht notwendig. Da wird das über Compiler pragmas geregelt, wenn man das beeinflussen will. Genauso gilt, es gibt keine Garantie dafür, daß "volatile" den gewünschten Effekt hat.

[-fricky-]

camper schrieb:

Zudem ist die Prämisse, volatile foo* -> bool wäre sinnlos, ohnehin nicht haltbar, worauf Zeus richtig hingewiesen hat.

ja, in z.b. einer if-anweisung, wo's darum geht ob 0 oder nicht. dafür isses ok. 'cout' soll mir aber den wert anzeigen. die ausgabe 'gleich oder ungleich null' ist ein wenig zu stark komprimiert. oder findest du nicht?

~john schrieb:

Genauso gilt, es gibt keine Garantie dafür, daß "volatile" den gewünschten Effekt hat.

der effekt von 'volatile' ist doch spezifiziert, nämlich das zugriffe jedesmal neu erfolgen sollen. das reicht doch als garantie.