Holger Klabunde schrieb:
in Programm mit Absturzgarantie
ibt schreiben.
Hallo,
die Gef=E4hrlichkeiten eines Pointers scheinen Dir nicht klar zu sein. In Sprachen die keinen Pointer haben und alle Feldgrenzen auf Einhaltung =
=FCberpr=FCfen kann man nicht einen Absturz provozieren indem man an eine= r=20 Adresse schreibt wo man nichts verloren hat.
Bye
Bernd Maier schrieb im Beitrag ...
Ich liebe diese Buecher.
Schon frueher kam mir der Inhalt immer etwas unpraktikabel vor. Und vor allem so gaenzlich aus dem Nichts gesaugt.
War ja auch kein Wunder, da die Autoren meistens noch gar kein grosses, kommerziell erfolgreiches Produkt geschrieben hatten, sondern nach ihrem ersten gescheiterten Kleinprojekt gleich der Meinung waren, ihre Unkenntnis in ein Buch schreiben zu muessen.
Die haben ihre Theorie nur aus Univorlesungen gesaugt. Die von Theoretikern gehalten wurden, die ihrerseits noch nie ein echtes Programm geschrieben hatten.
Wie erhellend war es, als man im Internet endlich mal die originalen Sourcen von wirklichen zu ihrer Zeit kommerziell herausragend erfolgreichen Programmen, wie CP/M, GEM oder **** finden konnte.
Strafen diese source codes doch all den Software Engineering Buechern Luegen. Und zeigt das doch, das man nicht alles glauben sollte, was irgendwelche Deppen zu Papier bringen.
-- Manfred Winterhoff, reply-to invalid, use mawin at despammed.com homepage: http://www.geocities.com/mwinterhoff/ de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/ Read 'Art of Electronics' Horowitz/Hill before you ask. Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
|> Es ist schwer mit Pascal, Basic oder Fortran einen harten Crah zu |> povozieren, in Java so gut wie unmöglich. Mit C passiert sowas regelmäßig |> aus Versehen.
Habe ich da gerade Java gehört? Write once, crash everywhere... Die meisten Darstellungsprobleme und Crashes habe ich bislang mit Java gehabt, auch bei SW, die das passende JRE (zB. für Solaris) gleich mitliefert. Es ist dabei egal, ob das Konzept selbst sowas nicht zulässt, aber wenn man zum Ausführen von Hello-World allein schon über 50 Klassen und mehrere MB Sourcecode braucht, MÜSSEN da einfach mehr Fehler drin sein. Es fängt bei ClassNotFound an (brauche ich jetzt zum Glücklichwerden 1.1.18, 1.2, 1.3 oder 1.4?) und geht bis zu NullPointerExceptions. Diverse Programme laufen nur mit dem 1.2er JIT (sunwjit) und nicht mit HotSpot, andere haben Probleme mit dem Redraw und den Fonts.
Ne, also wenn ich was plattformunabhängiges will, nehme ich Perl :-)
--
Georg Acher, acher@in.tum.de
http://wwwbode.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
"MaWin" schrieb:
Ja, genau. Und weil es mehr Arbeit macht und mehr kostet verzichten viele darauf und gehen zum "Cowboy Coding" über. Und wenn sie damit die Klappe fallen, müssen sie weinen.
Wer solche Bücher kauft ist doch selbst Schuld.
Einige erfolgreiche Projekte, die ohne SE-Techniken ausgekommen sind, widerlegen doch nicht alle SE-Konzepte. Übrigens stammen die meisten dieser Konzepte durchaus aus der Praxis. Das sind z.T. so triviale Dinge wie Cross-Inspection, die die Qualität aber ungemein steigern. Sowas wird z.B. am Linux-Kernel mit Erfolg praktiziert.
MfG, Bernd
"Georg Acher" schrieb:
[...]Nee, mit "hartem Crash" meine ich Fehler, die dein OS instabil machen. Klassischerweise also zum Anhalten bringen, Kernel Panic oder BSODs auslösen.
Sowas ist in Java wegen der Garbage Collection und mit der Sandbox nur schwer hinzubekommen. Konzepte wie Pointer in C erleichtern dieses aber ungemein.
MfG, Bernd
|> Nee, mit "hartem Crash" meine ich Fehler, die dein OS instabil machen. |> Klassischerweise also zum Anhalten bringen, Kernel Panic oder BSODs |> auslösen.
Sowas ist aber auch unter C (im Userspace) recht schwer zu schaffen.
|> Sowas ist in Java wegen der Garbage Collection und mit der Sandbox nur |> schwer hinzubekommen. Konzepte wie Pointer in C erleichtern dieses aber |> ungemein.
Naja, mit Java geht's deswegen nicht, weil es kaum ein Betriebssystem gibt, das in Java geschrieben ist... Und die wenigen Versuche, die tatsächlich existieren, brauchen dann leider auch wieder Erweiterungsbefehle in der JVM, um Pointer nachzumachen. Irgendwann muss man mit der Hardware reden, und die versteht keine Referenzen und Konstantenpools.
--
Georg Acher, acher@in.tum.de
http://wwwbode.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Mit einem richtigen OS passiert sowas gar nicht. Schlimmstenfalls crasht das Programm, aber nicht das Betriebssystem. Das ist deswegen so, weil richtige Betriebssysteme die Programme auch in eine Art Sandbox sperren.
Stimmt. Ganze Klassen von Fehlern schließt Java per Design aus. Allerdings sind die Designer IMHO an manchen Stellen zu weit gegangen. Ohne Flinte kann man sich zwar nicht mehr in den Fuß schießen, man kann aber auch nichts anderes mehr erlegen.
Speziell im Embedded-Bereich (wo der Thread ja angefangen hat) ist natürlich der Bloat von Java allein schon ein Ausschlußkriterium.
XL
-- Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition, die anderen sind einfach von sich aus unlogisch. -- Anselm Lingnau
"Axel Schwenke" schrieb:
Ja, stimmt. Obwohl Maxim ja seit längerem versucht, (Pseudo-)Java in Embedded-Systemen zu etablieren. Und für PICs hab ich auch schon irgendwas javaartiges gelesen...
MfG, Bernd
doch natürlich. Deshalb gehe ich damit ja auch sehr vorsichtig um.
Eine Division durch 0 ist auch gefährlich. Sollte man deshalb Compiler meiden mit denen man dividieren kann ? Es ist auch gefährlich wenn man statt PORTB PORTA tippt. Das provoziert ja geradezu einen Programmfehler bei dem der Compiler nicht meckert. Irgendwie muß man beim programmieren eben seinen Verstand benutzen. Einen Compiler der rät was man eigentlich programmieren wollte gibt es leider nicht.
Pointer gibts nicht nur in C: Pascal adr:=$0800; {Beginn bei RAM Adresse 0x0800 } geht bei NiliPascal jedenfalls Basic peek und poke glaube ich schon mal gesehen zu haben
Ein Pointer gerät doch nicht von alleine außer Kontrolle. Irgenwer muß ihm ja gesagt haben er soll weiterzählen und in Adressen schreiben. Wenn man nicht aufpasst wohin der Pointer zeigt (z.B. gar nichts reinschreibt ) dann ist das für mich ein NORMALER Programmierfehler wie eine Formel falsch einzutippen.
Wer Pointer nicht mag oder nicht versteht muß sie ja nicht benutzen.
Holger
-- Dipl. Ing. (FH) Holger Klabunde http://home.t-online.de/home/holger.klabunde/homepage.htm
Bernd Maier schrieb im Beitrag ...
Zeig mir mal deine grossen, kommerziell erfolgreichen Programme, oder schwaetzt du bloss ? homepage:
Es soll sogar Programme geben, die TROTZ Verwendung von SE-Methoden lauffaehig waren.
-- Manfred Winterhoff, reply-to invalid, use mawin at despammed.com de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/ Read 'Art of Electronics' Horowitz/Hill before you ask. Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
Bei uns an der Uni gibts sogar ein Seminar (oder Praktikum?!) was sich "Java für eingebettete Systeme" nennt ... *schauder*
-- Laurent
"MaWin" schrieb:
Nur gegen NDA ;)
Aber schau dir doch mal z.B. die Produkte von SAP an. Glaubst du wirklich, dass man dort auf Dinge wie Code Reviews, Prototyping, Anforderungsanalysen oder konzeptionelle UML-Entwürfe verzichten kann? (und jetzt komm mir biite nicht mit SAP ist aber sch**sse...) Oder schau dir eine Bank an: glaubst du, dass die irgendwelche Programme ohne genaue Analyse auf die Produktivdaten loslassen? (jaja, die Banken sind auch alle... ;)
lauffaehig waren.
Vielleicht reden wir nur aneinander vorbei, aber SE ist nicht besonders esoterisch oder ideologisch geprägt... Das sind zum größten Teil Basistechnologien: Selbst wenn du dir ein doofes Flussdiagramm oder einen Ablaufplan aufmalst betreibst du schon SE.
MfG, Bernd
"Laurent Schmalen" schrieb:
Aber bitte sofort den Link her! ;) Gibts nen Skript davon zum downloaden?
MfG, Bernd
Bernd Maier schrieb im Beitrag ...
Kein Problem, schick her.
Danke, die kenne ich. Inside-out. Die finde sogar ich uebel. Ohne das ich nun auf Befolgung von SE-Techniken besonderen Wert legen wuerde.
Doch, schon, das ist ja das Problem.
Kindergartenhorizont.
Wie gross meinst du ist das Flussdiagramm eines ordentlichen kommerziellen Programms ? So gross wie ein Fussballfeld ? Welchen Ueberblick gewinne ich, wenn mir jemand ein vollgekritzeltes Fussballfeld ausrollt ?
-- Manfred Winterhoff, reply-to invalid, use mawin at despammed.com homepage: http://www.geocities.com/mwinterhoff/ de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/ Read 'Art of Electronics' Horowitz/Hill before you ask. Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
MaWin schrieb:
Du bist also der Meinung man sollte eine großes System (z.B. eine Trägerrakte) ohne jegliche Pläne entwickeln? Einfach den Mechaniker an die Fräßmaschine stellen und sagen: "Fräß mal eine Triebwerksglocke" Bekommt er vielleicht auch hin. Aber wird diese Glocke auch noch bei den üblichen Verbrennungstemperaturen stabil sein?
Man braucht Pläne um große Systeme zu erstellen. Niemand sagt das man beim System-Entwurf einer Trägerrakete die Farbe der Tankisolierung definieren muß. Es sollte aber im Hinblick auf die Anwendung geplant werden ob es sich um ein ein- oder mehrstufiges Konzept mit Flüßig- oder Feststoffantrieb wird.
SE ist nichts anderes als Pläne zu erstellen wie man ein Produkt anschließend fertigt. In der Mechanik macht man das seit Jahrhunderten. Und in der Software soll dieses Vorgehen sinnlos sein?
-- Matthias Weißer matthias@matwei.de http://www.matwei.de
"MaWin" schrieb:
Ok, wenn hier meine Zitate schon verändert werden, sollten wir die Diskussion einfach beenden.
nun
Jaja, und deshalb macht SAP auch gute Geschäfte und hat einen recht hohen Marktanteil. Ohja, ich weiss, jetzt kommt dein Argument, dass die Beschaffung nur von Bekloppten und BWLern ohne Ahnung gemacht wird usw. usw...
Ja. Das Problem dieser Konversation.
aufmalst
Soo, auf eine böse Bemerkung verzichte ich hier einfach. :)
ich,
Ja, stimmt, du hast Recht, jetzt sehe ich es auch.
Wollen wir uns nun wieder emotional neutralen Themen zuwenden? Wie wäre es mit "Weller vs. Ersa"? ;)
Gute Nacht, Bernd
Die weitaus meisten Softwareprojekte haben nur einen winzigen Bruchteil des Etats und der Entwicklungszeit im Vergleich zu einem Raumfahrtprojekt. Du vergleichst Äpfel mit Birnen.
Btw.: Bei den Mondlande-Programmen der Amis und Russen ist so manches wild zusammengeschustert worden, nach Plänen, die höchstens in den Köpfen von einer Handvoll Genies existierten. Deshalb kann man diese Trägersysteme heute auch nicht mehr nachbauen, selbst wenn man wollte.
Nicht zwingend.
Gerade bei *wirklich* umfangreichen Systemen, die man nicht mehr als Ganzes überschauen kann und bei denen die Projektleitung gar nicht weiß, ob sie überhaupt in die richtige Richtung denkt, sind konkrete Pläne sogar eher schädlich. Denn sie schränken die Kreaktivität der Spezialisten massiv ein, und verhindern damit zweckmäßige Lösungen.
Wenn die Raketenentwicklung mit dem Ziel begonnen hätte, das Sonnensystem zu erforschen, hätte vermutlich nie ein Mensch diesen Planeten verlassen.
Wenn die Elektronik mit dem Ziel begonnen hätte, eine Maschine zu konstruieren, die sich gleichermaßen als Schreibmaschine, als Archiv, als Analysewerkzeug, als Kommunikationsmittel, und zur Unterhaltung eignet und auf einen Schreibtisch paßt, hätten wir wohl heute keine Computer.
Einfach weil beides aus damaliger Sicht nicht greifbar und damit nicht planbar war.
bottom-up (also das Entwickeln und Kombinieren von Bausteinen mit einem nicht oder nur vage formulierten Endziel) ist eine durchaus anerkannte Entwicklungsphilosophie, die zwar nicht immer exakt zu dem Ergebnis führt, was man anfangs im Sinn hatte, aber doch meist zu etwas, das irgendwie nützlich und verkäuflich ist. Oft sogar weit mehr, als die anfängliche Idee.
In dem Umfang, wie es in der Mechanik üblich ist, wäre SE weder bezahlbar, noch in vertretbarem zeitlichem Rahmen machbar, noch sinnvoll.
Anders als bei mechanischen Produkten ist es bei Software nicht erforderlich, der Fertigungsweg jederzeit mit identischem Ergebnis nachvollziehen zu können.
Und ebenfalls anders als bei mechanischen Produkten steht bei Software meist nicht ein klar umrissenes Ziel am Beginn der Planungen, sondern ein Problem, dessen Lösung oft noch gar nicht bekannt ist.
Hergen
-- Laurent
Hergen Lehmann schrieb:
Dafür funktionieren sie fast durchgehend nach der 90-90-Regel: die ersten 90 % der projektierten Zeit werden für die ersten 90 % des Projektes benötigt, während die restlichen 10 % des Projektes die zweiten 90 % der Zeit brauchen.
-- Jörg Wunsch "Verwende Perl. Shell will man können, dann aber nicht verwenden." Kristian Köhntopp, de.comp.os.unix.misc
mit Absturzgarantie
schreiben.
überprüfen kann man nicht einen Absturz provozieren indem man an einerAber Hallo,
was denkst Du macht eine Portausgabe unter Pascal?
Die schreibt z.B. 0x08 auf 0x378. Was denkst Du, was 0x378 in diesem Falle ist? Richtig, ein Pointer auf eine IO Adresse im (IO) Adreßraum des Prozessors.
Ein Pointer ist also böhhse.
Mit einer Sprache, die das nicht ermöglicht, möchte ich nicht programmieren, denn der Bildschirm wird wohl dunkel bleiben, wenn man das OS damit schreibt. Oder ist C als darunter liegende Sprache für das Betriebssystem und die Laufzeitbibliotheken plötzlich gut genug? Dazu war C mit seinen Pointern mal gedacht, um hardwarenah und schnell programmieren zu können, dazu braucht man Pointer auf Adressen. Alternativ kannst Du in Assembler programmieren, das ist noch hardwarenäher und noch schneller und noch fehlerträchtiger und noch pointriger...
Holm
-- L&P::Kommunikation GbR Holm Tiffe * Administration, Development FreibergNet.de Internet Systems phone +49 3731 41930 Bereich Server & Technik fax +49 3731 4196026 D-09599 Freiberg * Nonnengasse 31a http://www.freibergnet.de
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.