Textauszug Stefan aus nem anderen Posting: >Zu den C++-Kenntnissen möchte ich auch nochmal was los werden. >C++ wird immer wieder in den Stellenanzeigen verlangt. Ich kann von mir >nicht behaupten, daß ich gut in C++ bin, trotz 2 Jahren Berufserfahrung mit >dieser Sprache. Das was Du im Studium mit C++ hattest, ist leider >nichtmal ein Bruchteil dessen, was C++ ausmacht. C++ ist leider ein >Minenfeld, in das man sich nicht reintrauen sollte. In den >Bewerbungsgesprächen, an denen ich auf der einstellenden Seite dabei >war, brauchte ich nur 3 Fragen stellen. Keiner derjenigen, die gute bis >sehr gute C++-Kenntnisse hatten, konnte die Fragen 100% richtig >beantworten. Leider sind dies die 3 wichtigsten Fallen, in die man bei >der Programmierung immer wieder hineintappt. Minenfeld ist richtig bezeichnet, denn sie wissen nicht was sie tun..... Deswegen sagte ich ja auch, das C++ nur nen hype ist von dem die Persolanwichser erst recht nix verstehen, aber von den Leuten Wunder abverlangen.......aber ist euch eigendlich nicht schonmal der Gedanke gekommen, das die solche Horrorannoncen schreiben weil sie selber nicht all zu kompetente Leute habenderen Schwächen ihr mittels überzogenen Forderungen in Stellenannoncen wett machen sollt ??? Nun zum Auto: Letztes Jahr Sommernacht ich zufuß, komme an Tanke vorbei wollte Kippen holen. Komm wieder raus, da ist der Fahrer eines nagelneuen Peugots schätze mal er war so ende 30 immer noch mit der Karre am hampeln. Was war passiert ? Nun, der holde Herr war stolzer Besitzer eines Familien-PKW der sowas wie diese seitlich aufspringenden Türen hat. Problem dabei: Er hatte den Motor schon an und die Türen gingen auf zu auf zu usw. Das dauerte so um 10 Minuten bis die Türen endgültig dicht waren und der Flattermann zu ende............das dürfte nen Softwarefehler gewesen sein oder insbesondere die POWER OF C++........:-) Aber mal Scherz beiseite: Der Trick der dahinter steckt ist natürlich wieder Marke BWLer: E-Ingenieuren bringt man nicht umsonst C++ oder besser wäre nur C bei. Ziel hinter der Aktion ist ganz klar die Informatiker auszubooten. Das ist keinerlei Kritik an euch, denn ihr selber werdet auch nur benutzt, aber wenn ich mir das so überlege mit dieser sog. Standart-Template-Libary, die übrigens garnicht sooo standardisiert ist, wie es sich eigendlich gehört, kommt mir das verdächtig vor. Diese Bibliothek angepriesen für sich scheinbar wiederholende Routinearbeiten ist eigendlich nix anderes als ne art Maggi-Fix-Tüte für Leute die eben eine nicht so starke algorithmische ausbildung haben, aber dennoch kompilzierte Algorithmen für ihre Projekte brauchen. Was ist es da einfacher die Arbeit personalkostensparend von einem Elektro-Ing via STL- "Maggi-Tüte" mitmachen zu lassen und dafür den Informatiker raus zu werfen....so ist das etwa von diesen Personalwichsern im Kern angedacht......... Man kann sich das etwa so vorstellen, als wenn der Informatiker meinetwegen eine numerische Routine entwickelt und dann wenn sie fertig ist geschossen wird, weil der klimpernde Bäckermeister alla CDI (weil billiger) diese nur in seinem einfachen Programm aufrufen muss ohne zu wissen, was da eigendlich im inneren passiert und wo was schief gehen könnte. In dem Sinne kann man das bei der STL auch sehen. Die folge davon ist aufgeblaserner Speicher und nur scheinbare Fehlersicherheit. Wer mir das nicht abnimmt auch hier ein Beweis: Scott Meyers - Systematisches Testen von Programmen. Im Buch zeigt der Autor eindrucksvoll das eine billige If-Sequenz unter einer For-Schleife bis zu 100 Millionen Fehler auftreten lassen kann. So gefährlich das sogar ich die Luft angehalten habe, denn das was ich sah hätte ich nicht für möglich gehalten! Deswegen gibt es mittlerweile auch bei uns solche Fächer wie "Software-Qualitätssicherung" und ihr solltet das nicht unterschätzen, das tat ich seinerzeit auch, bis unsere Dozentin Frau Dr. Balzert FH-Do und mal so beiläufig sagte, das laut bekanntwerden von fällen in Amiland dortige Programmierer im Knast gelandet sind, wenn Unfälle passiert sind die auf Softwarefehler zurück gingen und Leute verletzt oder gar getötet wurden! Ich erinnere mal an das Zugunglück von Enschede 101 Tote !!! Kein Softwarefehler sondern die Bahn hat gegen den Rat und Willen der Betriebsingenieure wegen ner Macke an den Rädern trotzdem Speed fahren lassen. 3x lass ich euch raten wer da im Knast gelandet ist, jedenfalls nicht jene die das befohlen haben, sondern ein ganze latte Ing's die das wieder Willen erduldet haben! Weiteres Beispiel vorgezogenes Sylvesterfeuerwerk auf Steuerzahlerskosten! Die Rede ist von ARIANE 5 in franz. Kourou..........da haben sich die Herren Verfechter der so bezeichneten Widerverwendbarkeit in der Objektorientierten Programmierung aber kräftigst in den Arsch gebissen, als man versucht hat die komplette Software der ARIANE 4 direkt 1:1 auf die A5 zu übertragen und nur ein handvoll Flugparameter zu ändern. Das ergebnis war Affengeil !!!! Mitten über dem Dschungel in ein paar Km Höhe flog das Ding auseinander einfach ein geiler Anblick.....Sateliten im Arsch, Kohle im Arsch und weinende Ingeneurchen die auf den Leim der objektorientierten Wiederverwendbarkeit gegangen sind und nun jaulten, das sie auf Steuerkosten keine geilen Latinas mehr ficken durfen......ja HOLA.......tolle Wiederverwendbarkeit! Da sind ja selbst die Strandnutten noch zuverlässiger.......:-) http://de.wikipedia.org/wiki/Kourou Hier der Unfallbericht in den ersten beiden zeilen steht es: http://www2.informatik.uni-jena.de/~nez/rechnerarithmetik/Ariane/fallstudie_ariane_501.pdf#search=%22ariane%205%20rakete%20explodiert%22 Theo
Geh doch bitte mal in Behandlung, bloss weil du nicht schlafen kannst, musst du uns doch nicht solche Beiträge vorsetzen?!
@Theo, können wir uns darauf einigen, dass du deine länglich formulierten Postings mit etwas gewählterem Wortschatz (vulgär) und weniger breit gestreut hier abgibst? Und bitte nicht mehrere Threads für das gleiche Thema aufmachen. Es will dir ja keiner das Wort verbieten, aber mit deinen pauschalen Rundumschlägen - das ist ja fast nicht zum Aushalten, obwohl du das alles bestimmt sehr ernst meinst (davon bin ich überzeugt). Durch deine Meinungen weckst du in vielen (naja zumindest mir :-) den karitativen Instinkt, dir helfen zu wollen. Aber durch die Penetranz überwiegt langsam mehr die Einschätzung, dass du ein Troll bist, den man ignorieren muss. Was meinst du dazu? (Bin bespannt, ob ne vernünftige Antwort oder Beleidigungen und Unterstellungen oder Ignoranz kommt). ----, (QuadDash).
E-Techniker und Software-Engineering. Zwei Welten prallen aufeinander. Bisher habe ich noch alles weggeworfen, was E-techniker verbrochen haben. Das sind solche Dilettanten. Die können es einfach nicht. Außer unwartbaren Code hinhacken bringen sie einfach nichts auf die Reihe. Da sind solche Dilettanten!!!!!!! Die sollen an ihrem Lötkolben bleiben!!!!
DA MÜSSEN FACHLEUTE RAN UND KEINE AHNUNGSLOSEN E-TECHNIKER!!!!!
Hallo das ist doch schon wieder so eine oberflächliche Diskussion. E-Techniker (ich bin auch einer, deshalb fühle ich mich hier beleidigt) können genauso-gut programmieren wie Softis (so, das wärs mal) Das Problem der Qualität bei Programmierung liegt doch wo anders: Die Automobil-Industrie lagert gnadenlos aus. In der Umgebung von automobilherstellern schiessen die 3.-Lieferanten aus dem Boden wie Pilze. Da werden dann mal schnell ein paar Leute von der Strasse" eingestellt, die Lösungen für ein Fahrzeug designen - möglichst billig und möglichst schnell - alles im Rahmen zur Kostenersparnis. In militärischen Bereichn ist das übrigens genauso. So hat die EADS nach der Entwicklung des Tornado zwecks kostenersparnis die ganzen Profis in rente geschickt und zur Entwicklung des Jäger90/Eurofighters wieder neue Leute eingestellt. Das resultat kennt man. Gerhard
> C++ ist leider ein Minenfeld, in das man sich nicht reintrauen > sollte. Minenfeld stimmt. Nicht reintrauen: Schwachsinn. > Ich kann von mir nicht behaupten, daß ich gut in C++ bin, trotz 2 > Jahren Berufserfahrung mit dieser Sprache. Nach 2 Jahren bist du bestenfalls aus dem Anfängerstadium heraus. Die Mächtigkeit und Power die hinter C++ steckt, kann man nach so einer Zeit grade mal erahnen. > brauchte ich nur 3 Fragen stellen. Keiner derjenigen, die gute > bis sehr gute C++-Kenntnisse hatten, konnte die Fragen 100% richtig > beantworten. Leider sind dies die 3 wichtigsten Fallen, in die man > bei der Programmierung immer wieder hineintappt Das würde mich mal interessieren: Was waren die Fragen? Ich kann mir beim besten Willen nicht vorstellen, wie jemand mit 2 Jahren C++ Berufserfahrung jemanden mit sehr guten C++ Kentnissen ins Abseits stellt. Es sei denn jemand anderer hat ihm die Fragen vorgekaut oder das Gegenüber verfügt eben nicht über sehr gute Kenntnisse. Karl Heinz, der 12 Jahre C++ Industrieerfahrung auf dem Buckel hat und von den eher esoterischen C++ Ecken in der Template-Programmierung auch nach 12 Jahren eher wenig Ahnung hat :-)
Vor allem zeugt es von der Oberflächlichkeit des OP, als Beleg für die Ursache des Ariane-Absturzes eine (in PDF konvertierte) Powerpoint-Präsentation heranzuziehen. Dazu gab es übrigens auch eine Studie, dass der Grund für viele fehlerhafte Projekte in zu oberflächlichen Präsentationen zu suchen ist, wo versucht wurde, komplexe Zusammenhänge einfach darzustellen, was aber wohl öfters in die Hose geht.
>Im Buch zeigt der Autor eindrucksvoll das eine billige If-Sequenz unter >einer For-Schleife bis zu 100 Millionen Fehler auftreten lassen kann. >So >gefährlich das sogar ich die Luft angehalten habe ... Du solltest öfter solche Bücher lesen.
@Theo [ ] Du kannst C(++) [ ] Du weißt, was die STL ist [X] Du solltest weniger Maggi-Fix essen Vulgäre Ausdrücke und aufgeschnapptes Halb(?)-Wissen ersetzten keine Fakten, auch wenn du das noch so oft versuchst uns glauben zu machen
Autor: Tobi H. (Tobi) >@Theo >[ ] Du kannst C(++) >[ ] Du weißt, was die STL ist >[X] Du solltest weniger Maggi-Fix essen >Vulgäre Ausdrücke und aufgeschnapptes Halb(?)-Wissen ersetzten keine >Fakten, auch wenn du das noch so oft versuchst uns glauben zu machen Den C++ Schmarn hab ich vor nichtganz 10 Jahren mal lernen müssen, aber ich hatte wenigstens noch soviel Gripps, das ich merkte das das alles nur aufgeblasener Quark ist. Zu 2. Hab nen Büchlein über die STL und stelle fest, das die Routinen recht grob gehalten sind. Strings addieren, na ja, in BASIC ging das schon 20 Jahre früher. Maggi-Fix essen, na ja, haben nen vietnamesischen Bekannten der nen China-Imbis hat, da gibt's kein Maggi. PS: Ich würde an eurer stelle mal nen Blick auf ADA werfen! Was bei den Amis für Flugbomben gut genug ist, sollte für Tüdelüt-Handys eigendlich auch reichen! ADA hat allen Sprachen eines voraus: Eine eigene Thread-Verwaltung, mit der man im Programmkörper eigene Unterroutinen konkurrierend nach dem Round-Robinverfahren verwalten kann wie es normale (gute) Betriebssysteme auch machen. So zusagen ein "Mini-Betriebssystem" im Betriebssystem. ADA ist recht Pascal-ähnlich. Allerdings sehr sehr streng. Es gibt auch eine GUI dafür, und man kann ADA auch mit JAPI verbinden um GUI-Elemente zu haben. Theo
> Zu 2. Hab nen Büchlein über die STL und stelle fest, das die > Routinen recht grob gehalten sind. Strings addieren, na ja, in > BASIC ging das schon 20 Jahre früher. Aha. Dann schuettel doch mal aus deinem Fundus zb., eine doppelt verkettete Liste raus. Und anschliessend nimmst du das Testprogramm her und wechselst die Liste gegen ein dynamisch wachsendes Array aus. Und weil es so lustig ist möchte ich in beiden Varianten eine Sortierung rein. Ach ja. Als Füllung für beides nehmen wir mal eine Permutation von irgendwas her (kannst dir aussuchen wovon die Permutation gebildet wird). Und wenn du dann in 3 Wochen mit dieser Aufgabe fertig bist, zeig ich dir wie man das mit der STL in 10 Minuten macht. > Ich würde an eurer stelle mal nen Blick auf ADA werfen! Warst du nicht derjenige, der im Eröffnungsposting über die Ariane hergezogen ist? Nun die Ariane-Software ist in ADA geschrieben. (*) > ADA hat allen Sprachen eines voraus: > Eine eigene Thread-Verwaltung Gähn. Du solltest vorsichtiger sein, wenn du den Begriff 'alle' verwendest. Threads in einer Programmiersprache: Ein alter Hut und keineswegs neu oder exklusiv bei ADA. (*) womit ich keinesfalls ADA auf- oder abwerten möchte. Mich wunderts nur: Zuerst sich drüber lustig machen, dann als das Beste seit geschnittenem Brot anpreisen.
Ganz unrecht hat Theo nicht, auch wenn seine Sprache etwas davongallopiert. Wobei ich mich mal nicht auf die STL beziehen möchte, sondern eher auf die Sprache selber. So hat C eine grässliche Syntax, und C++ somit auch, setzt sogar noch eins drauf. Und ich meine nicht (in erster Linie) das Sonderzeichengewirr. Sondern die Typ/Datendeklarationen. Der Unterschied zwischen int (*p)[] und int *(p[]) erschliesst sich vielen nur schwer, intuitiv landet man da eher in der Falle. Überflüssigerweise ist die Systax zweideutig. Als in C die typedefs erfunden wurden, spielte das Kind am Rand vom Brunnen. Benutzerdefinierte Namen wurden zu halbgaren Schlüsselworten, normale Identifier sind sie grammatikalisch nicht mehr. C++ schubste es dann endgültig rein, die Cast/Constructor-Calls sorgten dafür, dass sich der Unterschied zwischen Deklarationen und Expressions nur noch heuristisch erschliesst: "int a;" ist Deklaration, "int (*a)[];" auch, aber was ist nun "int (a);" - Deklaration mit überflüssiger Klammer oder Cast? Auch die Klassendefinitionen sind alles andere als sauber. Constructors sind syntaktisch hässlich und die base class constructors ":" erinnern an bitfields. Ich hatte früher einiges mit Compilerbau zu tun und als mir C++ damals das erste Mal begegnete (80er, C++ war noch sehr frisch) war ich entsetzt. Warum in aller Welt musste Stroustrup ausgerechnet alle Fehler von C übernehmen? Naja, ist halt so wie die x86 Architektur: Man mag sie nicht, aber sie ist halt da. Dass C++ auf dem Unterbau C fusst, macht es auch inhaltlich riskant. C ist für normale Controller-Programme begrenzter Grösse ganz ok, genau für dieses Niveau wurde sie ja konzipiert. C++ hievt das Sprachniveau weit nach oben, grad die Mächtigkeit der STL ist ein Beispiel dafür. Der alte lowlevel Kram ist freilich noch da, und verleitet dazu, benutzt zu werden. Das Ergebnis ist dann u.U. eine wüste Mischung aus high- und lowlevel-Programmierung ohne dass dies sofort ersichtlich ist.
C++ ist kein Problem und auch keine hässliche Sprache. Das Problem sind die Horden die der Meinung sind, nur weil sie ein "Hallo Welt" in C++ schreiben können, C++ zu beherschen. C++ ist eben das Latein unter den Programmiersprachen. Kein Mensch käme auf die Idee, nur weil er ein paar Fetzen Latein auswendig kann, zu behaupten, er würde Latein beherschen. Doch die Meisten die ein "class A {...};" können, sind der Meinung sie würden C++ beherschen. Wer mit Latein und C++ nicht zurecht kommt, der sollte eben bei Esperanto und Basic bleiben.
Wärend Latein über hunderte von Jahren die Hochsprache Europas war, hatte C in der Anfangszeit eher plebejischen Charakter und wurde von der Hochkultur eher naserümpfend betrachtet. ;-) Die Hässlichkeit bezog ich übrigens nicht auf den optischen Eindruck, sondern auf die formale Seite, die Grammatik der Sprache.
@Theo:
> Dozentin Frau Dr. Balzert FH-Do
War das nicht die Dame, die den Inhalt der Bücher ihres Mannes (Helmut)
nicht verstanden hat? Durfte auch damals unter ihr 'lernen'. Ihr Mann
ist der Frau übrigens ein paar Generationen vorraus. Sprich sie aber
bitte nicht drauf an ;-)
Was regt Ihr Euch so auf ? C++ ist eine "Erweiterung" (für Chefs) der C-Sprache, respektive eine Möglichkeit C-Code schauder in C++ Code zu verwenden und gar zu kapseln. Wenn jemand eine saubere, objektorientierte Programmiersprache haben will, die auch Fehler und Beweise sinnvoll und relativ einfach realisieren kann, der sollte EIFFEL nehmen. Da gibt's Varianten und Invarianten und der Compiler weist einen auf Ungereimtheiten hin ;) Und gerade die Möglichkeit bestehenden C-Code schauder einzubinden, ohne ihn umschreiben zu müssen hat ja maßgeblich am Erfolg beigetragen ... Allerdings finde ich den Vergleich zwischen C++ und BASIC doch etwas dreist ;) Wer allerdings schonmal in den "Genuß" von "optimiertem" C-Code in einer Zeile mit verschobenen Shifts und eventuell noch'n GOTO doppelschauder gekommen ist, der wird verstehen, warum man C hassen kann ... Finde die Seite jetzt nicht, aber sinngemäß: How to shoot urself in the foot: C: Shoot urself in the foot. Pascal: The compiler wont let u shoot urself in the foot. . . . Rest der Programmiersprachenbeispiele dafür ist mir entfallen lol Wobei der ganze Quatsch sinnfrei ist, denn alle iterativen Programmiersprachen haben i.d.R. die selben Kontrollkonstrukte und warum nicht gleich in einer Turing Maschine programmieren ? Achja, hab' ich mich selbst nicht dran gehalten Uuups Dont feed the trolls GNUler
> Modula2: After realizing that you can't actually accomplish > anything in this language, you shoot yourself in the head. Der ist sehr schön. Wer sich mal Modula2 angeschaut hat (oder sogar damit arbeiten sollte), weiss was gemeint ist :D
Der Wirth'sche Ansatz war ja: Neues Problem, neue Sprache. Mangelnde Keativität kann man ihm ja nicht vorwerfen. Ist aber ein klassischer Elfenbeinturm-Ansatz.
Der Modula - C/C++ Vergleich ist sehr gut! Vieles aus Modula2 wurde in Turbo-Pascal verbaut! >Auszug zu C++ >Ehrlich gesagt, hat mit Speicherverschwendung keiner der heutigen >Entwickler ein Problem. Eigentlich kommt den meisten die >Speicherverschwendung durch Templates und unflexibles Binden bei >Klassen sehr gelegen, denn damit lässt sich den unverschämt >wachsenden Speichergrößen paroli bieten und auch der letzte >Benutzer kann davon überzeugt werden, dass man für "moderne" >Programme auch moderne Rechner braucht! http://users.informatik.uni-halle.de/~thielema/CHater.html#CvsM3_IfElse Und das wollte ich eigentlich mit meinen Aussagen über Templates gesagt haben, was in der Seite auszugsweise rezitiert steht. Glücklicherweise habe ich zuerst BASIC, dann Pascal und zuletzt C gelernt, was mich zumindest durch Pascal bedingt sauber programmieren ließ. Später kam dann mal sporadisch C++ Wir mussten damals bei "Lady Balzert" in Daten-Organistion z.B. eine Büchereiverwaltung programmieren (Pascal) und ich hatte die Idee einen Binärbaum für etliche verschiedene Datentypen zu benutzen in dem ich mir Vergleichsfunktionen für alle Datentypen schrieb und diese dann an die Baumroutinen mit übergab. Ergebnis: Im Extremfall bis zu 5 x kleinerer Maschinencode als bei meinen Studienkollegen. Die Verwendung der Vergleichsroutinen kostete zusätzliche Zeit im Bereich von Mikro-Sekunden (damals noch Intel 386-486 PC's). Also im Gegensatz zu den großen statischen Compilaten meiner Kollegen eher ein Witz an Speicherverbrauch. Aber was Modula-3 betrifft, muß man sagen nette Sprache. Ich werde irgend wann man nen blick auf ADA werfen, da dürfte die Sicherheit noch viel strenger sein. Insbesondere das Airbuskonsotium arbeitet viel mit ADA bei den Flugzeugsteuerungen. Bemerkenswert ist die Zusammenarbeit mit JAPI www.japi.de Da Japi die Java-Virtual-Machine (JVM) benutzt um eine GUI zu kreieren, und mit jeder JVM zusammenarbeitet eigendlich ne feine Sache, Sprachen und BetriebsSystem - unabhängig. Aber was die C++ - STL betrifft bietet diese Routinen, die normalerweise (weitgehend) zum Standardwissen eines Informatikers gehören sollten. So was gibt's auch in reinem C sieh hier: http://www.amazon.de/Algorithmen-mit-m-Diskette-Zoll/dp/3897211653/sr=1-7/qid=1157929469/ref=sr_1_7/302-0776332-0777607?ie=UTF8&s=books Nur eben alles weit kompakter als in C++. So bietet die STL z.B. auch die Verarbeitung von Mengen an mit Schnitt, Differenz, Vereinigung usw.und alles wird entweder mit ner Liste oder einem Baum realisiert. Wenn man weis, das die Mengenlehre sowie die boolsche Algebra sog. boolsche Verbände sind, die sich vice versa in einander übersetzen lassen, kann man eine Menge auch auch als gigantische Bitleiste "Array of Bytes" ansetzen und mittels modulo 8 die Position des Bytes und einer 8 Bitmaske das gesuchte Bit bestimmen. Ist alle mal schneller als jeder Baum geschweige denn eine Liste. Gemessen an der Geschwindigkeit macht da auch die Binärsuche schlapp! In der STL wird von sortierten Mengen ausgegangen! Bei der Bitleiste entfällt das sortieren und der benötigte Speicher ist 8x kleiner. Wenn man Strings in Mengen unterbringen will geht das auch! Mann setzt A=1, B=2....Z=26 sowie Kleinbuchstaben und Sonderzeichen hinten dran (ASCII-Liste). Nehmen wir mal das Wort "ADELE" Das soll nur 'ne grobe Beschreibung sein! Anschließend kann man mit dem Wort Buchstaben weise wie folgt arbeiten Summe(A^1, D^2, E^3, L^4, E^5.... ); usw. daraus eine Zahl kreieren, die mittels Summe der Potenzen der Buchstaben gewonnen wurde und diese dann in der Bitleiste setzen kann. Übrigens machen das alle Suchmaschinen so ähnlich bei Wortkonstrukten als sog. Vektorsuche mit der Bildung des Skalarproduktes {(0..1) * 100%} im Suchtext, wobei man dann 70% mehr oder weniger als Überenstimmung vorgeben kann. Datenbanken alla Oralce oder PostgreSQL würden bei Text-Retrieval sofort pleite gehen! Bei "Double" könnte man Mengen riskieren, das Programm dürfe aber nicht portabel sein, auch wenn es auf dem Zielrechner läuft, da die interne darstellung von Mantisse und Exponent bei den Herstellern variieren kann. Außerdem sind reelle Zahlen nicht diskret, also nicht abzählbar unendlich viel, wie die Gruppe der Integers, darunter die natürlichen und ganzen Zahlen. Wie ich schon sagte, "Algorythmics" wollen gelernt sein, denn schließlich schmeckt's beim Chinesen doch besser als aus der Maggi-Tüte oder ? ################################################################# Ach so, was ich oben noch einem Poster zur ARIANE sagen wollte. Das lag nicht an ADA, sondern daran, das man nicht unbedarft Code übernehmen kann sondern sich immer wieder vollkommen neu an die Situation anpassen muss, gerade erst recht bei technischen Produkten. Und da kommt wieder zum vorschein das am falschen Ende gespart wurde, denn 'ne zerschossene Rakete samt Satelit ist teurer als 100 Programmierer pro Jahr. In Sachen C und Betriebssysteme, gibt es allerdings eine bedeutende ausnahme. MVS/VSE das von IBM stammt und bei siemens noch als BS2000 gepflegt und verkauft wird. Das ding ist früher in PL/1 entwickelt worden und alle Mainframe haben Down-Zeiten von ca. 2h im Jahr, Unix folgt mit 22h und Windows-NT mit 220 stunden Down-Zeit. Mittlerweile haben aber auch Unix-Rechner die HotPlug-Technik so das teile im laufenden Betrieb getauscht werden können und somit auch sehr nahe an die BetriebsSicherheit der Mainframes herankommen. Testsieger ist allerdings der russische SETUN-1-Rechner der mit Trinärlogik arbeitet. Er bringt es auf eine UP-time von 20 Jahren ohne einmal down gewesen zu sein. Folgemodell Setun-2 löste ihn 1978 ab und beide steuerten oder steuern noch Lenins Mausoleum. Dieser Sachverhalt wiederlegt auch den Fall den die Amis als Spionage bei DEC entlarfen wollten, weil 1986 ein Deutscher über Schweden die DEC-Rechner an die Russen verkauft haben soll, angeblich zur Modernisierung ihrer Raketenstationen. Witz komm raus vor allem wenn die was viel zuverlässigeres haben als nen DEC-Unixrechner von 1986...... Theo
Also ich bin platt. Gebe zumindest zu deine Beiträge zumindest quer gelesen zu haben, aber die sind ja so was Wirres. Ich komm mir vor wie bei Galileo in der Glotze. Sag mal hast du von irgendwas worüber du schreibst auch richtig Ahnung, oder ist das alles nur zitiert von irgendwoher. Irgendwo mal gehört oder gelesen? Oder falsch verstanden? Außerdem: DU machst den Leuten den ganz ganz dringlichen Rat, doch mal auf ada zu schauen, weil das ja der Renner sei und dann erwähnst du mal so nebenbei daß du dir die ja auch mal anschauen willst - irgendwann. Gehts noch? Du redest von so vielen Sprachen, daß du die allenfalls aus der Zusammenfassung des Schülerdudens kennen kannst..... Das bringt doch keinem was wenn du hier einfach nur Schlagworte reinschreibst oder subjektive Einschätzungen ohne hartes Hintergrundwissen. Ok ich gebe zu: ALLES konzentriert hab ich nicht gelesen. Wenn ich harte Infos überlesen habe, ziehe ich meine Meinung zurück und behaupte das Gegenteil.
Hi, was 'ne tolle Diskussion. Jungs, bleibt auf dem Teppich! Mal abgesehen davon, das Pascal (und Turbo-Pascal) vor Modula kam ;-) zur Diskussion: C ist eigentlich nur ein besserer Macro-Assembler, kein Witz, am Anfang war das wirklich so. Auch wenn die heutigen C-Compiler deutlich besser sind und vor allem Standard-konformer! Aber wenn man versucht, ein everybodys-darling zu produzieren, sollte man sich natürlich nicht wundern, das das Konzept systembedingt so seine Schwächen hat. Die Möglichkeiten, mit C grandios Schiffbruch zu erleiden, sind bekannt und sollen hier auch nicht wiederholt werden. C++ ist nur eine Aufsatz auf C! D.h. es hat systembedingt die Schwächen von C geerbt und, weil man natürlich hier auch möglichst alles abdecken wollte, noch eine weitere "interessante Features" hinzugefügt. Man KANN in C/C++ gute Projekte jenseits von "hello world" durchführen, man kann aber auch spektakuläre Touchdowns produzieren. Der Unterschied zwischen dem einen und dem anderen heißt: Wissen, Erfahrung und vor allem DISZIPLIN! Die Disziplin, sich ein mehr oder weniger enges Korset and Programmier-Richtlinien zugeschnitten auf das jeweilige Projekt anzulegen! Es ist richtig, das es, um C-Projekte sicher und nachvollziehbar zu machen, einige Jahre Programmiererfahrung braucht, für C++ läuft die gleiche Zeit NOCHEINMAL! Und selbst dann gilt: ohne die Disziplin, sich an bestimmte Festlegungen und Regeln zu halten, geht's meist nur schief! Aber warum wird C++ als "Schweizer Messer" und Allheilmittel der Softwarebranche (und als Alptraum der Programmierer) gehandelt: weil den Entscheidern noch nicht beigebracht worden ist, das a) Softwareportierbarkeit (vor allem zu 100%!) nur eine Legende ist und b) das es nicht die Programmiersprache für alles gibt! Frag doch mal einen Entscheider, welche Programmiersprachen er kennt! Und weil man ebend seine Experten nicht fragen kann (weil, dann ist man ja ein Weichei!), wird's auch nicht besser. Soviel meine Meinung (und Erfahrung!) zu diesem Thema, schönen Tag noch, Thomas
Mir scheint irgendwie auch, als hätte Theo von nichts, was er schreibt wirklich eine Ahnung. Er widerspricht sich in zwei aufeinanderfolgenden Postings doch enorm selber. Außerdem schreibt er, als würde er jeden Absatz eine neue Quelle haben, von der er abschreibt Überigens - Übersichtlicher, verständlicher Code ist wesentlich wechtiger als möglichst klein - Klar hat die STL nur Standard-Routinen, aber wer will die jedes mal aufs neue schreiben? Das wäre doch Zeitverschwendung - STL hat Bitfelder, steht das in deiner Abschreibvorlage nicht drin? - Was hat ein Bitfeld-Zugriff mit einer Binätsuche zu tun, bzw wie sucht man binät in einem Bitfeld? Willst du das vorher sortiere?... - Wie willst du bei deinem Suchmaschinen-Vektor-Beispiel damit umgehen, dass dein Merkmalsraum keine konstante Anzahl an Komponenten hat? - Was hat HotPlug mit Unix-Rechnern zu tun. Du weißt schon was HotPLug ist? - Dass Komplexität und Miniaturisierung die Ausfallwahrscheinlichkeit unweigerlich steigern ist dir schon zu Ohren gekommen? Zu guter letzt: Bleib bei deinem Maggi-Fix, deine Texte habe zu viel Ähnlichkeit damit
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.