Überladen / Überschreiben von Funktionen in C möglich?
-
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.
-
pointercrash() schrieb:
Irrtum! Selbstreflektierender Code hat gar nichts mit SMC zu tun. SMC ist dann gegeben, wenn sich der Code selber zur Laufzeit verändert.
--> Reflection can be used for [...] modifying program execution at runtime. http://en.wikipedia.org/wiki/Reflection_(computer_science)
pointercrash() schrieb:
...Wohl nicht ganz so flexibel wie "echtes" Überladen in C++...
2 post darüber siehst du ja, wie 'flexibel' es ist.
-
pointercrash() schrieb:
SMC ist also Überladung zur Laufzeit
Nö, das ist überhaupt keine Überladung, sondern Überschreiben (sorry, schlechte deutsche Version von overriding). Hat zwar schon jemand in dem Thread geschrieben, aber es wurde anscheinend ignoriert ...
-
+fricky schrieb:
--> Reflection can be used for [...] modifying program execution at runtime. http://en.wikipedia.org/wiki/Reflection_(computer_science)
Ja, stimmt, da steht "modifying program execution" und nicht "modifying executable programs". Das basiert alles auf Erweiterung zur Laufzeit und ist spätestens seit LISP ein alter Hut. Ist aber was anderes, den eigenen Code zur Laufzeit zu ändern, als zur Laufzeit neuen Code zu integrieren und ggf. statt alten Codes auszuführen.
Bashar schrieb:
Nö, das ist überhaupt keine Überladung, sondern Überschreiben ...
Ich modifiziere mehrfach zur Laufzeit je nach Bedarf einen Teil des Codes, tausche Methodenteile sowie Parameter aus. So unterschiedlich ist das also nicht. Als Merkmal eher, ob es zur Compiletime oder zur Runtime passiert?
Wird aber sehr vielosofisch ...
-
pointercrash() schrieb:
Bashar schrieb:
Nö, das ist überhaupt keine Überladung, sondern Überschreiben ...
Ich modifiziere mehrfach zur Laufzeit je nach Bedarf einen Teil des Codes, tausche Methodenteile sowie Parameter aus. So unterschiedlich ist das also nicht. Als Merkmal eher, ob es zur Compiletime oder zur Runtime passiert?
Ich kann mich nur wiederholen. Überladen bedeutet, dass mehrere Funktionen denselben Namen haben und je nach Argumentzahl und -typen unterschieden wird, welche davon aufgerufen wird. Das kann man theoretisch auch zur Laufzeit machen (Multiple Dispatch ala CLOS, auch wenn das normalerweise nicht Überladen genannt wird).
Eine Implementierung zu überschreiben, sei es zur Compilezeit, zur Linkzeit oder zur Laufzeit, ist kein Überladen.
-
+fricky schrieb:
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.
Darf ich da mal um eine genauere Erläuterung bitten? Würde mich persönlich interessieren. Abgesehen vom Verlust der ABI, welche allerdings über
extern "C"auch wieder verwendet werden könnte, was gibt es noch für Nachteile?Grüssli
-
Dravere schrieb:
Darf ich da mal um eine genauere Erläuterung bitten? Würde mich persönlich interessieren.
Da gibt es schon etliche "Stolpersteine", ob der Compiler mit "extern C" alles berücksichtigt - who knows
Zudem verleitet es dazu, C und C++ zu mischen, eine der sichersten Möglichkeiten, ein Projekt schnellstmöglich in die Unwartbarkeit zu bringen ...
-
pointercrash() schrieb:
Ist aber was anderes, den eigenen Code zur Laufzeit zu ändern, als zur Laufzeit neuen Code zu integrieren und ggf. statt alten Codes auszuführen.
wo siehst du da einen grossen unterschied? wenn das eine möglich ist, dann geht doch auch das andere.
Dravere schrieb:
Darf ich da mal um eine genauere Erläuterung bitten?
pc() war schneller, sonst hätte ich genau seinen link gebracht.
-
pointercrash() schrieb:
Da gibt es schon etliche "Stolpersteine", ob der Compiler mit "extern C" alles berücksichtigt - who knows
Die Seite kenne ich schon. Aber mal ehrlich, welche Kompiler unterstützen bereits C99? Ich dachte, dass die Unterstützung bis heute äusserst schwach wäre. Habe mich aber nun auch wieder länger nicht mehr damit beschäftigt, da ich eher selten in C programmiere
Und die Unterschiede zwischen C90 und dem C in C++98 sind wohl eher minimal. Es gehen halt gewisse Dinge einfach leichter, wodurch man allerdings eben die ABI einbüsst und nur überextern "C"wiedergewinnen kann.Zudem würde man ja eben bewusst nicht mehr in reinem C programmieren, sondern halt eben das C aus C++ verwenden. Somit sich völlig von den C Kompilern abwenden.
pointercrash() schrieb:
Zudem verleitet es dazu, C und C++ zu mischen, eine der sichersten Möglichkeiten, ein Projekt schnellstmöglich in die Unwartbarkeit zu bringen ...
Das Argument ist in meinen Augen irgendwie nichts Wert. Das könnte man dann jedem C++ Programmierer vorhalten und deswegen dürfte man nicht mehr in C++ programmieren
Jeder ist selber dafür verantwortlich, wie er programmiert. Wieso also nicht ein C mit ein paar zusätzlichen C++ Möglichkeiten, wie zum Beispiel Funktionsüberladung?Ich bin auch gegen eine völlige Vermischung der beiden Sprachen, aber wie man in C++ zum Teil auf C Funktionen zurückgreifen kann, so wäre es doch auch nicht verkehrt, wenn man in C auf gewisse Features von C++ zugreifen kann. Auch Referenzen, wären doch durchaus was nettes
Grundsätzlich wäre es eine Art von prozedurales Programmieren unter C++. Wieso nicht?Grüssli
-
+fricky schrieb:
pointercrash() schrieb:
Ist aber was anderes, den eigenen Code zur Laufzeit zu ändern, als zur Laufzeit neuen Code zu integrieren und ggf. statt alten Codes auszuführen.
wo siehst du da einen grossen unterschied? wenn das eine möglich ist, dann geht doch auch das andere.
Reflection ist eher Daten-basiert, d.h. du manipulierst irgendwelche Metadaten, am Ende effektiv Funktionszeiger, um das Verhalten zu ändern. Klar, du musst den neuen Code laden und den alten entladen, aber das wars in der Hinsicht. Du änderst nicht direkt den bestehenden Maschinencode.
Das ist allerdings in Lisp auch nicht anders. Da kommt nur noch dynamisches Codegenerieren dazu, also man bastelt sich eine Liste, die die gewünschte Funktion darstellt, und ruft darauf COMPILE auf. Das Einhängen des neuen Codes in das Programm ist dann aber wieder nur Zeiger umbiegen.
Echte Selbstmodifikation, dass man also bestehende Maschinenbefehle abändert, ist selten.
-
Dravere schrieb:
Aber mal ehrlich, welche Kompiler unterstützen bereits C99?
keil, tasking, greenhills, metrowerks/freescale, iar, watcom, pelles-c, gcc, usw. reicht das?
Dravere schrieb:
Zudem würde man ja eben bewusst nicht mehr in reinem C programmieren, sondern halt eben das C aus C++ verwenden. Somit sich völlig von den C Kompilern abwenden.
unakzeptabel. google mal nach 'the spirit of C'. das ist z.b. einer der gründe, warum C nicht durch C++ ersetzt werden kann. C++ hat sich zu weit davon entfernt. ah, hier: http://www.lysator.liu.se/c/rat/a.html C ist primitiver, maschinenaher, übersichtlicher und einfacher strukturiert als C++, aber es reicht selbst für grosse projekte (linux/windows kernels etc.). zudem ist C code fast immer schlank und schnell. C++ hat ausserdem zig mal mehr macken als C. daher hat C, alles zusammengenommen, einen besseren 'wirkungsgrad' als C++.
Dravere schrieb:
pointercrash() schrieb:
Zudem verleitet es dazu, C und C++ zu mischen, eine der sichersten Möglichkeiten, ein Projekt schnellstmöglich in die Unwartbarkeit zu bringen ...
Das Argument ist in meinen Augen irgendwie nichts Wert. Das könnte man dann jedem C++ Programmierer vorhalten und deswegen dürfte man nicht mehr in C++ programmieren.
richtig. wer in C++ wie in C programmiert, sollte vielleicht überlegen, ob C für ihn (oder für dieses projekt) nicht vielleicht besser wäre.
-
was bedeutet ABI?
mfg,
A.n.
-
ABI n00b schrieb:
was bedeutet ABI?
abitur? ne, das: http://de.wikipedia.org/wiki/Binärschnittstelle
-
Dravere schrieb:
Ich bin auch gegen eine völlige Vermischung der beiden Sprachen, aber wie man in C++ zum Teil auf C Funktionen zurückgreifen kann, so wäre es doch auch nicht verkehrt, wenn man in C auf gewisse Features von C++ zugreifen kann. Auch Referenzen, wären doch durchaus was nettes
Grundsätzlich wäre es eine Art von prozedurales Programmieren unter C++. Wieso nicht?Wenn Du schon die "netten kleinen Unterschiede" kennst, weshalb fragst Du? Wahrscheinlich hast Du noch kein "MixedPickles"- Projekt von jemand anderem übernommen oder das versucht.
Wenn ich innerhalb von 20 Zeilen "new" und "realloc" lese, kommt mir das kalte Kotzen. Der Code, der da drin steckt, ist meist voll an den Compiler gebunden mit dem er erstellt wurde. Damit ist ein Hauptvorteil von C/C++ kaputt, die Source- Kompatibilität kannst Du vergessen.Die GUI in C++, der funktionale Unterbau in C, sowas kann schon OK sein, wenn es gescheit spezifiziert wurde.
Aber ein Durcheinander bedeutet bei Projektübergabe einen gewaltigen Einarbeitungsaufwand. Unternehmen können sich sowas i.a.R. nicht leisten, daß sich jemand seine "Mixsprache" generiert und wenn es doch passiert ist, wird sich kaum jemand finden lassen, das auf einen allgemein lesbaren Zustand zu bringen.
-
nachtrag:
Dravere schrieb:
...so wäre es doch auch nicht verkehrt, wenn man in C auf gewisse Features von C++ zugreifen kann. Auch Referenzen, wären doch durchaus was nettes
wozu? C hat doch pointer.
-
pointercrash() schrieb:
...
Wenn ich innerhalb von 20 Zeilen "new" und "realloc" lese, kommt mir das kalte Kotzen. Der Code, der da drin steckt, ist meist voll an den Compiler gebunden mit dem er erstellt wurde...Häh
realloc ist nicht standard?
-
-
pointercrash() schrieb:
Du noch kein "MixedPickles"- Projekt von jemand anderem übernommen oder das versucht.
Korrekt, wobei ich auch kein C/C++ Mischmasch vorschlage.
pointercrash() schrieb:
Wenn ich innerhalb von 20 Zeilen "new" und "realloc" lese, kommt mir das kalte Kotzen.
Genau das will ich ja nicht. Ich meinte eigentlich, einen C++ Compiler und nur die C Header, also nur malloc, free, printf, usw. das übliche C Zeug halt. Und einfach noch dazu ein paar wenige Features von C++, wie Referenzen, Überladung oder angenehme Schreibweise von structs. Aber keine STL, keine C++ Standardbibliothek, keine Klassen, keine Namespaces, keine Templates usw.
pointercrash() schrieb:
Der Code, der da drin steckt, ist meist voll an den Compiler gebunden mit dem er erstellt wurde. Damit ist ein Hauptvorteil von C/C++ kaputt, die Source- Kompatibilität kannst Du vergessen.
Diese Aussage verstehe ich allerdings überhaupt nicht. Ausser du hattest im Hinterkopf wirklich ein völliger Mischmasch von C und C++, aber das hatte ich ja eigentlich bereits gesagt, dass ich dies nicht meine.
Grüssli
-
Dravere schrieb:
Ich meinte eigentlich, einen C++ Compiler und nur die C Header, also nur malloc, free, printf, usw. das übliche C Zeug halt. Und einfach noch dazu ein paar wenige Features von C++, wie Referenzen, Überladung oder angenehme Schreibweise von structs. Aber keine STL, keine C++ Standardbibliothek, keine Klassen, keine Namespaces, keine Templates usw.
gibts schon: http://de.wikipedia.org/wiki/Embedded_C%2B%2B
finden aber alle doof, selbst stroustrup.
