Schlanke Programme mit C++
-
sothis_ schrieb:
Mustermann schrieb:
Ich verzichte komplett auf Exceptions, auf die Stdlib und nutze nur die Standard C Funktionen.
dann schreib doch gleich C-code kompiliere es mit einem C-compiler
Dann könnte er ja hier nicht rumtrollen.
-
wofuer brauchst du denn ein schlankes binary? hast du noch disketten?
-
@Mustermann: C++ ist tatsächlich keine geeignete Sprache, wenn du effiziente "Hello World"-Programme schreiben möchtest.
-
sothis_ schrieb:
Mustermann schrieb:
Ich verzichte komplett auf Exceptions, auf die Stdlib und nutze nur die Standard C Funktionen.
dann schreib doch gleich C-code kompiliere es mit einem C-compiler
Mir geht es ja lediglich um die Standard Funktionen. Klassen, Templates, Polymorphie und Operatorüberladung sind mir schon sehr wichtig.
In Zukunft werde ich mir auch die embeddedSTL genauer anschauen, zumindest ist dort oben erwähntes Programm statisch gelinkt nur 20KB groß.Machine schrieb:
sothis_ schrieb:
Mustermann schrieb:
Ich verzichte komplett auf Exceptions, auf die Stdlib und nutze nur die Standard C Funktionen.
dann schreib doch gleich C-code kompiliere es mit einem C-compiler
Dann könnte er ja hier nicht rumtrollen.
Ich habe bewusst nicht geschrieben das es an C++ liegt sondern an Implementierungen. Zudem ist nicht unüblich auf Exceptions zu verzichten und auch mit C Strings anstatt std::string zu arbeiten. Aber wenn Du es normal findest das ein Hello World Programm statisch gelinkt 1,3 MB groß wird...
rapso schrieb:
wofuer brauchst du denn ein schlankes binary? hast du noch disketten?
Primär geht es um Geräte mit wenig Speicher, sekundär um das Prinzip. Klar könnte ich C nehmen, aber warum auf die C++ OO Features verzichten?
Warum ich schlanke Programme gerade auf embedded Geräten für wichtig halte: http://www.fefe.de/dietlibc/diet.pdf
-
Mustermann schrieb:
Warum ich schlanke Programme gerade auf embedded Geräten für wichtig halte:
das sieht wohl jeder so.
Mustermann schrieb:
hehe -->
C++ is very dangerous because it hides complexity and bloat from the programmer.
also nimm besser gleich C, wie sothis bereits sagte.
-
Oder schreib halt gleich in Assembly wenns dir echt um jedes Bit und Byte geht.
-
Mustermann schrieb:
rapso schrieb:
wofuer brauchst du denn ein schlankes binary? hast du noch disketten?
Primär geht es um Geräte mit wenig Speicher, sekundär um das Prinzip. Klar könnte ich C nehmen, aber warum auf die C++ OO Features verzichten?
in dem fall wuerde ich dir empfehlen dynamisch zu linken, wenn du dann ein windows mit wenig speicher hast, koennen sich mehrere programme eine dll teilen. ansonsten, windows an sich ist schonmal das gegenteil von dem was geraete mit wenig speicher brauchen. und das ist kein bash, die zielsetzung war nunmal anders.
ich denke fuer die exe an sich sind die meisten symbole unwichtig, weshalb man die eigentlich rausstrippen koennte. ich hab jetzt nicht auf anhieb ne idee wie das mit VS geht, aber fuer gcc gibt es sowohl commandline options, als auch meistens strip tools (jedenfalls auf konsolen).aber an sich blasen dir templates ein binary durchaus sehr auf. ist der preis den mal zahlen muss.
-
Ich nehme dir die 1,3 MB nicht ab, tut mir Leid. Wenn ich hier (normaler PC) mit -Os kompiliere und die Binärdatei noch strippe komm ich auf etwa 400 K mit IOStreams, 80 K mit std::string und printf und 40 K nur mit printf. Dass die Streams nicht gerade das schlankeste sind sollte klar sein (wobei das in den Embedded-Varianten mit Sicherheit auch noch stark verbessert ist).
Den Template-Bloat kannst du mit sorgsamer Programmierung auch stark eindämmen.
-
Die Standard-Streams sind leider recht "fett". Aber wenn du schon von der dietlibc sprichst, kannst du ja die für C++ benötigte Funktionalität (hauptsächlich Stack-Zeugs für Exceptions) für die dietlibc portieren :). (sind glaube ich in der libgcc_s).
.filmor schrieb:
Den Template-Bloat kannst du mit sorgsamer Programmierung auch stark eindämmen.
Template-Bloat? Was soll das sein? Gerade Templates erlauben es doch Bloat zu verhindern, da der Compiler unnötigen Code entfernen und benutzen Code inlinen kann. Gibt ja sogar Empfehlungen für Embeddedprojekte alles als Template zu machen.
-
rüdiger schrieb:
Gibt ja sogar Empfehlungen für Embeddedprojekte alles als Template zu machen.
wo steht das?
embedded c++ z.b., ein c++ subset von c++ für embedded systeme, hat noch nicht mal templates.
-
Mein Tntnet läuft auf einem FreeWRT-Router. Die kleinsten Modelle für FreeWRT kommen mit 4MB Flash daher und daher geht es recht eng zu, da dort ja ein komplettes Linux rein passen muß.
Tntnet selbst benötigt mit den benötigten Bibliotheken ca. 1MB, was aufgrund des Funktionsumfanges akzeptabel ist und nicht dafür spricht, daß Templates zwangsweise zu Codebloat führen. Tntnet selbst verwendet praktisch überall STL und auch Exceptions. Selbstverständlich wird alles dynamisch gelinkt. Statisches linken macht einfach keinen Sinn. Und vor allen Dingen: strip nicht vergessen
. Die Option -Os bringt dagegen sehr wenig.Als Problem hat sich die Standarbibliothek erwiesen. Die shared library benötigt knapp 800k, was schon weh tut. Daher habe ich mich um alternativen umgeschaut und uclibc++ gefunden. Auf Anhieb lief es nicht, aber nach ein paar Bugfixes läuft Tntnet mit uclibc++. Die Biblothek nimmt nur noch gut 200k, also haben wir damit knapp 600k gespart.
Der Entwickler von uclibc++ ist zwar nicht sehr aktiv aber glücklicherweise sehr kooperativ und hat meine Patches akzeptiert und zügig ein neues Release gemacht.
-
rüdiger schrieb:
Template-Bloat? Was soll das sein? Gerade Templates erlauben es doch Bloat zu verhindern, da der Compiler unnötigen Code entfernen und benutzen Code inlinen kann. Gibt ja sogar Empfehlungen für Embeddedprojekte alles als Template zu machen.
weil mit templates vieles inlined wird, kannst du leicht den code aufblaehen gegenueber simplen funktion calls. besonders wenn du templates zum unrollen usw. benutzt.
bei mir gab letztens der VS compiler nach 20min compilieren auf
deswegen hab ich dann zwei template parameter zu normalen parametern umschreiben muessen und das dieses template ruf ich nun aus einer funktion auf (6mal), statt es im code an ca 8(*6) stellen direkt zu machen. das compiliert in nichtmal ner minute und die compilierte datei ist <15% in der groesse.ich glaube, dass beim MS compiler die compilezeit mehr als nur linear zur templatemenge steigt.
-
Hi,
C++ wurde nicht entwickelt um damit Controller zu programmieren oder Hello-World-Programme zu schreiben. Und die STL und Streams wurden nicht entworfen um Speicherplatz zu sparen.
Das ist genau so ein Unfug das zu kritisieren, wie damals die Marotte Forth, eine Sprache die zur Echtzeitsteuerung von Radioteleskopen entwickelt wurde für alles nehmen zu wollen.
C++ wurde entwickelt um damit Großprogramme wie Betriebssysteme und Compiler für PCs mit Speicher im Gigabyte-Bereich effektiv und effizient schreiben zu können. Und die STL wurde unter dem Gesichtspunkt entworfen, möglichst alles damit realisieren zu können und beliebig erweiterbar und typsicher zu sein.
Für beengte Umgebungen muß man sich eben auf die Grundstrukturen von C++ und dessen Objektmodell beschränken und für Konvertierungen, Ein- und Ausgabe und Speicherbereitstellungen gegebenenfalls eigene Funktionen schreiben oder auf die schlanken Versionen von C zurückgreifen. Es hindert einen ja dabei keiner Funktionen wie atoi unter einer moderneren Schnittstelle zu verbergen.Gruß Mümmel
-
muemmel schrieb:
C++ wurde entwickelt um damit Großprogramme wie Betriebssysteme und Compiler für PCs mit Speicher im Gigabyte-Bereich effektiv und effizient schreiben zu können.
Eigendlich falsch, hauptsächlich weil C++ nciht mit solchen Zielen designed wurde. Es entstand mehr aus einem eher evolutionären Vorgang. Beim ersten entwurf von C++ ging Stroustrup z.B. davon aus das 1MB (ja Megabyte) Speicher auf PCs zur Verfügung stehen würde usw.
Das man C++ für die von Dir genannten Aufgaben sehr gut nutzen kann? Ja, sicher. Das es speziell dafür entwickelt wurde? Nein.
Gibt ein schönes Buch: http://www.amazon.de/Design-Evolution-C-Bjarne-Stroustrup/dp/0201543303/ref=sr_1_1?ie=UTF8&s=books-intl-de&qid=1215091785&sr=8-1
-
Hi Loks,
ja sicher hast Du recht mit der eigentlichen "Erfindung" (aus C über C mit Klassen...)der Programmiersprache C++ damals durch Stroustup. Aber C++ ist ja bei weitem nicht mehr das was Bjarne damals entwickelt hat. Die letzten Versionen haben da doch schon recht gewaltig an Funktion zugelegt, und gerade die Bibliotheken sind gewaltig gewachsen. Wenn man dann noch das dazu nimmt, was aktuelle Implementationen dazupacken, z.B. die VCL bei CodeGear... dann kann man da schon davon ausgehen, das das was man sich heutezutage neu auf dem Computer installiert bei seiner Fertigstellung mit einem Speicher im mindestens Gigabytebereich im Hinterkopf designed worden ist.
Warum sollte man auch auf Kosten der Möglichkeiten sparen, wenn Platz heute keine Rolle mehr spielt. Hauptspeicher im Gigabytebereich, Festplatten im Terabytebereich, was macht es da noch, ob ein leeres Programm 10 k oder 2 GByte groß ist. Und bei großen Projekten ist es nie verkehrt, auf die nächste Rechnergröße zu schauen, denn bis das Programm fertig ist ist meist selbst die überholt.Guß Mümmel
-
muemmel schrieb:
C++ wurde entwickelt um damit Großprogramme wie Betriebssysteme und Compiler für PCs mit Speicher im Gigabyte-Bereich effektiv und effizient schreiben zu können.
seltsamerweise baut kaum einer betriebssysteme in c++. die bekanntesten pc-os'se sind jedenfalls nicht in c++ programmiert worden.
muemmel schrieb:
Warum sollte man auch auf Kosten der Möglichkeiten sparen, wenn Platz heute keine Rolle mehr spielt. Hauptspeicher im Gigabytebereich, Festplatten im Terabytebereich,
in solchen umgebungen muss man sich allerdings nicht mit c++ herumärgern. es gibt genügend modernere alternativen, die programmierung einfacher, sicherer und effizienter machen, als c++, diesen über 25 jahre alten hund mit angenagelten beinen.
muemmel schrieb:
...was macht es da noch, ob ein leeres Programm 10 k oder 2 GByte groß ist.
das, finde ich, ist übrigens eine ganz furchtbare einstellung. sowas hat uns 'vista' und 'ne menge anderen 'bloated bullshit' beschert.
-
windows7 und hurd werdens besser machen
-
Hi Fricky,
das mit 10k oder 2GByte war ein Schreibfaehler von mir, es sollte heißen 10 k oder 2 MByte. Und in dem Bereich macht es heute wirklich nichts aus.
Bei meiner ersten Abschlußarbet habe ich damals noch nach jeder Funktion geguckt, was an Größe dazu gekommen ist, und gegebenenfalls geändert.
War damals auch nötig, weil es auf Minimalst-Computern unter XT-Größe, so ab 256K Hauptspeicher laufen sollte.
Würde ich heute nie mehr machen, 0b ein Programm 2 oder 4 oder 6 MB groß ist, ist mir recht herzlich egal, Es muß zügig und fehlerfrei laufen und der Entwicklungsaufwand muß sich in Grenzen halten.
Feilen am letzten Byte lohnt sich nur noch bei Programmen, die wirklich sehr oft verwendet werden, wie Betriebssysteme und Offisse, aber gerade da wird ja die ganz große Datenschaufel genommen.
Wenn ich Anwendungen mit der VCL programmiere, gleich ob C++ oder Delphi, dann landet in jedem Fall erst mal ein richtiger Haufen auf der Platte, so als ob die Kuh was fallen gelassen hat. Andererseits ist der Zuwachs der sich mit jeder weiteren Quelltextseite ergibt dann recht gering. Aber ich habe dafür als Gegenwert ein Tool bei dem ich mich voll auf die eigentliche Verarbeitung konzentrieren kann und muß mir nicht ständig Gedanken machen, wie ich mit dem Nutzer reden will. Ich komme schneller und besser zu einem Ergebnis und davon hat auch der Nutzer etwas. Wenn ich nur auf API-Basis arbeiten würde käme ich sicher zu viel kleineren Programmen, aber es würde unendlich länger dauern und keiner könnte es bezahlen.Gruß Mümmel
-
fricky schrieb:
muemmel schrieb:
C++ wurde entwickelt um damit Großprogramme wie Betriebssysteme und Compiler für PCs mit Speicher im Gigabyte-Bereich effektiv und effizient schreiben zu können.
seltsamerweise baut kaum einer betriebssysteme in c++. die bekanntesten pc-os'se sind jedenfalls nicht in c++ programmiert worden.
hallo du schlaumeier, schon mal was von
Windows XP
Windows NT (NT4 and 2000)
Windows 9x (95, 98, Me)
gehört?
-
Naja, der Kernel-Code ist wohl schon C. Wie die unixoiden Systeme. Im Gegensatz zu den BSDs und Linux wird bei Microsoft im Userland allerdings wesentlich mehr auf C++ gesetzt, gerade auch durch die graphischen Administrationstools, z.B. in der Systemsteuerung, die bspw. die MFC verwenden.