Thomas M. schrieb: > Habe schon oft gelesen C sei gut für hardwarenahes Programmieren, > gerade auch für Mikrocontroller. Es ist zumindest überall vorhanden und, das behaupte ich mal unbegründet, mindestens so gut wie die Alternativen. > Aber die paar wenigen Mikrocontroller, die ich bisher > in die Finger bekommen hatte, waren allesamt Havard Architekturen. Intern dürften die meisten modernen Prozessoren Harvard-Architekturen sein, das ist nicht nur auf Controller beschränkt. Aus Sicht des Programmierers geht man aber davon weg (siehe z.B. ARMs Cortex-M). > Und für mehrere Addressräume auf verschiedenen > Bussystemen hat C nun mal nichts in der Trickkiste. Wenn man genügend Bits bezahlen kann und will, geht man zu flachen Adressräumen über. Niemand nutzt mehr Segmentierung, MMIO hat sich auch durchgesetzt und bis auf die kleinen 8- und 16-Bit-Architekturen hat sich das Problem erledigt. Damit sinkt auch der Bedarf nach passenden Sprachen. Mir ist grundsätzlich keine Sprache bekannt, die mit getrennten Adressräumen wirklich gut umgehen könnte. An den Stellen springen dann die Compiler ein, z.B. hat SDCC brauchbaren Support für Banking, avr-gcc kennt __flash und __eeprom und die Kommerzcompiler wissen auch damit einigermaßen umzugehen. Das Hauptproblem ist, dass der Programmierer die Aufteilung des Problems in verschiedene Adressräume selbst vornehmen muss. Ob er das im Linker oder im Compiler macht, ist relativ egal, aber es ist umständlich.
S. R. schrieb: > Mir ist grundsätzlich keine Sprache bekannt, die mit getrennten > Adressräumen wirklich gut umgehen könnte. Mir auch nicht, und das wäre für eine Hochsprache auch nicht wirklich sinnvoll. Die Konsequenz wäre dann doch, daß man eine hardwareabhängige Hochsprache hätte, was ein Widerspruch in sich ist. Hochsprachen sollen sowas gerade abstrahieren. Das ist auch der Grund, wieso das auch in C etwas krampfig ist. Zuende gedacht hätte eine Sprache, die mit Hardwareabhängigkeiten und den tollen neuen CPU-Features von W.S. zugestopft ist, vor allem zur Folge, daß sie nicht portabel wäre. Man könnte also nicht cross-platform entwickeln, testbeds wären nicht möglich, Migrationspfade wären von vornherein verschlossen, und bestehende Software könnte man auch komplett neu schreiben. Das wäre alles ein gewaltiger vendor-lock-in, an dem einzig der Hersteller dieser CPU interessiert wäre. Eben deswegen würden die Entwickler da auch einen großen Bogen drummachen, wenn sie schlau sind.
Jörg W. schrieb: >> Seitdem halte ich mich da (bis heute) immer zurück. > > Grundlos. Also "Zurückhaltung beim Programmieren" hat sich (bei mir) eigentlich immer bewährt. Du weisst doch: "Die längste Strecke zwischen zwei Punkten ist die Abkürzung" Und diverse, später notwendige, Bugfixes bestätigen das auch immer wieder. Ok, der "Kollege", der das mal "schnell gemacht" hat war sicher pünklich zu Hause^^ /regards
Andreas H. schrieb: >>> Mhh. Ich bin mir da nicht sicher, ob die das nicht schon eingesehen >>> hatten als in Ansi-C die Auswertungsreihenfolge solcher Ausdrücke noch >>> "depents on the implementation" war. Und DAS war damals unter UNIX auch >>> immer ein beliebter Fehler, das bekannte (*p && p->x++) ;-) >> >> Wo hast du das denn her? > > Ich hatte so einen Fehler mal auf einer SUN-3 (?). > Da ging es genau so in die Hose, wenn NULL==p war. Das sieht ja auch schon auf den ersten Blick falsch aus - ich hätte (p && p->x++) erwartet. Was soll *p denn überhaupt als Check aussagen?
Andreas H. schrieb: > (*p && p->x++) kann mir jemand sagen, wo so eine Zeile denn sinnvoll sein könnte? Ich wüsste nichtmal, was die überhaupt tut. p->x++ wenn irgendein Bit innerhalb der Struktur nicht 0 ist?
Achim S. schrieb: > Andreas H. schrieb: >> (*p && p->x++) > > kann mir jemand sagen, wo so eine Zeile denn sinnvoll sein könnte? Ich > wüsste nichtmal, was die überhaupt tut. p->x++ wenn irgendein Bit > innerhalb der Struktur nicht 0 ist? Die Zeile ist kein gültiges C, kann aber gültiges C++ sein. p ist ein Pointer auf ein Struct (sieht man an p->x). Ein Struct kann in C nicht nach bool konvertiert werden, in c++ gibt's dazu nen operator. So oder so würde p bei *p bereits dereferenziert, womit wenn dieses 0 ist etwas undefiniertes Passiert. Wenn statdessen (p && p->x++) gestanden wäre, würde es bedeuten: * wenn p null ist => ergibt false * wenn p nicht 0 ist, erhöhe p->x um eins, und gebe true zurück wenn p->x davor nicht 0 war, ansonsten false
Nase schrieb: > Solche Leute haben wir auch. > Die halten verbissen an ihrem zenn Jahre alten Kram fest, weil das ja > schon immer so war, verweigern jegliches Fortkommen und blockieren > wichtige Entscheidungen. Lass mich raten, Du bist: jung, hekisch, dynamisch, erfolglos und Deiner Meinung nach unterbezahlt.....
Daniel A. schrieb: > Die Zeile ist kein gültiges C, kann aber gültiges C++ sein. Das gab es damals noch nicht.
edgar S. schrieb: > Nase schrieb: >> Solche Leute haben wir auch. >> Die halten verbissen an ihrem zenn Jahre alten Kram fest, weil das ja >> schon immer so war, verweigern jegliches Fortkommen und blockieren >> wichtige Entscheidungen. > > Lass mich raten, Du bist: > > jung, hekisch, dynamisch, erfolglos und Deiner Meinung nach > unterbezahlt..... <irony> Wie kommst Du denn darauf? Haust Du nie in einem laufenden System mal die Software weg, spielst Deine neue Version, in der Language-of-the-Year ein, stellst fest, das die alte HW das nicht packt, bestellst neue HW, baust sie ein, fixed noch ein "paar kleine Issues" und erklärst dann wissend dem (ex-)Kunden, dass die 5 Tage Ausfall der Produktionsstrasse unvermeidlich waren, wenn man auf dem Stand der Technik bleiben will und die dabei entstandenen Kosten verschmerzbar sind? Naja, manche Kunden sind schon seltsam rückständig. Denen reicht es, wenn es einfach nur funktioniert. Echt antiquiert... </irony> /regards
Thomas M. schrieb: > Und für mehrere Addressräume auf verschiedenen Bussystemen hat C nun mal > nichts in der Trickkiste. Witzigerweise ist C auf Harvard-Maschinen groß geworden (PDP-11 mit split I&D).
Jörg W. schrieb: > Witzigerweise ist C auf Harvard-Maschinen groß geworden (PDP-11 > mit split I&D). Die Adressraumtrennung zwischen Programm und Daten war nie ein Problem. Sondern die zwischen veränderbaren Daten und konstanten Daten. Und dieses Problem hatte man bei der PDP-11 nicht.
A. K. schrieb: > Und dieses Problem hatte man bei der PDP-11 nicht. Auch nur, weil man zwischen beiden nicht unterschieden hat, waren halt alles Daten. So macht's ja am Ende auch der AVR-GCC.
A. K. schrieb: > Jörg W. schrieb: >> Witzigerweise ist C auf Harvard-Maschinen groß geworden (PDP-11 >> mit split I&D). > > Die Adressraumtrennung zwischen Programm und Daten war nie ein Problem. > Sondern die zwischen veränderbaren Daten und konstanten Daten. Genau. Mein Problem ist da vornehmlich, dass ich nicht mit Bordmitteln von C dynamisch z.B. eemem alloziieren kann. Einen Heap gibts ja nur im Ram.
chris_ schrieb: > Was hier noch gar nicht vor kam: graphische Programmiersprachen. > Ich bin der Meinung, eine richtig gute Programmiersprache muss > graphische Anteile beinhalten. Bloß nicht. Sprache soll Text sein und nichts weiter. Nichts gegen Visualisierungen von Quelltexten, das kann manchmal praktisch sein. Das Arbeiten mit Spezialeditoren, die man für Bildersprachen braucht und von denen man dann abhängig ist, ist ganz nett bei kleinen und einfachen Sachen. Aber bei größeren und komplexeren Projekten ist es ein Graus. Hier klicken und da was eintragen, dann dort ein Menü aufrufen und etwas auswählen. Eine mühselige Klickerei und gegenüber dem Arbeiten mit einem guten Texteditor sehr ineffizient. Ich kenn es aus der SPS-Programmierung. Ein Kunde wollte gern die Bausteine in FUP haben, während ich gewohnt bin, mit AWL-Qelltexten zu arbeiten. Nach einigen unerquicklichen Versuchen, habe ich herausgefunden, wie die AWL-Texte gestaltet sein müssen, um in FUP darstellbar zu sein. Nun generier ich sie doch in AWL und speicher sie dann als FUP ab.
:
Bearbeitet durch User
Thomas M. schrieb: > Genau. Mein Problem ist da vornehmlich, dass ich nicht mit Bordmitteln > von C dynamisch z.B. eemem alloziieren kann. Einen Heap gibts ja nur im > Ram. Du willst einen Heap im EEPROM? Dann schau dir mal ATtiny816 und Konsorten an, da scheint das zu gehen. Nach über 15 Jahren ist Atmochip endlich auf den Trichter gekommen, dass Harvard und linearer Adressraum kein Widerspruch sind :-)
Thomas M. schrieb: > Mein Problem ist da vornehmlich, dass ich nicht mit Bordmitteln > von C dynamisch z.B. eemem alloziieren kann. Einen Heap gibts ja nur im > Ram. Diese beiden Sätze kann man auch gut als kurze Ansprache bei einer Hochzeitsfeier bringen. :) schnell fort hier MfG Paul
Jörg W. schrieb: > Auch nur, weil man zwischen beiden nicht unterschieden hat, waren > halt alles Daten. So macht's ja am Ende auch der AVR-GCC. Bei der PDP-11 landeten alle adressierten Daten im Datensegment. Das war ebenso 64KB gross wie das Codesegment. Egal ob konstant oder variabel. Der AVR macht es von Haus aus auch so, indem der Startcode Flash-Daten ins RAM kopiert. Aber mangels ausreichender RAM-Kapazität stösst man dabei schnell an Grenzen. Und dann hat man es eben mit Daten im RAM und Daten im Flash zu tun, die sich mit Hardware-Pointern nicht adressieren lassen. Hätte Atmel den AVRs schon früh die Möglichkeit gegeben, Flash in den Datenadressraum einzublenden, beispielsweise in die zweite Adresshälfte, wäre der ganze Zirkus mit PROGMEM kaum jemals nötig. Allerdings wäre die Ablaufsteuerung etwas komplexer geworden.
:
Bearbeitet durch User
A. K. schrieb: > Der AVR macht es von Haus aus auch so, indem der Startcode Flash-Daten > ins RAM kopiert. Yep, so wie man den Kram auf der PDP halt von der Platte geladen hat, sowohl .text als auch .data. Ich wollte ja auch nur drauf hinaus, dass es keineswegs an C selbst liegt, „nicht mit Harvard“ klar zu kommen. Das Problem des AVRs ist ja eher der insgesamt recht knappe Adressraum. Beim ARM hat (trotz Harvard) keiner ein Problem damit. > Aber mangels ausreichender RAM-Kapazität stösst man > dabei schnell an Grenzen. Das ist der eigentliche Pferdefuß. Ist gewissermaßen so, wie wenn man auf der PDP hätte die Befehle direkt von der Platte gelesen hätte und nun gleiches auch mit den konstanten Daten tun möchte. > Hätte Atmel den AVRs schon früh die Möglichkeit gegeben, Flash in den > Datenadressraum einzublenden, beispielsweise in die zweite Adresshälfte, > wäre der ganze Zirkus mit PROGMEM kaum jemals nötig. Allerdings wäre die > Ablaufsteuerung etwas komplexer geworden. Naja, dann hätten wir statt der blöden 64-Ki-Segmentierung eine 32-Ki-Segmentierung gehabt. Auch nicht ernsthaft besser, finde ich. Der MSP430 macht sowas ähnliches, das funktioniert bis zu so 40 oder 48 KiB Flash (hab' die genaue Grenze vergessen) ganz gut, danach fängt man dann mit Verrenkungen an, einzelne Funktionen per Attribut (oder Pragma oder was auch immer) einem bestimmten Bereich im Flash zuzuweisen.
Jörg W. schrieb: > Naja, dann hätten wir statt der blöden 64-Ki-Segmentierung eine > 32-Ki-Segmentierung gehabt. Für fast alle Fälle hätte das ausgereicht. Nur Programme mit sehr grossem Datenanteil im Flash wären betroffen gewesen. Und deren Daten wären sehr wahrscheinlich grosse Tabellen gewesen, auf die nur die nur relativ wenigen Stellen zugegriffen wird. > Der MSP430 macht sowas ähnliches, das funktioniert bis zu so > 40 oder 48 KiB Flash (hab' die genaue Grenze vergessen) ganz gut, > danach fängt man dann mit Verrenkungen an, einzelne Funktionen per > Attribut (oder Pragma oder was auch immer) einem bestimmten Bereich > im Flash zuzuweisen. Missverständnis? Ich beziehe mich nur auf Datenadressierung. Codeadressierung wäre genau wie jetzt rein auf Flash bezogen. Banking wäre nur aufgetreten, wenn mehr als 32KB Daten im Flash liegen. Zu MSP430: Bis (circa) 64KB Code+Daten ist diese Architektur sehr elegant und sauber. Jenseits davon kann man das nicht mehr behaupten. Da ist einfach Schluss, das war nie vorgesehen. Bei der PDP-11 war je nach Modell bei 64K oder 2x64KB ja auch Schluss. Jenseits dessen kamen Overlays und das war kein Vergnügen.
:
Bearbeitet durch User
Was hat die "gute Programmiersprache" mit der Hardware-Architektur oder gar einem speziellen Prozessor von ATMEL oder TI zu tun. Mädels, ich glaube die Disskussion führt gerade in eine falsche Richtung. Es geht um eine "gute Programmiersprache" und "warum es diese nicht gibt." Bitte nicht abschweifen auf Nebenschauplätze!
1234567890 schrieb: > Bitte nicht abschweifen auf Nebenschauplätze! Der Zweig entstand aus der Frage, welche (Compiler-) Programmiersprache das Problem der Trennung in mehrere Adressräume, speziell in mehrere Datenadressräume, gut abbilden kann. Vorschläge erbeten. Tipp: Ohne Pointer und damit verwandte Konstruktionen wie Referenzparameter verschwindet das Problem.
:
Bearbeitet durch User
S. R. schrieb: >> Aber die paar wenigen Mikrocontroller, die ich bisher >> in die Finger bekommen hatte, waren allesamt Havard Architekturen. > > Intern dürften die meisten modernen Prozessoren Harvard-Architekturen > sein, das ist nicht nur auf Controller beschränkt. Was auch immer das bedeuten mag. Hardvard-Architektur heißt getrennte Adressräume und Speicherbusse für Code und Daten. "Die meisten modernen Prozessoren" haben höchstens getrennte Caches für Code und Daten. > Mir ist grundsätzlich keine Sprache bekannt, die mit getrennten > Adressräumen wirklich gut umgehen könnte. Sofern man eine echte Harvard-Architektur hat, die Trennung also wirklich zwischen Code und Daten gemacht wird, kommt C ganz hervorragend damit klar. Nur wird diese Trennung meist nicht sauber durchgezogen.
Wenn du einen Blick auf den ARM Cortex-M3 wirfst, findest du eine echte Harvard-Architektur. Allerdings ist der Adressraum linear und deswegen sind sowohl Flash als auch RAM identisch adressierbar und /für den Programmierer/ sieht es aus wie eine von Neumann-Architektur. Es ist aber keine!
S. R. schrieb: > Wenn du einen Blick auf den ARM Cortex-M3 wirfst, findest du eine echte > Harvard-Architektur. Für Programmiersprachen und ihre Abbildung auf Maschinen sind nicht Datenbusse relevant, sondern Adressräume. Wie sich die Busse intern aufteilen ist dafür völlig uninteressant. Wenn man in diesem Kontext die Begriff Harvard oder von Neumann verwendet, sollte man sich folglich auf Adressräume beziehen, nicht auf Datenbusse. Diese Begriffe entstanden in einem Kontext, in dem getrennte Datenbusse auch für getrennte Adressräume standen. Ich halte es für einen klassischen Fehler, sie auf irgendwelche Datenbusse zu beziehen. Es nimmt ihnen fast jeden Wert.
:
Bearbeitet durch User
A. K. schrieb: > Für Programmiersprachen und ihre Abbildung auf Maschinen sind nicht > Datenbusse relevant, sondern Adressräume. Tja, und so gesehen ist AVR eben nur eine vergurkte Harvard-Architektur - denn die Daten, welche das Problem sind und Progmem-Gefrickel erfordern, liegen ja im Flash, also im Code.
turbo autist schrieb: > ... Also Ich fahre mit der Kombination C und lua (bzw. dem extrem schnellen luajit) ziemlich gut. Deal with it.
Lukas S. schrieb: > lua Mit Lua hab ich auch mal ein bisschen rumgespielt, und zwar war das als ich mit FEMM was scripten musste, da muss man leider Lua verwenden. Was mir sofort aufgefallen ist war daß es erlaubt ist in Ausdrücken Variablen zu verwenden die gar nicht existieren und es kommt trotzdem nicht mal ne Warnung, es läuft einfach durch als wäre nichts, die Variable kommt ungefragt aus dem Nichts heraus in die Existenz und hat den Wert nil! Sowas hab ich zum letzten Mal in irgendwelchen halbgaren BASIC-Dialekten aus den 80ern gesehen, danach nie wieder. Und es ist bereits bei Version fünf Punkt irgendwas und dieser kapitale Schnitzer ist immer noch nicht behoben (vor 5 Minuten ausprobiert). Ich nominiere Lua für den diesjährigen Null-Pointer-Award.
Bernd K. schrieb: > Und es ist > bereits bei Version fünf Punkt irgendwas und dieser kapitale Schnitzer > ist immer noch nicht behoben (vor 5 Minuten ausprobiert). Weil das kein "Schnitzer" ist, sondern so gewollt ist.
Bernd K. schrieb: > Was mir sofort aufgefallen ist war daß es erlaubt ist in Ausdrücken > Variablen zu verwenden die gar nicht existieren Das ist bei vielen Sprachen so, die keine Deklaration von Variablen erzwingen, insbesondere bei Scriptsprachen. Das ist in der Tat lästig, weil man nichtmal ein rudimentäres Typensystem hat und vor allem bei Tippfehlern keine Fehlermeldung bekommt. Ich sehe sowas als grundsätzlichen Mangel einer Sprache.
So schlecht sind heutige Sprachen doch gar nicht — immerhin unterstützt C++ bereits Floppy Disks. Es stanzt zwar Löcher hinein wie in Lochkarten, aber das ist immerhin ein Anfang! http://www.xkcd.com/1755/
Nop schrieb: > Bernd K. schrieb: >> Was mir sofort aufgefallen ist war daß es erlaubt ist in Ausdrücken >> Variablen zu verwenden die gar nicht existieren > > Das ist bei vielen Sprachen so, die keine Deklaration von Variablen > erzwingen, insbesondere bei Scriptsprachen. Ich kenne jetzt nicht soviele davon, aber bei welchen ist das denn noch so?
>Ich kenne jetzt nicht soviele davon, aber bei welchen ist das denn noch
so?
Verschiedene Shell-Sprachen.
Rolf M. schrieb: > Ich kenne jetzt nicht soviele davon, aber bei welchen ist das denn noch > so? Ruby, aber dort ist nil vom Typ NilClass, also ebenfalls ein Objekt
Bernd K. schrieb: > Lukas S. schrieb: >> lua > > Mit Lua hab ich auch mal ein bisschen rumgespielt, und zwar war das als > ich mit FEMM was scripten musste, da muss man leider Lua verwenden. > > Was mir sofort aufgefallen ist war daß es erlaubt ist in Ausdrücken > Variablen zu verwenden die gar nicht existieren und es kommt trotzdem > nicht mal ne Warnung, es läuft einfach durch als wäre nichts, die > Variable kommt ungefragt aus dem Nichts heraus in die Existenz und hat > den Wert nil! Sowas hab ich zum letzten Mal in irgendwelchen halbgaren > BASIC-Dialekten aus den 80ern gesehen, danach nie wieder. Und es ist > bereits bei Version fünf Punkt irgendwas und dieser kapitale Schnitzer > ist immer noch nicht behoben (vor 5 Minuten ausprobiert). Ich nominiere > Lua für den diesjährigen Null-Pointer-Award. Das lässt sich ja auch nachrüsten: http://metalua.luaforge.net/src/lib/strict.lua.html bzw. http://lua-users.org/wiki/DetectingUndefinedVariables Mir gefällt vorallem die hohe Dynamik an der Sprache z.b. kein switch/case? kein Problem:
1 | switch = {
|
2 | ["help"] = function () print("Help:\n\n") end,
|
3 | ["exit"] = function () print("Tschüss...") os.exit() end
|
4 | } |
5 | switch[io.read("*line")]()
|
Außerdem ist lua sehr Portabel. Java (bzw. Oracle) behauptet zwar überall zu laufen, lua setzt es aber tatsächlich um: Vom Gameboy Advanced über den Nintendo DS, PalmOS, DOS, µCs/Baremetal (eLua) bis hin zu Alternativen Firmwares für Kameras.
Nop schrieb: > Ich sehe sowas als grundsätzlichen Mangel einer Sprache. Darum ist bei Perl-Code ein fehlendes "use strict;" quasi immer ein Zeichen von schlechter Qualität. Ob Lua etwas vergleichbares hat, weiß ich nicht.
S. R. schrieb: > Darum ist bei Perl-Code ein fehlendes "use strict;" quasi immer ein > Zeichen von schlechter Qualität. Wenn ein Programm nach tagelanger Fehlersuche immer noch nicht fehlerfrei läuft, kommt manch Einem der Ausdruck: use Strick in den Sinn. MfG Paul
Lukas S. schrieb: > Das lässt sich ja auch nachrüsten: Auf gut deutsch, wenn man nicht from cratch hackt, dann kann man sich darauf nicht verlassen, daß der Bestandscode so ist. > Mir gefällt vorallem die hohe Dynamik an der Sprache z.b. kein > switch/case? kein Problem: Mir gefällt das überhaupt nicht. Das war bei Lisp auch schon so, daß man sich praktisch damit eine Sprache selber definieren konnte. Das ist theoretisch ja schön, praktisch führt es aber dazu, daß jedes Projekt seine eigene Sprache hat. Eine bestehende Codebasis zu übernehmen ist mit solchen Sprachen ein ziemlicher Drecksjob. Das ist auch der Hauptgrund, wieso es zwar etliche Lisp-Hacker gibt, das aber tendentiell Einzelgänger sind und bleiben. Du kannst ohnehin kein großes Projekt mit sowas machen, weil die Fluktuation dafür sorgt, daß auch mal Leute gehen, und die Sprache dafür, daß keine neuen Leute reinkommen. Sowas ist write-only-code jenseits jeder Wartbarkeit, und solche Projekte überleben ihren Erschaffer nicht.
D. I. schrieb: > Rolf M. schrieb: >> Ich kenne jetzt nicht soviele davon, aber bei welchen ist das denn noch >> so? > > Ruby, aber dort ist nil vom Typ NilClass, also ebenfalls ein Objekt Hast du mal ein Beispiel, wie das aussieht? Ich kenne mich mit Ruby nicht aus, aber ein einfaches y = x erzeugt x nicht, sondern bringt einen Fehler, dass es nicht existiert, genau wie Python.
Rolf M. schrieb: > Hast du mal ein Beispiel, wie das aussieht? Ich kenne mich mit Ruby > nicht aus, aber ein einfaches y = x erzeugt x nicht, sondern bringt > einen Fehler, dass es nicht existiert, genau wie Python. Ja du hast recht, Variablen müssen immerhin definiert werden, habe es im Kopf mit nicht definierten Hash-Keys durcheinander gebracht, bei denen kriegt man nil.
T0: >Sprachen mit dynamischem Typensystem habe ich mal nicht aufgeführt weil >ich mich nicht sonderlich für Kinderspielzeug interessiere. Warum benimmst du dich dann wie ein Baby und heulst herum "äähhh es giiiibt ähhhh kein e ähhh g u t e n ääh Programmiersprachen ähhh" Ich empfehle dir BASIC das ist was für Mädchen.
Nop schrieb: > Tja, und so gesehen ist AVR eben nur eine vergurkte Harvard-Architektur > - denn die Daten, welche das Problem sind und Progmem-Gefrickel > erfordern, liegen ja im Flash, also im Code. Nur, wenn du zu geizig mit RAM bist ;), und auch nur, sofern es sich um konstante Daten handelt. Das „Gefrickel“ entsteht nur dann, wenn man für seine konstanten Daten nich noch extra RAM spendieren will. Normalerweise liegen die Daten ja im RAM und damit in einem separaten Adressraum.
Nop schrieb: > Das ist bei vielen Sprachen so, die keine Deklaration von Variablen > erzwingen, insbesondere bei Scriptsprachen. Das ist in der Tat lästig, > weil man nichtmal ein rudimentäres Typensystem hat und vor allem bei > Tippfehlern keine Fehlermeldung bekommt. > > Ich sehe sowas als grundsätzlichen Mangel einer Sprache. Autovivikation ist ein Feature der meisten modernen Skriptsprachen, und sie alle gehen recht unterschiedlich damit um. Lua und Perl erstellen ohne Warnung eine neue Variable, Lua initialisiert sie auf nil und Perl auf einen leeren String. In Perl kann man das durch "use strict;" verhindern, in Lua ist mir keine Lösung dafür bekannt. Ruby und Python steigen bei unbekannten Variablen -- also solchen, denen noch kein Wert zugewiesen wurde -- jeweils mit einem Fehler aus. Es ist auch nicht richtig, daß Python und Ruby kein Typsystem hätten; im Gegenteil haben beide Sprachen eine sehr starke Typbindung, wenngleich sie dynamisch ist, der Typ einer Variablen also zur Laufzeit geändert werden kann. Ein Typ ist nicht an eine Variable, sondern an ihren Wert gebunden; wenn dieser Wert einer anderen Variable zugewiesen wird, erhält sie den Typ des zugewiesenen Wertes, ungeachtet des Typs ihres vorherigen Wertes. Den Typ eines Wertes ändert Python aber nur auf ausdrückliche Anweisung. Python3 enthält zudem weiteren Support für Type Hints durch das Modul typing.
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.