Discussion :

[pyros]

Juste pour préciser, je parle des lib en général, pas de la STL ou de boost en particulier.

Sans sur-enchérir sur les contrainte technique (ça se gère la plupart du temps, mais à quel prix ? Et si la lib n'est pas compatible, il n'y a pas trop de solution...), tout projet à ses contraintes :

Certain se passent sur des zones sécurisés sans accès internet où il faut attendre 1 mois pour avoir l’autorisation de rentrer une clef usb. Dans ce cas, recodage de roue à gogo...

Comme l'a dit 3DArchi, certain impose des normes de certification très strict (DO-178 pour ne citer qu'elle), qui ne sont pas respecté par des lib tiers.

Et même sans parler de ces cas extrêmes, dans une grosse structure, le processus pour demander l'intégration d'une nouvelle lib peut prendre plusieurs mois.
Dans une petite structure, on a peut être tout simplement pas le temps, ou même les compétences pour l'intégrer (le type qui gère le déploiement est en vacance, le script a été fait par un presta et personne n'ose y toucher depuis, ça tourne sur ubuntu mais pas sur debian et personne ne sais pourquoi, ...).
On préfère parfois avoir à gérer les bug plus tard mais sortir la release à l'heure. Quitte à avoir une première version home made buggé mais utilisable le temps d'intégrer un truc plus fiable.

Je ne suis pas partisant de recoder la roue. Mais parfois, les contraintes humaines, organisationnelles ou financières font qu'on n'a pas le choix.

[screetch]

je pense que le principal problème dans le cas présenté ici c'est que boost est pas forcément le plus simple dans le cadre d'un projet de personne inexpérimentée.

Intégrer une bibliothèque, même si c'est que des headers, ca arrive a l'étape 1024 du manuel de c++; ca touche au compilo (l'include path), au redeploiement (integrer une DLL), et souvent les gens qui postent ici ont même pas cette connaissance (ce qui est bien emmerdant pour répondre correctement)

donc oui dans un monde parfait il suffirait de dire "boost.geometry" et les gensi ls feraient "ah ouais pas con". J'aimerai ce monde

mais on est pas dans un monde parfait et la dernière fois que j'ai conseillé a quelqu'un de mettre boost il a posté 5 autres posts dans la semaine avec des "include not found" et des "et sur la machine de mon pote ca compile pas" etc etc.

et c'est pas un problème lié a boost, ou a une bibliothèque, mais plutôt aux outils liés au C++; et il faut (malheureusement) les prendre en compte quand les gens postent.



Donc, pour conclure, dans une politique de moindre résistance, lorsque quelqu'un demande un truc sur une formule de maths bidon qui s'ecrit en 4 lignes C++ (sans bibliothèque), le plus simple est parfois de conseiller de le faire soi-même. Même si boost fait ca en 1 ligne. Pour éviter la cascade de questions qui va en découler. Même si bien profond dans mon coeur, j'aimerai répondre a la moitié des questions sur le forum par "boost est ton ami"



@Joel: le but du "jeu" sur le forum n'est pas de donner la bonne réponse, mais de donner la réponse que l'utilisateur peut implémenter le problème ne vient pas de boost mais de l'utilisateur =)

[screetch]

(tain je devient philosophe avec l'âge...)

[pyros]

Screetch, je ne peux que te féliciter pour ce post. Tu as parfaitement résumé la situation et mis un terme à un débat qui ne pouvait pas aboutir.

[screetch]

on peut encore en debattre hein =) si on dit jamais aux gens "intègre cette bibliothèque" ils apprennent jamais =)
on a dja de la chance qu'avec boost les includes suffisent souvent, et qu'il y ait pas de problème de link.

[pyros]

Toujours partant pour un bon troll

D'accord pour dire que les lib existent, mais pas d'accord pour dire "C'est la solution !".

Bien souvent, on trouve dans le forum c++ des débutants qui posent des questions sur les chaînes de caractères avec char*, le truc qui sent l'exo de TD à plein nez quoi... Leur répondre "les char* c'est nul, utilise les std::string à la place" ne vas pas les aider.
Mais fixer leur problème et rajouter "quand tu sera grand et que tu aura compris que les char* c'est casse c***, tu pourra utiliser les std::string" là c'est utile.

[Joel F]

@Joel: le but du "jeu" sur le forum n'est pas de donner la bonne réponse, mais de donner la réponse que l'utilisateur peut implémenter le problème ne vient pas de boost mais de l'utilisateur =)

le probleme c'est toujours l'utilisateur, y en aurait pas, ca serait quand meme bien plus simple :o

Plus serieusement, reprenons un exemple hors tout. Mr X debarque et demande comment faire de l'encryptage RSA. Va bien falloir qu'il se paluche librsa ou w/e ou vous allez lui dire de regarder la RFC ? Cacher la misere sous le tapis en n'apprenant pas au gens comment marche un compilo et comment lier une lib est je pense pas bon car le jour ou il devra le faire par obligation, il va bien chialer.

Je passe 789465 ans dans mes cours de C et de C++ a expliquer la chaine de compilation pour justement eviter ces drames. J'ai meme des TPs ou le but est justement d'aller a la peche aux composants car sinon, bon courage pour ecrir eun serveur HTTP avec encodage SSL en 4h de temps.

C'est un probleme d'education, et je pensais qu'un forum servait aussi a faire passer des messages pedagogiques.

[screetch]

le probleme c'est toujours l'utilisateur, y en aurait pas, ca serait quand meme bien plus simple :o

Plus serieusement, reprenons un exemple hors tout. Mr X debarque et demande comment faire de l'encryptage RSA. Va bien falloir qu'il se paluche librsa ou w/e ou vous allez lui dire de regarder la RFC ? Cacher la misere sous le tapis en n'apprenant pas au gens comment marche un compilo et comment lier une lib est je pense pas bon car le jour ou il devra le faire par obligation, il va bien chialer.

Je passe 789465 ans dans mes cours de C et de C++ a expliquer la chaine de compilation pour justement eviter ces drames. J'ai meme des TPs ou le but est justement d'aller a la peche aux composants car sinon, bon courage pour ecrir eun serveur HTTP avec encodage SSL en 4h de temps.

C'est un probleme d'education, et je pensais qu'un forum servait aussi a faire passer des messages pedagogiques.

je suis d'accord, mais une différence peut être que les gens qui sont en cours ont un désir d'apprendre, alors que les gens sur le forum ont parfois besoin d'une solution clé en main. C'est un peu du cas par cas.

Après, avoue qu'il y a un fossé entre du RSA et la distance ligne-point =)

[Gandalf]

Il y a un point a ajouter je crois : il n'y a rarement qu'une solution.
Utiliser une bibliothèque est une solution. Professionnellement, chaque fois que je l'ai proposé, la réponse à été négative... sauf une fois, ou finalement on a fini par redevelopper la bibliothèque en question pour des problèmes de licences

Réinventer la roue en est une autre solution.

[3DArchi]

Bien souvent, on trouve dans le forum c++ des débutants qui posent des questions sur les chaînes de caractères avec char*, le truc qui sent l'exo de TD à plein nez quoi... Leur répondre "les char* c'est nul, utilise les std::string à la place" ne vas pas les aider.
Mais fixer leur problème et rajouter "quand tu sera grand et que tu aura compris que les char* c'est casse c***, tu pourra utiliser les std::string" là c'est utile.

C'est juste ne pas avoir compris que les string sont les chaînes de caractères en C++, pas les const char*. De même que les tableaux dynamiques sont std::vector et non new[]/delete[]. N'importe quel cours un peu sérieux (comme par exemple le dernier Stroustrup, Programmation. Principes et pratique avec C++ ) présente d'abord et avant tout string comme type pour les chaînes de caractères. Je n'ai pas commencé par apprendre la théorie des nombres avant d'apprendre à compter . Donc, NON, les string ce n'est pas pour quand tu seras plus grand. C'est tout le contraire.

je suis d'accord, mais une différence peut être que les gens qui sont en cours ont un désir d'apprendre, alors que les gens sur le forum ont parfois besoin d'une solution clé en main.

Si tu regardes bien les questions, les posteurs font partis des deux catégories : ceux qui sont là pour un besoin donnée, ceux qui veulent terminer leur TD à l'arrache, ceux qui font du dev perso et viennent chercher du support, ceux qui apprennent en partie par eux même, etc...



*****
Ceci dit, je comprends fort bien le coup de sang de Joel hier. Calculer la distance entre un point et un segment est trivial. Mais l'utilisation de Boost.Geometry est trivial : un téléchargement, un dezip, un chemin à ajouter, un #include. Dire qu'il s'agit d'un lance-roquette pour écraser une mouche me semble bien abusif. Et traduit bien le réflexe de beaucoup de développeur : faire tout soi-même plutôt que d'utiliser des outils existants et éprouvés.

Quand on design une carte HW, personne ne propose de fondre son propre micro parce que ceux présents sur le marché ne correspondent pas tout à fait à son besoin. On en prend un et on s'adapte. Pourquoi en SW, la première chose faite est de penser en terme de dev et pas en terme de bibliothèque à utiliser ?

[pyros]

Donc, NON, les string ce n'est pas pour quand tu seras plus grand. C'est tout le contraire.

Sauf si l'intitulé de l'exercice est justement "implémenter une classe string basée sur un const char*".
Tout dépend de la manière dont le cour a été pensé, mais pour ma part lorsque j'ai appris le C et le C++, on nous apprenait déjà à bien gérer notre mémoire à la main avant de nous faire utiliser la stl. Ca permet aussi de comprendre que les string et vector ne sont pas magique, mais juste des class qui font des new/delete au bon moment.

Le problème d'utiliser trop tôt une lib aussi répandu est que certain peuvent penser qu'elle fait partie intégrante du langage (même si elle fait partit de la norme etc..., ça reste une lib externe). Du coup, j'ai déjà vu des gens penser qu'un std::vector était juste un autre type d'allocation, comme le malloc ou le new.
De même en javascript avec Jquery où beaucoup pensent que $ est un mot clef du langage.

Je n'ai pas commencé par apprendre la théorie des nombres avant d'apprendre à compter

Tu me l'avais déjà sortie celle là Là aussi, tout dépend de ce dont tu as besoin. Dans 99% des cas, je te l'accorde. Mais, dès que tu fait des maths un peu plus poussé, c'est toujours bon de savoir ce qu'il y a derrière.
je fait de la 3D, mais ça m'a énormément servi d'avoir fait de l'algèbre linéaire avant.
Et je pense qu'en C++, c'est toujours bon de savoir ce qu'il se passe derrière un string ou un vector. Ce n'est pas une raison pour ne pas les utiliser, au contraire, mais ça permet de mieux les utiliser (éviter des faire des push_back dans une boucle par exemple). Et dans les cas extrêmes (embarqué, template interdit, chef de projet borné), ça permet aussi de s'en passer.

[screetch]

Si tu regardes bien les questions, les posteurs font partis des deux catégories : ceux qui sont là pour un besoin donnée, ceux qui veulent terminer leur TD à l'arrache, ceux qui font du dev perso et viennent chercher du support, ceux qui apprennent en partie par eux même, etc...

ca fait plus de deux catégories =) il me semblait que le posteur ici n'avait pas forcément les moyens d'integrer boost (c'est un jugement au pif avec l'expérience du fofo hein, je peux me tromper). Si dans la question jepense que integrer boost va donner un mal de tête je préfère passer.
Mais c'est clair que si c'est toi qui posait une question j'aurai aucun scrupule a t'envoyer un lien sur boost.YYY, je me doute que tu sais faire.
Si j'ai pu me tromper ici, j'essaye quand même de ne pas le reproduire partout

(aussi j'ai la grande maladie du NIH, donc je suis "biaisé" dans le sens de donner la formule de maths plutôt que du lien vers boost)

*****
Ceci dit, je comprends fort bien le coup de sang de Joel hier. Calculer la distance entre un point et un segment est trivial. Mais l'utilisation de Boost.Geometry est trivial : un téléchargement, un dezip, un chemin à ajouter, un #include. Dire qu'il s'agit d'un lance-roquette pour écraser une mouche me semble bien abusif. Et traduit bien le réflexe de beaucoup de développeur : faire tout soi-même plutôt que d'utiliser des outils existants et éprouvés.

je le concois aussi, c'est du cas par cas. Si tu es un géant, un lance roquette ca ressemble a un briquet. Si tu es un nain, un lance roquette ca ressemble a une grosse bertha. Tout est relatif =)
C'est pour ca que j'évite de dire que j'ai un briquet pour résoudre le problème; et si je suis un géant et que je parlais a un nain il va se brûler

mais en gros tout le monde a raison, ca serait bien de mettre le plus de boost et STL possible dans les réponses.

[koala01]

Le problème d'utiliser trop tôt une lib aussi répandu est que certain peuvent penser qu'elle fait partie intégrante du langage (même si elle fait partit de la norme etc..., ça reste une lib externe).

Mais elle fait partie intégrante du langage...

Tout comme la libc (quelle que soit son origine) fait partie intégrante du langage C!!!

Il existe, certes, différentes implémentations, mais elles sont plus dues à des différences "philosophiques" et "historiques" qu'autre choses...

Du coup, j'ai déjà vu des gens penser qu'un std::vector était juste un autre type d'allocation, comme le malloc ou le new.
De même en javascript avec Jquery où beaucoup pensent que $ est un mot clef du langage.

A ce point là, c'est beaucoup plus un problème de la manière dont le prof a expliqué les choses que quoi que ce soit d'autre...

Et je pense qu'en C++, c'est toujours bon de savoir ce qu'il se passe derrière un string ou un vector. Ce n'est pas une raison pour ne pas les utiliser, au contraire, mais ça permet de mieux les utiliser (éviter des faire des push_back dans une boucle par exemple). Et dans les cas extrêmes (embarqué, template interdit, chef de projet borné), ça permet aussi de s'en passer.

Hé bien, non...

N'oublie pas que le propre de l'orienté objet est, justement, de faire en sorte que l'utilisateur n'ait pas besoin de savoir ce qu'il y a derrière pour utiliser une classe!

Il est, bien sur, toujours intellectuellement intéressant de savoir "ce qui se planque" derrière std::string mais tu n'as, a priori, aucun besoin de le savoir pour pouvoir l'employer.

Tout ce qu'il faut que tu saches "à la base", c'est comment faire les différentes opérations de base (affectation de valeur, comparaison, recherche éventuelle, concaténation, et sans doute une ou l'autre que j'aurais oubliée), mais C'EST TOUT

[Klaim]

N'oublie pas que le propre de l'orienté objet est, justement, de faire en sorte que l'utilisateur n'ait pas besoin de savoir ce qu'il y a derrière pour utiliser une classe!

Tu veux dire, le propre de l'abstraction! Fonctions, classes, bibliothèques, modules, etc. Tout ça c'est fait pour qu'on se concentre sur le problème à résoudre au lieu d'essayer de tout comprendre.


Personnellement je suis d'accord avec Joel.

D'abord parceque ne pas comprendre tous les aspects de C++ qui peuvent compliquer l'intégration d'une lib, c'est un handicap majeur quand on doit utiliser C++. Donc mieu vaut l'apprendre tot. Dans le cas présent, si la solution demandée est urgente, alors j'imagine qu'une solution torchée est envisageable, mais c'est pas une raison pour dire que c'est une meilleure idée. Mieu vaut accepter de choisir une solution probablement bancale (réécrire sois même quelque chose qui est déjà vérifié par des tas de gens dans le monde) uniquement sous des contraintes fortes (pas le droit à des libs externes, ou pas le temps d'ajouter la lib).

Ensuite parcequ'il est incroyableement plus simple de réaliser qu'on a besion d'implémenter sois-même une solution quand on a d'abord utilisé une solution disponible. D'abord utiliser une blibliothque, si ça va pas, alors envisager une autre solution.

Je pense que sans raison forte (apprendre le domaine, être sous contraintes non prise en charge par la solution dispo, connaitre un moyen de faire bien mieu que cette solution), on ne devrait pas réimplémenter ce genre de choses.

[JolyLoic]

Tout dépend de la manière dont le cour a été pensé, mais pour ma part lorsque j'ai appris le C et le C++, on nous apprenait déjà à bien gérer notre mémoire à la main avant de nous faire utiliser la stl. Ca permet aussi de comprendre que les string et vector ne sont pas magique, mais juste des class qui font des new/delete au bon moment.

Présenter les choses dans l'autre sens a au moins trois énormes avantages
- La courbe d'apprentissage beaucoup plus progressive
- Il est possible décrire bien plus tôt des programmes qui ont du sens, ce qui est très motivant
- On a donné une certaine habitude d'utilisation de ce qui au final est utilisé 99% du temps

Du coup, j'ai déjà vu des gens penser qu'un std::vector était juste un autre type d'allocation, comme le malloc ou le new.

Ce n'est pas tellement éloigné de la réalité...

Et je pense qu'en C++, c'est toujours bon de savoir ce qu'il se passe derrière un string ou un vector. Ce n'est pas une raison pour ne pas les utiliser, au contraire, mais ça permet de mieux les utiliser (éviter des faire des push_back dans une boucle par exemple). Et dans les cas extrêmes (embarqué, template interdit, chef de projet borné), ça permet aussi de s'en passer.

Je pense qu'il y a souvent mécompréhension entre partisans du vector/string d'abord et ceux du pointeurs d'abord. Et ce problème transparait dans cette phrase :
Je n'ai jamais dit qu'il ne fallait enseigner que l'utilisation de vector/string, au détriment des pointeurs, et de l'implémentation de vector/string. Et je ne pense pas que quiconque l'ai dit.
Je dis qu'il faut commencer par vector/string, et plus tard dans le cours dire : Maintenant, on a vu les fonctions spéciales de classes, les templates, la gestion mémoire, les exceptions, les pointeurs, on est donc armés pour faire un exercice : écrire soi même un vector/string simplifié ressemblant à ce qu'on utilise depuis le premier programme.

[problèmes de portabilité]
On parle d'une formule de math la.

On touche là à mon avis un des problèmes de boost : Le manque d'indépendance entre bibliothèques, ou du moins le manque de documentation sur les dépendances entre bibliothèques. Je n'ai aucun moyen simple de savoir a priori si boost.geometry utilise par exemple boost.thread (problèmes de portabilité lié à l'os) ou boost.mpl (problèmes de compatibilité lié au support des templates par le compilo). Et si je dois trouver cette information par essais erreurs ou examen du code, le coût d'utilisation de boost peut croître.

Actuellement dans ma boîte, je milite pour utiliser boost. Problème : On doit gérer 20 plateformes différentes, certaines anciennes. De base, tout ne compile pas. J'essaye donc d'extraire de boost la sous partie qui nous intéresse le plus, mais ce n'est pas évident (d'autant plus que les tests unitaires sont cassés depuis l'introduction de filesystem V3).

Donc, oui, dans l'absolu, l'utilisation de boost peut être moins simple qu'il n'y parait.

Ca me fait penser a tout ces gens qui font du C ou du C++ sous MSVC ou autre IDE et qui une fois mis devant un truc en ligne de commande sont perdu.

Je fais partie de ces gens, pas dans le sens où je n'arrive pas à travailler ainsi, mais dans le sens où ma productivité baisse de manière sensible quand je travaille ainsi. Et j'ai aussi rencontrés des gens habitués à la ligne de commande incapables d'utiliser correctement un IDE, ce qui n'est pas mieux.

Je passe 789465 ans dans mes cours de C et de C++ a expliquer la chaine de compilation pour justement eviter ces drames. J'ai meme des TPs ou le but est justement d'aller a la peche aux composants car sinon, bon courage pour ecrir eun serveur HTTP avec encodage SSL en 4h de temps.

C'est un probleme d'education, et je pensais qu'un forum servait aussi a faire passer des messages pedagogiques.

Je suis d'accord que ça fait partie de l'apprentissage. Mais c'est souvent mal ou pas enseigné. Le problème est que ça dépend fortement des outils choisis pour compiler (ide ou pas, si oui, lequel, si non, gmake, autotools, cmake, qmake, scons..., le choix est vaste). Dans le cadre d'un cours, soit on impose l'environnement de développement, et c'est gérable, mais probablement inutile quand l'étudiant sera placé dans la vraie vie, soit on laisse ça libre, et je ne vois pas comment aller au delà de principes généraux, en prévenant l'étudiant qu'il devra de toute façon les décliner plus tard.

Une partie du problème est qu'un prérequis est de maîtriser correctement le maniement des .h, qui est là aussi quelque chose de souvent mal enseigné, car assez difficile, l'outil étant pour le moins rustique...

[pyros]

N'oublie pas que le propre de l'orienté objet est, justement, de faire en sorte que l'utilisateur n'ait pas besoin de savoir ce qu'il y a derrière pour utiliser une classe!

Dans l'idéal, oui. Et je pense que plus le langage est haut niveaux, plus c'est vrai. Mais cela me fait furieusement penser à The law of leaky abstraction. D’ailleurs, dans une encapsulation parfaite, le std::vector n'aurait pas besoin de la méthode reserve.

Quelque soit la qualité de l'encapsulation, elle repose sur les contraintes des couches inférieurs. Dans une utilisation classique, ces contraintes ne sont pas visible (le push_back remplis très bien sa fonction), mais dans les cas d'utilisation extrêmes, l'abstraction atteint ses limites, et "fuit" (baisse inexplicable des perf due aux réallocation/copies intempestives ou des cache miss, allocation impossible à cause de fragmentation mémoire, ...).

Et si on doit dialoguer avec des modules plus "bas niveau", l'abstraction n'est parfois pas suffisante. Preuve en est le fameux &vector[0] pour donner un pointeur sur les données. Sachant que cette technique ne marche pas sur les vector<bool>, car l'implémentation n'est pas la même.

Le plupart des gens n'ont pas besoin de savoir comment marche leur voiture pour conduire. Mais un pilote de F1 ou de rally doit avoir un minimum de connaissance en mécanique pour tirer partie de sa machine.

Pour ce qui est de commencer l'apprentissage par les vector/string ou par les pointeur, je ne pense pas que l'une soit meilleur que l'autre. Elles ont toutes deux des défaut et des qualités. Une personne ayant commencé par les pointeurs fera peut être du code moins propre, mais sera peut être moins bloqué par ces problèmes d'implémentation... Car il faut être honnête, un étudiant qui aura vue les vector en premier ne verra pas l'utilité de se trimbaler des pointeurs à la main, et risque de zapper toute cette partie du cour

Pour le reste, je suis tout à fait d'accord avec Klaim. Utiliser une lib est la meilleur solution, MAIS, il y a des fois où l'ont à pas d'autre choix que de se le refaire soi-même

[Klaim]

pyros> Deux petites choses :

1. attention à bien comprendre ce que j'ai dit : il faut avoir de sacrées bonnes raisons pour refaire une lib! C'est le point le plus important.
2. Tu mélanges comportement et implémentation. On connait le comportement d'un std::vector parcequ'il est spécifié et que cela nous donne des garanties. Même chose pour tout un tas de classes : on s'attends a un certain comportement et on peut imaginer l'implémentation facilement. En revanche ce n'est pas l'implémentation! L'implémentation du std::vector de visual studio, je ne la connais pas, pas plus qu'aucun de tous les compilos que j'ai utilisé. La raison est que je n'ai pas eu besoin d'aller les debugger, il suffisait de connaitre le comportement et l'interface pour les utiliser. Quand je conçois un système (une classe ou un ensemble de classes) c'est précisément ce que je vise et c'est aussi ce qui m'aide à totalement oublier l'implémentation une fois écrite.


Quelque part.... il n'y a que l'intention qui compte

[3DArchi]

Quelque part.... il n'y a que l'intention qui compte

intention contrat

[pyros]

il faut avoir de sacrées bonnes raisons pour refaire une lib

Oui oui oui, c'est très rare, mais ça arrive...

Tu mélanges comportement et implémentation

Il y a quelque chose qui m’échappe alors...
Pour moi, savoir que je peux accéder à mes éléments en temps constant, et que lorsque je fait un push_back, j'ajoute mon élément à la fin fait partie du comportement. Avoir une méthode getPtr() retournant un pointeur sur une zone mémoire aurait fait partie du comportement. Derrière je veux pas savoir comment c'est fait.
Mais savoir que les éléments d'un vector sont stockés contigüe en mémoire est un détail d'implémentation. De même, savoir qu'un push_back peut nécessiter une réallocation et une copie fait partie de l'implémentation, et non du comportement. Ce sont des chose que l'on n'a pas à savoir pour utiliser un vector. non ?

[koala01]

Oui oui oui, c'est très rare, mais ça arrive...


Il y a quelque chose qui m’échappe alors...
Pour moi, savoir que je peux accéder à mes éléments en temps constant, et que lorsque je fait un push_back, j'ajoute mon élément à la fin fait partie du comportement. Avoir une méthode getPtr() retournant un pointeur sur une zone mémoire aurait fait partie du comportement. Derrière je veux pas savoir comment c'est fait.

Tu n'en a pas besoin, vu que :

• tu dispose déjà de comportement permettant de récupérer une référence sur un élément
• tu peux obtenir l'adresse de n'importe quel élément avec l'opérateur "address of"
• tu ne peux pas être sur dans l'absolu que ce soient des éléments et non des pointeurs qui sont stockés dans ton vector... au mieux, cela renverrait alors un "pointeur sur ce qui est stocké", avec les risque d'invalidation que toute manoeuvre d'ajout/suppression entrainte

Mais savoir que les éléments d'un vector sont stockés contigüe en mémoire est un détail d'implémentation.

c'est une garantie de fonctionnement, apportée par la norme et par les cas d'utilisation du vector

De même, savoir qu'un push_back peut nécessiter une réallocation et une copie fait partie de l'implémentation, et non du comportement.

C'est un détail d'implémentation, conséquence directe (et attendue) de la garantie de fonctionnement

Ce sont des chose que l'on n'a pas à savoir pour utiliser un vector. non ?

On n'as pas besoin, lors d'une utilisation clasique de vector de savoir comment cela fonctionne (bien que les spécifications du vector nous en donne des garanties sur l'un et des suspicions sur l'autre).

Par contre, il est bon de savoir les garanties "de complexité" apportées par les différentes fonctions (et de les comparer à celles des fonctions similaires des différentes collections existantes) ne serait-ce que pour pouvoir choisir en connaissance de cause la collection qui sera la plus adaptée à un besoin donné.

Savoir "dans les grandes lignes" ce qui est fait nous permet, effectivement, de choisir directement la collection la plus adaptée, savoir comment c'est implémenté ne nous intéresse pourtant pas.

Mais, bien plus que de savoir les grandes lignes de ce qui est fait (ce qui n'est pas indispensable !! ), il faut au minimum apprendre à travailler dans le bon ordre :

1. d'abord faire quelque chose qui marche,
2. éventuellement remettre en cause le choix d'une collection plutôt qu'un autre
3. améliorer nos propres algorithmes
4. Enfin, si les performances ne sont pas tout à fait au rendez vous, il peut devenir nécessaire de réfléchir à d'éventuelles "micro-optimisations" telles (pour donner un exemple précis) que l'utilisation de reserve sur un vector parce que l'on a la certitude que nous atteindrons un nombre minimal d'élément important.

Je ne dis pas que l'on n'aura jamais besoin d'aller jusqu'au point 4, loin de là, mais je certifie que les plus gros gains de performances seront remarqué entre le point 2 et le point 3