1. Foren
  2. Kommentare
  3. Software-Entwicklung-Forum
  4. Alle Kommentare zum Artikel
  5. › Programmiersprache…

Lokale Kopien von Funktionsparametern

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema


  1. Lokale Kopien von Funktionsparametern

    Autor: WurstCase 28.09.17 - 16:28

    "In Kotlin gilt die Konvention, möglichst immer alle genutzten Variablen auch tatsächlich als var zu definieren. Das betrifft auch die übergebenen Parameter, die der Rumpf von ggt() daher für die Berechnung in die Variablen a und b kopiert."

    Was ist denn genau der Vorteil dieser Konvention, Funktionsparameter innerhalb der Funktion in neue lokale Variablen zu kopieren? Und wie ist der erste Satz genau zu verstehen? Können Variablen/Konstanten auch anders (ohne var/val) deklariert werden, abgesehen von der Funktionsparameterliste?

  2. Re: Lokale Kopien von Funktionsparametern

    Autor: Nocta 29.09.17 - 10:49

    Ich habe noch nie Kotlin benutzt, aber ich verstehe das so, dass Variablen die man verändert, eben var sein müssen. Wenn man nun alle Variablen, die man tatsächlich in der Funktion verändert als var definiert, und den Rest als val hat man drei Vorteile:

    1) Der Compiler kann den Code mit "val" Werten ähnlich zu dem "const" Qualifier in anderen Sprachen besser optimieren.
    2) Der Nutzer weiß, dass die val Werte konstant sind und sich nicht ändern und der Nutzer weiß, dass sich alle anderen Variablen ändern werden (bzw ändern können) und er davon ausgehen muss, dass sie nach dem Funktionsaufruf tatsächlich andere Werte enthalten.
    3) Es werden nur Werte kopiert, die auch kopiert werden müssen, was einen minimalen Speicher und Geschwindigkeitsvorteil bieten sollte.

    Soweit jedenfalls aus meinem allgemeinen Verständnis heraus, von Kotlin speziell habe ich keine Ahnung.

  3. Re: Lokale Kopien von Funktionsparametern

    Autor: Das Osterschnabeltier 29.09.17 - 11:34

    Nocta schrieb:
    --------------------------------------------------------------------------------
    > Ich habe noch nie Kotlin benutzt, aber ich verstehe das so, dass Variablen
    > die man verändert, eben var sein müssen. Wenn man nun alle Variablen, die
    > man tatsächlich in der Funktion verändert als var definiert, und den Rest
    > als val hat man drei Vorteile:
    >
    > 1) Der Compiler kann den Code mit "val" Werten ähnlich zu dem "const"
    > Qualifier in anderen Sprachen besser optimieren.
    > 2) Der Nutzer weiß, dass die val Werte konstant sind und sich nicht ändern
    > und der Nutzer weiß, dass sich alle anderen Variablen ändern werden (bzw
    > ändern können) und er davon ausgehen muss, dass sie nach dem
    > Funktionsaufruf tatsächlich andere Werte enthalten.
    > 3) Es werden nur Werte kopiert, die auch kopiert werden müssen, was einen
    > minimalen Speicher und Geschwindigkeitsvorteil bieten sollte.
    >
    > Soweit jedenfalls aus meinem allgemeinen Verständnis heraus, von Kotlin
    > speziell habe ich keine Ahnung.

    Zu 1: Jeder vernünftige Compiler hat heute Constant Propagation und findet das auch selber heraus.

  4. Re: Lokale Kopien von Funktionsparametern

    Autor: MoonShade 30.09.17 - 11:16

    Andere Sprachen wie Skala halten das genauso mit der Konvention. Zitat aus Learning Skala:

    > For most languages [...] [using variables] is the typical pattern for working with named, assignable memory storage. [...] In Skala, values are preferred over variables by convention, due to the stability and predictability they bring to source code.

    > When you define a value you can be assured that it will retain the same value regardless of any other code that may access it. Reading and debugging code is easier when a value assigned at the beginning of a code segment is unchanged through the end of the code segment.

    > Finally, when working with data that may be available for the life span of an application, or accessible from concurrent or multithreaded code, an immutable value will be more stable and less prone to errors than mutable data that may be modified at unexpected times.

  5. Re: Lokale Kopien von Funktionsparametern

    Autor: tomate.salat.inc 30.09.17 - 12:15

    WurstCase schrieb:
    --------------------------------------------------------------------------------
    > Was ist denn genau der Vorteil dieser Konvention, Funktionsparameter
    > innerhalb der Funktion in neue lokale Variablen zu kopieren?

    Weil sich Parameter nicht ändern sollten. Besonders drastisch ist das, wenn du mit Code zu tun hast, wo Methoden gerne mal > 100 Zeilen lang sind. Das an sich ist schon sehr kacke. Besonders blöd wirds dann, wenn du die Methode erweitern darfst und sich irgendwo dazwischen in einem if plötzlich der Wert des Parameters ändert. Das ist dann im besten Fall noch ein Edge-Case --> BUG!

  6. Re: Lokale Kopien von Funktionsparametern

    Autor: horotab 05.10.17 - 11:09

    Wer Methoden schreibt, die so lang sind, mach idR sowieso etwas falsch. Im Idealfall hat jede Methode genau eine Aufgabe, das ist eine saubere Struktur die auch einfach zu Debuggen ist.

  1. Thema

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. DevOps System Engineer (w/m/d)
    DENIC eG, Frankfurt am Main
  2. Systemverantwortlicher (m/w/d) Modul - Ultrasonic Parking Functions
    IAV GmbH, Berlin, Chemnitz, Gifhorn
  3. Leitung der Stabsstelle IT und Digitalisierung (m/w/d)
    Kunstakademie Münster, Münster
  4. Senior Engineer Software Architecture (m/w/d)
    Continental AG, Frankfurt am Main

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (u. a. Project Wingman für 16,99€, The Wild Heart für 15,99€, Crying Suns für 6,99€)
  2. 27,99€ statt 49,99€
  3. gratis (bis 26. Mai)


Haben wir etwas übersehen?

E-Mail an news@golem.de