C auch OOP?

[Tachyon]

OOP ist mit C nicht möglich. Punkt. Was man in C, und eigentlich so gut wie mit jeder imperativen Sprache machen kann, ist OBP.
Konzepte wie Polymorphie oder Vererbung (wobei Vererbung ohne Polymorphie eigentlich witzlos ist) lassen sich nicht wirklich nachbilden. Auch solche Dinge wie RAII sind in C unmöglich.
Zwischen OBP und OOP besteht immernoch ein Unterschied. Ja, OOP ist ein Konzept, aber das Konzept muss explizit vom Sprachumfang unterstützt werden.

[Shade Of Mine]

Vererbung ist nicht kein merkmal dass OOP definiert.
JavaScript zB hat keine vererbung.

Und natuerlich ist es schwerer Konzepte zu implementieren wenn einem die Sprache dabei nicht hilft - aber es geht. Jede gute C API ist Objekt Orientiert.

Wir muessen uns dazu nur einmal die C Library selbst ansehen:
die string funktionen: schoenes OOD
die stdio funktionen: schoenes OOD
...

WinAPI und natuerlich auch die POSIX API. Oder kennt wer gmp? Alles schoenes OO-Design.

Vererbung ist haesslich, keine Frage: aber es ist zum glueck auch nicht das um und auf der OOP Und dennoch kann man vererbung implementieren. Wenn wir jetzt nur komfort betrachten, dann faellt C++ uebrigens auch durch was OOP betrifft: denn komfort bietet C++ ja nun wirklich kaum. Allein ein einfaches multi dispatching ist ja schon hoelle zum implementieren.

Zum glueck definiert der komfort einer sprache nicht die verwendbarkeit.

[loks]

Tachyon schrieb:

OOP ist mit C nicht möglich. Punkt. Was man in C, und eigentlich so gut wie mit jeder imperativen Sprache machen kann, ist OBP.
Konzepte wie Polymorphie oder Vererbung (wobei Vererbung ohne Polymorphie eigentlich witzlos ist) lassen sich nicht wirklich nachbilden. Auch solche Dinge wie RAII sind in C unmöglich.
Zwischen OBP und OOP besteht immernoch ein Unterschied. Ja, OOP ist ein Konzept, aber das Konzept muss explizit vom Sprachumfang unterstützt werden.

Nur mal so als Gedanke. Deinem Ansatz folgend wäre Maschinensprache nicht OOP fähig weil sie dieses ja nciht explizit untestützt.. Trotzdem werden ALLE C++ Programme in Maschinensprache übersetzt. Soll man das jetzt so intepretieren das aus einem OOP Programm beim Compilieren ein nciht-OOP Programm wird?

Man kann in jeder Sprache nach den Prinzipien von OOP programmieren, nur ist es nicht in jeder Sprache vorteilhaft es zu versuchen. Sprachen können OOP nur mehr oder weniger unterstützen, das ist alles.

Umgekehrt entspricht es ja ebenso einme Irrglauben allein durch die Benutzung von Klassen würde man schon OOP programmieren...

[loks]

Tachyon schrieb:

OOP ist mit C nicht möglich. Punkt.

Und mal als kleine Geschichtslektion:

Die ersten C++ Compiler haben nichts anderes gemacht als C++ in C zu üebersetzen und dann erst zu compilieren.... Wie also konnte (und kann) es möglich sein C++ nach C zu konvertieren wenn OOP in C nicht möglich wäre? Oder willst Du jetzt argumentieren ein OOP Programm wird zum imperativen programm wenn es von C++ nach C konvertiert wird?

[ganzeinfach]

Sag ich doch. Hässliches gefrimel.

Datenkapselung geschieht doch in C++ zur Compilezeit, danach gibt es doch sowieso keine Möglichkeit mehr festzustellen, ob eine Methode public oder private war. Soviel zu den C++ -> C Kompilern.

[Gast]

Tachyon schrieb:

OOP ist mit C nicht möglich. Punkt. Was man in C, und eigentlich so gut wie mit jeder imperativen Sprache machen kann, ist OBP.
Konzepte wie Polymorphie oder Vererbung (wobei Vererbung ohne Polymorphie eigentlich witzlos ist) lassen sich nicht wirklich nachbilden. Auch solche Dinge wie RAII sind in C unmöglich.
Zwischen OBP und OOP besteht immernoch ein Unterschied. Ja, OOP ist ein Konzept, aber das Konzept muss explizit vom Sprachumfang unterstützt werden.

Und C++ unterstützt Reflection (@shade, ja, hier die "allgemein verstandene" Reflection ;)) nicht explizit. Also ist C++ nicht OOP sondern OBP? Java, objC und viele andere Sprachen kennen direkt keine Mehrfachvererbung, aber bieten Interfaces mit welchem man, mehr oder weniger, dasselbe macht...

Letzendlich führen solche Aussagen (von dir) zu Debatten darüber wie OOP definiert ist, ob es überhaupt definiert werden kann/soll. Das hatten wir schon oft hier. Ohne Konsens.

[ganzeinfach]

Ach und nochwas zu den C++ -> C Kompilern. Assembler ist dann eine hochsprache, weil C und C++ erst nach Assembler übersetzt werdne.

[ghorst]

Tachyon schrieb:

OOP ist mit C nicht möglich. Punkt. Was man in C, und eigentlich so gut wie mit jeder imperativen Sprache machen kann, ist OBP.
Konzepte wie Polymorphie oder Vererbung (wobei Vererbung ohne Polymorphie eigentlich witzlos ist) lassen sich nicht wirklich nachbilden.

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.)
[quote="Tachyon"] Auch solche Dinge wie RAII sind in C unmöglich.[/cpp]
raii ist etwas, was es fast nur in c++ gibt. überall wo man keinen expliziten destruktor und/oder keine klare lebenszeiten (alle system mit gc...) für objekte hat, ist das nicht zu implementieren. wenn du es daran festmachen willst, sieht die welt der oop ziemlich dünn aus.

Zwischen OBP und OOP besteht immernoch ein Unterschied. Ja, OOP ist ein Konzept, aber das Konzept muss explizit vom Sprachumfang unterstützt werden.

cool: dann ist c ja eine funktionalsprache, objektorientiert und logisch ist sie auch noch. tipp: c hat einen makropräprozessor. wenn du den wirklich benutzt, kriegst du zwar code, den kein schwein mehr versteht, aber damit ist quasi jedes sprachkonzept möglich.

[ghorst]

ganzeinfach schrieb:

Sag ich doch. Hässliches gefrimel.

Datenkapselung geschieht doch in C++ zur Compilezeit, danach gibt es doch sowieso keine Möglichkeit mehr festzustellen, ob eine Methode public oder private war. Soviel zu den C++ -> C Kompilern.

den raffe ich jetzt nicht. ein c++->c compiler macht da genau das gleiche wie ein c++->asm oder c++->binary compiler er setzt zu dem zeitpunkt des kompilieren die forderungen um.
wenn ich jetzt an dem compiler vorbei spiele und bspw direkt auf die ausgabe bezug nehme, kann man die ganzen schutzmechanismen umgehen. es ist absolut kein kunststück die private oder protected funktionen eines objectes von außen aufzurufen, wenn man das ausgabemedium kennt.

[ganzeinfach]

ghorst schrieb:

den raffe ich jetzt nicht. ein c++->c compiler macht da genau das gleiche wie ein c++->asm oder c++->binary compiler er setzt zu dem zeitpunkt des kompilieren die forderungen um.

ja, und darum ist C noch lange keine OOP Sprache nur weil man alles was ein Kompiler mit OOP Sprache macht irgendwie nachbilden kann. Dann wären ja auch Assembler, Maschinencode und 0 und 1 OOP Sprachen.

Und die Datenkapselung in C ist nur solange gültig, wie die verwendeten Strukturen nicht Opensource sind (was sie im eigenen Programmen immer sind), den dann kann ich wieder ohne Probleme von außen auf internas der Struktur zugreifen.

[ghorst]

wieso sollte ich in einem system das handles benutzt, die structs in einen header packen und damit für alle offen machen? in einer source datei untergebracht ist sie genauso sicher, wie die datenkapselung von c++... oder auch: wenn ich will, macht es keine mühe das zu unterlaufen. wenn ich mich an da interface halte, habe ich kein problem, auch wenn hinter der kulisse mal die implementierung getauscht wird. (letzteres ist übrigens einer hauptgründe, warum man datenkapselung überhaupt betreibt...)
ansonsten sie braucht nicht opensource sein. man kann so etwas auch reverse-engineeren. geht übrigens auch sowohl für c als auch c++. wenn du natürlich argumentierst, dass ich mich selber austricksen kann, muss ich dir recht geben. aber das kann ich in c++ auch.

[ganzeinfach]

Reverse engineering hat mal garnix damit zu tun ob ne Sprache OOP unterstützt oder nicht, das geht völlig am Thema vorbei.

Zeig mir einfach einen C Code bei dem ich allen Code sehen kann und der einen Compileerror erzeugt, weil ich auf interne Daten direkt zugreife.

[ghorst]

ich zeige was viel schöneres: ein c++-code bei dem ich völlig legal die beschränkungen von protected und private umgehe.

#include <iostream>
class foo{
public:
  foo(int a):m_a(a){}
protected:
  virtual void dummy() {std::cout << "foo::dummy() " << m_a << std::endl;}
private:
  int m_a;
};

//nachbildung von foo als struct. das sollte mit den meisten c++-compiler funktionieren.
struct foo_struct{
  void **vtable; //das ist jetzt nicht ganz sauber, da es eigentlich funktionen
	         //sind, aber passt scho, da man eh casten muss.
  int m_a;
};

int main()
{
  foo bar(12);
  foo_struct* bar_struct=(foo_struct*)(&bar);
  //einmal umgehen des private für daten-member
  std::cout << bar_struct->m_a << std::endl;
  //einmal aufruf einer protetcted funktion von außen
  void (*func_dummy)(foo) =(void (*)(foo))(*(bar_struct->vtable));
  func_dummy(bar);
}

alles was von der klasse wissen muss, ist wie sie aussieht. also genau das gleiche wie bei dem nachbilden der struct, die sich hinter einem handle verbirgt.

das von dir geforderte kann man nicht erstellen, da man spätestens, wenn man die bytes einzeln im speicher zusammensucht jeden schutzmechanismus umgehen kann. hier nehmen sich c++ und c nicht viel und auch viele andere programmiersprachen, die dynamische bindung unterstützen, nicht viel. mit genug liebe, ist alles möglich.

[DEvent]

Tachyon schrieb:

OOP ist mit C nicht möglich. Punkt. Was man in C, und eigentlich so gut wie mit jeder imperativen Sprache machen kann, ist OBP.
Konzepte wie Polymorphie oder Vererbung (wobei Vererbung ohne Polymorphie eigentlich witzlos ist) lassen sich nicht wirklich nachbilden. Auch solche Dinge wie RAII sind in C unmöglich.
Zwischen OBP und OOP besteht immernoch ein Unterschied. Ja, OOP ist ein Konzept, aber das Konzept muss explizit vom Sprachumfang unterstützt werden.

Hast du den verlinkten Artikel ueberhaupt selbst durchgelesen?

[...]Object-based languages that do not support inheritance or subtyping are usually not considered to be true object-oriented languages.

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

[ganzeinfach]

DEvent schrieb:

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

Genauso wie mit Assembler, ist halt nur ein gefrimel.

[Shade Of Mine]

ganzeinfach schrieb:

Und die Datenkapselung in C ist nur solange gültig, wie die verwendeten Strukturen nicht Opensource sind (was sie im eigenen Programmen immer sind), den dann kann ich wieder ohne Probleme von außen auf internas der Struktur zugreifen.

Du definierst dir OOP wie es dir gefaellt. Sprachen wie zB Python oder JavaScript die man allgemeinhin als OO-Sprachen ansieht kennen auch keine Zugriffsrechte.

Das Problem ist, du definierst Kapselung ueber Zugriffsrechte. Das ist aber falsch. Zugriffsrechte helfen einem dabei Kapselung sicherer zu machen (gegen Murphy, nicht gegen machiavelli).

JavaScript hat zB keine Klassen und daher keine Vererbung und keine virtuellen Methoden. Dennoch hat es Polymorphie.

Aber wer wirklich zweifelt dass C OO-Programme unterstuetzt, der soll sich mal die WinAPI ansehen. Ueberall haben wir Handles auf denen wir operieren. Handles sind dabei polymorphe Objekte.

Wenn man mit der MFC programmiert hat, sollte einem das eigentlich klar geworden sein. Denn aus einem SetWindowTitle(hwnd, "text") wird ein this->SetTitle("text").

[Nagila Hawa]

Ist das nicht eigentlich egal, ob C objektorientierte Programmierung unterstützt? Ich meine egal ist es nicht, weil ich persönlich für objektorientierte Programme c++ benutzen würde und das wohl vielen so geht.

Möglich ist es doch trotzdem sich ein Struct Namens "bla", Funktionen mit den Namen "bla_*****" zu erstellen und zu meinen: "Das ist jetzt meine Klasse bla und ich behandle sie wie eine Klasse und die Instanzen wie ein Objekt.

Ob jemand objektorientiert programmiert, liegt doch eher daran, wie er selbst sein Datenmüll interpretiert.

Was private/public angeht: Ich kann ja auch eine "Membervariable" mit dem Komentar "/*Achtung, privat!!!!!!*/" schützen. Klar, kann jemand ganz böses das ignorieren und auf die Variable zugreifen, aber dieser böse jemand kann auch in c++ mit ein paar Klicks mehr diese Variable in den public-Bereich verschieben - Das Ergebnis ist das selbe. Der einzige Unterschied ist, daß in c++ verhindert wird, aus Versehen auf eine geschützte Variable zuzugreifen. Da meckert der Kompiler. Das sehe ich aber eher als Komfortfunktion, die bei der Objektorientierten Programmierung hilft, nicht als "Erlaubnis" objektorientiert zu Programmieren.

In diesem Sinne: "Nein, du darfst nicht objektorientiert Programmieren, das ist C!"

[Scheppertreiber]

So isses.

Ich habe den objektorientierten Ansatz auch mal probiert. Im Endeffekt sind so
viele Ausnahmen vom "Allgemeinen" aufgetreten das es eigentlich weder Zeit gespart
noch das Projekt übersichtlicher gemacht hat.

OO ist keine Frage der Sprache, es ist eine Denke.

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