Zugriff und Länge von Array in C

das Array hat VIER Elemente (0...3)!!!

danke

...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!

Wir unterhalten uns in einem embedded Forum aber jetzt nicht wirklich 
über Java, oder?
Nächstens kommt dann einer mit Flowcode oder ähnlichem...

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.

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.

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.

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.

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...

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....