Diskussion:Variable (Programmierung)

Lexical vs. Dynamic Scope (erl.)

Den Abschnitt Scope and Extent vom englischen Artikel zu übersetzen wäre wichtig für Programmiersprachen, wie Common Lisp, Scheme oder auch Dylan und natürlich auch für das Gesamtverständnis.
(Der vorstehende Beitrag wurde von Boelthorn~dewiki, am 29.5.2006, um 12:11 [MESZ], abgesendet.)

Ja, genau! :-) Das unterste Perl Beispiel unter Lexical scope (unter Lexical vs. Dynamic) ist meiner Meinung nach sehr gut. Das bringt es auf den Punkt und ist hier relevant. Diese Seite beschreibt nur lexical scoping, was zwar das gebräuchlichere scoping ist, aber man sollte das nicht weglassen. Vielleicht baue ich das mal ein. --Overmann 13:40, 19. Okt. 2008 (CEST)

erledigt --Herbert Klaeren 14:19, 23. Okt. 2008 (CEST)

Definition vs. Deklaration (erl.)

Meiner Meinung nach wirft der Artikel die Begriffe Deklaration und Definition durcheinander, der Artikel ist nicht sehr exakt! Der Abschnitt "Speicher anfordern mit Variablendeklaration" ist ein Widerspruch in sich, bei einer Deklaration wird kein Speicher angefordert, sondern bei einer Definition. (nicht signierter Beitrag von 84.150.242.49 (Diskussion) )

Da hast du völlig recht. Und deshalb sei mutig und korrigiere den Artikel selbst. It's a wiki!. --jpp ?! 20:01, 2. Jul. 2007 (CEST) PS: Unterschreibe deine Diskussionsbeiträge bitte immer mit „--~~~~“.

erledigt --Herbert Klaeren 14:19, 23. Okt. 2008 (CEST)

Beugung des Wortes

Die Variable ist im deutschen ein substantiviertes Adjektiv -- eine variable Speicherstelle/Sache/..., kurz: die Variable. Dann ist aber auch der Plural im Nominativ "Variable": eine Variable, viele Variable.

Dinge, die variabel sind, sind Variable, und nicht "Variablen"!

Sollte der Artikel die IMO korrekte Beugung benutzen, oder die umgangsprachliche?

N: Variable (s), Variable (p); G: Variabler (s), Variabler (p); D: Variablen (s), Variablen (p); A: Variable (s), Variable (p)
(Der vorstehende Beitrag wurde ursprünglich von Dhuesken, am 6.9.2007, um 14:49 [MESZ], abgesendet und zuletzt über 134.2.187.44, am 7.9.2007, um 15:24 [MESZ], geändert.)

Für die Informatik ist es wichtig, zu wissen, ob man von einer Variablen spricht oder von Variablen im allgemeinen. Deswegen hat sich (im möglichen Gegensatz zur (neuen?) deutschen Rechtschreibung in der technischen Literatur der Plural die Variablen durchgesetzt. --Herbert Klaeren 18:05, 20. Okt. 2008 (CEST)

Speicher anfordern ohne Variablen (erl.)

Die Darlegung in diesem Absatz ist unsinnig. Speicher in den kleinen Größenordnungen von Variablen werden niemals beim Betriebssystem angefordert (Betriebssysteme sind Großhändler für Speicher); dafür ist ein Laufzeitsystem zuständig. Man nenne mir außerdem mal ein Sprachkonstrukt, mit dem man Speicher anfordern kann, ohne diesen an eine Variable zu binden. Überarbeitung ist nötig! --Herbert Klaeren 16:26, 17. Okt. 2008 (CEST)

Ja genau! Und die Speicherverwaltung ist doch nicht die Motivation für Variablen. Das ist doch falsch. --Overmann 15:15, 19. Okt. 2008 (CEST)

Dieser Mangel des Artikels ist inzwischen behoben --Herbert Klaeren 10:54, 23. Okt. 2008 (CEST)

Bitte überarbeiten, 2008

Also, ich habe erst jetzt den Anfang des Artikels gelsen. Um Gotteswillen. Den müssen wir aber nochmal neu schreiben. Das hört sichan, wie aus einem Lehrbuch abgeschrieben ohne verstanden worden zu sein. Hier stör ich mich dran:

• Speichermanagement ist die Motivation für Variablen (stimmt nicht: Variablen sind abstrakte Objeke, die ihren Wert zur Laufzeit eines Programms ändern können (oder auch nicht), auch nur mit Adressen und Zahlen habe ich Variablen, der Zugriff ist nur schwerer. Warum benötigt man Variablen in einem Compterprogramm. Ich tue mich schwer, das zu Beantworten. Warum braucht man Wasser im Tee. Weil da ohne Wasser kein Tee wär. :-))
• Alle Variablen haben einen Namen (stimmt nicht)
• Der Name einer Variablen ist die Variable (stimmt nicht)
• Deklaration fordert Speicher an (stimmt nicht)
• Generell teilweise geradezu lieblos unpräzise.

So, ich editier jetzt noch was.
(Der vorstehende Beitrag wurde von Overmann am 19.10.2008, um 15:28 [MESZ], abgesendet.)

hallo Overmann (ich nehme mal an, der letzte Eintrag war auch von dir, hast wohl das signieren vergessen...), ich hab den Anfang mal umformuliert, so dass er mehr Sinn ergibt, OK? Zu tun ist immer noch genug an dem Artikel. lg --Herbert Klaeren 21:55, 22. Okt. 2008 (CEST)

statisch ist nicht lexikalisch

Statische Variabeln sind lokale Variabeln, deren Inhalt bei allen Aufrufen behalten wird. Es gibt darüber hinaus eine statische Typisierung, Lexikalisch heißt nicht statisch. Leider ist diese Aussage im ganzen Artikel mehrfach vorhanden. Ich vermute da ist ein System dahinter. Vielleicht kann das jemand begründen, was an lexikalischem Gültigkeitsbereich statisch ist?

Mir scheint es auch, der Autor des Abschnitt verwechselt Gültigkeitsbereich und Typisierung. So wie die Begriffe im abschnitt "Sichtbarkeitsbereich von Variablen (Scope)" verwendet werden, deutet vieles darauf hin. --Struppi (Diskussion) 14:29, 24. Apr. 2012 (CEST)

(Zusätzlich eingefügte Zwischenüberschrift war:) Sichtbarkeit und Bindung werden durch schwache bis falsche Erklärungen miteinander vermengt

Ich möchte in dieselbe Kerbe hauen wie Struppi. Dann füge ich noch eine weitere hinzu. Die Aussage, dass dynamisches Binden `... dem Konzept des modularen Programmierens .... widerspricht ...`, erachte ich nicht nur als gewagt, sondern ich halte sie für falsch. Generell sollte der Artikel genau dort noch einmal gründlich überarbeitet werden, wo Sichtbarkeitskonzepte und Bindungsmechanismen zu halbverdautem Quark zusammengerührt sind. -- Pseliger (Diskussion) 13:46, 26. Sept. 2015 (CEST) (Beitrag nachträglich in die übliche Gliederung gebracht und zudem +Anmerkung zur Zwischenüberschrift. -- Abmühung, am 4.7.2019, um 6:40 [MESZ])

Wie sag ich's meinem Kinde?! (Eine didaktische Katastrophe...)

Leute...

Wer vom Konzept(!) einer Variablen noch keinen blassen Schimmer hat und deshalb darauf angewiesen ist, in Nachschlagewerken wie der Wikipedia genau dazu nachzuschlagen,...

...wird durch DIESEN Artikel ER-schlagen!

"Lamda-Kalkül"! "referentielle Transparenz"! Ey, geht's noch?!

Die MASSE der Leute, die diesen Artikel HÄTTEN brauchen können, sind Leute, die

1. KEINE Mathematiker sind
2. über einfache, imperative Programmiersprachen ins Programmieren einsteigen
3. beim Erblicken solcher emotionaler Zumutungen die Flucht ergreifen
4. dem Tutor zum Schluß auch noch die Schuld geben

Sowas nennt man einen didaktischen Vollpfosten!

Und da ich aus Lösch-Erfahrung gelernt habe, werde ich es mir klemmen, hier irgendwelche Verbesserungen anbringen zu wollen. Die Leute, die sowas verbrechen, müssen mit der Kritik leben oder Toleranz aufbringen lernen...

--White-Gandalf (Diskussion) 17:32, 3. Sep. 2012 (CEST)

Schimpfen und gleich festhalten, dass man selbst nix verbessern wird ist immer sehr hilfreich. --Sebastian.Dietrich ✉ 19:10, 3. Sep. 2012 (CEST)

Tut mir leid, ich würde es ja gerne, aber ich verstehe den Artikel (mit dem Lambda-Kalkül) nicht. So wird es sicherlich vielen gehen. Ein klassisches Henne-Ei-Problem.

--Henrik Haftmann (Diskussion) 14:57, 11. Okt. 2012 (CEST)

Du meinst den Satz "in einer rein funktionalen Programmiersprache sind Variablen einfach nur Bezeichner, das heißt sie werden wie im Lambda-Kalkül nur dazu verwendet, die Eingabeparameter für eine Funktion zu bezeichnen. Während der Berechnung eines Funktionswerts ändert sich der Wert der Variablen deshalb nicht. Ein Ausdruck mit Variablen hat stets den gleichen Wert, unabhängig davon, an welcher Stelle im Programm er auftritt. Diese Eigenschaft ist unter dem Begriff referentielle Transparenz bekannt." - was genau verstehst du daran nicht? Ich vermute du kommst nicht aus der funktionalen Programmierung und verstehst was ganz anderes unter Variable - aber das macht den Satz an sich mMn nicht unverständlich - oder?

Nimm z.B. das Beispiel Funktion f(n): ... - hier ist n eine Variable, die den Eingabeparameter benennt und innerhalb eines Funktionsaufrufes ihren Wert niemals ändert --Sebastian.Dietrich ✉ 17:11, 11. Okt. 2012 (CEST)

Ich kann Henrik und white-Gandalf nur zustimmen.

Dieser Abschnitt ist für ein Nachschlagewerk katastrophal schlecht. Das mag vielleicht den Akademiker, der Informatik studiert hat, erfreuen. Aber für einen Nichakademiker, ist es eine absolute Nullaussage.

Deine Erklärung des fraglichen Abschnitt ist verständlicher. Aber ich frage mich was diese mit dem Abschnitt zu tun hat? was ist das lambda Kalkül und warum wird n sich innerhalb der Funktion nie ändern? Wo steht das in dem Abschnitt? aber wieso sollte das so sein, alle Programmiersprachen die ich kenne, können diesen Wert ändern, insofern wäre diese Aussage auch falsch. Aber vielleicht habe ich auch einfach etwas falsch verstanden. Oder die Erklärung ist falsch.

--Struppi (Diskussion) 13:35, 19. Nov. 2012 (CET)

Ich vermute du kennst (wie viele) eben keine funktionalen Programmiersprachen (ich kenne sie auch nur ausm Studium). Nimm z.B. mal Lisp: (defun square (x) (* x x)) da ist x die Variable, die sich auf gar keinen Fall ändern darf. Die Funktion berechnet was basierend auf x, aber x bleibt immer gleich. Bei prozeduralen/OO Sprachen sollten Methodenparameter ja auch möglichst gleich bleiben (auch wenn sie bei call-by-reference geändert werde könnten). Bei x=9;y=sqrt(x) wär jeder überrascht, wenn danach x was anderes als 9 wäre.

Dass hier das Lambda Kalkül genannt wird liegt daran dass (meines verstaubten Wissens nach) die funktionalen Programmiersprachen genau darauf aufbauen. d.h. unbekannter Ausdruck, aber hier schon richtig verwendet. Funktionale Programmierung ist halt eine Welt für sich & ihre Konzepte schwer in je einem Absatz erklärbar. --Sebastian.Dietrich ✉ 14:05, 19. Nov. 2012 (CET)

wie schon gesagt, du erklärst es so, dass ich mit 30 jähriger (Hobby)Programmiererfahrung verstehe was gemeint sein könnte. Wenn ich den Artikel lese, verstehe ich gar nichts.

Obwohl diese Aussage, für mich anders klingt als deine Erklärung weiter oben: "Nimm z.B. das Beispiel Funktion f(n): ... - hier ist n eine Variable, die den Eingabeparameter benennt und innerhalb eines Funktionsaufrufes ihren Wert niemals ändert"

Dort steht, dass sich die Variabel n INNERHALB des Funktionsaurufs niemals ändert. Du meinst aber sie kann innerhalb der Funktion nicht so geändert werden, dass die Änderung aussen sichtbar ist. Das Konzept call-by-reference wird ja auch erklärt, wobei mir aber nicht klar ist, ob das mit dem kritisierten Abschnitt zusammenhängt.

Für mich ist nach wie vor der Abschnitt "Sichtweisen von Variablen" völlig unverständlich. Aber wenn das so sein muss, dann muss es so sein. Ich ging davon aus, dass wikipedia auch für Laien gedacht ist. In diesem Fall aber wohl eher weniger. --Struppi (Diskussion) 09:47, 29. Nov. 2012 (CET)

Es muss natürlich nicht so sein - ich persönlich trau es mir aber nicht zu diesen Absatz zu "erleichtern" - dafür bin ich von funktionaler Programmierung und theoretischer Informatik schon zu weit entfernt. Vielleicht findet sich ja wer... --Sebastian.Dietrich ✉ 13:07, 29. Nov. 2012 (CET)

Sichtbarkeit vs. Lebensdauer

Ist zwar bei den automatischen Variablen meistens gleichbedeutend, aber nicht immer. Ein praktisches Beispiel schafft Klarheit:

void irgendwas(const SYSTEMTIME *now) {
 if (!now) {			/* kein Zeitpunkt angegeben? */
  SYSTEMTIME st;		/* Platz auf dem Stapel */
  GetSystemTime(now=&st);	/* 'mal auf die Uhr gucken */
 }				/* Diese schließende Klammer zerstört st nicht */
 TueIrgendwas(now->wMinute);	/* now kann auf st zeigen und ist hier immer noch gültig */
}				/* Diese schließende Klammer zerstört st (weil Ende der Funktion) */

--Henrik Haftmann (Diskussion) 15:01, 11. Okt. 2012 (CEST)

Das obige Beispiel ist im Grunde so nicht kompilierbar, da der Parameter now const ist.

Davon abgesehen erlischt die Variable st am Ende des Gültigkeitsbereichs. Es kann nur darauf zugegriffen werden, weil sie auf dem lokalen Funktionsstack liegt und durch keine neue, lokale Variable überschrieben wurde.

Dieses Beispiel zeigt im Gegenteil nur, dass Pointer auch auf ungültige Speicherbereiche zeigen können. -- Plankton314 (Diskussion) 20:01, 11. Okt. 2012 (CEST)

Der neue Abschnitt "Arten von Variablen"

...ist ziemlicher Unfug. Klar kann man zwischen Wert- und Referenzvariablen unterscheiden. Aber letztere gibt es in C# etwa nur in Form von Funktionsparametern, in Java gar nicht, in C++ auch als Rückgabewert von Funktionen. Dass der wertmäßige Inhalt einer Variablen selbst eine Referenz sein kann, ist ein orthogonales Thema. Die C#-Spezifikation unterscheidet zu diesem Zweck Wert- und Referenztypen. Jeder Typ ist eins von beiden, bei der Deklaration einer Variablen hat man darauf aber keinen Einfluss. Umgekehrt hat diese Unterscheidung keine Auswirkung auf die Semantik von Variablen — sie sind einfach abstrakte Behälter von Werten, auf die man normalerweise, aber nicht zwingend, sowohl lesend als auch schreibend zugreifen kann.

Beispiel in C#, das beide "Referenz"-Arten gleichzeitig gebraucht:

void foo(ref int[] bar) {
    bar[3] = 42;  // mit "out" statt "ref" compiletime-illegal
    bar = null;   // mit "in"  statt "ref" compiletime-illegal
}
void fooCaller() {
    int[] tenInts = new int[10];
    int[] shallowCopy = tenInts;
    tenInts[4] = 4711;
    foo(ref tenInts);
    // shallowCopy[3] ist jetzt 42, shallowCopy[4] ist 4711, tenInts ist null.
}

--77.179.86.221 00:25, 2. Aug. 2014 (CEST)

Welchen Mehrwert haben hier englischsprachige Bezeichner?

Hallo, mir ist aufgefallen daß vorgestern (also am 2.7.2019) eigentlich frei benennbare Bezeichner (siehe dazu ggf. auch unter selbsterklärender Variablenname; auch dauerhaft[er], im Zieleintrag, mit dort letzter Änderung am 11.6.2019) hier, in der doch eigentlich deutschsprachigen Wikipedia, meiner Ansicht nach unnötigerweise ins Englische (zurück?) übersetzt wurden. An den Verfasser dieser Änderung, am Eintrag ‚Variable (Programmierung) (nebenan): Welchen Mehrwert sollen bitte deine (Rück?)Übersetzungen bringen. Im Übrigen gibt es hier (im MediaWiki) auch sowas wie eine Zusammenfassung, wo du besonders solche (wenigstens mir sehr unverständlichen) Änderungen eben kurz zusammenfassen (oder auch erklären) könntest. Im Sinne einer guten Zusammenarbeit, mit lieben Grüßen. -- Abmühung, am 4.7.2019, um 7:40 (MESZ)

JavaScript scheint hier eher ungeeignet, als Beispiel für dynamisch typisierte Sprachen

Hallo nochmal, also das Beispiel nebenan, genauer unter der dortigen Abschnittsüberschrift Typen von Variablen, zu den (angeblich) dynamisch typisierten Programmiersprachen, erscheint mir doch eher ungeeigent zu sein, um als Beispiel für dynamisch typisierte Sprachen zu dienen. Soweit mir das bekannt ist, ist (oder war) JavaScript (wenigstens in seiner Anfangszeit) eigentlich (eher) untypisiert oder anders ausgedrückt, alle aufgenommenen Werte wurden (und werden?) grundsätzlich als Zeichenfolge verarbeitet – was ja im genannten Beispiel auch schon durch die dortige Wenn-Abfrage, mit ‚if (typeof wert === 'number')‘, wenigstens angedeutet wird. Wäre da ein treffenderes Beispiel dann nicht besser mit VB6 (oder früher oder allgemeiner mit VB-Classic) auszuwählen? Dort gab es nämlich sowas wie den sogenannten Variant (siehe auch unter der gegenwärtig gleichnamigen BKL Variant), was der sogenannten dynamischen Typisierung wohl eher entsprechen würde. -- Abmühung, am 4.7.2019, um 7:40 (MESZ)

Tatsächlich sind alle JavaScript-Variablen Variant, um in der VB-Nomenklatur zu bleiben.

x = 3;
x = "Drei";
x = false;

Nach der ersten Zeile hat x den typeof number, nach der zweiten string und ist nach der dritten boolean.

Dass JavaScript alles vom Typ Zeichenkette verwerten würde, müsste schon seeehr lange her sein und die allererste Version meinen, vielleicht noch bevor die das Parsen erfunden hatten. Ich kann mich erinnern, dass ich im letzten Jahrhundert kleine Gimmicks in Webseiten eingebaut hatte, und dabei in Schritten zu 50 Millisekunden numerisch addiert hatte, um neckische Text-Animationen winken zu lassen.

Was hingegen alles „grundsätzlich als Zeichenfolge verarbeitet“, ist die Vorlagenprogrammierung hier in diesem Wiki.

VG --PerfektesChaos 14:54, 4. Jul. 2019 (CEST)

Sichtbarkeit vs Gültigkeit

Die Begriffe Sichtbarkeit und Gültigkeit scheinen hier synonym und beinahe abwechselnd verwendet zu werden, ohne dass erwähnt wird, dass sie wirklich synonym sind. (nicht signierter Beitrag von Henning1000 (Diskussion | Beiträge) 11:03, 13. Jan. 2021 (CET))

Welche Stelle meinst Du? Sichtbar und gueltig sind nicht synonym. In "C" kannst du munter Zeigervariablen definieren, die sind sichtbar, aber - wenn nicht initialisiert - ganz sicher nicht gueltig (und ein "Dereferenzieren" einer solchen Zeigervariable ist idR fatal). MfG -- Iwesb (Diskussion) 11:16, 13. Jan. 2021 (CET)

Liste/Tabelle mit allen Variablentypen

Sollte man mal eine Liste oder Tabelle anfangen, mit allen Variablen, deren Platz und Art (Text, Zahl,....)? --Der Älteste (Diskussion) 20:53, 16. Dez. 2021 (CET)

Das steht hier: Datentyp#Elementare_Datentypen. --Bautsch 00:40, 17. Dez. 2021 (CET)