C auch OOP?

[pointercrash**]

Ich muß gestehen, C++ als C mit Klassen zu mißbrauchen und nach dem, was mir manchmal zur Nacharbeit unterkommt, scheint das im embedded- Bereich nicht unüblich zu sein. Ich nutze die Sprachfeatures von C++ also gar nicht bis im Sinne des Erfinders vermutlich unkorrekt.
Zu C (zurück)gekommen bin ich wegen der Kompatibilität auf Source- Ebene, da ist C unschlagbar!
OOP- Sachen nachzubilden ist natürlich machbar, gibt ja immer noch ein paar nette Precompiler, die Überladung, Vererbung usw. nachbilden. Ich hab's mir angeschaut, aber was da hinten rausfällt ist häßlich bis unwartbar - so ein bißchen tun wie OOP mach' ich auf Konzept- Ebene, der Code bleibt in C und ich werde belohnt, daß das Zeug für'n ATMega genauso compiliert wie für 'nen M16C, 'nen SH8 oder 'nem MSP430 .
Da ist C stark, macht Spaß
Aber echt OO ist das nicht, war dafür auch nicht gedacht, nur um zur root zurückzukommen ... also nicht echt OOP.

[Scheppertreiber]

Ist euch eigentlich schon aufgefallen, daß es "OO" schon viel länger gibt wie "C" ?
Ich habe das erste Mal "OO" auf einer Tür mit einem Herzchen drin gesehen. Muß ein Dialekt sein ...

[OP_Versteher]

Der OP interpetiert klassen mit OOP, was auch soweit in ordnung ist. Und er hat gelesen das strukturen und Klassen in C++ das gleiche sind (soweit richtig auser die member Visibiliy). Nun denkt der OP um die ecke und glaub evtl. mit C auch OOP orientiert programmieren zu können. Nun das geht schon (wie gesaget ein Konzept). Allerdings muss man das OOP Konzept in C ohne diversen Sprachfeatures implementieren. Die ganze polymorphy Konstruktor, vererbung, konstruktor/destruktor memberfunktionen -> dinge gibts es nicht in C. Aber man kann dennoch einen OOP stil in C umsetzen bspw:

struct Person_Dat{
  char acName[50];
  int iAlter;
};

Person_Dat* CreatePerson(char *acName,int iAlter){
  Person_Dat* p=malloc(sizeof(Person_Dat));
  strcpy(p->acName,acName);
  p->iAlter=iAlter;
  return p;
}

Person_Dat* CopyPerson(Person_Dat* p){
  Person_Dat* pC=malloc(sizeof(Person_Dat));
  memecpy(pC,p,sizeof(Person_Dat)));
  free(p);
}

void DelelePerson(Person_Dat* p){
  free(p);
}

etc.

[Tachyon]

DEvent schrieb:

Niemand hat behauptet das C eine echte OOP-Sprache ist. In C kann man aber funktional, prozedurial und eben objektorientiert programmieren (OOP).

Nein, man programmiert objektbasiert. Die Denke ist keine objektorientierte Denke, sondern eine objektbasierte Denke.

Das ist ein großer Unterschied, und die Ideen dafür wurden schon in den frühen 60'igern geboren.

Daraus ging dann auch recht schnell die erste objektorientierte Sprache hervor. Natürlich kann man jetzt wieder sagen, eine Unterscheidung zwischen objektbasiert und objektorientiert ist Korinthenkackerei, aber dann kann man auch sagen eine Unterscheidung zwischen Aggregation und Komposition ist Korinthenkackerei, oder sich diverse andere etablierte Begriffe heraussuchen und sagen, die geringen Unterschiede mit denen sich Begriff a) von Begriff b) unterscheidet sind Korinthenkackerei.

Btw. denke ich, Du hast den verlinkten Atikel nicht verstanden, denn Menge OBP > Menge OOP. :p

ghorst schrieb:

Dann schreibe dir flink eine vtable und ein paar makros für v-calls. dann hast zusammen mit dem, was ich oben für vererbung getippt habe, deine vererbung mit polymorphie (oben ist sie ja schon für datentypen) oder mach es gleich dynamisch. das geht. wenn du das ganze fertig haben willst: gobject. polymorphismus, vererbung, kapselung und hast du nicht gesehen. (ich finde den code zwar tierisch hässlich, aber das ist mein geschmack. ich mag auch vieles andere nicht, daher ist da hier nicht von relevanz.)

Mit Deinem Ansatz kann man nichtmal ein einfaches Aggregat vernünftig einfügen, ohne dafür eine Flut von Create-Funktionen aufzurufen. Und Du willst ja wohl nicht behaupten, dass der händische Aufruf einer Flut von spezialisierten Funktionen (spezialisiert, auf einzelne, bestimmte Strukturen) wirklich OOP sind, oder? Also: Eher nicht OOP.

@_sothis: Ja, lasst uns wieder alle ins Mittelalter sie Softwarekriese zurückfallen.

[sothis_]

diese ganze konzeptflut und die daraus entstehenden diskussionen in der informatik sind korinthenkackerei

[ghorst]

@tachyon ???
wieso sollte man damit nur schwer komposition/aggregation bauen können bzw. warum sollte es so schrecklich aufwendig sein? die "flut" von create-funktionen führst du bei c++/anderen oop sprachen auch aus. der einzige unterschied ist, dass sie bei c++ "klasse(parameter)" heißt und bei c mit oop "creatKlasse(parameter)". was daran nun soviel schwieriger oder aufwendiger sein soll, ist mir schleierhaft.

oder hast du nicht verstanden, wie man die vtable + v-calls implementieren würde bzw. wie eine rein dynamische lösung aussehen würde?

[Tachyon]

ghorst schrieb:

@tachyon ???
wieso sollte man damit nur schwer komposition/aggregation bauen können bzw. warum sollte es so schrecklich aufwendig sein? die "flut" von create-funktionen führst du bei c++/anderen oop sprachen auch aus. der einzige unterschied ist, dass sie bei c++ "klasse(parameter)" heißt und bei c mit oop "creatKlasse(parameter)". was daran nun soviel schwieriger oder aufwendiger sein soll, ist mir schleierhaft.

oder hast du nicht verstanden, wie man die vtable + v-calls implementieren würde?

Du musst Deine Creates für jedes Aggregat, für jede Vererbung usw. ausführen. Du willst doch nicht ernsthaft behaupten, dass Dein Funktionswust ein Ersatz dafür ist, was eine wirkliche OO-Sprache von Haus aus bietet.
Ich sehe in Deinen Funktionen nirgends OOP. Wenn überhaupt, dann vielleicht OBP, aber das kann man in C auch weniger unübersichtlich und fehlerträchtig hinbekommen.
Und was aufwändiger ist, sieht man alleine schon an Deinem katastophal unübersichtlichen Beispielkot.

[ghorst]

Du musst Deine Creates für jedes Aggregat, für jede Vererbung usw. ausführen.

das muss ich in c++ auch, wie dir wahrscheinlich aufgefallen ist.
mit ein bisschen mehr code in dem c mit oop, kann man das aber auch hübsch zusammenfassen, da ich aber nur das konzept erklären und keine fertige lösung liefert wollte, sieht das überraschenderweise bei mir alles ein bisschen krude ist. wenn man das ganze noch hübsch mit ein paar makros zukleisterst, sieht die sache schon anders aus.
aber hier um dir mal ein vollständiges bsp für statische objekte zu zeigen:
http://www.embedded.com/97/fe29712.htm
sieht das wirklich so grausam aus?
oder hier mal was hübsches für dynamische objekte:
http://library.gnome.org/devel/gobject/stable/
letzteres wurde hier schon mal erwähnt, aber von dir irgendwie nicht wirklich beachtet. schau es dir einfach mal.

[supertux]

Tachyon schrieb:

Du musst Deine Creates für jedes Aggregat, für jede Vererbung usw. ausführen. Du willst doch nicht ernsthaft behaupten, dass Dein Funktionswust ein Ersatz dafür ist, was eine wirkliche OO-Sprache von Haus aus bietet.
Ich sehe in Deinen Funktionen nirgends OOP.

Es stimmt, dass man in C vieles zu Fuss machen muss und nicht autoamtsich geschieht. Das heißt aber noch lange nicht, dass die Eigenschaft OOP zu sein, dadurch verloren geht, wenn Construkturen/Desktruktoren nicht automatisch ausgeführt werden. C++ erlaubt mit dem syntaktischen Zucker, schneller und eleganter OOP zu programmieren, aber C auch.

Und Du willst ja wohl nicht behaupten, dass der händische Aufruf einer Flut von spezialisierten Funktionen (spezialisiert, auf einzelne, bestimmte Strukturen) wirklich OOP sind, oder? Also: Eher nicht OOP.

es macht nicht minder OOP, sondern aufwändiger und das ist etwas anders.
Siehe Object-Oriented Programming With ANSI-C oder schaut dir GTK an.

[DEvent]

Tachyon schrieb:

ghorst schrieb:

@tachyon ???
wieso sollte man damit nur schwer komposition/aggregation bauen können bzw. warum sollte es so schrecklich aufwendig sein? die "flut" von create-funktionen führst du bei c++/anderen oop sprachen auch aus. der einzige unterschied ist, dass sie bei c++ "klasse(parameter)" heißt und bei c mit oop "creatKlasse(parameter)". was daran nun soviel schwieriger oder aufwendiger sein soll, ist mir schleierhaft.

oder hast du nicht verstanden, wie man die vtable + v-calls implementieren würde?

Du musst Deine Creates für jedes Aggregat, für jede Vererbung usw. ausführen. Du willst doch nicht ernsthaft behaupten, dass Dein Funktionswust ein Ersatz dafür ist, was eine wirkliche OO-Sprache von Haus aus bietet.
Ich sehe in Deinen Funktionen nirgends OOP. Wenn überhaupt, dann vielleicht OBP, aber das kann man in C auch weniger unübersichtlich und fehlerträchtig hinbekommen.
Und was aufwändiger ist, sieht man alleine schon an Deinem katastophal unübersichtlichen Beispielkot.

Deswegen habe ich doch gesagt das C keine OOP-Sprache ist, mit der man trotzdem OO-programmieren kann.

Der wirklich einzige Unterschied zwischen C und C++ ist das der C++ Compiler viele Funktionaufrufe und Pointer-Adressen fuer mich verwaltet, waehrend ich in C es alles selbst machen muss.

Ein Gegenbeispiel waehre z.B. Prolog, ich kann mir nicht vorstellen dort OO zu programmieren, aber k.a. hab mit Prolog nur sehr sehr wenig gemacht.

Komposition und Aggregation sind genau definiert: Bei der Komposition ist die Lebensdauer der Objekt von einander unabhaenig, bei der Aggregation sterben alle, wenn das Hauptobjekt stirbt.

Nenn doch mal eine Definition fuer OBP und OOP.

[TheTester]

DEvent schrieb:

[...]
Komposition und Aggregation sind genau definiert: Bei der Komposition ist die Lebensdauer der Objekt von einander unabhaenig, bei der Aggregation sterben alle, wenn das Hauptobjekt stirbt.

Genau andersherum, eine Komposition zwischen A und B ist eine Aggregation zwischen A und B in der die Objekte von B, welche Bestandteile eines Objekts von A sind, nur solange leben wie das Objekt von A.

Eine Aggregation hingegen zwischen zwei Klassen A und B ist eine Assoziation, die spezifiziert, dass Objekte der Klasse A aus Objekten der Klasse B aufgebaut sind.

[DEvent]

TheTester schrieb:

DEvent schrieb:

[...]
Komposition und Aggregation sind genau definiert: Bei der Komposition ist die Lebensdauer der Objekt von einander unabhaenig, bei der Aggregation sterben alle, wenn das Hauptobjekt stirbt.

Genau andersherum, eine Komposition zwischen A und B ist eine Aggregation zwischen A und B in der die Objekte von B, welche Bestandteile eines Objekts von A sind, nur solange leben wie das Objekt von A.

Eine Aggregation hingegen zwischen zwei Klassen A und B ist eine Assoziation, die spezifiziert, dass Objekte der Klasse A aus Objekten der Klasse B aufgebaut sind.

ups sorry

[_matze]

Markus12 schrieb:

BlaKonzepteBla schrieb:

Um mal kurz eine vernünftige Antwort zu geben; Ohne Geschwafel von "Konzepten" und "Problemen". Es stimmt soweit, dass in C++ Structs genauso wie Classes benutzt werden können. Im Umkehrschluß bedeutet das allerdings nicht im geringsten, dass man also in C mit Structs OO programmieren kann. Es gibt keine Kapselung, sprich du kannst nicht festlegen, ob die Variablen deines Structs von außen veränderbar sind oder nicht, es gibt keine Konstruktoren und Destruktoren und entsprechend keine wirklichen Memberfunktionen. In C ist OOP faktisch unmöglich da halt die essentiellen Bestandteilen nicht möglich sind. Ansonsten einfach nochma Wikipedia zu dem OOP Thema befragen. Dann wird dir auffallen, dass es dies alles so in C nicht gibt.
Achja @Scheppertreiber:
Du hättest genausogut schreiben können, dass Teiche gerne grün sind weil Katzen miauen. Hätte den selben Sinn.
Schöne Grüße

danke für diese präzise Erklärung.

Der Beweis, dass es sich um einen Troll handelt! Wer so konsequent die Kommentare von Shade of Mine etc. ignoriert, dies hier aber eine präzise Erklärung nennt, kann nichts anderes sein...