[C/C++] const auf integrale typen in einer Funktion sinnvoll?
-
;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.
-
;fricky schrieb:
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.
Aber du erwartest, das du auf diese Weise ernst genommen wirst? Lockeres Plaudern ist ja ganz okay, aber wenn es um solche Themen geht, sollte man sich schon etwas bemühen, da das die anderen Mitglieder auch tun.
;fricky schrieb:
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?
C++ ist eine eher anfängerfeindliche Sprache und scheint auf den ersten Blick tatsächlich enorm fehleranfällig und mühsam. Alleine schon die Möglichkeit, fast alles zu tun, gibt einem diesen Eindruck. Wenn man jedoch etwas Arbeit investiert, kann man C++ sehr effizient und vernünftig anwenden. Diese Arbeit mag vielleicht etwas grösser sein als bei anderen Sprachen, doch man hat dafür auch mehr Freiheiten. Wenn man die nicht braucht, kann man ruhig was anderes nehmen. Aber woher will man wissen, dass die zusätzlichen Möglichkeiten einem nicht helfen, wenn man sich nie tiefergründig mit ihnen befasst hat? Es ist natürlich einfacher, bei der oberflächlichen Ansicht zu bleiben, als etwas Aufwand zu investieren. Eigentlich schade, denn so eine voreingenommene Einstellung hat hindert einen gewaltig am Über-den-Tellerrand-Schauen. Es gäbe bestimmt Dinge, die dir auch gefielen, fricky, wenn du nur nicht so negativ an C++ rangehen würdest.
;fricky schrieb:
was wären denn deine kritikpunkte (ausser C++0x)?
Oh, da gibts auch im momentanen Standard einige. Gewisse Dinge sind tatsächlich nicht sauber umgesetzt, ein Teil davon kommt von C - aber klar hat auch C++ seine eigenen Fehler. Wenn man ein bisschen länger programmiert, fallen einem diese von selbst auf - dazu muss man nicht einmal Propaganda-Bash-Papers lesen.
dasameoldstory schrieb:
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 gewisse Dinge vom aktuellen Standard in C++0x verbessert werden, steht ausser Frage. Dass C++ nicht perfekt ist, übrigens auch. Das Problem ist nur, es werden häufig Dinge kritisiert, die bei Kenntnis der Programmiersprache entweder nicht auftreten (z.B. dauerndes fehleranfälliges Zeigergefrickel) oder eine so geringe praktische Relevanz besitzen, dass man absolut mit ihnen leben kann (z.B. fehlende
volatile int*-Überladung beistd::ostream).
