Schlanke Programme mit C++

[rüdiger]

Shade Of Mine schrieb:

rüdiger schrieb:

was sind deiner meinung nach dann die probleme von c++?

Die Grammatik ist imho das größte Problem. Daher gibt es für C++ leider nur sehr bescheidene Werkzeuge (trifft auch auf C zu). Ansonsten gibt es einige "Detail-Probleme". In Stephanovs Notes findet man eine ziemlich gute C++-Kritik imho.

Einige Sachen, die du ansprichst, kommen eben daher, dass es C++ schon lange gibt. Die Sprache hat sich entwickelt und mit der Sprache die Programmierer. Außerdem ist C++ sehr flexibel. Der Programmierstil verfeinert sich und es gibt immer wieder neue Konzepte, Stile und Bibliotheken, die einfach komplett neue und interessante Paradigmen einführen. Daher ist eine Bibliothek, die in den 90ern entworfen wurde, aus heutiger Sicht angestaubt (Qt, wxWidgets, MFC, VCL etc.). Aber das ist eigentlich kein schlimmes Problem, da man sich ja nicht mit solchen Libraries verwurschteln muss.

Shade Of Mine schrieb:

imho sind die ganzen dialekte die jeder compiler mitbringt ein problem da es schwer ist standardisierte tools dadrauf zu setzen. und die portabilitaet ist ja quasi nur mit dem gleichen compiler gegeben da viele systemabhaengige sachen wie zB calling conventions oder padding bytes oder sonstige attribute von jedem compiler syntaktisch anders geloest werden.

Das sehe ich als kein großes Problem an.

Shade Of Mine schrieb:

die inselloesungen bei libraries bindet mich an bestimmte firmen. wenn ich zB cross plattform anwendungen entwickeln will kann ich zwischen wxWidgets, Qt und gtkmm entscheiden - diese 3 bieten mir eine vernuenftige plattform. dabei fallen gtkmm und wxWidgets wegen windows respektive mac os weg, da sie dort nicht gut genug laufen. haben wir Qt oder uU auch eine andere Insel -> keine standardisierten tools dafuer. bei java habe ich standardisierte libraries was code generation enorm vereinfacht und ich kann problemlos die plattform wechseln und bin nicht an Sun gebunden da ich eine andere jvm nehmen kann.

GUI ist einfach nichts wirklich(!) Plattform unabhängiges. Klar kann man allen möglichen Systemen eine GUI aufzwingen, aber das ist keine gute Lösung. Die meisten Leute kommen eben nicht damit klar, wenn eine Anwendung sich etwas anders verhält. Aus dem Grund werden die meisten (professionellen) Anwendungen eben doch mit einer systemabhängigen GUI versehen.

So etwas wie Adobes Adam&Eve ist da eher der richtige Ansatz. Aber das muss ja kein Teil des Standards sein. Für so etwas kann man eben gerne eine Library nehmen. Es liegt dann natürlich am Programmierer, in wie fern man sich an fette Komponenten bindet oder zB via Adam&Eve den eigenen Code sauber von der fetten GUI-Lib trennt.

Shade Of Mine schrieb:

und dass eine standardisierte abi fehlt ist halt furchtbar wenn es um interop geht. man muss hoellisch mit den compilern aufpassen dass man wirklich immer eine kompatible abi hat. das erschwert es mit dlls/shared objects zu arbeiten und das ist aergerlich.

Ne, eine standardisierte ABI sollte nicht Teil des C++-Standards sein. Da so etwas zu stark vom System abhängt. Aber die Probleme die du ansprichst, liegen einfach an der Idiotie der Windows C++-Compiler Entwickler. Unter Linux gibt es zB eine einheitliche ABI.

[rüdiger]

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.

[fricky]

Strolch schrieb:

Nehmen wir mal die Bitgröße von nativen Datentypen an: ich kann sie doch über <limits> in meinem C++ abfragen und somit darauf reagieren. Es ist ja nicht so, das ich von C++ im Stich gelassen werde.

naja, du kannst aber nicht den typ einer variablen davon abhängig machen.

if (UINT_MAX  < 4294967295)
  long variable;
else
  int variable;

^^geht nicht. (übrigens, Artchi, wieso postest du nicht mit deinem mitglieds-namen?)

rüdiger schrieb:

btw. Es gibt ja Einen Vorschlag dafür C++ eine neue Syntax zu verpassen.

aha, aus * (pointer) wird ^, aus = wird := und == wird zu = (wie pascal).
was bringen solche änderungen?

[rüdiger]

fricky schrieb:

Strolch schrieb:

Nehmen wir mal die Bitgröße von nativen Datentypen an: ich kann sie doch über <limits> in meinem C++ abfragen und somit darauf reagieren. Es ist ja nicht so, das ich von C++ im Stich gelassen werde.

naja, du kannst aber nicht den typ einer variablen davon abhängig machen.

if (UINT_MAX  < 4294967295)
  long variable;
else
  int variable;

^^geht nicht. (übrigens, Artchi, wieso postest du nicht mit deinem mitglieds-namen?)

typedef boost::int_max_value_t<4294967295>::fast big_enough_int_t;

big_enough_int_t variable;

oder direkt

typedef boost::int_t<32>::fast big_enough_int_t;

rüdiger schrieb:

btw. Es gibt ja Einen Vorschlag dafür C++ eine neue Syntax zu verpassen.

aha, aus * (pointer) wird ^, aus = wird := und == wird zu = (wie pascal).
was bringen solche änderungen?

Die anderen Änderungen sind wohl wichtiger :p

[Tachyon]

sothis_ schrieb:

Tachyon schrieb:

sothis_ schrieb:

Tachyon schrieb:

Warum?

weil das seit C99 der vergangenheit angehört.

C99, ja... und das haben auch so viele Compiler so richtig umgesetzt, bis jetzt...

da konnte ich mir denken, dass jetzt sowas kommt. wer c-code mit microsoft kompilern kompiliert ist selbst schuld. nur weil microsoft es nicht _will_ dies zu unterstützen, macht das noch lange nicht den sprachstandard selbst schlecht.

Wie kommst Du auf MS? Ich spreche eher von solchen Sachen wie Visual DSP oder die TMS C-Compiler. Unter Windows programmiere ich bestimmt nicht in C.

[sothis_]

Tachyon schrieb:

Wie kommst Du auf MS?

das war nur ein beispiel. ich meinte, dass die argumentation mit hilfe der schlechten umsetzung eines sprachstandards hinfällig ist. ich sage doch auch nicht verallgemeinernd, dass c++ nicht mit templates umgehen kann, weil es das mit c++89 noch nicht gab und 10 jahre später, hypothetisch gesprochen, bei einigen compilern immer noch nicht implementiert ist. wenn man also behauptet c kommt nicht mit variablendeklarationen innerhalb eines blockes zurecht, ist das grundsätzlich falsch und kann nicht als grundlage für den vergleich mit anderen sprachen herangezogen werden.

[fricky]

Tachyon schrieb:

Ich spreche eher von solchen Sachen wie Visual DSP oder die TMS C-Compiler.

der visual dsp compiler für ADSP-218x kennt mittlerweile dieses C99 feature.
eigentlich sind es nur noch sehr wenige die C99 nicht unterstützen, aber für's jahr 2008 doch zu viele.

[*john 0]

fricky schrieb:

if (UINT_MAX  < 4294967295)
  long variable;
else
  int variable;

^^geht nicht.

Das ist das klassische Beispiel aus "Generative Programming"

template<bool condition, class Then, class Else>
struct IF {
    typedef Then RET;
};

template<class Then, class Else>
struct IF<false, Then, Else> {
    typedef Else RET;
}

IF<(UINT_MAX  < 4294967295), long, int>::RET i;

Es wäre natürlich schöner, wenn es einen neuen typsicheren Präprozessor gäbe und nicht diesen üblichen Hack, der als Altlast von C übernommen wurde. So bleibt nur diese Template-Lösung übrig.

[fricky]

~john schrieb:

Es wäre natürlich schöner, wenn es einen neuen typsicheren Präprozessor gäbe und nicht diesen üblichen Hack, der als Altlast von C übernommen wurde. So bleibt nur diese Template-Lösung übrig.

...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 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). für 'generative programming' finde ich, eigenen sich tools besser, die aus einer pseudo-sprache oder grafischen representation, quelltexte erzeugen, die man dann durch einen gewöhnlichen (z.b. C- oder Java-) compiler jagen kann. z.b. sowas: http://www.craigc.com/pg/tl/doc.html
übrigens, für variablen mit festgelegter bitanzahl gibts ja noch das: http://en.wikipedia.org/wiki/Stdint.h
(ist zwar für C99 aber funzt bestimmt auch unter C++)

[.filmor]

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.

Es soll Leute geben, die das als Vorteil sehen

fricky schrieb:

falls da 'n fehler drin ist, so dass es nicht kompiliert, könnten die fehlermeldungen ziemlich haarig sein 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).

Das stimmt, Debugging solcher Ausdrücke ist hässlich (aber nicht unmöglich, Stichwort statische Asserts).

fricky schrieb:

für 'generative programming' finde ich, eigenen sich tools besser, die aus einer pseudo-sprache oder grafischen representation, quelltexte erzeugen, die man dann durch einen gewöhnlichen (z.b. C- oder Java-) compiler jagen kann. z.b. sowas: http://www.craigc.com/pg/tl/doc.html

Und dann änder ich was an dem generierten Sourcecode, danach was an den bunten Bildchen und schon geht alles den Bach runter. Je weniger unabhängige Tools mit meinem Code rummachen desto besser.

Im Prinzip braucht C++ vor allem eine Syntaxüberarbeitung (wobei der Vorschlag im von rüdiger gepostete Link nicht unbedingt schön ist ;)), einheitliche ABI pro Plattform und Module.

[Zeus]

func max<[type T, type U]> : ( arg1 : T, arg2 : U -> decltype(arg1 + arg2) );

template<class T, class U> auto max(T arg1, U arg2) -> decltype(arg1 + arg2);

IHMO Dennoch ist der Vorschlag deutlich intuitiver als einige Sprachgerüste die mit C++09 kommen sollen, oder?

[Shade Of Mine]

ruediger:
ich sehe es pragmatischer. Ich sehe zB dass es Probleme macht dass C++ keine standardisierte ABI hat, ergo sehe ich das als defizit. Auch wenn ich der Meinung bin, dass eine standardisierte ABI nicht vom c++ standard vorgeschrieben werden sollte - sondern wohl eher von der Zielplattform. Aber wenn ich hier zB Java mit C++ vergleiche: man hat einfach ein viel besseres interop als man mit C++ erreichen kann.

Aehnlich bei den Libraries: ich will keine standardisierte Library fuer alles im Standard haben, weil das eine zu langsame Entwicklung waere - aber ich will alternativen zu Qt haben. Im moment ist Qt was plattformunabhaengige Frameworks betrifft das interessanteste. gtk ist unter windows schrott und wxwdigets unter mac. Hier fehlt einfach etwas. Und die Libs die sich durchgesetzt haben sind enorm alt und furchtbar designed.

[*john 0]

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?

[fricky]

~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.

[*john 0]

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.

[muemmel]

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

[Zeus]

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.

[fricky]

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

[muemmel]

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

[fricky]

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?