Alternativen zu der Standard Bibliothek

Artchi

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

bluecode

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?

icepacker

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

Artchi

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.

GPC

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

volkard

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.

Walli

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 )

virtuell Realisticer

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

bluecode

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:

tntnet

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

Artchi

tntnet schrieb:

Übrigens kommt das gleiche Programm unter Perl auf 57 Bytes und mit Java auf 540 Bytes.

Kenne zwar Perl nicht, aber Java: aber haste die 30 MB JRE vergessen, wie? Da wirken die 540 bytes schon wieder ganz anders, gell?

volkard schrieb:

gedulde dich noch ein paar jahre, dann biuste bei meiner lib richtig aufgehoben.

Da gedulde ich mich lieber ein paar Jahre auf den neuen Standard. Glaube nicht, dass du an den ran kommst :p. Daher halt ich es auch ein bisschen für Zeitverschwendung, was du da treibst.

tntnet schrieb:

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

Was den Vergleich zu Perl bzw Java angeht, du behauptest Software-Entwickler
zu sein und kennst scheinbar nicht den Unterschied von Maschiensprache zu
einer interpretierten Sprache bzw. Bytecode. Das find ich ziemlich traurig.

volkard

ion schrieb:

Da gedulde ich mich lieber ein paar Jahre auf den neuen Standard. Glaube nicht, dass du an den ran kommst :p.

den will ich doch benutzen. nur fürchte ich, daß er zu meinen lebzeiten nicht mehr fertig wird.

.filmor

GPC schrieb:

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

$ g++ --version
g++ (GCC) 3.4.2 (mingw-special)

GPC

Dann liegt's eindeutig daran, dass ELF Binareis kleiner sind als die Windows Binaries.

tntnet

AberHallo schrieb:

tntnet schrieb:

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

Was den Vergleich zu Perl bzw Java angeht, du behauptest Software-Entwickler
zu sein und kennst scheinbar nicht den Unterschied von Maschiensprache zu
einer interpretierten Sprache bzw. Bytecode. Das find ich ziemlich traurig.

Wo habe ich behauptet, Software-Entwickler zu sein

Na ja - ich bin halt davon ausgegangen, daß die Leute, die hier schreiben, die Ironie verstehen.

Zu den C++-Code muß man noch die libstdc++.so oder was auch immer auf der Plattform benötigt wird dazurechnen. Bei Java die JRE und Standardbibliothek und bei Perl den Interpreter halt.

Natürlich habe ich Äpfel mit Birnen verglichen. Mit Perl habe ich ja nur den Source-code betrachtet, der aber gleichzeitig der ausführbare Code (bzw. der interpretierte Code, um genau zu sein) ist. Auch der Java-Code ist ja kein Maschinencode. Java vereint halt die Nachteile einer Compilersprache (Notwendigkeit einer Compilezeit) mit den Nachteilen einer Interpretersprache (Notwendigkeit eines Interpreters zur Laufzeit)

Tommi

Artchi schrieb:

Kenne zwar Perl nicht, aber Java: aber haste die 30 MB JRE vergessen, wie? Da wirken die 540 bytes schon wieder ganz anders, gell?

Unheimlich intelligenter Kommentar. Welche Abhängigkeiten hat denn ein C++ Programm, wenn es nicht nur eine triviale Konsolen-Applikation werden soll. Denk mal an QT, GTK, FLTK, wxWidgets, MFC, Xml-Parser wie tinyXML, zlib, DirectX, FMOD, *hastdunichtgesehen* ....
Aber du linkst das sicher alles statisch ein und kommst auf unter 100kb ...