Schlanke Programme mit C++

[fricky]

tntnet schrieb:

Neulich auf dem Linux Tag in Berlin habe ich obico kennen gelernt. Die haben eine Fahrradcomputer gebaut. Und verwenden dafür natürlich C++.

embedded-linux ist in C geschrieben worden. ein paar, in c++ geschriebene userland-applikationen dranzustöpseln, ist nun wirklich keine innovation. zudem hat ein ARM9 normalerweise genug reserven, um durch c++ nicht ins schwitzen zu kommen.
btw: vor 10 jahren wäre das ding sicherlich messetauglich gewesen, aber heute?!?
für'n fahrradcomputer sind die ausmasse auch mehr als klobig: http://www.obico.de/images/lt08booth.jpg
ich glaube nicht, dass der obico ein kommerzieller erfolg wird.

[*john 0]

fricky schrieb:

klar, zuerst wäre c++ bestimmt unter den kandidaten, aber wenn er sich näher informieren würde, und dabei sowas findet: http://yosefk.com/c++fqa/defective.html
könnte das schon das aus für c++ bedeuten.

Für all diese Probleme gibt es Lösungen, bzw. sie sind aus Sicht aus höheren Programmiersprachen geschrieben. Was in Hinsicht auf Kernelentwicklung ziemlich sinnlos ist. Übrigens die meisten Probleme betreffen C in der einen oder anderen Form ebenfalls.

fricky schrieb:

die frage finde ich übrigens ganz interessant: 'welche programmiersprache nimmt man am besten für ein neues, grosses betriebssystem, vom kaliber eines windoofs oder unix".

Wenn man die Liste der potentiellen Kandidaten durchgeht und einige Anforderungen stellt bleiben ziemlich schnell nur zwei Sprachen übrig: Ada und C++. Bei allen anderen fehlen die notwendigen Compiler, es fehlt eine Normierung etc. oder man landet wieder bei C.

[Xantus]

DEvent schrieb:

MacOS ist in ObjectiveC geschrieben, Singularity in C# und Haiku in C++. Who cares was fuer eine Sprache fuer ein B-System verwendet wird?

Nene...so stimmt das nicht ganz ..

MacOS setzt bekanntlich auf Darwin auf - ist somit größtenteils in C geschrieben, als echtes Unix unter der Bonbonoberfläche. Und im Vergleich allerdings zu anderen Unix-like Systemen (*BSD, Solaris, Linux) setzt MacOS sogar vergleichsweise stark auf C++ oberhalb des Kernels, ich glaube HP-UX auch, da bin ich mir aber nicht so sicher. Objective-C nehmen die (und empfehlen natürlich) hauptsächlich für Anwendungsprogramme.

[*john 0]

Für die Treiberentwicklung wird bei MacOS X ein abgespecktes C++ verwendet. Objective-C wird für das Cocoa Framework und die darauf aufbauenden Applikationen benutzt.

[Mustermann]

Danke erstmal an alle!

@Tntnet: Genau solche Erfahrungen wollte ich gerne hören. Unabhängig von diesem Thread, hast Du mal Benchmarks gemacht wie sich Dein Web-Framework im Vergleich mit FastCGI skaliert?

@rüdiger:
Du meinst die dietlibc erweitern, damit sich die libstdc++ gegen die dietlibc linken lässt?

@Topic:
In den verlinkten Dokumenten ist mehrmals die Rede davon, dass mehr Code zu Cache Misses führen kann. Soweit klar, aber in wie weit ist C++ davon betroffen, habt ihr interessante Bookmarks/Literatur zu dem Thema?

[Shade Of Mine]

~john schrieb:

Für all diese Probleme gibt es Lösungen, bzw. sie sind aus Sicht aus höheren Programmiersprachen geschrieben.

Und das lustige - man kann mit board Mitteln von C++ ja die Abstraktion fast unendlich nach oben schrauben, je nachdem ob man will oder nicht.

Dann sind solche bescheuerten argumente wie "no high-level builtin types" oder "no runtime encapsulation". Das einzige was an dieser liste stimmt ist: komplizierte grammatik (was aber andere auswirkungen hat als der autor sich ausgedacht hat) und keine reflection.

warum sehen die Leute nicht die echten Probleme von C++?

zu langsamerer standardisierungsprozess (und daher zuviele dialekte), zuviele insel loesungen bei libraries und die guten libraries sind alt und daher nicht in modernen c++ geschrieben, zu schwache development tools (wegen komplizierter grammatik) und keine standardisierte ABI.

das sind die wirklichen probleme. stattdessen liest man immer wieder "komplizierte grammatik", "keine reflection", "boeses operator overloading",...

[rüdiger]

btw. ein schönes Beispiel für schlankeres und schnelleres C++-Programm vs fetteres und langsameres C-Programm ist wohl KDE vs GNOME.

Mustermann schrieb:

@rüdiger:
Du meinst die dietlibc erweitern, damit sich die libstdc++ gegen die dietlibc linken lässt?

Eher damit man C++-Programme mit der dietlibc linken kann.

Shade Of Mine schrieb:

warum sehen die Leute nicht die echten Probleme von C++?

zu langsamerer standardisierungsprozess (und daher zuviele dialekte), zuviele insel loesungen bei libraries und die guten libraries sind alt und daher nicht in modernen c++ geschrieben, zu schwache development tools (wegen komplizierter grammatik) und keine standardisierte ABI.

[Shade Of Mine]

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.

[Strolch]

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?

[.filmor]

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.

[otze]

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

[*john 0]

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.

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