Schlanke Programme mit C++
-
fricky schrieb:
...welche den kleinen nachteil hat, (mal abgesehen von der ätzenden syntax) dass das codegenerator-skript und der zu kompilierendes quelltext das selbe sind. falls da 'n fehler drin ist, so dass es nicht kompiliert, könnten die fehlermeldungen ziemlich haarig sein
Momentan mit dem cpp ist es doch viel schlimmer. Ein neuer besserer Präprozessor könnte typsicher sein, die eingebauten Typen der Sprache kennen etc. und so schon Fehler aufzeigen während der Präprozessorlauf stattfindet. Einfache Textersetzung wie bisher sollte abgeschafft werden.
fricky schrieb:
und falls es kompiliert, aber trotzdem ein bug drin ist, dürfte debugging auf quelltext-ebene unmöglich sein (mit fiesen preprocessor-makros ist es aber auch nicht besser).
Es spricht nichts dagegen eine Zweiphasen Compilieren einzuführen, dann wäre das Problem aus der Welt. (Früher wurde auf einem UNIX cpp und cc immer getrennt aufgerufen.)
fricky schrieb:
für 'generative programming' finde ich, eigenen sich tools besser, die aus einer pseudo-sprache
Solche Werkzeuge haben den großen Nachteil, daß sie nicht gut mit der Zielsprache harmonieren. Es fehlt hier die enge Verknüpfung zwischen den Typsystemen. C++ Templates sind deshalb so ein mächtiges Werkzeug, weil sie direkt in C++ zur Verfügung stehen. Wie willst Du typsicher z.B. Typelisten im Präprozessor bearbeiten, wenn dieser das C++ Typsystem gar nicht kennt?
-
~john schrieb:
Es spricht nichts dagegen eine Zweiphasen Compilieren einzuführen, dann wäre das Problem aus der Welt. (Früher wurde auf einem UNIX cpp und cc immer getrennt aufgerufen.)
das gibts heute auch noch, naja, teilweise jedenfalls: http://www.comeaucomputing.com/faqs/genfaq.html#ccompiler
~john schrieb:
fricky schrieb:
für 'generative programming' finde ich, eigenen sich tools besser, die aus einer pseudo-sprache
Solche Werkzeuge haben den großen Nachteil, daß sie nicht gut mit der Zielsprache harmonieren. Es fehlt hier die enge Verknüpfung zwischen den Typsystemen.
das macht aber nichts. um das typsystem der zielsprache, u.ä. plattformabhängige dinge, muss man sich im idealfall nicht kümmern, weil man auf einer anderen ebene 'programmiert'. z.b. dieses tool hier: http://legacy.imatix.com/html/libero/ kann code für 13 verschiedene programmiersprachen erzeugen.
-
fricky schrieb:
muss man sich im idealfall nicht kümmern, weil man auf einer anderen ebene 'programmiert'.
Mit einer GUI-Applikation ist man immer sehr in den Möglichkeiten beschränkt. Man kann Code generieren für bestimmte Problemstellungen, aber richtige Meta-Programmierung ist nicht möglich. Man muß dann zwangsweise wieder auf das Schreiben von Programmcode zurückgreifen. Wenn man Programme schreibt die Programme erzeugen so ist sinnvoll, daß die verwendete Programmiersprache Konzepte, Typen etc. der generierten Programmiersprache kennt, und man so schon Fehler im Metaprogramm erkennen kann.
Wenn man die schon vorher angesprochenen Typlisten als Sprachkonstrukt für den Präprozessor einführt, so ist das wünschenswert diese Typlisten zum Beispiel auf Typen mit gemeinsamen Konzepten zu beschränken. Und ein Fehler sollte dann schon beim Einfügeversuch in diese spezielle Typlisten auftreten und nicht erst viel später beim Übersetzen des resultierenden Programmcodes.
-
Hi,
rüdiger schrieb:
btw. Es gibt ja Einen Vorschlag dafür C++ eine neue Syntax zu verpassen. Man müsste dafür nur ein Compiler-Frontend oder ein "Neue-Syntax in Alte-Syntax"-Compiler schreiben.
Ich sehe nicht so ganz, worin der Sinn dieser neuen Syntax liegen sollte. Diese Sprache gibts bereits und die heißt Delphi.
Auch verstehe ich einge Gründe gegen C++ nicht. Das schöne an C++ ist ja, daß ich ganz nach jeweiligem Zweck wahlweise eine kleine Untermenge von C oder abgestuft andere Mittel bis hin zum vollen Sprachumfang von C++ nutzen kann.
C++ ist ein Angebotr, und kein Muss.
Man kann problemlos in den hardwarenahen Schichten fast reines C benutzen und damit alle Performancevorteile dieser Sprache haben und gleichzeitig durch Namensräume trotzdem übersichtlichen und handelbaren Code schreiben.
Andererseits kann man in den oberen Schichten beliebig weit abstrahierten Code verwenden ohne die Sprache wechseln zu müssen.Gruß Mümmel
-
Die C++ Syntax hat einige Probleme. Deswegen überlegen sich Leute daran zu schrauben. Außerdem kannst du die Syntax nicht als Delphi pauschal abstempeln, nur weil Operatoren die gleiche Bedeutung haben.
-
muemmel schrieb:
Auch verstehe ich einge Gründe gegen C++ nicht.
schau z.b. mal hier:
http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918
-
Hi Zeus,
Delphi ist viel näher an C++ als Du denkst. Es sind zwei Dialekte, die an sich fast das gleiche sagen. Borlands C++Builder und Delphi unterschieden sich nur im Parser, alles was danach kam war für beide Sprachen identisch. (obs bei RAD noch genau so ist weiß ich nicht). Auch ist Delphi mit den verschiedenen Versionen immer näher an C++ rangerückt. (Beispiel continue und break in Schleifen). Es stellt sich die Frage, ob es nicht auch in Delphi möglich sein sollte, komplette Betriebssysteme zu schreiben.
Wenn Delphi auch in den Möglichkeiten nicht so weit geht wie C++, so ist es in mancher Beziehung doch ein moderneres C++.
Generell gilt aber, wenn man einen Alleskönner haben will, dan muß man Zugeständnisse in den Handlichkeit machen. Das war schon mit Algol68 und PL1 so und ist es auch mit Ada und C++.
Sicher kann man die Syntax von C++ verbessern. Schon Kernighan und Ritchie sowie auch Stroustrup gaben zu, daß da einiges besser hätte sein können. Aber das ist halt der Preis, wenn man kompatibel bleiben will.
Ein C++ mit veränderter Syntax würde für lange Zeit mehr Fehlerquellen reinbringen und die Übersichtlichkeit verringern und Compiler die beide Varianten verstehen müssen verkomplizieren und verteuern. Und Programmierer müssten dann mit zwei Sprachen, die im Grunde nur eine sind, leben.
Dann lieber für große Projekte C++ und für kleinere Dephi.Gruß Mümmel
-
muemmel schrieb:
Es stellt sich die Frage, ob es nicht auch in Delphi möglich sein sollte, komplette Betriebssysteme zu schreiben.
es soll schon leute gegeben haben, die windows-gerätetreiber mit delphi geschrieben haben. also, warum nicht?
-
Hi Fricky,
war dämlich formuliert von mir. sollte eigentlich heißen, obs nicht auch mit Delphi sinnvoll wäre.
Gruß Mümmel
-
sinnvoll ist grundsätzlich erstmal alles, was geht
allerdings würden für mich einige gründe dagegen sprechen. diese sprache ist leider fest in der hand von borland (jetzt in verantwortung von codegear?), nicht standardisiert, ändert sich fast jedes jahr, und die mangelnde unterstützung für andere betriebssysteme hat ihr übriges getan mich von ihr wieder abzuwenden. aus diesen gründen geht auch unmittelbar hervor, das es noch keine vernünftige freie alternative für einen delphi compiler gibt. und c# wirds denke ich mal in zukunft ähnlich ergehen, es sei denn jemand setzt sich endlich mal hin und schreibt ein backend, welches nativen code erstellen kann
-
muemmel schrieb:
Hi Zeus,
Delphi ist viel näher an C++ als Du denkst. Es sind zwei Dialekte, die an sich fast das gleiche sagen. Borlands C++Builder und Delphi unterschieden sich nur im Parser, alles was danach kam war für beide Sprachen identisch.
Argh, eine Sprache ist eine Menge aus Regeln, die man Grammatik nennt - kurz gesagt, um die geht es mir. Nicht um den Output des Compiler. Der ist bei GCC wohl immer der gleiche, ob ich nun ein C++, C, Fortran, Ada oder Java-FrontEnd vom gcc nutzte.
-
Hi,
ist mir schon klar, was Du meinst Zeus, aber bei Delpi und C++Builder sind nicht nur die Ergebnisse identisch, sondern mit Ausnahme des Parsers auch die gesamte Verarbeitung. Die Sprachen selber sind auch recht verwandt. In vielen Dingen ist Delphi schon fast ein C++ in Pascalnotation.
Gegenüber C++ hat Delphi auch ein paar Vorteile, z.B. Bereiche bei Case, Threadunterstützung, elegantes Exception-Handling,
Die VCL mit ihren vielen Möglichkeiten die im vollen Quelltext vorliegt, einschleißlich der Möglichkeit eigene Komponenten zu genrieren und wie eigene zu verwenden ist auch toll. Mit dem String-Typ von Delphi kann man auch recht gut leben...
Was mir bei Delphi gut gefällt sind die internen Functionen.
Was mir dagegen fehlt sind die += bzw. ++ Operatoren sowie der bedingte Operator. Die ermöglichen es Schreibarbeit zu sparen und sinnvoll eingesetzt vermögen sie einen Quelltext übersichtlicher zu gestalten.
Für kleinere Projekte ist Delphi einfach handlicher. Für Großprojekte kommt es dagegen noch nicht so ganz mit C++ mit.
Daß Delphi in einer Hand ist sehe ich als gar nicht so schlecht an, das hat auch Java gut getan. Ein bisschen verderben auch bei Programmiersprachen zu viele Köche den Brei.
Die Änderungen der Sprache sind eigentlich von den absoluten Anfängen abgesehen immer so, daß es kein Problem darstellt alte Quelltexte nach neuer zu portieren.Gruß Mümmel
-
muemmel schrieb:
Hi,
ist mir schon klar, was Du meinst Zeus, aber bei Delpi und C++Builder sind nicht nur die Ergebnisse identisch, sondern mit Ausnahme des Parsers auch die gesamte Verarbeitung.
Und dem Scanner und der Fehlerbehandlung. Und das Ergebnis aus dem Parser geht dann in den Backend des Compilers :o