if(P2IES&&0x02==T_SET)// Wenn T_SET in P1IES == 1 ist, negative Flanke
9
{
10
INIT_TA2();// aktiviere 2s-Timer
11
P2IES&=~(T_SET);// Int. bei positiver Flanke
12
13
}
14
15
else
16
{
17
TA2CTL=0x00;// Timer Stopp
18
P2IES|=T_SET;// Zurück auf negative Flanke
19
TX_String("Zu kurz gedrueckt\n");
20
}
21
22
P2IFG&=~(T_SET);// Flanken Ereignis löschen
23
}
24
}
25
26
27
28
voidINIT_TA2(void)
29
{
30
TA2CTL=TACLR;// Timer-Counter RESET auf Null
31
TA2CCR0=65535;// 2s
32
TA2CCTL0=CCIE;// Interrupt bei TA2CCR0
33
TA2CTL=TASSEL_1+ID_0+MC_1;// ACLKK, 1:1, UP-Mode
34
}
35
36
37
38
39
#pragma vector=TIMER2_A0_VECTOR
40
__interruptvoidTA2_0_ISR()
41
{
42
P2IES|=T_SET;// Zurück auf negative Flanke
43
44
if(Saegezahn==1)
45
{
46
Saegezahn=0;
47
//Wobbel_Dir = 1;
48
TX_String("\nSignal Sinusfoermig\n");
49
}
50
else
51
{
52
Saegezahn=1;
53
// Wobbel_Dir = 1;
54
TX_String("\nSignal Saegezahn\n");
55
}
56
Wobbel_Dir=1;
57
i=3;
58
TB0CCR0=Freq[i];
59
TB0CCR2=PBreite[i];
60
61
TA2CTL=0x00;
62
P2IFG&=~(T_SET);
63
}
Wenn ich den Taster 2sec drücke, sollte sich die Siganlform ändern. Tut
sie auch. Aber "manchmal" (wähle den Begriff bewusst, denn dieses
Verhalten tritt eben nur manchmal auf) springt er wieder zurück, als
hätte er zweimal den Modus gewechslet, sodass der ursprüngliche Modus
eingestellt ist.
Für Hilfe wäre ich dankbar
lukker schrieb:> wenn ihr noch Informationen braucht, einfach melden
Da es ja nur einen Controller auf der ganzen Welt gibt brauchst
du diesen natürlich nicht angeben, ebensowenig wie einen
Schaltplan.
Meistens können wir uns ja alle fehlenden Informationen durch
unsere Glaskugel herbeischaffen.
Also alles gut.
Irgendwelche Funktionen (die womöglich auch noch auf irgendwas warten)
in einer ISR aufzurufen, gehört verboten!
ISR sollen so kurz wie möglich und so lang wie nötig sein.
Ein Taster prellt im Millsekunden-Bereich. Das kann man hin und wieder
mal abfragen, muss aber nicht mit einem Interrupt darauf reagieren.
STK500-Besitzer schrieb:> Taster per Interrupt abfragen? Nö!>> lukker schrieb: __interrupt void P2_ISR()> {> Entprell();>
Hab ich auch gleich gedacht. Entprellen in einer Interrupt-Funktion?
Da würde ich doch lieber den Taster in einer Timer-Funktion abfragen.
Und wenn der N Zyklen aktiv ist, dann ist er wirklich
gedrückt/losgelassen.
jo mei schrieb:> Da es ja nur einen Controller auf der ganzen Welt gibt brauchst> du diesen natürlich nicht angeben, ebensowenig wie einen> Schaltplan.>> Meistens können wir uns ja alle fehlenden Informationen durch> unsere Glaskugel herbeischaffen.>> Also alles gut.
MSP 430F5529
Ich kann mich meinem Vorredner nur anschließen. Um den Taster zu lesen
gibt es eigentlich nur zwei saubere Methoden:
- Ein RC-Glied mit anschließendem Schmitt Trigger
- Per Timerinterrupt den Zustand des Tasters fortlaufen in ein Array
schreiben und nur dann reagieren, wenn sich eine entsprechende Anzahl
Werte nicht geändert hat.
STK500-Besitzer schrieb:> Irgendwelche Funktionen (die womöglich auch noch auf irgendwas warten)> in einer ISR aufzurufen, gehört verboten!> ISR sollen so kurz wie möglich und so lang wie nötig sein.> Ein Taster prellt im Millsekunden-Bereich. Das kann man hin und wieder> mal abfragen, muss aber nicht mit einem Interrupt darauf reagieren.PittyJ schrieb:> Hab ich auch gleich gedacht. Entprellen in einer Interrupt-Funktion?> Da würde ich doch lieber den Taster in einer Timer-Funktion abfragen.> Und wenn der N Zyklen aktiv ist, dann ist er wirklich> gedrückt/losgelassen.
ich habe den Hinweis schon einmal bekommen. aber für jemanden wie mich,
der kaum Programmieren kann, ist es die einfachste Möglichkeit die ganze
Sache zu realisieren. Außerdem erfüllt es doch in dem einen, konkrekten,
einfachen Fall seinen Zweck. Und deswegen würde ich gerne in dem einen
konkreten, einfachen, Fall die Diskussion beiseite lassen. Grundsätzlich
habt ihr Recht.
Aber das ändert ja auch nichts an meiner eign Problematik
Stefan A. schrieb:> - Per Timerinterrupt den Zustand des Tasters fortlaufen in ein Array> schreiben und nur dann reagieren, wenn sich eine entsprechende Anzahl> Werte nicht geändert hat.
Wozu in ein Array schreiben?
Wenn sich der Zustand am Eingang geändert hat, wird ein Zähler
zurückgesetzt.
Wenn der Zähler abgelaufen ist, ist der Taster-Zustand stabil.
Dafür braucht man nur einen Zähler...
lukker schrieb:> Außerdem erfüllt es doch in dem einen, konkrekten,> einfachen Fall seinen Zweck.
Offensichtlich ja nicht, da es zu einem Fehlverhalten kommt.
> Und deswegen würde ich gerne in dem einen> konkreten, einfachen, Fall die Diskussion beiseite lassen.> Grundsätzlich habt ihr Recht.
Ja, natürlich haben wir Recht.
Warum machst du es dann so, wie alle Anfänger, die komischerweise immer
wieder an genau diesem Vorgehen scheitern?
Aufgrund deines beschränkten Codes (der Rest scheint ja geheim zu sein),
kann man das nicht mal ausprobieren.
STK500-Besitzer schrieb:> Aufgrund deines beschränkten Codes (der Rest scheint ja geheim zu sein),> kann man das nicht mal ausprobieren.
hier code plus asm datei für strings.
STK500-Besitzer schrieb:> Offensichtlich ja nicht, da es zu einem Fehlverhalten kommt.
ich verstehe aber nicht warum. oder zumindest den Zusammenhang, mit dem
was ihr genannt habt.
das eign programm ist nochmal um einige Ecken größer, aber die testdatei
(das im Anhang) reagiert wie die große Datei. Mit der Testdatei probiere
ich schon seit einigen Tagen rum
warte...ich habe auch ein Gegenargument
STK500-Besitzer schrieb:>> Außerdem erfüllt es doch in dem einen, konkrekten,>> einfachen Fall seinen Zweck.> Offensichtlich ja nicht, da es zu einem Fehlverhalten kommt.
in der Datei im anhang ist das vollständige Programm. den Taster T_ONOFF
habe ich auch per Interrupt gesteuert. Und der zeigt dieses Verhalten
nicht.
lukker schrieb:> if(P2IFG & T_SET) // Wenn Int. von T_SET, dann> {> if(P2IES && 0x02 == T_SET)
Du magst mal den Unterschied von binaeren und logischen Operatoren
nachschlagen. BTW der Mix von deutschen und englischen Variablennamen
sowie Gross- und Kleinschreibung verbessert die Lesbarkeit deines
Programmes nicht, eher im Gegenteil.
leo
Hugo H. schrieb:> Wie oft denn noch ? :-)
so oft bis es klappt =)
leo schrieb:> Du magst mal den Unterschied von binaeren und logischen Operatoren> nachschlagen.
wo steckt der Fehler in der Logik?
lukker schrieb:> so oft bis es klappt =)
Ok, nimm die Verzögerung aus der ISR!
Ok, nimm die Verzögerung aus der ISR!
Ok, nimm die Verzögerung aus der ISR!
Ok, nimm die Verzögerung aus der ISR!
Ok, nimm die Verzögerung aus der ISR!
Ok, nimm die Verzögerung aus der ISR!
Ok, nimm die Verzögerung aus der ISR!
...
MaWin schrieb:> k, nimm die Verzögerung aus der ISR!> Ok, nimm die Verzögerung aus der ISR!> Ok, nimm die Verzögerung aus der ISR!> Ok, nimm die Verzögerung aus der ISR!> Ok, nimm die Verzögerung aus der ISR!> Ok, nimm die Verzögerung aus der ISR!> Ok, nimm die Verzögerung aus der ISR!
aber was ändert das an meinem Problem?
lukker schrieb:> aber was ändert das an meinem Problem?
Was passiert, wenn ein neuer Interrupt ansteht, während du in der (ISR)
Schleife die Rechenzeit vergeudest?
die Diskussion ist für mich so:
" du scheiße prgrammiert"
"ich weiß, aber was ist mit der anderen Sache"
"übrigens. du hast scheiße programmiert"
usw....
lukker schrieb:> ich möchte die> Aufmerksamkeit auf etwas anderes richten
Vorm Lackieren muss der Rost entfernt werden!
lukker schrieb:> Mir ist so echt nicht geholfen
Doch, wenn du
Ok, nimm die Verzögerung aus der ISR!
MaWin schrieb:> lukker schrieb:>> ich möchte die>> Aufmerksamkeit auf etwas anderes richten>> Vorm Lackieren muss der Rost entfernt werden!>> lukker schrieb:>> Mir ist so echt nicht geholfen>> Doch, wenn du> Ok, nimm die Verzögerung aus der ISR!
wie ein schwachsinniger...
leo schrieb:> lukker schrieb:>> die Diskussion ist für mich so:>> " du scheiße prgrammiert">> Genau. Was ist nun mit dem '&&'?>> leo
und du leo, denk mal nach bevor du hier irgendwas reinschreibst. Echt
peinlich soetwas. hat alles seine richtigkeit
Pack Dich mal an der eigenen Nase.
Du bestehst auf einer nachgewiesenermaßen nicht funktionierenden Lösung,
willst sie irgendwie verbessert haben.
Dir wird freundlich dargelegt, dass Du eine Sackgasse beschritten hast.
Dir wird ein Weg aufgezeigt.
Du bestehst weiterhin auf einer nachgewiesenermaßen nicht
funktionierenden Lösung, willst sie irgendwie verbessert haben.
Deinen Programmiercode verbessert aber niemand. Wozu auch, ist ne
Sackgasse.
Nun fängst Du an beleidigend zu werden.
Starke Vorstellung.
Wenn Du das Forum hier länger verfolgst, so siehst Du, dies Muster gibts
immer wieder.
Am Schluß der Diskussion wirds dann heftig.
Warum willst Du nicht einsehen, das Dein Weg eine falsche Fährte ist?
Noch dazu, da Du einräumst schlecht programmieren zu können. Wäre nicht
grad dann geboten Ratschläge anzunehmen und Deinen Programmierstil zu
verbessern?
Die Chips hol ich mir immer schon, wenn Encoder oder Taster in ISR
abgefragt werden.
Es ist so vorhersehbar was passiert. Hab in der Vergangenheit von
niemanden gelesen, der einsichtig wurde. Alle haben bis aufs Messer ihre
Lösung verteidigt. Sie muß ja funktionieren. Auch wenn sie es nicht
richtig, nicht immer oder nicht immer richtig getan hat.
Warum glaubt jeder Anfänger er ist unfehlbar?
schwachsinnig schrieb:> Warum willst Du nicht einsehen, das Dein Weg eine falsche Fährte ist?
sehe ich doch ein. wie schwer ist es, meinen Standpunkt
nachzuvollziehen...??
Arduino Fanboy D. schrieb:> [OT]>> Ein witziger Thread...> Ich gehe mal Chips holen.>> [/OT]
freud mich, dass wenigstens einer von der Sache hier partizipiert :P
und nochmal: ich kann 1000 verschiedene Lösungswege verfolgen, mein
Beitrag zielt aber darauf ab, den fehler ( und damit ist nicht die
Abfrage des Tasters über ISR gemeint) zu finden
schwachsinnig schrieb:> Warum glaubt jeder Anfänger er ist unfehlbar?
glaubt niemand. aber genausowenig hat irgendjemand von eucht interesse,
mal ernstahft auf meine Frage einzugehen. Danke für nichts
STK500-Besitzer schrieb:> Ja, natürlich haben wir Recht.> Warum machst du es dann so, wie alle Anfänger, die komischerweise immer> wieder an genau diesem Vorgehen scheitern?>> Aufgrund deines beschränkten Codes (der Rest scheint ja geheim zu sein),> kann man das nicht mal ausprobieren.
habe immernoch Hoffnung, dass STK500 sich meldet....
lukker schrieb:> Arduino Fanboy D. schrieb:>> [OT]>>>> Ein witziger Thread...>> Ich gehe mal Chips holen.>>>> [/OT]>> freud mich, dass wenigstens einer von der Sache hier partizipiert :P
Ich kann dir vielleicht sogar einen Tipp geben...
Leider kenne ich deinen Kompiler nicht.
In meiner kleinen Arduinowelt würde die Funktion Entprellen() ratzekahl
weg optimiert werden.
Auch solltest du den Fehler mit dem && ausmerzen.
Arduino Fanboy D. schrieb:> Auch solltest du den Fehler mit dem && ausmerzen.
also erstens: ich habe die Logik dahinter verstanden, die Wenigstens tun
das
zweitens: mei8n programm funktioniert
lukker schrieb:> ich hoffe einfach mal das es ein Scherz ist, um mich zu provozieren...
Nein, das ist durchaus Ernst gemeint. Lesen und verstehen.
lukker schrieb:> zweitens: mei8n programm funktioniert
OK, und was war jetzt Deine Frage?
Ich hole mir jetzt nur noch Popkorn. Ansonsten schaue ich nur noch zu.
lukker schrieb:> ich möchte die Aufmerksamkeit auf etwas anderes richten.
Du möchtest uns dazu bringen, den gleichen Fehler zu begehen, den du die
ganze Zeit begehst:
Die offensichtlichen Fehler nicht angehen, fest darauf beharren,
bestimmte Teile richtig gemacht zu haben, und dann auf entsprechende
Ratschläge nicht mehr einzugehen.
Deine Herangehensweise ist immer noch dein größter Feind. Der Fehler
sitzt zu 99,99% vor dem Bildschirm. Schau mal in einen Spiegel, wer das
ist!
So wird es auch im dritten Anlauf wieder nichts.
> if(P2IES && 0x02 == T_SET)
T_SET hat den Wert 0x02. Der Ausdruck ist daher immer wahr. Beschäftige
dich mit der Rangfolge von Operatoren.
Damit der Ausdruck nicht nur richtig sondern auch lesbar wird, würde ich
auf magische Zahlen-Konstanten verzichten und schreiben:
> if (P2IES & T_SET)
Was deine Tastenabfrage im Interrupt angeht: Da wird Dir kein erfahrener
Programmierer Helfen, weil das eine Sackgasse ist. Wenn dien aktuelles
Problem gelöst ist, wird das nächste kommen, und dann noch ein und noch
ein. Du wirst immer wieder um Hilfe bitten.
Am Wende hast du dann mit Hilfe von Fachleiten einen Scheiß hin
gefrickelt, für den sich alle beteiligten nur schämen können. Wer will
das schon Also helfen wir lieber nicht dabei, in diese Sackgasse zu
fahren.
Stefan ⛄ F. schrieb:> Also helfen wir lieber nicht dabei, in diese Sackgasse zu> fahren.
Daß Du da überhaupt noch hilfst bei diesen Unverschämtheiten die sich
der TO hier geleistet hat. Da bleibt einem ja das Popkorn im Halse
stecken.
Stefan ⛄ F. schrieb:> Also helfen wir lieber nicht dabei, in diese Sackgasse zu> fahren.
Hör Dir das "Geschwätz" :-) nicht an - Vollgas! Irgendwo wird sich schon
eine Lücke auftun.
Stefan ⛄ F. schrieb:> Ein bisschen aufgewühlt bin ich schon
Cool down! Popkorn holen und mitlesen. Der TO kommt schon noch. Wir
werden noch eine Weile unseren Spaß haben.
lukker schrieb:> also erstens: ich habe die Logik dahinter verstanden, die Wenigstens tun> das> zweitens: mei8n programm funktioniert
Oh mein Gott! Da die Priorität von == über der von && liegt, wird zuerst
der Teilausdruck
1
0x02==T_SET
ausgewertet.
Wg.
1
#define T_SET 0x02
ist der Teilausdruck stets wahr. Es bleibt übrig:
1
if(P2IES&&1)
was zu
1
if(P2IES)
vereinfacht wird.
Ich habe selten so genialen Code gesehen :-)
Grüßle
Volker
P.S. Übrigens ist die Prio von == auch höher als die des &, so dass
sogar im K&R explizit empfohlen wird beim Ausmaskieren von Bits mittels
&-Operator explizit zu klammern.
Ich mach Bubu -was machst Du schrieb im Beitrag #6217652:
> Dort> wird genau das ausgeführt, was Du schreibst, nicht, was der Compiler> meint, wegoptimieren zu können.
Wie?
Bascom ist nicht in der Lage, die einfachsten Dinge zu optimieren?
Igitt!
was macht eigentlich
TX_String("\nCCR2\n");
Uart Ausgabe?
So etwas versuche ich, nicht in einen ISR zu packen.
Für mich muss eine ISR möglich kurz und schnell sein. Meist wird da nur
ein Flag getoggelt, ober ein Zähler hochgesetzt.
Alles andere läuft in zyklischen Normal-Tasks ab.
Insbesondere wenn der TX_String auch noch einen Interrupt wirft, weil
ein Fifo über/unterläuft wird es lustig.
Mit diesen kurzen ISRs bin ich die letzten 10 Jahre gut gefahren.
lukker schrieb:> ich habs schon verstanden! lies mal nitte weiter oben! ich möchte> die Aufmerksamkeit auf etwas anderes richten. Mir ist so echt nicht> geholfen
Dann poste doch endlich den gesamten scheiss sourcecode und Foto vom
Aufbau
PittyJ schrieb:> Mit diesen kurzen ISRs bin ich die letzten 10 Jahre gut gefahren.
Nicht nur du....
Aber dennoch macht es manchmal Sinn dort komplexere Automaten
abzuhandeln.
Aber Wartezeiten, auch, oder gerade, zum entprellen, das erscheint auch
mir einfach nur eine dumme Idee zu sein.
lukker schrieb:> Entprell();
Du kannst eine Delayschleife noch so oft "Entprell" nennen, es bleibt
ein Delay und hat mit Entprellen nicht das geringste zu tun.
Funktionierendes Entprellen macht man durch Mehrfachabtastung in einem
konstanten Intervall.
Z.B. 4-maliges Testen auf Gleichheit im 10ms Raster ist eine
zuverlässige Lösung.
Vom Prizip her ist das eine Tiefpaßfilterung (25Hz) mittels gleitendem
Mittelwert über 4 Messungen und den Triggerschwellen 0% und 100%, d.h.
25%, 50% und 75% bewirken keine Änderung des vorherigen Zustandes.
Das mag auf den ersten Blick aufwendig erscheinen, aber die
CPU-Belastung durch den 10ms Timerinterrupt ist lächerlich gering.
Diese Beispielwerte sind natürlich nicht in Stein gemeißelt, sondern nur
das Prinzip.
Arduino Fanboy D. schrieb:> Aber Wartezeiten, auch, oder gerade, zum entprellen, das erscheint auch> mir einfach nur eine dumme Idee zu sein.
Es IST eine strunzdumme Idee. Immer und überall, nicht nur in ISRs,
dort aber natürlich ganz besonders.
Nop schrieb:> Ich sag nur "Code nicht auf englisch".
Meinst Du, dieses Elaborat wäre mit englischen Kommentaren auch nur eine
Spur besser?
Die Codequalität hat ziemlich wenig mit der Kommentarsprache zu tun.
c-hater schrieb:> Arduino Fanboy D. schrieb:>>> Aber Wartezeiten, auch, oder gerade, zum entprellen, das erscheint auch>> mir einfach nur eine dumme Idee zu sein.>> Es IST eine strunzdumme Idee. Immer und überall, nicht nur in ISRs,> dort aber natürlich ganz besonders.
Halt!
Mich erschrickt gerade, dass ein C-Hasser mit mir, einem C++
Befürworter, einer Meinung ist.
Ist das noch normal?
Arduino Fanboy D. schrieb:> Halt!> Mich erschrickt gerade, dass ein C-Hasser mit mir, einem C++> Befürworter, einer Meinung ist.> Ist das noch normal?
Ja, denn eigentlich hasst er C nicht. Das ist nur eine Rolle die er
spielt, um sich möglichst oft künstlich aufregen zu können. Wenn wir
alle primär über Assembler diskutieren würden, hätte er sich ASM-Hasser
genannt und so verhalten.
Im Familienkreis habe ich eine Frau, die denkt sich aus, was andere
schlechtes denken oder tun könnten und dann klagt sie darüber, wie
schlecht es ihr oder anderen Angehörigen wegen diesen schlechten
Menschen geht. Dabei haben die überhaupt nichts getan!
Wenn sie z.B. jemand mit kräftigen Armen sieht, malt sie sich aus, wie
feste er wohl seine Frau schlagen könnte. Und dann tut ihr die Frau leid
und die Betreiber seines Fitness-Studios sind auch ganz böse, weil sie
ihn ja dazu ausbilden, seine Frau zu schlagen, usw....
Warum tut sie das? Keine Ahnung, aber sie kann wohl nicht anders. Manche
Menschen machen sich gerne Feinde - zumindest im Kopf.
@ Stefan ⛄ F.: Einspruch
"Amper hoch skillen?" hat allein schon durch seine Wortwahl und seine
unendlichen Möglichkeiten zittiert zu werden den Gipfel allen Potentials
erreicht.
Entprellen über Zeitschleifen kann ich nur den zweiten Platz zuweisen,
es kommt zu oft als Thema (es ist schon wieder ein neuer eröffnet).
PittyJ schrieb:> was macht eigentlich>> TX_String("\nCCR2\n");>> Uart Ausgabe?> So etwas versuche ich, nicht in einen ISR zu packen.
so weit so gut.
> Für mich muss eine ISR möglich kurz und schnell sein. Meist wird da nur> ein Flag getoggelt,
d.h. Du duplizierst das HW-Flag, das den Int auslöst.
> ober ein Zähler hochgesetzt.> Alles andere läuft in zyklischen Normal-Tasks ab.
Dazu braucht man für simple Flags keinen Int dazwischen, es sei denn,
die zeitliche Verzögerung wird "gebraucht". Oder der Flash ist noch in
Teilen frei.
> Insbesondere wenn der TX_String auch noch einen Interrupt wirft, weil> ein Fifo über/unterläuft wird es lustig.
Hä??
Wenn Puffer überlaufen, dann braucht man sinnvolle Behandlung, notfalls
ignoriert mal das empfangene Zeichen, wartet bis wieder Platz im
Sendepuffer frei ist, je nach Anforderungsprofil.
> Mit diesen kurzen ISRs bin ich die letzten 10 Jahre gut gefahren.
Und ich hab in den letzten 40 Jahren so manches dazugelernt.
Carl D. schrieb:>> Insbesondere wenn der TX_String auch noch einen Interrupt wirft, weil>> ein Fifo über/unterläuft wird es lustig.> Hä??> Wenn Puffer überlaufen, dann braucht man sinnvolle Behandlung, notfalls> ignoriert mal das empfangene Zeichen, wartet bis wieder Platz im> Sendepuffer frei ist, je nach Anforderungsprofil.
Wenn ich in einer ISR eine Funktion aufrufe, die darin noch einen
weiteren Interrupt auslösen kann, dann kann das je nach Platform lustige
Effekte liefern.
So etwas versuche ich zu vermeiden.
Wenn man die Dinge einfacher hält, können weniger Probleme auftreten.
Und meine ISR funktionieren.
Arduino Fanboy D. schrieb:> Mich erschrickt gerade, dass ein C-Hasser mit mir, einem C++> Befürworter, einer Meinung ist.
Pass auf, dass er sich jetzt nicht umbenennt in "C++ Hasser" :-D
Jetzt haben wir den TO vertrieben.
:-(
Popkorn einpack ....
ampere schrieb:> Entprellen über Zeitschleifen kann ich nur den zweiten Platz zuweisen,
Nee, den Platz muß er sich mit den LEDs ohne Vorwiderstände teilen.
Floh schrieb:> Arduino Fanboy D. schrieb:>> Mich erschrickt gerade, dass ein C-Hasser mit mir, einem C++>> Befürworter, einer Meinung ist.>> Pass auf, dass er sich jetzt nicht umbenennt in "C++ Hasser" :-D
Das ist doch per Vererbung eh mit drin.
