Poids de #include <iostream>

Bonjour,

j'ai d�couvert quelque chose d'assez surprenant qui alourdit mes applications.

Quand je rajoute un #include<iostream>, je passe de 25 ko � 263 ko!
J'ai fait ce test � la suite de la d�couverte du code d'un jeu vid�o adapt� par le cr�ateur m�me de SDL, et qui �tait en C++, avec tous les aspects POO, mais sans rien inclure de la STL ni de la SL. (Maelstr�m)

Je me demande donc s'il est courant de ne pas inclure ces ent�tes pour �conomiser de l'espace?

Quand je n'ai besoin ni de std::cout, ni de std::cin, ni de std::cerr, ni de std::clog, je n'inclus pas <iostream>.
Sinon, dis-toi que 200ko, ce n'est rien compar� compar� � une dizaine de m�ga.

Salut,

Il faut bien comprendre le fait que l'en-t�te iostream regroupe en d�finitive tout ce qui est n�cessaire pour... pouvoir afficher quelque chose sur la sortie standard, en ce, y compris l'ensemble de ce qui est n�cessaire... pour pouvoir afficher cette sortie standard :p

Si tu as un peu de temps � perdre, amuse toi simplement � regarder tout ce qui est inclus gr�ce au jeu des inclusions en cascade par le simple fait d'inclure le fichier <iostream>... C'est purement et simplment surprenant: Chez moi (avec Gcc), on voit que iostream inclus

• istream qui inclus
  
  • ios qui inclus
    
    • iosfwd
    • exception
    • bits/char_traits.h
    • cstdio
    • bits/localefwd.h
    • bits/ios_base.h
    • streambuf
    • bits/basic_ios.h
  • limits
• ostream
• bits/c++config.h

(je me suis arr�t� l� ;))
et qu'une bonne partie de ces fichiers sont, finalement, susceptibles de d�finir des classes, des traits ou des m�thodes qui, en d�finitives, interviendront dans le simple fait d'�crire un cin>>lavar ou un cout<<lachaine :P

Il n'est donc pas surprenant outre mesure que la simple inclusion de iostream provoque une prise de poids de l'ordre de 200 kb ;)

Mais, comme l'a fait remarquer Luc Hermite, si les 200kb pris peuvent para�tre �norme en compar� aux 23k de d�part, ils ne feront qu'une diff�rence minime compar� � l'application finie qui risque de faire plusieurs Mb ;)

De la m�me mani�re, il y a de fortes chances que, si le fichier d'en-t�te n'est pas inclus, c'est, tout simplement parce que l'auteur n'a besoin d'aucune classe/fonction/m�thode qu'il fournit, et non pour �conomiser quelques k � l'application ;)

et si tu enl�ves les informations de debug?

je passe de 100ko � 8ko

( si la place est vraiment un probl�me... )

comment faire?

tu compiles avec quoi?

Concr�tement:

1. N'inclus que les fichiers qui te sont r�ellement n�cessaires: la SDL permet un affichage directement dans sa fenetre me semble-t-il, pourquoi ne pas en profiter :question:
2. compile en mode debug quand tu d�veloppe ton application, en mode release quand tu t'apprete � fournir une version utile
3. ne t'inqui�te pas trop de la place que ca prend: tu auras surement d'autres soucis plus importants ;)

Tes premiers soucis, en tant que programmeur, c'est, et ca doit rester:

1. que ton application fonctionne
2. que ton application fasse ce que tu attend d'elle
3. que les algorithmes mis en oeuvre soient les meileurs possibles (ou � d�faut, les moins mauvais possible)

Ce n'est qu'une fois que ces trois points sont pleinements aquis que tu peux commencer � t'inqui�ter du reste: la vitesse d'ex�cution et/ou la taille de ton ex�cutable, et encore, si le besoin s'en fait r�ellement sentir uniquement.

Une possibilit� pour am�liorer l'un ou l'autre peut, tout simplement, de modifier les options de compilation (le param�tre -O sous Gcc, par exemple) ou d'envisager une "autre mani�re de coder" (pr� incr�mentation au lieu de post incr�mentation...) ;)

Pourquoi ne pas profiter de la fen�tre SDL? :P
J'en profite, mais je me vois mal adapter �a � l'affichage sur la fen�tre:

Code:

---

1 2 3 4 5 6

// initialize SDL video if ( SDL_Init( SDL_INIT_VIDEO ) < 0 ) { printf( "Unable to init SDL: %s\n", SDL_GetError() ); return 1; }

---

C'est pour �a que j'ai besoin d'une sortie.

Sinon, l'option -Os (optimize for size) ne change rien (pour l'instant) :(

Est-ce que tout programmeur C++ utilise la SL/STL, ou alors certains utilisent la cstdlib, par exemple?
Est-ce que c'est courant d'utiliser les ent�tes h�rit�es du C?

Citation:

---

Envoy� par coyotte507

Pourquoi ne pas profiter de la fen�tre SDL? :P
J'en profite, mais je me vois mal adapter �a � l'affichage sur la fen�tre:

Code:

---

1 2 3 4 5 6

// initialize SDL video if ( SDL_Init( SDL_INIT_VIDEO ) < 0 ) { printf( "Unable to init SDL: %s\n", SDL_GetError() ); return 1; }

---

C'est pour �a que j'ai besoin d'une sortie.

---

Afficher un message sur une fenetre non initialis�e risque en effet de poser probl�me...

Mais, pourquoi ne pas envoyer un message dans un fichier .log :question:
(en plus, typiquement, cet affichage n'est n�cessaire qu'en debug ;))

Citation:

---

Sinon, l'option -Os (optimize for size) ne change rien (pour l'instant) :(

---

Mais d'un autre cot�, il ne faut pas trop s'en inqui�ter si tu n'a qu'une fonction appel�e ;) (et puis, comme je l'ai dit plus haut, la taille de ton ex�cutable ne doit pas entrer en ligne de compte avant bien longtemps ;))

Citation:

---

Est-ce que tout programmeur C++ utilise la SL/STL, ou alors certains utilisent la cstdlib, par exemple?
Est-ce que c'est courant d'utiliser les ent�tes h�rit�es du C?

---

Tout programmeur reste �videmment libre de faire exactement ce qu'il veut chez lui...

Mais de nombreux programmeurs C++ pr�f�rent largement utiliser la S(T)L du C++ et �viter autant que possible le recours � la SL du C ;)

Ok merci...

J'esp�re que pour ce projet je vais pouvoir me passer de la STL.

l'essentiel c'est de savoir quand tu fais du C, du C++ ou que tu utilises une api externe.

Le C++ est fait pour se faciliter la vie et �crire du code safe � l'ex�cution, mais cela entraine des contraintes.

Tu peux utiliser 'strip' si tu es sur un syst�me Unix pour pouvoir supprimer les symboles de debug etc.. de ton binaire.