Verleitet C++ zum komplizierteren denken?
-
;fricky schrieb:
Burkhi schrieb:
Bei einen Microcontroller reicht es ja auch meistens aus, diesen in Assembler oder C zu programmieren, weil man solch hohe Anforderung an diesen meist gar nicht stellt.
was meinst du wohl, welche anforderungen an die gestellt werden? meistens arbeiten sie 24/7 an ihrer leistungsgrenze, der code muss kompakt, performant, sparsam mit RAM umgehen und 'direkt' sein. solche hohen anforderungen werden an PC-programme fast nie gestellt.
Kannst du bitte mal ein Beispiel geben, wo ein Microcontroller ständig an seiner Leistungsgrenze arbeitet? Was für Anforderungen sind das und was meinst du mit 'direkt'?
-
volkard schrieb:
(blaBla isMemberOf: Polar) ifTrue: [ self cutWithPolar: blaBla ] ifFalse: [ self cutWithLine: blaBla ].
Ist das jetzt nicht doch Double Dispatching aus dem Lehrbuch?
eine Art Simulation von double-dispatching. Der Standard-Mechanismus zur Auswahl der Methode zur Laufzeit ist single-dispatched, weil das 1. Argument einer message (der receiver) darüber entscheidet, welche Methode veranlaßt wird - es wird einfach im Methoden-Verzeichnis des receivers nach einem passenden Eintrag gesucht und aufgerufen.
Die "Typweiche" mit isMemberOf: läßt sich übrigens auf folgende OO-gemäße Weise vermeiden:
Man definiert eine Klasse "pairOfDrawElement", die als Unterklassen die Typenpaare "pairLinePolar", "pairPolarPolar" und "pairLineLine" enthält. Jede Unterklasse implementiert die Methode "cut".
Zur Datenstruktur "Figure" (Array von n Strecken, Bögen usw.) wird dann ein Array vom Typ "ArrayOfPairOfDrawElement" hergestellt, daß die n^2 Paare aus Strecke/Bogen, Strecke/Strecke, Bogen/Bogen
enthält.Der Algo "cutWith: aFigure" stellt dann zunächst das zugehörige ArrayOfPairOfDrawElements her und ruft dann nacheinander deren spezifische Schnittmethoden auf:
anArrayOfPairOfDrawElements do: [ :each | each cut ]. "isMemberOf: oder isKindOf: nicht mehr nötig."
Übrigens ist es möglich, in Smalltalk double- und multiple-dispatch zu implementieren, das geht in Smalltalk selbst (wenn auch mit geringerer Performance) ohne daß die VM oder die Sprache dazu geändert werden muß.
-
tntnet schrieb:
99,9% der besten Programme wurden aber aus guten Grund mit C++ geschrieben. Nämlich weil 99,9% der Programmiersprachen eben nicht dafür geeignet sind.
das ist nichts anderes, als eine vorlaute behauptung von dir, die du niemals begründen kannst. was sollen denn die 'besten programme' sein? und sag jetzt nicht dein in C++ gestricktes web-framework. du wirst sicherlich sofort einsehen, dass andere (nicht C++ basierte) webtechnologien, deiner software haushoch überlegen sind.
Burkhi schrieb:
Kannst du bitte mal ein Beispiel geben, wo ein Microcontroller ständig an seiner Leistungsgrenze arbeitet? Was für Anforderungen sind das...
z.b. in produktionsanlagen die praktisch das ganze jahr durchlaufen, zur messdatenerfassung, telemetrie, datalogging, etc. werden welche eingesetzt. die laufen unter vollast, pumpen gewaltige datenmengen durch die gegend und werden so gut wie nie ausgeschaltet. und auch sonst eigentlich in jeder komplexen technischen anlage, sei es nun im kfz oder in deiner waschmaschine für steuerungsaufgaben usw. die dürfen nicht einfach so abkacken, wie ms-windows oder der media-player. d.h. die anforderungen (an die software), was stabilität und bugfreiheit angeht, sind viel höher als beim pc-frickelkram. bei end-user embedded-zeugs wie handys z.b. kommt aber auch wieder mit der heissen nadel (c++?) gestrickte software zum einsatz.
-
;fricky schrieb:
... sei es nun im kfz oder in deiner waschmaschine für steuerungsaufgaben usw. die dürfen nicht einfach so abkacken ...
Schon richtig, aber das Gros der Prozessoren langweilt sich eher zu Tode. Was in den meisten Reiskocherapplikationen drinsteckt, ist meilenweit überdimensioniert.
Aber wenn was einfach und effektiv erledigt werden kann, naht schon Rettung: Ich hab' mal eine Getriebesteuerung mit einem 68HC11 und ein paar hundert Bytes ASM- Code gelöst, das Ding hatte noch so viel Luft, daß´ich auch noch fünf andere mitversorgen hätte können. Für eine kleine Erweiterung wurde ein visuelles Softwaredesigntool ausprobiert, womit man nach zehn Minuten Umeinanderklicken z.B. eine Schleife hinbekam, raus kam dann ziemlich viel P-Code, den das Target interpretieren durfte. Der C167 hat das gerade mal so für ein Getriebe hinbekommen, aber der ist aber auch um Dimensionen schneller als ein HC11.
Ähnlich geht es bei der Industrieautomatisierung zu. SPS wurde als Dödel- Programmiersprache für vertrottelte Einrichter geschaffen und markiert so ziemlich den Gipfel an Ressourcenvergeudung. Ein Schleifautomat bei einem Nachbarbetrieb z.B. ist so ein Teil, wo alles so langsam zugeht, daß sich ein PIC mit'm Uhrenquarz die meiste Zeit schlafen legen könnte, tatsächlich werkelt in der SPS ein 68030 mit 50 MHz unter Vollast. Ein einmal eingeschlagener Irrweg wird dann über Step-3/5/7 zum wirrköpfigen Wahnsinn ausgebaut und weil den kaum ein Mensch in der eigentlichen Zielgruppe mehr direkt programmieren kann, mit grafischen Konfigutrationstools zugeklatscht. An komplexeren Problemen habe ich dennoch etliche erfahrene Teams scheitern gesehen. :p
Aber immerhin: Das Zeug muß 24/7 funktionieren und das tut es, auch wenn das Grundkonzept pure Prozessorbeschäftigungstherapie ist.
Um den etwas weiten Bogen zu schließen: Es scheint Menschen zu geben, denen schlichte, effektive Lösungen Unbehagen verursachen. Da muß dann weiter gefasst werden als nötig, bis man aus einer einfachen Sache einen aufgeblasenen Popanz gemacht hat. Und wie man sieht, braucht man nichtmal C++ dazu.
-
Meine Erfassungspunkte, die ich für VW entwickelt habe, laufen in der Produktion 7 Tage rund um die Uhr, seit 2003 ist der älteste im Einsatz, und bisher gabs, obwohl die alle unter Windows laufen, nie Probleme damit. Das soll zeigen, dass es auch mit dem "Frickel C++ Builder" durchaus möglich ist, stabile und zuverlässige Programme sogar unter "Frickel-" Windows zu schreiben. Einen Ausfall in der Produktion kann sich VW nicht leisten, warum gehen sie dann so ein "Risiko" ein?
Unsere Stellwerksrechner und Bedienplatzsysteme (mit sicherer Anzeige), die nach SIL4 eingestuft sind, wurden auch in C++ programmiert, die Bedienplätze laufen auch unter Windows, der Stellwerkskern unter einen Unix-System, mit A und B Code und zusätzlich noch je eine Intel und Power PC Plattform. Wären C++ Programme wirklich so mit der heissen Nadel gestrickt, würden diese Systeme niemals eine Zulassung des EBA bekommen.
Damit schliess ich auch meinen Teil zur Diskussion ab, manche Leute leben nun mal in ihrer kleinen Welt, und solange sie da glücklich sind, sollte man sie auch glücklich sein lassen.
-
OK ich hab mir hier garnichts durchgelesen, aber ich muss sagen das was du auf Seite beschreibst, das habe ich genau so erlebt. Desshalb überlege ich mir auch zweimal bevor ich ein Projekt in C++ Anfange.
-
pointercrash() schrieb:
Das Zeug muß 24/7 funktionieren und das tut es, auch wenn das Grundkonzept pure Prozessorbeschäftigungstherapie ist.
Welches Grundkonzept denn nun?
-
tntnet schrieb:
99,9% der besten Programme wurden aber aus guten Grund mit C++ geschrieben. Nämlich weil 99,9% der Programmiersprachen eben nicht dafür geeignet sind.
Kindisches C++-Fanboy-Verhalten.
Sei mal nicht so begrenzt. Es ist jedem klar wie toll du C++ findest und wie sehr es dein Ego pumpt, dass du in der Sprache programmierst, die du so toll findest. Das ändert aber nicht im Geringsten an der Tatsache, dass die Sprache Müll ist.
tntnet schrieb:
Wenn Du mit dem Profitool C++ nicht umgehen kannst, dann lass es einfach und bleib bei Deinen leicht zu lernenden Hobbysprachen, die Dein Intelektuell nicht überfordern
.
Mach dich nicht lächerlich.
Wieder so ein typisch kindisches Fanboy verhalten. Wenn Kritik geübt wird, dann kommen Fanboys immer mit "du bist zu dumm um so ein Profi-Werkzeug zu bedienen". Komm mal auf den Teppich und setze mal deine rosa Brille ab.
Dir sollte folgendes klar werden:
- Die umständliche Bedienung ist kein hinreichendes Kriterium für die Professionalität. Im Gegenteil. Umständliche Bedienung zeugt von einem misslungenen Konzept. Denn es geht einfacher.
tntnet schrieb:
Und hör endlich auf, über das Profiwerkzeug C++ zu lästern, womit Du nicht umgehen kannst. C++ ist nicht schlecht, nur weil Du C++ nicht verstehst.
Schon wieder. Siehe oben. C++ wird aber auch nicht gut, nur weil du es versteh... *hust* weil du es meinst zu verstehen.
tntnet schrieb:
Ich wundere mich überhaupt, warum Du Dich hier im C++-Forum rumtreibst, wenn Du der Meinung bist, C++ sei schlecht.
Wieso sollte er nicht? Oder fühlst du dich in deinem Ego angegriffen wenn er deine angebetete Sprache kritisiert, womit er ja nicht unrecht hat.
-
tntnet schrieb:
99,9% der besten Programme wurden aber aus guten Grund mit C++ geschrieben. Nämlich weil 99,9% der Programmiersprachen eben nicht dafür geeignet sind.
99.9% ~ 100%
Aus dieser Aussage kann man deutlich herauslesen, dass C++ die einzige Sprache ist, die du beherrschst. Dann wundert es mich nicht mehr, dass du es so toll findest.
-
Aus dieser Aussage kann man deutlich herauslesen, dass C++ die einzige Sprache ist, die du beherrschst. Dann wundert es mich nicht mehr, dass du es so toll findest. Das ändert aber nicht im Geringsten an der Tatsache, dass die Sprache Müll ist.
Hier wird Verhalten von Personen beurteilt und nebenbei argumentfrei C++ kritisiert.
- A hat nichts mit B zu tun.
- Wenn es ein Fakt ist, warum wird dann ueberhaupt diskutiert? Warum wird ueberhaupt noch Software damit produziert? Es ist eben doch kein Fakt, sondern nur eine Meinung. Und Meinungen sind ja wie ...
Aus dieser Aussage kann man deutlich herauslesen, dass C++ die einzige Sprache ist, die du beherrschst. Dann wundert es mich nicht mehr, dass du es so toll findest.
Und was sagt das jetzt ueber C++ aus?
Java, C++, C#, C werden alle reichlich benutzt, obwohl sie sehr unterschiedlich sind.
OMG... Nein! Sie sind alle imperativ. Es wird einzig und allen durch Seiteneffekte programmiert. Alle bieten ein aehnliches Objektsystem (Messfehler bei C). Fuer alle gibt es Garbage collection (z.B. als Bibliothek).
-
u_ser-l schrieb:
volkard schrieb:
(blaBla isMemberOf: Polar) ifTrue: [ self cutWithPolar: blaBla ] ifFalse: [ self cutWithLine: blaBla ].
Ist das jetzt nicht doch Double Dispatching aus dem Lehrbuch?
eine Art Simulation von double-dispatching. Der Standard-Mechanismus zur Auswahl der Methode zur Laufzeit ist single-dispatched, weil das 1. Argument einer message (der receiver) darüber entscheidet, welche Methode veranlaßt wird - es wird einfach im Methoden-Verzeichnis des receivers nach einem passenden Eintrag gesucht und aufgerufen.
Die "Typweiche" mit isMemberOf: läßt sich übrigens auf folgende OO-gemäße Weise vermeiden:
Man definiert eine Klasse "pairOfDrawElement", die als Unterklassen die Typenpaare "pairLinePolar", "pairPolarPolar" und "pairLineLine" enthält. Jede Unterklasse implementiert die Methode "cut".
Nur eine Verschiebung. Wie erzeugst Du aus zwei Elementen das passende Paar?
Übrigens ist es möglich, in Smalltalk double- und multiple-dispatch zu implementieren, das geht in Smalltalk selbst (wenn auch mit geringerer Performance) ohne daß die VM oder die Sprache dazu geändert werden muß.
Eine Funktion, die anhand beider Typen in einer Liste schaut. Macht man in C++ auch.
-
lilafisch schrieb:
Kindisches C++-Fanboy-Verhalten.
Sei mal nicht so begrenzt. Es ist jedem klar wie toll du C++ findest und wie sehr es dein Ego pumpt, dass du in der Sprache programmierst, die du so toll findest. Das ändert aber nicht im Geringsten an der Tatsache, dass die Sprache Müll ist.
Java ist die beste Sprache von der Welt!
-
Artchi scheint das ganze arg an die Nieren zu gehen...
-
Burkhi schrieb:
Meine Erfassungspunkte, die ich für VW entwickelt habe, laufen in der Produktion 7 Tage rund um die Uhr, seit 2003 ist der älteste im Einsatz, und bisher gabs, obwohl die alle unter Windows laufen, nie Probleme damit. Das soll zeigen, dass es auch mit dem "Frickel C++ Builder" durchaus möglich ist, stabile und zuverlässige Programme sogar unter "Frickel-" Windows zu schreiben. Einen Ausfall in der Produktion kann sich VW nicht leisten, warum gehen sie dann so ein "Risiko" ein?
die gehen risiken ein, weil sie sich desen überhaupt nicht bewusst sind. einige entscheider haben leider keinen durchblick und glauben daher blind an irgendwelche microsoft- und pc-hersteller-werbesprüche. gegenbeispiel: ein betreiber von riesigen baggern und mobilen 'outdoor-bohrmaschinen' wollte seine monstergeräte mit 'ner messdatenerfassung ausrüsten, die dann jeden tag einmal die daten per email an einen server schickt. wir schlugen denen vor: 'nehmt unser kleines kästchen, das könnt ihr bequem an eurer bussystem anschliessen und es kann alles, was ihr braucht, hat keine mechanischen teile, ist wetterbeständig, kostet etwa 1/5 eines pcs, usw...' wollten sie aber nicht haben, weil sie der meinung waren, dass standard (aber schon für den harten einsatz) pc-technik einfach die bessere wahl ist. also haben sie besonders widerstansfähige industrie-pcs mit winXP darauf verwendet und von uns kam nur die software. moral von der geschicht: es läuft etwa ein halbes jahr, dannn ist irgendwas im eimer. mal wurden festplatten oder displays durch vibrationen gekillt, hin und wieder hats auch den gesamten pc zerrissen (wohl durch extreme temperaturunterschiede, in kalten gegenden ist das ganze irgendwie besonders kurzlebig). dass in der rauhen umgebung windows auch gern mal einfach so abstürzt und ein ganzer tag nichts aufgezeichnet wurde, muss ich nicht noch extra erwähnen.
Burkhi schrieb:
manche Leute leben nun mal in ihrer kleinen Welt, und solange sie da glücklich sind, sollte man sie auch glücklich sein lassen.
es gibt aber viele dieser kleinen welten. die gibt's nicht wegen irgendwelchen leuten, sondern es gibt überall verschiedene situationen und randbedingungen. wer, mit blindheit geschlagen, methoden und verfahren, die sich in welt a bewährt haben, unreflektiert in welt b einsetzt, kann auch schon mal böse auf die nase fallen.
-
;fricky schrieb:
...gegenbeispiel: ein betreiber von riesigen baggern und mobilen 'outdoor-bohrmaschinen' wollte seine monstergeräte mit 'ner messdatenerfassung ausrüsten, die dann jeden tag einmal die daten per email an einen server schickt. wir schlugen denen vor: ...keine mechanischen teile, ist wetterbeständig,... wollten sie aber nicht ...
...sie haben in ihren Kontext die falsche Entscheidung getroffen [PUNKT].
Nicht mehr und nicht weniger. Nur weil im Fall A die Lösung Z nicht passend ist gilt dies nicht für den Fall B.
;fricky schrieb:
Burkhi schrieb:
manche Leute leben nun mal in ihrer kleinen Welt, und solange sie da glücklich sind, sollte man sie auch glücklich sein lassen.
es gibt aber viele dieser kleinen welten...
Ja, schön das du es einsiehst. In dem einen Fall greift man zur Lösung Z, in der anderen zur Lösung Y. Manchmal kann man die Lösung sowohl mit M,N,O,P erreichen, manchmal ist N passender, manchmal P...
Und so ist es auch mit deinem ach so geliebten C und deinen ach so verhassten C++.
-
No comment:
Imageworks startet Open-Source-Projekte
Java ist die beste Sprache von der Welt!
-
Was bringt die "Diskussion"?
Die einen lieben eine Sprache und hassen alle anderen. Zu entscheiden, ob das gut oder schlecht ist, bleibt jedem selbst überlassen. Diskussion bringt hier eh nichts und Argumente sind ebenfalls nur Perlen vor die Säue geworfen.
Die anderen nehmen die Sprache oder das Werkzeug, das am besten zu jeweiligen Problem passt.
Und um auf die Frage des TOs zurückzukommen:
C++ verleitet zum abstrakten Denken. Ob "abstrakt" mit "kompliziert" gleichzusetzen ist... Keine Ahnung.Esst mehr Kunstrasen.
-
Tachyon schrieb:
Was bringt die "Diskussion"?
Nichts, es gibt höchstens ein paar Leute, welche sich einfach nicht verkneifen können, auf die sau dummen Kommentare von fricky zu antworten.
Lasst fricky seinen Unsinn in die Welt brüllen. Jeder mit ein wenig Grips erkennt dass er völlig fanatisch argumentiert mit völlig falschen Argumenten. Wer das nicht erkennt, den wollen wir im C++ Bereich gar nicht haben. Also was solls?Ich schliesse mich allerdings Artchi an:
C ist die beste Sprache der Welt! Heil C!Grüssli
-
Tim schrieb:
pointercrash() schrieb:
Das Zeug muß 24/7 funktionieren und das tut es, auch wenn das Grundkonzept pure Prozessorbeschäftigungstherapie ist.
Welches Grundkonzept denn nun?
Hast keine Lust mehr, zu googeln? Im Wesentlichen verdonnert Dich eine zyklusorientierte SPS zur reinen Polling- Programmierung, heißt, Dein Programm wird ein paar hundertmal++ pro Sekunde durchgerissen.
Mit Step-5/Step-7 vom großen S (von Mitsubishi Automation gibt's was Ähnliches) haben sie das großzügig um ereignisorientierte Programmierung erweitert, aber jeder Quatsch wird als Erweiterungskarte einzeln in Hardware gegossen. Ne Primitiv- SPS kostet so um die 100 Teuronen, aber die meisten Setups reißen die fünfstellige Latte. Schon schlau sowas - billig anfixen und dann voll abzocken.
-
Dravere schrieb:
Tachyon schrieb:
Was bringt die "Diskussion"?
Nichts, es gibt höchstens ein paar Leute, welche sich einfach nicht verkneifen können, auf die sau dummen Kommentare von fricky zu antworten.
Lasst fricky seinen Unsinn in die Welt brüllen. Jeder mit ein wenig Grips erkennt dass er völlig fanatisch argumentiert mit völlig falschen Argumenten. Wer das nicht erkennt, den wollen wir im C++ Bereich gar nicht haben. Also was solls?Ich schliesse mich allerdings Artchi an:
C ist die beste Sprache der Welt! Heil C!Grüssli
Vielleicht hat auch fricky Recht. Wer weiss, wer weiss....