Überladen / Überschreiben von Funktionen in C möglich?
-
+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 ...
-
+fricky schrieb:
C++ hat redundante 'features' wie referenzen (C hat schon pointer), ...
Das kann man wohl kaum als Argument bringen, da es so subjektiv ist.
+fricky schrieb:
... doppelte dyn. speicherverwerwaltung (malloc/free vs. new/delete/delete[]), ...
Ich sage immer wieder, dass ich keinen Mischmasch meine und ihr mixt die Sache immer wieder. Wieso wollt ihr die Sprachen immer mixen?
+fricky schrieb:
... usw. funktions- und operatorüberladung, die kaum nutzen bringen, aber verwirrung stiften können.
Wieder kein Argument, da es so extrem subjektiv ist.
+fricky schrieb:
ausserdem die inkompatibilitäten zu bestehendem C-code (C|sizeof('a') != C++|sizeof('a')), ...
Man will ja auch keine Kompabilität. Es ging bei dieser Frage um, entweder rein prozedural in C oder rein prozedural in C++. Nichts dazwischen und nichts untereinander.
+fricky schrieb:
... der void* in C++ ist so ziemlich verkrüppelt, ...
Das ist höchstens ein Argument, wieso man nicht C mit einem C++ Kompiler verwenden sollte. Wobei so extrem schlimm verkrüppelt finde ich es nicht. Es werden schlicht ein paar implizite Cast nicht unterstützt.
Wenn aber, wie in der zweiten Frage, die Trennung gemacht wird, also prozedural C mit C Kompiler gegenüber prozedural C++ mit C++ Kompiler, dann ist das Argument nichtig.+fricky schrieb:
etc. deshalb macht es keinen sinn, nur das C in C++ zu benutzen.
Finde ich nicht wirklich überzeugend. Aber du hast auch ein wenig neben meiner Frage durchgeantwortet. In meiner letzten Frage ging es um diesen Vergleich:
- prozedural C mit C Kompiler
- prozedural C++ mit C++ KompilerIch hoffe es ist jetzt verständlich, was ich eigentlich meinte. Ich kann gewisse Argument verstehen, wieso man kein prozedural C mit C++ Kompiler machen möchte, aber was ist das Argument gegen prozedural C++ mit C++ Kompiler? C++ hat viel mehr Möglichkeiten, auch für das prozedurale Programmieren. Wieso wird immer noch C genommen? Nur wegen ABI? Was gibt es noch, ausser subjektive Argumente?
Grüssli
-
Dravere schrieb:
C++ hat viel mehr Möglichkeiten, auch für das prozedurale Programmieren.
und welche?
