C nicht OOP?



  • Hm okay, stimmt, danke. Aber wenn ich schon grad dabei bin. Warum, auch wenn es hier nicht hingehört, ich jedoch denke das ihr das wisst, wurde denn Structs dann erweirtet und sozusagen zu Klassen gemacht?



  • FreakY<3Cpp schrieb:

    Hm okay, stimmt, danke. Aber wenn ich schon grad dabei bin. Warum, auch wenn es hier nicht hingehört, ich jedoch denke das ihr das wisst, wurde denn Structs dann erweirtet und sozusagen zu Klassen gemacht?

    weils einfacher ist, nur eine sorte zu haben als zwei. c++ ist nähmlich ganz drauf angelegt, eine einfache sprache zu sein.



  • volkard schrieb:

    weils einfacher ist, nur eine sorte zu haben als zwei. c++ ist nähmlich ganz drauf angelegt, eine einfache sprache zu sein.

    ... jaja, und wer "nämlich" mit "h" schreibt ist d*****h und c++ ist eine einfache Sprache für Informatik- Analphabeten.
    Kinder können so gemein sein, was? :p



  • pointercrash() schrieb:

    volkard schrieb:

    weils einfacher ist, nur eine sorte zu haben als zwei. c++ ist nähmlich ganz drauf angelegt, eine einfache sprache zu sein.

    ... jaja, und wer "nämlich" mit "h" schreibt ist d*****h und c++ ist eine einfache Sprache für Informatik- Analphabeten.
    Kinder können so gemein sein, was? :p

    sorry, meine sprache tut sich manchmal sich dem niwo der unterhaltung anpassen und manchmal macht sie das sogar im vorraus.



  • volkard schrieb:

    sorry, meine sprache tut sich manchmal sich dem niwo der unterhaltung anpassen und manchmal macht sie das sogar im v******.

    Joh, aber das war ja nur der erste Teil 😉 - Du findest C++ wirklich "einfach"?

    Aber whatsoever, diese "kann C OOP?"- Diskussion haben wir zyklisch immer wieder und im fünften Durchlauf verliert sie dann deutlich an Witz. Wat macht ihr, daß ihr nicht an niwo verliert?



  • volkard schrieb:

    weils einfacher ist, nur eine sorte zu haben als zwei. c++ ist nähmlich ganz drauf angelegt, eine einfache sprache zu sein.

    c++ hat doch zwei. 'class' ist ja nicht bloss ein #define class struct
    🙂



  • pointercrash() schrieb:

    volkard schrieb:

    weils einfacher ist, nur eine sorte zu haben als zwei. c++ ist nähmlich ganz drauf angelegt, eine einfache sprache zu sein.

    ... jaja, und wer "nämlich" mit "h" schreibt ist d*****h und c++ ist eine einfache Sprache für Informatik- Analphabeten.
    Kinder können so gemein sein, was? :p

    Ich vermute mal er meinte mit "einfach" nicht "einfach zu bedienen", sondern einfach "einfach".

    Ein einfaches Brett ist einfacher als ein Surfbrett. Mit dem Surfbrett ist es aber einfacher zu surfen.

    ABER, es ist möglich

    Möglich ist es in jeder Sprache. Die Frage ist nur, ob eine Sprache objektorientierte Programmierung auch unterstützt. Das tut C nicht.



  • Nagila Hawa schrieb:

    Ich vermute mal er meinte mit "einfach" nicht "einfach zu bedienen", sondern einfach "einfach".

    nö, er hat bloss einen scherz gemacht.
    🙂



  • +fricky schrieb:

    nö, er hat bloss einen scherz gemacht.
    🙂

    das stimmt. einen der einfachsten scherze auf kosten von c++. 🤡



  • Yahoooooooo, der monatliche C ist not OOP Thread 😃

    FreakY<3Cpp schrieb:

    Meine Frage nun : Wieso gilt C nicht als OOP, wenn Structs doch eig. fast das gleiche wie Klassen sind, immerhin sehe ich den einzigsten unterschied nur im Namen bisher.

    weil für diese Menschen eine Sprache nur dann eine OOP-Sprache ist, wenn man folgendes machen kann

    obj->methode(data);
    

    und das

    methode(obj, data);
    

    ist der Inbegriff der Nicht-OOP. Das Problem ist, C hat keinen syntaktischen Zucker fpr OOP, d.h. OOP ist in C mühselig und (als Bibliothek Entwickler) den Programmier sehr vertrauen. GTK+ ist das schönste Bsp für OOP in C, eine Klasse in GTK+ zu schreiben ist leider alles ander als trivial (in andere Sprachen wäre das deutlich einfacher).



  • Ojemine ... ist etwa ++C auch in VB geschrieben ? 😉



  • supertux schrieb:

    weil für diese Menschen eine Sprache nur dann eine OOP-Sprache ist, wenn man folgendes machen kann

    obj->methode(data);
    

    und das

    methode(obj, data);
    

    ist der Inbegriff der Nicht-OOP.

    demnacch wäre C eine reinrassige OO-sprache. ersteres geht nämlich auch in C.
    🙂



  • +fricky schrieb:

    demnacch wäre C eine reinrassige OO-sprache. ersteres geht nämlich auch in C.
    🙂

    ich nehme an, di meinst sowas?

    void f();
    struct object{
    	void(*methode)();
    };
    
    int main()
    {
    	struct object *obj=malloc(sizeof(*obj));
    	obj->methode=f;
    	obj->methode();
    


  • volkard schrieb:

    ich nehme an, du meinst sowas?

    ja, es geht sogar obj.methode(); in C. das sieht noch mehr nach OOP aus (weil's Java-ähnlich ist).
    🙂



  • supertux schrieb:

    FreakY<3Cpp schrieb:

    Meine Frage nun : Wieso gilt C nicht als OOP, wenn Structs doch eig. fast das gleiche wie Klassen sind, immerhin sehe ich den einzigsten unterschied nur im Namen bisher.

    weil für diese Menschen eine Sprache nur dann eine OOP-Sprache ist, wenn man folgendes machen kann

    obj->methode(data);
    

    und das

    methode(obj, data);
    

    ist der Inbegriff der Nicht-OOP.

    Schade. Dann muss ich Ada95 wohl beiseite legen. Nichtmal Objektorientierte Programmierung ist möglich. 😞



  • +fricky schrieb:

    demnacch wäre C eine reinrassige OO-sprache. ersteres geht nämlich auch in C.
    🙂

    dreh mir die Worte nicht im Thead, das habe ich nicht gesagt.



  • supertux schrieb:

    weil für diese Menschen eine Sprache nur dann eine OOP-Sprache ist, wenn man folgendes machen kann

    Wow, Pawlow hätte seine helle Freude.



  • pointercrash() schrieb:

    jaja, und wer "nämlich" mit "h" schreibt ist d*****h

    Und wer "nämlich" ohne "h" schreiben will, sollte konsequenterweise dann auch "nämlic" schreiben ...



  • supertux schrieb:

    +fricky schrieb:

    demnacch wäre C eine reinrassige OO-sprache. ersteres geht nämlich auch in C.
    🙂

    dreh mir die Worte nicht im Thead, das habe ich nicht gesagt.

    nix für ungut, ich meinte doch auch für 'diese menschen' die du erwähntest. dachte das wär' klar.
    🙂



  • Habe mir mit ANSI C ein Modul gebastelt, das so etwas ähnliches wie ein C++ Container sein soll.

    Der Header sieht so aus:

    #define DYN_ARRAY unsigned
    
    DYN_ARRAY create_dyn(unsigned size_of_single_element);
    
    void destroy_dyn(DYN_ARRAY id_array);
    unsigned append_items_n_dyn(DYN_ARRAY dyID, void* src, unsigned num);
    void destroy_item_dyn(DYN_ARRAY dyID, unsigned idx);
    unsigned destroy_equal_dyn(DYN_ARRAY dyID, void* key);
    unsigned get_size_dyn(DYN_ARRAY dyID);
    unsigned get_mem_size_dyn(DYN_ARRAY dyID);
    void* get_item_dyn(DYN_ARRAY dyID, unsigned idx, void* dest);
    unsigned find_item_dyn(DYN_ARRAY dyID, void* key);
    unsigned count_items_dyn(DYN_ARRAY dyID, void* key);
    
    #define append(ARRAY_ID, PTR_SRC) append_items_n_dyn((ARRAY_ID),(PTR_SRC), 1)
    /* usw. usf. */
    
    #include <stdio.h>
    #define STRING unsigned
    #define create_string() create_dyn(sizeof(char))
    
    unsigned pickLine(STRING destString, FILE* src);
    unsigned printString(STRING source, FILE* destination);
    unsigned printLine(STRING source, FILE* dest);
    FILE* openFile(STRING dyID, char* mod);
    char* cString(STRING dyID);
    /* usw. usf. */
    

    Es ist mir nicht ganz so geglückt, wie erhofft, aber für meine Hobby-Zwecke kann ich halbwegs damit arbeiten.

    Das Modul hat z.T. gewisse Ähnlichkeiten mit einer instanzierten Klasse in einer höheren oop-sprache.
    Man muss allerdings ein Objekt vom Typ DYN_ARRAY explizit erzeugen, im Unterschied zu 'echten' Objekten, die implizit konstruiert werden können.
    Also z.B. so:

    DYN_ARRAY komma = create_dyn(sizeof(float));
    DYN_ARRAY xyStructs = create_dyn(sizeof(xy_struct));
    

    Von create_dyn bekommt man dann eine eindeutige ID zurückgeliefert, die man bei allen Funktionsaufrufen, wo man etwas mit dem dyn. Array tun möchte, als Parameter übergibt.
    Beispielsweise würde bei

    float a = 5.2;
    append(komma, &a);
    

    eine Kopie des Werts von (a) am Ende des dyn. Arrays (komma) angefügt.
    Anhand der ID 'weiß' die Funktion natürlich, zu welchem dyn. Array etwas hinzugefügt werden soll, schließlich hat sich das Modul ja die ID auch selber ausgedacht. Hier liegt eine (entfernte) Ähnlichkeit dieser 'ID' mit dem this-> Pointer aus echten OOP-Sprachen vor, mit dem hauptsächlichen Unterschied, dass die ID immer explizit als Funktions-Parameter übergeben werden muss.
    Leider ist das ganze Konstrukt viel fehleranfälliger als 'echte' OOP-Container, und hat wirklich nur ansatzweise OOP-Charakter.
    Aber das Konzept, die (Instanzierung von Klassen) in der Form von 'IDs' nachzubilden, ist vom Grundgedanken her zweifellos OOP.
    Hauptsächlicher Problemfall ist allerdings, dass man von einem Modul nicht so ohne weiteres etwas ableiten kann, wie man es z.B. bei einer Basisklasse in echten OOP Sprachen könnte. (Bzw. man kann selbstverständlich das Modul selbst erweitern, indem man zu den bereits bestehenden Funktionen und (static) Globalen einfach weitere Funktionen und statics dazuschreibt. Wenn man dann das Modul neu kompiliert, kann es alles, was es vorher auch konnte, und eben zusätzlich noch etwas mehr.

    Zwischen Modularer und Objektorienter Programmierung besteht, wenn überhaupt, wohl nur ein mikroskopischer Unterschied.

    mfg


Anmelden zum Antworten