Aussehen
Suche Einloggen
[c] [meta] [fefe] [erp]

5431 Ergebnisse

[0] ... [136] [137] [138] [139] [140] [141] [142] [143] [144] [145] ... [271]
  • [l] HTTP 418 Felix 🫖 Tue, 22 Apr 2025 10:23:25 GMT Nr. 154290
    >>154245
    >Dort ist noch nicht einmal ein Typ-Cast im Kot drin
    Lüge :3

    Abgesehen davon: komisch alte C Sachen (Zeiger, brrrr) mit C++ mischen und sagen das wäre aber ein grundlegendes OOP-Problem ist falsch und dumm.

    Korrekterweise würde man einen Container von Base-Zeigern übergeben würg! und Probleme werden keine gehabt.
  • [l] Felix Tue, 22 Apr 2025 10:02:32 GMT Nr. 154285
    >>struct Derived1 : public Base
    Das ist C++. Das gibt es in C nicht.
  • [l] Felix Tue, 22 Apr 2025 09:55:16 GMT Nr. 154284
    >>154245
    Das ist Blödsinn. Der C-Standard gibt nicht vor, wie Arrayelemente im Speicher liegen. Du kannst nicht einfach Structs als Arrays betrachten.
  • [l] Felix Tue, 22 Apr 2025 09:52:00 GMT Nr. 154283
    >>154152
    Man macht das gar nicht mit Zeigern, man macht das direkt inline.

    Beispiel:
    typedef struct {
      int weight;
      int age;
    } pet;
    
    typedef struct {
      pet p;
      char *name;
    } dog;
    
    int get_age(pet *p) {
      return p->age;
    }
    
    dog *new_dog(int weight, int age, char *name) {
      dog *rex = malloc(sizeof(dog));
      ((pet *)rex)->weight = weight;
      ((pet *)rex)->age = age;
      rex->name = name;
      return rex;
    }
    
    dog *rex = new_dog(40, 5, "Rex");
    int age = get_age(rex)
    


    usw usf.
  • [l] Felix Tue, 22 Apr 2025 09:23:38 GMT Nr. 154279
    >>154278
    Ich bin nicht der Arrayfelix.

    t. GObjectfelix
  • [l] Felix Tue, 22 Apr 2025 09:04:27 GMT Nr. 154278 SÄGE
    >>154267
    >>154268
    Wie wollt ihr kernbehinderten Mongos denn Typurteile über Inhalte von Arrays Polymorpher Typen mit Vererbung fällen? Ach, geht halt nicht, weil Arrays haben mit Vererbung nix zu tun.

    Ihr saudummen Hurensöhne solltet einfach mal die Fresse halten, anstatt hier dumm rauszulabern. Was für Missgeburten hier rumhängen. Erkennbar noch nie Wohlgetyptheit von irgendwas nachgewiesen, aber hier rumpöbeln. Gesindel.
  • [l] Felix Tue, 22 Apr 2025 08:51:31 GMT Nr. 154277
    Das Problem mit dem OOP der 90er wurde mal hier am Beispiel von Java beschrieben:
    http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

    Nicht ohne Grund haben Rust und Go beide keine Klassen mehr.
  • [l] Felix Tue, 22 Apr 2025 08:41:49 GMT Nr. 154276
    >>154091
    Vererbung funktioniert doch ganz einfach mit Structs, siehe GObject.

    https://de.wikipedia.org/wiki/GObject
  • [l] Felix Tue, 22 Apr 2025 06:54:57 GMT Nr. 154268
    >>154266
    Ob du behindert bist?
  • [l] Felix Tue, 22 Apr 2025 06:37:46 GMT Nr. 154267
    >>154266
    >Alles hat mit allem zu tun
    >Alles hängt irgendwie miteinander zusammen
    Bubi glaubt heute wirklich schlau zu sein.
  • [l] Felix Tue, 22 Apr 2025 05:14:19 GMT Nr. 154266
    >>154249
    > Vererbung hat immer noch nichts mit Arrays zu tun
    Polymorphismus hat sehr wohl was mit Arrays zu tun.
  • [l] Felix Tue, 22 Apr 2025 04:03:37 GMT Nr. 154264
    JPG 207×243 7.9k
    Oke also wenn man mit Absicht Scheiße baut dann ist es scheiße.
    Das ist ja unglaublich Bob!

    Kuck mal hier ein Fahrrad mit viereckigen Rädern — also sind alle Fahrräder per se dumm weil ich so schlau bin und ein dummes Beispiel gefunden habe.
  • [l] Felix Mon, 21 Apr 2025 22:33:08 GMT Nr. 154254
    JPG 200×286 10.2k
    >>154215
    Was ist eigentlich dieses Unraid?
    >Unraid ist ein von Lime Technology, Inc. entwickeltes proprietäres Linux-basiertes Betriebssystem, das für den Einsatz auf Heim-Servern entwickelt wurde.
    Hmm naja...
    <Unterstützt wird die Nutzung der Dateisysteme XFS, Btrfs und ZFS. ReiserFS wird noch unterstützt.
    Basiert!
  • [l] Felix Mon, 21 Apr 2025 22:28:58 GMT Nr. 154253
    >>154245
    Also Felix hatte in 20 Jahren Programmieren irgendwie noch nie dein komisches Problem mit Arrays. Wirkt ziemlich konstruiert. Auch: Wieso denken alle immer, OOP = C++?

    >Dahinter steckt aber ein grundlegendes, von C++ vollkommen unabhängiges Problem.
    Nein, das ist ein reines C++-Problem, weil C++ halt an C drangeflanscht wurde.
  • [l] Felix Mon, 21 Apr 2025 21:10:53 GMT Nr. 154250
    >>154245

    Die Größe von Base ist 1, also ist arr[1].member1 das zweite int im Speicher, aber weil Base in Wirklichkeit Derived1 mit Größe 3 ist, ist das zweite int im Speicher member2 vom ersten Arrayelement, nicht member1 vom zweiten Arrayelement.
  • [l] Felix Mon, 21 Apr 2025 21:09:16 GMT Nr. 154249 SÄGE
    >>154245
    >*Man nimmt mehrere Arrays
    Vererbung hat immer noch nichts mit Arrays zu tun.

    >*Man nimmt ein switch
    Warum glauben Leute nur, dass sie Vererbung bräuchten? Man kann doch auch einfach bei jeder.png Änderung alle.jpg Verwendungen bei allen.jpg Benutzern anpassen. Es ist so ein Fach!

    >*Verbleibender, extrem seltener Fall: Man hat externe Programmierer bei Drittanbietern außerhalb der Organisationseinheit, die die aufzurufenden Funktionen schreiben, die zur Kompilierzeit noch gar nicht bekannt sind, Plugin-System-Style. Da braucht man Zeiger-Array und Virtuelle-Funktionszeiger-Tabellen.
    Oder man möchte einfach das Verhalten eines Objekts befristet anpassen, ohne dabei jedes Mal durch die gesamte Kotbasis dackeln zu müssen.

    >*Verbleibender, noch extrem seltenerer Fall: Man muss auch die Anzahl der Methoden zur Laufzeit dynamisch halten. Geht mit OOP garnicht, hat C bereits bei Dateisystemen vor Äonen gelöst.
    Wo fängt man bei so viel Verwirrung überhaupt an?

    >Dahinter steckt aber ein grundlegendes, von C++ vollkommen unabhängiges Problem.
    Nein, dahinter steckt das ausschließlich von C++ abhängige Problem, dass C++ Object Slicing vorschreibt.
  • [l] Felix Mon, 21 Apr 2025 20:40:30 GMT Nr. 154246
    >>154245
    +/-1 weil das Array im Base nicht populiert wird? Wenig überraschend.
  • [l] Felix Mon, 21 Apr 2025 20:15:13 GMT Nr. 154245
    >>154163
    >Schon klar, Polymorphismus zur Laufzeit braucht man eigentlich gar nicht.
    Tatsächlich braucht man den Polymorphismus nicht in der Ausprägung, der man in C++ begegnet. Wie schon oben geschrieben:
    *Man nimmt mehrere Arrays
    *Man nimmt ein switch
    *Verbleibender, extrem seltener Fall: Man hat externe Programmierer bei Drittanbietern außerhalb der Organisationseinheit, die die aufzurufenden Funktionen schreiben, die zur Kompilierzeit noch gar nicht bekannt sind, Plugin-System-Style. Da braucht man Zeiger-Array und Virtuelle-Funktionszeiger-Tabellen.
    *Verbleibender, noch extrem seltenerer Fall: Man muss auch die Anzahl der Methoden zur Laufzeit dynamisch halten. Geht mit OOP garnicht, hat C bereits bei Dateisystemen vor Äonen gelöst.

    >C++
    Ist tatsächlich für einen Vergleich zwischen OOP und Nicht-OOP sehr brauchbar, da man im Vergleich zu einigen anderen Sprachen die Wahl hat, ob man die OOP-ismen benutzt.

    >Was Arrays mit Vererbung zu tun haben, bleibt auch dein Geheimnis.
    #include <stdio.h>
    
    struct Base
    {
    	int member1;
    };
    
    struct Derived1 : public Base
    {
    	int member2;
    	int member3;
    };
    
    int diff1(Base * arr, size_t n)
    {
    	int result = 0;
    
    	for(size_t i = 0; i < n - 1; i++)
    		result += arr[i+1].member1 - arr[i].member1;
    
    	return result;
    }
    
    int diff2(Derived1 * arr, size_t n)
    {
    	int result = 0;
    
    	for(size_t i = 0; i < n - 1; i++)
    		result += arr[i+1].member1 - arr[i].member1;
    
    	return result;
    }
    
    int main(int /*argc*/, char ** /*argv*/)
    {
    	Derived1 arr[8];
    
    	for(size_t i = 0; i < 8; i++)
    	{
    		arr[i].member1 = 1;
    		arr[i].member2 = 5;
    		arr[i].member3 = 1337;
    	}
    
    	printf("%d\n", diff1(arr, 8));
    	printf("%d\n", diff2(arr, 8));
    
    	return 0;
    }


    Die Felixe dürfen mal die Ausgabe raten (ja, dort steht member1 minus member1).
    Dort ist noch nicht einmal ein Typ-Cast im Kot drin, Warnungen gibt es auch mit -Wall -Wextra -Wpedantic keine.
    Dahinter steckt aber ein grundlegendes, von C++ vollkommen unabhängiges Problem.


[0] ... [136] [137] [138] [139] [140] [141] [142] [143] [144] [145] ... [271]
[c] [meta] [fefe] [erp]