Schlanke Programme mit C++
-
rüdiger schrieb:
was sind deiner meinung nach dann die probleme von c++?
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.
die komplexe grammatik verhindert dass man viele gute tools hat die mit c++ code umgehen koennen. refactoring, etc. visual studio ist zwar ziemlich gut, aber jede x-beliebige freie java ide hat die selben features und meistens noch etwas mehr gratis dabei, weil der aufwand der implementierung soviel geringer ist.
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.
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.
-
Shade of Mine! Generell hast du erstmal Recht. Aber in den Details kann ich da nicht ganz zustimmen.
mho 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.
Wenn ich von Platform A auf Platform B portiere, will ich doch die Features der jeweiligen Platform nutzen. Da steht mir doch eher ein in Stein gemeisselter Dialekt im Weg? Ich kann dann z.B. nicht einen Kernel auf Platform B portieren, weil vielleicht die C++-Norm darauf nicht passt. Meistens sind doch die Unterschiede in den Compilern in den verschiedenen Platformen begründet.
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.
die komplexe grammatik verhindert dass man viele gute tools hat die mit c++ code umgehen koennen. refactoring, etc. visual studio ist zwar ziemlich gut, aber jede x-beliebige freie java ide hat die selben features und meistens noch etwas mehr gratis dabei, weil der aufwand der implementierung soviel geringer ist.
Ich weiß ja nicht ob du VA-X in Aktion kennst? IntelliSense von MS ist leider buggy, und das hat auch das VisualC++-Team auch mehrmals entschuldigt. Sie wollen sich bessern. Aber VA-X ist eine ganz andere Liga und es funktioniert für die komplexe C++-Grammatik schon sehr gut.
Die Codecompletion von Eclipse und NetBeans beruht aber auf was ganz anderes: Reflection! Das Verfahren und die Möglichkeiten sind hier ganz anders als es bei C++ möglich ist. Reflection macht im IDE-Bereich sehr viel Sinn. Hier wäre es vielleicht sinnvoll, wenn die C++-Compiler der IDE Informationen zur Codecompletion liefern könnten? MS will ja angeblich sowas in Zukunft machen, dazu müssen sie aber ihren unwartbaren Compiler ersetzen (was auch auf den G++ zutrifft).
Ich halte Reflection für die C++-Runtime für unwichtig, da C++ statisch ist und es bleiben sollte. Es würde aber für C++-IDEs einen immensen Vorteil bringen. Aber evtl. sollte man hier die Compiler in die Pflicht nehmen um das Defizit zu umgehen?
ie 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.
Hem, das Argument leuchtet mir überhaupt nicht ein. Swing ist doch im Mac nicht besser integriert als es z.B. gtkmm ist? Ich rede jetzt nicht von Bugs! Ich meine wirklich das Look & Feel. Hat Swing alle Cocoa-Features? Bestimmt nicht. Swing ist das, was gtkmm oder Qt für C++ ist. NUr eine andere Sprache. Sorry, aber wer auf Swing schwört, dürfte mit gtkmm oder Qt auch keine Probleme haben, wenn es um deren philosophischen Ansatz geht. Eventuelle Bugs sind bei dem Thema zweitrangig.
SWT ist dagegen das, was wxWidgets für C++ ist. So muß man das meiner Meinung nach vergleichen.
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.
Hier gehe ich 100% mit dir! Ein Schande, das es nicht auf der jeweiligen Platform eine Kompatibilität geben. Z.B. wäre es schon sehr begrüssenswert, wenn z.B. alle C++-Compiler und Linker unter Windows XP die LIBs oder DLLs austauschen könnten.
Werden wir aber leider nicht sehen. Durch COM+ und ActiveX sollte doch aber unter Windows zumindest sowas als Workaround möglich sein?
-
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 mit den Dialekten kann ich nicht nachvollziehen. Bis auf den _declspec-Unfug begegnen einem doch recht selten Nicht-ISO-C++-Erweiterungen.
Letzteres finde ich ist das größere Problem.Shade Of Mine schrieb:
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.
Es fehlen GUI-Funktionalitäten im Standard, das stimmt.
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.
Das Problem existiert ja eigentlich nur unter Windows, Intel und GCC scheinen sich zu verstehen. Es ist echt schade, dass die Module für C++ nicht durchgekommen sind, die hätten bestimmt was in die Richtung bewirken können.
-
.filmor schrieb:
Das mit den Dialekten kann ich nicht nachvollziehen. Bis auf den _declspec-Unfug begegnen einem doch recht selten Nicht-ISO-C++-Erweiterungen.
Letzteres finde ich ist das größere Problem.aber jeder compiler kann irgendwas anderes _nicht_. benutzt mal komplexe templates, dann kann man schon wetten abschließen, bei welchen compilern der Code nicht funktioniert. Und das ist eigentlich untragbar.
-
Shade Of Mine schrieb:
oder "no runtime encapsulation".
Also, ich fände es schon gut, wenn C++ einige Features mehr von Ada hätte. Es wäre auch relativ einfach Division durch 0 und Verwandte abzufangen und eine Exception zu werfen, zumindest auf den wichtigsten Plattformen. Es nervt einfach C-mäßig immer vorher prüfen zu müssen, wenn die Hardware das eh erkennt und eine Exception werfen kann.
Shade Of Mine schrieb:
zu langsamerer standardisierungsprozess
Die Normierung geht doch immer zügig voran. Das Problem ist die komplexe Grammatik. Wenn man sich anschaut wie lange es gedauert hat, bis der erste Ada95 konforme Compiler auf dem Markt war (wenn ich mich richtig erinnere war's nur ein Jahr), dann sieht man wo die eigentlichen Probleme liegen.
-
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.
-
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.
-
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?
-
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
-
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.
-
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.
-
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.
-
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.
-
~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++)
-
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.
-
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?
-
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.
-
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.