Halli hallo, bitte verzeiht mit die doofe Frage. ich lese mich grade in die Deklaration von Variablen mit uint8_t usw. ein und verstehe auch welche deklaration bei welchem variablentyp am besten passt. Allerdings ist mir nicht ganz klar warum man diese Variabel nun mit einem bestimmten Datentyp deklariert. Sag ich dem Compiler damit nur wie groß die Variabel wird oder hat das noch einen anderen zweck? Und kann man eine Variabel auch ohne Deklaration initialisieren? Danke schonmal bis dann.
Graum schrieb: > Allerdings ist mir > nicht ganz klar warum man diese Variabel nun mit einem bestimmten > Datentyp deklariert. Man muss die Deklarier, dass der Compiler weiß, dass es sie gibt, wie groß sie ist, ober er die Bits als signed, unsigend Ganzzahl oder Flieskomma betrachten muss.
Damit der Compiler weiß, wie viel Speicherplatz er reservieren soll. Und was Operationen mit der Variablen tun sollen: zB die Multiplikation eines "int" ist grundverschieden von der eines "float", und auf einem "char*" geht sie gar nicht. Graum schrieb: > Und kann man eine Variabel auch ohne Deklaration initialisieren? Du kannst sie höchstens in einem Schritt definieren & initialisieren:
1 | int x = 7; |
Für den Compiler ist nicht ersichtlich welcher Datentyp am optimalsten für das Speichern von Ergebnissen herhalten kann. Eine 8 kann in einem Char/Int/Short oder sonstwo Platz finden, aber beim Rechnen damit schon Über/-Unterlaufen. Da liegt die Verantwortung beim Programmierer den optimalen Typ vorher dem Compiler durch Deklarierung mitzuteilen. Die andere Variante ist der z.B. Datentyp Variant aus VB. Dieser wird ggf. angepasst und hin- und herkonvertiert bei Bedarf, was aber Rechenzeit frist und nur Aufwändiger im Speicher dargestellt werden kann und unterschiedlicher Behandlung bedarf beim Rechnen damit.
Graum schrieb: > Sag ich dem Compiler damit nur wie groß die Variabel wird oder hat das > noch einen anderen zweck? Jein, denn *kopfkratz*: 1. Du deklariest den Variablennamen ohne den der Compiler nix anfangen kann 2. Du deklariest den Variablentyp, Ganzzahl, Gleitzahl, String usw. 3. Du deklariest damit auch die maximale Größe int, float, char usw. 4. Du initialisierst die Variable sinnvollerweise bei der Deklaration Und wenn Du nun ein gutes Assembler, BASIC, C/C++, EIFFEL, FORTRAN, PASCAL usw. Buch hättest würde das da drin stehen, daher kaufen :-P Und die Größe von z.B. int, long usw. hängt von der aktuellen Architektur ab, das kann 8bit, 16bit, 32bit, 64bit usw. usf. sein. Nebenbei gibt's auch wiki & Co. und Suchen scheint auch irgendwie nicht mehr üblich zu sein: http://de.wikipedia.org/wiki/Deklaration_%28Programmierung%29 Ich empfehle Dir ein gutes Buch zu der Programmiersprache mit der Du arbeitest !
kopfkratzer schrieb: > Graum schrieb: >> Sag ich dem Compiler damit nur wie groß die Variabel wird oder hat das >> noch einen anderen zweck? > > Jein, > denn *kopfkratz*: > 1. Du deklariest den Variablennamen ohne den der Compiler nix anfangen > kann > 2. Du deklariest den Variablentyp, Ganzzahl, Gleitzahl, String usw. > 3. Du deklariest damit auch die maximale Größe int, float, char usw. > 4. Du initialisierst die Variable sinnvollerweise bei der Deklaration 5. Es wird definiert in welchem Bereich die Variable gültig ist und Fallabhängig der Speicherbereich (Heap oder Stack) definiert.
Graum schrieb: > oder hat das > noch einen anderen zweck? Um klare Verhältnisse zu schaffen: dass es diese Variable gibt und welchen Typ sie hat. Es gibt auch Programmiersprachen (Basic), da können Variablen einfach aus dem Nichts auftauchen, aber das ist SEHR fehleranfällig, etwa wenn man X1 berechnet hat, und dann an einer späteren Stelle aus Vergesslichkeit mit X weiterrechnet - in Basic zulässig, gibt aber Blödsinn, in den meisten "ordentlichen" Programmiersprachen ein Compiler-Fehler, weil X nicht deklariert ist. Georg
Graum schrieb: > Und kann man eine Variabel auch ohne Deklaration initialisieren? Der gesamte Speicherbereich ist in einzelne "Zellen" aufgeteilt (z.B. 1 Byte pro Zelle = byteweise Adressierung). Jede dieser Zellen hat eine Adresse. Das ist quasi wie ein großer Schrank mit vielen Fächern, wobei alle diese Fächer durchnummeriert sind. Hast du kein Fach im Schrank, so kannst du dort auch nichts ablegen - ohne Deklaration existiert deine Variable nicht und kann auch nicht initialisiert werden. Hast du dagegen ein Fach im Schrank "zugewiesen" bekommen, so kannst du dort jederzeit etwas ablegen. Aber eben nicht alles: Es wäre dort bestimmt genug Platz für ein Buch, aber sicherlich nicht genug Platz für ein Fahrrad.
Solange die hellseherischen Fähigkeiten der üblichen Compiler eher mangelhaft sind, wirst Du dem (indirekt) Teil sagen müssen was Sache ist. Das fängt schon bei so einfachen Sachen wie einer Kopieraktion also Var1 = Var2 an. Muss hier ein Byte, zwei Bytes oder wie viele kopiert werden? Bedenke, dass z. B. unmittelbar hinter Var2, Var3 anfängt, die nicht mitkopiert werden soll. Das geht mit der unterschiedlichen, internen Darstellung von Werten weiter. Eine 8-bit Zahl wird anders als eine 16-bit Zahl addiert, subtrahiert u.s.w. Die interne Darstellung einer Fließkommazahl ist völlig anders als die einer aus integer-Fraktion. Hast Du z.B. uint8_t Var1, Var2, Var3; und double Var4, Var5, Var6; so kannst Du einfach: Var1 = Var2 + Var3; und Var4 = Var5 + Var6; schreiben. Trotzdem die Behandlung, unter der Oberfläche, völlig anders ist. Der Compiler weis was zutun ist.
Oha.. vielen dank für die zahlreichen Antworten und sehr guten Erklärungen. Jetzt ist mir einiges klar geworden ;-)
@Georg, in Bezug auf Basic: Nenne doch mal ein Basic-Dialekt, wo das so möglich ist .... CBRler
Amateur schrieb: > Solange die hellseherischen Fähigkeiten der üblichen Compiler eher > mangelhaft sind, wirst Du dem (indirekt) Teil sagen müssen was Sache > ist. Die "hellseherischen Fähigkeiten" existieren schon seit Ende der Siebziger: http://de.wikipedia.org/wiki/Typinferenz_nach_Hindley-Milner Seit den Achtzigern setzen das Compiler für "richtige" Sprachen auch um.
Hi Um deine Klarheit mal ein wenig zu trüben... du deklarierst nicht wirklich Variablen, sondern legst eine Adresstabelle an. Ich denke, das ist in C nicht viel andersals in Assembler. Nur das C etwas mehr Informationen dazupackt, eben das Format der dort erwarteten Daten. Und dieses Format wird in der Deklaration mitgegeben. So weiß der Compiler, immer wenn er ein a im Quellcode liest, aus wieviel Bytes dieses a besteht und wie der Inhalt zu behandeln ist. Auch, wo er die Adresse von einer danach anzulegenden Variablen die Adresse b findet. Ist a ein Byte groß, ist b im Speicherplatz direkt dahinter. Ist es eine Float dann eben 4 oder gar 8 Speicherpläte weiter hinten. Wie du siehst, eine Variable ist nicht einfach nur eine Variable... Gruß oldmax
Hi @CBRler Wenn du schon 1980 mit Basic gespielt hättest, würdest du die Frage nicht stellen. Hättest du jetzt gesagt Basic Compiler, wär die Frage berechtigt gewesen, aber in den 80gern waren noch viele Interpreter unterwegs und die konnten fast alle solch Variablengedöns ohne Deklaration. Die haben einfach genommen, was kam. Gruß oldmax
Fortran konnte das ebenfalls. Variablen implizit definieren, wobei in diesem Fall auch noch der erste Buchstabe des Variablennamens für den zu verwendenden Datentyp herangezogen wurde. Was auf den ersten Blick für uns Jungspunde wie ein Segen aussah, entpuppte sich schnell als erstklassige Fallgrube für schwer zu findende Fehler durch Tippfehler. Hatte man das erst mal begriffen dann begann jede Fortran Source erst mal mit einem IMPLICIT NONE, um diese Typisierungsautomatik abzustellen. In Summe ging das erzwungene Typisieren alle Variablen deutlich schneller als das Suchen von Fehlern, die auf irgendwelche Tippfehler und damit implizit definierten Variablen zurückgingen.
> entpuppte sich schnell als erstklassige Fallgrube
Und doch wird deiser fundamentale Fehler immer wieder wiederholt, zum
Beispiel in Java Frameworks mit Reflection.
Ständig gibt es neue Programmiersprachen und Frameworks, die angeblich
alles einfacher und schneller machen, indem sie unter anderem auf
Deklarationen verzichten. An deren Entwicklung sind offensichtlich zu
viele Menschen ohne ausreichende Programmiererfahrung beteiligt.
stefanus schrieb: >> entpuppte sich schnell als erstklassige Fallgrube > > Und doch wird deiser fundamentale Fehler immer wieder wiederholt, zum > Beispiel in Java Frameworks mit Reflection. > Deswegen muß man bei Reflection (egal ob JAVA, .NET o.ä.) das auch IMMER via
1 | try
|
2 | {
|
3 | "Reflectionaufruf"
|
4 | }
|
5 | catch "Nixgefunden" |
erledigen. Schlimmer geht aber immer, wenn man z.B. einen Code hat der selbstverändernd ist. > Ständig gibt es neue Programmiersprachen und Frameworks, die angeblich > alles einfacher und schneller machen, indem sie unter anderem auf > Deklarationen verzichten. An deren Entwicklung sind offensichtlich zu > viele Menschen ohne ausreichende Programmiererfahrung beteiligt. Die meisten "neuen" Programmiersprachen werden ja nicht unbedingt wegen der besseren Wartbarkeit geschrieben, sondern um einen bestimmten Fall zu optimieren bzw. zu vereinfachen, siehe z.B. RUBY ... Und wenn ich an JAVASCRIPT denke O.o ...
CBRler schrieb: > in Bezug auf Basic: Nenne doch mal ein Basic-Dialekt, wo das so möglich > ist .... Das ist bei praktisch allen "richtigen" Basics so. Beispiele: - Applesoft Basic - C64 Basic - GW-Basic - QuickBasic/QBasic - Blassic - YaBasic - ... In all diesen Basics hat eine nicht explizit initialisierte Variable automatisch den Wert 0 (bzw. "" bei Strings). oldmax schrieb: > Wenn du schon 1980 mit Basic gespielt hättest, würdest du die Frage > nicht stellen. Ja, die obigen Beispiele stammen großteils aus den 80er- und 90er-Jahren, es gibt aber auch neuere Exemplare, wie Blassic und YaBasic zeigen. > Hättest du jetzt gesagt Basic Compiler, wär die Frage berechtigt > gewesen, aber in den 80gern waren noch viele Interpreter unterwegs und > die konnten fast alle solch Variablengedöns ohne Deklaration. Auch damals gab es schon für die meisten Rechner (bspw. Apple, Commodore und CP/M-Rechner) zu den jeweiligen Basic-Interpretern kompatible Compiler, die deswegen ebenfalls ohne Variablendeklarationen auskamen. Das, was heute als Basic verkauft wird (bspw. Visual Basic .NET) hat mit dem, was ursprünglich einmal Basic war, nicht mehr viel mehr als den Namen gemeinsam.
stefanus schrieb: > Ständig gibt es neue Programmiersprachen und Frameworks, die angeblich > alles einfacher und schneller machen, indem sie unter anderem auf > Deklarationen verzichten. An deren Entwicklung sind offensichtlich zu > viele Menschen ohne ausreichende Programmiererfahrung beteiligt. Bei diesen "neuen", deklarationsarmen Sprachen muss man allerdings zwei Fälle unterscheiden: - Dynamische Typisierung: Die ist in der Tat sehr fehleranfällig, erlaubt aber in kleineren Softwareprojekten trotz dieses Mankos kürzere Entwicklungszeiten. Darauf beruht bspw. der Erfolg von Python und Ruby. Wer solche Sprachen für Monsterprojekte einsetzt, muss mit den Folgen leben. - Statische Typisierung mit Typinferenz statt Deklarationen: Siehe auch Michael schrieb: > Die "hellseherischen Fähigkeiten" Die Probleme der dynamischen Typisierung gibt es hier nicht, da sämtliche Typfehler zur Compile-Zeit aufgedeckt werden. Es ist nur nicht ohne weiteres möglich, Typinferenz auf bestehende Typsysteme nachträglich aufzusetzen, deswegen gibt es sie in den meisten etablierten Sprachen nicht. In C++ und C# wurde Typinferenz zwar vor einiger Zeit eingeführt, ihre Anwendungsmöglichkeiten sind aber sehr eingeschränkt. Bei Haskell hingegen sind Typsystem¹ und -inferenz zusammen entwickelt worden und deswegen aus einem Guss. Das heißt aber nicht, dass es keine Deklarationen gibt: Sie können optional verwendet werden und sind in einigen Fällen auch sehr sinnvoll. ——————————— ¹) Mit eines der mächtigsten, wenn nicht sogar das mächtigste, das es derzeit gibt.
CBRler schrieb: > in Bezug auf Basic: Nenne doch mal ein Basic-Dialekt, wo das so möglich > ist .... Das war in allen Basic Versionen der "ersten Stunde". Es gab sogar einen uC mit eingebautem Basic-Interpreter: 8052AH BASIC
Lothar Miller schrieb: > Das war in allen Basic Versionen der "ersten Stunde". Das war eben basic Basic, und das war auch genauso gewollt, um den User nicht mit sowas kompliziertem wie Deklarationen zu behelligen. For i = usw usw Next i war völlig ausreichend als Programm, Nebenwirkungen mit einem "anderen" i musste man selbst verantworten. Ich beschäftige mich nicht mehr mit Basic, aber ich hätte vermutet, dass das im Rahmen der Kompatibilität auch heute noch funktioniert. Dass man Objekte oder DLL-Funktionen deklarieren muss, steht ja auf einem anderen Blatt, aber nicht einfache Variablen wie i,x,y . Man könnte natürlich auch der Meinung sein, heutige Versionen wie VB.net wären Verrat an der ursprünglichen Einfachheit. Georg
Georg schrieb: > Ich beschäftige mich nicht mehr mit Basic, aber ich hätte vermutet, dass > das im Rahmen der Kompatibilität auch heute noch funktioniert. Der Rahmen der Kompatibilität war und ist bei Basic infinitesimal schmal. So akzeptieren die meisten neueren Basic-Compiler auch keine Zeilennummern mehr. > Man könnte natürlich auch der Meinung sein, heutige Versionen wie VB.net > wären Verrat an der ursprünglichen Einfachheit. VB.Net ist eigentlich C# mit einer – von Weitem betrachtet – basic-ähnlichen Syntax. Um .Net möglichst breit unters Volk zu streuen, hatte MS den genialen Einfall, die gleiche Sprache in zwei unterschiedlichen Gewändern für unterschiedliche Anwendergruppen anzubieten: - C# für alle selbsternannten Profiprogrammierer, die sagen "Basic, pfui, das ist doch etwas für Loser und Spaghettiprogrammierer" - VisualBasic.Net für alle Anfänger, die sagen "C#, bäh, das hört sich an wie C und ist nur etwas für Masochisten und Kryptologen" So kann jede dieser beiden Anwendergruppen über die jeweils andere herzlich lästern, ohne zu merken, dass sie im Endeffekt genau gleich programmieren ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.