Alternativen zu der Standard Bibliothek

Hi Community,

ich bin auf der Suche nach einer kompletten Alternative zu der C++ Standard Bibliothek. Ich surfe nun schon seit einiger Zeit durch die Boost Doku und muss sagen, einfach genial!

Nun meine Fragen:

Kann Boost ohne Elemente aus der Standard Bibliothek(std::string) auskommen?
Was bietet die Standard Bibliothek was Boost nicht hat?
Gibt es Performancevorteile für eine der beiden Libs?
Sind die Boost iostreams ein guter Ersatz für cout/cin?

Was ist Eure Meinung zu Boost? Kann man Boost als Alternative benutzen?

:xmas1:

Boost ist eine Erweiterung und kein Ersatz.

Artchi

Also Boost baut selbst auf die Standardlib auf, weiß nicht wie es da ein Ersatz sein kann/soll? Und die Genialität von Boost ist nur das Spiegelbild der Standardlib, denn Boost versucht die Philosophie der Stdlib weiter zu entwickeln. Deshalb: was stört dich an der Standardlib? Oder du hast sie nicht verstanden oder dich mit dieser nicht hinreichend beschäftigt.

Boost fehlen außerdem ein paar Sachen, die die Stdlib hat. Und zwar wichtige Dinge.

Die Boost Streams z.B. bedienen sich auch nur den Streamklassen von der Standardlib. Der Sinn der Boost Streams ist halt nur, das man einfacher Streams bauen kann. Sie sind kein Ersatz.

Komme mir irgendwie von dir verarscht vor.

bluecode

Artchi schrieb:

Deshalb: was stört dich an der Standardlib?

Die Größe. :xmas1:

Artchi

bluecode

Damit mein ich speziell std::string und iostreams. Wenn ich z.B. ein leeres Projekt also nur main() hab, dann ist die Exe 16kib groß. Include ich dann <string> und erstell einen string wird die exe um 107kib größer. Bei iostreams ist des noch viel krasser: Die exe wird um 448kib größer.
Das meinte ich mit Größe. Ich find des schlicht nicht akzeptabel.

[edit: Das liegt eher an der Implementation als am C++ Standard, ich weiß. Aber ich glaube mit boost wird das wohl noch schlimmer oder wie ist da eure Erfahrung?]
[edit2: Falls des jemand reproduzieren will: Mein Compiler war DevC++ bzw. Mingw, d.h. unter Windows]

Walli

Was sind kib? Schonmal die Debug-Erweiterungen ausgestellt?

Santa Clause schrieb:

[*] Gibt es Performancevorteile für eine der beiden Libs?

Warum fragen eigentlich immer alle nach Performance? Eine Lib nimmt dir auch nicht das Denken ab.

bluecode: LOL

otze

das liegt eher an den linkern. das problem ist, dass wenn du die iostreams nutzt, dir die komplette iostream lib dazugelinkt wird, egal ob du alle features brauchst(und das sind wirklich viele), oder nicht.

ähnlich ist es beim string. bei ihm wird dir aber nicht die stl dazugelinkt, sondern afaik die c-lib. und da dies absolut grundlegende funktionen sind, wird dir niemand diese libs ersparen können.

.filmor

Im Übrigen kann dir die Größe doch ziemlich egal sein. Wenn du kleinste Programme haben willst nimm halt C und/oder Assembler.

Walli

Man kriegt normalerweise auch C++ Programme klein. Aber selbst wenn nicht... was sind schon 500kB in 2005?

EDIT: Ausgenommen natürlich Systeme auf denen 500kB immer noch ne Menge ist, aber da wird man sich den Einsatz von STL/boost auch dreimal überlegen.

GPC

Beim aktuellen g++ bleibt die executable eigentlich selbst mit iostream recht klein, jedenfalls viel kleiner als früher! Aber hey, wen jucken auf nem 0815-Dektop 500 kb???

bluecode

KiB sind kilobyte, aber die mit 1024Byte nicht die mit 1000Byte.

Ich hab ja nur gesagt, dass mich persönlich die Größe dieser KLassen (I/O Streams & string) stört. Ich bin nunmal nicht das Maß aller Dinge. Mir ist auch klar, dass das andere anders sehen, aber ich sehs halt nicht ein soviel Platz nur für ein cout zu verschwenden, deswegen benutz ich i/o streams und std::string halt net.

Im Übrigen kann dir die Größe doch ziemlich egal sein. Wenn du kleinste Programme haben willst nimm halt C und/oder Assembler.

Klasse Idee
Ich entscheide immer noch ob ich C++ und die STL oder eben nur C++ benutze. Die Größe ist mir nunmal nicht egal.

bluecode

@GPC: Wie groß werden bei dir Programme mit I/O Streams?

GPC

bluecode schrieb:

@GPC: Wie groß werden bei dir Programme mit I/O Streams?

Sitz nich an meinem eigenen Rechner, deshalb kann ich nur ausm Gedächtnis antworten, aber IIRC waren's < 100 kb

EDIT, war mal mit folgendem Code kurz testen:

#include <iostream>
#include <string>

int main(int argc, char **argv) {
  std::string s("Hallo Welt\n");
  std::cout<<s;
  return EXIT_SUCCESS;
};

Mein Compiler: g++ (GCC) 3.3.6

Gehen wir kompilieren:

Null Optimierung:

g++ -o main main.cpp

ergibt Größe von 13,4 kb.

Ein bisserl mehr Optimierung:

g++ -O2 -o main main.cpp

ergibt Größe von 13,1 kb, nicht grad viel weniger, O3 bringt selbes Ergebnis.

Jetzt weiter auf Größe optimieren:

g++ -O3 -Os -o main main.cpp

ergibt 13,0 kb.

Also bei 13kb kann sich keiner beschweren!

otze

bluecode schrieb:

Ich hab ja nur gesagt, dass mich persönlich die Größe dieser KLassen (I/O Streams & string) stört. Ich bin nunmal nicht das Maß aller Dinge. Mir ist auch klar, dass das andere anders sehen, aber ich sehs halt nicht ein soviel Platz nur für ein cout zu verschwenden, deswegen benutz ich i/o streams und std::string halt net.

ok, nochmal: string selbst ist nicht groß. wenn du kleine exen machen willst, dürftest nichtmal mehr die c-header benutzen, denn afaik wird der compiler es wohl so machen:

wenn irgendein standardheader eingebunden wird, wird sofort die standardlib mitgelinkt. es ist ganze egal ob <string> oder <ctime> oder irgendeine andere standarddatei, es wird sofort alles eingebunden(bis auf die iostream lib).

Und wenn du nicht verstehst, wie die iostreams so groß sein können, dann zieh dir mal ne komplette dokumentation von ihnen an land, du wirst staunen ;).

Ich entscheide immer noch ob ich C++ und die STL oder eben nur C++ benutze. Die Größe ist mir nunmal nicht egal.

die stl ist ein fundamentaler bestandteil von c++. wenn du sie nicht benutzen willst, würd ich dir ne andre sprache ans Herz legen

Artchi

Also sorry, aber 500 KB? Wie heißt es so schön? Das Problem sitzt meistens nicht im, sondern vorm Rechner.

Das kann ich hier nicht bestätigen. Meine Test-Exe mit iostream und string ist mit VC++2003 Standard 72 KByte klein. Ohne Tricks, einfach kompiliert und gelinkt. Wobei ich den Nicht-Optimierenden-Compiler habe... kann also nicht einstellen, das er es auf Code-Größe optimieren soll. In der Pro-Version wirds bestimmt kleiner.

#include <iostream>
#include <string>

int main() {
	std::string s;
	std::cout << s;
}

Und das neue VC++2005 macht ohne Tricks noch kleinere Exes, ich habs damals mit der Beta-Version ausprobiert. Waren (nagelt mich nicht fest) nur knapp 20 KB klein... glaub ich. Hatte mich sehr positiv überrascht, der der Compiler und Linker mittlerweile so gut sind.

GPC

Ätsch bätsch, meine is kleiner

.filmor

Kann es sein, dass du ELF-Binaries erstellst? Die sind doch IIRC generell kleiner als Windows-PEs?! Mein MinGW g++ spuckt (gestripped und mit -Os) für das Programm knapp 200K aus

Artchi

.filmor schrieb:

Im Übrigen kann dir die Größe doch ziemlich egal sein. Wenn du kleinste Programme haben willst nimm halt C und/oder Assembler.

Auf eine andere Sprache ausweichen, ist glaub ich nicht das Ziel, um eine Schwierigkeit zu lösen. Das was du vorschlägst, nennt sich "weg laufen". C++ ist eine Universalsprache, die man überall einsetzen können soll. Wenn einem die Exe zu groß ist, haben wir festgestellt, muß man nur die richtigen Tools benutzen und entsprechend die richtigen Parameter an die Tools geben.

Die aktuellen Tools von MS und GNU können das ganz gut leisten, wie ich hier an den Antworten sehe. Will aber nicht sagen, das man nicht doch mal Assembler bräuchte, ist aber ein ganz anderes Feld als C oder C++.