Alternativen zu der Standard Bibliothek
-
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.
-
@GPC: Wie groß werden bei dir Programme mit I/O Streams?
-
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!
-
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
-
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.
-
Ätsch bätsch, meine is kleiner
-
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
-
.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++.
-
Bei mir unter Linux 2.6.14 mit GCC 3.4.3 erzeugt obiger Code eine Größe von 13314 Bytes. Ohne Optimierungen
-
Dich zwingt niemand, cout und std::string zu verwenden.
Du kannst dir auch wrapper für C funktionen dafür schreiben,
bei iostream ist das sogar recht einfach möglich.Wenn du aber glaust, das die STL nur aus strings und streams
bestehst, irrst du, da ist wesentlich mehr.
Boost existiert ja auch nur, um das noch zu ergänzen.Wenn dich also die STL wirklich stört, dann schau dir mal
andere Sprachen an, und frag dich, ob du wirklich C++ machen
willst. Evtl. ist ja PHP viel besser...
-
Vielleicht hat er noch nie Geld in ein gutes Buch investiert, in dem einfach mal die Standard-Lib erklärt wird. Der Witz ist ja auch, das eigentlich strings und streams vielleicht (wenn überhaupt!) 5% in einem solchen Buch ausmachen. Daran sieht man sehr schön, das viele C++-Einsteiger eigentlich nur HelloWorld mit der C++ Stdlib gemacht haben...
Deshalb an bluecode und den Thread-Ersteller mein Buchtip:
http://www.springeronline.com/sgw/cda/frontpage/0,11855,1-40109-22-48185313-0,00.html
-
hi,
werd ich jetzt komplet misverstanden?
Mir gefallen eben nur std::string und I/O streams nicht wegen der Codegröße die sich bei meinem Test ergeben haben. Aber da hab ich mich wohl geirrt(in Sachen Compilereinstellungen). Ich hab nie was gegen den Großteil der STL gesagt (mein Ausspruch "Die Größe" bezog sich ausschließlich auf eben diese).
Und noch eine Anmerkung bzgl. all dieser "wenn du die STL nicht magst dann nimm halt ne andere Sprache"-Menschen: C++ ist nicht STL.:xmas2: Frohe Weihnachten euch allen :xmas1:
edit: seit ihr eigentlich alle heute ein bisschen aggressiv?
-
sorry für euch, aber da könnt ihr alle einpacken
mein test code
#include <iostream> #include <string> int main(int argc, char **argv) { std::string s("Hallo Welt\n"); std::cout<<s; return EXIT_SUCCESS; }
compiler:
g++ (GCC) 4.0.2
compiliert mit
g++ -o main main.cpp
so und jetzt kommts:
das ganze ist 10.2 KB großlg icepacker
ps:
mit dem code
#include <iostream> #include <string> int main() { std::string s; std::cout << s; }
wird es nur 9.9 KB groß, ohne optimierungen
-
bluecode! Wir und heute aggressiv? Ich glaub, ich hab heute eigentlich recht gute Laune! Das werden dir hier bestimmt andere bestätigen.
Die STL ist mit ein paar Änderungen in die ISO-C++ Standard-Lib eingeflossen. Somit ist sie C++. Das macht C++ unter anderem aus, das wir eine solche Std-Lib haben und nutzen können. Das ist auch nur möglich, weil C++ entsprechende Sprachmerkmale anbietet, die man woanders auch vergeblich sucht. Insgesamt stimmt es also schon, zu sagen, wenn man die Std-Lib nicht mag, dann sollte man sich vielleicht eine andere Sprache suchen.
Eines sollte man auch noch bedenken: eine Std-Lib ermöglicht es auch fremden Code einfacher zu verstehen. Wenn also jeder in seinen C++ Programmen mind. die Std-Lib benutzt, wird man sich als Std-Lib-Kenner einfacher im Code zurecht finden. Wenn aber jeder meint "Ach, die C++ Std-Lib gefällt mir nicht, deshalb nehme ich jetzt Lib X..." werden wir im Chaos enden. Vorallem wird man hier im Forum nicht so schnell Hilfe erwarten dürfen können. Weil die meisten hier ganz einfach die Std-Lib benutzen und kennen.
-
.filmor schrieb:
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
Yup, so ist es. Welche Version hast du?
-
Santa Clause schrieb:
ich bin auf der Suche nach einer kompletten Alternative zu der C++ Standard Bibliothek.
gedulde dich noch ein paar jahre, dann biuste bei meiner lib richtig aufgehoben.
-
bluecode schrieb:
KiB sind kilobyte, aber die mit 1024Byte nicht die mit 1000Byte.
/ot: Für die meisten Leute war ein Kilobyte schon immer 1024 Byte, nur für die Festplattenhersteller nicht. Kibibytes finde ich überflüssig, wahrscheinlich war das auch der Grund dafür, dass ich die Abkürzung dafür schnell wieder verdrängt habe. Benutzt kein Schwein (außer du
)
-
bluecode schrieb:
KiB sind kilobyte, aber die mit 1024Byte nicht die mit 1000Byte.
[klugscheissermodus]
Deswegen nennt man sie auch nicht Kilobyte sondern Kilo Binary Byte
[/klugscheissermodus]Ok, und nun definieren wir:
kb := kib
und freuen uns, das wir hier beides gleichsetzen :p
mfg
v R
-
Ich glaub ich sag dazu lieber nix mehr. Ich hab bereits 2Mal komplette Inkonpetenz in diesem Thread bewiesen. Bin halt ein :xmas2: .
Des muss für dieses Jahr reichen.Frohes Fest euch allen :xmas1:
-
Das Programm compliziert unter Debian Sarge ohne Optimierung und anschliessenden strip ergibt 4736 Bytes. Mit -Os noch 4456 Bytes. Unter SuSE-Linux 10.0 x86-64 kommt das Programm auf 7208 Bytes. Mit -Os auch, aber mit -O2 auf 7200 Bytes.
Übrigens kommt das gleiche Programm unter Perl auf 57 Bytes und mit Java auf 540 Bytes.
Tommi