C nicht OOP?



  • 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