[C/C++] const auf integrale typen in einer Funktion sinnvoll?
-
otze schrieb:
Anfänger. Die Referenz ist ein Abstraktes Ding. das gibt es gar nicht. Du greifst auf das Originalobjekt zu.
oh stimmt, im zweiten cast hätte ja noch ein & hingemusst. mein fehler. ich muss zugeben: meine letzten experimente mit c++ liegen schon etwas zurück.
-
;fricky schrieb:
otze schrieb:
Anfänger. Die Referenz ist ein Abstraktes Ding. das gibt es gar nicht. Du greifst auf das Originalobjekt zu.
oh stimmt, im zweiten cast hätte ja noch ein & hingemusst. mein fehler. ich muss zugeben: meine letzten experimente mit c++ liegen schon etwas zurück.
Ich sage ja, einfach einmal mit der Materie befassen bevor man trollt, das wirkt dann besser.
-
Shade Of Mine schrieb:
;fricky schrieb:
otze schrieb:
Anfänger. Die Referenz ist ein Abstraktes Ding. das gibt es gar nicht. Du greifst auf das Originalobjekt zu.
oh stimmt, im zweiten cast hätte ja noch ein & hingemusst. mein fehler. ich muss zugeben: meine letzten experimente mit c++ liegen schon etwas zurück.
Ich sage ja, einfach einmal mit der Materie befassen bevor man trollt, das wirkt dann besser.
ach nö, für meine belange reicht der blick aus der vogelperspektive. wieso sollte ich auch 'nen 'schwarzen gürtel' in der cpp-programmierung anstreben, wenn ich c++ voraussichtlich nie verwenden werde? bisherige versuche liegen, wie gesagt, schon eine weile zurück und nur die albtraumhaftesten erlebnisse haben sich bei mir eingeprägt. für mich reicht es aus, c++ code lesen zu können. und ob da irgendwo ein reinterpret_cast oder c-cast auftaucht, ist dabei völlig gleich. ausserdem hast selbst du, als meister des fachs, im ersten cast eine dereferenzierung gesehen, so dass ich mich, als c++-noob, dafür nicht schämen muss.
-
;fricky schrieb:
ach nö, für meine belange reicht der blick aus der vogelperspektive. wieso sollte ich auch 'nen 'schwarzen gürtel' in der cpp-programmierung anstreben, wenn ich c++ voraussichtlich nie verwenden werde?
Die Frage ist nicht warum du C++ lernen sollst, sondern warum du über C++ sprichst wenn du keine Ahnung davon hast.
Fast jeder deiner Posts zeigt dass du die Grundlagen nicht verstanden hast, natürlich kommt dir C++ dann komisch vor. Mir kommt zB japanisch auch komisch vor und ich kann mir nicht vorstellen dass man mit dieser Schrift vernünftig arbeiten kann... Aber ich poste nicht dauernd wie dumm Japanisch ist
bisherige versuche liegen, wie gesagt, schon eine weile zurück und nur die albtraumhaftesten erlebnisse haben sich bei mir eingeprägt.
Weil du vermutlich alles falsch gemacht hast.
für mich reicht es aus, c++ code lesen zu können. und ob da irgendwo ein reinterpret_cast oder c-cast auftaucht, ist dabei völlig gleich. ausserdem hast selbst du, als meister des fachs, im ersten cast eine dereferenzierung gesehen, so dass ich mich, als c++-noob, dafür nicht schämen muss.
Da ist eine dereferenzierung.
****reinterpret_cast<int>(a);
Der erste * ist ein derferentierungs operator.
Solltest du aus C her kennen.
Der cast entspricht einem
(int)a;
in C.
-
Shade Of Mine schrieb:
Fast jeder deiner Posts zeigt dass du die Grundlagen nicht verstanden hast, natürlich kommt dir C++ dann komisch vor.
in der tat, jedesmal wenn ich versuche, etwas davon zu verstehen kommt es mir extrem komisch vor. aber ok, ich bin vielleicht auch etwas zu verwöhnt.
Shade Of Mine schrieb:
für mich reicht es aus, c++ code lesen zu können. und ob da irgendwo ein reinterpret_cast oder c-cast auftaucht, ist dabei völlig gleich. ausserdem hast selbst du, als meister des fachs, im ersten cast eine dereferenzierung gesehen, so dass ich mich, als c++-noob, dafür nicht schämen muss.
Da ist eine dereferenzierung.
****reinterpret_cast<int>(a);
Der erste * ist ein derferentierungs operator.aber wieso stürtzt er nicht schon da ab? schliesslich ist a null. würde er in der zeile a dereferenzieren, dann käme er nicht mehr zum zweiten cast, was er aber schafft (bei mir jedenfalls).
-
;fricky schrieb:
in der tat, jedesmal wenn ich versuche, etwas davon zu verstehen kommt es mir extrem komisch vor. aber ok, ich bin vielleicht auch etwas zu verwöhnt.
Du versuchst es ja nicht, du gehst mit der Einstellung ran dass C++ kaputt ist. So kann das nicht funktionieren.
aber wieso stürtzt er nicht schon da ab? schliesslich ist a null. würde er in der zeile a dereferenzieren, dann käme er nicht mehr zum zweiten cast, was er aber schafft (bei mir jedenfalls).
Mein Gott fricky, muss man dir alles vorkauen?
Es stürtzt deshalb nicht ab, weil der Compiler hier optimiert.
int* p=0;
int& r=*p;stürtzt deshalb nicht ab obwohl p dereferenziert wird, weil der compiler referenzen sofern möglich als zeiger implementiert (bzw als alias wenn das möglich ist). das bedeutet in wahrheit wird der inhalt von p hier nie angesprochen. das ist aber extrem von der plattform abhängig. denn referenzen müssen ja nicht als zeiger implementiert sein. es kann sein dass es hier bereits PENG macht. es ist illegal einen null zeiger zu dereferenzieren, auch wenn der compiler hier diese dereferenzierung einfach wegoptimiert.
der compiler greift also erst bei
int i=r;
auf den speicher zu auf den p zeigt und schmiert also erst hier ab.das ist das problem mit undefinierten verhalten
Ist ähnlich wie ein:
int* p=0;
int* p2=&*p;
in C.p wird zwar dereferenziert, aber da der compiler hier optimiert, passiert nichts.
-
Shade Of Mine schrieb:
;fricky schrieb:
in der tat, jedesmal wenn ich versuche, etwas davon zu verstehen kommt es mir extrem komisch vor. aber ok, ich bin vielleicht auch etwas zu verwöhnt.
Du versuchst es ja nicht, du gehst mit der Einstellung ran dass C++ kaputt ist. So kann das nicht funktionieren.
es war nicht immer so. ich habe bestimmt zwei jahre oder länger gebraucht, bis ich zu dem schluss gekommen bin, dass c++ so ziemlich vermackelt ist. vorher hatte ich auch schon manchmal ein ungutes gefühl, aber dachte mir: 'das muss wohl so sein'.
Shade Of Mine schrieb:
aber wieso stürtzt er nicht schon da ab? schliesslich ist a null. würde er in der zeile a dereferenzieren, dann käme er nicht mehr zum zweiten cast, was er aber schafft (bei mir jedenfalls).
Es stürtzt deshalb nicht ab, weil der Compiler hier optimiert.
int* p=0;
int& r=*p;
stürtzt deshalb nicht ab obwohl p dereferenziert wird, weil der compiler referenzen sofern möglich als zeiger implementiert (bzw als alias wenn das möglich ist). das bedeutet in wahrheit wird der inhalt von p hier nie angesprochen.den ersten teil deiner erklärung halte ich aber für falsch, denn es wird nicht dereferenziert, sondern erst wenn die referenz benutzt wird. daher muss auch nichts optimiert werden, weil ja die referenz (wie du danach schon sagtest) ein alias für *p ist.
-
;fricky schrieb:
den ersten teil deiner erklärung halte ich aber für falsch, denn es wird nicht dereferenziert, sondern erst wenn die referenz benutzt wird. daher muss auch nichts optimiert werden, weil ja die referenz (wie du danach schon sagtest) ein alias für *p ist.
Wenn p ein UDT ist, dann würde ein T& r=*p; sehr wohl einen zugriff auf das referenzierte objekt produzieren.
und wenn referenzen intern keine zeiger sind, kann das natürlich auch bei builtins der fall sein.
es ist also eine optimierung, genau wie &*p eine ist.
-
Was soll hier mit Zugriff gemeint sein?
-
camper schrieb:
Was soll hier mit Zugriff gemeint sein?
reale dereferenzierung.
*p ist eine syntaktische dereferenzierung aber bei &*p wird zB nichts real dereferenziert, es findet kein zugriff auf *p statt.
einen wirklichen zugriff auf *p findet aber zB hier statt: int i=*p;
-
;fricky schrieb:
aber wieso stürtzt er nicht schon da ab? schliesslich ist a null. würde er in der zeile a dereferenzieren, dann käme er nicht mehr zum zweiten cast, was er aber schafft (bei mir jedenfalls).
Ach ja, fricky, vielleicht würde hier die Assembler-Ausgabe des Compilers weiterhelfen, aber dazu müsste man sich mit der CPU beschäftigen, mit den Adressierungsarten usw. - und das ist ja alles Quatsch...
-
abc.w schrieb:
;fricky schrieb:
aber wieso stürtzt er nicht schon da ab? schliesslich ist a null. würde er in der zeile a dereferenzieren, dann käme er nicht mehr zum zweiten cast, was er aber schafft (bei mir jedenfalls).
Ach ja, fricky, vielleicht würde hier die Assembler-Ausgabe des Compilers weiterhelfen
glaub ich nicht, eine 'syntaktische dereferenzierung' (um es mit shade-of-mines worten zu sagen) auf c++ level, muss nicht notwendigerweise eine entsprechung im assemblercode haben.
abc.w schrieb:
und das ist ja alles Quatsch.
allerdings. wieso erzählst du's dann, wenn du weisst das es quatsch ist?
-
;fricky schrieb:
Shade Of Mine schrieb:
;fricky schrieb:
in der tat, jedesmal wenn ich versuche, etwas davon zu verstehen kommt es mir extrem komisch vor. aber ok, ich bin vielleicht auch etwas zu verwöhnt.
Du versuchst es ja nicht, du gehst mit der Einstellung ran dass C++ kaputt ist. So kann das nicht funktionieren.
es war nicht immer so. ich habe bestimmt zwei jahre oder länger gebraucht, bis ich zu dem schluss gekommen bin, dass c++ so ziemlich vermackelt ist. vorher hatte ich auch schon manchmal ein ungutes gefühl, aber dachte mir: 'das muss wohl so sein'.
das lässt jetzt aber weniger rückschlüsse auf C++ zu, als auf dich.
-
hustbaer schrieb:
das lässt jetzt aber weniger rückschlüsse auf C++ zu, als auf dich.
auf beide, würde ich sagen. mag sein, dass ich in gewissen dingen zu pingelig und zu wenig kompromissbereit bin, aber pferd und reiter müssen nunmal zueinander passen, sonst wird das nix. übrigens kann ich mich normalerweise gut mit bugs und macken arrangieren, wenn es keine ausweichmöglichkeit gibt. aber wenn ich alternativen sehe, bei denen bestimmte unzulänglichkeiten garnicht erst existieren, dann hat meine toleranz ein ende.
-
Das nennt man Rigidität, fricky.
-
abc.w schrieb:
Das nennt man Rigidität, fricky.
ach nö, das ist eher 'ne mischung aus pragmatismus, erfahrungswerten (ich habe einige male mitbekommen, wie andere mit c++ gescheitert sind) und rationalen entscheidungen. wäre ich rigide, würde ich in reinem ansi-C ein vernetztes warenwirtschaftssystem oder ähnliches programmieren wollen. sowas würde mir im traum nicht einfallen. ausserdem würde ich, ohne zu murren, selbstverständlich c++ benutzen, wenn's die einzige programmiersprache auf der welt wäre.
-
;fricky schrieb:
auf beide, würde ich sagen. mag sein, dass ich in gewissen dingen zu pingelig und zu wenig kompromissbereit bin, aber pferd und reiter müssen nunmal zueinander passen, sonst wird das nix. übrigens kann ich mich normalerweise gut mit bugs und macken arrangieren, wenn es keine ausweichmöglichkeit gibt. aber wenn ich alternativen sehe, bei denen bestimmte unzulänglichkeiten garnicht erst existieren, dann hat meine toleranz ein ende.
Fricky, wenn du C++ nicht magst, ist das eine Sache. Das ist völlig okay.
Wenn du aber ständig sinnlos rumflamen musst und dann nicht mal brauchbare Begründungen hast, sondern deine Argumente aus einzelnen Bash-Papers schlagwortartig zusammenbastelst, erhält man schon einen etwas speziellen Eindruck. Es ist absolut offensichtlich, dass du nur oberflächliche Kenntnisse über die Programmiersprache C++ besitzt. Trotzdem masst du dir andauernd an, über Dinge urteilen zu können, welche du nicht im Geringsten verstehst. Fast immer stellt sich dabei heraus, dass dir einfach die Erfahrung mit C++ fehlt, um irgendeine Behauptung vernünftig rechtfertigen zu können. Dazu kommt deine Fähigkeit, Fakten um jeden Preis nicht wahrhaben zu wollen, nur um das eigene konservative Weltbild nicht zu gefährden. Eine wahrlich sehr gute Diskussionsgrundlage.
Kann ja sein, dass du es wirklich derart lustig findest, andere Leute auf diese Weise zu nerven. Aber für den Fall, dass du tatsächlich einmal gewillt sein solltest, eine sachliche Diskussion zu führen, musst du deine Vorgehensweise stark überdenken. Du hast nämlich irgendwie die Fähigkeit, immer die irrelevantesten Aspekte von C++ zu kritisieren. Dabei gäbe es doch wirklich genügend Kritikpunkte, aber damit müsste man sich eben befassen.
-
Nexus schrieb:
Wenn du aber ständig sinnlos rumflamen musst und dann nicht mal brauchbare Begründungen hast, sondern deine Argumente aus einzelnen Bash-Papers schlagwortartig zusammenbastelst, erhält man schon einen etwas speziellen Eindruck.
das lässt sich ganz einfach erklären: ich sehe irgendein statement und gebe impulsiv meinen senf dazu. irgendwelche links zu bash-seiten ergoogle ich in windeseile und poste sie dazu, das dauert keine 30 sekunden. ich baue keine wohlüberlegten schlussketten auf, die man paraphrasieren/formalisieren könnte und die einer aussagenlogischen untersuchung standhalten würden, bin ja kein philosoph. es ist nur lockeres plaudern, was ich von mir gebe, wie's viele in forensystemen so machen.
Nexus schrieb:
Es ist absolut offensichtlich, dass du nur oberflächliche Kenntnisse über die Programmiersprache C++ besitzt. Trotzdem masst du dir andauernd an, über Dinge urteilen zu können, welche du nicht im Geringsten verstehst.
dass ich von c++ gerade mal so die grundlagen kenne, hab' ich mehr als einmal zugegeben. aber da diese grundlagen schon so offensichtlich inkonsistent sind, gehe ich davon aus, dass mich in den tiefen noch grössere abgründe erwarten. oder meinst du es gibt ein licht am ende des tunnels, also dass es sich lohnt, den steinigen c++-weg zu gehen, um am ende als 'erleuchteter' dazustehen? welchen sinn hätte das für mich, im hinblick darauf, dass ich eine programmiersprache als werkzeug und nicht als forschungsobjekt betrachte?
Nexus schrieb:
Du hast nämlich irgendwie die Fähigkeit, immer die irrelevantesten Aspekte von C++ zu kritisieren. Dabei gäbe es doch wirklich genügend Kritikpunkte, aber damit müsste man sich eben befassen.
was wären denn deine kritikpunkte (ausser C++0x)?
-
Nexus schrieb:
Du hast nämlich irgendwie die Fähigkeit, immer die irrelevantesten Aspekte von C++ zu kritisieren. Dabei gäbe es doch wirklich genügend Kritikpunkte, aber damit müsste man sich eben befassen.
Irgendwie muss ich jetzt an Archie denken, der hatte das bei solchen diskussionen auch immer behauptet. Und plötzlich tauchen so Sachen wie nullptr im neuen Standard auf, obwohl das doch nur geflame von Leuten war, die doch von C++ keine Ahnung hatten.
-
dass ich von c++ gerade mal so die grundlagen kenne, hab' ich mehr als einmal zugegeben. aber da diese grundlagen schon so offensichtlich inkonsistent sind, gehe ich davon aus, dass mich in den tiefen noch grössere abgründe erwarten. oder meinst du es gibt ein licht am ende des tunnels, also dass es sich lohnt, den steinigen c++-weg zu gehen, um am ende als 'erleuchteter' dazustehen?
Vieles was am Anfang bei C++ verwirrend ist, wird konsistent, wenn man ein wenig tiefer gegraben hat.
Der Anfänger(Basher) sagt: "Was ne Scheiss Sprache. Wenn ich A+B+C mache, dann funktioniert gar nichts".
Der Profi sagt: Und? Wann brauchst du A+B+C wirklich gleichzeitig? A+B , B+C und A+C funktionieren perfekt - und damit hast du bereits mehr Möglichkeiten, als bei anderen Sprachen wo es B nicht einmal gibt.
