3. Wozu immer Zeiger?

Wozu immer Zeiger?

  • C

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

    0
  • W

    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.

    0
  • C

    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.

    0
  • W

    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.

    0
  • Administrator

    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

    0
  • Mod

    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.

    0
  • *

    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?

    0
  • Mod

    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.

    0
  • W

    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)

    0
  • P

    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.

    0
  • W

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

    0
  • *

    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)

    0
  • ?

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

    0
  • *

    Die IDE meiner Wahl zeigt alle Argumente bereits bei der Eingabe des Funktionsaufrufs und das ist "sofort".

    0
  • W

    Code::Blocks zeigt die Argumente manchmal bei der Eingabe und beim Lesen natürlich nicht.

    0

  • @[Rewind]:
    Während man Code schreibt, kann man mit allem möglichen mehr oder weniger gut zurecht kommen.

    Aber was macht man beim Lesen von Code? Beim Suchen von Fehlern?

    Viel zu viele Programmierer machen sich darüber viel zu wenig Gedanken, und erzeugen viel zu viel schrecklichen Code.

    0
  • *

    Da bleibt wohl nichts anderes übrig als die Maus zu bemühen.

    0
Anmelden zum Antworten