Version imprimable
Bonjour.
Quand est il utile d'utiliser des structures si ce n'est pour la lisibilité du code?
Autre question du même genre, je sais que les pointeurs sont utiles par exemple dans une fonction qui doit renvoyer plusieurs valeurs.
Auriez vous d'autres cas concret d'utilisation des pointeurs?
La lisibilité du code n'est clairement pas l'aspect essentiel, bien que cela joue effectivement.Citation:
Envoyé par Grosbulle
Mais la principale raison pour utiliser des structures, c'est que tu as besoin de travailler sur plusieurs données (de type potentiellement différents) qui "vont bien ensembles"
A priori, le processeur (et le compilateur aussi, d'ailleurs) ne connaît que les types qui permettent de représenter des valeur numériques.
Or, s'il y a -- effectivement -- pas mal de situations dans laquelle une valeur numérique est "suffisante" pour représenter l'information dont on a besoin, il arrive souvent que ... ce ne soit pas suffisant, parce que l'on travaille régulièrement avec des informations beaucoup plus complexes que cela.
On va donc régulièrement décider de "regrouper" plusieurs données qui "vont bien ensemble" pour nous permettre de représenter ces "données complexes"; la donnée que nous pourrons ainsi représenter étant alors "bien plus" que "la seule somme des données qui la compose", car... nous lui aurons donné un nom.
Je ne sais pas où tu as lu cela, mais on n'utilise plus les pointeurs à cette fin depuis... 1998!!!!Citation:
Envoyé par Grosbulle
Si tu veux renvoyer plusieurs données, tu as sans doute intérêt à choisir la collection qui sera la mieux adaptée à l'usage que tu veux en faire. Tu pourras trouver la liste de toutes les collections disponibles ==>ICI<==
(TIP: std::vector est sans doute la collection que l'on utilise le plus souvent, car elle présente les meilleures performances lors de l'accès aux éléments qu'elle contient)
On fait tout pour ne pas utiliser de pointeurs "tels quels"...:Citation:
Envoyé par Grosbulle
- on préfère utiliser les références (voire des références constantes) à chaque fois que possibles
- si on a besoin de pointeurs, on se tourne volontiers vers les pointeurs intelligents (de préférence std::unique_ptr, ou, si on n'a vraiment pas d'autre choix, le couple std::shared_ptr / std::weak_ptr)
- Et on ne décidera de passer au pointeur nu que si l'on y est vraiment contraint et forcé.
Et, quoi qu'il en soit, on veillera toujours à ne pas gérer la mémoire allouée à ces pointeurs à la main ;)
<EDIT>PS: Il n'y a pas de question simple sur les pointeurs, car c'est le pire nid à embrouille que l'on puisse trouver dans un langage comme le C++
Donc tu confirmes que c'est juste pour la lisibilité :mrgreen: : on utilise les structures pour les donnés (<- quasi sans comportement, sauf constructeur, destructeur) (et plus automatique qu'1 structure C) comme les DTO (<- lien wiki) et les classes pour les objets (<- avec comportement)Citation:
Envoyé par koala01
koala01 milite pour le C++ moderne, les smarts pointers et template partout :whistle:Citation:
Envoyé par Grosbulle
Mais il oublie :mrgreen: que le C++ moderne a mis en avant l'échange ("swap") pour éviter les copies temporaires inutiles avec la question de l'appartenance, et aussi d'être plus efficace que les optimisations compilateur (<- lien wiki en anglais) : et cela passe par des pointeurs. Mais c'est au fin fond des objets STL.
Moi j'ai effectivement des exemples, mais ce sont plus des choses que tu fais en C, en "bas niveau" : par exemple lorsque tu as une chaine de caractères et que tu recherches la première occurrence, ou alors tu veux la couper en deux : tu retournes le pointeur de la bonne case.
Mais cela rejoint ce que j'ai dit :mrgreen: : cela permet d'éviter les copies temporaires inutiles, de travailler "in place" si c'est possible, ...
Le regroupement de donnée n'est pas vraiment lié à la lisibilité, mais à la sémantique.Citation:
Envoyé par foetus
Il n'y a rien de plus efficace que l'élision par copie, puisque cette optimisation transforme des instructions en... rien du tout.Citation:
Envoyé par foetus
Et sinon, oui, les conteneurs utilisent des pointeurs en interne. Mais on s'en fiche, il est dans sa petite classe qui s'occupe de le manipuler, en tant qu'utilisateur on ne le voit pas. Les pointeurs nus ont une sémantique nulle: on ne connaît pas les contraintes.
C'est un mauvais exemple:Citation:
Envoyé par foetus
- Tu veux une position ? Alors utilise un itérateur.
- Tu veux une sous-chaîne ? Alors utilise un range / une vue.
- etc
Que l'itérateur soit un pointeur et la vue une paire de pointeur, on s'en fiche. Le concept est plus important et permet de faire abstraction du pointeur. Avec une classe/structure qui définit un concept, on peut facilement ajouter des infos en mode debug pour vérifier les dépassements (comme c'est le cas dans libstdc++ et libc++) sans modification du code utilisateur.
Non, les structures permettent de donner une sémantique aux données. De leur donner un sens. De définir clairement "ce que l'on peut faire" avec la donnée.Citation:
Envoyé par foetus
Je milite effectivement pour le C++, mais absolument pas pour des " smarts pointers et template partout "Citation:
Envoyé par foetus
Je milite pour l'usage des "smarts pointers" au lieu des pointeurs nus, c'est vrai, parce qu'ils nous permettent d'éviter de nombreux problèmes, mais uniquement lorsque l'on se trouve dans une situation dans laquelle on a vraiment besoin de recourir au pointeurs.
Or, ces situations (que les pointeurs soient nus ou intelligents) font office d'exceptions (même si elles arrivent souvent)
Quant aux template, je milite pour leur utilisation "raisonnée".
C'est à dire que je milite effectivement pour l'utilisation de template lorsqu'on en vient à se rendre compte que la logique que l'on met au point pour un type X sera -- effectivement -- la même que pour les types Y et Z.
Je ne l'oublie absolument pas. Je profite "simplement" du fait que la SL manipule correctement les pointeurs en interne pour inciter les gens à ne pas les utiliser eux-mêmes.Citation:
Envoyé par foetus
Car il faut de dire que l'utilisation de pointeurs (et de son pendant : l'allocation dynamique de mémoire) représente un sac de noeuds des plus complexe pour des raisons cependant toutes simples:
- si un pointeur représente une adresse mémoire "invalide" (comprends : qui ne contient pas la donnée que l'on espère) et qu'on essaye d'accéder au contenu de la mémoire, le programme plante
- si on libère trop tôt la mémoire allouée à un pointeur, et que l'on essaye de l'utiliser par la suite, on se retrouve dans la situation (1)
- si on ne libère pas la mémoire au bon moment, on perd la possibilité de le faire par la suite, et cela occasionne une fuite mémoire
- si une exception survient (et qu'elle est récupérée) on a neuf chances sur dix de se retrouver dans un "contexte" dans lequelle nous ne pourrons plus libérer la mémoire
L'utilisation d'indices fait aussi très bien le travail si tu utilises std::string::npos pour représenter l'absence de ton occurrence ;)Citation:
Envoyé par foetus
Tu sais très bien que ce n'est pas vrai :mrgreen: parce que tu m'avais reproché qu'1 développeurCitation:
Envoyé par koala01
- Soit il utilise la STL ou autres bibliothèques externes comme Boost - et donc rarement des pointeurs.
- Soit il est créateur d'une "bibliothèque" - et donc pointeur, rvalue reference, ...
Et c'est là que :mrgreen:
- TOI tu as du mal à comprendre qu'on soit obligé de faire un [peu - beaucoup] de code "bibliothèque"
- MOI j'ai du mal à concevoir d'avoir du code/ un projet 105% compatible STL ou Boost
On dirait plutôt que ce soit toi qui ai du mal à concevoir le fait que l'on puisse adapter son discours à la personne que l'on a en face de soi.
Quand on a un développeur "débutant" en face de soi, on sait qu'il n'a en aucun cas le recul nécessaire à une compréhension correcte de toute la problématique liée à la gestion dynamique de la mémoire.
Et on sait que ce manque de compréhension va forcément lui poser des problèmes sans noms si on décide de le laisser (tenter de) recourir à cette pratique.
La meilleure solution (ou, disons, à tout le moins "la moins mauvaise solution") est de lui dire
A coté de cela, quand nous nous adressons à quelqu'un de "plus expérimenté", nous pouvons tenir un discours qui serait proche deCitation:
Pis de panaque, les femmes et les enfants par dessus bord!
Dans une très grosse majorité des cas, il est tout à fait possible de travailler sans devoir -- en plus -- prendre en compte tous les problèmes liés à la gestion dynamique de la mémoire "manuelle".
On va donc te montrer les moyens d'y arriver de manière à ce que tu puisse te concentrer sur ton problème réel au lieu de devoir de concentrer là dessus.
Plus tard, nous verrons effectivement quelques cas dans lesquels nous n'aurons effectivement pas d'autre choix.
Nous essayerons déjà de limiter au maximum les problèmes en ayant recours aux pointeurs intelligents
Et nous espérons que, quand nous devrons aborder ce problème, tu auras sans doute un "bagage suffisant", un recul suffisant que pour te permettre de comprendre toutes les implications de cette pratique
.Citation:
Bon, tu sais "tout le mal" que l'on peut penser de l'allocaion dynamique de la mémoire, surtout si c'est sans avoir recours aux pointeurs intelligents
Si tu es sur de n'avoir effectivement pas d'autre choix que d'y avoir recours, il faut -- à tout le moins -- que tu veilles à le faire de manière "logique et sensée", avant d(e ré)'expliquer ce que l'on appelle "de manière logique et sensée"
Et j'estime malgré tout (même si ce n'est qu'un avis personnel ;) ) il n'y a aucun mal à rappeler à ce développeur "plus expérimenté" que, malgré tout, la "manière logique et sensée" de s'y prendre correspond finalement à "une manière bien connue et souvent implémentée" de faire les choses, ni de rappeler que NIH est une véritable plaie (hors de tout contexte "purement pédagogique", s'entend) parce qu'il implique souvent de redévelopper une roue qui a de très grosses chances de s'avérer ... être carrée.
Finalement, on peut se foutre pas mal de savoir si la fonctionnalité en question est fournie par la SL, par boost, par Qt ou par n'importe quelle autre bibliothèque largement mieux testée (et sans doute bien mieux optimisée) que ta version NIH. Ce qui importe surtout, c'est que tu peux profiter du "soutien" d'une bibliothèque pour obtenir deux fois plus vite un résultat deux fois plus fiable que celui que le NIH risque de te permettre d'obtenir.
Alors, bien sur, mon sentiment personnel est que l'on a tout "à gagner" (ou, à tout le moins, que l'on n'a "rien à perdre") à préférer l'utilisation d'une bibliothèque tierce au NIH. Et je souhaite bien du plaisir à quiconque voudrais essayer de me convaincre du contraire ;)
Alors, bien sur, je comprends très bien la raison du "mais je n'ai pas le choix" ou du "mais je suis obligé de le faire moi-même". Et il va de soi que, face à une telle raison, je mettrai tout en oeuvre pour permettre à celui qui me pose la question de résoudre son problème.
Mais ce n'est pas parce que je comprends une raison quelconque que je déciderai d'y souscrire ;)
Les pointeurs c'est ce qui retourne le plus le cerveau a vrai dire mais c'est très utile et au fur a mesure on les utilises de plus en plus (avec précaution).
Tu es bon pour relire le file @fabzyr, car on dit justement que les pointeurs sont à éviter et qu'on en utilise très peu. Et que dans 99% ou il est nécessaire, celui-ci est manipulé via une classe qui cache le bousin et fournit une sémantique claire et non ambigu.