Verleitet C++ zum komplizierteren denken?

weiß zwar nicht, wozu so eine Polar/kartesische Gemengelage sinnvoll sein soll, aber dazu bildet man eine Oberklasse "DrawElement" zu Strecke + Ellipsenbogen + Polar; deren Instanzen werden in einem Array gespeichert, das die Eingabe für den Schnittalgorithmus darstellt.

Geeignete Schnittalgorithmen zwischen den 3 Typen werden ja vorausgesetzt, also geht es nur noch darum, die Vereinigungsmenge aus den einzelnen Schnittpunktmengen zwischen je zwei "DrawElement" zusammenzusetzen, das paßt schon.

volkard

u_ser-l schrieb:

weiß zwar nicht, wozu so eine Polar/kartesische Gemengelage sinnvoll sein soll, aber dazu bildet man eine Oberklasse "DrawElement" zu Strecke + Ellipsenbogen + Polar; deren Instanzen werden in einem Array gespeichert, das die Eingabe für den Schnittalgorithmus darstellt.
Geeignete Schnittalgorithmen zwischen den 3 Typen werden ja vorausgesetzt, also geht es nur noch darum, die Vereinigungsmenge aus den einzelnen Schnittpunktmengen zwischen je zwei "DrawElement" zusammenzusetzen, das paßt schon.

4 Typen, oder? Ellipsenbogen, Quadrat, Gerade, Polarzeug.
Wie findest Du aus einem der 16 möglichen eingehende Typtupel den richtigen der 6 Schnittalgorithmen?

volkard

u_ser-l schrieb:

weiß zwar nicht, wozu so eine Polar/kartesische Gemengelage sinnvoll sein soll

Das weiß ich auch nicht. Der Polarkram war nicht wirklich nötig.

volkard schrieb:

Wie findest Du aus einem der 9 möglichen eingehende Typtupel den richtigen Schnittalgorithmus?

(blaBla isMemberOf: Polar) ifTrue: [ self cutWithPolar: blaBla ]
  ifFalse: [ self cutWithLine: blaBla ].

Ellipsenbögen gehen in Polardarstellung, bleiben also die Kombinationen Polar/Polar, Polar/Strecke und Strecke/Strecke.

volkard

u_ser-l schrieb:

volkard schrieb:

Wie findest Du aus einem der 9 möglichen eingehende Typtupel den richtigen Schnittalgorithmus?
(blaBla isMemberOf: Polar) ifTrue: [ self cutWithPolar: blaBla ]
  ifFalse: [ self cutWithLine: blaBla ].
Ellipsenbögen gehen in Polardarstellung, bleiben also die Kombinationen Polar/Polar, Polar/Strecke und Strecke/Strecke.

Ist das jetzt nicht doch Double Dispatching aus dem Lehrbuch?

volkard

u_ser-l schrieb:

(blaBla isMemberOf: Polar) ifTrue: [ self cutWithPolar: blaBla ]
  ifFalse: [ self cutWithLine: blaBla ].

um das normale dispatching nochmal zu verwenden, könnte man auch dem anderen Objekt die aufbereitete Nachricht weiterleiten.

(blaBla isMemberOf: Polar) ifTrue: [ self cutWithPolar: blaBla ]
  ifFalse: [ self cutWithLine: blaBla ].

würde zu
(in der Klasse Polar)

blaBla cutWithPolar: self

(in der Klasse Line)

blaBla cutWitLine: self

z.B. in der Klasse Polar wäre dann in cutWithLine klar, daß self ein polar und blaBla eine Strecke ist und man hätte den richtigen Algorithmus. Das würde man wohl anstreben, wenn man davon ausgeht, daß das eingebaute (single) Dispatching so ziemlich das beste ist, was man haben kann und daraus das double dispatching bauen will.
In C++ findet man auch beide Vorgehensweisen, das mit if sähe so aus

(blaBla isMemberOf: Polar) ifTrue: [ self cutWithPolar: blaBla ]
  ifFalse: [ self cutWithLine: blaBla ].

wird zu

if(Polar* b=dynamic_cast<Polar>(blaBla))
   return cutWithPolar(b);
if(Polar* b=dynamic_cast<Line>(blaBla))
   return cutWithLine(b);
/*wenn hier, dann programmierfehler*/

Die Version mit dem Zurückschicken brauche ich nicht zu scheiben, die ist ja gleich.

tntnet

;fricky schrieb:

tntnet schrieb:

C++ ist nicht einfach zu bedienen, aber wenn ich es beherrsche, also eine ausreichende Ausbildung erfahren habe, dann kann ich mit C++ mit einem angemessenen Aufwand die besten Applikationen der Welt machen.

da gebe ich dir recht, was immer auch die 'besten applikationen der welt' (oder von der welt, wie artchi sagen würde) sein mögen. aber leider trifft dein argument auf 99.9% aller sprachen zu, der unterschied liegt nur in der einfachheit der bedienung und dem damit verbundenen aufwand.

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.

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 . 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.

Ich wundere mich überhaupt, warum Du Dich hier im C++-Forum rumtreibst, wenn Du der Meinung bist, C++ sei schlecht.

JustAnotherNoob

tntnet schrieb:

die Dein Intelektuell nicht überfordern

tntnet schrieb:

;fricky schrieb:

tntnet schrieb:

C++ ist nicht einfach zu bedienen, aber wenn ich es beherrsche, also eine ausreichende Ausbildung erfahren habe, dann kann ich mit C++ mit einem angemessenen Aufwand die besten Applikationen der Welt machen.

da gebe ich dir recht, was immer auch die 'besten applikationen der welt' (oder von der welt, wie artchi sagen würde) sein mögen. aber leider trifft dein argument auf 99.9% aller sprachen zu, der unterschied liegt nur in der einfachheit der bedienung und dem damit verbundenen aufwand.

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 denke ich nicht. Für große Projekte sind vor allem die vorhandenen Tools (dazu zähle ich sowohl vorhandene Libs als auch Tools an sich, z.b. IDEs) und deren Support wichtig, und da sieht es bei C++ eindeutig am besten aus. Auch geschulte Leute gibts für C++ wahrscheinlich mehr als für Brainfuck.

Die Tatsache, dass sich so eine Masse an Tools und Anhängern für C++ entwickelt hat, muss nichtmal an der Sprache selbst liegen. Es ist selbstverständlich, dass sich in der Industrie einige wenige Sprachen durchsetzen müssen, die überall verwendet werden (natürlich mit Ausnahmen wie Sprachen die für Nischenanwendungen benötigt werden), aus Einfachheits- und natürlich Kostengründen. Dass das nicht unbedingt mit der Eleganz oder der Performance, sprich dem "Look and Feel" einer Sprache zu tun haben muss, sieht man ja bei uns. Java, C++, C#, C werden alle reichlich benutzt, obwohl sie sehr unterschiedlich sind.

Natürlich wird sich dabei sowas wie Brainfuck nicht durchsetzen, aber C++ ist sicherlich nicht das Non-Plus-Ultra und trotzdem wird sie sich wahrscheinlich gegenüber kommenden "besseren" Nischensprachen besser halten.

Burkhi

;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.

pointercrash**

;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.

Burkhi

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.

Krux

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.

knivil

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).

volkard

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.