Hallo Leute. Hab habe eine Crc8 Klasse die ich an mehrere Klassen vererbe (Uart1, 2, I2C usw.) In der Crc8 Klasse wird bei jeder Vererbung jedes Mal die gleiche Tabelle von 256Byte angelegt. Dies ist bei mehreren Klassen durchaus Ressourcen fressend und unnötig. Man Könnte jetzt die Tabelle einmal Global anlegen und auf diese verweisen. Geht es auch ohne Globale Variablen? zB. so Wird eine Klasse instanziiert die die crc8 Tabelle anlegt, überspringen die folgenden Klassen das Anlegen der crc8 Tabelle benutzen die bereits angelegte Tabelle. Ist das so Möglich? Wenn ja was sind denn das die Schlagwörter nach denen ich suchen muss?
lege sie mal als const static an. Aber warum wird denn Uart von CRC8 abgeitet? Das macht doch wenig sinn, ein eigenes CRC8 object ja, aber ableiten?
Alex schrieb: > Ja ist in der Statemaschiene einfacher zu handhaben. was ist daran einfacher? du bekommst doch schon Probleme wenn die UART gleichzeitig senden und empfangen soll. Dann brauchst man schon 2 CRC8 Objekte.
Peter II schrieb: > Das macht doch wenig sinn, Eben. Eine Vererbung ist immer dann angebracht, wenn es eine 'IST EIN' Beziehung gibt. Ein PKW ist ein Auto. Ein LKW ist ein Auto. Ein Auto ist ein Kraftfahrzeug. Ein Motorrad ist ein Kraftfahrzeug. Das alles sind Beispiele, in denen eine 'IST EIN' Beziehung offensichtlich ist. Aber: Eine UART ist ein CRC8 Gerät? Das würde ich mal ganz stark in Zweifel ziehen. Eine UART ist ein Kommunikationsgerät. Es verwendet vielleicht eine CRC8. Genauso wie so manch anderes Kommunikationsgerät. Aber deswegen ist eine UART kein CRC8 Gerät. -> Vererbung ist hier sehr wahrscheinlich das falsche Stilmittel.
Alex schrieb: > Ok Danke. > Ja ist in der Statemaschiene einfacher zu handhaben. Dann kann man immer noch den CRC Teil in einen CRC-Status-Teil und einen CRC-Maschinerie Teil zerlegen. Jedes verwendende Objekt hat seinen eigenen Running-CRC Status. Aber es gibt nur eine einzige CRC-Maschinerie (in der dann auch die Tabelle liegt), die diesen CRC Status je nach Input auf den jeweils neuesten Stand bringt. Man kann natürlich auch (in diesem Fall) eine CRC Klasse machen, die im Prinzip genau diesen Status enthält, und deren Objekte sich alle die konstante CRC-Basistabelle als einen static Member teilen. Im Endeffekt läuft es aufs gleiche raus, nur hat man 1 Klasse weniger. Nichts desto trotz: Eine UART IST KEIN CRC Objekt. Es enthält vielleicht eines, so wie ein Auto einen Motor hat. Aber genausowenig wie ein Auto ein Motor IST, genausowenig ist eine UART eine CRC. Als Faustregel IST EIN ********
1 | class A : public B |
2 | {
|
3 | ...
|
4 | };
|
HAT EIN *******
1 | class A |
2 | {
|
3 | ...
|
4 | |
5 | B memberB_; |
6 | };
|
Als erster Anlaufpunkt ist eine derartige Unterscheidung, die sich aus dem Alltagszusammenhang ergibt ("ist ein" versus "hat ein") meistens eine gute Richtlinie. Ob man dann im 'hat ein' Fall einen Member als Objekt hat, oder ob es dort eine Referenz oder einen Pointer auf eine einzige zentrale Instanz gibt (weil es in einer Firma zb nur eine einzige Warenausgabe gibt, d.h. die Firma hat nur 1 Warenausgabe-Objekt aber alle einzelnen Abteilungen enthalten Referenzen darauf), muss man im Einzelfall entscheiden.
:
Bearbeitet durch User
Dann hab ich mich wohl falsch ausgedrückt... Der State Uart1_COM bekommt die Klasse Uart und CRC8 vererbt. I2C_COM bekommt die Klasse I2C und CRC8 vererbt. Sind damit die Gemüter wieder beruhigt?
Alex schrieb: > Dann hab ich mich wohl falsch ausgedrückt... > > Der State Uart1_COM bekommt die Klasse Uart und CRC8 vererbt. I2C_COM > bekommt die Klasse I2C und CRC8 vererbt. Bist du sicher dass du das Konzept der Vererbung bei OOP verstanden hast?
Alex schrieb: > Dann hab ich mich wohl falsch ausgedrückt... > > Der State Uart1_COM bekommt die Klasse Uart und CRC8 vererbt. Also Mehrfachvererbung? Kann man machen, muss man aber nicht machen. Hier wär mir der Zusammenhang zwischen den geerbten Klassen etwas zu lasch. Ich würde der Uart1 einen Member einer CRC Klasse verpassen, wobei sich alle CRC Objekte die Tabelle als statischen Member teilen.
:
Bearbeitet durch User
Alex schrieb: > Der State Uart1_COM bekommt die Klasse Uart und CRC8 vererbt. ??? "Der State" lese ich zumindest so, daß damit ein Zustand irgendeiner State-machine gemeint ist. Ein solcher Zustand hat in meinen State Machines normalerweise einen byte oder integer Wert und vieleicht noch einen String als Namen, mehr nicht. Bei dir IST ein solcher Zustand ein serielle Schnittstelle? Bei dir IST dieser Zustand zusätzlich auch ein CRC8 Generator? Mehrfachvererbung ist meist das Ergebnis schlechten Designs. Immer KISS (keep ist simple and stupid) beachten.
Ja Statemaschiene. Zustand Uart1_com Unterzustand Rx Tx RX&Tx String muss crc geprüft/angehängt werden. Sollte ich für crc ein extra State machen. Müsste ich in der Statemaschene die Rx/Tx Daten Kopieren an den crc8 State senden und dann wieder zurück. Ist unnötig bring andere Problemme mit sich wie eventFifo überlauf usw. Also was genau sprich dagegen einen State zu schreiben der den String auf crc prüft/anhängt Außer dass es jetzt Mehrfach Vererbung ist?
zb, dass du nur mit Verrenkungen gleichzeitig CRC Betrieb auf der Sende und Empfangsstufe laufen lassen kannst. Wenn etwas eigentlich einfaches nur mit Verrenkungen möglich ist, dann ist das meiner Erfahrung nach ein Indiz dafür, dass in der Klassenhierarchie etwas nicht stimmt. Aber vielleicht brauchst du ja auch nicht die Fähigkeit gleichzeitig mit CRC Überwachung senden und empfangen zu können.
:
Bearbeitet durch User
Karl Heinz schrieb: > Eine Vererbung ist immer dann angebracht, wenn es eine 'IST EIN' > Beziehung gibt. Kanonisches Gegenbeispiel: Ein Kreis ist eine Ellipse.
Fred schrieb: > Karl Heinz schrieb: >> Eine Vererbung ist immer dann angebracht, wenn es eine 'IST EIN' >> Beziehung gibt. > > Kanonisches Gegenbeispiel: Ein Kreis ist eine Ellipse. Ok. Ich bein eigentlich schon davon ausgegangen, dass es um die prinzipielle Fragestellung 'Vererbung' oder 'Member Inclusion' geht. Die Frage, inwiefern sich dann einzelne Objekte durch die Parametrierung der Objekte unterscheiden hab ich mal aussen vor gelassen. In diesem Sinne gilt ja auch, dass ein Audi ein Auto ist, man aber sehr wahrscheinlich keine Klasse 'Audi' von 'PKW' herleiten wird.
Nein baruich ich nicht. Bsp. es kommt ein event TX erst wenn TX verarbeitet ist wähend es sendet kommt ein event Rx Tx macht weiter Rx kommt in den EventFifo Tx done event Rx wird abgearbeitet. (verarbeite empfangene Daten)
Jetzt vergiss diesen Vererbungsscheiss bei Kommunikationsroutinen. Eine CRC Statemachine hat genau eine Variable, den CRC Wert. Der wird mit jedem Empfangenen, resp gesendeten Byte um eins propagiert. Dh RX & TX brauchen je eine eigene CRC Variable. Und Schluss.
Karl Heinz schrieb: > Fred schrieb: >> Karl Heinz schrieb: >>> Eine Vererbung ist immer dann angebracht, wenn es eine 'IST EIN' >>> Beziehung gibt. >> >> Kanonisches Gegenbeispiel: Ein Kreis ist eine Ellipse. > > Ok. > Ich bein eigentlich schon davon ausgegangen, dass es um die prinzipielle > Fragestellung 'Vererbung' oder 'Member Inclusion' geht. Das Kreis-Ellipse Problem ist ein klassisches Beispiel um gegen OOP zu hetzen. Denn dort funktioniert der naive Ansatz "IST EIN" ganz schlecht und zwar in beide Richtungen. Wobei sich das ganz schnell auflöst wenn man eben nicht davon ausgeht dass ein Kreis eine Ellipse oder umgekehrt ist. IMO ist diese Annahme überhaupt nicht zwingend. Die Stimmung gegen OOP und dieses Beispiel, kommt aus recht prominenten Kreisen auch innerhalb der FSF, glaube sogar vom großen Stallman persönlich. gruß cyblord
Nein tue ich nicht. :) Der Aufwand ist mir zu groß. Die Statemaschiene bietet nun mal nicht diese Möglichkeit es so "einfach" zu machen. Da ist die Vererbung einfacher, auch wenn es Logisch getrennt sein müsste.
Alex schrieb: > Der Aufwand ist mir zu groß. welcher Aufwand? 1 Zeile code zum anlegen von CRC8 Objekt der der klasse? ob du dann den State updates oder eine Methode von CRC8 aufrufst ist doch wohl der gleiche Aufwand.
Ist ok. Der Aufwand die Statemaschiene und ihre Möglichkeiten zu erklären ist mir jetzt zu groß. Aber es ist nicht einfach nur eine Zeile Code. Sondern so ~600 min schätz ich mal. Die antwordt auf meine ursprüngliche Frage ist ja nicht falsch. Danke. Bis zum nächsten mal.
cyblord ---- schrieb: > hetzen. Denn dort funktioniert der naive Ansatz "IST EIN" ganz schlecht > und zwar in beide Richtungen. Wobei sich das ganz schnell auflöst wenn > man eben nicht davon ausgeht dass ein Kreis eine Ellipse oder umgekehrt > ist. IMO ist diese Annahme überhaupt nicht zwingend. Wobei es in der Informatik sowieso nur ganz wenige 100% Regeln gibt. Genau deshalb hab ich ja auch von einer Faustregel gesprochen. Wenn Informatik so einfach wäre, dass man nur 30 Regeln ungefragt und ohne nachdenken zu müssen anwendet und man dann automatisch ein super Programm bekommt, dann bräuchte man kein Informatik-Studium und auch keine Erfahrung. Dann könnte das jede Hausfrau (keine Beleidigung beabsichtigt). Wer immerwährende Grundsätze sucht, die er unüberlegt anwenden kann, der muss zu den Religionen gehen. Dort ist das sogar ein wesentliches Element, dass man nicht näher die Regeln hinterfragen und gegebenenfalls anpassen bzw. verletzen darf.
cyblord ---- schrieb: > Das Kreis-Ellipse Problem ist ein klassisches Beispiel um gegen OOP zu > hetzen. Keineswegs. Es ist ein klassisches Beispiel, um zu zeigen, daß objektorientierte Modellierung sich nicht an Echtwelt-Objekten festklammern soll, sondern daß sie lediglich ein Ausdrucksmittel ist, um gewisse Vorteile im Code zu erzielen. Beispielsweise Dispatching oder gemeinsame Nutzung von Codestücken. Und anhand dieser Kriterien muß man objektorientiert modellieren. Nicht naiv anhand irgendwelche ge-brainstormter Substantive.
Alex schrieb: > Ist ok. > Der Aufwand die Statemaschiene und ihre Möglichkeiten zu erklären ist > mir jetzt zu groß. > Aber es ist nicht einfach nur eine Zeile Code. Sondern so ~600 min > schätz ich mal. Ich verstehs immer noch nicht. Wenn der ursprüngliche Klassenansatz einigermassen Sinn machte, dann ist es normalerweise einfach, die Klassenhierarchie etwas anzupassen, ohne dass es exorbitant viele tatsächliche Codeänderungen gibt. Aber seis drum. Unter deinen Voraussetzungen sehe ich nicht wirklich da jetzt ein großes Problem (wohl aber eines, das eines Tages kommen könnte, wenn sich die Anforderungen an die Klasse verändern). Wie auch immer. Es scheint wohl so zu sein, dass sich deine ursprüngliche Fragestellung damit lösen lässt, das du die CRC Tabelle als static Member in der CRC Klasse gestaltest. Das wiederrum ist etwas, was auf jeden Fall sinnvoll ist, egal wie der restliche Aufbau aussieht.
Fred schrieb: > Kanonisches Gegenbeispiel: Ein Kreis ist eine Ellipse. Nur neugierdehalber: was ist daran falsch? hab ich in Geometrie was verpasst?
Fred schrieb: > cyblord ---- schrieb: >> Das Kreis-Ellipse Problem ist ein klassisches Beispiel um gegen OOP zu >> hetzen. > > Keineswegs. Es ist ein klassisches Beispiel, um zu zeigen, daß > objektorientierte Modellierung sich nicht an Echtwelt-Objekten > festklammern soll, sondern daß sie lediglich ein Ausdrucksmittel ist, um > gewisse Vorteile im Code zu erzielen. Beispielsweise Dispatching oder > gemeinsame Nutzung von Codestücken. Da hast du recht. Nur wird es von gewissen Kreise gerne zum hetzen benutzt. Lehrreich ist es auf jeden Fall. > Nur neugierdehalber: was ist daran falsch? hab ich in Geometrie was > verpasst? Wenn du als Klasse einen Kreis nimmst, mit einem Feld, dem Radius, und dann eine Klasse Ellipse machst, die vom Kreis erbt, bringt ihr das Radius-Feld gar nichts. Weil eine Ellipse Breite und Höhe braucht. Andersrum ebenfalls. Somit klappt hier der OOP-Ansatz nicht. Obwohl, rein geometrisch, der Kreis nur eine Sonderform der Ellipse ist.
:
Bearbeitet durch User
Michael Reinelt schrieb: > Fred schrieb: >> Kanonisches Gegenbeispiel: Ein Kreis ist eine Ellipse. > > Nur neugierdehalber: was ist daran falsch? hab ich in Geometrie was > verpasst? Er stört sich daran, dass einem blindes Gehorchen von Richtlinien, die explizit als 'Faustregeln' und 'erste Näherungen' bezeichnet wurden, zu ...
1 | class Ellipse : public Geometry |
2 | {
|
3 | ...
|
4 | };
|
5 | |
6 | class Circle : public Ellipse |
7 | {
|
8 | ...
|
9 | };
|
... führt. Wer das schon mal in einem Geometrie Programm probiert hat, wird festgestellt haben, dass er sich damit eine Menge Probleme aufhalst. Denn je nach Verändern der Parameter 'Länge der Halbachsen' wird dann plötzlich aus dem einen Objekttyp ein anderer Objekttyp. Genauso wie zb ein Quadrat nicht wirklich als Sonderform eines Rechtecks in der Klassenhierarchie modelliert wird, obwohl umgangssprachlich ein Quadrat eine Sonderform eines Rechtecks IST. Wie er sagt: "wer naiv ..." Und genau da liegt der springende Punkt. Wer naiv seinem Guru hinterher läuft und seine Regeln ohne zu hinterfragen akzeptiert, der ist Priester und kein Informatiker. Das bedeutet aber noch lange nicht, dass diese Faustregeln generell zu nichts nütze wären. Man muss einfach nur akzeptieren, dass sie einen in manchen Fällen auch in die Irre führen. 'One size fits all' funktioniert bei Baseballkappen, aber nicht in der Programmentwicklung. Und das ist gut so, denn sonst wär ich arbeitslos. :-)
:
Bearbeitet durch User
Karl Heinz schrieb: > Wie er sagt: "wer naiv ..." > Und genau da liegt der springende Punkt. Wer naiv seinem Guru hinterher > läuft und seine Regeln ohne zu hinterfragen akzeptiert, der ist Priester > und kein INformatiker. Daher heißen die ja auch "FSF-Jünger". Übrigens, KHB du wirkst ein bisschen gereizt. Ich denke jedem hier ist klar, was du meinst. Ich habe nur nach der "provokanten Frage" von Fred, angefügt dass diese oftmals zum hetzen missbraucht wird. Mehr wurde nicht gesagt. Also komm mal wieder runter...
cyblord ---- schrieb: >> Nur neugierdehalber: was ist daran falsch? hab ich in Geometrie was >> verpasst? > > Wenn du als Klasse einen Kreis nimmst, mit einem Feld, dem Radius, und > dann eine Klasse Ellipse machst, die vom Kreis erbt, bringt ihr das > Radius-Feld gar nichts. Logisch weil eine Ellipse auch nicht eine Sonderform des Kreises ist, sondern umgekehrt. > Andersrum ebenfalls. Somit klappt hier der OOP-Ansatz nicht. Obwohl, > rein geometrisch, der Kreis nur eine Sonderform der Ellipse ist. Warum nicht? (vielleicht dämliche Frage, aber ich bin in OOP nicht so tief drinnen). Ich müsste ja nur die beiden Achsen "verstecken" ein neues Attribut "Radius" (oder von mir aus Druchmesser) einführen und Breite/Höhe auf den Radius setzen. Dann kann ich alle möglichen und unmöglichen Berechnungen der Ellipse 1:1 für den Kreis durchführen (auch wenn das performancemäßig nicht ganz optimal sein wird)
cyblord ---- schrieb: > Übrigens, KHB du wirkst ein bisschen gereizt. Ich denke jedem hier ist > klar, was du meinst. Dann frage ich mich, was dieser Zwischenruf überhaupt sollte. Wenn ich diese Regeln als unumstössliche Wahrheiten dargestellt hätte, wäre es ok gewesen. Aber genau das hab ich nicht getan. Ganz im Gegenteil hatte ich sehr darauf geachtet, das als Leitlinie darzustellen. Aber egal was ich sage, immer kommt jemand daher, der einem das Wort im Mund umdreht.
Michael Reinelt schrieb: >> Andersrum ebenfalls. Somit klappt hier der OOP-Ansatz nicht. Obwohl, >> rein geometrisch, der Kreis nur eine Sonderform der Ellipse ist. > Warum nicht? (vielleicht dämliche Frage, aber ich bin in OOP nicht so > tief drinnen). Ist ok. Machen kannst du es. Das Problem kommt, wenn du dann mit den Objekten auch Operationen machen willst. Zum Beispiel die Operation "Skalieren". Was bei anderen Objekttypen problemlos klappt, wird hier zu einem Problem. Durch eine Skalieroperation wird aus einem Kreis eine Ellipse. Bzw. auch umgekehrt kann mit der richtigen Skalieroperation aus einer Ellipse ein Kreis werden. Wie aber gestaltest du das als Memberfunktion? Und zwar möglichst so, dass du in der darunter liegenden Basisklasse (Geometrie-Dings) eine virtuelle Scale Funktion hast von der alle abgeleiteten Klassen erben?
:
Bearbeitet durch User
Karl Heinz schrieb: > Was bei anderen Objekttypen problemlos klappt, wird hier zu einem > Problem. Durch eine Skalieroperation wird aus einem Kreis eine Ellipse. Nicht wenn du für einen Kreis die Skalierfunktion überschreibst daß sie beie Achsen gleichzeitig skalierst. Genauso kannst du die Setter überschreiben, daß sie beim setzen von r1 auch r2 auf den gleichen Wert setzen. Es ist wie du richtig sagst, man muss eben das Hirn benutzen.
Karl Heinz schrieb: [Kreis <=> Ellips] > Machen kannst du es. Das Problem kommt, wenn du dann mit den Objekten > auch Operationen machen willst. > Zum Beispiel die Operation "Skalieren". Guter Einwand! Extrem guter Einwand! Muss ich mir merken! Erinnert mich frappant an meine CAD-Zeit. Als der Kunde Kreise schräggestellt haben wollte. Aber mit der Einschränkung, dass es Kreise bleiben müssten. Weil seine CNC-Maschine (Drahterodieren) nur Kreise könne... Ach, was bin ich froh dass diese zeit vorbei ist :-)
Karl Heinz schrieb: > eine virtuelle Scale Funktion Eben die ist virtuell, weil sie bei unterschiedlichen abgeleiteten Klassen unterschiedlich ausgeprägt sein kann. Alternativ ist sie nicht virtuell, weil für viele abgeleitete Klassen genügend, aber bestimmte müssen sie trotzdem überschreiben. Beispiel Fahrzeug, abgeleitet Auto und Motorrad. Sowohl bremsen, als auch kuppeln als auch Gas geben ist bei beiden völlig unterschiedlich implementiert.
Udo Schmitt schrieb: > Karl Heinz schrieb: >> Was bei anderen Objekttypen problemlos klappt, wird hier zu einem >> Problem. Durch eine Skalieroperation wird aus einem Kreis eine Ellipse. > > Nicht wenn du für einen Kreis die Skalierfunktion überschreibst daß sie > beie Achsen gleichzeitig skalierst. > Genauso kannst du die Setter überschreiben, daß sie beim setzen von r1 > auch r2 auf den gleichen Wert setzen. > > Es ist wie du richtig sagst, man muss eben das Hirn benutzen. Natürlich geht das, aber wenn du am Ende ALLES überschreiben musst, und für alles ne Extrawurst brauchst, wozu dann noch die Vererbung. Dann sparst du keine Zeile Code und das ganze ist ad absurdum geführt. Das ist der Punkt hinter dieser Sache. Aber nochmal, der Einwand war nicht gegen deinen Post gerichtet, Karl-Heinz. Es war nur eine Info am Rande. gruß cyblord
:
Bearbeitet durch User
Karl Heinz schrieb: > Dann frage ich mich, was dieser Zwischenruf überhaupt sollte. Weil hier nicht nur wir beide reden, sondern wie gesehen auch Leute, die das Kreis-Ellipse-problem noch gar nicht kannten. Und wer davon noch nie gehört hat, der tappt mit p>95% irgendwann in diese Problematik. Was ist nun also dein Problem? Niemand hat dich persönlich angegriffen, niemand hat deiner Erklärung widersprochen. Aber trotzdem bist du furchtbar unentspannt.
cyblord ---- schrieb: > Natürlich geht das, aber wenn du am Ende ALLES überschreiben musst, und > für alles ne Extrawurst brauchst, wozu dann noch die Vererbung. Dann > sparst du keine Zeile Code und das ganze ist ad absurdum geführt. Das ist so nicht richtig. Beispiel Fahrzeug. Du hast entweder ein Motorrad oder ein Auto instanziiert. Es macht trotzdem Sinn beide vom Fahrzeug abzuleiten (oder ein Interface Fahrzeug zu benutzen) denn dann kannst du beide als Fahrzeug an eine Methode fahren einer Klasse Fahrer übergeben, und die Methode benutzt nur Gas geben, Bremsen und lenken, ohne sich um die Implementirung scheren zu müssen. OO ist deutlich mehr als nur Code Zeilen sparen.
Udo Schmitt schrieb: > Beispiel Fahrzeug, abgeleitet Auto und Motorrad. Sowohl bremsen, als > auch kuppeln als auch Gas geben ist bei beiden völlig unterschiedlich > implementiert. Schon richtig. Aber nach dem Bremsen ist ein Motorrad immer noch ein Motorrad. > Nicht wenn du für einen Kreis die Skalierfunktion überschreibst > daß sie beie Achsen gleichzeitig skalierst. Ich hatte das eher so gemeint, dass man einen Kreis nur in einer Richtung skaliert :-) Eine Operation, die ein CAD ja können muss. Befüllst du aber eine Liste mit Objekten
1 | content.add( new Circle( point, radius ) ); |
und wendest du auf die selektierten Objekte die Operation an
1 | foreach( Geometry* obj, selectedContent ) |
2 | obj->scale( x_factor, 0.0 ); |
dann hast du den 'unschönen' Zustand, einen Kreis in der Datenbasis zu haben, der in Wirklichkeit gar kein Kreis mehr ist.
:
Bearbeitet durch User
Udo, ich brauche keine Belehrung über die Grundlagen von OOP. Ich habe bereits mein Info-Diplom. Lies bitte hier nochmal genau nach, wenn du den Punkt nicht verstehst: http://de.wikipedia.org/wiki/Kreis-Ellipse-Problem @Fred: Du bringst es auf den Punkt!
Fuer eine serielle schnittstelle sollte man sich ueberlegen ob man den tabellenbasierten CRC Ansatz oder den auscodierten Shift-XOR Ansatz verfolgen will. Ich habe den auscodierten Shift-XOR Ansatz in Verwendung. Er benoetigt in deer Groessenordnung von 15 Zeilen. Den tabellenbasierten Ansatz habe ich auch verwendet, und der ist ohne die effektive Tabelle auch um die 15 Zeilen.
Sorry, ich verwende den CRC16. Wie gross auch immer der unterschied in code ist.
Karl Heinz schrieb: > Ich hatte das eher so gemeint, dass man einen Kreis nur in einer > Richtung skaliert :-) Eine Operation, die ein CAD ja können muss. Ok, zeigt wieder das Denken nimmt einem keiner ab :-) Im gegenteil, je mächtiger das Tool (OOP) desto mehr unterschiedliche Wege führen nach Rom, und nicht alle sind immer sinnvoll. Karl Heinz schrieb: > Schon richtig. > Aber nach dem Bremsen ist ein Motorrad immer noch ein Motorrad. Wie gesagt, man müsste dann halt alle Operationen so überschreiben daß es nicht dazu kommen kann daß r1 und r2 unterschiedlich sind. Ob das dann noch eine gute und sinnvolle Implementierung ist, ist eine andere Frage...
> Nicht wenn du für einen Kreis die Skalierfunktion überschreibst > daß sie beie Achsen gleichzeitig skalierst. Im Wiki-Artikel wird darauf ebenfalls eingegangen. Das ist nicht erlaubt bzw. nicht zu empfehlen. Weil es sich im Verhalten ggü. einer Ellipse extrem unterscheidet und das so vom Nutzer nicht vorrausgesehen werden kann. Siehe auch: http://de.wikipedia.org/wiki/Liskovsches_Substitutionsprinzip
cyblord ---- schrieb: > @Fred: > Du bringst es auf den Punkt! Dabei bist jetzt du unentspannt: cyblord ---- schrieb: > Udo, ich brauche keine Belehrung über die Grundlagen von OOP. Ich habe > bereits mein Info-Diplom. Warum hast du dann alles auf Code Ersparnis reduziert? Egal, wenns jetzt darum geht wer was für einen Abschluss hat bin ich raus :-)
cyblord ---- schrieb: >> Nicht wenn du für einen Kreis die Skalierfunktion überschreibst >> daß sie beie Achsen gleichzeitig skalierst. > > Im Wiki-Artikel wird darauf ebenfalls eingegangen. Das ist nicht erlaubt > bzw. nicht zu empfehlen. Weil es sich im Verhalten ggü. einer Ellipse > extrem unterscheidet und das so vom Nutzer nicht vorrausgesehen werden > kann. Yep. Man könnte natürlich von einem menschlichen Benutzer verlangen, dass er zunächst den Sonderfall 'Kreis' in eine 'Ellipse' umwandelt und erst dann die Operation durchführt. Tut er das nicht, dann geht die Operation schief. Allerdings, was ein menschlicher Benutzer, der vor dem Bildschirm sitzt, gerade noch akzeptiert ist eine Sache. Was man dann in einem Batchbetrieb macht, wenn 300 CAD-Zeichnungen durch einen Prozessor laufen ist eine andere Sache. Letzten Endes muss man immer im Einzelfall anhand der konkreten Situation entscheiden, was man tut.
Udo Schmitt schrieb: > Warum hast du dann alles auf Code Ersparnis reduziert? Hab ich nicht. Es geht nicht um die Ersparnis selbst. Sondern um Extrawürste für spezielle Unterobjekte, was man eben so nicht haben will. z.B. dass sich die Breite ändern, wenn ich eine Methode zum ändern der Höhe aufrufe. Wenn du Vererbung betreibst und keinen Code einsparen kannst, dann ist das ein sicheres Zeichen dass was schief läuft. Es ist ein Symptom. > Egal, wenns jetzt darum geht wer was für einen Abschluss hat bin ich > raus :-) Darum gehts nicht, aber wir brauchen doch bei einem bekannen Informatik-Problem nicht bei Adam und Eva anfangen zu diskutieren was Vererbung ist und wozu man sie braucht. gruß cyblord
cyblord ---- schrieb: > Wenn du Vererbung betreibst und keinen Code einsparen kannst, dann ist > das ein sicheres Zeichen dass was schief läuft. Es ist ein Symptom. Auch da kann ich jetzt nicht einfach zustimmen, du kannst immer noch den Code für eine Zeichenroutine einsparen, oder den Code um ein umfassendes Rechteck zu berechnen. Und wir sind uns einig, daß man immer noch Brain2.0 benutzen muss und es dafür keinen Königsweg gibt und man manchmal dann statt Vererbung gleichwertige Klassen die aus einer Basisklasse erben nutzen sollte. Und ich habe gelernt, daß das Rechteck/Quadrat Ellips/Kreis Problem ein vielfach akademisch diskutiertes Problem ist, das wusste ich noch nicht.
:
Bearbeitet durch User
Udo Schmitt schrieb: > Und ich habe gelernt, daß das Rechteck/Quadrat Ellips/Kreis Problem ein > vielfach akademisch diskutiertes Problem ist, das wusste ich noch nicht. Dem schließe ich mich an, danke!
Udo Schmitt schrieb: > cyblord ---- schrieb: >> Wenn du Vererbung betreibst und keinen Code einsparen kannst, dann ist >> das ein sicheres Zeichen dass was schief läuft. Es ist ein Symptom. > > Auch da kann ich jetzt nicht einfach zustimmen, du kannst immer noch den > Code für eine Zeichenroutine einsparen, oder den Code um ein umfassendes > Rechteck zu berechnen. Ach, da geht noch viel mehr. Gerade beim Ellipsen-Kreis Problem ist das ja symptomatisch. Den Umfang eines Kreises zu berechnen ist trivial. Den Umfang einer Ellipse zu berechnen ist in geschlossener Form gar nicht möglich. Die dabei anfallenden Integrale sind formelmässig nicht lösbar und hab in der Mathematik zu einer ganzen Klasse geführt, die man 'elliptische Integrale' nennt. Selbiges mit der Fläche. Unter anderem deshalb ist es ja so verführerisch eine Klasse Kreis von einer Klasse Ellipse herzuleiten um den Trivialfall vom allgmeinen Fall zu trennen.
Alex schrieb: > Hab habe eine Crc8 Klasse die ich an mehrere Klassen vererbe (Uart1, 2, > I2C usw.) Bist du sicher, daß du die Klasse wirklich vererbst? > In der Crc8 Klasse wird bei jeder Vererbung jedes Mal die gleiche > Tabelle von 256Byte angelegt. Das würde bei einer tatsächlichen Vererbung nämlich nicht passieren. > Wird eine Klasse instanziiert die die crc8 Tabelle anlegt, überspringen > die folgenden Klassen das Anlegen der crc8 Tabelle benutzen die bereits > angelegte Tabelle. Wußte ich's doch, es geht überhaupt nicht um Vererbung, sondern um Instanziierung. Das Problem besteht also auch schon, wenn du mehrere Instanzen der ursprünglichen CRC-Klasse erzeugst, nicht wahr? Die Lösung ist, die CRC-Tabelle nicht als Teil einer Instanz zu erzeugen, sondern als Teil einer Klasse, das entsprechende Zauberwort für C++ heißt, glaube ich, "static". Alle Erben dieser Klasse und sämtliche Instanzen der ursprünglichen Klasse und auch aller ihrer Erben besitzen dann automatisch Zugriff auf physisch ein- und dasselbe "Objekt", es verbraucht also nur einmal Speicher. Du solltest dir mal die Grundlagen der OO-Programmierung reinziehen...
Wir sind hier bei Microcontroller & Digitale Elektronik, und da ist eine solche Tabelle Code, nicht Daten.
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.