Hi, eine Grundlagenfrage: gegeben ist dieses: >#define LAENGE 4 >uint16_t Array[LAENGE]; Ich möchte drarauf zugreifen und der Compiler gibt mir bei folgendem Zugriff > x = Array[LAENGE]; die folgende Warnung: >Warning: Subscript out of Range Ich hatte eigentlich gedacht, dass das Array[LAENGE] 5 Elemente hätte, also von 0 bis 4 zugewgriffen werden kann... Das ist falsch? mfg
Array schrieb: > Ich hatte eigentlich gedacht, dass das Array[LAENGE] 5 Elemente hätte, Warum sollte das Array 5 Element haben wenn du dem Compiler sagst daß das Array 4 Elemente hat. Merke: Ein Array kann man IMMER von 0 bis Länge-1 indizieren! Du brauchst ein C Buch und solltest es auch lesen.
In C kann man es wohl auch außerhalb indizieren, nur kommt dabei natürlich Schrott raus. An so Stellen haben dann Sprachen wir Java einen kleinen Vorteil, sie sagen dir nämlich - du dämlich "Array: Index out of Bounds....blabla Exception"... Gruß Jonas
Jonas Biensack schrieb: > An so Stellen haben dann Sprachen wir Java einen kleinen Vorteil, Dann sollte man aber auch nicht die Nachteile von einer Sprache wie Java auf einem µC verschweigen. Hast du schon mal Java auf einem µC mit einigen 100 Byte bis max. 8kByte RAM effektiv! eingesetzt?
Jonas Biensack schrieb: > An so Stellen haben dann Sprachen wir Java einen > kleinen Vorteil Das gibts aber nicht zum Nulltarif. Sie müssen dazu zusätzliche Variablen anlegen und diese auch bei jedem einzelnen Zugriff zusätzlich prüfen. Peter
...naja, der C-Compiler hatte es mir ja auch gesagt... Hatte es nur in meinem Gedächtnis anders abgespeichert mit Arraygröße und Zugriff und mich über die Warnung gewundert und daher nochmal hier vergewissert, dass ich es wirklich falsch erinnert habe.
Array schrieb: > ...naja, der C-Compiler hatte es mir ja auch gesagt... Der Compiler hat dich gewarnt, weil du so "nett" warst, einen ungültigen index direkt zu verwenden. Normal greift man auf die Array-elemente aber per index via variable zu. Und dann hat der compiler kaum noch eine chance dich zu warnen. Zugriffe auf array-elemente in java oder z.b. .net werden vom compiler nicht in assembler umgewandelt, sondern sind methodenaufrufe. Und die enthalten dann die zusätzlichen prüfungen zur Laufzeit!
Vor allen Dingen sind Arrays in Java (und den meisten anderen Programmiersprachen) echte 'Objekte', während Arrayzugriff in C im Grunde nichts anderes als Pointerarithmetik in anderer Verpackung darstellt.
Wir unterhalten uns in einem embedded Forum aber jetzt nicht wirklich über Java, oder? Nächstens kommt dann einer mit Flowcode oder ähnlichem...
Uli schrieb: > Wir unterhalten uns in einem embedded Forum aber jetzt nicht wirklich > über Java, oder? Was würde bei einem 32 Bit embedded System, auf dem ein Linux läuft, gegen Java sprechen? Man kann auch manchmal über den Tellerrand schauen. Bei der aktuellen Diskussion ging es rein ob und warum Indexgrenzüberschreitungen zur Laufzeit erkannt werden können.
Das kommt darauf an für was das System verwendet wird. Ich hab aber schonmal den Versuch gesehen ein Infotainment-System für Audis in java zu entwickeln (ARM9-Core). Der Versuch ging mal so richtig in die Hose, aus Laufzeitgründen. Bevor mich jemand falsch versteht, ich finde Java ne wunderschöne Sprache, aber eigentlich doch eher für den Desktop-Bereich wenn man mal schnell was hinschludern will. Ansonsten hab ich schon beliebig viele Projekte gesehen die aufgrund der falschen Sprachwahl (und aufgrund von unerfahrenen Leuten) mal so megamäßig den Bach runtergegangen sind. Und da bei yC in den meisten Fällen auch irgendwo Echtzeit-Verhalten gefragt ist fällt eine managed Sprache sowieso irgendwie raus....
Anders Ausgedrückt: So ziemlich jede Sprache hat ihre Berechtigung und ihren Einsatzort. Man würde ja auch nie C nehmen um mal eben schnell ein kleines Skriptchen zu schreiben...
Uli schrieb: > Bevor mich jemand falsch versteht, ich finde Java ne wunderschöne > Sprache, aber eigentlich doch eher für den Desktop-Bereich wenn man mal > schnell was hinschludern will. Nur ist es in der Realitaet so, dass sich Java nicht auf dem Desktop, sondern im Server-Bereich durchgesetzt hat. Das muss man nicht verstehen, es ist einfach so. Was Java den Erfolg gebracht hat, sind uebrigens weniger oft genannte Sprachfeatures wie die Speicherverwaltung oder sowas wie die Arrays mit Zugriffsschutz - sondern die mitgelieferte Standardbibliothek. Wer ein Array mit Zugriffsschutz haben will, kann sich das eigentlich 1-2-3 schnell selbst schreiben. > Anders Ausgedrückt: So ziemlich jede Sprache hat ihre Berechtigung und > ihren Einsatzort. Noe, viele Sprachen sind einfach nur Muell.
Serversoftware in Java? Hab ich noch nie gehört. Muss aber auch nix heißen.
Marwin schrieb: > Noe, viele Sprachen sind einfach nur Muell. Stimmt schon, aber die taugen dann als schlechtes Beispiel... nee, ganz im Ernst, ich finde sogar Sprachen wie Brainf-uck oder Java2k ganz lustig, und immerhin taugen sie für lustige Gedankenexperimente. Wieder andere muß man in Ihrem historischen Kontext sehen. Niemand würde heutzutage mehr Modula-2 oder Pascal nehmen, aber es waren halt doch Meilensteine der Sprachentwicklung. Ansonsten sehe ich (und das ist sicherlich nur eine mögliche Meinung) bei Sprachen klare Favoriten für die jeweilige Anwendung: Embedded: C Betriebssysteme: C Desktop-Anwendungen aller Art: C/C++ modelierung physiklastiger Software: C++ Skripte: Perl, Phyton Schnelle Oberflächen: Tk
Simon K. schrieb: > Serversoftware in Java? Hab ich noch nie gehört. Muss aber auch nix heißen. Dann google mal nach "Java Application Server". Und das ist dann nur die Spitze des Eisbergs. Im Mikrocontroller-Forum herrscht mitunter eine sehr eingeschraenkte Weltsicht vor, wenn es um Informatik-Themen geht... Andersrum ist das allerdings genauso: Frag Informatiker zum Beispiel in der Finanzindustrie nach Assembler - die gucken dich an, als haettest du nach einem Dinosaurier gefragt.
Simon K. schrieb: > Serversoftware in Java? Hab ich noch nie gehört. Muss aber auch nix > heißen. Servelts, Tomcat Gibt es schon, wird glaube ich teilweise bei Versicherungen recht häufig eingesetzt (saß schonmal in einem Bewerbungsgespräch, beidem es darum ging).
Uli schrieb: > Ansonsten sehe ich (und das ist sicherlich nur eine mögliche Meinung) > bei Sprachen klare Favoriten für die jeweilige Anwendung: Das ist leider auch eine sehr eingeschraenkte Sicht der Dinge. > Embedded: C Wieso kein C++? Wird Zeit, dass die Mikrocontroller-Gesellschaft mal einen kleinen Schritt nach vorne macht - Embedded heisst heute nicht mehr nur Ampelschaltung! Das sind oft grosse Applikationen, die von einem objektorientierten Ansatz profitieren und der profitiert von einer Sprache, die das unterstuetzt. > Betriebssysteme: C Dito. > Desktop-Anwendungen aller Art: C/C++ Werden heute auf MacOS in objective-C und auf Windows in C# entwickelt. Bleibt fuer C/C++ vor Allem Linux. > modelierung physiklastiger Software: C++ Dazu kann ich mich nicht aeussern. > Skripte: Perl, Phyton Das hoeren die Python-Entwickler zwar nicht gerne, aber so verbreitet ist das gar nicht. Wenn's um Unix-Systeme geht, liegen Shell- und Perl-Skripte weit vorne. > Schnelle Oberflächen: Tk Das kann man wohl nur aus einer speziellen Sichtweise so sehen.
Marwin schrieb: > Wieso kein C++? Weil etliche der verwendeten µCs dafür entschieden zu klein sind, und im Falle der beliebten AVRs auch noch den massiven Nachteil* der Harvard-Architektur mit sich schleppen. *) Ich sehe die Klimmzüge, die erforderlich sind, um Daten im Flash und nur dort unterzubringen und darauf zuzugreifen als Nachteil; die fast täglich hier erscheinenden Threads deswegen werte ich ebenfalls als Indiz dafür. Bei anderen Architekturen schreibt man an der entscheidenden Stelle const und muss sich um nichts weiter kümmern.
Udo Schmitt schrieb: > Merke: Ein Array kann man IMMER von 0 bis Länge-1 indizieren! Merkt man sich das kann man auf Java etc. locker verzichten. Java und Konsorten erinnern mich irgendwie an die risikofreie, allseits behütete Gesellschaft die wir mittlerweile haben: Es geht kaum etwas kaputt, aber nichts geht mehr. BWL & Gutmensch rulez. No risc no fun. Ich finde Java furchtbar.
Joachim Drechsel schrieb: > Java und Konsorten erinnern mich irgendwie an die risikofreie, allseits > behütete Gesellschaft die wir mittlerweile haben: Es geht kaum etwas > kaputt, aber nichts geht mehr. BWL & Gutmensch rulez. C ist ja wohl nur was für Weicheier! Wir haben den Hexcode für die Opcodes noch auswendig gewusst und direkt eingegeben!!!!! Hochsprache, nur für Looser! Und du fährst garantiert auch noch ein Auto ohne ABS, ASR oder gar synchronisiertem Getriebe. Wer braucht eine Batterie im Auto, das kann man ankurbeln. Junge wach auf, die Welt bewegt sich weiter und wir sind im 21 Jahrhundert. Das was du über Java sagst habe ich fast wörtlich vor 20 Jahren über C gehört. Bis du deine C Anwendung geschrieben hast habe ich eine gleichwertige Anwendung in Java schon auf 3 Betriebssystemen und 4 versch. Datenbanken beim Kunden und verdiene Geld damit. Und gehen tut damit sogar mehr, nämlich echte portable und Datenbank / betriebssystemunabhängige Anwendungen. Schau mal über den Tellerrand.
Ich fahre kein Auto, mein Mopped hat einen Kickstarter. Meinem Tellerrand geht es prima und ich muß meine Software nicht über -zig Platformen verteilen. Ich lebe auch davon. Seit wann ist eigentlich C nicht mehr portabel ? Was will ich mit einem schwachbrüstigen Interpreter ?
Aufwecker schrieb: > Anwendung in Java schon auf 3 Betriebssystemen und 4 versch. Datenbanken > beim Kunden und verdiene Geld damit. Seither waren wir bei Embedded. Und für zeitkritische Dinge kann man sowas eben für uC vergessen...
Niedlich, wie sich hier wieder Leute über Dinge aufregen, welche sie offenbar gar nicht kennen.
Sebastian Richter schrieb: > Niedlich, wie sich hier wieder Leute über Dinge aufregen, welche sie > offenbar gar nicht kennen. Muß mal sein, ist ja Feierabend ;) Meinem VL habe ich bei Java nachhelfen müssen, es war schrecklich mit was sie angehende Physiker heutzutage quälen. Nebenbei halte ich einen sauberen Lösungsweg für wichtiger wie die gewählte Programmiersprache. Nur so am Rande ...
>> Desktop-Anwendungen aller Art: C/C++ > > Werden heute auf MacOS in objective-C und auf Windows in C# entwickelt. > Bleibt fuer C/C++ vor Allem Linux. Und Windows 8 denn wieder C++ in einer M$ Sondervariant da WinRT nicht mehr in der. net-Welt angesiedelt ist sondern nur von dieser angesprochen werden kann. Matthias
Ich hab im Prinzip nichts gegen C++ in der embedded Welt. Allerdings arbeite ich für einen großen deutschen Elektrokonzern in der Softwareentwicklung (embedded, ARM9 und PPC-Targets) und sehe zu häufig wie die Konstrukte die C++ ermöglicht viel zu häufig dafür eingesetzt werden inperformanten, schlechten Code zu schreiben. Jedes größere embedded Projekt mit java ist noch gescheitert, ich laß mich abger gerne eines besseren belehren. C++ bei Betriebssystemen konnte man sich damals beim Mach-Kernel life und in Farbe angucken... Ist auch nix draus geworden. C# finde ich eigentlich nen ganz netten Ansatz, aber ich hab auch zuviel gesehen, bei dem das Projekt dann vollkommen vergeigt wurde weil die neuen Konzepte falsch eingesetzt wurden. Aber mal ganz im Ernst: Wie gesagt, eigentlich ist so gut wie jede Sprache für irgendwas gut, und wie auch weiter oben geschrieben wurde so kommt es wesentlich mehr auf das design an als auf die verwendete Sprache. Aber ich kanns mir heutzutage jedesmal wieder angucken: Leute die nur java gelernt haben, sind häufig nicht in der Lage zu verstehen was in den tiefen des Systems wirklich passiert. Dies ist schon auf dem Desktop unabdingbar um guten Code zu schreiben und gilt umsomehr im embedded Bereich. C zwingt die Leute eben doch sich mehr mit den internas zu beschäftigen. Assembler zu lesen ist auch eine Fähigkeit die ich von jedem Entwickler erwarten würde, aber schreiben? Nein! Außer in sehr kurzen, per Profiler ermittelten Codeabschnitten seh ich da heutzutage keinen Sinn mehr drin. Und wie gesagt: Nix gegen C++ im embedde Umfeld, aber bitte nur wenn die Leute wissen was sie tun... Ihr glaubt gar nicht was da ansonsten für undebugbarer (wer schon mal versucht hat mit Lauterbach etwas komplexere C++-Files zu debuggen weiß was ich meine), unperformante Sachen rauskommen, und welchen Codegrößen zuwach man so erwarten darf....
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.