C nicht OOP?



  • +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



  • AnsiCFan schrieb:

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

    Das geht absolut nicht aus deinem Elaborat hervor.



  • AnsiCFan schrieb:

    Aber das Konzept, die (Instanzierung von Klassen) in der Form von 'IDs' nachzubilden, ist vom Grundgedanken her zweifellos OOP.

    Da hast Du wahr.

    AnsiCFan schrieb:

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

    Da aber nicht. Du zeigst nur, daß man mit ein wenig Mühe in C fein OO p kann. Man kann übrigens auch in C++ ganz auf die OO verzichten.
    Trotzdem ist die "Objektorientierte Programmierung" ein nichtleerer Begriff. Worüber man trefflich streiten kann, ist, ob die objektorientiertheit von Sprachen ein sinnvolles Attribut ist oder nur ein Werbefurz.



  • volkard schrieb:

    [...]Worüber man trefflich streiten kann, ist, ob die objektorientiertheit von Sprachen ein sinnvolles Attribut ist oder nur ein Werbefurz.

    Das hängt wohl davon ab, wieviel Geld Firmen dafür übrig haben, ständig neue Räder zu erfinden...



  • Es ist doch wegen der Produktivität. Und der Effizienz. Und der Wirtschaftlichkeit.
    Und den Synergieeffekten.

    *bullshitbingo* !!!



  • Tachyon schrieb:

    volkard schrieb:

    [...]Worüber man trefflich streiten kann, ist, ob die objektorientiertheit von Sprachen ein sinnvolles Attribut ist oder nur ein Werbefurz.

    Das hängt wohl davon ab, wieviel Geld Firmen dafür übrig haben, ständig neue Räder zu erfinden...

    ob es sinnvoll ist, sprachen das attribut "objektorientiert" überhaupt zu geben oder zu verweigern. du hast meinen satz ganz mißverstanden.



  • volkard schrieb:

    ob es sinnvoll ist, sprachen das attribut "objektorientiert" überhaupt zu geben oder zu verweigern.

    zumindest macht es 'ne neue sprache erstmal interessant. nehmen wir mal C#. wenn die nicht objektorientiert wäre, hätte kein schwein notiz davon genommen (weil sie sonst absolut nichts neues zu bieten hat).
    🙂


Anmelden zum Antworten