Operatoren überladen?
-
Fiesek schrieb:
Du meinst dann eher eine "DeepCopyFunc(void* pParam)"?
+fricky schrieb:
na, weil ein 'deep copy' doch meistens für'n konkreten typ gilt und sehr speziell ist. für andere structs brauchste 'ne andere deep-copy funktion.
Je nu, why denn not so?
DeepCopy(void *pParam, size_t size)Dann klappt's auch mittem void
-
pointercrash() schrieb:
Je nu, why denn not so?
DeepCopy(void *pParam, size_t size)Dann klappt's auch mittem void
Aber wohl kaum mit einer tiefen Kopie ... woher soll ich denn nun wissen, WO in der zu kopierenden Struktur sich der/die Zeiger befindet/n, der auf einen zu kopierenden Speicherbereich zeigt, für den ich Speicher anfordern und den ich dann kopieren muß?
-
pointercrash() schrieb:
Je nu, why denn not so?
DeepCopy(void *pParam, size_t size)Dann klappt's auch mittem void
C hat leider kein 'instanceof' oder sowas.
-
Belli schrieb:
Aber wohl kaum mit einer tiefen Kopie ... woher soll ich denn nun wissen, WO in der zu kopierenden Struktur sich der/die Zeiger befindet/n, der auf einen zu kopierenden Speicherbereich zeigt, für den ich Speicher anfordern und den ich dann kopieren muß?
Das Beispiel ist ohnehin nur ein Abriß und funktioniert natürlich so nicht, aber man kann es zum Funktionieren bringen, wenn z.B. die Struct einen einheitlichen Headerteil hat.
Meine ganzen Eventqueues und Systick- Slots sind z.B. so aufgebaut. Mit demselben Prinzip läßt sich eine DeepCopy auch realisieren.
-
Wenn man so ein einheitliches Layout nicht hat, muss man halt für jede Struktur eine eigene DeepCopy-Funktion haben. Genauso wie in C++, sie müssen nur alle unterschiedlich heißen.
-
Bashar schrieb:
Wenn man so ein einheitliches Layout nicht hat, muss man halt für jede Struktur eine eigene DeepCopy-Funktion haben. Genauso wie in C++, sie müssen nur alle unterschiedlich heißen.
Ja, ist aber total unschön. Da ich selten DeepCopy brauche, mach' ich das aber tatsächlich noch per Hand.
Aber statt HandleEvent(union events) aufzurufen, sich mit einem Sack voll auszuparsenden Namen rumzuschlagen, tu' ich mir nicht mehr an.
Der Preis dafür sind Speicherverschnitt (die Structs in der union events sind unterschiedlich lang) und ein bißchen Laufzeitverlust.
Also alles kein Drama, die Faulheit siegt.
-
pointercrash() schrieb:
Belli schrieb:
Aber wohl kaum mit einer tiefen Kopie ... woher soll ich denn nun wissen, WO in der zu kopierenden Struktur sich der/die Zeiger befindet/n, der auf einen zu kopierenden Speicherbereich zeigt, für den ich Speicher anfordern und den ich dann kopieren muß?
Das Beispiel ist ohnehin nur ein Abriß und funktioniert natürlich so nicht, aber man kann es zum Funktionieren bringen, wenn z.B. die Struct einen einheitlichen Headerteil hat.
Meine ganzen Eventqueues und Systick- Slots sind z.B. so aufgebaut. Mit demselben Prinzip läßt sich eine DeepCopy auch realisieren.Das setzt aber voraus, daß alle für die tiefe Kopie relevanten Zeiger in dem einheitlichen Headerteil sind.
Es mag ja durchaus sein, daß es im Einzelfall solche Systeme gibt, aber so als allgemein zu empfehlende Vorgehensweise ist die (void - Variante imho nicht geeignet.
-
Belli schrieb:
Es mag ja durchaus sein, daß es im Einzelfall solche Systeme gibt, aber so als allgemein zu empfehlende Vorgehensweise ist die (void
- Variante imho nicht geeignet.ACK.
Aber ich glaube, dem OP ging es um Operatorenüberladung, ob jetzt speziell DeepCopy, sei mal dahingestellt, ich wollte nur grundsätzlich den Weg aufzeigen, wie man zu einem Ersatz unter C kommt.
Ich packe in eine Struct einen Funktionszeiger, den Parameterblock usw., diese Structs in eine Union und komme dafür mit einem einheitlichen Aufruf aus. Stopfe ich einen anderen Funktionszeiger in die Struct, ist die Operation "überladen".Das Prinzip läßt sich auch auf den Umgang mit Daten umstricken, nichts weiter meinte ich.
-
Belli schrieb:
Das setzt aber voraus, daß alle für die tiefe Kopie relevanten Zeiger in dem einheitlichen Headerteil sind.
nö, im header muss nur stehen, welche wirkliche struct mit dem void* gemeint ist.
Belli schrieb:
Es mag ja durchaus sein, daß es im Einzelfall solche Systeme gibt, aber so als allgemein zu empfehlende Vorgehensweise ist die (void
- Variante imho nicht geeignet.sogar der windows-kernel verwendet 'ne ähnliche 'vererbungs'-struktur. deswegen hat m$ z.b. damals stolz rumgetönt, dass win-nt ein 'objekt-basiertes' OS ist.
-
+fricky schrieb:
sogar der windows-kernel verwendet 'ne ähnliche 'vererbungs'-struktur. deswegen hat m$ z.b. damals stolz rumgetönt, dass win-nt ein 'objekt-basiertes' OS ist.
Echt? Was ist daran "objekt- basiert"? Methode (Funktionspointer) und Daten in einer Struct
Muß wohl an der Liebe der Amis zu bombastischen Namen liegen, die dann zurechtgeschnippelt eingewerbedeutscht wurden.
Mein letztes Beispiel dazu ist "Algorithmic Material Adaptive Velocity Auto Correction", kurz AMAVAC (U.S. Pat. Pend.), das ich kürzlich in Source zu Gesicht bekommen habe. Dahinter steckt eine Ausgleichsgerade, so ca. 5 Zeilen Source, ich hab' mich 'ne Viertelstunde fast nicht eingekriegt vor Lachen, besonders weil mir sofort klar war, warum das so nicht gescheit funktionieren kann
Bin mal gespannt, ob die auf den Hirnfurz wirklich ein Patent kriegen. Aber ist ja das Land der unbegrenzten Unmöglichkeiten.
-
pointercrash() schrieb:
+fricky schrieb:
sogar der windows-kernel verwendet 'ne ähnliche 'vererbungs'-struktur. deswegen hat m$ z.b. damals stolz rumgetönt, dass win-nt ein 'objekt-basiertes' OS ist.
Echt? Was ist daran "objekt- basiert"? Methode (Funktionspointer) und Daten in einer Struct
ja, haben sie so gemacht. irgendwie auch garnicht so doof. immerhin zu 'ner zeit, als OOP u.a. kaum ein schwein kannte.
ich hab' den mods versprochen, keine links auf ebooks mehr zu posten, deshalb such mal selber bei 'esnips' nach "Inside-Windows-2000,-3rd-Edition---MS-Press"
und dann lies chapter 3, system mechanisms, object manager.pointercrash() schrieb:
"Algorithmic Material Adaptive Velocity Auto Correction"
klingt ja abscheulich, wie per zufall zusammengewürfelt. ich dachte immer, ich hab 'ne gute vorstellungskraft, aber das entzieht sich ihr völlig.
-
+fricky schrieb:
ich hab' den mods versprochen, keine links auf ebooks mehr zu posten, ...
Öh, warum wollten sie den Schwur?
Btw, ich glaub' ich hab' was Du meintestpointercrash() schrieb:
"Algorithmic Material Adaptive Velocity Auto Correction"
+fricky schrieb:
klingt ja abscheulich, wie per zufall zusammengewürfelt. ich dachte immer, ich hab 'ne gute vorstellungskraft, aber das entzieht sich ihr völlig.
Ganz einfach, nachdem das Patent eingereicht wurde, darf ich ja drüber plaudern, zumindest verklausuliert. Erstmal ist AMAVAC ein angeblich cooles Kürzel und es geht um die Verarbeitungsgeschwindigkeit des Werkstücks, bzw. des Rohlings. Und man hat definiert, daß eine Spiralfeder, ein Gummiband und ein Lederriemen die gleichen, nur linear parametrierbaren Eigenschaften haben. Das hat aber nur die Spiralfeder (aber nicht bei der Kompressibilität) und die wird zwar als Einziges nicht bearbeitet, aber als Modell für alles hergenommen. Könnte jedem einleuchten, daß das doof ist, aber die haben das so eingereicht.
Genug OT- Geplauder?
-
pointercrash() schrieb:
+fricky schrieb:
ich hab' den mods versprochen, keine links auf ebooks mehr zu posten, ...
Öh, warum wollten sie den Schwur?
weil ich meistens raubkopien gepostet habe ('inside windows 2000' ist auch nicht kostenlos erhältlich). das könnte dem admin probleme bereiten. er ist zwar ein scheisstyp, aber sowas hat er nicht verdient.