Überladen / Überschreiben von Funktionen in C möglich?
-
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.
-
+fricky schrieb:
gibts schon: http://de.wikipedia.org/wiki/Embedded_C%2B%2B
finden aber alle doof, selbst stroustrup.Nicht wirklich das, was ich gesagt habe. Nicht nur, dass hier ein anderer Standard genommen wird, es wird sogar Objektorientierung unterstützt. Ist es wirklich so schwer zu verstehen, was ich meine?
Naja, vielleicht sollte ich die Frage mal von einer anderen Richtung aus setzen. Wenn ich mich allerdings von der anderen Seite annähere, dann hat es nichts mehr mit C zu tun. Aber ich frage jetzt trotzdem mal:
Wieso wird eigentlich unter C++ nicht auch prozedural programmiert? Man hat diese Möglichkeiten unter C++ genauso wie in C. Wieso verwenden die Leute C und nicht C++? Nur wegen dem ABI? Was sind die Vorteile von C bei der prozeduralen Programmierung gegenüber C++?Ich möchte hier keinen Flameware starten. Es interessiert mich wirklich einfach nur. Das ist eine Frage, welche ich mir schon lange stelle.
Grüssli
-
Dravere schrieb:
Was sind die Vorteile von C bei der prozeduralen Programmierung gegenüber C++?
Ich möchte kurz anmerken, dass man natürlich auch in C objektorientiert programmieren kann (man muss halt nur auf Dinge wie Vererbung usw. verzichten). Ansonsten ist das aber eine interessante Frage und ich bin auf die Antworten gespannt.
-
_matze schrieb:
objektorientiert programmieren kann (man muss halt nur auf Dinge wie Vererbung usw. verzichten)
Brüller des Tages
-
Dravere schrieb:
Was sind die Vorteile von C bei der prozeduralen Programmierung gegenüber C++?
weil C++ gegenüber C keinen vorteil bringt, wenn man nicht objektorientiert programmieren will. C++ hat redundante 'features' wie referenzen (C hat schon pointer), doppelte dyn. speicherverwerwaltung (malloc/free vs. new/delete/delete[]), usw. funktions- und operatorüberladung, die kaum nutzen bringen, aber verwirrung stiften können. ausserdem die inkompatibilitäten zu bestehendem C-code (C|sizeof('a') != C++|sizeof('a')), der void* in C++ ist so ziemlich verkrüppelt, etc. deshalb macht es keinen sinn, nur das C in C++ zu benutzen.
_matze schrieb:
Ich möchte kurz anmerken, dass man natürlich auch in C objektorientiert programmieren kann...
klar, aber ein durch und durch objektorientiertes programm, würde ich nicht in C coden wollen (ausser es muss sehr maschinennah sein). in C++ aber auch nicht.
-
Ich habs gut, ich kann kein C++ programmieren, also kommt beim mir auch kein Mischmasch raus.
-
Die, bei denen Mischmasch rauskommt, können auch kein C++ programmieren :p
-
c+++ noob schrieb:
Ich habs gut, ich kann kein C++ programmieren, also kommt beim mir auch kein Mischmasch raus.
ich kann c++ grundlagen. mag aber c lieber :p
- nur echt mit zweimal ascii 48
-
+fricky schrieb:
gibts schon: http://de.wikipedia.org/wiki/Embedded_C%2B%2B
finden aber alle doof, selbst stroustrup.Hmm, was haltet ihr von Objective C? Das wäre so eine Geschichte, die anders als C++ die C- Wurzeln nicht tangieren, aber ein Objektkonzept à la Smalltalk zuliefern würde. Kann man nutzen oder auch nicht. Dank MacOS X ist das sogar halbwegs verbreitet.
Leider habe ich im embedded- Bereich keinen freien, brauchbaren Compiler dafür gefunden (stattdessen verstärkt C/C++, ich sehe schon die Zahl der Zombie- Projekte wachsen) und alleine zum Probieren schaff' ich mir nix dergleichen an.
Hat jemand dazu schon Erfahrungen gesammeltBashar schrieb:
Die, bei denen Mischmasch rauskommt, können auch kein C++ programmieren :p
Das ist ein vernichtendes Urteil über viele Poster im C++- Forum, sei mal angemerkt ...
