Überladen / Überschreiben von Funktionen in C möglich?
-
supertux schrieb:
Ich mag keine Überladung, ich finde das verwirrender als hilfreicher. Just my 2 cents.
Sehe ich auch so. Es ist imho sinnvoller, die Unterscheidung im Funktionsnamen festzuhalten.
-
_matze schrieb:
supertux schrieb:
Ich mag keine Überladung, ich finde das verwirrender als hilfreicher. Just my 2 cents.
Sehe ich auch so. Es ist imho sinnvoller, die Unterscheidung im Funktionsnamen festzuhalten.
sehe ich ebenfalls so. jede information, die im quelltext nicht sichtbar ist, trägt ein stückchen dazu bei, dass code schwerer verständlich wird. wobei sich das mit funktionsüberladungen noch in grenzen hält. ein wirklich starke sourcecode-verschlüsselung erreicht man mit operatorüberladung. nicht prinzipiell, aber so wie es z.b. C++ macht.
-
+fricky schrieb:
nicht prinzipiell, aber so wie es z.b. C++ macht.
Ja ja, immer voll auf die Zwölf...
-
Ichwillswissen schrieb:
Es ist hier zwar ein altes thema, aber ich würde es gern nochmal aufgreifen...
Warum ist denn Überladen in C nicht möglich? Gibt es dazu glaubwürdige Quellen, die dies beweisen?
Eher das Gegenteil: Guckst Du hier http://students.ceid.upatras.gr/~sxanth/lwc/ex6.html, hier http://students.ceid.upatras.gr/~sxanth/lwc/ex12.html und hier:http://students.ceid.upatras.gr/~sxanth/lwc/ex7.html sowie http://students.ceid.upatras.gr/~sxanth/lwc/ex8.html
Geht nicht gibt's nicht
EDIT: Hatte zuerst Beispiele übersehen. Nachtrag: Das Zeug funktioniert wirklich. Unschön ist halt, daß beim Debuggen oft der Bezug zur Source schlecht nachvollziehbar ist. Muß also jeder für sich selbst entscheiden, ob das praktisch ist. Davon abgesehen kann man sich ja mit Funktionspointern eine Art Überlademechanismus "handschnitzen".
-
pointercrash() schrieb:
...
Geht nicht gibt's nicht ;)...was hat das mit überladen zu tun:
Will be translated to the C program
/************* Function Prototypes ************/FILE *oper_comma_OvErlOaD_PS_IO_FILEPc2(FILE * f, char *s);
FILE *oper_comma_OvErlOaD_PS_IO_FILEPv2(FILE * f, void *p);
FILE *oper_comma_OvErlOaD_PS_IO_FILEi2(FILE * f, int i);
void oper_thingy(void *p);
sind doch alles verschiedene funktionsnamen.
-
pointercrash() schrieb:
Ichwillswissen schrieb:
Es ist hier zwar ein altes thema, aber ich würde es gern nochmal aufgreifen...
Warum ist denn Überladen in C nicht möglich? Gibt es dazu glaubwürdige Quellen, die dies beweisen?
Eher das Gegenteil: Guckst Du hier http://students.ceid.upatras.gr/~sxanth/lwc/ex6.html, hier http://students.ceid.upatras.gr/~sxanth/lwc/ex12.html und hier:http://students.ceid.upatras.gr/~sxanth/lwc/ex7.html sowie http://students.ceid.upatras.gr/~sxanth/lwc/ex8.html
Geht nicht gibt's nicht
uuhhh .... wie krank ist das...
-
Krank? Nein! In etwa macht es so der C++ Compiler. Es hat auch nichts mit Overloading in C zu tun, da es kein C ist, sondern nur, wie Overloading in C++ (ist ne andere Sprache) nach C durch einen Praeprozessor realisiert werden koennte.
-
knivil schrieb:
In etwa macht es so der C++ Compiler.
also doch krank.
-
Fuer den einen ist es normal, fuer den anderen halt ... krank.
-
knivil schrieb:
Krank? Nein! In etwa macht es so der C++ Compiler. Es hat auch nichts mit Overloading in C zu tun, da es kein C ist sondern nur, wie Overloading in C++ (ist ne andere Sprache) nach C durch einen Praeprozessor realisiert wirden koennte.
Right! Natürlich ist das kein "natives" Overloading in C, sondern dessen Simulation. Wobei die Vorgehensweise tatsächlich der eines C++- Compilers ähnelt.
Die andere Möglichkeit, die schon kurz angesprochen wurde, wäre selbstmodifizierender Code, aber das scheuen Informatiker mehr als der Teufel das Weihwasser und die Prozessordesigner unterstützen die Phobie oft durch totale Trennung von Daten- und Programmbereichen.
Somit weiß C davon folglich auch nichts; in Assembler habe ich aber schon bestimmte Timings hingetrickst, die anders nicht zu erreichen waren.Darüber hinaus fällt mir nichts ein, was mit selbstmodifiziertem Code arbeiten würde ...
-
pointercrash() schrieb:
Die andere Möglichkeit, die schon kurz angesprochen wurde, wäre selbstmodifizierender Code...
das wäre aber kein überladen. überladung ist doch 'ne ziemlich starre geschichte, bei der so'n compiler sich die funktion aussucht, die seiner meinung nach (argumentenliste usw.) am besten passen würde. selbstmodifizierender code geht mehr in richtung 'reflection'. aber noch was: man kann in C funktionen beim linken überladen. hab' ich schon mal gemacht.
-
+fricky schrieb:
[...]aber noch was: man kann in C funktionen beim linken überladen. hab' ich schon mal gemacht.
könntest du das bitte näher erläutern?
-
hando schrieb:
könntest du das bitte näher erläutern?
bei 'nem keil oder imagecraft-compiler (wahrscheinlich geht's mit jedem compiler irgendwie), kann man vorhandene library-funktionen durch eigene ersetzen (z.b. putchar(), getchar() überladen). mit 'nem compilerflag oder #pragma ging das. nix berauschendes also.
-
ersetzen ist aber nicht überladen.
-
-
knivil schrieb:
Krank? Nein! In etwa macht es so der C++ Compiler. Es hat auch nichts mit Overloading in C zu tun, da es kein C ist, sondern nur, wie Overloading in C++ (ist ne andere Sprache) nach C durch einen Praeprozessor realisiert werden koennte.
den "lightwight c++" Text an der Website konnte ich auch lesen. Krank bleibt dennoch krank.
-
dann kann man ja auch gleich behaupten: das vergeben von verschiedenen funktionsnamen ist krank.
-
Was ist eigentlich mit der Möglichkeit, dass man in C programmiert, aber einen C++ Kompiler verwendet? Oder wäre das ein Pakt mit dem Teufel?
Grüssli
-
im so ill schrieb:
dann kann man ja auch gleich behaupten: das vergeben von verschiedenen funktionsnamen ist krank.
nö, die sind ja verschieden, d.h. eindeutig. ich hatte gerade erst 'ne tolle fehlermeldung:
1>c:\qmls-0.2\qmls\mccluskey.cpp(203) : error C2668: 'pow' : ambiguous call to overloaded function
1> c:\programme\microsoft visual studio 8\vc\include\math.h(575): could be 'long double pow(long double,int)'
1> c:\programme\microsoft visual studio 8\vc\include\math.h(573): or 'long double pow(long double,long double)'
1> c:\programme\microsoft visual studio 8\vc\include\math.h(527): or 'float pow(float,int)'
1> c:\programme\microsoft visual studio 8\vc\include\math.h(525): or 'float pow(float,float)'
1> c:\programme\microsoft visual studio 8\vc\include\math.h(489): or 'double pow(double,int)'
1> c:\programme\microsoft visual studio 8\vc\include\math.h(123): or 'double pow(double,double)'
1> while trying to match the argument list '(int, unsigned int)'^^weil es mehrere 'pows' gibt.
Dravere schrieb:
Was ist eigentlich mit der Möglichkeit, dass man in C programmiert, aber einen C++ Kompiler verwendet?
ganz schlechte idee, das geht selten gut.
-
+fricky schrieb:
pointercrash() schrieb:
Die andere Möglichkeit, die schon kurz angesprochen wurde, wäre selbstmodifizierender Code...
das wäre aber kein überladen. überladung ist doch 'ne ziemlich starre geschichte, bei der so'n compiler sich die funktion aussucht, die seiner meinung nach (argumentenliste usw.) am besten passen würde. selbstmodifizierender code geht mehr in richtung 'reflection'. aber noch was: man kann in C funktionen beim linken überladen. hab' ich schon mal gemacht.
Irrtum! Selbstreflektierender Code hat gar nichts mit SMC zu tun. SMC ist dann gegeben, wenn sich der Code selber zur Laufzeit verändert. Bei mir sah das so aus, daß ich nur ein 32-Byte- Fenster zur Verfügung hatte, um mit einem schnellen Bustiming (Zeropage- Zugriffe) einen Baustein auszulesen, bereits ein Return hätte den Inhalt verworfen. Also hab' ich mir was gebastelt, das nach dem ersten und zweiten Durchlauf ein paar Opcodes ausgewechselt hat, inklusive die durch eine per jmp gebildete Endlosschleife in einen Rücksprung per rts- Opcode umzuwandeln. :p
SMC ist also Überladung zur Laufzeit, geht aber nur auf Von-Neumann- Architekturen bzw. auf Opcode- Ebene. Sowas kann kein Compiler
Die selbstoptimierenden Systeme sind eher Spielzeuge der KI- Forschung und nutzen ganz andere Mechanismen, die man eher als Selbstparametrierung bezeichnen kann.Auf Linker- Ebene Libs zu tauschen ist für Embedded- Fuzzis übrigens eher Tagesgeschäft als was Besonderes und mit pragmas mußte ich mich da noch nie abplagen. Meist geht es da um die stdio- Geschichten, die meist stdin und stdout genau dahin schicken, wo Du's überhaupt nicht brauchen kannst
. Früher hatte ich so einen Library Manager, wo man beliebig Libs versionieren und angeben konnte, welche zugelinkt werden sollen, bei manchen "modernen" IDEs geht das in abgespeckter Form über den Debug/Release- Mechanismus (von wegen Fortschritt - ha!), aber dicker Schwur: Pragma- Gedöns war noch nie nötig.
Nur: Mit Überladung hat das auch nicht wirklich zu tun.Einzig eine Geschichte, die zumindest nah dran kommt, fällt mir jetzt noch ein: Funktionen ersetzen durch Macros, das geht auch prima temporär über include guards gesteuert. Wohl nicht ganz so flexibel wie "echtes" Überladen in C++, aber ich bin immer wieder erstaunt, was man damit so alles machen kann. Was mich dennoch daran ärgert: Bei vielen Compilern kriege ich das aufgelöste Macro- Zeugs nur über Umwege zu Gesicht, bei einigen sogar gar nicht. Geht da was schief, ist Spaß beim Rätseln angesagt.