Abo
  1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Programmiersprache für…

Lokale Kopien von Funktionsparametern

  1. Thema

Neues Thema Ansicht wechseln


  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.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Dataport, Bremen, Berlin, Magdeburg, Hamburg, Rostock, Altenholz bei Kiel, Halle (Saale)
  2. THE BRETTINGHAMS GmbH, Berlin
  3. ALDI International Services GmbH & Co. oHG, Mülheim an der Ruhr
  4. OEDIV KG, Bielefeld

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 72,99€ (Release am 19. September)
  2. 245,90€ + Versand


Haben wir etwas übersehen?

E-Mail an news@golem.de


Physik: Den Quanten beim Sprung zusehen
Physik
Den Quanten beim Sprung zusehen

Quantensprünge sind niemals groß und nicht vorhersehbar. Forschern ist es dennoch gelungen, den Vorgang zuverlässig zu beobachten, wenn er einmal angefangen hatte - und sie konnten ihn sogar umkehren. Die Fehlerkorrektur in Quantencomputern soll in Zukunft genau so funktionieren.
Von Frank Wunderlich-Pfeiffer


    Webbrowser: Das Tracking ist tot, es lebe das Tracking
    Webbrowser
    Das Tracking ist tot, es lebe das Tracking

    Die großen Browserhersteller Apple, Google und Mozilla versprechen ihren Nutzern Techniken, die das Tracking im Netz erschweren sollen. Doch das stärkt Werbemonopole im Netz und die Methoden verhindern das Tracking nicht.
    Eine Analyse von Sebastian Grüner

    1. Europawahlen Bundeszentrale will Wahl-O-Mat nachbessern
    2. Werbenetzwerke Weitere DSGVO-Untersuchung gegen Google gestartet
    3. WLAN-Tracking Ab Juli 2019 will Londons U-Bahn Smartphones verfolgen

    Digitaler Knoten 4.0: Auto und Ampel im Austausch
    Digitaler Knoten 4.0
    Auto und Ampel im Austausch

    Auf der Autobahn klappt das autonome Fahren schon recht gut. In der Stadt brauchen die Autos jedoch Unterstützung. In Braunschweig testet das DLR die Vernetzung von Autos und Infrastruktur, damit die autonom fahrenden Autos im fließenden Verkehr links abbiegen können.
    Ein Bericht von Werner Pluta

    1. LTE-V2X vs. WLAN 802.11p Wer hat Recht im Streit ums Auto-WLAN?
    2. Vernetztes Fahren Lobbyschlacht um WLAN und 5G in Europa
    3. Gefahrenwarnungen EU setzt bei vernetztem Fahren weiter auf WLAN

    1. Videostreaming: Netflix und Amazon Prime Video locken mehr Kunden
      Videostreaming
      Netflix und Amazon Prime Video locken mehr Kunden

      Der Videostreamingmarkt in Deutschland wächst weiter. Vor allem Netflix und Amazon Prime Video profitieren vom Zuwachs in diesem Bereich.

    2. Huawei: Werbung auf Smartphone-Sperrbildschirmen war ein Versehen
      Huawei
      Werbung auf Smartphone-Sperrbildschirmen war ein Versehen

      Besitzer von Huawei-Smartphones sollten keine Werbung mehr auf dem Sperrbildschirm sehen. Der chinesische Hersteller hatte kürzlich Werbebotschaften auf seinen Smartphones ausgeliefert - ungeplant.

    3. TV-Serie: Sky sendet Chernobyl-Folge mit Untertiteln einer Fanseite
      TV-Serie
      Sky sendet Chernobyl-Folge mit Untertiteln einer Fanseite

      Der Pay-TV-Sender Sky hat die Serie Chernobyl in der Schweiz mit Untertiteln ausgestrahlt, die von einer Fan-Community erstellt wurden. Wie die inoffiziellen Untertitelspur in die Serie gelangt ist, ist unklar.


    1. 12:24

    2. 12:09

    3. 11:54

    4. 11:33

    5. 14:32

    6. 12:00

    7. 11:30

    8. 11:00