Pourquoi l'inclure si ce n'est pas necessaire

Le problème exposé dans ce sujet a été résolu.

Voila en refaisant un tour sur les algorithmes de la bibliothèques standard, j’ai remarque une chose que je ne comprends point.

Code 1 :

#include <iostream>
#include <vector>

int main ()
{
    std::vector<int> const first { 1, 2, 3, 4 };
    std::vector<int> const second { 1, 2, 3, 4, 0 };

    bool const equivalence {
        std::equal (std::cbegin (first), std::cend (first),
            std::cbegin (second), std::cend (second) )
    };

    std::cout << std::boolalpha << "sont-ils equivalents : " << equivalence << std::endl;

    return 0;
}

Ce code compile et s’exécute normalement alors que j’ai omis volontairement la ligne d’en-tête suivante :

#include <algorithm>

Du coup je me demandais quel est l’intérêt de l’inclure s’il n y a aucun message d’erreur a afficher en cas de non inclusion du fichier.

Voici un autre exemple (le code est tire du cour de ce site) :

#include <iostream>
#include <stdexcept>
#include <string>

int main()
{
    try
    {
        // Essayez avec un nombre très très grand ou bien avec des lettres pour observer le comportement de std::stoi.
        int entier { std::stoi("1000000000000000000000000000000000000000000000000000000") };
        std::cout << "Entier : " << entier << std::endl;
    }
    catch (std::invalid_argument const & exception)
    {
        std::cout << "Argument invalide : " << exception.what() << std::endl;
    }
    catch (std::out_of_range const & exception)
    {
        std::cout << "Chaîne trop longue : " << exception.what() << std::endl;
    }

    return 0;
}

Peu importe que j’inclus le fichier d’en-tête string ou que je ne l’inclus pas, mon programme va quand même compiler et s’exécuter. Et quel est l’interet de l’inclure puisqu’il n y a aucune déclaration de variable de type string.

J’ai du m’expliquer ceci en supposant que le fichier string est inclus dans le fichier ou est définit la fonction stoi et que c’est pourquoi ce n’est pas nécessaire de l’inclure a nouveau. Mais je ne crois pas que c’est le cas pour le fichier algorithm

J’espère avoir été clair dans mon incompréhension, Merci en Avance.


Il y a aussi d’autres cas similaires dans le cours que je ne comprends pas la raison d’inclure tel fichier.

+0 -0

Certains fichiers d’en-tête incluent d’autres fichiers d’en-tête et donc la compilation passe, même sans inclure directement ces fichiers.

Mais il n’y a aucune garantie que cela sera le cas sur toutes les plateformes, avec tous les compilateurs, et que cela ne changera pas au cours du temps.

Inclure systématiquement string ou algorithm quand on les utilise permet de respecter la norme C++ et d’avoir la garantie que le code restera valide.

+8 -0

Désolé de reposter ceci alors que j’avais marqué résolu. Je vais etre bref par conséquent :

Donc si l’un des deux fichiers d’en-têtes incluent le fichier d’en-tête algorithm alors pourquoi un message d’erreur s’affiche si j’utilise un autre algorithme de la bibliothèque standard.

Par exemple :

#include <iostream>
#include <vector>


int main ()
{
    std::vector<int> first { 1, 2, 3, 4 };
    std::vector<int>  second { 1, 2, 3, 4, 0 };

    bool const equivalence {
        std::equal (std::begin (first), std::end (first),
            std::begin (second), std::end (second) )
    };

    std::cout << std::boolalpha << "sont-ils equivalents : " << equivalence << std::endl;

    std::reverse (std::begin (first), std::end (first) );
    
    return 0;
}

En partant du fait que le fichier algorithm est soit inclut dans le fichier d’en-tête vector ou iostream !!! Pardonnez mon ignorance !

+0 -0

algorithm n’a pas à être inclut par un quelconque autre fichier d’en-tête. Il peut l’être, mais c’est alors un fruit du hasard. Il ne faut en aucun cas supposer que c’est du code correct.

Et qui dit que algorithm contient exactement tout le code qu’il est censé contenir sans passer par des fichiers intermédiaires qui pourraient être employés par d’autres fichiers?

Bref, ne fais aucune supposition.

J’ai vérifié chez moi, et mon fichier algorithm, il ne contient, en simplifiant, que

#include <utility> // UK-300.
#include <bits/stl_algobase.h>
#include <bits/stl_algo.h>

La fonction equal est définie dans <bits/stl_algobase.h>. Or, ce fichier est appelé par l’include de string, qui est appelé (indirectement) par celui de iostream.

La fonction reverse est définie, elle, dans <bits/stl_algo.h>. Tu vois bien qu’il est tout à fait possible que, pour equal, inclure algorithm ne soit pas nécessaire, mais que ce soit nécessaire pour reverse.

Et comme dis au-dessus, c’est comme ça chez moi, avec un compilateur, dans une version donnée. Demain, ou ailleurs, ça peut être fait différemment.

+5 -0

Super, grâce a vous j’arrive a mieux comprendre les explications de gbdivers et ceux de lmghs. Bref je saisis plus les sous-entendus de leurs explications et je comprends pourquoi c’est nécessaire d’inclure algorithm pour utiliser reverse et qu ce n’est pas nécessaire de l’inclure pour equal mais qu’il est quand même important de l’inclure car ça peut changer du jour au lendemain.

Merci pour votre éclaircissement Gabbro

+0 -0

Une dernière question : comment avez-vous fait pour afficher le contenu du fichier algorithm Gabbro ? J’utilise la ligne de commande pour compiler mes fichiers cpp ? Donc pouvez-vous me dire le(s) commande(s) utiliser pour afficher le contenu de ce fichier ?

+0 -0

Il faut simplement ouvrir le fichier algorithm qui se trouve dans les fichiers d’en-tete du compilateur. Le chemin depend de la configuration.

Gabbro a probablement utilisé un éditeur, qui permet d’ouvir un include simplement en faisant un un clic dessus. C’est beaucoup plus simple que de s’embeter a chercher a la main.

+2 -0

Gabbro a probablement utilisé un éditeur, qui permet d’ouvir un include simplement en faisant un un clic dessus. C’est beaucoup plus simple que de s’embeter a chercher a la main.

Travaillant professionnellement sur de vieux Unix sans serveur X, avec des chemins d’include complexes, je n’ai pas l’habitude de ces facilités. J’ai eu les infos en 2 minutes à coup de find et grep. Quand on sait ce qu’on cherche et où c’est, ça va vite. Mais quand on a des outils qui aident, il faut les utiliser. :B

+1 -0

Travaillant professionnellement sur de vieux Unix sans serveur X, avec des chemins d’include complexes, je n’ai pas l’habitude de ces facilités

gf avec un path approprié doit fonctionner sous Vim, non ? La plupart des IDE récents n’ont pas inventé grand chose, ils cumulent "juste" des trucs de plein d’outils. C’est rare de se trouver vraiment à poil sur du Unix.

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte