Hallo,
ich weiß, dass es schon mehrere 'Welche Programmiersprache?'-Threads
gibt, und ich habe auch da schon etwas recherchiert. Aber ich denke,
dass meine Frage etwas raushaut.
Kurze Vorrede:
Ich bin Physiklehrer, der auf einem Mac mit Xcode freizeitprogrammiert.
Mit Xcode kann ich auch problemlos C-Code für den ATmega8 programmieren
und brennen. Xcode ist eine Mac-Programmierumgebung, die viele
Programmiersprachen ermöglicht: C, Objective-C, C++, Java, Python, Ruby.
Ich selbst kann ein bisschen C- und Objective-C.
Meine Schüler (Oberstufe) leben in der Windoofs-Welt. Sie wollen einen
Quadrokopter bauen, weshalb sie sich mit der
Mikrocontrollerprogrammierung auseinandersetzen wollen. Ich selbst bin
ihnen da etwa einen Monat voraus, also auch noch Anfänger. Ich schätze,
dass meine Schüler Anfänger- bis Fortgeschrittenen-Erfahrungen in der
Visual-Basic-Programmierung haben. Außerdem können sie (und ich) ein
Roboter-Mikrocontroller-Interface in dessen Basic-Dialekt programmieren.
Sie sind wettbewerbserfahren und haben eine gute 'Frustrationstoleranz'.
Frage 1:
In vielen Forumsbeiträgen wird für Assembler geworben, weil es näher an
der Hardware (bzw. dem Maschinencode?) ist. Nach meinem Umschiffen von
Assembler sowie den C-Programmiererfahrungen, die ich jetzt habe, kann
ich diese Argumentation nicht so recht nachvollziehen, da ich zur
C-Programmierung genauso die Register verwalten muss. Da ich möchte,
dass meine Schüler ihr Abi packen und daher auch nur
Freizeitprogrammierer bleiben, tendiere ich z.Z. dazu, meinen Schülern
die C-Programmierung ans Herz zu legen, weil ich sie da parallel beraten
könnte. Einzige Alternative sehe ich in BASCOM, weil sie hier halt schon
Basic-Erfahrungen einbringen können. Wie seht ihre das?
Frage 2:
Für Steuerungsaufgaben wäre natürlich langfristig eine PC-Programmierung
nett. Nach den Forumsbeiträgen zu urteilen würden die meisten C# bzw.
C++ favorisieren, wo die Schüler ihre (dann schon vorhandenen)
C-Kenntnisse einbringen könnten. Alternative wegen Basic-Erfahrung:
Visual-Basic. Da ich annehme, dass die Schüler nach dem Abitur in Sachen
'Programmierung & Technik' weiter machen und studieren werden, wäre auch
hier eine längerfristige Lösung wichtig, und nicht nur ein möglichst
schnelles Ergebnis. Zum Zweiten: Wie seht ihr das?
Vielen Dank für Eure, hoffentlich klärenden Beiträge. Berücksichtigt
dabei bitte auch, dass ich sie beraten möchte. Also bitte keine schrägen
Individual-Empfehlungen abseits der hier genannten Programmiersprachen,
außer natürlich es macht wirklich absolut Sinn.
dibujo
An der der FH wo ich studiere wird im ersten und zweiten jahr alles in c
und oder c++ unterrichtet .....
also wäre es von dem standpunkt her nicht völlig falsch;)
ASM halte ich für übertrieben! Die systeme sind mitlerweile alle so
leistungsfähig das das meiner ansicht nach nicht nötig ist! Sollte man
sehr sehr sehr zeit kritische Routienen brauchen so kann man diese in
ASM noch in das c programm einbinden.... und für den pc ist asm eh
schwachsinnig.... Ich denke es wäre sinnvoll mit einem kleinen Projekt
anzufangen;) direkt an so ein riesen projekt dran ist denke ich
aussichtslos
Ich würde auch für c plädieren. Bei mir an der Hochschule war das damals
auch die Standardsprache für solche Zwecke. Wir haben nur c und c++
programmiert. Mit c kann man wirklich nichts falsch machen und die Kids
lernen was Vernünftiges.
Ich finde die Sprache c für die µC Programmierung auch nicht besonders
schwer. Wenn es an die Windowsprogrammierung geht, gibts allerdings
einfachere Sprachen als C++.
Grüße
Jonny
> Mit Xcode kann ich auch problemlos C-Code für den ATmega8> programmieren und brennen.
C ist auch die Standardsprache für Mikrocontoller. Andere Sprachen gibts
normal nicht. Dass es für den AVR auch Bascom und ein Pascal Derivat
gibt ist eher Hobbyprogrammierern zu verdanken. Für Typen die nur in der
Industrie benutzt werden gibt i.a. vom Hersteller einen C-Compiler und
das wars.
> In vielen Forumsbeiträgen wird für Assembler geworben, weil es näher an> der Hardware (bzw. dem Maschinencode?) ist. Nach meinem Umschiffen von> Assembler sowie den C-Programmiererfahrungen, die ich jetzt habe, kann> ich diese Argumentation nicht so recht nachvollziehen,
Mit Assembler kann man evtl. und auch nur vielleicht mal da und dort ein
Byte sparen, aber wenn man kein kostensensitives Produkt in
Millionenstückzahl produziert wird in der Industrie in C programmiert.
-> Der Mehraufwand
> die C-Programmierung ans Herz zu legen, weil ich sie da parallel> beraten könnte. Einzige Alternative sehe ich in BASCOM, weil sie hier> halt schon Basic-Erfahrungen einbringen können.
Ich würde die Bedeutung der Programmiersprache nicht überschätzen. Es
ist doch so dass es für jedes Konstrukt in Basic ein Entsprechendes in C
oder Pascal (oder in jeder anderen prozedurorientieren Sprache, den
ganzen "Algol68"-Ähnlichen) gibt, wahrscheinlich sogar 1:1. Nur die
Syntax ist ein wenig anders. Aber da - denke ich - werden die Schüler
sich recht schnell umstellen können.
Das beste Beispiel dafür ist noch Borlad C++. Die hatten ihr Borland
Delphi (ein Pascal mit OO-Erweiterungen) zuerst draussen, und als sie
gesehen habe dass der Markt aber auch C++ will, haben sie ihre C++-IDE
gestrikt indem sie ihrer IDE einen C++-zu-Delphi-Preprocessor
drangeklatscht haben. Der hat nur die Sytax umgestellt, alle Konstrukte
und Programmierideen haben 1:1 in beiden Sprachen funktioniert.
(Deswegen hasse ich auch alle Basic vs. C vs. Pascal Diskussionen, die
Sprachen sind genau gleich, nur mit leicht abgewandelter Syntax)
Viel wichtiger und kritischer sehe ich die "Programmierumgebung", d.h.
dass man den Compiler mitsamt der meist vorhandenen IDE (intgrated
development environment, d.h. das ganze Fenster-Zeug und Klinki-Bunti
drumrum) und das Programmierkabel im Griff hat. Dass man z.B. weiß wenn
dieser oder jene seltsame Fehler auftaucht, woran das liegt ("aah, das
Problem hatte ich schon mal, da muß noch dieses Verzeichis in den Pfad
oder die Zeile in das Makefile oder ..."). Weil das kann ewig viel Zeit
kosten. Eigentlich würde ich raten die selbe Programmierumgebung im
Unterricht zu benutzen die du schon von deinem Privatrechner kennst,
aber die Schule hat wahrscheinlich keine Macs. Gibts das "Xcode" auch
für das OS das die Rechner an der Schule haben?
Ansonsten musst du dich an das Forum hier halten wenns mit WinAVR oder
dem AVR-Studio Probleme gibt.
HTH
Randy
Asssembler, denn mit allem anderen lernt man die Grundlagen nicht und
kann deshalb nicht effizient proggen. Schön wäre es auch, wenn mal
jemand nen vollständigen Befehlssatz (so wie die kurze AVR-Asm Referenz,
die ist extrem super) vom 80x86 mit allen Erweiterungen (MMX, Pentium X,
SSE etc.) veröffentlichen würde, denn sonst muss man sich den Kram alles
im Internet zusammensuchen. Ausserdem ist ASM sehr praktisch um
willentlich und unwillentliche Bugs zu entfernen :)
Das ist kompletter Unsinn. Man braucht keines Wegs Assembler zu lernen
um effizient programmieren zu können. C ist maschinennah genug um damit
sehr effizient zu programmieren. Will man sein Leben angenehm gestalten
ist auch C++ sehr gut geeignet. Entgegen vieler Meinungen hier kann man
auch wunderbar C++ als erste Programmiersprache lernen. C++ ist zwar
viel komplexer als etwa C, BASIC oder Pascal, aber von der Komplexität
sieht man am Anfang nicht viel. Man fängt ja nicht gleich mit templates
und Polymorphie an.
Ich denke auch, dass die Programmierumgebung nicht vernachlässigt werden
sollte.
Gerade Anfängern vergeht häufig schon die Lust am Programmieren, bevor
sie das System überhaupt zum Laufen gebracht haben.
Mit C bzw. C++ kann man nichts falsch machen. Selbst wenn man später
Visual Basic oder Delphi oder Java nutzen möchte, fällt dies mit C
Kentnissen wesentlicher einfacher.
Darum möchte ich an dieser Stelle Anfängern, die einen Einblick in die
professionelle Programmentwicklung bekommen möchten, noch einmal auf die
Seite http://www.haiq.info hinweisen.
Dort wird als erstes in 3 Stufen die komplette Programmierumgebung mit
den OpenSource Paketen von Trolltech (Qt4), dem OpenSource Compiler
MinGW, sowie der OpenSource IDE (HaiQ) installiert.
Danach geht es direkt in die Programmierung (10 Lektionen, learning by
doing). Und zwar unabhängig von Microsoft (für alle gängigen
Betriebssysteme geeignet).
Ich würde einem Anfänger, aus eigener Erfahrung, auch nicht empfehlen,
vorher dicke Lehrbücher zu studieren. Am Anfang ist das Problem, dass
man das Wesentliche noch nicht vom Unwesentlichen unterscheiden kann und
somit gezwungen ist, sich alle reinzuziehen, was am Anfang mehr
verwirrend denn hilfreich ist.
Nach dem Lehrgang sind die Leute jedenfalls so weit, dass sie einen
umfassenden Einblick in die graphische C bzw. C++ Entwicklung erworben
haben, um selbst entscheiden zu können, wie (und ob überhaupt) sie damit
weitermachen wollen. Dann können sie auch den Ausführungen in
Lehrbüchern folgen und haben schon mal eine 'bildliche' Vorstellung
davon, was jene seltsamen Begriffe und Abkürzungen und ... und ... und
... überhaupt bedeuten.
Und laßt Euch nicht von den 'Profis' verrückt machen. So schwer, wie die
es oft machen, ist Programmieren gar nicht. Man muß nur den richtigen
Einstieg finden, um nicht schon zu Beginn den Spaß daran zu verlieren.
In diesem Sinne ... good coding ...
Habe mit Basic angefangen, danach mit asm, damit konnte man
Sachen machen, die mit Basic nicht gingen! (25 Jahre her)!
Hatte danach einen Abstecher zu Pascal, und bin wieder bei
Basic (Visual-Basic, Bascom) und asm gelandet!
Ich behaupte, mit dieser Kombination kann man (nicht unbedingt ich)
alles, was aus dem C Lager kommt, bezüglich Entwicklungszeit und
Programmausführungsgeschwindigkeit in den Schatten stellen!
Es gibt aber auch Nachteile:
Basic wird selten (gar nicht) an Hochschulen gelehrt, dadurch sind
nur wenige gute Quelltexte im Internet verfügbar.
siehe
http://nehe.gamedev.net/
dort fehlen zu einigen Lektionen die Basic Quellen
Da die meisten der proffessionellen Progs in C programmieren
und Basic nicht verstehen wollen, halten sich hartnäckig
die Vorurteile: Basic ist langsam, hat einen großen Footprint,
keine Zeiger, keine Datenfelder, keine Vererbung .....
Diese Aufzählung lässt sich beliebig erweitern.
Nochmal an alle C-Leute DEM IST NICHT SO.
Basic hat noch ein Nachteil:
Man wird als Anfänger nicht zum struktuierten Programmierung
gezwungen. Dieser Nachteil kann sich aber später zu einem
riesen Vorteil wandeln! Nämlich dann, wenn die C-Leute
komplette Klassenstrukturen durch den Ram ziehen und sich
wundern, dass ihr Programm nicht unter einem GByte Hauptspeicher
läuft! (das war jetzt übertrieben aber beschreibt trotzdem
das Grundproblem)
so zum Schluß:
Jede Hochsprache hat Vor- und Nachteile, darum haben alle
ihre Berechtigung! Wer das Geklammer in C bzw. in Pascal
mag, soll es tun.
Anmerkung:
Kann C und Pascal Quellen lesen möchte aber nicht in diesem Stil
programieren müssen!
Fred
Wenn ihr schon eine gewisse Basic-Affinität habt, dann schau dir mal
RealBasic an!
http://www.application-systems.de/realbasic/
Das gibts für Mac, Windows und Linux in identischen Versionen und man
kann auf jeder Plattform auch für die jeweils anderen lauffähige
Programme compilieren. Fertige Programme benötigen keine Installation
und bestehen nur aus einer einzigen Datei, es ist keine extra
Laufzeitumgebung oder RuntimeLib nötig. Das bietet so m.E. z.Zt. keine
andere IDE.
Damit kann man natürlich nicht für Mikrocontroller programmieren, aber
für Desktop und Notebook.
Und bevor alle die, die Basic nicht mögen (ist jedem selber überlassen),
wieder "Buh" und "Bäh" rufen: RB ist ein modernes, objektorientiertes
System mit Klassen, Methoden und Funktionen. Man kann eigene Klassen
erstellen oder von vorhandenen ableite und erweitern.
Es gibt praktisch Nichts, was nicht geht, z.B. Netzwerk-, Internet und
Multimedia, Grafik (Pixel und Vektor), Datenbankzugriffe (MySQL, Oracle,
Postgre, OpenSQL, SQLLite, ODBC ...), PDF erstellen/lesen,
Systemzugriffe (die schränken dann antürlich die Plattformunabhängigkeit
ein), Schnittstellen (seriell, parallel, USB), Drucken usw.
Ich mache seit ca. 5 Jahren große kommerzielle Projekte mit Realbasic
und habe es bisher nicht bereut.
Frank
Ich hab das früher ähnlich gemacht. Lange Zeit Basic und dann Assembler
dazu (erst über CALL ABSOLUTE, später dann über libs). War auch immer
der Meinung, dass man C/C++ einfach nicht braucht.
Irgendwann bin ich dann doch umgestiegen und bin heute der Meinung, dass
Basic (inzw. Visual Basic) zwar ganz nett für kleine Sachen ist, sonst
aber nix taugt.
In einer Schule ist es wahrscheinlich wirklich gut aufgehoben, aber
später bei richtigen Projekten wird man (eigentlich zurecht) ausgelacht,
wenn man mit Basic ankommt.
Hallo,
> In einer Schule ist es wahrscheinlich wirklich gut aufgehoben, aber> später bei richtigen Projekten wird man (eigentlich zurecht) ausgelacht,> wenn man mit Basic ankommt.
Ich will nicht bestreiten, dass es so ist. Ist am Ende auch jedem seine
Sache. Mich würde aber mal interssieren, warum das so ist. Ich vermute,
dass die meisten heutigen Basic-Gegner auf ihrem Kenntnisstand von MS-
bzw. QBASIC o.ä. stehengeblieben sind - dann hätten sie natürlich recht.
Irgendwie scheinen nur wenige zur Kenntnis zu nehmen wollen, dass auch
Basic-Dialekte weiterentwickelt werden. Und ob ich nun "if ... then ...
end if" schreibe oder das Ganze in geschweifte Klammern, ist nun sowas
von egal.
Frank
Ob sich BASIC nun weiter entwickelt oder nicht, BASIC ist und bleibt ein
Beginners All-purpose Symbolic Instruction Code - eine reine
Anfänger-Programmiersprache.
Hat denn BASIC Versionskontrollsysteme (hmm... hässliche Übersetzung)
ala CVS oder Subversion? Wie schaut es mit fertigen Make-Skripts aus?
Wenn ich ein großes Projekt hab will ich nicht jedesmal alles neu
übersetzen müssen. Ist es möglich mit mehreren Leuten gleichzeitig
weiterzuarbeiten?
Das allein zur Umgebung - die Sprache selbst erlaubt afair keine
ordentliche Trennung bei großen Projekten. Selbst bei C++ hat man
festgestellt, dass das noch etwas mangelhaft ist - und Namespaces
eingeführt, zusätzlich zu all den Mechanismen die C und C++ ohnehin
schon bieten.
Header sind in C/C++ auch ein enormer Vorteil, Java hat Packages, und so
hat jede größere Sprache ihre Mechanismen große Projekte zu kapseln. Hat
Basic sowas?
Denk mal an den Linux Kernel. Ich hab da eben mal sloccount drübergejagt
(Programm das Codezeilen zählt und Sprachen zuordnet, dabei werden
doppelte Sachen ausgefiltert und Leerzeilen, Kommentare etc. auch
weggelassen).
Das Ding enthält 5 Mio. Codezeilen, aber jedes Modul etc. für sich sieht
nur einen klitzekleinen Teil davon. Mach sowas mal mit Basic.
Multithreading ist mit Basic auch ein Problem (hat sich da mit .net was
verbessert? Bei VS 6 würd ich sagen da gibt's kein Problem - es
existiert einfach nicht).
> Hat denn BASIC Versionskontrollsysteme (hmm... hässliche Übersetzung)> ala CVS oder Subversion?
RealBasic speichert seine Quellcodes als XML und kann deshalb mit CVS
verwaltet werden.
> Wenn ich ein großes Projekt hab will ich nicht jedesmal alles neu> übersetzen müssen.
Das Übersetzten selbst großer Projekte (z.B. 2 MB Quellcode) dauert nur
Sekunden, ist egal ...
>Ist es möglich mit mehreren Leuten gleichzeitig> weiterzuarbeiten?
Man kann Codesegmente als externe Module oder Klassen irgendwo im Netz
ablegen. Dann können verschiedene Leute daran arbeiten.
> Das allein zur Umgebung - die Sprache selbst erlaubt afair keine> ordentliche Trennung bei großen Projekten.
s.O., nach der OO-Methode, z.B.
main.ok=DB_Zugriff.open(User.loginData)
wobei z.B. DB_Zugriff ein in sich geschlossenes Modul sein kann, main.ok
eine boolesche Variable des Fensters main und user.logindata eine
Eigenschaft des Objektes User ...
> Multithreading ist mit Basic auch ein Problem (hat sich da mit .net was> verbessert? Bei VS 6 würd ich sagen da gibt's kein Problem - es> existiert einfach nicht).
RB kann Threads, ohne NET auf allen 3 Plattformen.
Frank
> > Hat denn BASIC Versionskontrollsysteme (hmm... hässliche Übersetzung)> > ala CVS oder Subversion?>> RealBasic speichert seine Quellcodes als XML und kann deshalb mit CVS> verwaltet werden.
Heißt das, man kann den Quelltext nicht mit jedem beliebigen Texteditor
bearbeiten?
Man kann wählen bzw. voreinstellen, zwischen
- einem eigenen komprimierten Format (Standard)
- XML
- nur Text
Beim Laden wird das Format automatisch erkannt.
Frank
Also als "Anfänger" einen Quadrokopter bauen zu wollen halte ich für
sehr mutig. Ich hab mich mal ein bisschen hereingelesen, was alles
gebraucht wird an Bauteilen und vor allem Algorithmen, holla die
Waldfee!
Das meiste davon hört sich eher nach Verlegenheitslösung an.
Frank Esselbach wrote:
> RealBasic speichert seine Quellcodes als XML und kann deshalb mit CVS> verwaltet werden.
Kann Visual Basic das auch? Ist Quellcode zwischen den beiden
austauschbar? Wie schon gefragt wurde - lässt sich Realbasic Code auch
mit anderen Editoren öffnen?
Selbst in visual studio c/c++ kann ich mir aussuchen welchen Compiler
ich heute nehmen will - bin also unabhängig. Geht das auch bei Basic?
>> Wenn ich ein großes Projekt hab will ich nicht jedesmal alles neu>> übersetzen müssen.>> Das Übersetzten selbst großer Projekte (z.B. 2 MB Quellcode) dauert nur> Sekunden, ist egal ...
Nein, ist es nicht. Der Linux Kernel ist gepackt (!) schon ~40MB groß,
entpackt ist meiner 500MB. Wie sieht es da aus?
Der Kernel ist übrigens gemessen am Gesamtsystem eine eher kleine, aber
sehr komplizierte Komponente. Gegen zB. KDE ist der Linux Kernel ein
Winzling.
Noch vergessen: Gibt es alternative Compiler?
>>Ist es möglich mit mehreren Leuten gleichzeitig>> weiterzuarbeiten?>> Man kann Codesegmente als externe Module oder Klassen irgendwo im Netz> ablegen. Dann können verschiedene Leute daran arbeiten.
Das meinte ich nicht. Gibt es Möglichkeiten für alle Entwickler
einsehbar bestimmte Sachen zu sperren, damit solang niemand anders an
der selben Sache weiterentwickelt?
Für sowas braucht es eigentlich ein ausgewachsenes
Versionskontrollsystem.
>> Das allein zur Umgebung - die Sprache selbst erlaubt afair keine>> ordentliche Trennung bei großen Projekten.>> s.O., nach der OO-Methode, z.B.>> main.ok=DB_Zugriff.open(User.loginData)>> wobei z.B. DB_Zugriff ein in sich geschlossenes Modul sein kann, main.ok> eine boolesche Variable des Fensters main und user.logindata eine> Eigenschaft des Objektes User ...
Das ist keine ordentliche Trennung. Im Namespace hast du nach wie vor
alle Module etc. rumfliegen. Wie gesagt, sowas kann C, C++, Java, etc.
auch - und weil es nicht reicht kennen die alle noch weitergehende
Konzepte.
Man könnte es zwar auch einzig und allein über Module machen, aber man
könnte auch alles in Assembler entwickeln.
>> Multithreading ist mit Basic auch ein Problem (hat sich da mit .net was>> verbessert? Bei VS 6 würd ich sagen da gibt's kein Problem - es>> existiert einfach nicht).>> RB kann Threads, ohne NET auf allen 3 Plattformen.
Gibt es dafür gute Debugger? Wie sieht es mit Interthreadkommunikation
aus?
Wie gesagt - schaut alles nach Verlegenheitslösung aus. Klar
funktioniert das für einen Hobbyprogrammierer, da funktioniert das
mitunter sogar besser als eine ausgewachsene Lösung, weil man auch ohne
lange Einarbeitungszeit damit klarkommt.
Aber bei größeren Sachen stößt man schnell an Grenzen.
Also ich würde einfach C einführen. Das ist in dem Bereich einfach der
Standard. Ein wenig ASM am Rande hat aber sicher noch niemandem
geschadet. Das fördert häufig das Verständniss für die internen Abläufe.
Als Entwicklungs-Umgebung auf jeden Fall AVR-Studio+WinAVR, damit können
die auch zuhause problemlos arbeiten. Und dank GCC kann dann auch jeder
die Plattform nutzen die er gerne hätte (Windoof, Mac, Linux,
wasauchimmer)
Wichtiger als die Programmiersprache finde ich aber das die Schüler
lernen die Hardware und ihre Abläufe zu verstehen. Ausserdem sollten sie
dabei auch lernen strukturiert zu arbeiten und sich vorher ein paar
Gedanken zu machen bevor zu drauf loshacken. ;)
Also ich habe an der Schule und an der Hochschule am Anfang zunächst
immer Assembler gelernt, keine großartigen optimierten Programme, aber
z.B. eine etwas schwierigere Aufgabe "wie kann man eine Multiplikation
zweier Binärzahlen lösen wenn es keine Multiplikationsbefehl gibt" Oder
wie wird ein Unterprogramm geschrieben (Sprungbefehle). Ich finde das
sehr wichtig, dass man Assembler-Grundzüge lernt, denn wenn man später
mal Fehler im C-Code suchen muss, dann kann es passieren dass man wieder
auf der Assemblerebene landet.
Nach jeweils einem Semester bzw. Schuljahr wurde dann C eingeführt, da
kamen dann auch mal komplexere Sachen, LCD ansteuern,
RS232-Kommunikation, I2C-Bus, SPI-Schnittstelle.
Randy schrieb:
[...]
> Ich würde die Bedeutung der Programmiersprache nicht überschätzen.
[...]
Naja, also das letzte mal, als ich mir BASIC angeschaut habe, war das
auf dem C64. ;-)
Als ich da mal was schönes abstraktes programmieren wollte,
und zwar ein Programm, das mir die kürzeste Verbindung zwischen zwei
Bahnhöfen im Berliner U-Bahn-Netz ausgibt, da war's das dann mit Basic.
Zumindest das Commodore-basic von damals ermögglichte mir nicht eine
Möglichkeit, solche Probleme zu lösen (oder jedenfalls nicht sinnvoll).
Es gab nicht die entsprechenden Datenstrukturen, die dazu notwendig
gewesen wären. Das hatte mir damals einen riesen Frust eingebracht und
meine Computerbegeisterung stark abgebremst.
Als ich dann später C lernete, sah ich, daß dies zwar als Sprache solche
Datenstrukturen auch nicht mitbringt, mir aber die Möglichkeit gibt,
diese selber zu bauen.
Inwieweit sowas nun beim Controller-programmieren von Wichtigkeit ist?
Hmhhh, kommt wohl drauf an, wie simpel/primitiv man seinen Code bauen
will, oder wie komplexe Sachen man implementieren will.
Vielleicht ist da auch was größeres als ein 8-Bit-AVR von nöten, wenn
man wirklich komplexe Sachen bauen will, oder muss sich seine eigene
Sprache und seinen eigenen Compiler bauen.
Aber ich denke, wenn man schon eine Hochsprache wie C nimmt, will man
vielleicht auch die Möglichkeiten ausschöpfen.
Ansonsten darf ich mal festhalten, daß der Befehlssatz des AVR ja doch
ziemlich C-ähnlich ist, und wenn man keine sehr abstrakten Dinge baut,
kann man auch fast gleich beim Assembler bleiben.
Und hin und wieder muss man auch Assembler nehmen, da der C-Code ggf.
nicht das bietet, was man sucht.... zum beispiel musste ich letztens
Assembler-Code nutzen, um die Taktrate eines AVR's umzuprogrammieren,
weil der vom avr-gcc gelieferte Code nicht nutzbar dafür war. (brauchte
zu viele Taktzyklen).
Alles in Allem tendiere ich daher dazu, bei etwas größeren projekten C
zu nehmen, und aber auch Assembler zu kennen, wenigstens mal sich das
anzuschauen. Am besten auch mal ein komplettes projekt in Assembler zu
machen (auch wenn es nur was kleines ist).
BASIC halte ich für Schüler als zum kennen lernen OK.
Man wird ja nicht gleich zu krasse Sachen programmieren wollen, wenn man
die Materie gerade kennen lernen will.
Wenn man aber z.B. Robotik machen will (wie bei mir demnächst), und auch
mal etwas komplexere Algorithmen nutzen will, also etwas abstrakter an
die Sache dran geht, dann ist absehbar, daß man mit BASIC nicht weit
kommen wird.
[...]
> (Deswegen hasse ich auch alle Basic vs. C vs. Pascal Diskussionen, die> Sprachen sind genau gleich, nur mit leicht abgewandelter Syntax)
[...]
Wenn man immer nur
setze_Port(), lösche_Port(), und if-then-else sowie wait_soundso_ms()
macht, stimmt das.
Wenn man aber auch mal abstraktere Sachen bauen will,
kommt man um eine geeignete Programmiersprache nicht herum.
Aber dies basiert auf dem BASIC von Commodore; inwieweit denn der BASCOM
auch wirklich inder Lage ist, andere Datenstrukturen anzubieten, weiss
ich nict, aber soweit ich das gesehen habe, was so im netz zu finden
war, sieht es da nicht so rosig aus.
Oliver
Ich schrieb:
> Asssembler, denn mit allem anderen lernt man die Grundlagen nicht und> kann deshalb nicht effizient proggen.
[...]
Sehe ich genauso.
Anfangs wollte ich nur Assembler nehmen; aber auf Arbeit wird C
genommen.
Also mache ich nun beides. :-)
Fred schrieb:
> Habe mit Basic angefangen, danach mit asm, damit konnte man> Sachen machen, die mit Basic nicht gingen! (25 Jahre her)!
heheh.... siehste: mit BASIC alleine ging es nicht.
[...]
> Ich behaupte, mit dieser Kombination kann man (nicht unbedingt ich)> alles, was aus dem C Lager kommt, bezüglich Entwicklungszeit und> Programmausführungsgeschwindigkeit in den Schatten stellen!
[...]
Wenn man gut C kann, und abstrakt programmiertt, kann man das evtl. auch
wieder toppen ;-)
>> Es gibt aber auch Nachteile:>> Basic wird selten (gar nicht) an Hochschulen gelehrt, dadurch sind> nur wenige gute Quelltexte im Internet verfügbar.
Welches BASIC denn?
da gibt es wohl mehr BASIC's als es C's gibt :-)
[...]
> Da die meisten der proffessionellen Progs in C programmieren> und Basic nicht verstehen wollen, halten sich hartnäckig> die Vorurteile: Basic ist langsam, hat einen großen Footprint,> keine Zeiger, keine Datenfelder, keine Vererbung .....> Diese Aufzählung lässt sich beliebig erweitern.>> Nochmal an alle C-Leute DEM IST NICHT SO.
Es gibt in BASIC Pointer?
Welches BASIC ist das denn?
Das ist mir jedenfalls neu.
Kann man sich in BASIC auch eigene Datenstrukturen bauen?
>> Basic hat noch ein Nachteil:> Man wird als Anfänger nicht zum struktuierten Programmierung> gezwungen. Dieser Nachteil kann sich aber später zu einem> riesen Vorteil wandeln! Nämlich dann, wenn die C-Leute> komplette Klassenstrukturen durch den Ram ziehen
C hat keine Klassen.
Das gibt es bei C++, aber nicht bei C.
Und wer ein bischen mitdenkt, beim programmieren,
der macht seinen Code auh schlank.
Unter anderem durch Auswahl geeigeneter Datenstrukturen.
> und sich> wundern, dass ihr Programm nicht unter einem GByte Hauptspeicher> läuft! (das war jetzt übertrieben aber beschreibt trotzdem> das Grundproblem)
Das wäre im prinzip auch bei BASIC ein Problem.... ausser, man kann so
komplexe Sachen damit garnicht bauen... was meiner Meinung nach der Fall
ist.
[...]
> Kann C und Pascal Quellen lesen möchte aber nicht in diesem Stil> programieren müssen!
[...]
Tja, die Syntax von BASIC (BASCOM) habe ich mir vorhin nochmal
angeschaut.
Sieht schon recht leserlich aus.
Es gibt durchaus besser lesbaren Code als das meiste C-Zeugs.
Gibt auch wesentlich bessere Sprachen als BASIC, Pascal, C, C++ usw.
aber nicht für's MicroController-Umfeld zugeschnitten.
I_ H. schrieb:
> Hat denn BASIC Versionskontrollsysteme (hmm... hässliche Übersetzung)> ala CVS oder Subversion?
Man kann das versionskontrollsystem für jeglichen Programmcode benutzen.
Was hat das denn mit der programmiersprache zu tun?!
...tse.
Frank Esselbach schrieb:
>> Hat denn BASIC Versionskontrollsysteme (hmm... hässliche Übersetzung)>> ala CVS oder Subversion?>> RealBasic speichert seine Quellcodes als XML und kann deshalb mit CVS> verwaltet werden.
Häh?
Man kann doch den Sorurce, den man tippt mit cvs bzw. svn verwalten...
tim schrieb:
> Also ich habe an der Schule und an der Hochschule am Anfang zunächst> immer Assembler gelernt, keine großartigen optimierten Programme, aber> z.B. eine etwas schwierigere Aufgabe "wie kann man eine Multiplikation> zweier Binärzahlen lösen wenn es keine Multiplikationsbefehl gibt" Oder> wie wird ein Unterprogramm geschrieben (Sprungbefehle).
Soweit stimme ich zu.
> Ich finde das> sehr wichtig, dass man Assembler-Grundzüge lernt, denn wenn man später> mal Fehler im C-Code suchen muss, dann kann es passieren dass man wieder> auf der Assemblerebene landet.
Hier sehe ich das anders, jedenfalls, wenn die Diskussion hier so weit
weg vom Microkontroller ist.... im Unix-/Linux-Umfeld musste ich mir nie
den Assemblercode anschauen, um C-Probleme zu lösen.
Aber letztens, beim Prograsmmieren von Startcode für einen AVR-Chip
musste ich das tatsächlich.
Dann müssten wir die Diskussion aber wieder zurück zum Theme Controller
führen.
Wenn es hier ganz allgemein um Programmiersprachen geht,
nicht auf controller bezogen, dann darf ich bitte noch OCaml und Haskell
erwähnen, sowie Python.
Für deftige Projekte im Unixoiden Umfeld würde ich zu OCaml raten.
Wenn man viele Libraries braucht und Performance nicht so ein Problem
darstellt, oder man auch GUI-zeugs oder Web-zeugs machen will, kann man
mit Python gut voran kommen. (Oder mit Perl; Python ist aber noch besser
strukturiert als Perl.)
Für Controller-Zeugs steht IMHO nur C und Assembler zur Debatte,
aber meine BASIC-kenntnisse sind ein paar Dekaden alt.
Lasse mich gerne davon überzeugen, daß man mit BASIC heutzutage auch
eigene Datenstrukturenimplementiewren kann.
Da hätte ich gerne mal Beispielcode dafür gesehen,
aber auch für ein BSDIC, das auch auf AVR läuft. :-)
C ist eine gute Idee weil es nebenbei viel Hardwaregrundlagen
vermittelt.
Bei BASIC empfinde ich die sehr kontextbehaftete Grammatik eher als
Lernhindernis...
auch auf die gefahr hin, dass es schon jemand vorgeschlagen hat (ich hab
nicht den ganzen Thread gelesen)
Schülern, als Einstieg in die Programmierung würde ich Logo (falls es
das noch gibt) oder Processing empfehlen.
bei beiden sieht man schnell Resultate und kann recht feine sachen damit
machen
zwieblum schrieb:
> den richtigen geist schilt man mit LISP
achso, den Geist chillt man mit LISP? ;-)
ich dachte, es wäre eher gut, ihn anzuregen ;-)
Ja,LISP hätte ich beinahe auch genannt;
aber da das steht eigentlich noch auf meiner
wenn-ich-zeit-habe-schaue-ich-mir-das-mal-näher-an-Liste.
daher habe ich's weggelassen
> Schülern, als Einstieg in die Programmierung würde ich Logo (falls es> das noch gibt) oder Processing empfehlen.
Leider gibt es Logo noch, hat aber Probleme mit der DOS-Emulation unter
XP und modernen Grafikkarten.
> bei beiden sieht man schnell Resultate und kann recht feine sachen damit> machen
Sag mal, bist du wahnsinnig? Logo ist die krankste
"Programmiersprache", die ich je gesehen habe. Da mein Lehrer kein
Englisch konnte und so Dinge wie "if" ihm daher unmöglich waren zu
lernen, mussten wir das deutsche Logo verwenden. Die Lernkurve bei Logo
ist ein ganz flacher Logarithmus:
Tatsächlich, am Anfang sieht man schnell, wie einfach es ist ein paar
Linien zu zeichnen. Sobald die Programme aber minimal komplexer werden,
wirds ekelig: Keine Zeilenumbrüche in "WENN"-Blöcken möglich (nicht nur
nicht in der Bedingung, sondern auch nicht im auszuführenden Code!!) -
d.h. wunderschön lange Zeilen - mysteriöse Bugs im Parser, absolut
unverständliche und verwirrende Fehlermeldungen, hirnrissige Namen der
Befehle, nur globale Variablen (keine funktionslokalen Variablen möglich
- sehr viel Spaß bei der Fehlersuche), keine structs o.ä., bekloppte
Syntax...
Logo ist der mit Abstand beste Weg, Schülern zu erklären "lernt
niemals programmieren, es ist eine einzige Qual und ihr werdet es eh
nicht verstehen".
Selbst ich als damals schon der C/C++ -Programmierung mächtiger hatte
oft genug Schwierigkeiten zu verstehen, warum dies oder das jetzt schon
wieder nicht funktioniert.
Auch die doch sehr beschränkten Möglichkeiten in Sachen Ein/Ausgabe
hindern einen daran, richtig Freude am Programmieren zu kriegen.
Ich hatte damals ein Gtk+ -basiertes "Framework" geschrieben, welches
die gleichen Ein/Ausgabe -Möglichkeiten wie Logo in C/C++ bietet (also
der "Igel" und so) und sogar Makros geschrieben dass man alles mit
deutschen Befehlen machen kann. Aber der Lehrer hat sich geweigert das
auch nur anzusehen. Hab meine Programme trotzdem damit gemacht (waren
natürlich viel schneller, einfacher und leistungsfähiger als
Logo-Programme), wenigstens hat der Lehrer die nicht einfach mit 6
bewertet...
Hi
Wenn man mich nach einer Programmiersprache für µC fragt, würde ich
immer sagen, "C", auch wenn ich's nicht kann und mich mit ASM vergnüge.
Alle anderen Programmiersprachen mögen auch Spaß machen, aber es geht in
der Schule um Grundlagenwissen. Es fängt auch kein Erstklässler mit
komplexen Gleichungen an, sondern lernt das kleine Einmaleins.
Um Programme schreiben zu können, Sollte (muß) ein wenig Verständnis der
Hardware gegeben sein.
Ein Basic-Befehl "Print" hat wesentlich mehr Code, als diese 5
Buchstaben vorgaukeln. Das ist bei Anwendungsprogrammen auf PC Basis
irrelevant, weil Speicher ohne Ende. Was kümmert da ein Programm von
einigen MByte oder gar GByte. Bei µC sieht's da doch ein wenig anders
aus. Ist ja auch für völlig andere Aufgaben gedacht. Ein 8k
Assemblerprogramm ist schon sehr komplex. Bei "C" hab ich allein schon
wegen der Bedeutung von verschiedenen Zeichen, die Teilweise mühselig
auf der Tastatur gesucht werden müssen doch sehr schnell das Interesse
verloren, diese Sprache sprechen zu müssen. Das ich trotzdem "C"
empfehle hat den Grund, das "C" sehr Hardwarenah programmiert werden
kann und zusätzlich mathematische Funktionen durch eingebundene
Bibliotheken erleichtert. Eine Realzahl-Multiplikation zu Fuß in
Assembler ist dagegen eine echte Herausforderung. Andererseits wird für
Steuerungstechnik soviel mathematische Funktionalität selten gefordert.
Da ist m.E. Assembler für ein schnelles Verständnis der Vorgänge im
Prozessor besser geeignet. Basic, Pascal oder andere Hochsprachen halte
ich für Schulzwecke nicht geeignet. Wenn man Schüler für µC begeistern
kann, lernen sie auch gern Assembler oder "C".
Gruß oldmax
C ist keine schoene Anfaengersprache - zu viele Dinge, die man am Anfang
einfach tun muss, ohne eine Chance zu haben, sie zu verstehen.
Assembler ist da wesentlich schoener und es beschaeftigt sich nur mit
kleinen, leicht zu verstehenden Dingen. Problem ist da eher zu
vermitteln, was so kleine, primitive Aktionen wie das Umherschieben von
ein paar Werten mit der Computerwelt zu tun hat, die der Anwender kennt.
Und es wird schnell langweilig, weil es doch sehr muehsam sein kann,
etwas Interessantes zu erreichen.
Deswegen ist eine Sprache wie Basic toll fuer den Einstieg, vor Allem
wenn auf einfache Art und Weise grafische Ausgabe moeglich ist. Dadurch
hat der Einsteiger ein schnelles Erfolgserlebnis, vor Allem im
Unterricht, wenn man sich z.B. an bereits bekannten mathematischen
Aufgaben orientieren kann.
Ich empfehle daher stets die Reihenfolge Basic -> Assembler -> C. Zu dem
Ganzen dazu gehoert auch das grundlegende Verstaendnis digitaler
Schaltungen. Assembler mag einem nach Basic zuerst wie ein Rueckschritt
erscheinen, aber waehrend man mit Basic grundlegend, aber noch recht
abstrakt algorithmisches Denken kennenlernt, bringt einem Assembler die
noetigen Grundlagen ueber die "reale Welt" eines Computerprogramms
naeher. Dann muss man spaeter in C auch nicht solche Kapriolen machen,
um Pointer zu erklaeren :-/
> C ist keine schoene Anfaengersprache - zu viele Dinge, die man am Anfang> einfach tun muss, ohne eine Chance zu haben, sie zu verstehen.
Richtig.
> Assembler [...] wird schnell langweilig, weil es doch sehr muehsam sein > kann,
etwas Interessantes zu erreichen.
Das gilt insbesondere für Anfänger, die in ASM bei mehr als einem
Hallo-Welt-Programm bereits von der Komplexität erschlagen werden.
Assembler ist gut, um die Funktionsweise einer CPU zu verstehen -
beschäftigen sollte man sich damit, wenn man schon etwas programmieren
kann.
> Deswegen ist eine Sprache wie Basic toll fuer den Einstieg
Seh ich auch so. Ich gehe dabei davon aus, dass du kein C64-Basic
meinst, sondern ein modernes mit lokalen Variablen, Block-IFs usw. à la
Visual Basic. Hab auch selbst vor Urzeiten mit QuickBasic (semi-modern)
angefangen, hat mir glaube ich nicht geschadet.
> Ich empfehle daher stets die Reihenfolge Basic -> Assembler -> C
Meine Lernreihenfolge war Basic -> C -> Assembler -> Pascal (nur passiv,
um in Pascal geschriebene Beispiele aus einem Buch über
Grafikprogrammierung nachzuvollziehen) -> etwas besser C -> C++ ->
diverse Skriptsprachen.
Aktuell versuche ich meinen C++-Stil zu verbessern, finde aber kaum Zeit
um was zu programmieren ;-)
der mechatroniker schrieb:
> Seh ich auch so. Ich gehe dabei davon aus, dass du kein C64-Basic> meinst, sondern ein modernes mit lokalen Variablen, Block-IFs usw. à la> Visual Basic. Hab auch selbst vor Urzeiten mit QuickBasic (semi-modern)> angefangen, hat mir glaube ich nicht geschadet.
Ich meine tatsaechlich sowas wie C64. Die Idee ist ueberhaupt nicht,
damit komplexere Programme schreiben zu koennen. Sondern einfach der
bequeme Einstieg in algorithmisches Denken. Keine Klassen, keine
Objekte, nur Schleifen, wenige Funktionen, maximal 2-3 Seiten.
Schaden tun die von dir erwaehnten Features wahrscheinlich auch nicht -
aber irgendwo muss der Reiz, eine richtige (TM) Sprache zu lernen, ja
herkommen :-)
Ich würde unter anderem mit einer Skriptsprache starten, z.B. mit
Tcl/Tk.
Durch den sehr einfachen Sprachaufbau ist man dort schnell drin und man
hat mit Tk die Möglichkeit, sehr schnell grafische Ergebnisse zu
erhalten (z.B. durch Malen auf einem canvas).
Assembler finde ich zumindest für die Grundlagen sinnvoll: die logischen
Verknüpfungen, Verschieben, Aufbau eines Funktionsaufrufes (Stack, push,
pop) lässt sich gerade an einem Mikrocontroller schön erklären und
direkt nachvollziehen.
Viele Probleme, die z.B. in C auftauchen, entstehen, weil die Leute
nicht wissen, was der Compiler dort auf Maschinenebene ausspuckt.
Und es macht sicher Spaß, wenn kleine Erfolgserlebnisse (LED-Laufband
oder so.) direkt anzeigen, dass es funktioniert hat. Mit preiswerten
Controllern lässt sich da sicherlich einiges machen, um Schüler zu
begeistern.
Chris D.
C: Viel zu schwierig für unbedarfte Schüler.
C++: Die schlimmst Hybridsprache die je gebaut wurde. Viel zu komplex
und die Programme die rauskommen sind meistens Zwitter zwischen C und
wirklich objektorientiert.
Pascal: ist tot
Basic: kann man machen muss man aber nicht (Microsoftzentriert)
LISP: es gibt immer noch unverbesserliche
Wenn dann nehmt was modernes: entweder JAVA oder C#. Man hann zu Beginn
damit auch ohne großes Wissen über objektorientierte Programmierung
arbeiten und durch die Benutzung von Objekten gewöhnt man sich den
Umgang damit von vorneherein an.
Und wenns um Microcontrollerprogrammierung geht, debuggen muss man doch
eh in Assembler und was der Controller wirklich tut versteht men eh nur
wenn man weiss was was die Register und Ports so machen und wie die
Zusammenhänge genau sind, also besser erst nur Assembler als auch noch C
dazulernen. Für größere Projekte ist das natürlich etwas anderes.
Mein Senf, Udo :-)
Udo R. S. schrieb:
> Wenn dann nehmt was modernes: entweder JAVA oder C#.
Java vereint hier die Nachteile von C und Basic - Sehr maechtig,
vermittelt keine Grundlagen und erfordert die Einhaltung vieler
"obskurer Rituale".
Erklaere mal einem Anfaenger, was eine NullPointerException ist...
Hi
Wenn es um PC Programmierung geht, klar, Finger von Assembler. Da ist
jede Hochsprache besser geeiget. Ich benutze auch Delphi ( Pascal) und
mir würd heut nicht mehr einfallen, in Assembler zu schreiben, obwohl es
der Compiler versteht und einbinden kann.
Wenn es aber um die Programmierung von µC's geht, da bleib ich dabei,
ist BASIC oder PASCAL der falsche Weg. Bestenfalls "C" wegen der
Hardwarenähe und weil's eben immer noch für viele die "richtige"
Programmiersprache ist bis hin zu PC-Anwendungen. Schließlich gibt's da
auch ein Visual C.
Assembler muß nicht langweilig sein. Nehmt ein greifbares Projekt, nicht
zu groß, aber doch anspruchsvoll. Z. B. eine Datenerfassung mit
Schnittstele zu einem PC. Dann machen beide Programmiersprachen, die für
den µC und die für die Visualiserung am PC Sinn und Spaß. Oder die
Steuerung einer ( alten) Eisenbahnanlage. Vielleicht ein Kreis, ein
Ausweichgleis und evtl. ein paar Signale. Ist schnell aufgebaut und man
kann in der Praxis arbeiten.
Gruß oldmax
Da bin ich aber gespannt wie mit Java den uC programmiert ;-).
Java ist keineswegs eine schlechte Sprache, nur sehe ich immer wieder
auf meiner Arbeit von FH Abgängern welche nur Java gelernt haben, wie
weit weg sie von der Realität sind.
In dem Alter würde ich C nehmen, kein C++ und kein C#. Man sollte nicht
zu viel ein bisschen können sondern besser eine Sprache verstehen. Für
diejenigen die das Flair dafür haben ist der Schritt von Strukturiertem
Programmieren nach Objekt Orientiertem Programmieren nicht so schlimm.
Auch unter dem Aspekt das die Lehrperson (noch ein Kompliment an den
Lehrer, dass er sich soviele Gedanken macht und sich einsetzt) auch
nicht die grossen Vorkenntnisse hat, macht C in meinen Augen wirklich
Sinn.
Es steht der Hardware recht nah und ist nicht unnötig komplex.
Eine Sprache für alles, also uC und PC. Dann bleibt auch etwas hängen.
IMHO
Grüsse,
R.
Rene H. schrieb:
> Da bin ich aber gespannt wie mit Java den uC programmiert ;-).NanoVM ;)
> Eine Sprache für alles, also uC und PC. Dann bleibt auch etwas hängen.
C sollte man auf dem PC nur in absoluten Ausnahmefällen verwenden.
> Denken: Viel zu schwierig für unbedarfte Schüler.
Über seltsame Idiome, Pointer, den Sinn der main(), kompliziertes
Stringhandling nachzudenken, während man gerade versucht zu lernen,
algorithmisch zu denken: natürlich.
Es gibt sogar Lehrer, die unterrichten die erste Mathestunde in
deutscher Sprache statt in hebräischer. Ja, richtig, sowas, was die
Schüler schon können. Ist das jetzt klickibunti?
Hi
Bleibt doch mal auf dem Teppich und müllt hier nicht mit
unqualifizierten Antworten das Forum zu. Einen Glaubenskrieg über
verschiedene Sprachen kann ich ja gerade noch nachvollziehen, da die
Meisten noch was damit anfangen können. Ich finde es gut, wenn ein
Lehrer sich auch nach anderen Sprachen erkundigt und nicht einfach sagt
"so spreche ich, also hört auf mich"
Gruß oldmax
der mechatroniker schrieb:
>> Denken: Viel zu schwierig für unbedarfte Schüler.>> Über seltsame Idiome, Pointer, den Sinn der main(), kompliziertes> Stringhandling nachzudenken, während man gerade versucht zu lernen,> algorithmisch zu denken: natürlich.
Alles richtig.
Aber mit Ausnahme der Sonderstellung von main() kann man auch in C
durchaus schon interssante Programme schreiben, in denen weder seltsame
Idiome (was immer das auch sein mag) noch Pointer vorkommen. Irgendwann
muss es natürlich sein, das ist schon klar. Aber man muss einen Neuling
zumindest nicht gleich am Anfang damit überfallen damit er überhaupt
irgendetwas programmieren kann.
Stringhandling ist zugegebenermassen in C ein schwieriges Thema, eignet
sich allerdings gut um in die Pointerthematik einzuführen. Und bis dahin
hat man mit Schleifen, Abfragen, Sequenz, einfachen Funktionen u.dgl.
ein weites Betätigungsfeld in dem sich auch viele interessante
Aufgabenstellungen finden lassen.
oldmax schrieb:
[...]
> Basic, Pascal oder andere Hochsprachen halte> ich für Schulzwecke nicht geeignet.
Wieso denn nicht?
BTW: C gilt auch als Hochsprache, auch wenn manch einer es als
fast-Assembler ansieht.
Verglichen mit Ocaml, Haskell oder Lisp oder auch Python
ist es zwar recht low-level, aber es ist dennoch eine sog.
Hochsprache.
Gruß,
Oliver
Peter Stegemann schrieb:
> In Assembler macht man nix, das muss man nur mal gemacht haben :^)
So ähnlich sehe ich das auch.
Gerade auf einem µC ist es nicht schlecht, wenn man die ersten
Gehversuche in Assembler macht und so einen Blick ganz nah an die
Hardware werfen kann. Die Scheu vor dem Datenblatt verfliegt dann ganz
schnell.
Aber für eine ernsthafte Anwendung wäre mir das zu mühsam. Ein wenig
Komfort möchte ich bei der Programmierung schon haben und da ist es mir
dann auch egal, ob der Compiler ein paar Prozentpunkte an Speed
verschenkt oder nicht.
Peter Stegemann schrieb:
[...]
> Ich empfehle daher stets die Reihenfolge Basic -> Assembler -> C. Zu dem> Ganzen dazu gehoert auch das grundlegende Verstaendnis digitaler> Schaltungen. Assembler mag einem nach Basic zuerst wie ein Rueckschritt> erscheinen, aber waehrend man mit Basic grundlegend, aber noch recht> abstrakt algorithmisches Denken kennenlernt,
Dafür ist BASIC sicherlich nicht so gut geeignet, wie funktionale
Sprachen, also z.B. Lisp oder OCaml.
Mein Favorit ist OCaml.
Aber ich habe nicht damit angefanmgen, sondern damals (1982 oder so)
mit BASIC.
> bringt einem Assembler die> noetigen Grundlagen ueber die "reale Welt" eines Computerprogramms> naeher. Dann muss man spaeter in C auch nicht solche Kapriolen machen,> um Pointer zu erklaeren :-/
Wenn man mit Assembler anfängt, hat man direkt den bezug zur Maschine
und den digitalen Schaltungen. Wozu also BASIC?
Konsequenter wäre demnach eher
Assembler ==> C ==> BASIC.
Man will aber BASIC nicht mehr wollen, denke ich, wenn man bereits C
kann.
Daher eher:
Assembler ==> C ==> ( OCaml Haskell Python / LISP )
Gruß,
Oliver
Peter Stegemann schrieb:
[...]
> Ich empfehle daher stets die Reihenfolge Basic -> Assembler -> C.
[...]
Hmhhh, jetzt komme ich ja ins Grübeln...
...denn das war auch meine Reihenfolge,
wobei Assembler damals Maschinencode/Assembler war
(so mit Hexcode in Dezimalwerte wandeln und mit Poke
in den Speicher schreiben und mit SYS (?) den Maschinencode aufrufen)
der mechatroniker schrieb:
[...]
> Aktuell versuche ich meinen C++-Stil zu verbessern, finde aber kaum Zeit> um was zu programmieren ;-)
Lerne doch lieber eine vernünftige Sprache... sowas wie OCaml :-)
Chris D. schrieb:
> Ich würde unter anderem mit einer Skriptsprache starten, z.B. mit> Tcl/Tk.
Buärks!
Hatte ich auch mal gelernt.
Das ist vollkommen uneffektive Syntax.
Ich hatte als erste Scriptsprache Tcl/Tk,
später Perl. Nach Perl war Tcl/Tk für mich durch, ausser, wenn es m al
schnell um ein bischen GUI-Code ging.
Tcl/Tk wurde als Glue-Sprache entwickelt, um C-Teile zusammen zu bauen
und schnell eine GUI dafür her zu zaubern.
Tcl wurde nicht dafür entwickelt, tolle programme darin zu schreiben.
Später kamen immerhin Namespaces und andere Schmankerl dazu, da hatte
ich aber eeh keine Böcke mehr auf Tcl.
Ich fand Tcl's Syntax einfach viel zu uneffektiv.
Zu flach.
>> Durch den sehr einfachen Sprachaufbau
Eben.
IMHO ist das ZU einfach!
[...]
> Viele Probleme, die z.B. in C auftauchen, entstehen, weil die Leute> nicht wissen, was der Compiler dort auf Maschinenebene ausspuckt.
Vielleicht im Controller-Bereich, oder wenn man Kerne-Programmierung
macht.
Ansonsten ist C ja gerade der Sprung weg von der Maschinennähe, auch
wenn ein Rest Nähe zur Maschine geblieben ist, wenn man sich anschaut,
daß man auf die Größe der von den Variablen belegten Speichermenge
(short int int long int, float, double, alignment bei structs usw.)
achten muss.
Für maschinennahe Programmierung ist dies aber auch notwendig.
Daher ist C ein sehr guter Kompromiss von Abstraktion und Maschinennähe.
Udo R. S. schrieb:
[...]
> Wenn dann nehmt was modernes: entweder JAVA oder C#.
C#: M$-zentriert
JAVA: ist einfach grottig.
Vor vielen jahren hatte ich von Java-Projhekten immer gehört, sie wären
plattformübergreifend und die Sprache wäre so toll.
In der Praxis war der krams unperformant und nicht wirklich
plattformübergreifend.
Es hakte und klemmte doch immer irgendwo.
Später hiuess es dann, Java sei viel perofrmanter und besser portabel
geworden (besser portabel als ohnehin grundsätzlich portabel, wie geht
das?). Bis jetzt habe ich aber noch keine Java-Applikation gesehen, die
wirklich gut oder performant ist. Obendrein hat Java auch pointer.
Was hat das in einer "modernen" Sprache zu suchen?
JAVA ist uralt und wird nur permanent weiterentwickelt.
IMHO ist es immernoch Schrott.
> Man hann zu Beginn> damit auch ohne großes Wissen über objektorientierte Programmierung> arbeiten und durch die Benutzung von Objekten gewöhnt man sich den> Umgang damit von vorneherein an.
"Alles ist ein Objekt" ist doch ziemlich dogmatisch.
Und: wird das wirklich konsequent umgesetzt?
AFAIK nicht.
>> Und wenns um Microcontrollerprogrammierung geht, debuggen muss man doch> eh in Assembler
Bei Java sicherlich ;-)
> und was der Controller wirklich tut versteht men eh nur> wenn man weiss was was die Register und Ports so machen
Wenn man eine Hochsprache nimmt, will man sich zumindest um die Register
nicht mehr kümmern müssen, sonst kann man gleich bei Assembler bleiben.
:->
Wenn man selbst bei JAVA sich um registerinhalte kümmern muss,
dann ist das doch armselig.
Kann man bei JAVA-Programmen wenigstens auch Assembler einbinden?
Dann kann man wenigstens die performancekritischen Sachen orgendltich
machen ;-)
> und wie die> Zusammenhänge genau sind, also besser erst nur Assembler als auch noch C> dazulernen. Für größere Projekte ist das natürlich etwas anderes.>> Mein Senf, Udo :-)
Hmhhh, der Senf war aber sehr mild. ;-)
Peter Stegemann schrieb:
> Udo R. S. schrieb:>>> Wenn dann nehmt was modernes: entweder JAVA oder C#.>> Java vereint hier die Nachteile von C und Basic - Sehr maechtig,> vermittelt keine Grundlagen und erfordert die Einhaltung vieler> "obskurer Rituale".>> Erklaere mal einem Anfaenger, was eine NullPointerException ist...
Und erkläre mal einem Programmiersprachenkenner, wozu so ein Unfug
notwendig ist!
Wer will sich denn mit NULL-Pointern rum schlagen, wenn er/sie abstrakt
programmieren will?
In Python, OCaml usw. gibt es so einen Unsinn nicht.
Java ist wie C++ nur ein verwurschteltes C.
oldmax schrieb:
[...]
> Assembler muß nicht langweilig sein. Nehmt ein greifbares Projekt, nicht> zu groß, aber doch anspruchsvoll. Z. B. eine Datenerfassung mit> Schnittstele zu einem PC. Dann machen beide Programmiersprachen, die für> den µC und die für die Visualiserung am PC Sinn und Spaß. Oder die> Steuerung einer ( alten) Eisenbahnanlage. Vielleicht ein Kreis, ein> Ausweichgleis und evtl. ein paar Signale. Ist schnell aufgebaut und man> kann in der Praxis arbeiten.
[...]
Hilfreich ist es doch, wenn man auf beiden Systemen die gleiche Sprache
benutzen kann.
daher ist C im Vorteil: das macht auf Mikrokontrollern Sinn, aber auch
auf PCs.
Ich wollte, als ich mit AVR anfing, eigentlich erst mal nur Assembler
machen, aber im Job ist Vorgabe, C, und Assembler soll Ausnahme bleiben
(musste ich aber bei Startup-Code auch mal einsetzen).
Also ist beides für mich derzeit sinnvoll.
Peter Stegemann schrieb:
> In Assembler macht man nix, das muss man nur mal gemacht haben :^)
heheh, der war gut (auch wenn ich es bei Mikrokontrollern etwas anders
sehe)
Ok, noch ein ernsthaftes Statement zu C
> Eine Sprache für alles, also uC und PC. Dann bleibt auch etwas hängen.
Ist, wenn das Ziel lautet "Didaktisch sinnvolle Sprache für
Programmierunterricht für absolute Anfänger" IMHO absolut kein
Kriterium.
Zu Skriptsprachen: OCaml hatte ich noch nie in der Hand, muss ich mir
mal anschauen, Tcl/Tk ebenso.
Was ich an Skriptsprachen bis jetzt in der Hand hatte:
- PHP: für größere Anwendungen (und Webanwendungen werden heutzutage
manchmal etwas größer) zu skriptsprachig, für kleinere Ok. Für Anfänger
aufgrund der Domäne "Web" und der damit einhergehenden zusätzlichen
Komplexität (Client/Server, Frage der Datenspeicherung über
Seitenaufrufe hinweg, sobald man mehr als eine Hallo-Welt-Anwendung
machen möchte) schätze ich es als eher ungeeignet ein.
- Visual Basic: besser als sein Ruf, IMHO auch als Anfängersprache (Mal
zwei Textboxen rein, Button, Ins Click-Event ne einfache Berechnung
anhand der eingegebenen Sachen, was z.B. Anwendung einer Formel aus der
Geometrie sein kann: solche Sachen lassen sich da gut üben.)
- SQL: sicher nicht gleich mit Datenbank anfangen.
Sonstige Gedanken zu versch. Sprachen:
- FUP: erleichtert den Einstieg IMHO dann, wenn man gewohnt ist, "in
Hardware" zu denken, nicht aber, wenn man das algorithmische Denken
überhaupt nicht beherrscht.
- Java: Ich hatte im 1. Semester viele im Java-Kurs, die Probleme hatten
zu verstehen, warum man eine Klasse braucht und was main ist, und warum
die "public static" ist. Wäre mir wahrscheinlich nicht anders gegangen,
wenn ich vorher nicht C und C++ gekannt hätte.
Ich würde den Schülern erst einmal etwas Theorie beibringen, auf jeden
Fall Zustandsautomaten (oder je nach Reife der Schüler DFAs, NFAs,
KellerAutomaten und Turing-Maschinen). Das können die später noch
gebrauchen. Dann vielleicht UML (Aktivitätsdiagramme, Zustandsdiagramme)
oder wenigstens Struktogramme.
Damit können die schon den kompletten Quadrokopter entwickeln, ohne
Programmiersprache :-)
Wenn man diese Grundlagen verstanden hat, dann ist es egal, ob du C,
ASM, C++ oder Java nimmst. Bei OO-Sprachen würde ich dann
UML-Objektdiagramme und Klassendiagramme nehmen, zuerst die
Objektdiagramme, dann ist es oft einfacher zu verstehen.
Irgendwann macht es bei den Schülern "Klick" im Kopf, und sie stecken
ihren Lehrer bei den Aufgaben in die Tasche :-)
Karl heinz Buchegger schrieb:
> Aber mit Ausnahme der Sonderstellung von main() kann man auch in C> durchaus schon interssante Programme schreiben, in denen weder seltsame> Idiome (was immer das auch sein mag) noch Pointer vorkommen.
Alleine die Klammerflut ist doch fuer einen Neuling reiner Augenkrebs.
Erklaeren kannst du das am Anfang nicht und einem Lernwilligen die ganze
Zeit sagen: "Das erklaere ich in ein paar Wochen, jetzt muss das einfach
mal so gemacht werden" ist doch voellig frustrierend.
Oliver B. schrieb:
> Chris D. schrieb:>> Ich würde unter anderem mit einer Skriptsprache starten, z.B. mit>> Tcl/Tk.>> Buärks!>> Hatte ich auch mal gelernt.>> Das ist vollkommen uneffektive Syntax.
Also, bisher habe ich damit alles erreicht, was ich erreichen wollte.
Du meinst sicher "ineffizient".
So habe ich auch mal gedacht. Mittlerweile empfinde ich Redundanz als
äußerst angenehm, zumal sich das nicht weiter auf die Geschwindigkeit
auswirkt.
Tcl-Programme kann man mit etwas Geschick selbsterklärend schreiben.
> Ich hatte als erste Scriptsprache Tcl/Tk,> später Perl. Nach Perl war Tcl/Tk für mich durch, ausser, wenn es m al> schnell um ein bischen GUI-Code ging.
Perl ist nicht schlecht, aber mich störte genau das: GUIs müssen
irgendwie angebunden werden.
> Tcl/Tk wurde als Glue-Sprache entwickelt, um C-Teile zusammen zu bauen> und schnell eine GUI dafür her zu zaubern.> Tcl wurde nicht dafür entwickelt, tolle programme darin zu schreiben.
Und C sollte ursprünglich auch nicht auf Mikrocontrollern laufen...
Der ursprüngliche Zweck und die spätere Verwendung sind eben zwei Paar
Schuhe :-)
> Später kamen immerhin Namespaces und andere Schmankerl dazu, da hatte> ich aber eeh keine Böcke mehr auf Tcl.
Oha, dann hast Du viele schöne Sachen verpasst. Selbst Schuld ;-)
Man kann mittlerweile sehr schön OO programmieren - auch große Projekte.
> Ich fand Tcl's Syntax einfach viel zu uneffektiv.> Zu flach.
Genau das liebe ich so :-)
>> Durch den sehr einfachen Sprachaufbau>> Eben.>> IMHO ist das ZU einfach!
So ist das halt - jeder hat seinen Geschmack :-)
Ich verwende Tcl mittlerweile sehr erfolgreich auch auf Mikrocontrollern
- das funktioniert deswegen so gut, weil Tcl so schön einfach ist.
> Ansonsten ist C ja gerade der Sprung weg von der Maschinennähe, auch> wenn ein Rest Nähe zur Maschine geblieben ist, wenn man sich anschaut,> daß man auf die Größe der von den Variablen belegten Speichermenge> (short int int long int, float, double, alignment bei structs usw.)> achten muss.
Eben. Meiner Meinung nach sind in C eine Menge "Reste" übrig geblieben -
die immer wieder für Ärger sorgen (Pointer, Speicherlöcher usw.)
> Für maschinennahe Programmierung ist dies aber auch notwendig.
Nicht unbedingt. Viele Dinge müssten nicht sein und sind wirklich
Relikte aus der Steinzeit.
> Daher ist C ein sehr guter Kompromiss von Abstraktion und Maschinennähe.
Das war es sicherlich in den 70ern - heute ist das nur noch veraltet.
Meiner Meinung nach ist C eher besserer Assembler: schnell, aber viel zu
fehleranfällig für größere Projekte. Da gibt es einfach Besseres.
Chris D.
Chris D. schrieb:
> Meiner Meinung nach ist C eher besserer Assembler: schnell, aber viel zu> fehleranfällig für größere Projekte. Da gibt es einfach Besseres.
Sowas kommt immer von Leuten, die in ihren Kuschelsprachen noch keine
wirklich grossen Projekte gemacht haben. Fuer manche ist ja schon ein
1000-Zeilen Mikrocontroller-Programm ein grosses Projekt - aber ich rede
von richtigen Projekten, die mindestens einen ganzen Schrank im RZ
brauchen. Da kannst du dann lange versuchen, das mit Tcl zu machen,
statt mit den "veralteten" Sprachen C/C++/Java.
Peter Stegemann schrieb:
> Karl heinz Buchegger schrieb:>>> Aber mit Ausnahme der Sonderstellung von main() kann man auch in C>> durchaus schon interssante Programme schreiben, in denen weder seltsame>> Idiome (was immer das auch sein mag) noch Pointer vorkommen.>> Alleine die Klammerflut ist doch fuer einen Neuling reiner Augenkrebs.> Erklaeren kannst du das am Anfang nicht und einem Lernwilligen die ganze> Zeit sagen: "Das erklaere ich in ein paar Wochen, jetzt muss das einfach> mal so gemacht werden" ist doch voellig frustrierend.
Ach komm.
So schlimm ist die Klammerflut dich gar nicht.
In jeder Sprache muss man Syntax lernen, das bleibt nicht aus.
Ob ich mir jetzt merken muss, dass es
if bedinung then
anweisungen
endif
heisst, oder
if( bedingung )
{
anweisungen
}
ist doch gehupft wie gehatscht. (Die Variante, dass die Klammer bei nur
1 Anweisung entfallen kann, würde ich einem Anfänger zunächst gar nicht
unterjubeln)
Karl heinz Buchegger schrieb:
> Ach komm.> So schlimm ist die Klammerflut dich gar nicht.
Frag mal Unbedarfte, wie das aussieht. Vor Allem geschweifte Klammern...
oder guck mal, wie oft Anfaenger Klammerfehler machen. Ich habe da 2
Semester Erfahrungen als Tutor gesammelt :-/
> Frag mal Unbedarfte, wie das aussieht. Vor Allem geschweifte Klammern...> oder guck mal, wie oft Anfaenger Klammerfehler machen. Ich habe da 2> Semester Erfahrungen als Tutor gesammelt :-/
Vor allem im Zusammenhang mit der kontextsensitiven C-Syntax und der
Folge, dass kein Compiler bei typischen Tippfehlern Fehlermeldungen
ausgeben kann, die einen Anfänger in die richtige Richtung schubsen
(auch wenn gerade der gcc in den letzten Jahren recht intelligent
geworden ist).
Fuer Anfaenger erst mal was schoenes mit dem real ausfuehrbare
Struktogramme (also nicht UML) zusammenklicken kann, haette auch was. Am
Besten noch in Kombination mit angeschlossener Hardware. Fuer die BeBox
gab es mal sowas. So kann man einige regelungstechnische Aufgaben schoen
implementieren, mit externen Sensoren und Lampen / Motoren. So Sachen
wie Funktionen auf einem echten Plotter zeichnen waeren damit auch noch
drin.
Offenbar meckern/fluchen hier eine ganze Menge von Leuten über Pointer
in C/C++. Aber hat jemand einen sinnvollen Gegenvorschlag?
Alle mir bekannten Rechnerarchitekturen arbeiten mit "flachen" Speicher,
also einer langen Kette von Bytes. Möchte man dort hinein "abstrakte
Datentypen" (Listen, Trees, etc.) speichern, kann man diese nicht
hintereinander in den Speicher packen, sondern muss sie über diesen
verteilen. Um seine Daten dann wiederzufinden, muss man sich merken, wo
sie sind - mithilfe von Pointern. Das heißt, man kann gar nicht ohne
Pointer programmieren. Mann kann Pointer lediglich hübsch verpacken,
sodass der zugehörige Speicher automatisch freigegeben wird, wenn man
den Speicher aller Pointer, die auf den Speicher zeigen, freigibt
(Garbage collection, Reference counting). Das gibt es in C deswegen
nicht, weil C als "flache" (oder "nicht-magische" ;) Sprache konzipiert
ist - das Programm macht exakt das macht, was da steht, ohne versteckte
Abläufe im Hintergrund. C++ als C-Weiterentwicklung ist ebenfalls so
gedacht, ermöglicht aber, dass man sich selber solche versteckten Dinge
programmiert (z.B. durch Programmierung einer Kapsel-Klasse für
automatisch Referenzen zählende Pointer, wie z.B. im GTKmm geschehen).
Man kommt also auf keinen Fall um Pointer herum, man kann lediglich eine
automatische Speicherbereinigung in den Pointer-Datentyp implementieren,
und das ist in "flachen" Sprachen wie C umständlich (Glib z.B.
implementiert eine Referenzzählung in C, ist aber Tipparbeit - dafür
sieht man sofort, was passiert), in C++ gut machbar und in Java, Ruby,
Python etc. vor-implementiert. Aber das ganze ist eher so eine Art
verkürzte Syntax, aber kein echtes Sprach-Feature.
Folgerung: Prozessor mit flachem Speicher ohne Pointer geht nicht.
Gegenbeweise sind willkommen.
Peter Stegemann schrieb:
> Chris D. schrieb:>>> Meiner Meinung nach ist C eher besserer Assembler: schnell, aber viel zu>> fehleranfällig für größere Projekte. Da gibt es einfach Besseres.>> Sowas kommt immer von Leuten, die in ihren Kuschelsprachen noch keine> wirklich grossen Projekte gemacht haben.
Komisch ist eher, dass die Leute hier immer genau wissen, was andere als
Informatiker (und Projektleiter) schon so alles durchgezogen haben :-)
Das waren damals (1999) durchaus große Dinger mit etwa einem Dutzend
Beteiligter und >300000 Zeilen Code.
Das geht durchaus - aber man muss dazu eben über den Tellerrad schauen,
anstatt direkt "Wird nie was!" von sich zu geben.
> Fuer manche ist ja schon ein> 1000-Zeilen Mikrocontroller-Programm ein grosses Projekt - aber ich rede> von richtigen Projekten, die mindestens einen ganzen Schrank im RZ> brauchen.
Ich allerdings auch.
> Da kannst du dann lange versuchen, das mit Tcl zu machen,
Das musste man gar nicht lange versuchen - das funktionierte relativ
zügig ohne Probleme - aber dazu benötigt man Köpfe, die nicht gleich
"Ähhhh, wie doof, das ist ja ne Skriptsprache." von sich geben.
Die fand man damals bevorzugt jenseits des Atlantiks.
> statt mit den "veralteten" Sprachen C/C++/Java.
Wer sprach bei Java und C++ von veraltet?
Ich meinte ausschließlich C.
Es ist ja nicht so, dass ich kein C verwende - manche wirklich
zeitkritische Dinge (im Controllerbreich) müssen eben doch in C oder
Assembler implementiert werden.
Für solche kleinen, überschaubaren Codestücke ist es durchaus ok.
Aber wirklich große Sachen will ich damit heute nicht mehr bauen.
Dafür ist mir die Syntax zu fehleranfällig.
Mittlerweile sind die Festplatten groß und die Rechner schnell genug, um
mehr Redundanz zugunsten von Fehlerfreiheit zuzulassen.
Chris D.
Oliver B. schrieb:
> Peter Stegemann schrieb:>> Udo R. S. schrieb:>>>>> Wenn dann nehmt was modernes: entweder JAVA oder C#.>>>> Java vereint hier die Nachteile von C und Basic - Sehr maechtig,>> vermittelt keine Grundlagen und erfordert die Einhaltung vieler>> "obskurer Rituale".>>>> Erklaere mal einem Anfaenger, was eine NullPointerException ist...>> Und erkläre mal einem Programmiersprachenkenner, wozu so ein Unfug> notwendig ist!>> Wer will sich denn mit NULL-Pointern rum schlagen, wenn er/sie abstrakt> programmieren will?>> In Python, OCaml usw. gibt es so einen Unsinn nicht.
In Python nennt sich das nur etwas anders: null reference und None statt
null.
In OCaml oder F# gibt es das auch, z.B. wenn man C/C++DLLs einbindet und
man nicht weiß, was Options/Option Types sind (und schon ist man bei
Monaden...)
> Java ist wie C++ nur ein verwurschteltes C.
Chris D. schrieb:
> Peter Stegemann schrieb:>> Da kannst du dann lange versuchen, das mit Tcl zu machen,> Das musste man gar nicht lange versuchen - das funktionierte relativ> zügig ohne Probleme - aber dazu benötigt man Köpfe, die nicht gleich> "Ähhhh, wie doof, das ist ja ne Skriptsprache." von sich geben.> Die fand man damals bevorzugt jenseits des Atlantiks.
Ich hatte da einen ganz tollen Tag, 2001. Da durfte ich teilhaben an der
Unterhaltung zwischen dem Projektleiter und Skriptfreak eines
"erfolgreichen" Projektes mit seinem "boesen Zwilling" aus einer anderen
Firma, die alles in C gemacht hatten. Das war wie beim Skat, wo einer
alle Stiche kriegt. Der Resourcenverbrauch und der Pflegebedarf der
Tcl-Loesung war einfach nur peinlich im direkten Vergleich. Zu
Erkenntnissen hat das natuerlich nicht gefuehrt.
Ich benutze selbst durchaus auch Skriptsachen, mal diese, mal jene -
wenn der Anwendungsfall passt.
> Mittlerweile sind die Festplatten groß und die Rechner schnell genug, um> mehr Redundanz zugunsten von Fehlerfreiheit zuzulassen.
Den Spruch hoere ich in dieser oder jener Form seit Jahren. Nur leider
wachsen auch die Aufgaben und fressen die Leistung schlicht und einfach
auf.
Btw, >300.000 Zeilen ist nicht beeindruckend.
> Aber hat jemand einen sinnvollen Gegenvorschlag?> Alle mir bekannten Rechnerarchitekturen arbeiten mit "flachen"> Speicher, also einer langen Kette von Bytes.
nicht alle. LISPMASCHINE hatte was anderes. und das ding hat einen
riesigen vorteil "(" ist einfach viel sexier als "{" oder "[" ...
Ohne alles gelesen zu haben:
Die mit Abstand schlimmsten Einsteigersprachen sind m.M.n. genau
diejenigen, bei denen eine IDE versucht, mitzuhelfen. Etwa Basic oder
Delphi.
Ich hab selbst mal Informatikunterricht gegeben, daher kann ich aus
Erfahrungen erzählen: Die Gefahr war viel zu groß, dass irgendwer
einfach aus Versehen z.B. mal eine Delphi-Unit umbenannt hat und die IDE
damit verwirrt hat. Oder mal ein Stück Quelltext gelöscht, welches die
IDE erzeugt hatte und so weiter.
Das schöne an C ist m.M.n. eigentlich, dass man mit einer leeren Datei
anfängt, den Compiler in der Hand hat und effektiv nix kaputt machen
kann. Dass man dann direkt an der Konsole klemmt, ist nur von Vorteil.
Dann braucht man auch keine 'getchar(), damits Konsolenfenster auf
bleibt' und solche Scherze.
Einfacher und direkter geht es eigentlich kaum.
Niklas Gürtler schrieb:
> Offenbar meckern/fluchen hier eine ganze Menge von Leuten über Pointer> in C/C++. Aber hat jemand einen sinnvollen Gegenvorschlag?> Alle mir bekannten Rechnerarchitekturen arbeiten mit "flachen" Speicher,> also einer langen Kette von Bytes.
Wenn jemand "Pointer" an C kritisiert, dann meint er die fehlende
Gültigkeitsprüfung bei Speicherzugriffen. Unter den heutzutage
verwendeten Programmiersprachen ist dieses Problem bei C einzigartig,
und nebenbei die Quelle für den Großteil aller Sicherheitslücken.
Peter Stegmann schrieb:
> aber ich rede> von richtigen Projekten, die mindestens einen ganzen Schrank im RZ> brauchen.
Wieso ist das ein Kriterium für ein "richtiges" Projekt? Man kann auch
mit ein paar hundert Zeilen Code einen Schrank in einem RZ beschäftigen.
> Da kannst du dann lange versuchen, das mit Tcl zu machen,> statt mit den "veralteten" Sprachen C/C++/Java.
Das einzige was C und Java gemeinsam haben sind die geschweiften
Klammern.
Sven P. schrieb:
> Ohne alles gelesen zu haben:> Die mit Abstand schlimmsten Einsteigersprachen sind m.M.n. genau> diejenigen, bei denen eine IDE versucht, mitzuhelfen. Etwa Basic oder> Delphi.>> Ich hab selbst mal Informatikunterricht gegeben, daher kann ich aus> Erfahrungen erzählen: Die Gefahr war viel zu groß, dass irgendwer> einfach aus Versehen z.B. mal eine Delphi-Unit umbenannt hat und die IDE> damit verwirrt hat. Oder mal ein Stück Quelltext gelöscht, welches die> IDE erzeugt hatte und so weiter.
Man muss ja nicht gleich mit GUIs anfangen, reine Konsolenanwendungen
reichen.
Oder man geht den anderen Weg und fängt z.B. mit squeak.org an (inkl.
opencroquet.org / opencobalt.org).
>> Das schöne an C ist m.M.n. eigentlich, dass man mit einer leeren Datei> anfängt, den Compiler in der Hand hat und effektiv nix kaputt machen> kann. Dass man dann direkt an der Konsole klemmt, ist nur von Vorteil.> Dann braucht man auch keine 'getchar(), damits Konsolenfenster auf> bleibt' und solche Scherze.> Einfacher und direkter geht es eigentlich kaum.
Geht schon: Z.B. die REPLs von F#/OCaml, Haskell oder Ruby (z.B. im
Browser http://tryruby.sophrinix.com/).
Vorteil: Kein Compiler, kein Warten, direkte Rückmeldung, keine char
arrays, keine Rückfragen was denn char** argv ist...
Andreas Schwarz schrieb:
> Niklas Gürtler schrieb:>> Offenbar meckern/fluchen hier eine ganze Menge von Leuten über Pointer>> in C/C++. Aber hat jemand einen sinnvollen Gegenvorschlag?>> Alle mir bekannten Rechnerarchitekturen arbeiten mit "flachen" Speicher,>> also einer langen Kette von Bytes.>> Wenn jemand "Pointer" an C kritisiert, dann meint er die fehlende> Gültigkeitsprüfung bei Speicherzugriffen. Unter den heutzutage> verwendeten Programmiersprachen ist dieses Problem bei C einzigartig,> und nebenbei die Quelle für den Großteil aller Sicherheitslücken.
Das resultiert entweder aus ungültigen Array-Zugriffen (die man durch
vorherige if-Abfragen verhindern kann; andere Programmiersprachen
automatisieren das, ist aber im Endeffekt das selbe => Nur verkürzte
Syntax) oder aus ungültigen Pointern, welche man durch fehlende
Speicherverwaltung bekommt, was man aber auch lösen kann - siehe oben.
Ist aber eben Tipparbeit, und die "modernen" Sprachen haben in
Wirklichkeit auch Pointer, nehmen einem also nur diese Tipparbeit ab -
verkürzte Syntax. Dafür hat man in C aber die volle Kontrolle und sieht
direkt, was abläuft.
zwieblum (Gast) schrieb:
> nicht alle. LISPMASCHINE hatte was anderes. und das ding hat einen> riesigen vorteil "(" ist einfach viel sexier als "{" oder "[" ...
Habe ich was verpasst? Die Lispmaschine ist doch wohl ein (vermutlich in
C geschriebener) Interpreter, der ebenfalls nur flachen Speicher
verwaltet und Pointer verwendet.
es gab' mal vor äonen (ende 70er/anfang 80er) lispmaschinen. im prinzip
war's eine in silizum gegossene lisp-umgebung. sogar "treiber" waren
lisp :-) sun hat das ganze dann anfang 2000 mit java-coprozessoren in
einer schmalspurvariante probiert.
oh, ich vergaß: bild von einer LISP Maschine ist hier:
http://de.wikipedia.org/wiki/LISP . und in LISP gibt's keinen
unterschied zwischen daten und code, keine illegale zeigerarithmetik ...
:-)
Niklas Gürtler schrieb:
> Das resultiert entweder aus ungültigen Array-Zugriffen (die man durch> vorherige if-Abfragen verhindern kann; andere Programmiersprachen> automatisieren das, ist aber im Endeffekt das selbe => Nur verkürzte> Syntax) oder aus ungültigen Pointern, welche man durch fehlende> Speicherverwaltung bekommt, was man aber auch lösen kann - siehe oben.
Das Problem dass C kein sicheres Speicherhandling ermöglicht kann man
nicht lösen, man kann es nur eindämmen indem man
Sicherheitsüberprüfungen von Hand einbaut. Dazu muss man überhaupt erst
mal alle Fehlerquellen kennen. Vermittle einem Anfänger mal warum man
manche Funktionen der C-Library prinzipiell gar nicht sicher verwenden
kann, oder dass ein Benutzer von einem Programm mit den Zeilen
1
string=einlesen();
2
printf(string);
mit etwas Glück an beliebige Adressen springen kann. Das wissen selbst
viele erfahrene Programmierer nicht.
> Dafür hat man in C aber die volle Kontrolle und sieht> direkt, was abläuft.
Spätestens wenn man den Coredump im Debugger aufmacht.
der mechatroniker schrieb:
> Ok, noch ein ernsthaftes Statement zu C>>> Eine Sprache für alles, also uC und PC. Dann bleibt auch etwas hängen.>> Ist, wenn das Ziel lautet "Didaktisch sinnvolle Sprache für> Programmierunterricht für absolute Anfänger" IMHO absolut kein> Kriterium.
Klar: eine Sprache lernen und viel damit erreichen. :-)
>> Zu Skriptsprachen: OCaml hatte ich noch nie in der Hand, muss ich mir> mal anschauen, Tcl/Tk ebenso.
Ocaml ist keine Scriptsprache.
Andreas Schwarz schrieb:
> Das Problem dass C kein sicheres Speicherhandling ermöglicht kann man> nicht lösen, man kann es nur eindämmen indem man> Sicherheitsüberprüfungen von Hand einbaut.
Das Problem bei X ist, dass es kein Y hat, deswegen muss man... solche
Argumente kann man fuer jede Sprache beliebig erzeugen.
Jedes Werkzeug ist anfaellig fuer Fehlbedienung. Bei C ist das leichter
moeglich, dafuer aber kann man in C auch Dinge machen, die mit anderen
Sprachen nicht oder nur umstaendlich gehen. C steht bei mir nicht
umsonst erst etwas weiter hinten in der Liste der Sprachen die ein
Anfaenger lernen soll - aber es steht auf jeden Fall drauf. Ein
C-Programm baut nicht von alleine Mist, sondern weil der Programmierer
Mist gebaut hat. Sowas sind stets Struktur- und Organisationsprobleme
und die hat er in jeder Sprache, wenn er sein Handwerk nicht lernt.
Deswegen ist eine harte Schule zur rechten Zeit eine gute Schule -
danach kann man es sich dann immer noch mit der persoenlichen
Lieblingssprache kuschelig einrichten.
Uebrigens: Applikationen wie Purify sind heute Standard. Damit sollten
auch die chaotischsten Programmierer ihre Fehler finden.
zwieblum schrieb:
> wann hast du den letzten coredump debugged?
Ist bei mir ein halbes Jahr her. Seither suche ich nur noch Fehler in
Java, da wuenscht man sich oefters einen ordentlichen coredump.
Chris D. schrieb:
> Oliver B. schrieb:>> Chris D. schrieb:>>> Ich würde unter anderem mit einer Skriptsprache starten, z.B. mit>>> Tcl/Tk.>>>> Buärks!>>>> Hatte ich auch mal gelernt.>>>> Das ist vollkommen uneffektive Syntax.>> Also, bisher habe ich damit alles erreicht, was ich erreichen wollte.> Du meinst sicher "ineffizient".
jau
>> So habe ich auch mal gedacht. Mittlerweile empfinde ich Redundanz als> äußerst angenehm, zumal sich das nicht weiter auf die Geschwindigkeit> auswirkt.> Tcl-Programme kann man mit etwas Geschick selbsterklärend schreiben.
Das kann man in allen Sprachen... und auch in allen Sprachen vergeigen.
>>> Ich hatte als erste Scriptsprache Tcl/Tk,>> später Perl. Nach Perl war Tcl/Tk für mich durch, ausser, wenn es m al>> schnell um ein bischen GUI-Code ging.>> Perl ist nicht schlecht, aber mich störte genau das: GUIs müssen> irgendwie angebunden werden.
[...]
Gibt auch Module für, muss man nicxht alles "anbinden".
Tcl/Tk => Perl/Tk
>>> Tcl/Tk wurde als Glue-Sprache entwickelt, um C-Teile zusammen zu bauen>> und schnell eine GUI dafür her zu zaubern.>> Tcl wurde nicht dafür entwickelt, tolle programme darin zu schreiben.>> Und C sollte ursprünglich auch nicht auf Mikrocontrollern laufen...
Eben.
Deswegen war ich bisher immer skeptisch diesbezüglich.
Aber wenn das Vorgabe ist und man da mehr Speicher hat als dmalas auf
C64, dann geht das schon ;-)
>> Der ursprüngliche Zweck und die spätere Verwendung sind eben zwei Paar> Schuhe :-)
Klar.
>>> Später kamen immerhin Namespaces und andere Schmankerl dazu, da hatte>> ich aber eeh keine Böcke mehr auf Tcl.>> Oha, dann hast Du viele schöne Sachen verpasst. Selbst Schuld ;-)
naja, ich kenne ja bessere Sprachen, also habbe ich nicht wirkolich viel
verpasst. heheh :-)
> Man kann mittlerweile sehr schön OO programmieren - auch große Projekte.
Na und?
Trotzdem wird die Syntax ddurch nicht wesentlich besser geworden sein.
>>> Ich fand Tcl's Syntax einfach viel zu uneffektiv.>> Zu flach.>> Genau das liebe ich so :-)
Du schreibst lieber 200 Seiten Code, statt drei zeilen? ;-)
>>>> Durch den sehr einfachen Sprachaufbau>>>> Eben.>>>> IMHO ist das ZU einfach!>> So ist das halt - jeder hat seinen Geschmack :-)
klar.
> Ich verwende Tcl mittlerweile sehr erfolgreich auch auf Mikrocontrollern> - das funktioniert deswegen so gut, weil Tcl so schön einfach ist.
Auf controllern?
Aha, das war mir neu.
Daß das möglich ist, hänbgt aber nicht mit der verbose-ineffizienten
Syntax zusammen.
Die Ausdrucksstärke einer Sprache ist nicht direkt mit der Größe des
dann resultierenden Maschinenprogramms gleichsetzbar.
Dein Argument greift nicht.
>>> Ansonsten ist C ja gerade der Sprung weg von der Maschinennähe, auch>> wenn ein Rest Nähe zur Maschine geblieben ist, wenn man sich anschaut,>> daß man auf die Größe der von den Variablen belegten Speichermenge>> (short int int long int, float, double, alignment bei structs usw.)>> achten muss.>> Eben. Meiner Meinung nach sind in C eine Menge "Reste" übrig geblieben -> die immer wieder für Ärger sorgen (Pointer, Speicherlöcher usw.)
Nein, nicht übrig geblieben., sondern damit eingeführt worden.
Übrig geblieben ist es in java, das damit aufzeigt, daß es über C nicht
weit hinaus geht. :-)
[...]
>> Daher ist C ein sehr guter Kompromiss von Abstraktion und Maschinennähe.>> Das war es sicherlich in den 70ern - heute ist das nur noch veraltet.
Daß Tcl auch auf Mikroco0ntrollern läuft, ist mir neu.
Aber dann kann man ja auch bei BASIC bleiben.
>> Meiner Meinung nach ist C eher besserer Assembler: schnell, aber viel zu> fehleranfällig für größere Projekte. Da gibt es einfach Besseres.
??
Niklas Gürtler schrieb:
> Offenbar meckern/fluchen hier eine ganze Menge von Leuten über Pointer> in C/C++.
[...]
Aus gutem Grund.
> Aber hat jemand einen sinnvollen Gegenvorschlag?
Ja.
Referenzen, wie in OCaml.
Damit kann man nicht gegen die Wand fahren.
> Alle mir bekannten Rechnerarchitekturen arbeiten mit "flachen" Speicher,> also einer langen Kette von Bytes.
"Alle mir bekannten Rechnerarchitekturen"...
eben.
> Möchte man dort hinein "abstrakte> Datentypen" (Listen, Trees, etc.) speichern, kann man diese nicht> hintereinander in den Speicher packen, sondern muss sie über diesen> verteilen.
Schade, daß wir da nicht die rechnerarchitekturen anpassen...
> Um seine Daten dann wiederzufinden, muss man sich merken, wo> sie sind - mithilfe von Pointern.
...wenn man bei den Konzepten ud Hardware'n bleibt...
> Das heißt, man kann /gar nicht ohne/> Pointer programmieren.
Doch.
In Sprachen, wo es keine pointer gibt, kann man ohne Pointer
programmieren.
> Mann kann Pointer lediglich hübsch verpacken,> sodass der zugehörige Speicher automatisch freigegeben wird, wenn man> den Speicher aller Pointer, die auf den Speicher zeigen, freigibt> (Garbage collection, Reference counting).
Deine Argumentation stimmt, wenn man eine Sprache ohne Pointern auf
einer Sprache mit Pointern implementiert.
Ansonsten stimmt es nicht.
> Das gibt es in C deswegen> nicht, weil C als "flache" (oder "nicht-magische" ;) Sprache konzipiert> ist
historisch gesehen gibt es das nicht, weil es damals wohl nicht so viele
andere Konzepte gab?!
Obwohl...hmhhh... LISP ist ja auch schon recht alt....
> - das Programm macht exakt das macht, was da steht, ohne versteckte> Abläufe im Hintergrund.
Hahah, quatsch.
Das programm macht, was im Hintergrund als Maschinencode abläuft, und
was genau das ist, hängt von der verwendeten C-Lib, dem Compiler usw.
ab.
> C++ als C-Weiterentwicklung
Nein, es ist einje eigene Sprache... eher verwurstelung.
OO wurde nur so halbwegs umgesetzt.
[...]
> Man kommt also auf keinen Fall um Pointer herum,
doch.
Sprachen "oberhalb" von C haben ggf. keine Pointer.
Evtl. bauen sie auf C auf, dann brauchen sie Pointer indirekt.
Oder sie bauen direkt auf Assembler auf, ohne C-Umweg, dann können sie
keine Pointer nutzen, denn Assembler hat keine Pointer, nur verschiedene
Adressierungsarten. :-)
Damit ist eigentlich schon alles erzählt, was es dazu zu sagen gibt. :-)
[...]
> Folgerung: Prozessor mit flachem Speicher ohne Pointer geht nicht.> Gegenbeweise sind willkommen.
s.o.
Chris D. schrieb:
[...]
> Es ist ja nicht so, dass ich kein C verwende - manche wirklich> zeitkritische Dinge (im Controllerbreich) müssen eben doch in C oder> Assembler implementiert werden.>> Für solche kleinen, überschaubaren Codestücke ist es durchaus ok.>> Aber wirklich große Sachen will ich damit heute nicht mehr bauen.> Dafür ist mir die Syntax zu fehleranfällig.>> Mittlerweile sind die Festplatten groß und die Rechner schnell genug, um> mehr Redundanz zugunsten von Fehlerfreiheit zuzulassen.
...
oh geil, festplatten im Mikrokontroller! :-)
Arc Net schrieb:
> Oliver B. schrieb:>> Peter Stegemann schrieb:>>> Udo R. S. schrieb:>>>>>>> Wenn dann nehmt was modernes: entweder JAVA oder C#.>>>>>> Java vereint hier die Nachteile von C und Basic - Sehr maechtig,>>> vermittelt keine Grundlagen und erfordert die Einhaltung vieler>>> "obskurer Rituale".>>>>>> Erklaere mal einem Anfaenger, was eine NullPointerException ist...>>>> Und erkläre mal einem Programmiersprachenkenner, wozu so ein Unfug>> notwendig ist!>>>> Wer will sich denn mit NULL-Pointern rum schlagen, wenn er/sie abstrakt>> programmieren will?>>>> In Python, OCaml usw. gibt es so einen Unsinn nicht.>> In Python nennt sich das nur etwas anders: null reference und None statt> null.
[...]
Nein.
Dereferenziere einen NULL-Pointer in C, und wenn Deine C-Lib das nicht
abfängt, knallst Du gegen die Wand.
> In OCaml oder F# gibt es das auch, z.B. wenn man C/C++DLLs einbindet und> man nicht weiß, was Options/Option Types sind (und schon ist man bei> Monaden...)
Das mit dem Einbinden von C ist dann nicht mehr OCaml, sondern mixed
Code.
Also bist Du wieder bei C und den Pointern.
Das ist aber ein verglciuh der hinkt.,
Denn wenn man NUR C nimmt, kann man mit NULL-Pointern gegen die Wand
fahren.
Nur mit OCaml's Referenzen kannst du nicht gegen die Wand fahren.
Und bei Python auch nicht.
zwieblum schrieb:
>> Aber hat jemand einen sinnvollen Gegenvorschlag?>> Alle mir bekannten Rechnerarchitekturen arbeiten mit "flachen">> Speicher, also einer langen Kette von Bytes.>> nicht alle. LISPMASCHINE hatte was anderes. und das ding hat einen> riesigen vorteil "(" ist einfach viel sexier als "{" oder "[" ...
...da stand ja auch: "Alle mir bekannten"
Sven P. schrieb:
> Ohne alles gelesen zu haben:> Die mit Abstand schlimmsten Einsteigersprachen sind m.M.n. genau> diejenigen, bei denen eine IDE versucht, mitzuhelfen. Etwa Basic oder> Delphi.
Die IDE hat aber nicht direkt was mit der Sprache zu tun.
Es gibt auch C mit IDE und sicherlivch auch BASIC ohne...
Andreas Schwarz schrieb:
> Niklas Gürtler schrieb:
[...]
> Peter Stegmann schrieb:>> aber ich rede>> von richtigen Projekten, die mindestens einen ganzen Schrank im RZ>> brauchen.>> Wieso ist das ein Kriterium für ein "richtiges" Projekt? Man kann auch> mit ein paar hundert Zeilen Code einen Schrank in einem RZ beschäftigen.
Eben....
Da las ich letztens den Spruch: "Die dümmsten programmierer schreiben
die längsten Programme" oder so ähnlich.
Und für die, die es nicht verstehen gibt es hier einen wunderbaren
Artikel dazu:
http://www.developer.com/tech/article.php/988641/Its-Not-About-Lines-of-Code.htm
Kann ich nur vollkommen unterstreichen!
Ciao,
Oliver
Niklas Gürtler schrieb:
> Andreas Schwarz schrieb:>> Niklas Gürtler schrieb:>>> Offenbar meckern/fluchen hier eine ganze Menge von Leuten über Pointer>>> in C/C++. Aber hat jemand einen sinnvollen Gegenvorschlag?>>> Alle mir bekannten Rechnerarchitekturen arbeiten mit "flachen" Speicher,>>> also einer langen Kette von Bytes.>>>> Wenn jemand "Pointer" an C kritisiert, dann meint er die fehlende>> Gültigkeitsprüfung bei Speicherzugriffen. Unter den heutzutage>> verwendeten Programmiersprachen ist dieses Problem bei C einzigartig,>> und nebenbei die Quelle für den Großteil aller Sicherheitslücken.> Das resultiert entweder aus ungültigen Array-Zugriffen (die man durch> vorherige if-Abfragen verhindern kann; andere Programmiersprachen> automatisieren das,> ist aber im Endeffekt das selbe => Nur verkürzte> Syntax)
[...]
Diese Argumentation ist unsinnig, denn es ist eh ALLES das selbe: alles
Assmebler/Maschinensprache.
Also sind alle Programmiersprachen nur Assembler.
Wenn Du auf der Ebene argumentierst, kannst Du nicht ernsthaft erwarten,
daß wir das ernst nehmen.
Das ist eine Ausrede, mehr nicht.
> oder aus ungültigen Pointern, welche man durch fehlende> Speicherverwaltung bekommt, was man aber auch lösen kann - siehe oben.> Ist aber eben Tipparbeit, und die "modernen" Sprachen haben in> Wirklichkeit auch Pointer,
... Pointer gibt es nur von C her.
Der Prozessor kennt das nicht, er kennt nur Adressierungsarten.
Pointer sind ein Konzept in C, und es gibt Sprachen, die kenne sowas
nicht.
OCaml kennt referenzen, die sind so was ähnliches, adressieren aber aus
Programmierersicht nicht auf eine konkrete Adresse im Speicher.
Und es gibt Sprachen, die kennen nicht mal referenzen.
Ja, und es ist alles das selbe: sind bloß Atome und Moleküle, also
braucht man nicht mal Assembler, sondern nur Physik. ;-)
Oliver B. schrieb:
> Andreas Schwarz schrieb:>> Wieso ist das ein Kriterium für ein "richtiges" Projekt? Man kann auch>> mit ein paar hundert Zeilen Code einen Schrank in einem RZ beschäftigen.> Eben....
Eben was? Es ging nie um die Frage, ob man mit wenigen Zeilen ein ganzes
Rack beschaeftigen kann, sondern um die Behauptung, C sei zu
fehleranfaellig fuer grosse Projekte und Tcl besser geeignet.
> Und für die, die es nicht verstehen gibt es hier einen wunderbaren> Artikel dazu:>> http://www.developer.com/tech/article.php/988641/Its-Not-About-Lines-of-Code.htm
Erstens ist das schon wieder ein anderes Thema, zweitens schiesst der
Autor sich mit dem letzten Statement in den Fuss:
"Ability to solve customer problems quickly"
Das ist das Standardargument aller Pfuscher, denn es laesst
Langfristigkeit voellig ausser Acht.
Oliver B. schrieb:
> Wenn Du auf der Ebene argumentierst, kannst Du nicht ernsthaft erwarten,> daß wir das ernst nehmen.
Ist das der Pluralis Majestatis oder bist du jetzt zum Meinungsfuehrer
fuer die C-Hasser gewaehlt worden?
> ... Pointer gibt es nur von C her.>> Der Prozessor kennt das nicht, er kennt nur Adressierungsarten.
Das ist totaler Quatsch, anders kann man es nicht sagen. Was glaubst du
denn, wie in Assembler auf Speicher zugegriffen wird? Eine
Speicheradresse in einem Register ist ein Pointer. An einer anderen
Speicherstelle ist es ein Pointer.
Peter Stegemann schrieb:
> Jedes Werkzeug ist anfaellig fuer Fehlbedienung. Bei C ist das leichter> moeglich, dafuer aber kann man in C auch Dinge machen, die mit anderen> Sprachen nicht oder nur umstaendlich gehen.
Welche? So ziemlich alles ist in C umständlicher als in anderen
Sprachen.
> Ein C-Programm baut nicht von alleine Mist
Gegenbeispiel: gets. Baut per Definition Mist, immer und unvermeidlich.
> Uebrigens: Applikationen wie Purify sind heute Standard. Damit sollten> auch die chaotischsten Programmierer ihre Fehler finden.
Damit findet man nur die Fehler die gerade auftreten, nicht die die noch
im Code versteckt sind.
Oliver B. schrieb:
>> Möchte man dort hinein "abstrakte>> Datentypen" (Listen, Trees, etc.) speichern, kann man diese nicht>> hintereinander in den Speicher packen, sondern muss sie über diesen>> verteilen.> Schade, daß wir da nicht die rechnerarchitekturen anpassen...
Und wie sehe so eine Architektur aus?
Andreas Schwarz schrieb:
> Peter Stegemann schrieb:>> Jedes Werkzeug ist anfaellig fuer Fehlbedienung. Bei C ist das leichter>> moeglich, dafuer aber kann man in C auch Dinge machen, die mit anderen>> Sprachen nicht oder nur umstaendlich gehen.> Welche? So ziemlich alles ist in C umständlicher als in anderen Sprachen.
Arbeite mal in Java mit strukturierten Memory-Buffern. Das endet
unvermeidlich in wilden Offset- und Kopierorgien, wo in C einfach mit
Pointern gearbeitet werden kann.
Oder versuch mal ein konstantes Latenzverhalten mit einer Sprache mit
Garbage-Collection hinzukriegen - das geht in Java auch nach 6 Versionen
noch nicht.
>> Ein C-Programm baut nicht von alleine Mist> Gegenbeispiel: gets. Baut per Definition Mist, immer und unvermeidlich.
Und die ruft ein C-Programm sporadisch und unvermeidlich auf, ja? Oder
entscheidet das vieleicht doch eher der Programmierer? Kaputte
Bibliotheksfunktionen sind ja nun auch kein Alleinstellungsmerkmal von
C.
>> Uebrigens: Applikationen wie Purify sind heute Standard. Damit sollten>> auch die chaotischsten Programmierer ihre Fehler finden.> Damit findet man nur die Fehler die gerade auftreten, nicht die die noch> im Code versteckt sind.
Da man sowieso moeglichst alle Pfade des Codes testet, ist das kein
echtes Problem.
Peter Stegemann schrieb:
> Andreas Schwarz schrieb:>> Welche? So ziemlich alles ist in C umständlicher als in anderen Sprachen.>> Arbeite mal in Java mit strukturierten Memory-Buffern. Das endet> unvermeidlich in wilden Offset- und Kopierorgien, wo in C einfach mit> Pointern gearbeitet werden kann.
Das geht in C genau so lange gut bis jemand das Programm von Little auf
Big Endian portieren möchte oder umgekehrt.
> Oder versuch mal ein konstantes Latenzverhalten mit einer Sprache mit> Garbage-Collection hinzukriegen - das geht in Java auch nach 6 Versionen> noch nicht.
Siehe Realtime Java.
>>> Ein C-Programm baut nicht von alleine Mist>> Gegenbeispiel: gets. Baut per Definition Mist, immer und unvermeidlich.>> Und die ruft ein C-Programm sporadisch und unvermeidlich auf, ja? Oder> entscheidet das vieleicht doch eher der Programmierer? Kaputte> Bibliotheksfunktionen sind ja nun auch kein Alleinstellungsmerkmal von> C.
Gemeingefährliche Bibliotheksfunktionen sind ein ziemliches
Alleinstellungsmerkmal von C. gets ist nur ein Extrembeispiel.
>>> Uebrigens: Applikationen wie Purify sind heute Standard. Damit sollten>>> auch die chaotischsten Programmierer ihre Fehler finden.>> Damit findet man nur die Fehler die gerade auftreten, nicht die die noch>> im Code versteckt sind.>> Da man sowieso moeglichst alle Pfade des Codes testet, ist das kein> echtes Problem.
Alle Pfade kann man in nichttrivialen Programmen unmöglich testen,
bestenfalls alle Zweige; und selbst wenn, dann würde man damit nicht
alle Fehler aufdecken können, weil das Auftreten auch von den Daten
abhängig ist, nicht nur vom Pfad.
> Siehe Realtime Java.
jaaaa .... wie immer hängt das an der definition von "realtime" ...
> Gemeingefährliche Bibliotheksfunktionen sind ein ziemliches> Alleinstellungsmerkmal von C.
nun, der sinn von geladenen waffen ist, dass sie auch abgefeuert werden.
wenn du natürlich vorziehst den elefanten mit erdnüssen zu bewerfen ...
wie wär's mal wenn die superwuppertollen programmierer vor dem code
hinschludder - hey geil, ich schaff' locker 200 zeilen pro tag - es mal
mit nachdenken versuchen würden?
"weg mit den bäumen, die töten golffahrer!"
Peter Stegemann schrieb:
> Oliver B. schrieb:>> Andreas Schwarz schrieb:>>>> Wieso ist das ein Kriterium für ein "richtiges" Projekt? Man kann auch>>> mit ein paar hundert Zeilen Code einen Schrank in einem RZ beschäftigen.>> Eben....>> Eben was? Es ging nie um die Frage, ob man mit wenigen Zeilen ein ganzes> Rack beschaeftigen kann, sondern um die Behauptung, C sei zu> fehleranfaellig fuer grosse Projekte und Tcl besser geeignet.>>> Und für die, die es nicht verstehen gibt es hier einen wunderbaren>> Artikel dazu:>>>> http://www.developer.com/tech/article.php/988641/Its-Not-About-Lines-of-Code.htm>> Erstens ist das schon wieder ein anderes Thema, zweitens schiesst der> Autor sich mit dem letzten Statement in den Fuss:>> "Ability to solve customer problems quickly">> Das ist das Standardargument aller Pfuscher,
Nein.
> denn es laesst> Langfristigkeit voellig ausser Acht.
Nein.
Denn man kann (langfristig) nur dann kurzfristig Probleme lösen,
wenn man früh genug vorgebaut hat.
Ich habe den text mehrfach gelesen, und entweder ist der sehr
vieldeutoig interpretierbar, oder Du hast ihn nicht verstanden.
Ich kann die Argumentation komplett nachvollziehen und habe immer Code
auf langfristige benutzung hin geschrieben, nicth auf schnelles
Pfuschen.
Gerade das schnelle Pfuschen (viel Code produzieren, statt drüber
nachzudenken) wird in dem Artikel ja kritisiert.
Andreas Schwarz schrieb:
> Peter Stegemann schrieb:>> Andreas Schwarz schrieb:>>> Welche? So ziemlich alles ist in C umständlicher als in anderen Sprachen.>> Arbeite mal in Java mit strukturierten Memory-Buffern. Das endet>> unvermeidlich in wilden Offset- und Kopierorgien, wo in C einfach mit>> Pointern gearbeitet werden kann.> Das geht in C genau so lange gut bis jemand das Programm von Little auf> Big Endian portieren möchte oder umgekehrt.
Du wolltest ein Beispiel, du hast es bekommen. Meinst du ich produziere
jetzt die ganze Nacht Beispiele, die du dann mit schnippischen
Bemerkungen relativierst? Ich mache uebrigens die letzten 3 Wochen
nichts Anderes als das oben erwaehnte - in C waer's schon lange fertig
und idiotensicher.
Schau dir mal java.util.ByteBuffer an und erklaere dann hier nochmal,
dass das in C nicht einfacher ist.
>> Oder versuch mal ein konstantes Latenzverhalten mit einer Sprache mit>> Garbage-Collection hinzukriegen - das geht in Java auch nach 6 Versionen>> noch nicht.> Siehe Realtime Java.
Du willst wirklich behaupten, das Problem sei damit weniger umstaendlich
in Java geloest, als in C? Du hast das noch nicht wirklich in einem real
existierenden, nichttrivialen Projekt eingesetzt, oder?
>> Da man sowieso moeglichst alle Pfade des Codes testet, ist das kein>> echtes Problem.> Alle Pfade kann man in nichttrivialen Programmen unmöglich testen,> bestenfalls alle Zweige; und selbst wenn, dann würde man damit nicht> alle Fehler aufdecken können, weil das Auftreten auch von den Daten> abhängig ist, nicht nur vom Pfad.
Eine Binsenweisheit, die nicht nur auf alle Fehlermoeglichkeiten
zutrifft, sondern auch gerne als Ausrede dafuer benutzt wird, gleich gar
nicht zu testen. Dann muss man sich ueber's Resultat aber auch nicht
wundern. Mit ordentlichem Testing und Design kann man diese Luecke
weitgehend schliessen und das muss man in jeder Sprache sowieso tun.
Oliver B. schrieb:
> Ich habe den text mehrfach gelesen, und entweder ist der sehr> vieldeutoig interpretierbar, oder Du hast ihn nicht verstanden.
"This article examines some of the usual definitions for programmer
productivity, shows why they are wrong, and then proposes an alternate
definition that accurately captures what programming is really about."
"Ability to solve customer problems quickly -- This is the true
definition of programmer productivity, and is what Ingrid accomplished
in the example."
Bis zu diesem Punkt ist der Artikel eigentlich ganz gut - aber ab da ist
er irrefuehrend. Dass die Faehigkeit, Probleme schnell zu loesen
langfristig von der Qualitaet der existierenden Basis abhaengt, steht
da schlicht und einfach nicht.
Peter Stegemann schrieb:
> Oliver B. schrieb:>>> Wenn Du auf der Ebene argumentierst, kannst Du nicht ernsthaft erwarten,>> daß wir das ernst nehmen.>> Ist das der Pluralis Majestatis oder bist du jetzt zum Meinungsfuehrer> fuer die C-Hasser gewaehlt worden?
Wieso?
C ist doch ganz nett. :-)
>>> ... Pointer gibt es nur von C her.>>>> Der Prozessor kennt das nicht, er kennt nur Adressierungsarten.>> Das ist totaler Quatsch, anders kann man es nicht sagen.
Soso...
> Was glaubst du> denn, wie in Assembler auf Speicher zugegriffen wird? Eine> Speicheradresse in einem Register ist ein Pointer.
Pointer ist eine Abstraktion der Speicherzugriffe der jeweiligen
Maschine und ihrer Hardware.
> An einer anderen> Speicherstelle ist es ein Pointer.
Wenn Pointer das selbe sind, wie Adressierungsarten,
dann müssten Pointer ja diverse Adressierungsarten
als diverse Pointer-Arten anbieten.
Das ist aber nicht der Fall.
Wie das in der Maschine (evtl. eine komplett andere Architektur)
umgesetzt wird, ist ja eben nicht 1:1 C -> ASM.
Wäre die Abbildung so primitiv, könnte man ja gleich wiederum Assembler
nehmen.
Die diversen Adressierungsarten muss man sogar mit teils recht
umfangreichen C-Konstrukten nachbilden. (Oder anders rum müssen simple
Pointer-Operationen je nach Hardware recht unterschiedlich /aufwendiger
gelöst werden.)
Und wenn Pointer 1:1 auf Adressierungsarten umzusetzen wären, dann
müsste C entweder für unterschiedliche Prozessoren unterschiedliche
C-Dialekte anbieten, oder wäre ggf. unvollständig.
Was der Compiler macht, ist das Umsetzen von C-Pointern auf die
Maschinenbefehle der jeweiligen Hardware-Architektur.
Das Problem, was man bei C in dem Falle noch nicht gelöst hat (in
späteren Sprachen sehr wohl), ist, daß man bei falschen/fehlerhaften
Adressen mit dem Programm in undefinierte Betriebszustände kommt.
Eine Referenz in OCaml funktioniert ähnlich wie ein Pointer in C, ist
aber nicht dasselbe, sondern ein abstrakteres Gebilde. Zu sagen, eine
Ocaml-Referenz ist ein Pointer ist genauso quatsch, wie zu sagen, ein
C-Pointer ist eine Adressierungsart im Prozessor. Man hat nicht umsonst
verschiedene Namen für die Sachen, denn es sind unterschiedliche Sachen.
Sie haben teils ähnliche Eigenschaften, teils andere Eigenschaften.
Ansonsten könnte man auch den Unterschied zwischen den verschiedenen
Sprachen komplett aufheben und sagen: ist alles Maschienncode und alles
Turing-complete, also alles gleich.
Das trifft dann auf die Berechenbarkeit zu, aber nicht auf die Art und
Weise, wie es benutzt/Programmiert wird.
Man könnte auch sagen: OO: ist alles eh bloß C und Pointer, denn auch
die Klassen benutzen ja Adressierungsarten und Pointer-Arithmetik.
Daher ist auch OO und nicht-OO das selbe.
Java == C == LISP == TRUE, weil alles mit Pointern arbeitet...
Stimmt.
UND
Stimmt nicht.
Stimmt && Stimmt_nicht == TRUE
Kommt auf die Perspektive drauf an.
Vielleicht reden wir aneinander vorbei.
> Pointer ist eine Abstraktion der Speicherzugriffe der jeweiligen> Maschine und ihrer Hardware.
Mein Gott seid ihr heutzutage "verbildet". Ihr streitet euch bei den
simpelsten Begriffen um des Kaisers Bart und schwallt ellenlos lange
Beiträge mit kaum mehr Inhalt.
Ein Pointer ist eine Variable die auf einen Speicherbereich zeigt. Das
ist alles, mehr braucht man dazu nicht zu sagen.
Ihr müsst mal wieder lernen einfache Dinge auch einfach erklären zu
können und nicht wie Politiker die sich vor dem eigenen Rücktritt
sträuben daherzuschwätzen.
Oliver B. schrieb:
>>> In Python, OCaml usw. gibt es so einen Unsinn nicht.>>>> In Python nennt sich das nur etwas anders: null reference und None statt>> null.> [...]>> Nein.> Dereferenziere einen NULL-Pointer in C, und wenn Deine C-Lib das nicht> abfängt, knallst Du gegen die Wand.
Knallt man bei Python auch, wenn man auf None nicht vorbereitet ist.
Allerdings hat man im Gegensatz zu C noch einen Airbag und die
Geschwindigkeit ist geringer.
1
class Test(object):
2
def Foo(self):
3
...
4
v = Test()
5
v.Foo()
6
v = None
7
v.Foo() # AttributeError
> Nur mit OCaml's Referenzen kannst du nicht gegen die Wand fahren.> Und bei Python auch nicht.
Python siehe oben.
OCaml/F#: Option Types
1
let bar (a : int option) =
2
Option.get a
3
4
bar None (* Exception *)
Geht somit auch mit OCaml oder F#. Man knallt immer noch vor die Wand,
wenn man nichts dagegen tut, hat aber zusätzlich zum Airbag noch ABS und
einen Bremsassistenten (auch wenn normalerweise garantiert ist, dass es
keine Nullreferenzen gibt).
Peter Stegemann schrieb:
> Andreas Schwarz schrieb:>> Das geht in C genau so lange gut bis jemand das Programm von Little auf>> Big Endian portieren möchte oder umgekehrt.>> Du wolltest ein Beispiel, du hast es bekommen. Meinst du ich produziere> jetzt die ganze Nacht Beispiele, die du dann mit schnippischen> Bemerkungen relativierst?
Das war keine schnippische Bemerkung, sondern ein Hinweis darauf dass
das was in C so einfach aussieht bei genauerem Hinsehen oft ziemlich
fragil ist. Die Doppelbenutzung von Zeigern führt garantiert zu
Problemen bei der Portierung auf Architekturen mit anderer Endianess,
wenn man nicht genau auf dieses Problem achtet. Und dann ist der Vorteil
schon fast dahin.
>>> Oder versuch mal ein konstantes Latenzverhalten mit einer Sprache mit>>> Garbage-Collection hinzukriegen - das geht in Java auch nach 6 Versionen>>> noch nicht.>> Siehe Realtime Java.>> Du willst wirklich behaupten, das Problem sei damit weniger umstaendlich> in Java geloest, als in C? Du hast das noch nicht wirklich in einem real> existierenden, nichttrivialen Projekt eingesetzt, oder?
Ich glaube überhaupt nichts, ich wollte nur widerlegen dass man mit
anderen Sprachen als C keine Echtzeit realisieren könnte.
>>> Da man sowieso moeglichst alle Pfade des Codes testet, ist das kein>>> echtes Problem.>> Alle Pfade kann man in nichttrivialen Programmen unmöglich testen,>> bestenfalls alle Zweige; und selbst wenn, dann würde man damit nicht>> alle Fehler aufdecken können, weil das Auftreten auch von den Daten>> abhängig ist, nicht nur vom Pfad.>> Eine Binsenweisheit, die nicht nur auf alle Fehlermoeglichkeiten> zutrifft, sondern auch gerne als Ausrede dafuer benutzt wird, gleich gar> nicht zu testen.
Wieso darfst du eigentlich Argumente bringen, und wenn ich dann
Gegenargumente bringe sind das "schnippische Bemerkungen" oder
"Binsenweisheiten"? :)
Das mit dem Testen ist wieder ein anderes Thema. Der Punkt ist, eine
Sprache mit Bereichsüberprüfungen kann eine ganze Klasse von Fehlern
komplett ausschließen, die du durch Testen nicht weitgehend
ausschließen kannst. Dass ist keine Binsenweisheit oder Theorie, sondern
hat ganz praktische Auswirkungen: ein Großteil der Sicherheitsupdates
die du installieren darfst, egal für Windows, Linux, Firefox oder
sonstwas, sind für C-spezifische Fehler, die mit einer Sprache mit
Bereichsprüfungen nicht hätten auftreten können. Ich hab mal nach
"firefox security holes" gegoogelt und die erstbeste rausgesucht:
http://www.mozilla.org/security/announce/2009/mfsa2009-59.html
"Heap buffer overflow in string to number conversion"
Böse ausgedrückt: 35 Jahre nach der Erfindung von C ist die Komplexität
einer String-zu-Zahl-Konvertierung damit noch nicht beherrschbar.
Zeiger in C sind keine Adressen und sind es auch nie gewesen. Zeiger
sind Zeiger. Punkt.
Wenn man Zeiger nicht missbraucht, kriegt man keine Probleme mit
Endianess. Ebenso, wenn man Bitvektoren nicht missbraucht. Ein Cast
eines uint16_t auf einen uint8_t ist eben nicht der korrekte Weg, um an
die unteren/oberen (arithmetischen) 8 Bits zu kommen...
Delphi ohne IDE würd ich dann auch gern mal sehen -- einfacher wirds
dann sicherlich nicht.
Man kann sich überdies in jeder Sprache ins Knie schießen. In jeder
zeitgemäßen Bibliothektsreferenz steht neben 'gets()' ein dickes
Ausrufezeichen und erläutert, warum gets() gefährlich sein kann -- wo
ist also das Problem? Dass man mal wieder lesen muss?
Auch in C++ oder PHP kann man Mist mit Referenzen machen, nur da sieht
man meistens nicht mehr genau, wo denn das referenzierte Objekt
irgendwie mal verloren gegangen ist oder so. Dagegen ist doch recht
schnell zu klären, wo ein Zeiger verbogen wurde, würde ich doch meinen.
Führt es denn zu sichererem/'besserem' Quelltext, wenn man immer mehr
implizit macht? Objekte löscht man z.B. nicht mehr, sondern verlässt
sich darauf, dass die irgendwann mal eingesammelt werden?
(Memo an Hirn: Niemals Diskussionen über Pointer starten) Lassen kann
ich's aber trotzdem nicht:
Die Lisp-Maschine braucht keine Pointer und hat keinen "linearen
Speicher"? Heißt das, wenn ich z.B. eine Liste implementieren will
speichere ich alle Elemente direkt hintereinander ab (wie ein Array),
und wenn ich zwischen Element 34 und Element 35 ein Element einfügen
will, kann ich das einfach im Speicher dazwischenschieben? Wie
funktioniert das? Klingt auf jeden Fall interessant.
C ist halt so konzipiert, dass es die Abläufe in der CPU möglichst genau
abbildet, aber kürzer als Assembler ist (den Beinamen "Super-Assembler"
trägt C nicht zu Unrecht), und deswegen hat C zwangsweise Pointer, weil
es auf Hardwareebene eben nicht anders geht. Automatische
Gültigkeitsprüfung und/oder Referenzzählung hat C nicht, weil die CPU es
auch nicht hat. Dieser niedrige Grad an Abstraktion ist gefährlich, wenn
man ihn nicht anzuwenden weiß, aber man kann gut optimieren. Firefox mag
zwar eine Menge Sicherheitslücken wegen C haben, aber ich will gar nicht
wissen, wie langsam Firefox wäre, wenn er in Ruby oder Java geschrieben
wäre.
Andreas Schwarz schrieb:
> Das war keine schnippische Bemerkung, sondern ein Hinweis darauf dass> das was in C so einfach aussieht bei genauerem Hinsehen oft ziemlich> fragil ist. Die Doppelbenutzung von Zeigern führt garantiert zu
Was fuer eine Doppelbenutzung?
> Problemen bei der Portierung auf Architekturen mit anderer Endianess,> wenn man nicht genau auf dieses Problem achtet. Und dann ist der Vorteil> schon fast dahin.
Ich kann dir nur empfehlen, versuche es wirklich mal in Java. Es muss
eine ganze Menge passieren, dass der Vorteil von C in diesem Aspekt
dahin ist.
>> Du willst wirklich behaupten, das Problem sei damit weniger umstaendlich>> in Java geloest, als in C? Du hast das noch nicht wirklich in einem real>> existierenden, nichttrivialen Projekt eingesetzt, oder?> Ich glaube überhaupt nichts, ich wollte nur widerlegen dass man mit> anderen Sprachen als C keine Echtzeit realisieren könnte.
Niemand hat behauptet, dass es nicht realisierbar waere. Schau es dir
an, es ist wesentlich umstaendlicher als in C - q.e.d.
> Wieso darfst du eigentlich Argumente bringen, und wenn ich dann> Gegenargumente bringe sind das "schnippische Bemerkungen" oder> "Binsenweisheiten"? :)
Ich kann nichts dafuer, dass du dir einen unhaltbaren Standpunkt
ausgesucht hast.
> Das mit dem Testen ist wieder ein anderes Thema. Der Punkt ist, eine> Sprache mit Bereichsüberprüfungen kann eine ganze Klasse von Fehlern> komplett ausschließen, die du durch Testen nicht weitgehend> ausschließen kannst.
Der Unterschied ist, dass die Sprache mit Ueberpruefung eine Exception
wirft, die man handeln kann oder auch nicht. Die ohne Ueberpruefung
laeuft womoeglich weiter und macht Unsinn. Letzteres ist natuerlich
schlimmer, aber bei keiner der beiden Sprachen wird ein Fehler
ausgeschlossen.
> Dass ist keine Binsenweisheit oder Theorie, sondern> hat ganz praktische Auswirkungen: ein Großteil der Sicherheitsupdates> die du installieren darfst, egal für Windows, Linux, Firefox oder> sonstwas, sind für C-spezifische Fehler, die mit einer Sprache mit> Bereichsprüfungen nicht hätten auftreten können.
Es sind Fehler, die einfach zu finden sind, wenn man will. Natuerlich
ist die Wurzel des Problems in der Sprache zu finden - aber es ist nicht
das grosse tragische Problem, als das es gerne dargestellt wird, da es
einfache Mittel dagegen gibt. Der Entwickler muss nur seinen Arsch
hochkriegen und Purify & Co laufen lassen. Dass das viele nicht tun, ist
das eigentliche Problem. Es ist ein Mythos, dass schlampige Entwickler
mit der richtigen Sprache ploetzlich Qualitaetssoftware abliefern.
Peter Stegemann schrieb:
> Andreas Schwarz schrieb:>>> Das war keine schnippische Bemerkung, sondern ein Hinweis darauf dass>> das was in C so einfach aussieht bei genauerem Hinsehen oft ziemlich>> fragil ist. Die Doppelbenutzung von Zeigern führt garantiert zu>> Was fuer eine Doppelbenutzung?
Als Zeiger auf eine Struktur, und als Zeiger auf ein Byte-Array, um
strukturierte Daten bequem abspeichern/zerpfücken zu können. Meintest du
das nicht?
> Niemand hat behauptet, dass es nicht realisierbar waere. Schau es dir> an, es ist wesentlich umstaendlicher als in C - q.e.d.
Gerade meintest du noch nicht dass es kein echtzeitfähiges Java gibt,
und jetzt weißt du dass es wesentlich umständlicher ist? Übrigens habe
nicht ich Java ins Spiel gebracht.
> Der Unterschied ist, dass die Sprache mit Ueberpruefung eine Exception> wirft, die man handeln kann oder auch nicht. Die ohne Ueberpruefung> laeuft womoeglich weiter und macht Unsinn. Letzteres ist natuerlich> schlimmer, aber bei keiner der beiden Sprachen wird ein Fehler> ausgeschlossen.
Der Fehler dass durch unerlaubt Speicherzugriffe der komplette Prozess
kompromittiert werden kann wird durch eine Sprache mit
Zugriffsüberprüfungen ausgeschlossen.
> Es sind Fehler, die einfach zu finden sind, wenn man will. Natuerlich> ist die Wurzel des Problems in der Sprache zu finden - aber es ist nicht> das grosse tragische Problem, als das es gerne dargestellt wird, da es> einfache Mittel dagegen gibt. Der Entwickler muss nur seinen Arsch> hochkriegen und Purify & Co laufen lassen. Dass das viele nicht tun, ist> das eigentliche Problem.
Tools wie Purify oder Valgrind werden sowieso praktisch in allen großen
Projekten eingesetzt bei denen irgend etwas sicherheitsrelevant ist; das
was man von außen zu sehen bekommt sind die Bugs die danach noch übrig
bleiben.
> Es ist ein Mythos, dass schlampige Entwickler> mit der richtigen Sprache ploetzlich Qualitaetssoftware abliefern.
Es geht nicht darum dass schlampige Programmierer Qualitätssoftware
abliefern können, sondern das durchschnittliche Programmierer Software
abliefern können die nicht kommentarlos abstürzt oder Sicherheitslöcher
aufreißt nur weil irgendwo ein +1 bei einer Indizierung vergessen wurde.
Sven P. (haku) wrote:
> Zeiger> sind Zeiger. Punkt.
Tolle "Erklärung" für einen Zeiger. Erinnert mich an die Basta-Politik
eines Zigarre rauchenden Altkanzlers.
Andreas Schwarz (andreas) (Admin) wrote:
> Der Fehler dass durch unerlaubt Speicherzugriffe der komplette Prozess> kompromittiert werden kann wird durch eine Sprache mit> Zugriffsüberprüfungen ausgeschlossen.
Spräche das nicht eigentlich dafür nur noch eine Laufzeitumgebung wie
.NET einzusetzen?
Eine Laufzeitumgebung wie .NET muss es dafür nicht unbedingt sein, eine
statisch kompilierte Sprache die alle Zugriffe auf Gültigkeit prüft
(z.B. D) würde es auch tun. Aber .NET ist sicherlich aufgrund der
Verbreitung die beste Wahl unter Windows.
Andreas Schwarz (andreas) (Admin) wrote:
> Eine Laufzeitumgebung wie .NET muss es dafür nicht unbedingt sein, eine> statisch kompilierte Sprache die alle Zugriffe auf Gültigkeit prüft> (z.B. D) würde es auch tun. Aber .NET ist sicherlich aufgrund der> Verbreitung die beste Wahl unter Windows.
"statisch kompilierte Sprache" was genau meinst du damit? Beispiele
bekannter Sprachen?
Interessierter schrieb:
> Sven P. (haku) wrote:>>> Zeiger>> sind Zeiger. Punkt.>> Tolle "Erklärung" für einen Zeiger. Erinnert mich an die Basta-Politik> eines Zigarre rauchenden Altkanzlers.
Das sollte keine Erklärung sein. Ich wollte und will damit lediglich
unterstreichen, dass ein Zeiger keine Adresse und vorallem keine 'Zahl'
ist, auch wenn z.B. im Windows-Kern früher furchtbar gerne
Zeivervariablen mit Zahlen beschrieben wurden.
So von wegen:
1
int*l;
2
l=5;
Krieg ich die Krise bei.
C an sich ist doch schon ziemlich typensicher. Klar, wenn man C mit
wildem Herumgecaste dazu zwingt, baut es auch Mist. Aber das macht
Delphi/Pascal dann auch.
Andreas Schwarz (andreas) (Admin) wrote:
> Wie gesagt D, oder auch Ada oder Delphi. Für Gültigkeitsüberprüfungen> braucht man nicht unbedingt etwas wie .NET.
Jetzt mal ehrlich, wieviel Prozent der weltweit entwickelten Software
wird in diesen drei von dir aufgezählten Sprachen erstellt? Wobei Delphi
ja mal einen hohen bekanntheits bzw. beliebtheitsgrad hatte. Gab sehr
gute Artikel in der c't. Glaubst du wirklich "D" würde C verdrängen? Und
wie lange wird "D" bestannt haben bis "E", "F", "G" .. es abgelöst haben
wird? Das sind irgendwo alles interessante neue Sprachkonstrukte aber
bevor die sich richtig durchgesetzt haben sind sie doch schon wieder weg
vom Fenster. Selbst das gute alte Pascal dürfte als einführende
Programmiersprache an Hochschulen noch einen höheren Stellenwert haben
als "Exoten" wie Ada.
http://de.wikipedia.org/wiki/Liste_von_Hallo-Welt-Programmen/Programmiersprachen
Interessierter schrieb:
> Glaubst du wirklich "D" würde C verdrängen?
Nein, ich habe das auch nirgendwo angedeutet. .NET und JVM sind wegen
der hohen Verbreitung unter Windows das sinnvollste. Dabei ist man auch
nicht auf Java oder C# festgelegt, sondern hat freie Wahl zwischen C#,
VB, Java, Python, Ruby und vielen anderen Sprachen die auf diesen
Plattformen laufen.
Niklas Gürtler schrieb:
> Firefox mag> zwar eine Menge Sicherheitslücken wegen C haben, aber ich will gar nicht> wissen, wie langsam Firefox wäre, wenn er in Ruby oder Java geschrieben> wäre.
Sieh dir Opera Mini oder Lobo (http://lobobrowser.org/java-browser.jsp)
an...
Andreas Schwarz schrieb:
> Tools wie Purify oder Valgrind werden sowieso praktisch in allen großen> Projekten eingesetzt bei denen irgend etwas sicherheitsrelevant ist; das> was man von außen zu sehen bekommt sind die Bugs die danach noch übrig> bleiben.
Zum einen das, zum anderen sind diese Tools nur so gut, wie die Tests
die dann mit der Software gemacht werden (und auch erstmal geschrieben
werden müssen). Letztlich beweisen die Tools nur das unter diesen
Bedingungen keine Fehler mehr auftreten, nicht die generelle Abwesenheit
von Fehlern.
Peter Stegemann schrieb:
> Niemand hat behauptet, dass es nicht realisierbar waere. Schau es dir> an, es ist wesentlich umstaendlicher als in C - q.e.d.
Nein, z.B. Java-Bytecode direkt in einem Controller (inkl. RTOS und
Treibern von Ajile http://www.ajile.com/)
oder bei Erlang
http://lambda-the-ultimate.org/node/2393http://lambda-the-ultimate.org/node/2954
btw gibt's irgendwelche in C geschriebenen Systeme die eine
Verfügbarkeit von 99.9999999% erreichen?
oder auch Singularity wo u.a. sehr schön gezeigt wird, wie man Prozesse
in Software isolieren kann ohne den Overhead der dazu bei klassischen
Systemen notwendig ist (http://www.codeplex.com/singularity)
Sven P. schrieb:
> C an sich ist doch schon ziemlich typensicher.
Nein. C ist nur statisch typisiert, aber weder stark typisiert, noch
bietet es Typsicherheit.
Interessierter schrieb:
> Jetzt mal ehrlich, wieviel Prozent der weltweit entwickelten Software> wird in diesen drei von dir aufgezählten Sprachen erstellt?http://www.tiobe.com/content/paperinfo/tpci/index.html
oder etwas älter
http://www.cs.berkeley.edu/~flab/languages.html
Andreas Schwarz (andreas) (Admin) wrote:
Interessierter schrieb:
>> Glaubst du wirklich "D" würde C verdrängen?> Nein, ich habe das auch nirgendwo angedeutet.
Aber du hast die bekannten Sprachen wie C, C++ dafür kritisiert nicht
genügend Sicherheit in ihren Bibliotheksfunktionen mitzubringen und als
Beispiel dafür gets() angeführt. Dagegen hast du als bessere Alternative
Sprachen gesetzt die Gültigkeitsüberprüfungen übernehmen. Daraus ergibt
sich doch Zwangsläufig, dass das Bibliotheksorientierte C/C++ durch eine
sicherere Sprache ersetzt (sprich verdrängt) werden sollte und ich habe
nur erwähnt, dass ich nicht das Gefühl habe, dass genau das passiert
(abgesehen von .NET, das im Windows Bereich den bisherigen Unterbau
abgelöst hat).
> .NET und JVM sind wegen> der hohen Verbreitung unter Windows das sinnvollste. Dabei ist man auch> nicht auf Java oder C# festgelegt, sondern hat freie Wahl zwischen C#,> VB, Java, Python, Ruby und vielen anderen Sprachen die auf diesen> Plattformen laufen.
Aber im Bezug auf Sicherheit kann auch .NET sog. Unmanaged Code
ausführen, bietet also im Prinzip all die Unsicherheit die auch die
C-Bibliotheksfunktionen als Ballast mit sich herumtragen. Damit liegt es
doch im Prinzip am Anwender ob Programmiercode Sicher ist oder nicht
oder?
> Opera Mini oder Lobo
aehm, du solltest zum stützen deiner these gute beispiele wählen ...
> Nein, z.B. Java-Bytecode direkt in einem Controller (inkl. RTOS und> Treibern von Ajile http://www.ajile.com/)> btw gibt's irgendwelche in C geschriebenen Systeme die eine> Verfügbarkeit von 99.9999999% erreichen?> oder auch Singularity wo u.a. sehr schön gezeigt wird, wie man Prozesse> in Software isolieren kann ohne den Overhead der dazu bei klassischen> Systemen notwendig ist (http://www.codeplex.com/singularity)
ei, du sollst nicht die werbesprüche der hersteller nachplappern sonder
mindestens mal mit dem zeug gearbeitet haben, wissen wie's funktioniert
und den rest deiner aussage mal im lichte der sinnhaftigkeit prüfen.
aper schön dass LISP bald PASCAL überholt ...
Arc Net schrieb:
> Sven P. schrieb:>> C an sich ist doch schon ziemlich typensicher.>> Nein. C ist nur statisch typisiert, aber weder stark typisiert, noch> bietet es Typsicherheit.
Das ist mir geläufig, ich arbeite seit Jahren damit.
Wenn man es nicht mit der Brech-Cast-Stange drauf ankommen lässt, reicht
das meistens auch vollkommen aus.
Ansonsten würde es mich ja mal interessieren, in welcher Sprache denn
ein System geschrieben ist, welches 99,9999999% Verfügbarkeit erreicht.
Und vorallem, in welcher Sprache diese Sprache implementiert ist...
Hand aufs Herz, Die Lisp-Maschinen und Java-Prozessoren bilden schon
irgendwo die Ausnahme.
Sven P. schrieb:
> Arc Net schrieb:>> Sven P. schrieb:>>> C an sich ist doch schon ziemlich typensicher.>>>> Nein. C ist nur statisch typisiert, aber weder stark typisiert, noch>> bietet es Typsicherheit.>> Das ist mir geläufig, ich arbeite seit Jahren damit.> Wenn man es nicht mit der Brech-Cast-Stange drauf ankommen lässt, reicht> das meistens auch vollkommen aus.
Wenn C nicht viel zu viele implizite Casts von sich aus machen würde und
Casts von void* nach xyz* überhaupt nicht zulassen würde...
> Ansonsten würde es mich ja mal interessieren, in welcher Sprache denn> ein System geschrieben ist, welches 99,9999999% Verfügbarkeit erreicht.> Und vorallem, in welcher Sprache diese Sprache implementiert ist...
Erlang. 1.7 Mio Zeilen in einem ATM-Switch (AXD301,
http://ll2.ai.mit.edu/talks/armstrong.pdf)
http://www.erlang.org/download.html> Hand aufs Herz, Die Lisp-Maschinen und Java-Prozessoren bilden schon> irgendwo die Ausnahme.
Leider.
zwieblum schrieb:
> ei, du sollst nicht die werbesprüche der hersteller nachplappern sonder> mindestens mal mit dem zeug gearbeitet haben, wissen wie's funktioniert> und den rest deiner aussage mal im lichte der sinnhaftigkeit prüfen.
Wie wär's mit Argumenten, statt leerer Behauptungen?
p.s. sowohl aJ100 als auch der ähnliche IM1101 von Imsys sind hier schon
"behandelt" worden. Erlang sollte eigentlich auch jeder kennen, der
mit/an parallelen Anwendungen arbeitet oder sich aktuell z.B. mit
CouchDB beschäftigt
Arc Net schrieb:
> Sven P. schrieb:>> Arc Net schrieb:>>> Sven P. schrieb:>>>> C an sich ist doch schon ziemlich typensicher.>>>>>> Nein. C ist nur statisch typisiert, aber weder stark typisiert, noch>>> bietet es Typsicherheit.>>>> Das ist mir geläufig, ich arbeite seit Jahren damit.>> Wenn man es nicht mit der Brech-Cast-Stange drauf ankommen lässt, reicht>> das meistens auch vollkommen aus.>> Wenn C nicht viel zu viele implizite Casts von sich aus machen würde und> Casts von void* nach xyz* überhaupt nicht zulassen würde...
Hm, C castet von alleine nur void * weg, an allen anderen Stellen muss
es zumindest warnen.
Ich glaube, Erlang braucht zur Übersetzung auch zumindest zum Bootstrap
C, Perl und Flex, oder..?
Arc Net schrieb:
> Oliver B. schrieb:>>>> In Python, OCaml usw. gibt es so einen Unsinn nicht.>>>>>> In Python nennt sich das nur etwas anders: null reference und None statt>>> null.>> [...]>>>> Nein.>> Dereferenziere einen NULL-Pointer in C, und wenn Deine C-Lib das nicht>> abfängt, knallst Du gegen die Wand.>> Knallt man bei Python auch, wenn man auf None nicht vorbereitet ist.
Ääääähhh. Bin in Python noch nicht so tief drin,
daß einem die None's um die Ohren fliegen können ist mir neu.
Aber kannst Du das ggf. mal erklären...
...was pasiert denn dann?
Stirbt Python mit einem Coredump?
> Allerdings hat man im Gegensatz zu C noch einen Airbag und die> Geschwindigkeit ist geringer.
Vielleicht meinst Du ja auch eine andere Art von Problem.
Wenn man in C einen NULL-Pointer dereferenziert oder
einen Pointer ins Nirgendwo benutzt, dann landet man im Nirgendwo.
Das kann man dann INNERHALB von dem C-Programm nicht mehr abfangen.
Das System haut einem auf die Finger und im unixoiden/linuxoiden Umfeld
wird der prozess gekillt, und ggf. ein Speicherabzug auf die Platte
geschrieben.
Soweit ich Python kenne, kann man dort Exceptions abfangen.
Dies ist ja auch der Grund, ein Exception-System in der Sprache zu
haben.
... damit man Probleme selbst abfangen kann, und nicht der Kernel den
prozess beendet.
>>
1
> class Test(object):
2
> def Foo(self):
3
> ...
4
> v = Test()
5
> v.Foo()
6
> v = None
7
> v.Foo() # AttributeError
8
>
Schicke doch mal kompletten Code, den man eingeben kann.
In python bin ich noch nicht so geübt.
Was passiert denn bei dem Beispiel?
Wird Python vom Kernel abgeschossen?
>>> Nur mit OCaml's Referenzen kannst du nicht gegen die Wand fahren.>> Und bei Python auch nicht.>> Python siehe oben.> OCaml/F#: Option Types>
1
> let bar (a : int option) =
2
> Option.get a
3
>
4
> bar None (* Exception *)
5
>
Schick mal lauffähigen Code ;-)
Was soll denn da schlimmes passieren?
> Geht somit auch mit OCaml oder F#. Man knallt immer noch vor die Wand,> wenn man nichts dagegen tut, hat aber zusätzlich zum Airbag noch ABS und> einen Bremsassistenten (auch wenn normalerweise garantiert ist, dass es> keine Nullreferenzen gibt).
Wird Ocaml dann vom Kernel gekillt?
Wäre mir neu. Das wäre ein Bug, wenn dem so wäre.
Peter Stegemann schrieb:
> Oliver B. schrieb:>>> Vielleicht reden wir aneinander vorbei.>> Du schwafelst. Voellig sinnlos, darauf einzugehen.
Du verstehst nicht, was ich meine.
Das ist alles.
Interessierter schrieb:
>> Pointer ist eine Abstraktion der Speicherzugriffe der jeweiligen>> Maschine und ihrer Hardware.>> Mein Gott seid ihr heutzutage "verbildet". Ihr streitet euch bei den> simpelsten Begriffen um des Kaisers Bart und schwallt ellenlos lange> Beiträge mit kaum mehr Inhalt.>> Ein Pointer ist eine Variable die auf einen Speicherbereich zeigt. Das> ist alles, mehr braucht man dazu nicht zu sagen.
Dazu kann man sagen, daß wenn man den Pointer dereferenziert,
das Programm in nicht-definierte Zustände kommen kann,
weil man z.B. einen ungültigen Pointer hat und auf nicht erlaubten
Speicherbereich zugreift, oder einen NULL-Pointer dereferenziert.
Wenn die C-Lib das nicht abfängt - was sie nicht muss, denn das ist in
der Sprachdefinition von C nicht vorgeschrieben - dann endet das ganze,
wenn man Pech hat damit, daß das Betriebssystem einem das Programm
beendet.
Man kann innerhalb des programs diesen Ausnahmezustand nicht mehr
abfangen.
Falls Du das noch nicht erlebt hast, hast Du entweder noch nicht viel
mit Pointern gearbeitet, oder zufälligerweise oder glücklicherweise noch
nicht ungltige Pointer dereferenziert. Daß Du keine Fehler beim
programmieren machst, halte ich aber für sehr unwahrscheinlich, denn die
passieen sicherlich jedem.
>> Ihr müsst mal wieder lernen einfache Dinge auch einfach erklären zu> können und nicht wie Politiker die sich vor dem eigenen Rücktritt> sträuben daherzuschwätzen.
Du hast scheinbar obiges Pointer-Dereferenzieren noch nicht gemacht.
Oder Du weisst nicht, daß Referenzen in manchen anderen Sprachen als C
dem programmierer keinen Zugriff auf einen bestimmten Speichrberg´eich
geben, indem in dr Referenz die Adresse auf einen Speicherbereich steht,
auf die der Programmierer zugreifen könnte.
So eine Referenz gibt einem den Inhalt eines Speicherobjektes, stellt
aber nicht die Adresse dar.
Und es gibt aufgrund des Sprachdesigns von z.B. Ocaml auch niemals
udefinierte Variablenwerte.
Es ist alles immer mit einem bestimmten Wert initialisiert und niemals
- wie es in C möglich ist -, ein Zeiger auf womöglich bereits
freigegebenen Speicher, wo das Programm dann beim Zugriff auf den
Speicher
vom Betriebssystem getötet wird.
Bei Sprachen, die Exceptions sauber handhaben braucht man daher auch
nicht so einen unsinn, wie in java: NullPointerException.
Wenn sowas ein Sprachfeature ist und kein Bug, dann ist das ein Manko
bei der Sprache.
Bei C sehe ich das noch ein. Bei Java, das immer als "modern"
angeprioesen wird, sehe ich es als nicht akzeptabel an.
Andreas Schwarz schrieb:
[...]
> Das mit dem Testen ist wieder ein anderes Thema. Der Punkt ist, eine> Sprache mit Bereichsüberprüfungen kann eine ganze Klasse von Fehlern> komplett ausschließen, die du durch Testen nicht weitgehend> ausschließen kannst. Dass ist keine Binsenweisheit oder Theorie, sondern> hat ganz praktische Auswirkungen: ein Großteil der Sicherheitsupdates> die du installieren darfst, egal für Windows, Linux, Firefox oder> sonstwas, sind für C-spezifische Fehler, die mit einer Sprache mit> Bereichsprüfungen nicht hätten auftreten können. Ich hab mal nach> "firefox security holes" gegoogelt und die erstbeste rausgesucht:>> http://www.mozilla.org/security/announce/2009/mfsa2009-59.html> "Heap buffer overflow in string to number conversion"> Böse ausgedrückt: 35 Jahre nach der Erfindung von C ist die Komplexität> einer String-zu-Zahl-Konvertierung damit noch nicht beherrschbar.
hahah, eben.
Sehe ich genauso.
off-by-one errors sind auch so eine nette Sache, die immer wieder vor
kommt
Sven P. schrieb:
> Zeiger in C sind keine Adressen und sind es auch nie gewesen. Zeiger> sind Zeiger. Punkt.
hahah.
Und auf was zeigen Zeiger?
Und was ist daher die Bedeutung der Zeiger (also auf etwas zu zeigen)?!
>> Wenn man Zeiger nicht missbraucht,
Du brauchst nur einen zeiger auf eine automatische variable
zurückgeben und schon hast Du ein Problem, wenn Du den später
dereferenzieren willst.
Das magst du zeiger missbrauchen nennen,
es ist aber eine Sache, die eben auch versehentlich mal passieren kann.
Und wenn man Pech hat, geht alles so lange gut, bis der Code das erste
mal beim Kunden ausgeführt wird. ;-)
Es kann nämlich sein, daß der Speicher vom System noch nicht aufgeräumt
wurde wenn man am testen ist... und der Fehler fällt beim Testen nicht
auf.
[...]
> Führt es denn zu sichererem/'besserem' Quelltext, wenn man immer mehr> implizit macht? Objekte löscht man z.B. nicht mehr, sondern verlässt> sich darauf, dass die irgendwann mal eingesammelt werden?
Das ist durchaus sehr hilfreich.
Dann kann nämlich das, was ich oben erwähnte, nicht mehr vom
Prorammierer verursacht werden.
Auf diese Weise kann Python nie zum Absturz gebracht werden.
Möglich ist es nur, wenn ein in C geschriebener Module *eiße baut.
Python ist eine sehr durchdachte, syntaktisch sehr einfache Sprache.
Manchmal sogar einfacher zu lesen als Pseudecode ;) zB
if i in [1,2,3,"vier"]
if i not in [1,2,3,"vier"]
if 0 < i < 10
Praktisch ist auch funktionale Sichtweise und unbenannte
Lambda-Funktionen.
1
>>> map(lambda x:x**2, filter(lambda t: type(t) in [int,long,float], [1,2,3,4,5,6.0,"sieben"]))
2
[1, 4, 9, 16, 25, 36.0]
filtert aus einer Liste mit beliebigen Elementen Elemente vom Typ
int,long,float. Die gefilterte Liste wird auf eine neue Liste
über lambda x:x**2 gemappt.
Grüsse
Niklas Gürtler schrieb:
> (Memo an Hirn: Niemals Diskussionen über Pointer starten) Lassen kann> ich's aber trotzdem nicht:
heheh :-)
> C ist halt so konzipiert, dass es die Abläufe in der CPU möglichst genau> abbildet, aber kürzer als Assembler ist (den Beinamen "Super-Assembler"> trägt C nicht zu Unrecht), und deswegen hat C zwangsweise Pointer, weil> es auf Hardwareebene eben nicht anders geht. Automatische> Gültigkeitsprüfung und/oder Referenzzählung hat C nicht, weil die CPU es> auch nicht hat.
[...]
Seltsame Argumentation.
Was macht C eigentlich, wenn die CPU etwas älter ist und keine
Fließkomma-Arithmetik hat?
Hat C dann auch keine Möglichkeit, zwei double's zu multiplizieren?
Bzw., in deinem Sprachgebrauch "hat C dann keine double-Multiplikation,
weil die CPU es auch nicht hat"?
Dein Vergleich hinkt also.
> Dieser niedrige Grad an Abstraktion ist gefährlich, wenn> man ihn nicht anzuwenden weiß, aber man kann gut optimieren. Firefox mag> zwar eine Menge Sicherheitslücken wegen C haben, aber ich will gar nicht> wissen, wie langsam Firefox wäre, wenn er in Ruby oder Java geschrieben> wäre.
Ruby und Java sind ja auch grottig lahm ;-)
Was die Optimierung von C angeht: abstraktere Sprachen haben Vorteile in
sehr komplexem Programmen.
Dort ist nämlich optimized-by-the-programmer nicht wirklich mehr so
einfach. daher sind bei sehr komplexen Programmen eher
higher-level-als-C-Sprachen im Vorteil.
(nein, ich meine nicht Java, das ich nach wie vor für grottig halte.)
Andreas Schwarz schrieb:
> Peter Stegemann schrieb:>> Andreas Schwarz schrieb:
[...]
>>> Es sind Fehler, die einfach zu finden sind, wenn man will. Natuerlich>> ist die Wurzel des Problems in der Sprache zu finden - aber es ist nicht>> das grosse tragische Problem, als das es gerne dargestellt wird, da es>> einfache Mittel dagegen gibt. Der Entwickler muss nur seinen Arsch>> hochkriegen und Purify & Co laufen lassen. Dass das viele nicht tun, ist>> das eigentliche Problem.>> Tools wie Purify oder Valgrind werden sowieso praktisch in allen großen> Projekten eingesetzt bei denen irgend etwas sicherheitsrelevant ist; das> was man von außen zu sehen bekommt sind die Bugs die danach noch übrig> bleiben.
Tools, die die Mankos einer Sprache ausbügeln sollen (workarounds)
zeigen ja eben die schwäche der Sprache auf.
>>> Es ist ein Mythos, dass schlampige Entwickler>> mit der richtigen Sprache ploetzlich Qualitaetssoftware abliefern.>> Es geht nicht darum dass schlampige Programmierer Qualitätssoftware> abliefern können, sondern das durchschnittliche Programmierer Software> abliefern können die nicht kommentarlos abstürzt oder Sicherheitslöcher> aufreißt nur weil irgendwo ein +1 bei einer Indizierung vergessen wurde.
Eben.
Interessierter schrieb:
> Sven P. (haku) wrote:>>> Zeiger>> sind Zeiger. Punkt.>> Tolle "Erklärung" für einen Zeiger. Erinnert mich an die Basta-Politik> eines Zigarre rauchenden Altkanzlers.
heheh
>> Andreas Schwarz (andreas) (Admin) wrote:>>> Der Fehler dass durch unerlaubt Speicherzugriffe der komplette Prozess>> kompromittiert werden kann wird durch eine Sprache mit>> Zugriffsüberprüfungen ausgeschlossen.>> Spräche das nicht eigentlich dafür nur noch eine Laufzeitumgebung wie> .NET einzusetzen?
Die Laufzeitumgebung als Workaround der Schwächen der benutzten
Programmier-Sprache?
Warum nicht gleich eine geeignetere Sprache nehmen?
Sven P. schrieb:
> Interessierter schrieb:>> Sven P. (haku) wrote:>>>>> Zeiger>>> sind Zeiger. Punkt.>>>> Tolle "Erklärung" für einen Zeiger. Erinnert mich an die Basta-Politik>> eines Zigarre rauchenden Altkanzlers.> Das sollte keine Erklärung sein. Ich wollte und will damit lediglich> unterstreichen, dass ein Zeiger keine Adresse und vorallem keine 'Zahl'> ist,
[...]
Der Zeiger repräsentiert aber eine Adresse.
Und zwar als Speicherbereichs-Adresse.
Da liegt ja dr Unterschied zu referenzen anderer Sprachen, die zwar auf
ein Speicherobjekt referenieren, aber nicht über einen zahlenwert, der
eine Speicherstelle lokalisiert, sondern auf eben jenes
speicherobjekt.... und zwar so, daß das Verändern dieser referenz zwar
auf ein anderes Speicherobjekt zeigen kann, aber niemals undefiniert
sein kann, so daß es auch kein dereferenzieren in der Weise gibt, daß
das betriebssystem einen das Programm killt, weil man in unerlaiubte
Bereiche adressieren will.
auch wenn z.B. im Windows-Kern früher furchtbar gerne
> Zeivervariablen mit Zahlen beschrieben wurden.> So von wegen:>
1
>int*l;
2
>l=5;
3
>
> Krieg ich die Krise bei.
Warum?
Warum kriegst Du dabei die Krise?
>> C an sich ist doch schon ziemlich typensicher.
hahahah, der Lacher war echt gut! :-)
Das meinst Du nicht wirklich ernst, oder?
> Klar, wenn man C mit> wildem Herumgecaste dazu zwingt, baut es auch Mist. Aber das macht> Delphi/Pascal dann auch.
Au Mann.
C ist nicht "typsicher" - und das ist bei manchen Anwendungsfällen ja
gerade auch sein Vorteil!
The biggest trouble is that integer overflow is not detected even at run time, which places OCaml right next to C and assembly with respect to type checking. One may argue that this is not a type issue (and you might even be right technically), but my retort is that the mathematical integers do not overflow, and I expect a language to provide something at least somewhat resembling them (and no, I cannot always use bignums - they are slow and cannot be used directly in arithmetics, see below).
will damit sagen, dass jede Sprache Schwächen hat. Python mag auch
grottig
lahm (10-30 mal langsamer) aber dafür ...
Arc Net schrieb:
> Sven P. schrieb:>> Arc Net schrieb:>>> Sven P. schrieb:>>>> C an sich ist doch schon ziemlich typensicher.>>>>>> Nein. C ist nur statisch typisiert, aber weder stark typisiert, noch>>> bietet es Typsicherheit.>>>> Das ist mir geläufig, ich arbeite seit Jahren damit.>> Wenn man es nicht mit der Brech-Cast-Stange drauf ankommen lässt, reicht>> das meistens auch vollkommen aus.>> Wenn C nicht viel zu viele implizite Casts von sich aus machen würde
eben.
> und> Casts von void* nach xyz* überhaupt nicht zulassen würde...
eben.
>>> Ansonsten würde es mich ja mal interessieren, in welcher Sprache denn>> ein System geschrieben ist, welches 99,9999999% Verfügbarkeit erreicht.>> Und vorallem, in welcher Sprache diese Sprache implementiert ist...>> Erlang.
Das hatte ich vermutet. :-)
Oliver B. schrieb:
> Wenn man in C einen NULL-Pointer dereferenziert oder> einen Pointer ins Nirgendwo benutzt, dann landet man im Nirgendwo.> Das kann man dann INNERHALB von dem C-Programm nicht mehr abfangen.
Deshalb auch der Satz mit dem Airbag und der Geschwindigkeit,
> Das System haut einem auf die Finger und im unixoiden/linuxoiden Umfeld> wird der prozess gekillt, und ggf. ein Speicherabzug auf die Platte> geschrieben.>> Soweit ich Python kenne, kann man dort Exceptions abfangen.
Genau das ist der Punkt: Man kann Exceptions abfangen, man kann auch auf
Nullpointer testen, man kann auch in C mit setjmp/longjmp eine Art
Exception-Handling basteln...
Das einzige was hier nicht passieren kann, ist, dass damit Code
eingeschleust werden kann. Trotzdem kann das Programm einen
undefinierten Zustand hinterlassen (nicht alle Daten gespeichert etc).
1
# das reicht als Test in Python
2
v = None
3
v.Foo() # AttributeError
4
5
(* das läuft so in OCaml/F# *)
6
let bar (a : int option) =
7
Option.get a
8
9
bar None (* Exception *)
> Dann kann nämlich das, was ich oben erwähnte, nicht mehr vom> Prorammierer verursacht werden.
Nicht mehr mit denselben Auswirkungen siehe oben
Sven P. schrieb:
> Hm, C castet von alleine nur void * weg, an allen anderen Stellen muss> es zumindest warnen.
Warnen alle Compiler vor so etwas
q Arc Net (arc):
>> ei, du sollst nicht die werbesprüche der hersteller nachplappern sonder>> mindestens mal mit dem zeug gearbeitet haben, wissen wie's funktioniert>> und den rest deiner aussage mal im lichte der sinnhaftigkeit prüfen.>>Wie wär's mit Argumenten, statt leerer Behauptungen?
1) der hersteller gibt eine reaktionszeit der interreuptroutine an, aber
nicht des java codes. auf der ganzen seite war kein eine einzige
untersuchung/angabe zur latenzzeit.
2) auf der tollen seite http://www.codeplex.com/singularity funktioniert
kein einziger link zu den original-"papers". ausserdem ist das ding noch
so was von weit weg vom realen einsatz wie kaffeesudlesen.
3) die "echtzeitfähigkeit" wird durch meist sehr brutales weglassen von
sicherheitsfeatures erreicht. geeigneter code kann durchaus die
"sicherheitsprüfung" des compilers erfolgreich bestehen, aber dennoch in
der vm mist bauen.
abgesehen davon ist's hübsch zu sehen wie sich leute wegen heisser luft
beflegeln :-)
Oliver B. schrieb:
Du führst gerne Selbstgespräche, hu?
> Sven P. schrieb:>> Interessierter schrieb:>>> Sven P. (haku) wrote:>>>>>>> Zeiger>>>> sind Zeiger. Punkt.> [...]>> Der Zeiger repräsentiert aber eine Adresse.> Und zwar als Speicherbereichs-Adresse.
Wo steht das? Ein Zeiger zeigt auf ein Objekt.
> und zwar so, daß das Verändern dieser referenz zwar> auf ein anderes Speicherobjekt zeigen kann, aber niemals undefiniert> sein kann, so daß es auch kein dereferenzieren in der Weise gibt, daß> das betriebssystem einen das Programm killt, weil man in unerlaiubte> Bereiche adressieren will.
Nicht?
1
#include<iostream>
2
3
usingnamespacestd;
4
constint&min(constint&a,constint&b){
5
if(a>b)
6
returna;
7
else
8
returnb;
9
}
10
11
intmain(){
12
constint&i=min(1+3,1+4);
13
cout<<i<<endl;
14
}
Bitte sehr. Undefiniertes Verhalten mit Referenzen in C++; i
referenziert ein temporäres Objekt, das nicht mehr exisitert.
>> So von wegen:>>
1
>>int*l;
2
>>l=5;
3
>>
>> Krieg ich die Krise bei.>> Warum?>> Warum kriegst Du dabei die Krise?
Weil Zeiger keine Zahlen sind. Es steht nirgendwo geschrieben, dass ein
(int *) den Wertebereich eines int hat oder alle Werte eines int
darstellen kann.
Zitat:
>Any pointer type may be converted to an integer type. Except as>previously specified, the result is implementation-defined. If>the result cannot be represented in the integer type, the behavior>is undefined. The result need not be in the range of values of any>integer type.
Ein Zeiger kann also in einen Integer verwandelt werden, es ist aber
absolut freigestellt, welche die Abbildung dazwischen ist. Lediglich der
NULL-Zeiger ist eindeutig 0.
Arc Net schrieb:
> Sven P. schrieb:>> Hm, C castet von alleine nur void * weg, an allen anderen Stellen muss>> es zumindest warnen.>> Warnen alle Compiler vor so etwas>
1
>intb=0;
2
>double*dP=(double*)&b;
3
>// oder hier vor
4
>void(*fP)()=(void(*)())&b;
5
>fP();
6
>
Nein. Muss er auch nicht, denn die Zeigertypen sind identisch, da du sie
explizit herumgecastet hast.
Ich glaube, man merkt i.d.R. schon, wenn man einen Cast formuliert.
Arc Net schrieb:
> Oliver B. schrieb:>> Wenn man in C einen NULL-Pointer dereferenziert oder>> einen Pointer ins Nirgendwo benutzt, dann landet man im Nirgendwo.>> Das kann man dann INNERHALB von dem C-Programm nicht mehr abfangen.>> Deshalb auch der Satz mit dem Airbag und der Geschwindigkeit,
öööhh.
Dann meinst anscheinend Du zwar das selbe, aber mein Anliegen war,
ide Unterscheidung zwischen C und OCaml/Python darzustellen,
daß eben in C der gesamte Prozess gekillt wird.
Das ist dann von dem Prozess selbst nicht mehr aufzuhalten!
Also kann man für solche Fälle keine Fehlerbehandlung einbauen!
/* geht eben nicht */
/* --------------- */
if( system_wants_to_kill_myself_with_coredump )
{
fange_das_mal_ab();
}
>>> Das System haut einem auf die Finger und im unixoiden/linuxoiden Umfeld>> wird der prozess gekillt, und ggf. ein Speicherabzug auf die Platte>> geschrieben.>>>> Soweit ich Python kenne, kann man dort Exceptions abfangen.>> Genau das ist der Punkt: Man kann Exceptions abfangen, man kann auch auf> Nullpointer testen, man kann auch in C mit setjmp/longjmp eine Art> Exception-Handling basteln...
...basteln... na das ist ja echt nicht die Art von Qualitätsanpruch, die
ich meine! ;-)
Man kann Exceptions abfangen. Ja.
Man kann auch auf NULL-Pointer testen.
Oder man kann das vergessen.
Mann kann aber keine NULL-Pointer-Dereferenzierung oder
Pointer-der-auf-ungültigen-Speicherbereich-zeigt-Dereferenzierung
abfangen!
if( *ungueltiger_Pointer )
{
zu_spaet();
}
Eine eine Exception, die man direkt dort, wo sie entsteht vergessen
hat zu catchen, die lässt sich wenigstens noch auf einer anderen Ebene
des programms nochmal abfragen/catchen.
Das geht auch bei einem NULL-Pointer.
Das geht aber nicht, wenn man einen NULL-/ungültigen Pointer
dereferenziert.
Keine Chance mehr!
Ist das etwa nicht nachvollziehbar, was ich hier schreibe?
Ist der Zusammenhang so schwer zu verstehen?
> Das einzige was hier nicht passieren kann, ist, dass damit Code> eingeschleust werden kann. Trotzdem kann das Programm einen> undefinierten Zustand hinterlassen (nicht alle Daten gespeichert etc).>>
1
> # das reicht als Test in Python
2
> v = None
3
> v.Foo() # AttributeError
4
>
5
> (* das läuft so in OCaml/F# *)
6
> let bar (a : int option) =
7
> Option.get a
8
>
9
> bar None (* Exception *)
10
>
OK, also eben nur eine Exeption.
Der prozess (ocaml /python) läuft weiter.
Also keine nichtabangbare Situation.
Also hat nur C hier ein Problem!
Das ist es, wobvon ich die ganze Zeit rede.
>...das ist ja ganz nett... und was willst Du uns damit sagen?
sorry, war etwas aus dem Kontext gerissen. Es bezog sich auf Dein
Statement,
dass Ruby grottig lahm sei. Ich habe Python verwendet, weil ich es
gerade am Laufen hatte. Aber gut, jetzt schmeisse ich Ruby an.
1
irb(main):020:0* start = Time.now; d = 45**1000; Time.now - start
Im Grunde juckt es doch nicht wirklich ob ein Programm 0.001 Sekunde
braucht oder 0.02. Selbstverständlich gilt das nicht für alle Programme.
Das Problem, dass ich bei diesen netten Skriptsprachen sehe, ist, dass
doch mehr Fehler erst zur Laufzeit abgefangen werden. Aber sie sind
nur ein Werkzeug und kein "Hammer für alles".
By the way: Etwas Haskell und Clisp kenne ich auch. Ich konnte mich auch
mit der anderen Denkweise anfreunden. Leider hatte ich dann nicht mehr
viel Zeit tiefer einzusteigen.
Grüsse
Sven P. schrieb:
> Oliver B. schrieb:> Du führst gerne Selbstgespräche, hu?
falsch gequotet?
>>> Sven P. schrieb:>>> Interessierter schrieb:>>>> Sven P. (haku) wrote:>>>>>>>>> Zeiger>>>>> sind Zeiger. Punkt.>> [...]>>>> Der Zeiger repräsentiert aber eine Adresse.>> Und zwar als Speicherbereichs-Adresse.> Wo steht das? Ein Zeiger zeigt auf ein Objekt.>>> und zwar so, daß das Verändern dieser referenz zwar>> auf ein anderes Speicherobjekt zeigen kann, aber niemals undefiniert>> sein kann, so daß es auch kein dereferenzieren in der Weise gibt, daß>> das betriebssystem einen das Programm killt, weil man in unerlaiubte>> Bereiche adressieren will.> Nicht?
[...]
> Bitte sehr. Undefiniertes Verhalten mit Referenzen in C++; i> referenziert ein temporäres Objekt, das nicht mehr exisitert.
Ich redete nicht über C++, sondrn OCaml. :-)
>>>> So von wegen:>>>
1
>>>int*l;
2
>>>l=5;
3
>>>
>>> Krieg ich die Krise bei.>>>> Warum?>>>> Warum kriegst Du dabei die Krise?> Weil Zeiger keine Zahlen sind. Es steht nirgendwo geschrieben, dass ein> (int *) den Wertebereich eines int hat oder alle Werte eines int> darstellen kann.
Und warum kompiliert das dann?
Müsstest Du nicht eine Krise kriegen,
darüber, daß C sowas erlaubt?
Stattdessen kriegst du eine Krise, wenn man sowas schreibt.
Das ist der Knackpunkt.
Würde die Sprache das nicht erlauben, und dahr den code nicht
kompilieren, gäbe es keinen Grund, sich drüber aufzuregen / darüber eine
krise zu kriegen, denn in einem lauffähigen Code würde so ein konstrukt
nicht auftreten.
Man müsste also auch keine teste darüber machen, keine Warnings dafür
beim Kompilieren ausgeben und auch keine externen Tools aufrufen, die
sowas ent-Krise-ln.
Beispiel für Referenzen in Ocaml:
1
# let x = ref 55;;
2
val x : int ref = {contents = 55}
3
# !x;;
4
- : int = 55
5
# let x = ref 4567;;
6
val x : int ref = {contents = 4567}
7
# !x;;
8
- : int = 4567
9
# let x = ref "Hallo";;
10
val x : string ref = {contents = "Hallo"}
11
# !x;;
12
- : string = "Hallo"
13
# let mal_zwei x1 x2 = x1 *. x2;;
14
val mal_zwei : float -> float -> float = <fun>
15
# !x;;
16
- : string = "Hallo"
17
# !x 3.98 4.09;;
18
Error: This expression is not a function; it cannot be applied
19
# let x = ref mal_zwei;;
20
val x : (float -> float -> float) ref = {contents = <fun>}
21
# !x;;
22
- : float -> float -> float = <fun>
23
# !x 3.98 4.09;;
24
- : float = 16.2782
25
#
Normalerweise braucht man auch nicht mal referenzen nehmen,
denn es geht auch meist ohne Referenzen und man macht so Sachen, wie
1
let a = 22;;
Dann kann man über "a" auf die "22" zugreifen.
Es gibt wederbei den referenzen noch bei variablen ohne referenzen eine
Operation, die das leistet, was man in C mit "&" erreicht.
Ein Äquivalent für
1
int x = 55;
2
int* x_ptr = &p;
existier in Ocaml nicht.
Daher kann es auch keine äquvalenten Probleme geben,
wie in C, wo man undfinierte Pointer hat oder *NULL.
>Das ist der Knackpunkt.>Würde die Sprache das nicht erlauben, und dahr den code nicht>kompilieren, gäbe es keinen Grund, sich drüber aufzuregen / darüber eine>krise zu kriegen, denn in einem lauffähigen Code würde so ein konstrukt>nicht auftreten.
bitte entschuldige, das ist schwachsinn. nur weil es auf einer
rechnerarchitektur (z.b.: pc userspace) nicht sinnvoll ist heißt nicht,
dass das konstrukt immer sinnlos ist. z.b. auf microcontrollern macht es
erstaunlicherweise sinn.
wenn das dem programmierer zu komplex ist, dann soll er lieber eine
kischelsprache nehmen.
Auf Mikrocontrollern muss man zwar manchmal bestimmte Adressen
adressieren, aber dazu ist es nicht nötig zur Laufzeit Pointer
umzubiegen.
Übrigens:
"Wichtige Regeln - erst lesen, dann posten!
* Groß- und Kleinschreibung verwenden"
Zwie Blum schrieb:
> q Arc Net (arc):>>> ei, du sollst nicht die werbesprüche der hersteller nachplappern sonder>>> mindestens mal mit dem zeug gearbeitet haben, wissen wie's funktioniert>>> und den rest deiner aussage mal im lichte der sinnhaftigkeit prüfen.>>>>Wie wär's mit Argumenten, statt leerer Behauptungen?>> 1) der hersteller gibt eine reaktionszeit der interreuptroutine an, aber> nicht des java codes. auf der ganzen seite war kein eine einzige> untersuchung/angabe zur latenzzeit.
Woher soll der Hersteller wissen, wie lang deine Interruptroutine
braucht?
Thread- und JVM-Wechsel werden über interne Hardwaretimer realisiert...
> 2) auf der tollen seite http://www.codeplex.com/singularity funktioniert> kein einziger link zu den original-"papers".http://research.microsoft.com/en-us/projects/singularity/#publications
(Die Seite ist nicht schwer zu finden...)
http://research.microsoft.com/pubs/69431/osr2007_rethinkingsoftwarestack.pdf> ausserdem ist das ding noch> so was von weit weg vom realen einsatz wie kaffeesudlesen.
Was man sieht ist schon ganz gut brauchbar für ein Forschungsprojekt
(Helios und Midori gibt's auch noch, Linux wurde auch nicht an einem Tag
erschaffen)
Oliver B. schrieb:
> Dann meinst anscheinend Du zwar das selbe,
Ja
> aber mein Anliegen war,> ide Unterscheidung zwischen C und OCaml/Python darzustellen,> daß eben in C der gesamte Prozess gekillt wird.
eine Möglichkeit gibt's noch: signal.h einbinden und
signal(SIGSEGV, handler) dazu noch setjmp/longjmp, (aber lassen wir das)
> Beispiel für Referenzen in Ocaml:
Man sollte vllt dazu sagen, dass es in OCaml/F#, besser gesagt in
funktionalen Sprachen allgemein, keine Variablen gibt, sondern nur Werte
die an einen Namen gebunden werden.
Referenzen erzeugen ein neues "Objekt", kopieren den ursprünglichen Wert
und dann kann der Wert im neuen Objekt geändert werden (nicht aber die
Referenz, auch wenn es im Beispiel so aussieht).
zwieblum schrieb:
>>Das ist der Knackpunkt.>>Würde die Sprache das nicht erlauben, und dahr den code nicht>>kompilieren, gäbe es keinen Grund, sich drüber aufzuregen / darüber eine>>krise zu kriegen, denn in einem lauffähigen Code würde so ein konstrukt>>nicht auftreten.>> bitte entschuldige, das ist schwachsinn.
Das ist nicht Schwachsinn, sondrn Du raffst es einfach nicht.
Wenn Du nicht verstehen willst, und stattdessen meine
Ansichten/Argumente als Unsinn bezeichnist, dann zeigt das Deine Idiotie
auf.
> nur weil es auf einer> rechnerarchitektur (z.b.: pc userspace) nicht sinnvoll ist heißt nicht,> dass das konstrukt immer sinnlos ist.
Du verstehst es icht.
Ich habe nicht gesagt, daß C immer sinnlos ist.
Und Du verstehst auch nicht, daß die Sprache, in der man programmiert
vom Compiler übersetzt wird, und daß Dein Argument bzgl. Architekturen
damit stark schwächelt.
> z.b. auf microcontrollern macht es> erstaunlicherweise sinn.
C macht auch auf PCs Sinn.
Du raffst nicht, daß ich nicht sage, daß C keinen Sinn macht,
sondern daß es ftmals keinen Sinn macht, die Schwierigkeiten, die es
mitbringt, hinzunehmen, nur weil man zu faul odr nicht in der Lage ist,
andere Sprachen zu verstehen.
>> wenn das dem programmierer zu komplex ist, dann soll er lieber eine> kischelsprache nehmen.
Dieses Argument ist so bescheuert... es zeigt, daß Du Dich wohl sehr
toll fühlst, eine an vielen Stellen schwächelnde Sprache zu nutzen,
daraus das Argument ziehst, ein super toller programmierer zu sein; das
heisst, nur weil Du willst, daß man Dir huldigt, wie kewl Du doch bist,
nimmst Du eine Sprache, die so super dolle ist und als "Guru-like" gilt.
dabei reicht Dein geist offenbar nicht aus, auch zu sehen, daß hinterm
Tellerand noch mehr kommt.
Ich habe selbst C viele Jahre lang benutzt und finde es immernoch besser
als vieles andere, was einem heutzutage so als "modern" angepriesen
wird.
Nur denke ich nicht, daß das das non-plus-ultra ist.
Kannst Du überhaupt auch noch andere Sprachen (und kannst Du C wirklich,
oder laberst Du nur?), oder verteidigst Du C nur, weil Du nix anderes
kannst und auch zu faul bist, m,al was anderes zu lernen?
Sven P. schrieb:
> Oliver B. schrieb:> Du führst gerne Selbstgespräche, hu?>>> Sven P. schrieb:>>> Interessierter schrieb:>>>> Sven P. (haku) wrote:>>>>>>>>> Zeiger>>>>> sind Zeiger. Punkt.>> [...]>>>> Der Zeiger repräsentiert aber eine Adresse.>> Und zwar als Speicherbereichs-Adresse.> Wo steht das? Ein Zeiger zeigt auf ein Objekt.
[...]
Und was ist die Differenz aus zwei Objekten, auf die ein Zeiger zeigt?
Wie bitteschön erklärst Du Zeigerarithmetik mit Deinem
Erklärungs-Ansatz?
Was hier leider missverstanden wird: "Objekt" muß man im Kontext von C
anders interpretieren als im Kontext von OO-Sprachen.
Ein Byte auf das ein Zeiger zeigt (und dessen (virtuelle)
Speicheradresse der Zeiger beinhaltet) wird auch als "Objekt"
bezeichnet, aber in anderem Sinne als in OO-Sprachen.
Wenn in C die Pointer/Zeiger so abstrakt wären, wie es hier gerne
dargestellt werden soll, dann bitte erklärt) mir das Mysterium der
Zeigerarithmetik.
Und wozu gibt es bitteschön sizeof()?
Interessant, daß, wenn man über abstrakte Referenzen spricht, man als
überkandidelt gilt, und wenn es um C geht, will man dann diese abstrakte
Denke gerne doch noch schnell einheimsen.
Sven P. schrieb:
[...]
> Weil Zeiger keine Zahlen sind.
[...]
Sondern was sind zeiger?
Und wenn Zeiger keine Zahlen sind,
wie kommt es dann, daß man die Differenz von Zeigern bilden kann?
Banane - Zitrone = 123
...
Ach ja, "2 mal 2 gleich grün". :-)
Hahahahh :-)
Arc Net schrieb:
> Zwie Blum schrieb:>> q Arc Net (arc):>>>> ei, du sollst nicht die werbesprüche der hersteller nachplappern sonder>>>> mindestens mal mit dem zeug gearbeitet haben, wissen wie's funktioniert>>>> und den rest deiner aussage mal im lichte der sinnhaftigkeit prüfen.
[...]
>> aber mein Anliegen war,>> ide Unterscheidung zwischen C und OCaml/Python darzustellen,>> daß eben in C der gesamte Prozess gekillt wird.>> eine Möglichkeit gibt's noch: signal.h einbinden und> signal(SIGSEGV, handler) dazu noch setjmp/longjmp, (aber lassen wir das)>
:-)
>> Beispiel für Referenzen in Ocaml:> Man sollte vllt dazu sagen, dass es in OCaml/F#, besser gesagt in> funktionalen Sprachen allgemein, keine Variablen gibt,
jau.
...den rest fand ich aber irgendwie seltsam erklärt...
...ok, ist schon spät ;-)
Oliver B. schrieb:
Du redest wirklich mit dir selbst...
> Sven P. schrieb:> [...]>> Weil Zeiger keine Zahlen sind.> [...]>> Sondern was sind zeiger?
Zeiger.
> Und wenn Zeiger keine Zahlen sind,> wie kommt es dann, daß man die Differenz von Zeigern bilden kann?> Banane - Zitrone = 123
Kann man auch nur bei gleichartigen Zeigern. Objekte können in Vektoren
liegen (wobei die Adressen der Einzelobjekte eines Vektors nicht
unbedingt numerisch hintereinander liegen müssen -- kann der Compiler
frei entscheiden) an. Die Differenz zweier Zeiger (Resultattyp:
ptrdiff_t) gibt an, wie viele Objekte zwischen den Zeigern im Vektor
liegen.
Beispiel:
1
Objekt1 Objekt2 Objekt3 Objekt4
2
^ ^
3
| |
4
zeig1 zeig2
Es ist unbestimmt:
- wo die Objekte im physischen Speicher liegen
- wie groß die Zeiger sind, wenn sie in Integer umgewandelt werden
Es steht lediglich fest, dass zeig2 größer als zeig1 ist, da zeig2 auf
ein Objekt rechts von zeig1 zeigt. Was nicht heißen muss, dass Objekt3
an einer größeren Adresse im Speicher liegen muss. Zeiger können auch
Strukturen sein, etwa solcherart:
1
structpointer{
2
longseg;
3
longoff;
4
}
Dann macht der Compiler sich entsprechend Gedanken über die Umsetzung.
Auf einigen Mikroprozessoren werden Zeiger etwa drei Bytes breit
implementiert und sind dann transparent für Flash, RAM und EEPROM
nutzbar. Auch da muss der Compiler dann halt die geeigneten
Zugriffsmethoden einbauen.
Sizeof gibt die Größe eines Objektes in Einheiten von char wieder. Hat
auch nichts mit Bits und Bytes zu tun..
Was Zeiger und Integer angeht:
Ich weiß nicht, wieso das in C erlaubt wird, aber bisher hatte ich keine
sinnvolle Verwendung dafür. Mir sind aber die Unzulänglichkeiten
bekannt, wieso das in die Hose gehen kann, das reicht mir.
Vielleicht sollte man 'rm' auf der Konsole auch verbieten, das warnt
auch nicht, wenn man irgendwo im Heimatverzeichnis ein Leerzeichen zu
viel mitgibt und damit nicht *~, sondern * und ~ löscht.
Wird in C++ eine Exception nicht aufgefangen, wird im Übrigen auch der
Prozess abgeknallt.
>> Sondern was sind zeiger?> Zeiger.
Das ist genau der Typ von Definition, der das Lernen von Programmier-
sprachen manchmal so schwer macht ;-)
Die andere, nicht selbstreferenzierende "Definition": Ein Zeiger bedarf
keiner Definition, er ist einfach da.
Beide Varianten findet man in ähnlicher Form tatsächlich in Lehrbüchern.
Ich frage mich nur, was das soll.
Als ich damals nach Basic und Assembler als dritte Programmiersprache
Pascal lernte, hatte ich anfangs unendliche Schwierigkeiten, das Konzept
der Zeiger zu verstehen und richtig anzuwenden, da es diese ja in Basic
und Assembler überhaupt nicht gab. Irgendwann fiel es mir wie Schuppen
von den Augen: Diese obskuren Zeiger sind ja nichts anderes als die
Speicheradressen der Daten, auf die sie zeigen. Speicheradressen waren
mir aber sehr wohl ein Begriff, da es sie sowohl in Basic als auch in
Assembler gab.
Sowohl beim Lernen als auch bei der Anwendung von Programmiersprachen
finde ich es nicht nur legitim, sondern sogar wichtig, mitunter auf
Rechnerarchitekturebene zu denken, weil das einfach die Codequalität
verbessert.
Sven, du beziehst dich mit der Unterscheidung zwischen Zeigern und Ad-
ressen auf den C-Standard, in dem weitgehend vermieden wird, die Begrif-
fe "Pointer" und "Address" synonym zu verwenden, um dem Compilerentwick-
ler die Möglichkeit offen zu lassen, die Zeiger auf speziellen Rechner-
architekturen auch anders zu implementieren. Man merkt aber an folgenden
Passagen, dass selbst die Autoren des Standards bei Zeigern immer auch
an Adressen denken:
"p is assigned the address of the first element of an array […]"
Dabei ist p eine Zeigervariable.
"6.5.3.2 Address and indirection operators"
Der unäre &-Operator wird also "Adressoperator" und nicht etwa "Zeiger-
operator" genannt.
"The unary & operator yields the address of its operand."
Hier wieder.
"An address constant […] shall be created explicitly using the unary
& operator or an integer constant cast to pointer type, […]"
Ohne diese offizielle Erlaubnis, Integers durch Casts als konstante Ad-
ressen zu interpretieren und dann als Zeiger für Zugriffe auf Speicher-
zellen oder I/O-Register zu verwenden, wären bspw. sämtliche io*.h-Da-
teien der AVR-LibC "böse".
Wenn man erst einmal vom akademischen Sockel der Zeiger-Adressen-Unter-
scheidung heruntergekommen ist, merkt man, dass die Referenzen, wie sie
bspw. in C++ und Java vorkommen, nichts weiter als syntaktisch versüßte
Zeiger mit eingeschränkten Manipulationsmöglichkeiten, und damit letzt-
endlich ebenfalls Adressen sind.
Als vor Kurzem ein Kollege ein Verständnisproblem mit C++-Referenzen
hatte und ich ihm mangels Zeit für eine detailliertere Erklärung einfach
antwortete "Das sind letztendlich konstante Zeiger bzw. Adressen, für
die man zur Dereferenzierung kein '*' braucht", konnte er perfekt damit
umgehen. Wahrscheinlich viel besser, als wenn ich ihm eine 30-Minuten-
Predigt, beginnend mit "Ja, das ist etwas ganz Abstraktes und hat mit
Zeigern und Adressen überhaupt nichts zu tun ..." gehalten hätte.
Ich kenne auch keinen Compiler, egal welcher Sprache, der Zeiger und
Referenzen nicht als Adressen der Zielarchitektur implementiert.
Vielleicht gibt es einen, aber es reicht ja, sich das Leben erst dann
schwer zu machen, wenn man einen solchen tatsächlich benutzt ;-)
Arc Net schrieb:
[...]
> eine Möglichkeit gibt's noch: signal.h einbinden und> signal(SIGSEGV, handler) dazu noch setjmp/longjmp, (aber lassen wir das)
[...]
Dir ist aber bewusst, daß signal() nicht reliable ist?
Wenn schon, dann sigaction() und Co.
Die sind aber nicht wirklich zum Sprachumfang von C gehörend.
yalu schrieb:
>> Sven, du beziehst dich mit der Unterscheidung zwischen Zeigern und Ad-> ressen auf den C-Standard, [...]
Das ist mir schon klar.
Wenn du den Standard genau liest, wirste feststellen, dass von Adressen
die Rede ist, nicht aber von Adressen im physikalischen Speicher, ROM,
RAM, EEPROM, Festplatte oder sonstwo. Der Compiler ganz allein kann sich
aussuchen, wie er seine Zeiger auf physischen Speicher abbildet und
wieso und warum.
Natürlich fasst man Zeiger als Adressen auf, aber nicht als
physikalische Adresse in zu DRAM-Baustein oder Register.
Zwei Zeiger in einem Computer können auch denselben Inhalt haben (oder
meinethalten zum selben int-Wert kommen, wenn man sie als int
interpretiert), d.h. auf die gleiche 'Adresse' verweisen und trotzdem
sind zwei völlig verschiedene Objekte gemeint. Deshalb kann man Zeiger
z.B. auch nicht ohne Weiteres zwischen zwei Prozessen austauschen.
> Ohne diese offizielle Erlaubnis, Integers durch Casts als konstante Ad-> ressen zu interpretieren und dann als Zeiger für Zugriffe auf Speicher-> zellen oder I/O-Register zu verwenden, wären bspw. sämtliche io*.h-Da-> teien der AVR-LibC "böse".
Die sind nicht böse, sondern funktionieren zunächst einzig und alleine
mit dem Compiler, für die sie entworfen wurden. Dass die
Integer-Interpretation eines Zeigers beim avr-gcc ziemlich direkt mit
der Adresse im SRAM/Registerfile übereinstimmt, haben die
(avr-)gcc-Leute so eingerichtet.
Auf einer PC-Architektur würde das Prinzip schon nicht mehr aufgehen, da
mindestens eine MMU die 'Adressen' verbiegen und sonstwo einblenden
kann.
Wie ich bereits sagte: Die Abbildungsfunktion vom Zeiger zum Integer ist
eine völlig unbestimmte. Kann linear sein, oder halt auch nicht.
Vielleicht missverstehen wir uns auch einfach dabei, was eine 'Adresse'
ist ;-)
Ich fasse Zeiger auch als Adressen auf, aber ich mache keine Annahmen
darüber, wo ich denn im RAM/... gelandet bin. Das verbietet
beispielsweise eine Reihe von 'Sauereien', wie etwa Structs und Unions,
um an einzelne Bytes von Datenworten zu kommen und so weiter.
Sven P. schrieb:
> Wenn du den Standard genau liest, wirste feststellen, dass von Adressen> die Rede ist, nicht aber von Adressen im physikalischen Speicher, ROM,> RAM, EEPROM, Festplatte oder sonstwo.
Wenn du deine eigene Aussage von weiter oben
> Zeiger in C sind keine Adressen und sind es auch nie gewesen. Zeiger> sind Zeiger. Punkt.
genau liest, wirste feststellen, dass von Adressen die Rede ist, nicht
aber von Adressen im physikalischen Speicher, ROM, RAM, EEPROM,
Festplatte oder sonstwo. ;-) SCNR
> Vielleicht missverstehen wir uns auch einfach dabei, was eine> 'Adresse' ist ;-)
In diesem Kontext, wo es um Programmiersprachen geht, beziehe ich auf
Adressen innerhalb des Adressraums, in dem auch die in der jeweiligen
Sprache programmierte Anwendung läuft. Und genau als solche werden
Zeiger und Referenzen üblichweise implementiert.
Dass es auf ganz anderen Hardware-/Softwareebenen auch ganz andere
Adressräume gibt, ist schon klar, aber davon sieht das Programm
(zumindest auf direktem Weg) normalerweise nichts.
Hi
Falls ihr es gemerkt habt, eure Debatte über all die vielen
Programmiersprachen deren flacher Speicher enlose Verkettung von
Pointern erzeugt hat den Threadersteller mittlerweile Wortlos gemacht
und ihr diskutiert mittlerweile eure Votrlieben aus, ohne auf den
Hintergrund zu achten. Da ist eine Klasse von Schülern, deren Interesse
für µC und PC Programmierung sinnvoll angeregt werden. Warum nicht mit
Delphi(Pascal) auf PC, nur weil's da eine IDE gibt, die schnelle
Ergebnisse bringt. Welcher Dummkopf wird seinen Schülern erzählen, das
man den Code der IDE mal eben löschen kann oder eine UNIT mal eben
umtaufen darf? Also versetzt euch doch bitte mal von eurem hohen
Programmiererroß auf die Stufe eines Lehrers, der von all den Dingen,
die hier angesprochen werden vermutlich zu 80% Bahnhof versteht. Soll er
nun das Handtuch werfen, weil mittlerweile sein Wissen um mindestens 10
Programmiersprachen gewachsen ist und deren Einsatz in ach so herrlichen
0815 Anwendungen unentbehrlich ist? Also, zurück zum Thema auf der BAsis
der Schüler:
Welche Programmiersprache ist ohne teure Lizenz zu bekommen und wie
verständlich kann ein Lehrkörper damit umgehen.
Wie werden µC eingesetzt und wie kann ich ein Projekt aufziehen, an
welchem alle Schüler Interesse haben und nicht nur ein paar blinkende
LED's sehen.
Danach solltet ihr die Programmiersprache auswählen! Nicht jeder Schüler
wird ein Kollege von euch werden. Manche, weil sie feststellen das zum
Programmieren eine spezielle Denkweise gehört und sie besser
fußballspielen können. Andere werden vermutlich Doktoren, Physiker,
Mathematiker oder Chemiker, vielleicht Lehrer oder auch "nur" Lokführer.
Wenn ich geschrieben habe, Basic oder Pascal halte ich für keine gute
Einstiegssprache, bezog sich das auf µC. Wer meine Texte liest, erkennt
sehr schnell, das es auch noch PC's gibt, die ich heut nur in krassen
Sonderfällen mit Assembler traktieren würde. Wer sich für ein Studium
zum Programmierer entscheidet, erlernt sicherlich mehr als nur C,Basic
und Pascal und er wird wissen, welche Sprache für welche
Anwendungssoftware Schwerpunkt ist. Dies hier zu diskutieren ist
schlichtweg "Thema verfehlt"
Gruß oldmax
Auf diesen uralt Thread noch mal meine Meinung.
Um eine Computersprache zu lernen ist keine geeignet.
Schon die Prämissen sind so intuitiv wie die Minkowski Diagramme zur
speziellen Relativitätstheorie.
Es geht damit los das es eine Anweisungsliste gibt die mit dem was die
Kiste letzlich macht nichts zu tun hat.
Diese ist angefüllt mit kryptischen wortähnlichen Buchstabenfolgen. Im
Fall von C kommen noch aberwitzige Sonderzeichen wie {} dazu die auch
noch exakt an den notwendigen Positionen stehen müssen weil ein
"compiler" - schon dieses Konstrukt zu begreifen heißt für einen
unbescholtenen Bürger erstmal 3 Wochen Lernarbeit- sonst zu blöd ist die
simpelste Textfolge überhaupt auf einem "Schirm" - noch so eine
aberwitzige Definition - zu "Printen" was ein Normalbürger nun mal mit
Weihnachtsgebäck assoziiert und nicht mit irgendwas wo der
betriebsblinde Progger davon ausgeht der Rest der Welt davon schon mal
gehört hätte.
Von Interaktion hat auch noch keines dieser dubiosen Systeme etwas
gehört. Ein 10 Print "Hello World" macht selbst wenn alles richtig
geschrieben ist absolut gar nichts. Man muss das ganze mit "Run" F5
sonstwas starten um mit ein wenig Glück in irgendeinem anderen Fenster
etwas zu sehen.
Bis dahin hat der studierende natürlich den nächsten Kram zu lernen der
mit der eigentlichen Zeile nichts mehr zu tun hat.
Er muss erstmal für ihn sinnlose Konstrukte lernen um einfachste
Zusammenhänge erstmal zu sehen. Die sog. Einstiegsschwelle auf die Otto
Normalprogger auch noch stolz ist da er ja so toll war das ganze zu
überwinden. Das ist zwar für das Ego Klasse hat aber bestenfalls mit
wilhelminischer kuk Pädagogik, aber nichts mit Lehrmethoden des Jahres
2000+ zu tun.
Ein System wo links die Anweisung und rechts das Ergebnis erscheint ist
mir nicht bekannt. Wäre so etwas aber nicht aber didaktisch um Längen
besser als der ganze Krampf mit dem die Proggerwelt den Einstieg unnötig
erschwert?
Gast XIV schrieb:
> Er muss erstmal für ihn sinnlose Konstrukte lernen um einfachste> Zusammenhänge erstmal zu sehen.
Hm, deine sinnlosen Konstrukte bilden die Grundlage jeglicher
Algorithmik. Was sollte man denn anstelle dieser besser lehren? Wie man
Klicki-Bunti-Spiele programmiert?
Ich muss dann unweigerlich an Klippert-Training denken... da dachte man
auch, das würde die Lernmethodik seit je her revolutionieren.
Das führt dann zu den 80% Abbrecherquote der Informatikstudiengänge:
Script-Kiddies, die ein bisschen HTML, Java, CSS können und glauben,
damit programmieren zu können. Script-Kiddies, die dann auf die Schnauze
fallen, wenn sie ein Semester lang Lineare Algebra pauken müssen.
Lineare Algebra dürfte so ziemlich das unanschaulichste Gebiet der
Mathematik überhaupt sein...
Man muss halt unterscheiden, ob man den Schülern etwas über Informatik
beibringen kann und will, oder nur schnell irgendwelche Ergebnisse
erzielen möchte. Informatik besteht halt zum größten Teil nicht aus
bunten Bildchen und schnellen 3D-Animationen, sondern aus Algorithmen
und Datenstrukturen.
Entweder man macht Informatik und vermittelt die Grundlagen davon, oder
man macht eine Spielecke auf und schwimmt irgendwo an der Oberfläche
herum.
Und ja, wenn Interesse da ist (und das ist durchaus hinzukriegen, wenn
man obiges gescheit vermittelt), lassen sich diese sinnlosen Konstrukte
in ein paar Unterrichtsstunden abhandeln.
Es steckt mehr hinter Informatik, als ein paar blöde Ballerspielchen
zusammenzuklicken. Zur Informatik gehört systematisches und generisches
Denken, das kann man auch an anderen Stellen immer wieder gebrauchen.
Und kein Lehrer bringt seinen Schülern bei, den automatischen Quelltext
der IDE zu verunstalten. Braucht er auch garnicht, es passiert einfach.
Schüler sind neugierig (sollten neugierig sein) und sollten erforschen
und probieren, was auch wichtig ist. Da ist aber eine IDE (etwa die
Delphi-IDE) nur hinderlich, bei der man viel zu viel Vorwissen braucht,
um ein zerschossenes Projekt wieder mit der IDE verträglich zu machen.
Been there, done that. Sowohl als Schüler als auch als Lehrer.
> Falls ihr es gemerkt habt, eure Debatte über all die vielen> Programmiersprachen deren flacher Speicher enlose Verkettung von> Pointern erzeugt hat den Threadersteller mittlerweile Wortlos gemacht> und ihr diskutiert mittlerweile eure Votrlieben aus, ohne auf den> Hintergrund zu achten.
Genau so ist das.
Deswegen schrieb ich auch:
Ein Pointer ist eine Variable die auf einen Speicherbereich zeigt. Das
ist alles, mehr braucht man dazu nicht zu sagen.
darauf hin schrieb Oliver B. (ickbineeenberliner)
> Dazu kann man sagen, daß wenn man den Pointer dereferenziert,> das Programm in nicht-definierte Zustände kommen kann,> weil man z.B. einen ungültigen Pointer hat und auf nicht erlaubten> Speicherbereich zugreift, oder einen NULL-Pointer dereferenziert.
Oliver, du beschreibst was man mit einem POINTER = ZEIGER machen kann,
aber nicht was er oder es ist. Was man damit machen kann, darüber kann
man sich lange auslassen.
Und dann kam der schlaue Sven P. (haku) mit seiner Dedinition über
Zeiger
> Ein Zeiger zeigt auf ein Objekt.
Wamit er eine Erklärung mit einem neuen zu erklärenden Begriff abzugeben
versuchte, was gleich völlig zur Verwirrung führt, weil das nämlich die
nächste Debatte eröffnet: Was ist ein Objekt?
Also auch diese Erklärung ist untauglich.
Dann hat es dem yalu (Gast) dessen Postings ich schätze gereicht und er
kam mit seiner Definition, zuerst aber seine Kritik:
> Das ist genau der Typ von Definition, der das Lernen von Programmier-> sprachen manchmal so schwer macht ;-)> Die andere, nicht selbstreferenzierende "Definition": Ein Zeiger bedarf> keiner Definition, er ist einfach da.> Beide Varianten findet man in ähnlicher Form tatsächlich in Lehrbüchern.> Ich frage mich nur, was das soll.
Richtig! Das frage ich mich auch. Aber nun zu yalu's Versuch einer
Definition:
> Irgendwann fiel es mir wie Schuppen> von den Augen: Diese obskuren Zeiger sind ja nichts anderes als die> Speicheradressen der Daten, auf die sie zeigen.
Ja, that's it. Damit erkläre ich mich sofort solidarisch. Yalu, you made
my day!
"Zeiger sind ja nichts anderes als die
Speicheradressen der Daten, auf die sie zeigen."
Meine Definition war
Ein Pointer ist eine Variable die auf einen Speicherbereich zeigt.
Und damit Sven P. (haku) mir jetzt nicht auf's Dach steigt gilt
natürlich auch folgendes:
Selbstverständlich kann sich an der Speicheradresse auf die der Zeiger
zeigt auch statt einer einfachen Variablen (so würde man den Zeiger im
Lehrbuch beginnen zu erklären) eine ganze Struktur befinden, oder ein
komplizierteres Konstrukt wie ein Objekt. Auch kann der Zeiger auf eine
Funktion zeigen oder sonst irgend ein Gebilde. Der Speicherbereich auf
den der Zeiger deutet muss auch gar nicht im RAM liegen, sondern kann
auch unveränderbar im ROM liegen usw. Man kann auch viel mit dem Pointer
= Zeiger machen. Man kann ihn inkrementieren (also seine Adresse
erhöhen), dekrementieren (die Adresse erniedrigen), man kann richtige
Rechenspielchen mit dem Zeiger veranstalten und ihm auch falls es Sinn
macht in beliebige (hoffentlich dann passende ;)) Typen umwandeln (per
type casting je nach Programmiersprache zulässig oder auch nicht). All
das (und noch mehr) kann man mit dem Zeiger machen, aber der Zeiger
bleibt letzlich immer eine 'Speicheradresse die auf einen
Speicherbereich zeigt', egal wie man die Daten auf die er zeigt
interpretiert.
Und wenn jetzt auch noch Andreas Schwarz dem hier Geschriebenen
zustimmen kann, dann leben wir alle glücklich und zufrieden mit unseren
mehr oder weniger ausgeprägten Programmierfähigkeiten (meine sind gerade
mal wieder ein wenig eingerostet) und erfreuen uns an einem Stückchen
funktionierenden Programmcodes wenn es denn funktioniert oder wundern
uns darüber, wenn es bei der Ausführung zur unvorhergesehenen Ausnahme,
dem Programmausnahmefehler (der sog. exception) kommt.
:)
@ Oliver B.:
disqualifizierst du dich immer selber oder machen das auch mal andere
für dich ? :-)
@ arc net:
nur weils so lustig ist: du kannst mir sichen den großartigen vorteil
von sips erklären, oder? für alle anderen, m$ sieht ie revolution das so
- und nein, es gibt darauf (noch) kein trivialpatent:
"SIPs differ from conventional operating system processes in other
ways. They cannot share writable memory with other SIPs; the
code within a SIP is sealed at execution time; and SIPs are
isolated by software verification, not hardware protection."
> Woher soll der Hersteller wissen, wie lang deine Interruptroutine braucht?> Thread- und JVM-Wechsel werden über interne Hardwaretimer realisiert...
ja, aber ohne die angabe wie lange die contextwechsel der VM dauern ist
das humbug. wenn da steht - zitat :
"Microprogrammed Real-Time Operating System (RTOS) kernel provides
microsecond response to interrupts / context switches and direct
implementation of Java threading primitives"
dann heißt das, dass der interrupthandler der vm n microsekunden zur
reaktion auf einen interrupt braucht. das ist weder besonders toll noch
trifft das irgedeine aussage darüber wann der contextwechsel vollzogen
ist.
ach ja, meine shift-taste ist defekt ;-)
Ja, da kann ich mich anschließen.
Wobei ich noch zwei Nachträge zum Verständnis hätte:
(1)
Ein 'Objekt' (in C, laut K&R) ist etwas, das Speicher belegt, das hat
nichts mit OOP zu tun. Auch ein int ist ein Objekt. Wurde aber bereits
gesagt.
(2)
Ein Zeiger zeigt auf ein Objekt :-)
Das schließt ein, dass er nicht auf eine Funktion zeigt. In C ist es
nicht erlaubt, zwischen Zeigern und Funktionszeigern zu konvertieren.
Beispielsweise ist folgendes verboten:
1
void*(funktionszeiger)(void);
2
void*zeiger;
3
4
funktionszeiger=zeiger;
U.a. führt das zu Problemen, etwa mit dlopen(). dlopen gibt einen Zeiger
auf eine Funktion einer Bibliothek (als void *) zurück; blöderweise muss
man den in einen Funktionszeiger umwandeln, was aber eben nicht erlaubt
ist.
An diesem Problem forscht eine Arbeitsgruppe der Openstd schon eine
ganze Weile :-]
Wieder ein Grund, warum Zeiger nicht (zwangsläufig) auf Adressen im
physikalischen Speicher zeigen...
> Welche Programmiersprache für Schüler?
Plankalkül und nix anderes - oder soll die nächste Generation zu
Warmduschern und Vorwärtseinparkern erzogen werden?
Beispiel (von Wikidingsda gemopst):
P1 max3 (V0[:8.0],V1[:8.0],V2[:8.0]) => R0[:8.0]
max(V0[:8.0],V1[:8.0]) => Z1[:8.0]
max(Z1[:8.0],V2[:8.0]) => R0[:8.0]
END
P2 max (V0[:8.0],V1[:8.0]) => R0[:8.0]
V0[:8.0] => Z1[:8.0]
(Z1[:8.0] < V1[:8.0]) -> V1[:8.0] => Z1[:8.0]
Z1[:8.0] => R0[:8.0]
END
zwieblum schrieb:
> @ Oliver B.:>> disqualifizierst du dich immer selber oder machen das auch mal andere> für dich ? :-)>>> @ arc net:>> nur weils so lustig ist: du kannst mir sichen den großartigen vorteil> von sips erklären, oder? für alle anderen, m$ sieht ie revolution das so> - und nein, es gibt darauf (noch) kein trivialpatent:>> "SIPs differ from conventional operating system processes in other> ways. They cannot share writable memory with other SIPs; the> code within a SIP is sealed at execution time; and SIPs are> isolated by software verification, not hardware protection."
Was bedeutet wohl: "isolated by software verification"?
Richtig, die Fehler, die sonst so auftreten können, werden durch
vorherige Verifikation ausgeschlossen (Singularity läßt auch das
"normale" Vorgehen zu, falls man's braucht).
Das das nicht mit "normalen" Sprachen, wie C, geht, dürfte auch bekannt
sein.
Welche Vorteile hat das nun?
U.a. müssen keine illegalen Speicherzugriffe abgefangen werden,
es müssen keine MMU-Tabellen verändert werden, keine TLB-Flushs,
es braucht keine Call-Gates (früher harte Interrupts mit allem was dazu
gehört, heute die etwas schnelleren sysenter/syscall-Befehle), weniger
Overhead bei der Interprozesskommunikation, u.a. weniger bzw. keine
Parameterüberprüfungen etc. pp.
>> Woher soll der Hersteller wissen, wie lang deine Interruptroutine braucht?>> Thread- und JVM-Wechsel werden über interne Hardwaretimer realisiert...>> ja, aber ohne die angabe wie lange die contextwechsel der VM dauern ist> das humbug. wenn da steht - zitat :>> "Microprogrammed Real-Time Operating System (RTOS) kernel provides> microsecond response to interrupts / context switches and direct> implementation of Java threading primitives">> dann heißt das, dass der interrupthandler der vm n microsekunden zur> reaktion auf einen interrupt braucht. das ist weder besonders toll noch> trifft das irgedeine aussage darüber wann der contextwechsel vollzogen> ist.
Kontextwechsel innerhalb von 1 us, Stichworte: stackbasierter Bytecode
vs. Registerarchitektur, MMU, etc. einfach mal ins Datenblatt schauen
und selber testen...
@Arc Net (arc):
Die ganze Magie reduziert sich auf automatisches Beweisen der
Korrektheit eines Programmes. Dass das nicht geht dürfte bekannt sein.
Die Sprache, die verwendet wird, ist dabei irrelevant, sofern sie
Turing-complete ist.
Das Ding von Ajile ist ein Java-Prozessor, nicht mehr nicht weniger. Ich
weiß nicht wo du ein Datenblatt mit Timings gefunden hast, auf der
Hompage des Herstellers habe ich jedenfalls keines gefunden. Jedenfalls
verhindert der nicht, dass dein Code Mist baut.
Thread beobachten
Seitenaufteilung abschalten