Hallo,
da im Newsartikel AVR-Ada erwähnt wird, würde mich interessieren, wer
hier schon Erfahrung mit Ada im Allgemeinen und mit Microcontrollern
(oder sogar AVR-Ada) im speziellen gesammelt hat.
Früher dachte ich immer, Ada sei die Sprache für sicherheitsrelevante
Anwendungen, aber heute weis ich, daß da auch gerne C genommen wird.
Interessant ist sicher auch die Nähe zu VHDL, aber ich bin mir nicht
sicher, ob es wirklich eleganter als C ist. Zu den im Newsartikel
aufgeführten Beispielen:
1
UCSR0B=(1<<RXEN0)|(1<<TXEN0);
Wenn man die Konstanten anders definieren würde, dann könnte man das
auch so schreiben:
1
UCSR0B=RXEN0|TXEN0;
Zum zweiten Beispiel:
1
LCD_Driver.Init;
2
LCD_Driver.G_Scroll_Mode:=None;
3
LCD_Driver.Scroll_Offset:=0;
4
LCD_Driver.Colons:=False;
5
LCD_Driver.Update_Required:=True;
Das kann man so natürlich auch in C schreiben, wobei Funktionspointer
in Structs eher unüblich sind - man nimmt da besser gleich C++.
Was meint Ihr zu der Thematik? Ist C gut genug? Ist Ada zu exotisch?
Ist Version 0.3 noch viel zu früh für ernsthafte Projekte?
Markus
Das Problem mit Ada ist dass es kaum Compiler gibt. Die Sprache an sich
ist C sicherlich überlegen.
Bitfelder in C sind für Low Level-Programmierung nutzlos, C begünstigt
schlampiges Softwaredesign, C versteht noch nicht einmal Konstanten in
Binärschreibweise, und seit Jahrzehnten benötigt man diesen
bescheuerten ifndef-Hack um zu verhindern dass Header mehrfach
interpretiert werden. Wie kann es sein dass so eine Sprache im
Embedded-Bereich so eine große Bedeutung erlangen konnte und sich seit
16 Jahren praktisch nichts geändert hat?
Welche Alternativen gibt es sonst im Embedded-Bereich? C++? Löst das
die Probleme, oder bietet es nur mehr Möglichkeiten sich in den Fuß zu
schießen?
"sicherheitsrelevante Anwendungen, aber heute weis ich, daß da auch
gerne C genommen wird."
Soweit ich weiss, wird da C gerade da nicht benutzt, vielleicht hat es
sich inzwischen geändert?
Vor Jahren habe ich mal an einer kleinen Sachen für ein KKW
mitgearbeitet - da hiess es kategorisch: Kein C! Irrwitzigerweise wurde
aber Assembler akzeptiert. Begründung: durch falsche (berechnete)
Indizierung von Variablen könne in falsche Speicherbereiche zugegriffen
werden (was ja auch richtig ist) - die mögliche Fehlerquote halte ich
aber in Assembler für vielfach höher.
@Andreas:
Das mit den Headerfiles nervt mich auch. Das hat man gemacht, damit die
Compiler die .c-Files nur einmal lesen müssen (1-pass-compiler). Daß die
Binärschreibweise fehlt lag wohl ursprünglich daran, daß Octal- und
Hexadazimaldarstellung deutlich weniger Tipparbeit machen und für einen
geübten Bitpfriemler genauso leicht zu lesen ist. Fehlt mir aber auch.
C++ ist ein großer Fortschritt im Vergleich zu C - löst aber die
angesprochenen Probleme leider auch nicht.
@crazy horse:
Die Automobilbranche verwendet C. Das kann man zwar nicht mit einem KKW
vergleichen, würde ich aber trotzdem als sicherheitskritisch ansehen.
Hi,
ich verfolge das Thema Ada auch gerade mit wachsendem Interesse. Das
könnte durchaus ne interessante Alternative sein, je nachdem wie gut
der Compiler wird. Ich hab mir den AVR-Ada jetzt noch nicht so genau
angeschaut, aber die Sprache selbst scheint ja objektorientiert zu sein
und bringt von Haus aus schon Multitasking mit.
Da ich bisher recht gute Erfahrungen mit Multitasking auf µC's gemacht
hab interessiert mich das besonders. Wie gesagt, wenn die Umsetzung gut
gemacht ist wäre das sicher interessant
Das Runtime-System von AVR-Ada ist praktisch nichtexistent (d.h. keine
Tasks), es steht aber auf der TODO-Liste. Genaueres siehe Website. Wie
es mit OO aussieht weiß ich nicht, bin selber Ada-Newbie.
Die Codequalität entspricht der von AVR-GCC. Im avr-ada tar.gz ist ein
Beispielprogramm einmal in C, einmal in Ada, mit jeweils dem erzeugten
Assemblercode.
Ob Bereichsüberprüfungen von Variablen, Stack-Überlauf-Erkennung und
solche Dinge funktionieren weiß ich leider nicht.
Ich bin gestern daran gescheitert AVR-Ada unter MacOS zu bauen; unter
Windows (MingW) und Linux soll es wohl relativ einfach funktionieren,
aber in gcc-3.4 scheint noch irgend ein Mac-spezifischer Bug drin zu
sein.
Das das ganze noch in den Kinderschuhen steckt hab ich schon gesehen.
Aber man kann das ganze ja mal im Auge behalten. Wäre schön wenn grad
Multitasking realität würde
Aber gerade in der Automobilbranche wird die Benutzung von C doch oft
recht stark reglementiert Stichwort MISRA) . Das ist zwar nicht so
schön wie gleich eine passende Sprache zu nehmen, aber immerhin.
siehe:
http://de.wikipedia.org/wiki/MISRA-Chttp://www.misra.org.uk/
Also ich verfolge diese Ada Geschichte für AVRs auch schon eine Weile
mit wachsendem Interesse. Wenn man bedenkt, welche immensen Vorteile
diese Sprache gegenüber C bietet, wäre das wirklich eine tolle Sache
wenn dieser Compiler weiterentwickelt wird.
Alleine die Möglichkeiten, die Ada bietet, Datenstrukturen bis auf
einzelne Bit anzulegen und dem Compiler ganz genau mitzuteilen, wie und
wo er diese Sachen, natürlich auch bis aufs Bit genau, anzulegen hat,
sind Dinge, von denen C Programmierer nur träumen können. Man kann
Register oder Device-Dateien direkt und äußerst elegant ansprechen, wo
gibt es sowas sonst?
Im Gegensatz zu anderen Sprachen bietet Ada eine eigene, komplette
Multitasking-Umgebung, die unabhängig von
Betriebssystemimplementationen ist. Das kommt daher, weil Ada ja
ursprünglich für eingebettete Systeme gemacht worden ist und hier seine
Stärken voll ausspielen kann. Wenn das in AVR-Ada implementiert werden
könnte, wäre das der ultimative Traum. Da werde ich keine Zeile mehr in
C schreiben, das ist sicher.
Von C auf Ada zu wechseln, ist gefühlsmäßig ungefähr so, wie wenn man
einen Opel GT gegen einen Mercedes SLR McLaren eintauscht ;-)
Gruß, Norbert
einer der gründe, warum ada zumindest im hobby-bereich fast keine
beachtung findet ist u.a. die strenge typesierung. auch das man (wie
schon angesprochen) unter ada nicht so schlampig oder quick and dirty
arbeten kann wie unter c/c++,... und das erfordert ein vielfaches mehr
an code. (bei uns geht man bei c-tausendzeilern um knapp den faktor 3
aus)
die nähe von vhdl und ada (entwicklungsname ironman) kommt daher, da
ada und vhdl die selben eltern (verteidigungsministerium) hat. man
wollte die sauberkeit und sicherheit der sprache beibehalten. zum OO
sei gesagt, das ada95 oft verpöhnt wird!!!
viele unserer programmierer sagen, ada95 hätte lieber eine neue sprache
werden sollen. ada an sich ist schön konsistend, ada95 hat tolle
ansätze, muss sich aber mit ada (ohne OO) vertragen, und dass soll wohl
probleme bringen. sie sagen adaOO sollte so wie das ebenfalls fast
unbekannte D (C++ ohne c altlasten) neu aufgesetzt werden.
btw oo ist meistens bei kritischen anlagen/systemen nicht zugelassen!
wir müssen meist auch mit c/fortan/ada auskommen weil andere sprachen
nicht zulässig (vom Auftraggeber) sind.
>Von C auf Ada zu wechseln, ist gefühlsmäßig ungefähr so, wie>wenn man einen Opel GT gegen einen Mercedes SLR McLaren eintauscht
stimmt! c++ programmierer tun sich mit dem erlernen von ASM auch immer
schwer ;-)
ps. dies soll kein streitgespräch über "die bessere
programmiersprache" sein!
hey... was durch den compiler geht, hat keine fehler im
programmcode(uninitialisierte variablen z.b.)!!! was fehler der
programmstrucktur (das was der Programmierer von sich gibt) nicht
einschließt!!! das kann immernoch "müll" sein!!!
>Die Ariane5 Rakete ist trotz ADA abgestürzt...
Die Ariane 5 ist abgestürzt weil man den Bordcomputer der Ariane 4
übernommen hatte. Leider haben die Techniker dabei eine Kleinigkeit
übersehen, was zu dem beschriebenen Problem führte. Die Steuersoftware
hat übrigens fehlerfrei funktioniert. Aber was nützt das, wenn die
dazugehörige Hardware nicht paßt. Das ist aber eine mittlerweile
hinreichend bekannte Sache.
Die Sprache heißt übrigens Ada und nicht "ADA". Darauf legen
Ada-Programmierer großen Wert.
Ach ja, dass Ada gegenüber C (oder C++) ein mehrfaches an Tipparbeit
bei der Programmierung bedeutet, bestreitet niemand. Aber dafür braucht
man in C++ dann später die 10-fache Zeit um die ganzen mysteriösen
Fehler und Speicherlecks, verursacht durch verbogene Zeiger, in den
Wald gelaufene Feldindices und durch vergessene free-Aufrufe zu suchen.
Man darf sich natürlich aussuchen, was man lieber hat ;-)
Gruß, Norbert
Hi,
ich bin grad dabei mich in Ada einzulesen und muß sagen das mir das,
was ich so gelesen habe, recht gut gefällt. Ich muß gestehen das ich
auf die OOP Fähigkeiten von Ada95 noch nichtmal allzu scharf bin. Mich
würde das Multitasking dann doch schon eher interessieren. Am
Wochenende hab ich hoffentlich Zeit mal die ersten Gehversuche zu
machen.
Hat sich hier sonst schon jemand das Ganze mal näher angeschaut und
vielleicht schon erste kleine Projekte realisiert und kann mal von
seinen Erfahrungen und Eindrücken berichten?
Gruß
Markus
Hi, anscheinend arbeitet keiner mit Ada?
Ich versuche das grade, aber scheitere schon daran die Examples zu
compilieren. Ich kenne mich mit den GCC nicht wirklich aus und krieg da
null auf die Reihe. Hier wäre etwas mehr Hilfe (zb hier im Wiki) ganz
nett.
Würde mich darüber freuen wenn da jemand mal was machen könnte um den
Einstieg zu erleichtern.
Gruß
Markus
ein Problem mit einer Dynmamik drinne .. sprich Objekte zur Laufzeit
anlegen/freigeben können auf 2 Arten gelöst werden
1 Datenstrukturen verwenden die diese Aufgabe übernehmen => Container
2 es händisch machen
zu 1 .. C++ bringt viele Container mit, ich kenne Ada nicht sehr gut
aber ich denke die Vielfalt ist da nicht so gross
zu 2 .. nun hier ist es egal ob C ob C++ oder Ada, hier ist man auf
sich alleine gestellt.
Was mir vor kurzem durch den Kopf ging war .. ich meinte verstanden
zu haben warum in letzter Zeit dynamische Sprachen so erfolgreich sind.
Allen voran Python und Ruby.
Die Sache ist doch die, wenn ich beim Coden bin ... und noch halb im
Erforschen des Problems (und der Requirements), so ist es ein leichtes
die Datenstruktur anzupassen. Aus einem Array ein Hash in null komma
nichts machen. Oder wenn hash sich nicht als passend erweist, dann eben
eine Klasseninstanz.
Das wäre in Ada pain in the ass :) ich müsste alle Deklarationen
durchforsten .. alle packages .. alle Funktionen die damit
rumhantieren.
def add(a,b):
return a+b
add(1,2)
add(1.0, 2)
add(1+1j,2j) # complex
add("hello", "world")
arbeitet mit allem!
name[1] ... könnte ebenfalls ein Array oder ein Hash mit key=1 sein
oder ein Objekt(Klasseninstanz mit [] operator)
Es gibt allerdings fairerweise auch Probleme. zB dass Fehler immer
öfter hin in die Laufzeit verlagert werden. Ist ärgerlich.
Darum finde ich dynamische Sprachen nützlich um das Problem besser zu
erkennen .. etwas lauffähiges in 10% der benötigten Zeit zu machen
und dann gegegebenfalls nach C,C++,Ada übertragen.
meine 2 cent
Um mal meine Meinunfg zu äußern: Was habt ihr gegen C?
->Wem die C(++)-Include-Guard stören solls lassen.
->Wer meint unbedingt sauber prgorammieren zu müssen, damit er nicht
den Überblick übers Programm verliert solls lassen.
->Wer meint, dass Bitgenaue Strukturen sinnvoll sind, obwohl die
Adressierung eh im Byte-Bereich stattfindet, solls lassen.
->Wer mit der uneingeschränkten Freiheit von C ( + InlineASM +
_emit_) nicht zurecht kommt, solls lassen.
->Wer keine Ahnung hat, ordentliche Algos zu schrieben, solls lassen.
->Wer stänigs nur nervige Bugs durch eigene Unachtsamkeit produziert,
soll lassen.
->Wem der/die Syntax von C zu einfach ist solls lassen.
->Wer etwas gegen schnelles Programmschreiben hat, solls lassen.
->Wer...
Zusammenfassung: C kann alles. Wer mit der Vielfalt der Möglichkeiten
überfordert ist und schon bei simplem Casts den Überlblick verliert,
der wird von C (durch seine vielseitge Syntax) nicht unterstützt und
verzweifelt schlussendlich - kann ich verstehen. Wer sich jedoch
dahinterklemmt, da bin ich mir sicher, kann es doch gar nicht
bereuen..
Andere Sprachen bringen vielleicht ihre Vorteile mit sich, welche
meistens in Vordefinierten Funktionen liegen. Mich persönlich stört es
aber, wenn ich nicht weiß, was mein Code macht. Syntaktische Vorteile
sind irgendwie ausgeschlossen. Ich hab noch keine Hochsprache mit
kürzerem Syntax gesehen...
MFG
PS: Sry, für die sture Meinung. Ich mag C(++)
Was soll das denn jetzt? Mich interessiert hier nicht die Meinung von C
Programmierern. Was die dazu denken ist mir klar. Also einfach mal
Klappe halten wenn nix zum Thema beigetragen wird.
Ich will einfach mal über den Tellerrand schauen um zu schauen was es
sonst noch auf der Welt gibt und nen Schritt in's 21. Jhd machen. Wenn
ihr im 19. Jhd stehenbleiben wollt ist das eure Sache.
Also bitte, konstruktive Kommentare zu Ada, kein
Programmiersprachenkrieg
Ich dachte, das sollte kein Glaubenskrieg sein? Hier wurde doch nur nach
Erfahrungen mit Ada gefragt...
Aber gut:
"Ich hab noch keine Hochsprache mit kürzerem Syntax gesehen..."
Also kennst du Perl nicht :)
OK, OK, Perl laeuft nicht auf Controllern, aber auf dem PC programmier
ich damit am liebsten.
Beispiel: Datei(wird als Parameter beim Aufruf uebergeben) oeffnen(mit
Abbruch und Fehlermeldung bei nicht vorhandener/nicht lesbarer Datei)
und die Zeilen mit Numerierung wieder ausgeben:
#!/usr/bin/perl
open IN, shift or die $!;
print ++$counter, " $_" while <IN>;
Zugegeben, das ist ein gekuensteltes Beispiel, aber dein Aequivalent in
C(++) haette 5-10 mal so viele Zeilen.
gruss, bjoern.
@bjoern
Perl ist auch dynamisch aber für mein Geschmack auch
zu chaotisch :)
hier Dein Beispiel im anderen Gewand
aber mit knappheit hast du recht, in C++
wären das paar Zeilen mehr
apropos sobald es zu /^(\w+)=(\d+)/i Sachen kommt
kann man C,Ada etc vergessen :)
#!/usr/bin/env python
import sys
cnt = 0
for datei in sys.argv[1:]:
for line in file(datei).readlines():
print cnt,line,
cnt += 1
liebe alte Bash
nl datei
#!/usr/bin/env ruby
cnt = 0
ARGF.each{|line| print cnt+=1, line}
Offtopic:
"Perl ist auch dynamisch aber für mein Geschmack auch zu chaotisch
:)"
Man kann TMTOWTDI auch als Kunstform ausueben...
siehe: http://www.perlmonks.org/?node=Obfuscated%20Code
"apropos sobald es zu /^(\w+)=(\d+)/i Sachen kommt kann man C,Ada
etc vergessen :)"
Ja, RegEx sehen fuer viele C-Programmier wie "Line-Noise" aus :)
Man sollte aber fairerweise erwaehnen, dass die ganzen Scriptsprachen
urspruenglich fuer Administrationsaufgaben gedacht waren. Und da
gehoert eine effiziente Syntax um auf Dateien zu arbeiten und Daten
umzusortieren natuerlich dazu. C andererseits ist universeller. Da kann
man selber seine Routinen fuer Listen, Hashes, sortieren, und was weiss
ich schreiben, so wie man es fuer effizient haelt. Nachteil ist halt,
dass man das machen muss.
Die Bash-Version finde ich uebrigens am Besten. Warum das Rad neu
erfinden? (wobei nl sicher in C geschrieben wurde)
Noch ein Perl-One-Liner, allerdings ohne die Datei direkt zu
oeffnen(also eigentlich eine Bash-Perl-Combo):
cat <DATEI> | perl -ne 'print ++$counter, " $_"'
So, das war mein letzter Post in diesem Thread, da ich noch nicht mit
Ada gearbeitet habe, und daher auch nichts konstruktives zum Thema
beitragen kann. Nur kurz meine Meinung dazu: Auf Controllern benutze
ich auch C, evtl. noch inline-asm. Ada ist sicherlich genauso maechtig,
aber wenn man eine Sprache kann, mit der man vertraut ist, und die sich
bewaehrt hat, sollte man dabei bleiben. Kommt aber sicherlich auch auf
die eigene Einstellung an. Ich will, dass meine Schaltungen das tuen,
was ich will. Ich bin nicht daran interessiert, dass ich es auf
verschiede Weisen realisieren kann. Ich habe auch kein Interesse daran,
dass mir andere nicht weiterhelfen koennen, weil ich eine exotische
Sprache benutze.
gruss, bjoern.
"Zugegeben, das ist ein gekuensteltes Beispiel, aber dein Aequivalent
in
C(++) haette 5-10 mal so viele Zeilen."
5*3Zeilen sind 15Zeilen. 3*10Zeilen sind 30Zeilen.
Wenn man jetzt von der Konsole aufm PC spricht, behaupte ich, ich hab
den Dateiinhlat sogar inerhalb von 12 Zeilen Byteweise umgedreht.
(C++)
FILE File = fopen(FileName, "w+b");
if (!File) {cout << "Fehler"; return; }
fseek(File, SEEK_END, 0);
int Size = ftell(File);
fseek(File, SEEK_SET, 0);
char* Buffer = new char[Size*2];
fread(Buffer, Size, 1, File);
for (int i = 0; i < Size; i++) Buffer[Size*2-i] = Buffer[i];
fseek(File, SEEK_SET, 0);
fwrite(Buffer+Size, Size, 1, File);
delete[] Buffer;
fclose(File);
So. Aber schluss damit. Ihr habt recht. Ich wollt bloß mal sagen, da
hier C(++) so schlecht gemacht wurde, dass es doch großteils an einem
selber liegt, wenn man damit nicht zu recht kommt. Unterhaltet euch
über Ada, aber lasst C in ruhe. Vergleichts doch lieber mit Palscal :)
MFG
"->Wer meint unbedingt sauber prgorammieren zu müssen, damit er nicht
den Überblick übers Programm verliert solls lassen."
Diesen Satz muss man sich auf der Zunge zergehen lassen.
"->Wer..."
Leute wie du, die statt ihren Werkzeugkasten zu verbessern darauf stolz
sind mit miesen Werkzeugen trotzdem irgendwas hingefrickelt zu bekommen
sind der Grund dafür dass es mit der Qualität von Software nicht
aufwärts geht. Sauberes Programmieren? Ach wo, solange nur ich durch
meinen Code durchblicke sichert das meinen Arbeitsplatz. Softwaretests?
Wozu denn, solange es Fehler gibt hab ich immer was zu tun. Gute
Architektur? Überflüssig, regelmäßig Neuschreiben geht doch auch.
Die Folgen dieser perfektionierten Rückständigkeit sieht man an
diversen Statistiken über gescheiterte Projekte, Fehler,
Sicherheitslücken, usw.
@Der Albi:
Respekt. Rumgehüpfe in Dateien und einen Puffer, der 2x so groß ist wie
die Datei selbst ;-)
Das sollte man aber noch optimieren ...
Grüße, Freakazoid
Was willst du mit diesem Spaghetticode-Beispiel eigentlich beweisen?
Dass dieses Programm in C/C++ nur 12-mal so lange ist wie in anderen
Sprachen?
File.read("test.txt").reverse
Ahaha, C ist also nichts für sicherheitskritische Anwendungen? Da
gackern ja die Hühner. Wieviele Betriebssysteme sind in C geschrieben?
(kleiner Tipp: alle. Einschließlich VxWorks, das in der Luft- und
Raumfahrt eingesetzt wird). Somit ist es totaler Schwachsinn aus
'Sicherheitsgründen' eine andere Sprache zu verwenden, wenn das OS
selbst in C geschrieben ist!
C hat sich nicht ohne Grund durchgesetzt. Es erlaubt die direkte
Kontrolle über Hardware ohne komplexe Dinge unmöglich oder ineffizient
zu machen, und es erzeugt schnellen, kompakten Code ohne viel
Overhead.
Klar kann man mit C auch Scheiße bauen. Das liegt dann aber am
Programmierer, an der Qualitätssicherung und am Auditing. Man kann mit
Ada genauso Müll produzieren? Beispiel gefällig? Erinniert sich jemand
an das schöne Feuerwerk mit der Ariane 5?
http://en.wikipedia.org/wiki/Ariane_5_Flight_501
500 Millionen $ in Rauch aufgelöst. Natürlich unversichert.
Back to Topic: wer hat schon ein wenig mit AVR Ada gearbeitet? Kann man
schon was über die Qualität und Stabilität sagen? Was kann und muß man
noch am Compiler verbessern?
Es ist eine Tatsache dass in C regelmäßig Bugs gefunden werden werden,
die in Ada prinzipiell gar nicht hätten auftreten können. Schau doch
mal in eine beliebige Bug-Datenbank was die Nummer-1-Ursache für
(speziell sicherheitskritische) Probleme ist: Buffer Overflows. Pointer
die hinzeigen wo sie nicht hinzeigen dürfen,
Index-Bereichsüberschreitungen, etc. Es würde mich sehr wundern wenn es
auch nur ein einziges größeres C-Projekt gäbe in dem noch nie eines
dieser Probleme aufgetreten ist. VxWorks ist da keine Ausnahme:
http://www.securityspace.com/de/smysecure/catid.html?id=11184
Das Ariane-Problem wird von Ada-Gegnern gerne zitiert, nur leider hat
es mit Ada überhaupt nichts zu tun.
auf nem kleinen avr find ich irgendwie ada noch nicht so wirklich
brauchbar da es wie gesagt noch nicht alle vorteile ausspielen kann...
sauberes C auf nem avr ist nicht das problem.. schlimmer wirds wenn man
mal um die 500kb code hat.. hab ich jetzt auf nem arm und da wirds
suchen dann schon unangenehm...
wie siehts eigentlich mit ada am arm aus ???
73
Andreas: das mit den Buffer Overflows ist so eine Sache ... die sind
eigentlich nur kritisch, wo Benutzerinput ausgewertet wird. In einer
Steuerung wird der Programmierer schon wissen, wie groß die Buffer sein
müssen, auch wenn er keine Überprüfung einbaut. Außerdem wird das auch
getestet. Bei einer Paßwortabfrage ist das was ganz anderes!
> Das Ariane-Problem wird von Ada-Gegnern gerne zitiert, nur leider> hat es mit Ada überhaupt nichts zu tun.
Mit was dann? Mit Pascal?
Hans: Nimms mir nicht übel, aber wenn 500kB Code für dich zu viel sind,
dann liegt das nicht an der Programmiersprache.
Zum Beispiel ist der Linux-Kernel ein klein wenig größer, trotzdem
gibts da keine Probleme. Alles nur eine Frage der Organisation.
Aber bei größeren Embedded-Projekten scheint C++ tatsächlich im Kommen
zu sein.
Ariane 5 hat nichts mit Ada zu tun.
Dort wurde die Steuerung einer Ariane 4 wiederverwendet ohne sorfältig
die Betriebsparamter zu überprüfen. Die Folge war eine Exception bei
einer Werteumrechnung, die bei A5 nicht mehr notwendig gewesen wäre.
Das und einiges mehr hat zur Zerstörung geführt.
> Andreas: das mit den Buffer Overflows ist so eine Sache ... die> sind eigentlich nur kritisch, wo Benutzerinput ausgewertet wird.> In einer Steuerung wird der Programmierer schon wissen, wie groß> die Buffer sein müssen, auch wenn er keine Überprüfung einbaut.
Wenn es um einen einfachen Regler geht wird man damit eher keine
Probleme haben, aber heutzutage hat ja fast jedes Gerät irgend eine Art
von Kommunikatationsschnittstelle, ob CAN, Ethernet, Bluetooth oder
RS-232. Ein Auto wird vermutlich keinen FTP-Server eingebaut haben,
aber vielleicht sendet ein Modul in eine Statusmeldung an der sich ein
anderes Modul verschluckt weil bei der Implementierung falsche Annahmen
gemacht wurden ("der ankommende String ist immer Null-terminiert",
"das Paket kann nie größer als 512 Byte sein", usw.)? Dann explodiert
in C das Programm, in Ada gibt es eine Exception, und wenn die
ordnungsgemäß verarbeitet wird passiert gar nichts. Weil man die
Gefahren von C erkannt hat wird in diesem Bereich oft mit
eingeschränkten C-Varianten (MISRA C) gearbeitet, die die Probleme
etwas entschärfen.
"->Wer meint unbedingt sauber prgorammieren zu müssen, damit er nicht
den Überblick übers Programm verliert solls lassen."
Autsch. Das tut weh.
Man sollte lieber diesem Grundsatz folgen:
"Software ist wie Unterwäsche, man zeigt sie nur her, wenn sie sauber
und ordentlich ist." (Gefunden in einem Forum)
Das heißt, ein sauberer Programmstil und vernünftige Dokumentation des
Werkes ergeben gut wartbaren Code, der sich auch nach Jahren noch
ändern lässt, ohne sich erst monatelang einarbeiten zu müssen.
Und bei der Gelegenheit kann man sich gleich noch Gedanken zum Thema
'Reusable Code' und modularem Programmaufbau machen.
Gruss
Jadeclaw.
@Der Albi
>5*3Zeilen sind 15Zeilen. 3*10Zeilen sind 30Zeilen.>Wenn man jetzt von der Konsole aufm PC spricht, behaupte ich, ich hab>den Dateiinhlat sogar inerhalb von 12 Zeilen Byteweise umgedreht.>(C++)
example.C:1: error: parse error before `=' token
example.C:3: error: `File' was not declared in this scope
example.C:3: error: `SEEK_END' was not declared in this scope
example.C:3: error: ISO C++ forbids declaration of `fseek' with no
type
example.C:3: error: initializer list being treated as compound
expression
example.C:4: error: `File' was not declared in this scope
example.C:4: error: `ftell' was not declared in this scope
example.C:5: error: `File' was not declared in this scope
example.C:5: error: `SEEK_SET' was not declared in this scope
example.C:5: error: ISO C++ forbids declaration of `fseek' with no
type
example.C:5: error: redefinition of `int fseek'
example.C:3: error: `int fseek' previously defined here
example.C:5: error: initializer list being treated as compound
expression
example.C:7: error: `File' was not declared in this scope
example.C:7: error: ISO C++ forbids declaration of `fread' with no
type
example.C:7: error: initializer list being treated as compound
expression
example.C:8: error: parse error before `for'
example.C:8: error: parse error before `;' token
example.C:8: error: syntax error before `++' token
example.C:9: error: `File' was not declared in this scope
example.C:9: error: `SEEK_SET' was not declared in this scope
example.C:9: error: ISO C++ forbids declaration of `fseek' with no
type
example.C:9: error: redefinition of `int fseek'
example.C:5: error: `int fseek' previously defined here
example.C:9: error: initializer list being treated as compound
expression
example.C:10: error: `File' was not declared in this scope
example.C:10: error: ISO C++ forbids declaration of `fwrite' with no
type
example.C:10: error: initializer list being treated as compound
expression
example.C:11: error: parse error before `delete'
example.C:12: error: `File' was not declared in this scope
example.C:12: error: ISO C++ forbids declaration of `fclose' with no
type
nicht schlecht fuer 12 zeilen code :)
AVR-Ada unterstützt keine Exceptions und Tasks, ob die
Bereichsüberprüfungen zur Laufzeit funktionieren weiß ich nicht.
Ich habe gerade RTEMS entdeckt, das ist ein RTOS für u.a.
ARM-Prozessoren das Ada unterstützt (inkl. Tasks):
http://www.rtems.com/wiki/index.php/RTEMSAda
Beispielanwendung (leider ohne Sourcecode-Download g):
http://www.rtems.com/wiki/index.php/Avenger
Es sieht so aus als ob das auch für kleinere ARMs geeignet ist (SAM7
und LPC2xxx), fertige Portierungen habe ich leider noch nicht gefunden.
Offtopic:
Sorry, ich kanns mir nicht verkneifen.
@Der Albi:
Hier eine lauffaehige Variante deines Gegenbeispiels:
#!/usr/bin/perl
open IN, shift or die $!;
print scalar reverse <IN>;
Und wenn du den ganzen Schlunz noch dazuschreibst, den du unter den
Tisch fallen lassen hast(includes, main{}), bist du auch wieder bei
mehr als dem 5-Fachen.
So, jetzt halt ich mich wirklich raus...versprochen!
gruss, bjoern.
Thread beobachten
Seitenaufteilung abschalten