Discussion :

[Klaim]

koala01 m'a doublé

[3DArchi]

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

Non, ca fait parti du contrat de std::vector :

The elements of a vector are stored contiguously, meaning that if v is a vector<T, Allocator> where T is some type other than bool, then it obeys the identity &v[n] == &v[0] + n for all 0 <= n < v.size().

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.

ça se discute. Le contrat de std::vector spécifie vector::capacity et vector::reserve. En revanche, rien n'est imposé en terme de stratégie d'allocation du moment que les post conditions de ces 2 fonctions sont garanties (en gros, qu'il n'y as pas d'allocation avant autant d'ajout que retourne capacity et après reserve, capacity>=paramètre).

[pyros]

Cela fait partie du contrat, mais n'est-ce pas un contrat sur la manière dont les données sont stocké en interne ?
Je suis d'accord que, du moment qu'il y a un contrat assez précis, l’implémentation découle plus ou moins de ce dernier (on ne vas pas implémenter un conteneur avec accès en temps constant avec des listes chaînées), mais forcer l'implémentation à utiliser une manière de stocker les données plutôt qu'une autre, je trouve qu'on grattouille un peu les limites de l'encapsulation.

[koala01]

Cela fait partie du contrat, mais n'est-ce pas un contrat sur la manière dont les données sont stocké en interne ?
Je suis d'accord que, du moment qu'il y a un contrat assez précis, l’implémentation découle plus ou moins de ce dernier (on ne vas pas implémenter un conteneur avec accès en temps constant avec des listes chaînées), mais forcer l'implémentation à utiliser une manière de stocker les données plutôt qu'une autre, je trouve qu'on grattouille un peu les limites de l'encapsulation.

Pas vraiment...

N'oublie pas que "tableau", "pile", "file", "liste chainée" etc sont des concepts qui se rapportent à la gestion d'éléments plusriels que l'on retourve ou que l'on doit implémenter dans tous les langages.

Ces "concepts" sont clairement définis en termes de fonctionnalité et de complexité pour ce qui concerne l'ajout, la suppression et le parcours d'éléments: que tu travailles avec une liste simplement chainée en C, en C++, en Java ou en n'importe quel langage que tu puisse envisager, le but que tu recherche est de permettre l'insertion, l'ajout et la suppression en temps constant et de favoriser l'accès séquentiel aux différents élément.

Tu t'astreint donc à un contrat garantissant ces complexités, ce qui, naturellement, amènera à une implémentation sensiblement similaire quel que soit le langage utilisé.

Il est donc tout à fait logique que la norme, tout en laissant l'implémentation libre, explicite clairement les contrats qui devront être respectés pour les différents types de colletions, vu que ces contrats font partie de ce que l'on attend des concepts eux-même

[Aleph69]

Bonsoir,

le problème initial qui a généré toute cette discussion est de savoir comment calculer la distance entre un point et un segment. A mon sens, la meilleure réponse possible a été donnée pratiquement juste après : un lien vers un site expliquant comment faire et donnant une formule facile à implémenter. Ecrire sa propre fonction calculant cette distance ne relève pas du tout syndrome NIH. La "roue" existe, on l'a donnée, il reste à l'implémenter. Conseiller une grosse bibliothèque (boost, geos, ou toute autre) pour faire cela, c'est vraiment prendre un marteau pour écraser une mouche pour reprendre une expression déjà utilisée dans cette discussion. Je ne vois même pas où est le débat sur ce point. En fait, la question initiale ne relève même pas du C++ : elle n'a pas été postée au bon endroit.

En revanche, c'est une bonne chose de mentionner que ces bibliothèques existent et de montrer qu'il peut être très simple d'y avoir recours : c'est ce que 3DArchi a pris le temps de faire en fournissant un exemple d'utilisation pour le problème de calcul de distance concerné. Ensuite, c'est à la personne qui est venu poser sa question de déterminer si elle va juste avoir besoin de calculer la distance d'un point à un segment ou si elle va en fait avoir besoin d'une multitude de fonctions géométriques du même genre. Dans ce dernier cas, il y a effectivement syndrome NIH parce qu'elle va passer plus de temps à tenter d'écrire ces fonctions par elle-même plutôt que de se familiariser avec une bibliothèque (installation comprise), le tout pour un résultat qui risque fortement d'être de moins bonne qualité que ce que propose telle ou telle bibliothèque (réinvention de la roue carrée).

Pour ce qui est du syndrome NIH en entreprise, c'est un peu plus délicat. Cela dépend de beaucoup de facteurs techniques/humains et il me semble difficile de faire des généralités sur ce point. Je précise au passage que ce n'est pas mieux dans le secteur public (CNRS, ...) qu'ailleurs. Joel F travaille dans un laboratoire d'informatique mais je suis certain qu'il sait aussi bien que moi que dans d'autres spécialités, les connaissances en informatique sont... disons plus légères.

En ce qui me concerne, je suis un utilisateur de ce forum, pas du tout un expert du c++. J'apprends énormément de choses ici que je n'ai pas vues pendant mes études. Ceci dit, maintenant que je commence à bien connaître le forum, je peux tout de même formuler une critique importante (d'utilisateur). Quasi-systématiquement, lorsque je pose une question, on me renvoie vers boost, même si je précise dans mon intitulé que ce n'est pas le but recherché. Il y a des personnes qui développent dans boost et je peux comprendre qu'elles cherchent à promouvoir cette bibliothèque mais ce n'est pas toujours dans l'intérêt de la personne qui a posté une question. Je distinguerai deux types de réponses :

1. utilise boost.geometry c'est très bien, voici les avantages/inconvénients, je te donne un petit exemple pour que tu puisses démarrer et te donner envie d'utiliser cette bibliothèque
2. boost.geometry

La réponse 1 est parfaite, on y apprend des choses, c'est ce qu'a fait 3DArchi pour ne pas le citer. Je ne citerai pas ceux qui ont tendance à faire la réponse 2 mais parfois je me demande s'ils savent à quel point leur réponse ne sert (pratiquement) à rien. Premièrement, ce serait mieux de faire une phrase (majuscule + point), introduite par quelques salutations. Deuxièmement, pourquoi boost? Parce que c'est mieux ou parce que vous participez au développement?

Il faut admettre qu'il y a des personnes qui viennent ici pour apprendre (à mon avis la majorité mais je peux me tromper) et qui ont besoin de faire quelques roues carrées pour progresser.

[koala01]

Bonsoir,

le problème initial qui a généré toute cette discussion est de savoir comment calculer la distance entre un point et un segment. A mon sens, la meilleure réponse possible a été donnée pratiquement juste après : un lien vers un site expliquant comment faire et donnant une formule facile à implémenter. Ecrire sa propre fonction calculant cette distance ne relève pas du tout syndrome NIH. La "roue" existe, on l'a donnée, il reste à l'implémenter. Conseiller une grosse bibliothèque (boost, geos, ou toute autre) pour faire cela, c'est vraiment prendre un marteau pour écraser une mouche pour reprendre une expression déjà utilisée dans cette discussion. Je ne vois même pas où est le débat sur ce point. En fait, la question initiale ne relève même pas du C++ : elle n'a pas été postée au bon endroit.

En revanche, c'est une bonne chose de mentionner que ces bibliothèques existent et de montrer qu'il peut être très simple d'y avoir recours : c'est ce que 3DArchi a pris le temps de faire en fournissant un exemple d'utilisation pour le problème de calcul de distance concerné. Ensuite, c'est à la personne qui est venu poser sa question de déterminer si elle va juste avoir besoin de calculer la distance d'un point à un segment ou si elle va en fait avoir besoin d'une multitude de fonctions géométriques du même genre. Dans ce dernier cas, il y a effectivement syndrome NIH parce qu'elle va passer plus de temps à tenter d'écrire ces fonctions par elle-même plutôt que de se familiariser avec une bibliothèque (installation comprise), le tout pour un résultat qui risque fortement d'être de moins bonne qualité que ce que propose telle ou telle bibliothèque (réinvention de la roue carrée).

Pour ce qui est du syndrome NIH en entreprise, c'est un peu plus délicat. Cela dépend de beaucoup de facteurs techniques/humains et il me semble difficile de faire des généralités sur ce point. Je précise au passage que ce n'est pas mieux dans le secteur public (CNRS, ...) qu'ailleurs. Joel F travaille dans un laboratoire d'informatique mais je suis certain qu'il sait aussi bien que moi que dans d'autres spécialités, les connaissances en informatique sont... disons plus légères.

En ce qui me concerne, je suis un utilisateur de ce forum, pas du tout un expert du c++. J'apprends énormément de choses ici que je n'ai pas vues pendant mes études. Ceci dit, maintenant que je commence à bien connaître le forum, je peux tout de même formuler une critique importante (d'utilisateur). Quasi-systématiquement, lorsque je pose une question, on me renvoie vers boost, même si je précise dans mon intitulé que ce n'est pas le but recherché. Il y a des personnes qui développent dans boost et je peux comprendre qu'elles cherchent à promouvoir cette bibliothèque mais ce n'est pas toujours dans l'intérêt de la personne qui a posté une question. Je distinguerai deux types de réponses :

1. utilise boost.geometry c'est très bien, voici les avantages/inconvénients, je te donne un petit exemple pour que tu puisses démarrer et te donner envie d'utiliser cette bibliothèque
2. boost.geometry

La réponse 1 est parfaite, on y apprend des choses, c'est ce qu'a fait 3DArchi pour ne pas le citer. Je ne citerai pas ceux qui ont tendance à faire la réponse 2 mais parfois je me demande s'ils savent à quel point leur réponse ne sert (pratiquement) à rien. Premièrement, ce serait mieux de faire une phrase (majuscule + point), introduite par quelques salutations. Deuxièmement, pourquoi boost? Parce que c'est mieux ou parce que vous participez au développement?

Il faut admettre qu'il y a des personnes qui viennent ici pour apprendre (à mon avis la majorité mais je peux me tromper) et qui ont besoin de faire quelques roues carrées pour progresser.

Peut etre ne l'as tu pas remarqué, mais la modération a bien fait sont travail et a scindé la discussion...

Nous sommes ici dans une nouvelle discussion qui, justement, ouvre le débat sur le NIH, pour, justement, éviter de "pourrir" la celle d'origine avec des considérations qui n'ont rien à voir avec le problème du PO

[Aleph69]

@koala : je suis désolé mais c'est loin d'être clair étant donné que le lien vers l'ancienne discussion est donné dans le premier message et qu'il y est mentionné que la présente discussion y fait suite.

[koala01]

@koala : je suis désolé mais c'est loin d'être clair étant donné que le lien vers l'ancienne discussion est donné dans le premier message et qu'il y est mentionné que la présente discussion y fait suite.

Au contraire, on indique ainsi clairement l'origine du débat auquel on se livre ici, et on indique de l'autre coté qu'un débat possiblement intéressant a été ouvert suite à la question (ou à une réponse dans le cas présent )

[Aleph69]

@koala : à quoi cela sert-il de m'indiquer l'origine du débat si je ne peux en parler? Ou alors je n'ai pas compris ton intervention concernant mes remarques?

[Joel F]

Bonsoir,
La "roue" existe, on l'a donnée, il reste à l'implémenter. Conseiller une grosse bibliothèque (boost, geos, ou toute autre) pour faire cela, c'est vraiment prendre un marteau pour écraser une mouche pour reprendre une expression déjà utilisée dans cette discussion.

Non, ce qui existe a ce point, c'est le plan de la roue.
Boost ou geos, c'est le choix entre Michelin et Bridgestone.

Tu coules la resine de tes pneux toi ? Moi, non.

Pour ce qui est du syndrome NIH en entreprise, c'est un peu plus délicat. Cela dépend de beaucoup de facteurs techniques/humains et il me semble difficile de faire des généralités sur ce point. Je précise au passage que ce n'est pas mieux dans le secteur public (CNRS, ...) qu'ailleurs. Joel F travaille dans un laboratoire d'informatique mais je suis certain qu'il sait aussi bien que moi que dans d'autres spécialités, les connaissances en informatique sont... disons plus légères.

Si tu savais, tu ferais comme moi, tu pleurerais du sang

En ce qui me concerne, je suis un utilisateur de ce forum, pas du tout un expert du c++. J'apprends énormément de choses ici que je n'ai pas vues pendant mes études. Ceci dit, maintenant que je commence à bien connaître le forum, je peux tout de même formuler une critique importante (d'utilisateur). Quasi-systématiquement, lorsque je pose une question, on me renvoie vers boost, même si je précise dans mon intitulé que ce n'est pas le but recherché. Il y a des personnes qui développent dans boost et je peux comprendre qu'elles cherchent à promouvoir cette bibliothèque mais ce n'est pas toujours dans l'intérêt de la personne qui a posté une question.

On pousse rien. Si boost reviens tout le temps ou POCO ou w/e, c'est que l'implantation est la, tester et valider. Et je repete apprendre a se servir de composants logiciels, c'est 101 du developement,

[Aleph69]

Non, ce qui existe a ce point, c'est le plan de la roue.
Boost ou geos, c'est le choix entre Michelin et Bridgestone.

Tu coules la resine de tes pneux toi ? Moi, non.

Non, non, il s'agit bien de la roue. Comme je l'écrivais, la question n'a rien à voir avec le c++ et aurait dû être postée dans un autre forum (algorithmes).

En ce qui concerne le fait de réinventer la roue proprement dit, on pourrait faire ce reproche à boost comme à beaucoup d'autres bibliothèques.

Si tu savais, tu ferais comme moi, tu pleurerais du sang

Je ne connais pas cette expression et le contexte ne me permet d'en déduire le sens.

On pousse rien. Si boost reviens tout le temps ou POCO ou w/e, c'est que l'implantation est la, tester et valider. Et je repete apprendre a se servir de composants logiciels, c'est 101 du developement,

Je ne reproche pas de conseiller boost ou tout autre bibliothèque. Je critique la manière dont cela est fait parfois. Et je suis en parfait accord avec ta seconde phrase même si implémenter quelques fonctions élémentaires par soi-même fait également parti de l'apprentissage. L'un ne doit pas empêcher l'autre.

[3DArchi]

Bonjour,

@aleph69: merci pour tes remarques intéressantes. J'en comprends la remarque implicite. Je me souviens avoir été dérouté lorsque j'ai commencé à fréquenter ce forum et que l'on me répondait par d'obscurs sigles... comme NIH

Je pense qu'il est aussi important de comprendre que la première bonne solution à un problème est : "existe-t-il une bibliothèque qui fait déjà ça ?". Ca devrait être le premier (ou presque) cours de programmation.

La question était-elle posée au bon endroit ? J'ai tendance à penser que si elle l'a été sur le forum C++, c'est qu'une solution mathématique n'était pas l'objectif premier mais bien une implémentation C++. A partir de là, il me semble que diriger vers une bibliothèque est assez pertinent.

Un marteau pour écraser une mouche ? Depuis le début de cette question, je pense et je maintiens que Boost.Geometry est de loin une solution triviale : un téléchargement, un dezip (certes très gros, mais pas plus que mon IDE), un #include et c'est tout ! Je suis curieux de savoir combien de temps on passe à faire sa propre fonction de calcul ? Entre se demander quel type pour les points, les segments, puis implémenter le calcul, se rendre compte qu'on a fait un ou deux bugs, les corriger. Si on est bien, on a un petit document de design, un jeu de test U, et soyons fou, une revue par un pair et pourquoi pas un outil d'analyse statique. Il est où le marteau ?

[pyros]

Je pense qu'il est aussi important de comprendre que la première bonne solution à un problème est : "existe-t-il une bibliothèque qui fait déjà ça ?".

Dans le cas général, oui. Mais je rejoins Aleph69, c'est toujours bon de donner une lib et encore mieux de donner un exemple d'utilisation, mais dans l'absolue ça ne répond pas à la question initial. Cela ne peut venir qu'en complément.

On ne sais jamais à quels contraintes est soumis la personne qui pose la question. Peut-être utilise-t-elle déjà une lib maison auquel il manque quelques fonction. Peut-être son chef refuse d'intégrer une nouvelle lib juste pour ça (pour des raisons plus ou moins justifiés). Peut être est-ce un exercice de TD où elle doit jutement réinventer la roue. Peut être n'a-t-elle tout simplement pas envie d'utiliser une lib et qu'elle souhaite la recoder elle-même pour s'amuser. C'est bon des fois d'aller au McDo manger de la m***

Bref, il y a une multitude de cas particulier, certes minoritaire, qui font qu'utiliser une lib n'est pas forcement la réponse souhaitée.

[koala01]

Dans le cas général, oui. Mais je rejoins Aleph69, c'est toujours bon de donner une lib et encore mieux de donner un exemple d'utilisation, mais dans l'absolue ça ne répond pas à la question initial. Cela ne peut venir qu'en complément.

On ne sais jamais à quels contraintes est soumis la personne qui pose la question. Peut-être utilise-t-elle déjà une lib maison auquel il manque quelques fonction. Peut-être son chef refuse d'intégrer une nouvelle lib juste pour ça (pour des raisons plus ou moins justifiés). Peut être est-ce un exercice de TD où elle doit jutement réinventer la roue. Peut être n'a-t-elle tout simplement pas envie d'utiliser une lib et qu'elle souhaite la recoder elle-même pour s'amuser. C'est bon des fois d'aller au McDo manger de la m***

Bref, il y a une multitude de cas particulier, certes minoritaire, qui font qu'utiliser une lib n'est pas forcement la réponse souhaitée.

J'ai l'impression que l'on est d'accord sur le principal, sauf sur l'ordre dans lequel les choses "doivent" se faire...

Ce que disent 3D, joel et tant d'autres (et à quoi je souscris, d'ailleurs), c'est que le plus facile, c'est de prendre une roue "toute faite", pour éviter de nous retrouver avec une roue carrée, mal centrée ou ovoide, et pour éviter de s'attaquer à une théorie dont la personne n'a sans doute que faire, et que ce devrait être la première solution proposée.

Puis, si, pour une raison X, Y ou Z dont il ne nous appartient pas de juger la pertinence, la roue toute faite ne convient pas, il sera toujours temps de nous ateler à la création d'une roue "maison".

Mais cela passera par un tas de théorie, dont une partie sera sans doute fort éloignée du problème (mais nécessaire pour la compréhension) et pour un résultat pouvant présenter quelques lacunes

[Luc Hermitte]

Je ne reproche pas de conseiller boost ou tout autre bibliothèque. Je critique la manière dont cela est fait parfois.

C'est exactement la même chose que de répondre FAQ ou STFW. Mais en un chouilla plus constructif (que STFW) vu que l'on a déjà donné la piste.
Ceux qui répondent n'ont pas forcément de le temps pour rédiger une réponse de qualité. Ils ne sont pas là pour donner des solutions NIHiennes clé en main (pour exactement les mêmes raisons que l'on ne répond pas aux exo en donnant les solutions clés en main) ; sans parler que les snippets de codes donnés dans les forums devraient être sous droit d'auteur et non dans le domaine public si on reste strict, ce qui poserait normalement des problèmes pour les intégrer dans des produits libres, open-source ou propriétaires.

De plus, ce n'est pas parce que l'on connait le nom d'une lib qui répond au besoin que l'on va savoir comment l'utiliser. Pourquoi serait-ce au bénévole qui répond à lire la doc d'un truc dont il n'a pas forcément l'utilité ou pour lequel il n'a pas la curiosité d'en savoir plus ? Devrait-il ne pas donner la piste de réponse parce qu'il n'a pas envie/temps de faire le boulot de l'OP pour voir comment ça marche exactement ?

NB: bien sûr après il y a maintes façons de répondre pour dire "regarde le COTS machin, il résout ton problème normalement".

[oodini]

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.

Il y aussi beaucoup de gens qui font du C ou du C++ sous Emacs ou vi et qui une fois mis devant Visual C++ sont perdus...

[Luc Hermitte]

<on n'est pas vendredi pourtant...>
Non, pas perdus. Mais le coup de gueule est normal. Quand on passe d'un éditeur de code sources à un truc aussi évolué que notepad pour éditer son texte, c'est très agaçant.

Définir un projet pour compiler un malheureux fichier c'est idiot aussi, mais bon, c'est comme ça.
</>

[oodini]

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

Ça peut être plus que ça.
Je crois me souvenir que dans Effective C++, la taille des objets String, pour une chaîne vide varie d'un facteur 1 à 4 selon l'implémentation.

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

Quand tu dois interagir avec une bibliothèque C, c'est loin d'être un détail.

[Klaim]

Ça peut être plus que ça.
Je crois me souvenir que dans Effective C++, la taille des objets String, pour une chaîne vide varie d'un facteur 1 à 4 selon l'implémentation.

Il me semble avoir lu quelque part que ce n'est plus vrai, mais ça mériterai vérification.

[3DArchi]

Définir un projet pour compiler un malheureux fichier c'est idiot aussi, mais bon, c'est comme ça.

Code commande en ligne VC++ :

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

cl main.cpp