Wozu immer Zeiger?
-
Argh. Verdammter Arrayzugriff
. Ja, da ist ein Zeiger in der Implementierung versteckt. Irgendwie bekommt man den bestimmt auch noch weg :p .
-
SeppJ schrieb:
Argh. Verdammter Arrayzugriff
. Ja, da ist ein Zeiger in der Implementierung versteckt. Irgendwie bekommt man den bestimmt auch noch weg :p .Und dann ist da immer noch der Stack-Pointer, damit du auf deine ints auch zugreifen kannst. :p
Damit du keine Zeiger brauchst, müsste jedes Programm mit den Registern auskommen. Und das wage ich zu bezweifeln.
-
wxSkip schrieb:
Und dann ist da immer noch der Stack-Pointer, damit du auf deine ints auch zugreifen kannst. :p
Ach, ich arbeite auf irgendeiner exotischen Maschine ohne Stack
. Das ist vom Standard erlaubt. 
Aber den Arrayzugriff ohne Pointer zu machen ist tatsächlich ganz schon tricky. Da fällt mir so spontan nichts als Ersatz ein.
-
SeppJ schrieb:
wxSkip schrieb:
Und dann ist da immer noch der Stack-Pointer, damit du auf deine ints auch zugreifen kannst. :p
Ach, ich arbeite auf irgendeiner exotischen Maschine ohne Stack
. Das ist vom Standard erlaubt. Aber den Arrayzugriff ohne Pointer zu machen ist tatsächlich ganz schon tricky. Da fällt mir so spontan nichts als Ersatz ein.
So exotisch ist doch eine Turingmaschine gar nicht
-
wxSkip schrieb:
So exotisch ist doch eine Turingmaschine gar nicht
Auf dem Papier und im Simulator nicht. In der Praxis schon irgendwie. Es gibt da die LEGO Mindstorms Version die man bei Youtube finden kann und ein paar weniger coole Hobby-Projekte. Ob die wohl einen C++-Compiler haben?
-
Ich bin sehr gespannt, was das für eine Turingmaschine ohne Befehlszeiger sein soll. Das funktioniert ja nicht mal auf dem Papier?
-
cooky451 schrieb:
Ich bin sehr gespannt, was das für eine Turingmaschine ohne Befehlszeiger sein soll. Das funktioniert ja nicht mal auf dem Papier?
Befehlszeiger? Man muss halt den (mechanischen) Schreib-/Lesekopf inkrementell bewegen.
-
wxSkip schrieb:
Befehlszeiger? Man muss halt den (mechanischen) Schreib-/Lesekopf inkrementell bewegen.
Das ist für mich trotzdem ein Zeiger, ändert ja nichts an dem Konzept..
-
cooky451 schrieb:
wxSkip schrieb:
Befehlszeiger? Man muss halt den (mechanischen) Schreib-/Lesekopf inkrementell bewegen.
Das ist für mich trotzdem ein Zeiger, ändert ja nichts an dem Konzept..
Dann sind aber auch die ints von SeppJ für den Arrayzugriff Zeiger.
-
wxSkip schrieb:
Dann sind aber auch die ints von SeppJ für den Arrayzugriff Zeiger.
Ja, klar.
SeppJ schrieb:
Argh. Verdammter Arrayzugriff
. Ja, da ist ein Zeiger in der Implementierung versteckt.
-
Nein, ich meinte, schon die ints selber werden relativ zum Arrayanfang als Zeiger (miss/ge)braucht (genau wie der Schreib-/Lesekopf bei meinem Beispiel). Danach ist sowieso Zeigerarithmetik involviert.
-
SeppJ schrieb:
2. Dafür würden sie komische Probleme bringen: Was soll zum Beispiel der Typ eines solchen Arrays sein und wann steht er fest? Auf diese Frage gibt es keine befriedigende Antwort und das in einer Sprache in der Typen dermaßen wichtig sind!
Frage am Rande: Wie wurde dies eigentlich in C99 gelöst?
Grüssli
-
Dravere schrieb:
Frage am Rande: Wie wurde dies eigentlich in C99 gelöst?
Die genauen Details müsste ich selber nachschlagen. Aber die C99 Umsetzung ist berühmt berüchtigt. Die Grundidee ist, dass die Arrays tatsächlich den Typ VLA haben. Solche Typen haben starke Einschränkungen, können unter anderem nicht in structs oder unions auftauchen und auch nicht extern sein (das gilt auch für Pointer auf diese Typen). sizeof funktioniert jedoch wie erwartet und wird zur Laufzeit ausgewertet. Auch typedefs sind möglich, diese werden dann auch zur Laufzeit ausgewertet, wenn der Programmfluss an dem typedef vorbei kommt.
Insgesamt recht kompliziert. Gefühlt jeder zweite Absatz im C99-Standard hat eine Sonderklausel für VLAs.
-
Am Anfang kam dieses eine Code-Beispiel. Hier mal eine andere Variante.
void verdoppeln(int &var) { var *= 2; } //[...] int test = 2; verdoppeln(test); // test = 4 //[...]Kann man da sagen, welche besser oder zu bevorzugen ist? Und wenn ja, warum?
-
Abgesehen von der natürlich besseren Benutzung von *=: Die Referenz. Ist lesbarer und es macht keinen Sinn, an eine Funktion dieser Art einen Nullzeiger zu übergeben, was der wichtigste Unterschied zwischen Referenzen und Zeigern wäre. Daher kann man es auch gleich ausschließen und hat so eine Fehlerquelle weniger.
-
Ist auch etwas schwierig zu beantworten, da das ein praxisfernes Beispiel ist. Die Referenz ist aus dem von SeppJ genannten Grund hier normalerweise zu bevorzugen, als Gegenargument könnte man sehen, dass eine Übergabe per Pointer deutlicher macht, dass die Funktion ihr Argument verändert. (Ebenso wie Pointerübergabe IMHO deutlicher machen kann, dass ein Argument polymorph verwendet wird)
-
wxSkip schrieb:
als Gegenargument könnte man sehen, dass eine Übergabe per Pointer deutlicher macht, dass die Funktion ihr Argument verändert.
Nö. Gibt wohl kaum was deutlicheres als eine Referenz auf non-const, um zu sagen "hey, ich verändere das Argument".
Gilt natürlich auch bei Pointern auf non-const, wobei Pointer zusätzlich besagen "Argument kann auch NULL sein".
Alternativ können Pointer natürlich auch C-Style bedeuten, wobei man sich dann auch auf const vs. non-const nicht mehr ernsthaft verlassen darf.wxSkip schrieb:
(Ebenso wie Pointerübergabe IMHO deutlicher machen kann, dass ein Argument polymorph verwendet wird)
Halte ich nicht für stichhaltig. Polymorphie funktioniert auf Referenzen genausogut wie auf Pointern. Ein Hinweis auf Polymorphie ist genau dann gegeben, wenn das Argument eine polymorphe Basisklasse ist - am Liebsten natürlich eine abstrakte.
-
@pumuckl: Dass die Funktion eine (nicht-konstante) Referenz nimmt, siehst du beim Aufruf aber nicht, nur bei Deklaration/Definition. Wenn du einen logisch sinnvollen Funktionsnamen/-aufruf hast, ist das aber sowieso unproblematisch.
-
wxSkip schrieb:
Dass die Funktion eine (nicht-konstante) Referenz nimmt, siehst du [...] nur bei Deklaration/Definition.
Und die kann man immer sofort sehen... (zumindest bei den neueren IDEs)
-
[Rewind] schrieb:
wxSkip schrieb:
Dass die Funktion eine (nicht-konstante) Referenz nimmt, siehst du [...] nur bei Deklaration/Definition.
Und die kann man immer sofort sehen... (zumindest bei den neueren IDEs)
Nix sofort. Bei jedem Funktionsaufruf den Mauszeiger dahin zu bewegen, auf den Tooltip zu warten und zu lesen ist bei weitem kein flüssiges Lesen von Quelltext.
"Sofort sehen" wäre, wenn die IDE Argumente für non-const Parameter irgendwie markieren oder einfärben würde. Und das kann die IDE meiner Wahl nicht.
