Discussion :

[coyotte507]

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?

[Luc Hermitte]

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.

[koala01]

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

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

[nikko34]

et si tu enlèves les informations de debug?

je passe de 100ko à 8ko

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

[coyotte507]

comment faire?

[nikko34]

tu compiles avec quoi?

[koala01]

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

[coyotte507]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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?

[koala01]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
(en plus, typiquement, cet affichage n'est nécessaire qu'en debug )

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 )

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

[coyotte507]

Ok merci...

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

[nikko34]

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.

[vdumont]

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