Frage zu Klassen

[Markus O. (markusjo)]

Hi,

ich steige gerade in das Thema Klassen ein. Leider liegt mir das derzeit 
gar nicht, will es aber versuchen. Hab mir dazu einige Seiten und Videos 
angesehen. Auf der folgenden Seite finde ich das ganz gut erklärt: 
https://spacehal.github.io/docs/arduino/objectOriented

  public:                 // alle Methoden (oder Attribute) nach public sind öffentlich
    Led(int pPin) {       // Konstruktor (ohne void, int, etc.)
      pinLed   = pPin;
      stateLed = false;
      pinMode(pinLed, OUTPUT)

Wieso wird "pinLed nicht direkt in den Konstruktor geschrieben, sondern 
"pPin" und dann direkt an die pinLed var. übergeben? MUSS das so oder 
kann man das so machen? Welche Vorteile gibt es, wenn es nicht notwendig 
ist?

Vielen Dank!

[Stefan F. (Gast)]

Markus O. schrieb:
> Wieso wird "pinLed nicht direkt in den Konstruktor geschrieben

Meinst du so?:

public:
   Led(int pPin) : pinLed(pPin) {  
      stateLed = false;
      pinMode(pinLed, OUTPUT)

Für mich sind das einfach nur zwei Alternativen, die letztendlich das 
Gleiche bewirken.

pPin ist jedenfalls ein Argument des Konstruktors und nur innerhalb des 
Konstruktors bekannt.

So geht es nicht:

public:
   Led(int pinLed) {  
      stateLed = false;
      pinMode(pinLed, OUTPUT)

Weil damit die gleichnamige Member Variable pinLed nicht initialisiert 
würde. Argumente und Member Variablen sind nicht das gleiche.

[Markus O. (markusjo)]

Stefan F. schrieb:
> public:
>    Led(int pinLed) {
>       stateLed = false;
>       pinMode(pinLed, OUTPUT)

Ja, genau so meinte ich das.

> So geht es nicht:

Ok! Werde es mir mit einem freien Kopf und viel Ruhe noch einmal genau 
ansehen.

Danke!

[Oliver S. (oliverso)]

pinLed sollte eigentlich nach der Initialiserung durch den Konstruktor 
nicht mehr verändert werden können, weil im laufende Betrieb niemand die 
LEDs umlötet.

Also kann das const sein, was dann die erste Art der Initialisierung im 
Konstruktor-Rumpf nicht mehr erlaubt.

Der initiale Wert für stateLed  lässt sich dann auch gleich bei der 
Deklaration angeben, und wenn man dann noch das undefinierte pin in 
pinLED ändert, sieht es so aus:

class Led { 
    const int  pinLed;  
    bool stateLed {false};  

  public:                   
    Led(int pPin) : pinLed(pPin) {  
      pinMode(pinLed, OUTPUT); // Pin als Ausgang definieren
    }
};

Oliver

[Stefan F. (Gast)]

Es könnte z.B. auch sein, dass du den Integer Wert begrenzen willst.

public: 
   Led(int pPin) { 
      if (pinLed >= 0) {
         pinLed   = pPin;
         pinMode(pinLed, OUTPUT)
      } else {
         pinLed = -1; // -1 bedeutet "nicht verwendet"
      }
      stateLed = false;

[Arduino F. (Firma: Gast) (arduinof)]

Markus O. schrieb:
> pinMode(pinLed, OUTPUT)

Da fehlt ein Semikolon!
Zudem hat pinMode() nichts im Konstruktor zu suchen.
Bei AVR vielleicht unkritisch.
Aber bei anderen Architekturen ist noch nicht gewährleistet, dass zu dem 
Zeitpunkt der pinMode() seine Wirkung entfalten kann.

Darum haben auch alle Klassen in der Arduino Welt (die sowas tun müssen) 
eine begin() oder init() Methode.

[Stefan F. (Gast)]

Arduino F. schrieb:
> Da fehlt ein Semikolon!

Super, damit wurde die Welt mal wieder vor dem Verderben gerettet.

[Michael B. (laberkopp)]

Markus O. schrieb:
> Wieso wird "pinLed nicht direkt in den Konstruktor geschrieben

?!?

Markus O. schrieb:
> MUSS das so oder kann man das so machen

Man kann auch mit einer constructor member initializer list arbeiten, 
aber der Computer hat letztlich immer genau dasselbe zu tun: den als 
Parameter übergebenen Wert in die Klassenstruktur zu kopieren.

Hier verschiedene Möglichkeiten:

https://www.learncpp.com/cpp-tutorial/constructor-member-initializer-lists/

Markus O. schrieb:
> Leider liegt mir das Thema derzeit gar nicht,

Dabei ist es so einfach:

So bald man Exceptions in einer Programmiersprache ermöglichen will

void processing(char *ptr)
{
   // tue irgendwas 
}
void shit(int x)
{
  if(x>20) throw "Bullshit";
}
void test(int y)
{
   try
   {
      char *leaked=strdup("Something");
      shit(y);
      processing(leaked);
      free(leaked);
   }
   catch (char *message)
   {
       puts(message);
   }
}
int main(void)
{
   test(22);
}

hat man ein Problem mit dynamisch allokiertem Speicher auf dem heap, 
hier leaked welcher bei einem Fehler in shit nicht mehr freigegeben 
wird.

Man braucht Variablen die bei einem stack unwind, also Verlassen des 
Scopes, ihre Daten selbst freigegeben können. Man braucht also Variablen 
mit Codeergänzung, vor allem Destruktoren.

Eine Klasse ist eine struct Struktur mit Funktionen die einen 
versteckten self Patameter auf ein Element diesen Strukturtyps 
beinhalten.

struct string
{
   char *data;
}
assign(struct string *self,char *value)
{
   self->data=strdup(value);
}
destroy(struct string *self)
{
   free(self->data);
}

ist dann

class string
{
   char *data;
   string(char *value)
   {
      data=strdup(value);
   }
   ~string()
   {
      free(data);
   }
}

mit dem Zusatzeffekt, dass ~string automatisch aufgerufen wird, wenn so 
eine Variable im stack unwind freigegeben wird, also

void processing(char *ptr)
{
   // tue irgendwas 
}
void shit(int x)
{
  if(x>20) throw "Bullshit";
}
void test(int y)
{
   try
   {
      string notleaked("Something");
      shit(y);
      processing(notleaked);
   } // bei verlassen dieses Blocks egal ob normal oder wegen exception wird ~string von notleaked automatisch aufgerufen und gibt den Speicher auf den data zeigt frei
   catch (char *message)
   {
       puts(message);
   }
}
int main(void)
{
   test(22);
}

Alles andere (Vererbung etc.) ist dann nur Zusatznutzen oder -ärger.

Der Kern sind aber Klassen = eine struct aus Daten zusätzlich mit 
Funktionen mit verstecktem self Parameter die dann eben nicht Funktionen 
sondern Methoden heissen.

[Arduino F. (Firma: Gast) (arduinof)]

Stefan F. schrieb:
> damit wurde die Welt mal wieder vor dem Verderben gerettet.

Ja!
Jeder Fehler weniger bringt einen der Lösung näher!
Das hast du gut erkannt.

class Led                 // Beginn der Klassendefinition
{
  private:
    const byte pinLed;          // LED-Pin (Attritbute der Klasse)
    bool stateLed;        // Zustand der LED

  public:                 // alle Methoden (oder Attribute) nach public sind öffentlich
    Led(const byte pPin):pinLed{pPin},stateLed{false}{}  
    void init()     
    {
      pinMode(pinLed, OUTPUT);
    }
    void toggle()         // Die Methoden einer Klassen können auf die Attribute zugreifen
    {
      stateLed = !stateLed;
      digitalWrite(pinLed, stateLed);
    }
};                        // Eine Klassendefinition endet mit einem Semikolon

Led ledGreen(4);  // ein `Led` Objekt mit dem Namen `ledGreen` mit Pin 4
Led ledRed(5);      // ein weiteres `Led` Objekt mit Pin 5

void setup()
{
  ledGreen.init();
  ledRed.init();
}

void loop()
{
  ledGreen.toggle();      // Methodenaufruf vom Objekt ledGreen
  delay(200);
  ledRed.toggle();        // Methodenaufruf vom Objekt ledGreen
  delay(800);
  ledGreen.toggle();
  delay(200);
  ledRed.toggle();
  delay(800);
}

Warum der Autor des Tutorials es anders macht?
KA... Ihm ist aber nicht der Einzige...

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Arduino F. schrieb:

> Jeder Fehler weniger bringt einen der Lösung näher!

Dann würde ich noch auf die gute, alte Regel aufmerksam machen wollen, 
nach der jeder c'tor der nur ein nicht default Argument hat und nicht 
zur impliziten Konvertierung dienen soll, als `explicit` markiert werden 
sollte:

    explicit Led(const byte pPin)...

Ansonsten könnte der Compiler den c'tor verwenden, um implizite 
Konvertierungen vor zu nehmen. Dieses Beispiel würde übersetzen obwohl 
man ggf. lieber einen Fehler vom Compiler hätte:

void light_show(Led light);

int main()
{
    light_show( 42 );
}

[Arduino F. (Firma: Gast) (arduinof)]

Torsten R. schrieb:
> Dieses Beispiel würde übersetzen obwohl
Das Drama ist eigentlich, dass die begin() Methode in dem Fall nicht 
ausgeführt wird.


Macht es nicht Sinn dort eine Referenz zu übergeben?
> void light_show(Led &light)
Dann bekommst du auch deine Meldung.


Und ja, explicit ist hier durchaus Sinn behaftet!
Wieder eine/zwei potentielle Fehlerquellen ausgemerzt.
Die Welt wird so gerettet (ein Stückchen besser), quasi zum Nulltarif

[Wilhelm M. (wimalopaan)]

Michael B. schrieb:
> Man kann auch mit einer constructor member initializer list arbeiten,
> aber der Computer hat letztlich immer genau dasselbe zu tun: den als
> Parameter übergebenen Wert in die Klassenstruktur zu kopieren.

Das kommt darauf an, was man will. Aber im Normalfall muss man das in 
der initializer-list des ctors machen.

Arduino F. schrieb:
> class Led                 // Beginn der Klassendefinition
> {
>   private:
>     const byte pinLed;          // LED-Pin (Attritbute der Klasse)
>     bool stateLed;        // Z

Es gibt den Spruch "naming is hard", und das trifft hier genau zu - 
wobei es hier eigentlich ganz leicht ist, die Namensgebung zu 
verbessern.

[Wilhelm M. (wimalopaan)]

Michael B. schrieb:
> char *leaked=strdup("Something");

Was hat das hier im Kontext von C++ zu suchen?
Es dient nur dazu, damit Du Dein Wissen über exceptions hier einbringen 
kannst.

[Wilhelm M. (wimalopaan)]

Torsten R. schrieb:
> Dieses Beispiel würde übersetzen obwohl
> man ggf. lieber einen Fehler vom Compiler hätte:

In dem Beispiel gibt es zwei Gründe dafür, und explicit ist nur einer 
dafür ;-)

[Wilhelm M. (wimalopaan)]

Yeah, Moby ist da ;-)

[Arduino F. (Firma: Gast) (arduinof)]

Wilhelm M. schrieb:
> Moby ist da ;-)

Und gleich wird er uns seine portable ASM Lösung vorstellen, die auf 
jedem µC/Arduino läuft.

[Frank M. (ukw) (Moderator)]

Arduino F. schrieb:
> Und gleich wird er uns seine portable ASM Lösung vorstellen

Moby hat hier noch nie jemandem geholfen. Nur geprahlt. Dabei gibt (und 
gab) es genügend Fragen/Probleme in diesem Forum zu Assembler, die bis 
heute ungelöst sind. Nein: Keines davon hat Moby jemals beantwortet oder 
gelöst. Typischer Blender halt.

[Michael W. (miks)]

SUCH DIR ENDLICH HILFE!!!

[Michael B. (laberkopp)]

Wilhelm M. schrieb:
> Michael B. schrieb:
>> char *leaked=strdup("Something");
>
> Was hat das hier im Kontext von C++ zu suchen?
> Es dient nur dazu, damit Du Dein Wissen über exceptions hier einbringen
> kannst.

Oje Wilhelm, es ist ein Beispiel um zu zeigen warum man Klassen braucht.

Wenn du es nicht verstanden hast, schade.

Man kann dort auch beliebigen anderen Kram hinschreiben der irgendwas 
auf dem heap alloziert, mir fiel nichts kürzeres ein, was für jemanden 
dem nur C bekannt ist, unmittelbar verständlich ist.

Exceptions sind halt DER Grund warum man Klassen braucht. Klassen nur 
der Klassen wegen sind kein Grund, sondern höchstens ein nice to have.

Wobei es verdammt viele Programme gibt, die durch Klassen schlechter 
verständlich und schlechter wartbar und in der Performance schlechter 
wurden.

[Wilhelm M. (wimalopaan)]

Michael B. schrieb:
> Exceptions sind halt DER Grund warum man Klassen braucht.

Nö: klares Nein.

[C-hater (c-hater)]

Wilhelm M. schrieb:
> Michael B. schrieb:
>> Exceptions sind halt DER Grund warum man Klassen braucht.
>
> Nö: klares Nein.

Ich hätte nicht gedacht, dass ich irgendeiner der von dir geäusserten 
Meinungen mal zustimmen würde. Aber nu isses doch passiert. Also 1+

[Rolf M. (rmagnus)]

Michael B. schrieb:
>> Was hat das hier im Kontext von C++ zu suchen?
>> Es dient nur dazu, damit Du Dein Wissen über exceptions hier einbringen
>> kannst.
>
> Oje Wilhelm, es ist ein Beispiel um zu zeigen warum man Klassen braucht.

Der primäre Grund, warum es Klassen gibt, ist aber nicht, um Exceptions 
zu unterstützen, sondern …

Michael B. schrieb:
> Alles andere (Vererbung etc.) ist dann nur Zusatznutzen oder -ärger.

… Vererbung - und insbesondere darauf basierend Polymorphie.

> Exceptions sind halt DER Grund warum man Klassen braucht. Klassen nur
> der Klassen wegen sind kein Grund, sondern höchstens ein nice to have.

Klassen nutzt man, um die objektorientierte Denkweise umzusetzen. Wenn 
du das als "Klassen nur der Klassen wegen" betrachtest und den Mehrwert 
von Vererbung nicht verstanden hast, dann solltest du dir das nochmal 
anschauen. Sich jetzt gerade Exceptions als den einzigen Grund für 
Klassen auszusuchen, ist etwas seltsam.

> Wobei es verdammt viele Programme gibt, die durch Klassen schlechter
> verständlich und schlechter wartbar und in der Performance schlechter
> wurden.

Und vermutlich genau so viele, die durch Klassen übersichtlicher und 
deutlich besser wartbar sind. Die Verwendung von Klassen bedeutet auch 
nicht automatisch eine schlechtere Performance.

[C-hater (c-hater)]

Rolf M. schrieb:

> Die Verwendung von Klassen bedeutet auch
> nicht automatisch eine schlechtere Performance.

Das ist zwar theoretisch tatsächlich so, praktisch passiert aber genau 
dies fast immer. Der Fluch der Kapselung. Noch ohne jede Vererbung: Der 
Code der Klasse muß jederzeit den Datenbestand der Klasse konsistent 
halten, egal, welche der Mehoden in welcher Reihenfolge aufgerufen wird. 
Allein das impliziert schon fast immer einen gewissen Overhead.

Wenn dann aber noch Vererbung und insbesondere polymorphe Methoden 
hinzukommen, ist der Overhead sogar garantiert. Das ist theoretisch 
beweisbar (und natürlich vor Jahrzehnten bereits formal bewiesen 
worden).

Das ist halt das, was OOP in Kauf nimmt, um leicht verwendbare Objekte 
bieten zu können, die auch eine relativ hohe Sicherheit gegen 
Fehlbenutzung haben. Auf Perfomance war das OOP-Konzept niemals 
optimiert.

Aber das Hauptproblem ist wohl: diese Objekte sind ZU leicht zu 
verwenden. Keiner der "Programmierer", die Objekhierarchien Fremder 
benutzen, beschäftigt sich noch damit, was die benutzte Methode jeweils 
kostet und ob man das, was man letztlich will, nicht auch billiger haben 
könnte, selbst unter Benutzung desselben Objekts...

Das Problem ist also nicht OOP an sich, sondern unfähige "OO-Leecher". 
Früher(tm) habe ich die im Delphi-Umfeld "Komponentenschubser" genannt. 
Nunja, Delphi interessiert heute fast niemand mehr, aber der Typ des 
unfähigen Komponentenschubsers existiert wohl in jeder OO-Sprache und 
OO-Umgebung. OO-Systembedingt...

Und genau das ist, was OO-Anwendungen immer und immer langsamer macht...

[Sophie T. (sophie_t)]

Der Trend geht aktuell von der OOP eher weg, siehe Rust. Da gibt es 
keine Vererbung. C++ bietet Mehrfachvererbung und da kommt man schnell 
in Teufels Küche. Exceptions werden auch nur genutzt, wenn es wirklich 
notwendig ist. Da kommt nämlich ein Overhead rein. Sonst macht man das 
wie in C mit irgendwelchen return codes. Mittlerweile gibt es ja 
std::optional das kommt ja schon nahe an Rust heran.

[Michael B. (laberkopp)]

Wilhelm M. schrieb:
> Michael B. schrieb:
>> Exceptions sind halt DER Grund warum man Klassen braucht.
>
> Nö: klares Nein.

Deine Argumentationskette ist umwerfend und so stichhaltig überzeugend.

Du solltest Politiker werden.

Rolf M. schrieb:
> Und vermutlich genau so viele, die durch Klassen übersichtlicher und
> deutlich besser wartbar sind.

Sicher nicht genau so viele, sondern die sind die Ausnahme.

Es gibt saubere Lehrbeispiele. Aber wenig reales Zeug dass mit so viel 
Mühe durchprogrammiett wurde.

> Die Verwendung von Klassen bedeutet auch
> nicht automatisch eine schlechtere Performance.

Jein, das Mitschleppen von self kostet IMMER Performance. Die müsste man 
durch Nutzung von 'features' wieder reinholen. Eines dieser features 
wären exceptions

Rolf M. schrieb:
> … Vererbung - und insbesondere darauf basierend Polymorphie.

Das ist OOP, geht auch ohne Klaasen, siehe Win16/32.

[Wilhelm M. (wimalopaan)]

C-hater schrieb:
> Wilhelm M. schrieb:
>> Michael B. schrieb:
>>> Exceptions sind halt DER Grund warum man Klassen braucht.
>>
>> Nö: klares Nein.
>
> Ich hätte nicht gedacht, dass ich irgendeiner der von dir geäusserten
> Meinungen mal zustimmen würde. Aber nu isses doch passiert. Also 1+

Geht mir genauso ... mal sehen, wo die Reise hin geht ;-)

[Wilhelm M. (wimalopaan)]

Rolf M. schrieb:
> Der primäre Grund, warum es Klassen gibt, ist aber nicht, um Exceptions
> zu unterstützen, sondern …
>
> Michael B. schrieb:
>> Alles andere (Vererbung etc.) ist dann nur Zusatznutzen oder -ärger.
>
> … Vererbung - und insbesondere darauf basierend Polymorphie.

Auch da würde ich widersprechen: nicht Vererbung als Technik für 
Inklusionspolymorphie ist der hauptsächliche Beweggrund sondern die 
Kapselung und Abstraktion. Vererbung generell wird meistens überbewertet 
und nur Anfänger versuchen, alles in eine Klassenhierarchie zu pressen. 
Komposition ist wichtiger, und damit wieder die Kapselung und 
Abstraktion.

[Wilhelm M. (wimalopaan)]

C-hater schrieb:
> Noch ohne jede Vererbung: Der
> Code der Klasse muß jederzeit den Datenbestand der Klasse konsistent
> halten, egal, welche der Mehoden in welcher Reihenfolge aufgerufen wird.
> Allein das impliziert schon fast immer einen gewissen Overhead.

Das suggeriert, dass man ohne OOP ganz locker mit Inkonsistenzen 
leichter leben könnte. Und das ist natürlich ab einer bestimmten Größe 
des SW-Artefaktes Blödsinn.

[Wilhelm M. (wimalopaan)]

Michael B. schrieb:
> Wilhelm M. schrieb:
>> Michael B. schrieb:
>>> Exceptions sind halt DER Grund warum man Klassen braucht.
>>
>> Nö: klares Nein.
>
> Deine Argumentationskette ist umwerfend und so stichhaltig überzeugend.

Ja, weil Deine Aussage einfach (im Wortsinne) falsch ist. Den Rest kann 
man überall nachlesen, man starte bei Wikipedia. Das muss ich hier nicht 
wiederholen.

[Michael B. (laberkopp)]

Wilhelm M. schrieb:
> Ja, weil Deine Aussage einfach (im Wortsinne) falsch ist. Den Rest kann
> man überall nachlesen, man starte bei Wikipedia. Das muss ich hier nicht
> wiederholen.

Du hast nicht mal nachgedacht, sondern plärrst stumpf das nach was du 
Mal aufgeschnappt hast nach. Armes Herdentier, bleibt dumm wie Brot.

Versuche mal herauszufinden, welche Abhangigkeiten es gibt und welche 
notwendige Vorbedingungen sind.

Als Ubung: warum Atom und Region der Kern von Windows sind.

[Wilhelm M. (wimalopaan)]

Michael B. schrieb:
> Wilhelm M. schrieb:
>> Ja, weil Deine Aussage einfach (im Wortsinne) falsch ist. Den Rest kann
>> man überall nachlesen, man starte bei Wikipedia. Das muss ich hier nicht
>> wiederholen.
>
> Du hast nicht mal nachgedacht,

Hellseher?

[Arduino F. (Firma: Gast) (arduinof)]

C-hater schrieb:
> Der
> Code der Klasse muß jederzeit den Datenbestand der Klasse konsistent
> halten, egal, welche der Mehoden in welcher Reihenfolge aufgerufen wird.


Übersetzt und den Hasser Bias da mal raus genommen:
> Der Code der Klasse kann jederzeit den Datenbestand der Klasse konsistent
> halten.

Ja, das ist doch fantastisch!
C und ASM Anwender können nur von sowas träumen.
Oder müssen das mit viel Aufwand nachstricken, und es wird nur halb so 
gut.

Übrigens:
Kein Wort glaube ich deiner negativen Propaganda.
Auch weil sich irgendwann herausgestellt hat, dass du mindestens 11 
Jahre in der C++ Entwicklung verschlafen hast.
Interessieren würde mich mal, ob du dir jemals die Einarbeitungsphase, 
von min. 1/2 Jahr, angetan hast. Ob deine Gehirnwindungen C++ kompatibel 
sind. Ich meine, ob du überhaupt in der Lage bist, dich den, z.B. OOP, 
Konzepten positiv zuzuwenden.

Zu allen deinen Punkten kann man sagen:
> Wer will, findet Wege.
> Wer nicht will, (er)findet Gründe.

Beispiel:
C-hater schrieb:
> Keiner der "Programmierer", die Objekhierarchien Fremder
> benutzen, beschäftigt sich noch damit, was die benutzte Methode jeweils
> kostet und ob man das, was man letztlich will, nicht auch billiger haben
> könnte, selbst unter Benutzung desselben Objekts...
Erstens: Da steckt eine Pauschalisierung drin "keiner". 
Pauschalisierungen haben bestenfalls eine Wahrscheinlichkeit, eine 
Trefferwahrscheinlichkeit.
So auch eine Falschwahrscheinlichkeit. Die Ansage ist also in ihrer 
Absolutheit falsch.

Es kann schon sein, dass du deine offensichtliche Ablehnung auf solchen 
absolut Behauptungen aufbaust, um dich selber zu überzeugen. Würde es 
zumindest halbwegs erklären.
Tipp:
Je öfter du dir das vorbetest, desto fester glaubst du selber daran.

[C-hater (c-hater)]

Wilhelm M. schrieb:

> Das suggeriert, dass man ohne OOP ganz locker mit Inkonsistenzen
> leichter leben könnte.

Nein, das ist natürlich nicht so.

Es ist vielmehr so: da es ohne OOP die Garantie nicht gibt, dass der 
Datenbestand bei beliebiger Aufrufreihenfolge der Methoden (dann also 
keine Methoden, sondern Funktionen) konsistent bleiben wird, kann man 
einfach eine bestimmte Reihenfolge VORSCHREIBEN.

Also z.B. sowas (sehr einfacher Fall): "bevor irgendeine andere 
xyz_-Funktion aufgerufen werden darf muß einmalig xyz_init aufgerufen 
werden".

Die Crux des Objektes ist halt: das muss das selber prüfen, in aller 
Regel zur Laufzeit. Das kostet Zeit und Codespace. Das Nicht-Objekt mit 
derselben Funktionalität kann auf diese Prüfungen verzichten, da die 
Einhaltung der Restriktionen dem Benutzer obliegt.

Kannst du dir genauso vorstellen, wie die UB-Scheiße in C/C++. Auch hier 
wird der Benutzer dazu verdonnert, einfach alles richtig zu machen...

[C-hater (c-hater)]

Arduino F. schrieb:

> Ich meine, ob du überhaupt in der Lage bist, dich den, z.B. OOP,
> Konzepten positiv zuzuwenden.

Ich habe wahrscheinlich schon OOP betrieben, da warst du noch das 
lüsterne Glitzern in den Augen deines Vaters.

Konkret: Anfang der 1990er.

[Ein T. (ein_typ)]

C-hater schrieb:
> Ich habe wahrscheinlich schon OOP betrieben, da warst du noch das
> lüsterne Glitzern in den Augen deines Vaters.
>
> Konkret: Anfang der 1990er.

Da wäre es doch super, wenn Du Dir endlich mal wenigstens einen leisen 
Hauch von einer Ahnung zulegen würdest.

[Michael B. (laberkopp)]

C-hater schrieb:
> Ich habe wahrscheinlich schon OOP betrieben, da warst du noch das
> lüsterne Glitzern in den Augen deines Vaters.
> Konkret: Anfang der 1990er.

Cool, voll der Experte.

1990 war Smalltalk schon 18 Jahre erwachsen, aber du weisst sicher nicht 
dass diese das Paradebeispiel für Objektorientierung war. 1990 war es 
schliesslich eher wieder out, weil die Leute spätestens als es 1980 
widespread wurde langsam merkten, dass man damit keine konkurrenzfähigen 
Programme schreiben konnte.

[Ein T. (ein_typ)]

Michael B. schrieb:
> C-hater schrieb:
>> Konkret: Anfang der 1990er.
>
> 1990 war Smalltalk schon 18 Jahre erwachsen,

Der Punkt ist nicht, wie lange man glaubt, OOP zu machen, oder zu 
wissen, wann das Paradigma mit welcher Sprache entwickelt wurde -- 
nebenbei: das war nicht Smalltalk. Der Punkt ist vielmehr, ob man die 
Objektorientierung verstanden habt -- und solltet Ihr beide das haben, 
habt Ihr es zumindest vor mir sehr erfolgreich verborgen.

[C-hater (c-hater)]

Ein T. schrieb:

> Der Punkt ist nicht, wie lange man glaubt, OOP zu machen, oder zu
> wissen, wann das Paradigma mit welcher Sprache entwickelt wurde --
> nebenbei: das war nicht Smalltalk. Der Punkt ist vielmehr, ob man die
> Objektorientierung verstanden habt

Also, ich denke, das habe ich. Ich kenne und verstehe nicht nur das 
Konzept, sondern weiss auch bis in's letzte Detail, wie es physisch 
umgesetzt wird. Zumindest für Delphi und .net (also zumindest für C# und 
VB). Bei C++ nur für den Teil, der tatsächlich zu Code wird, das reine 
Compilezeit-Geraffel ist mir zu unleserlich, das kann man niemandem 
ernsthaft zumuten. Ist aber sehr wahrscheinlich genau das Feature, was 
im (kleinen) µC-Bereich überhaupt nur sinnvoll nutzbar ist.
Mag sein, das tue ich mir trotzdem vor der Rente nicht mehr an. Zumal 
auch meine sehr viel jüngeren Kollegen damit nicht warm werden. Auch für 
die scheint das unlesbar (und insbesondere auch: undebugbar). Die wollen 
das genau so wenig wie ich.

> und solltet Ihr beide das haben,
> habt Ihr es zumindest vor mir sehr erfolgreich verborgen.

Das mag in meinem Fall daran liegen, dass ich den allergrößten Teil des 
Codes, den ich produziere, nicht veröffentlichen darf, selbst wenn ich 
es wollen würde. Weil ich zwar der Urheber bin, aber mein Brötchengeber 
die Rechte daran besitzt.