IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Affichage des résultats du sondage: Quelles sont les difficultés majeures qui bloquent l'apprentissage du C++ en 2012

Votants
106. Vous ne pouvez pas participer à ce sondage.
  • La qualité de l'enseignement du C++

    60 56,60%
  • La gestion bas niveau de la mémoire

    24 22,64%
  • L'absence de mécanisme de protection (garbage collector)

    16 15,09%
  • Une syntaxe trop complexe

    26 24,53%
  • Pas assez de fonctionnalités dans le langage de base (IHM)

    29 27,36%
  • Trop d'outils ou de bibliothèques externes

    16 15,09%
  • Des abstractions haut niveau trop complexes (template)

    18 16,98%
  • L'évolution trop lente du langage et le retard qu'il a pris

    21 19,81%
  • Le manque de portabilité du C++

    7 6,60%
  • Un système de compilation beaucoup trop complexe

    32 30,19%
  • Les messages d'erreurs incompréhensibles

    47 44,34%
  • Le manque de ressources pour l'apprentissage

    14 13,21%
Sondage à choix multiple
C++ Discussion :

Le C++, un langage orienté débutant ! [Débat]


Sujet :

C++

  1. #101
    Membre éclairé Avatar de seeme
    Profil pro
    Inscrit en
    Octobre 2005
    Messages
    430
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France

    Informations forums :
    Inscription : Octobre 2005
    Messages : 430
    Points : 791
    Points
    791
    Par défaut
    Citation Envoyé par Luc Hermitte Voir le message
    Dans le standard, en gros tous les pointeurs bruts, plus les types ressources hérités du C (-> FILE) (& POSIX -> sockets, ...).
    Je t'invite à regarder la FAQ. Si ton prof était au point, il t'a peut-être présenté le concept sans introduire le mot clé.

    Mais c'est une situation classique : ils préfèrent montrer la syntaxe et le monde C plutôt que d'enseigner le développement robuste dans un contexte C++ où les exceptions existent. Si tant est qu'ils soient initiés à la gestion des ressources et aux situations exceptionnelles en C++.


    Un enseignant est là pour inculquer les bonnes pratiques.
    Et il est plus important pour un élève de disposer de bonnes pratiques qui assurent du code robuste, que de survoler les détails de la gestion de la mémoire en C (cf plus haut -> en C++ il ne faut pas oublier les exceptions, et donc le RAII) et avoir du code qui va très vite .... dans le mur.
    Ca on en veut pas. Quand on met des développeurs dans une batterie pour pondre au KLoC du code, la (micro souvent) optimisation induite par vector vs list vs new[] est bien moins pertinente que la robustesse. Un ou deux plus experts que les autres, ou une seconde phase de réglages suffisent amplement pour régler ces détails. Et cela coutera moins cher que la chasse aux fuites et aux segfaults.
    Je suis entièrement d'accord.

  2. #102
    Membre à l'essai
    Profil pro
    Inscrit en
    Janvier 2009
    Messages
    10
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2009
    Messages : 10
    Points : 12
    Points
    12
    Par défaut
    Oui. Le c++ est difficile, parce qu'il a plusieurs couches - comme les oignons (et les ogres Pixar):

    1) Le C de base et la gestion de memoire a l'aide des references, pointeurs, tableaux.
    Moche et peu securise, mais ultra-performant et indispensable dans des environnements bas-niveau comme l'embarque.

    2) Le C++ oriente objet, c'est a dire
    A. le polymorphisme a l'execution (heritage,fontions virtuelles)
    - utile mais plein d'ambiguites dans la norme
    - en plus ca casse la compatibilite binaire du C
    B. l'encapsulation grace a public/prive/protege
    - utile mais ambigu aussi. Tous les cas de figure ne sont pas utilises.
    => L'oriente objet est actuellement, a mon avis, sur-represente dans les cours pour debutants. C'est la partie du standard a reecrire a mon avis.

    3) La metaprogramation templates - ou polymorphisme a la compilation
    - tres utile et en train d'evoluer rapidement.
    - mal ficele: oblige d'exposer le code dans les _tpl.h
    => sous-represente dans les cours debutants
    Et pour cause ca conflicte pas mal avec l'oriente objet.

    La bibliotheque standard est basee sur 1 + 2 + 3.
    Je pense qu'elle est indispensable ! L'implementation comme l'utilisation correcte sont a enseigner.

    4) Les directives pre-processeur - indispensable pour faire certaines choses
    => sous-represente dans les cours debutants
    Il y a une espece de tabou la dessus.

    Je crois que le C++ est une evolution ratee du C.
    Et j'en veux pour preuve le succes de la librairie Qt,
    qui detourne subtilement certains mecanismes pour contourner des limitations.
    Boost et d'autres librairies ont contribue a dorer la pilule, et c++11 a comble pas mal d'insuffisances, donc je sais pas trop ce que ca donne(ra) maintenant.

    Mais j'ai utilise pendant 2 ans le C++ 2003 tel qu'implemente par MSVC2005 et gcc 3.4.x et j'en ai souffert !

    Edit:
    Les raisons principales que j'ai donnees:
    A. Absence d'enseignement de qualite du C++. On enseigne trop superficiellement 2 + 3 + 4. On ne parle pas assez des patterns.
    Mais attention: je ne pense pas qu'on puisse enseigner le C++ sans parler des pointeurs et donc du C (le 1)
    Trop de choses ? Il faut commencer tot ! ( Lycee 1ere S ?)
    B. Absence de portabilite du C++.
    Le build-system est different, les messages d'erreur et warning sont differents, le traitement des template est different, le traitement de thread est different (du moins dans C++2003)
    Pour faire du multi-plateformes il faut avoir 2 vies au moins.
    C. Trop d'outils et de bibliotheques externes/pas assez dans le langage de base
    Trop souvent on doit se faire suer a compiler et utiliser une bibliotheque C, mono-plateforme, ou du fortran, ou du Qt (faux C++) pour pouvoir faire des choses tres simples.

    D'ailleurs B et C viennent aggraver le A:
    Pour pouvoir enseigner le C++ il faut rester mono-plateforme et avoir un IDE beton, avec plein de bibliotheques externes installees et integrees impecablement au build-system.

  3. #103
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    Juin 2010
    Messages
    7 113
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : Juin 2010
    Messages : 7 113
    Points : 32 958
    Points
    32 958
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par jeanlou Voir le message
    Je pouvais écrire un programe de plusieurs milliers de lignes, après compilation, il suffisait d'un petite disquette pour le copier !

    Quand est-il aujourd'hui ? Bientôt il faudra un Blu-Ray !
    Aujourd'hui ce sont les assets qui prennent le plus de place et nécessitent autant de stockage.
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  4. #104
    Membre émérite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2008
    Messages
    832
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Décembre 2008
    Messages : 832
    Points : 2 625
    Points
    2 625
    Par défaut
    Citation Envoyé par Hardwarista Voir le message
    A. Absence d'enseignement de qualite du C++. On enseigne trop superficiellement 2 + 3 + 4. On ne parle pas assez des patterns.
    Mais attention: je ne pense pas qu'on puisse enseigner le C++ sans parler des pointeurs et donc du C (le 1)
    Trop de choses ? Il faut commencer tot ! ( Lycee 1ere S ?)
    B. Absence de portabilite du C++.
    Le build-system est different, les messages d'erreur et warning sont differents, le traitement des template est different, le traitement de thread est different (du moins dans C++2003)
    Pour faire du multi-plateformes il faut avoir 2 vies au moins.
    C. Trop d'outils et de bibliotheques externes/pas assez dans le langage de base
    Trop souvent on doit se faire suer a compiler et utiliser une bibliotheque C, mono-plateforme, ou du fortran, ou du Qt (faux C++) pour pouvoir faire des choses tres simples.

    D'ailleurs B et C viennent aggraver le A:
    Pour pouvoir enseigner le C++ il faut rester mono-plateforme et avoir un IDE beton, avec plein de bibliotheques externes installees et integrees impecablement au build-system.
    Pour ce qui est de la portabilité du système de build, je ne vois pas trop... tu parles des options du compilateur?
    Si c'est le cas, alors je te rejoins, je ne crois pas que la norme impose les options de compilation. En même temps, elle ne pourrait pas imposer grand chose, puisque son rôle est de s'assurer que chaque architecture puisse avoir son implémentation, sans être bridée. Ce qui implique de pouvoir ajouter des options pour utiliser les optimisations particulières de cette architecture.
    Tiens, maintenant que j'y pense... Il serait très bien possible de créer un compilateur C++ qui génère du bytecode java. Si ça n'existe pas, c'est sûrement parce que les dev C++ n'apprécient pas nécessairement l'idée des machines virtuelles...
    Mais c'est possible. D'ailleurs, C++ l'a fait pour .NET (C++/CLI il me semble).

    A priori, tu as utilisé visual 2003 en dernier. Sache qu'avec visual studio, le respect du standard est franchement douteux (je pense que ça s'améliore, mais tout le monde connaît, je pense, l'amour de microsoft pour le respect des standards dans les années 90/début 2000). Par exemple, stdint.h, il ne connaît pas, c'est pourtant enfantin à implémenter (juste une suite de #define bon sang!) et présent dans le standard de 99!
    Autre chose, du vécu que j'ai eu avec d'anciennes versions de VS: du code qui compilait sur 2003 ne compilait plus sur 2005. Parce que l'auteur de cette immondice avait utilisé des extensions propriétaires de ms qui ont été retirées ensuite. Génial...

    Je fais, personnellement, du multi plateforme sans le moindre problème, je suis encore jeune et n'ai pas dépensé tant de temps que ça à m'y former.
    Limite, je pense que j'aurai plus de difficultés à programmer en mono plateforme, parce qu'il me faudrait apprendre toutes les optimisations spécifiques à chaque plate forme. Et je suis pas un grand motivé pour le travail dupliqué... (programmeur en même temps )
    En fait, c'est la l'intérêt d'utiliser les choses inclues dans la SL: ces choses sont écrites pour avoir le même résultat final (notez bien: pas le même comportement, le même résultat. Pas forcément avec les même perfs non plus d'ailleurs).
    D'ailleurs, je n'utilise ni Qt, ni Fortran (que je ne connais pas... je devrais peut-être y jeter un oeil un jour?) et encore moins de bibliothèques mono plateformes.
    En C++ (pas en C donc) il y a:
    IHM => wxWidgets (qui ont aussi réinventé la roue, pour certains trucs, comme Qt et avec les mêmes raisons je pense).
    Jeux 2D => SFML
    Jeux 3D => Ogre3D
    Reconnaissance d'images => OpenCV (bien qu'honnêtement la doc du binding C++ est à chier, je préfère du coup utiliser l'API C)
    Systèmes de fichiers, threads & co => boost

    WxWidgets fonctionne de la même façon que tous les framework d'IHM. SFML est simple comme bonjour à utiliser, Ogre, je sais pas, pas eu l'occasion de tester, et OpenCV ben... faut savoir lire la doc, mais c'est plutôt fréquent ça non?

    Pour les template, ils fonctionnent pareil sur tous les compilateurs qui respectent la norme. Par contre, ce qui est sûr, c'est que les messages d'erreur quand on les utilise sont assez prise de tête.
    Et naturellement, ça change selon le compilateur, ainsi que les warning. Peut-être qu'effectivement, il serait possible de normaliser les messages d'erreurs et warning, mais je soupçonne que ça n'est pas le cas pour éviter d'avoir à maintenir une panoplie de messages d'erreurs. Mais ça n'a rien a voir avec la portabilité. Du code sans erreur ni warning aura les mêmes messages d'erreurs et warning sur n'importe quel compilo standard. (et pour cause: il n'en aura pas ).

    Au niveau des reproches que tu fais au C++, je vais me permettre d'en corriger un.
    Citation Envoyé par Hardwarista Voir le message
    2) Le C++ oriente objet, c'est a dire
    A. le polymorphisme a l'execution (heritage,fontions virtuelles)
    - utile mais plein d'ambiguites dans la norme
    - en plus ca casse la compatibilite binaire du C
    En fait, quand on utilise l'orienté objet, on casse la compatibilité binaire avec n'importe quel autre compilateur ou, voire même théoriquement avec des options de compilations différentes sur le même compilateur.
    Ceci, parce que dans un souci d'optimisation ils ont lâché la bride sur l'implémentation. C'est une des forces du C++, mais qui a un revers de médaille.
    Cela dis... quand on veut écrire des systèmes de plug-in, on passe par le paradigme du C, vu qu'on est en C++ on peut jongler entre les paradigmes, et c'est la une des plus grosses forces de ce langage.

    Pour l'encapsulation et la notion de public/protected/private, tous les langages OO l'ont. Ca n'a rien à voir avec C++.

    Et pour clôturer: j'aimerai que tu m'indiques en quoi la méta programmation est en conflit avec l'objet? J'ai envie de dire que c'est comme si on avait un langage pour que le compilateur génère du code lui même a partir d'un modèle. Modèle qui est lui extrêmement réutilisable, ce qui correspond tout à fait à la philosophie objet.

  5. #105
    En attente de confirmation mail

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2004
    Messages
    1 391
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Doubs (Franche Comté)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 391
    Points : 3 311
    Points
    3 311
    Par défaut
    Citation Envoyé par Hardwarista Voir le message
    2) Le C++ oriente objet, c'est a dire
    A. le polymorphisme a l'execution (heritage,fontions virtuelles)
    - utile mais plein d'ambiguites dans la norme
    [...]
    B. l'encapsulation grace a public/prive/protege
    - utile mais ambigu aussi. Tous les cas de figure ne sont pas utilises.
    Tu as des exemples d'ambiguités ? Je ne vais pas mettre ma main à couper qu'il n'y en a pas, mais de la à dire "plein"

    De même pour les "cas de figure non utiles", tu penses à quoi en particulier ? Je suis bien d'accord que certaines choses n'arrive pas si on se borne à l'orienté objet, mais ils peuvent servirent dans d'autre situation.

    Citation Envoyé par Hardwarista Voir le message
    => L'oriente objet est actuellement, a mon avis, sur-represente dans les cours pour debutants. C'est la partie du standard a reecrire a mon avis.
    A défaut d'être sur-représenté, je pense surtout qu'il est mal enseigné et que les autres paradigmes sont sous-représenté.

    Citation Envoyé par Hardwarista Voir le message
    3) La metaprogramation templates - ou polymorphisme a la compilation
    - tres utile et en train d'evoluer rapidement.
    - mal ficele: oblige d'exposer le code dans les _tpl.h
    => sous-represente dans les cours debutants
    Et pour cause ca conflicte pas mal avec l'oriente objet.
    Je ne vois pas ce qui "conflicte" avec l'OO, ce sont des systèmes orthogonaux, ca amène bien le besoin de certaines syntaxes, mais pas de réel conflit, AMA.

    Pour l'obligation d'exposition, la séparation interface/implémentation était possible dans le précédent standard (export), sauf qu'aucun compilateur (ou presque : EDG) ne l'implémentait. Cette feature a été retiré pour deux raisons (je détaille pas, cf raport du comité pour les détails) :
    -> Complexe à mettre en oeuvre (plusieurs années de développement)
    -> Peu demandé par les utilisateurs
    (Il y a aussi des problèmes techniques).

    Citation Envoyé par Hardwarista Voir le message
    4) Les directives pre-processeur - indispensable pour faire certaines choses
    => sous-represente dans les cours debutants
    Il y a une espece de tabou la dessus.
    C'est pas qu'il y a un tabou, c'est surtout que ce qui peut n'être fait que par le pré-processeur est négligeable devant le reste, donc, AMA, ca ne doit être enseigné qu'à la fin. Sinon c'est la porte ouverte à voir du code pré-processeur là où de la TMP suiffirait.

  6. #106
    Membre éclairé
    Avatar de Ekleog
    Homme Profil pro
    Étudiant
    Inscrit en
    Janvier 2012
    Messages
    448
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Janvier 2012
    Messages : 448
    Points : 879
    Points
    879
    Par défaut
    Citation Envoyé par Bktero Voir le message
    C'est pas qu'il y a un tabou, c'est surtout que ce qui peut n'être fait que par le pré-processeur est négligeable devant le reste, donc, AMA, ca ne doit être enseigné qu'à la fin. Sinon c'est la porte ouverte à voir du code pré-processeur là où de la TMP suiffirait.
    Avant les variadic templates, c'était quand même un passage quasiment obligé. Non ?

  7. #107
    Membre émérite
    Profil pro
    Inscrit en
    Novembre 2004
    Messages
    2 764
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2004
    Messages : 2 764
    Points : 2 704
    Points
    2 704
    Par défaut
    1. La qualité de l'enseignement du C++

    J'ai appris en autodidacte. Je ne saurais donc dire...
    D'un point de vue bouquins, ce qui manque, en revanche, c'est tout ce qui concerne les performances, les optimisations effectuées par les compilateurs, etc. Ainsi qu'un livre qui décrit exhaustivement le C++, avec toutes les chausse-trappes (il serait sans doute constitué de plusieurs volumes), plutôt qu'une collection de livres de recettes (Meyers, Sutter...).

    2. La gestion bas niveau de la mémoire
    C'est une possibilité, rarement une obligation.

    3. L'absence de mécanisme de protection (garbage collector)
    Quand c'est expliqué clairement (dans un cours ou un bouquin), c'est au final plus clair, je pense. Mais bon, c'est vrai que lorsque on est obligé d'utiliser des classes RAII templatisées, au début, ça ne facilite pas l'apprentissage...

    4. Une syntaxe trop complexe
    Elle devient complexe quand on atteint un certain niveau, et à ce moment là, elle ne devient plus complexe. Sauf quand on est dans de la généricité de bon niveau. Même après quelques années, il existe encore quelques frictions mentales.

    5. Pas assez de fonctionnalités dans le langage de base (IHM)
    Clairement. Notamment sur les strings. Heureusement que C++11 apporte les threads.

    6. Trop d'outils ou de bibliothèques externes
    C'est pas tant leur nombre qui pose problème, mais plutôt quand aucune se détache du lot, que leur doc est merdique, ou que leur intégration n'est pas simple (mettre en place Boost pour un débutant, ce n'est pas une sinécure).

    7. Des abstractions haut niveau trop complexes (template)
    Elles sont complexes parce qu'elles sont de haut niveau. Aucun autre langage ne propose une telle expressivité. De toute façon, on ne se détermine pas sur le choix d'un langage en lisant Alexandrescu...

    8. L'évolution trop lente du langage et le retard qu'il a pris
    Point de vue langage, il est plutôt en avance (même si sur la dérivation de classe, il y a des choses à faire). C'est du côté des bibliothèques que ça traine des pieds...

    9. Le manque de portabilité du C++
    C'est vrai que le recours obligatoire à Boost.FileSystem et, jusqu'à il y a peu, à Boost.Thread, rendait les choses pénibles. Surtout que l'installation de Boost n'est pas des plus aisées pour le débutant. Sans compter les systèmes de build...

    10. Un système de compilation beaucoup trop complexe
    C'est à mon sens le plus gros point noir. Ce n'est pas clair, et peu documenté.
    Et quant on doit faire du multi-plate-formes, rien en vas plus.
    Par ailleurs, je ne pense pas que les enseignements poussent assez sur le sujet : souvent, on a des trucs tout cuits, mais des explications détaillées sur les problèmes posés par les conflits de variables entre .lib/.dll, par exemple, ce n'est pas si facile à trouver.

    11. Les messages d'erreurs incompréhensibles
    On s'y fait... Bien plus facile chez Microsoft, notamment avec les codes d'erreur.
    Dès qu'on utilise les templates, c'est assez l'horreur, il faut bien l'avouer.

    12. Le manque de ressources pour l'apprentissage
    Il y en a pléthore. Mais certains sujets sont en revanche peu documentés. Les flux, l'environnement de compilation/édition de lien, les IDE, le déboguage...

  8. #108
    Membre émérite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2008
    Messages
    832
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Décembre 2008
    Messages : 832
    Points : 2 625
    Points
    2 625
    Par défaut
    Citation Envoyé par Ekleog Voir le message
    Avant les variadic templates, c'était quand même un passage quasiment obligé. Non ?
    Je ne trouve pas.
    Parce que la ou je vois du préprocesseur, c'est pour:
    _ activer/désactiver des options dans un logiciel. Chose qui pourrait être faite via un système de plugin, moyennant une architecture étudiée dans ce sens.
    _ garantir la compatibilité entre divers OS. En fait, souvent garantir la compatibilité avec windows. Les #IFDEF que je vois sous souvent suivis de WIN32...

    L'utilisation des macros, quand à elle, est plutôt anecdotique. Par exemple, elles sont utilisées par wxWidgets pour gérer les évènements. Sauf qu'ils ont enfin laissé tomber ce système pour un basé sur des callbacks.
    Je les utilise dans un projet professionnel également, pour écrire plus vite des classes de wrapper, qui n'ont strictement aucune logique dedans. Et d'ailleurs, elles sont trop limitées pour ce que je voudrais en faire. (J'aurai bien utilisé les variadic template, malheureusement, je dois utiliser VS2008...)

    Ah, si, une autre utilisation des macros, non remplaçable par les variadic templates: pouvoir écrire du code de journalisation, surtout pour le mode debug, grâce aux macros __LINE et __FILE. Très utile ça pour le débogage. Mais pas pour le code métier je pense.

    Autre chose qui nécessite les directives de préproc, les header guard. Ajouter le fameux #ifndef TRUC_H #define TRUC_H #endif dans les header n'est cependant qu'un idiome auquel on ne fait plus attention au bout de 2 mois. (Je me demande d'ailleurs pourquoi les header ne sont pas traités comme ça par défaut mais bon...)

  9. #109
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    Juin 2010
    Messages
    7 113
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : Juin 2010
    Messages : 7 113
    Points : 32 958
    Points
    32 958
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par Freem Voir le message
    Autre chose qui nécessite les directives de préproc, les header guard. Ajouter le fameux #ifndef TRUC_H #define TRUC_H #endif dans les header n'est cependant qu'un idiome auquel on ne fait plus attention au bout de 2 mois. (Je me demande d'ailleurs pourquoi les header ne sont pas traités comme ça par défaut mais bon...)
    Parce qu'on peut vouloir inclure plusieurs fois le même header !
    Et si c'était géré par défaut de cette manière, ça deviendrait impossible.
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  10. #110
    Membre éclairé
    Avatar de Ekleog
    Homme Profil pro
    Étudiant
    Inscrit en
    Janvier 2012
    Messages
    448
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Janvier 2012
    Messages : 448
    Points : 879
    Points
    879
    Par défaut
    Citation Envoyé par Freem Voir le message
    Je ne trouve pas.
    Parce que la ou je vois du préprocesseur, c'est pour:
    _ activer/désactiver des options dans un logiciel. Chose qui pourrait être faite via un système de plugin, moyennant une architecture étudiée dans ce sens.
    Sauf que parfois l'overhead peut être extrèmement couteux. (enfin, ça dépend si on parle de plugin à la compilation ou à l'exécution, mais j'ai plus tendance à appeler modules les plugins à la compilation)

    _ garantir la compatibilité entre divers OS. En fait, souvent garantir la compatibilité avec windows. Les #IFDEF que je vois sous souvent suivis de WIN32...
    Toujours est-il que la compatibilité est toujours importante, quelle que soit l'opinion qu'on se fait du système ciblé et de ses API.

    L'utilisation des macros, quand à elle, est plutôt anecdotique. Par exemple, elles sont utilisées par wxWidgets pour gérer les évènements. Sauf qu'ils ont enfin laissé tomber ce système pour un basé sur des callbacks.
    Je les utilise dans un projet professionnel également, pour écrire plus vite des classes de wrapper, qui n'ont strictement aucune logique dedans. Et d'ailleurs, elles sont trop limitées pour ce que je voudrais en faire. (J'aurai bien utilisé les variadic template, malheureusement, je dois utiliser VS2008...)
    Quand je disais avant les variadic templates, je pensais entre autres a fait de proposer des fonctions variadic templates.
    Exemple : boost.function pré-variadic templates.
    Et, comme tu le dis si bien, les macros sont toujours nécessaires pour faire une partie le boulot sur un compilo sans les variadics, et ces compilateurs existent malheureusement encore ...
    Alors, oui, il y a boost & co. pour nous cacher les macros, mais c'est un des trois langages du c++ (en excluant l'asm, hein -- je ne suis pas sûr que je n'en oublie pas d'autre), chacun influant sur son moment de la compilation / de l'exécution.

    Ah, si, une autre utilisation des macros, non remplaçable par les variadic templates: pouvoir écrire du code de journalisation, surtout pour le mode debug, grâce aux macros __LINE et __FILE. Très utile ça pour le débogage. Mais pas pour le code métier je pense.
    M'est avis que le code métier a quand même des macros avec, désactivés avec l'activation de NDEBUG.

    Autre chose qui nécessite les directives de préproc, les header guard. Ajouter le fameux #ifndef TRUC_H #define TRUC_H #endif dans les header n'est cependant qu'un idiome auquel on ne fait plus attention au bout de 2 mois. (Je me demande d'ailleurs pourquoi les header ne sont pas traités comme ça par défaut mais bon...)
    Parce que sinon beaucoup d'autres idiomes disparaitraient ?
    Exemple, boost.pp.iterate_file (ou quelque chose du genre).

  11. #111
    Membre émérite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2008
    Messages
    832
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Décembre 2008
    Messages : 832
    Points : 2 625
    Points
    2 625
    Par défaut
    Citation Envoyé par Ekleog Voir le message
    Sauf que parfois l'overhead peut être extrèmement couteux. (enfin, ça dépend si on parle de plugin à la compilation ou à l'exécution, mais j'ai plus tendance à appeler modules les plugins à la compilation)
    Je pense qu'on ne charge la factory qu'une seule fois, non? Mais je peux me tromper très facilement, mon expérience des plug-in étant plus qu'anecdotique.
    Citation Envoyé par Ekleog Voir le message
    Toujours est-il que la compatibilité est toujours importante, quelle que soit l'opinion qu'on se fait du système ciblé et de ses API.
    Elle reste importante... C'est selon les gens, malheureusement.
    Pour moi, c'est un fait (je m'estime libriste, et j'estime que choisir son OS est aussi une liberté fondamentale, qu'il me plaise ou pas. Pour ça que je m'obstine à faire du code portable au maximum d'ailleurs.). Les API windows ne me gênent pas en soit, ce qui me gêne, c'est une certaine difficulté que j'ai éprouvée à plusieurs reprises entre elles et du code plus standard. Mais bon, ça reste la principale cible des développements, alors il faut faire avec.
    Citation Envoyé par Ekleog Voir le message
    Quand je disais avant les variadic templates, je pensais entre autres a fait de proposer des fonctions variadic templates.
    Exemple : boost.function pré-variadic templates.
    Et, comme tu le dis si bien, les macros sont toujours nécessaires pour faire une partie le boulot sur un compilo sans les variadics, et ces compilateurs existent malheureusement encore ...
    Alors, oui, il y a boost & co. pour nous cacher les macros, mais c'est un des trois langages du c++ (en excluant l'asm, hein -- je ne suis pas sûr que je n'en oublie pas d'autre), chacun influant sur son moment de la compilation / de l'exécution.
    Je suis d'accord que c'est l'une des 3 phases de la génération de code. Mais je pense qu'il s'agit de celle qui est la moins puissante. Du moins, je le pensais avant de lire la suite de ton message (partie relative à boost_pp_iterate).
    Citation Envoyé par Ekleog Voir le message
    M'est avis que le code métier a quand même des macros avec, désactivés avec l'activation de NDEBUG.
    J'avais effectivement oublié ce flag.
    Effectivement, dès lors que l'on utilise assert, par exemple, le code est modifié. Mais peut-on vraiment considérer qu'il s'agisse du code métier? J'ai cette tendance à considérer que le code de débogage ne fait pas partie du code métier et qu'il ne devrais pas avoir d'influence sur celui-ci. Mais je peux me tromper, je suis loin d'être un dev très expérimenté (à mon grand regret).
    D'ailleurs, j'ai l'impression que tu n'as pas cité ce flag que pour la fonction assert. Tu lui connais une autre utilité? Peut-être changer un format de données au débug pour le rendre plus lisible (mais moins efficace)? Même dans ce dernier cas, j'ai du mal à relier ce point à du code métier...
    Citation Envoyé par Ekleog Voir le message
    Parce que sinon beaucoup d'autres idiomes disparaitraient ?
    Exemple, boost.pp.iterate_file (ou quelque chose du genre).
    Qu'est-ce? Avoir lu http://www.boost.org/doc/libs/1_49_0...f/iterate.html me fait supposer qu'il s'agit d'une technique pour faire des boucles avec le pré processeur? Si c'est le cas, cela peut effectivement être très utile, mea culpa de ne pas connaître.

  12. #112
    Membre à l'essai
    Profil pro
    Inscrit en
    Janvier 2009
    Messages
    10
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2009
    Messages : 10
    Points : 12
    Points
    12
    Par défaut
    Citation Envoyé par Freem Voir le message
    Pour ce qui est de la portabilité du système de build, je ne vois pas trop... tu parles des options du compilateur?
    Si c'est le cas, alors je te rejoins, je ne crois pas que la norme impose les options de compilation. En même temps, elle ne pourrait pas imposer grand chose, puisque son rôle est de s'assurer que chaque architecture puisse avoir son implémentation, sans être bridée. Ce qui implique de pouvoir ajouter des options pour utiliser les optimisations particulières de cette architecture.
    Tiens, maintenant que j'y pense... Il serait très bien possible de créer un compilateur C++ qui génère du bytecode java. Si ça n'existe pas, c'est sûrement parce que les dev C++ n'apprécient pas nécessairement l'idée des machines virtuelles...
    Mais c'est possible. D'ailleurs, C++ l'a fait pour .NET (C++/CLI il me semble).
    Je parle surtout du fonctionnement du make: les dependances entre .h et .cpp, entre objets et librairies statiques et librairies dynamiques, l'export de symboles depuis une librairie etc. Ces choses la sont traitees de maniere tres similaire par toutes les plateformes - sans exclure le fait qu'il y a des optimisations specifiques. C'est pour ca que CMake ou scons existent d'ailleurs. Est-ce que la norme en parle ? Je suppose que non parce que les objets et librairies produits ne sont pas censes etre transferables. Mais le savoir-faire du developpeur si ! D'ailleurs si la norme en parlait les cours de C++ en parleraient aussi.

    Oui, j'aime bien ton idee d'une machine virtuelle qui re-assemblerait le code machine en fonction de la plateforme. Comme ca tout ce que j'ecris pour la machine virtuelle prend plus de valeur.

    Citation Envoyé par Freem Voir le message
    A priori, tu as utilisé visual 2003 en dernier. Sache qu'avec visual studio, le respect du standard est franchement douteux (je pense que ça s'améliore, mais tout le monde connaît, je pense, l'amour de microsoft pour le respect des standards dans les années 90/début 2000). Par exemple, stdint.h, il ne connaît pas, c'est pourtant enfantin à implémenter (juste une suite de #define bon sang!) et présent dans le standard de 99!
    Autre chose, du vécu que j'ai eu avec d'anciennes versions de VS: du code qui compilait sur 2003 ne compilait plus sur 2005. Parce que l'auteur de cette immondice avait utilisé des extensions propriétaires de ms qui ont été retirées ensuite. Génial...
    Je n'ai utilise que VS2005. Je compatis.

    Citation Envoyé par Freem Voir le message
    Pour les template, ils fonctionnent pareil sur tous les compilateurs qui respectent la norme. Par contre, ce qui est sûr, c'est que les messages d'erreur quand on les utilise sont assez prise de tête.
    Et naturellement, ça change selon le compilateur, ainsi que les warning. Peut-être qu'effectivement, il serait possible de normaliser les messages d'erreurs et warning, mais je soupçonne que ça n'est pas le cas pour éviter d'avoir à maintenir une panoplie de messages d'erreurs. Mais ça n'a rien a voir avec la portabilité. Du code sans erreur ni warning aura les mêmes messages d'erreurs et warning sur n'importe quel compilo standard. (et pour cause: il n'en aura pas ).
    Mm certes. Mais le fait est que la meme cause d'erreur donne 3 messages differents sur 3 plateformes differentes. Le connexions neuronales perdues a faire le rapprochement moi je dis c'est rageant.

    Et puis les templates c'est pas magique: les classes c++ sont instanciees pour chacune des valeurs de parametre de template. Et c'est le meme combat pour les #define. Pour quoi ne pas me montrer dans un fichier temporaire le code effectifvement genere ?! Et le TMP c'est comme du langage interprete, donc ca devrait etre deboguable comme du langage interprete.

    Citation Envoyé par Freem Voir le message
    Au niveau des reproches que tu fais au C++, je vais me permettre d'en corriger un.

    En fait, quand on utilise l'orienté objet, on casse la compatibilité binaire avec n'importe quel autre compilateur ou, voire même théoriquement avec des options de compilations différentes sur le même compilateur.
    Ceci, parce que dans un souci d'optimisation ils ont lâché la bride sur l'implémentation. C'est une des forces du C++, mais qui a un revers de médaille.
    Cela dis... quand on veut écrire des systèmes de plug-in, on passe par le paradigme du C, vu qu'on est en C++ on peut jongler entre les paradigmes, et c'est la une des plus grosses forces de ce langage.
    Je ne sais pas si c'est un probleme insoluble de merger deux versions d'un dll tout en faisant un mapping des symboles C++. Je ne sais pas non plus s'il y a des langages qui le font. En tout cas ca manque. Et je ne vois pas de raison de faire un compromis sur la performance.

    Citation Envoyé par Freem Voir le message
    Et pour clôturer: j'aimerai que tu m'indiques en quoi la méta programmation est en conflit avec l'objet? J'ai envie de dire que c'est comme si on avait un langage pour que le compilateur génère du code lui même a partir d'un modèle. Modèle qui est lui extrêmement réutilisable, ce qui correspond tout à fait à la philosophie objet.
    Voir la premiere partie de cet article
    http://www.artima.com/cppsource/type_erasure.html

    Puis voir comment Java et C# traitent le probleme.
    http://en.wikipedia.org/wiki/Polymor...c_Polymorphism

    Le souci avec C++ c'est que les templates n'ont pas etes concus pour s'integrer bien avec le concept d'API oriente object. Combien de fois on n'essaie de templatiser une fonction ou une classe, pour eviter de dupliquer du code, et qu'on se retrouve avec une horreur de chaine d'inter-dependances qui ralonge la compilation et oblige a changer les fonctions publiques virtuelles ?

    Le fait qu'il n'est pas possible d'exporter des template est aussi dans la meme ligne.

    Aussi, toutes les classes-template de conteneurs de la STL ne sont pas concues pour etre etendues par heritage. Mais dans ce cas ca devrait s'appeler differement ! De dire "les classes on peut les etendre par heritage" puis "ah non pas celles-la" c'est assez tordu je trouve.

  13. #113
    Membre éclairé
    Avatar de Ekleog
    Homme Profil pro
    Étudiant
    Inscrit en
    Janvier 2012
    Messages
    448
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Janvier 2012
    Messages : 448
    Points : 879
    Points
    879
    Par défaut
    Citation Envoyé par Freem Voir le message
    Je pense qu'on ne charge la factory qu'une seule fois, non? Mais je peux me tromper très facilement, mon expérience des plug-in étant plus qu'anecdotique.
    On ne charge la factory qu'une seule fois, mais pour passer aux plugins il faut rendre virtual toutes les méthodes utilisées (pour avoir unt v-table, corrigez-moi si je me trompe).

    Elle reste importante... C'est selon les gens, malheureusement.
    Pour moi, c'est un fait (je m'estime libriste, et j'estime que choisir son OS est aussi une liberté fondamentale, qu'il me plaise ou pas. Pour ça que je m'obstine à faire du code portable au maximum d'ailleurs.). Les API windows ne me gênent pas en soit, ce qui me gêne, c'est une certaine difficulté que j'ai éprouvée à plusieurs reprises entre elles et du code plus standard. Mais bon, ça reste la principale cible des développements, alors il faut faire avec.
    Surtout quand il y a un standard (POSIX) ... Mais ici n'est pas le sujet.

    [...]

    J'avais effectivement oublié ce flag.
    Effectivement, dès lors que l'on utilise assert, par exemple, le code est modifié. Mais peut-on vraiment considérer qu'il s'agisse du code métier? J'ai cette tendance à considérer que le code de débogage ne fait pas partie du code métier et qu'il ne devrais pas avoir d'influence sur celui-ci. Mais je peux me tromper, je suis loin d'être un dev très expérimenté (à mon grand regret).
    D'ailleurs, j'ai l'impression que tu n'as pas cité ce flag que pour la fonction assert. Tu lui connais une autre utilité? Peut-être changer un format de données au débug pour le rendre plus lisible (mais moins efficace)? Même dans ce dernier cas, j'ai du mal à relier ce point à du code métier...
    L'exemple même que tu donne fait intervenir le préprocesseur :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
       std::unique_ptr<Serializer> serializer
    #ifndef NDEBUG // Debug active
       {new SerializePretty()};
    #else
       {new SerializeToBinary()};
    #endif
    Un autre exemple :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    #ifndef NDEBUG
       void debug_only_function();
    #endif
    Ici, on gagne sur la taille de l'exécutable, et on s'assure que les fonctions réservées au debug (qui pourraient peut-être contenir des failles de sécurité) ne sont utilisées nulle part lors de la compilation release.

    Qu'est-ce? Avoir lu http://www.boost.org/doc/libs/1_49_0...f/iterate.html me fait supposer qu'il s'agit d'une technique pour faire des boucles avec le pré processeur? Si c'est le cas, cela peut effectivement être très utile, mea culpa de ne pas connaître.
    Boost.preprocessor est un ensemble d'utilitaires pour le préprocesseur. (Attention à ne pas regarder le code source, c'est particulièrement horrible -- vive le DRY !)
    Iterate permet d'inclure un fichier N fois, avec un compteur en bonus.
    Il y a aussi du BOOST_PP_REPEAT, qui n'inclut pas un fichier mais répète l'expansion d'une macro.

    Et caetera.

    Non, le préprocesseur est àmha aussi utile que les templates (il est possible de faire avec tout ce que font les templates je crois, mais ce serait plus verbeux). C'est simplement qu'il est *clairement* plus complexe, et nécessite une bonne bibliothèque.

  14. #114
    Membre éclairé
    Avatar de Ekleog
    Homme Profil pro
    Étudiant
    Inscrit en
    Janvier 2012
    Messages
    448
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Janvier 2012
    Messages : 448
    Points : 879
    Points
    879
    Par défaut
    Citation Envoyé par Hardwarista Voir le message
    [...]
    Oui, j'aime bien ton idee d'une machine virtuelle qui re-assemblerait le code machine en fonction de la plateforme. Comme ca tout ce que j'ecris pour la machine virtuelle prend plus de valeur.
    LLVM est à peu près ça. D'ailleurs, son nom le prouve : Low Level Virtual Machine.
    Mais l'avantage du c++ est justement qu'on a le choix de compiler ou interpréter ou JIT-er son code !

    [...]
    Et puis les templates c'est pas magique: les classes c++ sont instanciees pour chacune des valeurs de parametre de template. Et c'est le meme combat pour les #define. Pour quoi ne pas me montrer dans un fichier temporaire le code effectifvement genere ?! Et le TMP c'est comme du langage interprete, donc ca devrait etre deboguable comme du langage interprete.
    g++ -save-temps

    Le souci avec C++ c'est que les templates n'ont pas etes concus pour s'integrer bien avec le concept d'API oriente object. Combien de fois on n'essaie de templatiser une fonction ou une classe, pour eviter de dupliquer du code, et qu'on se retrouve avec une horreur de chaine d'inter-dependances qui ralonge la compilation et oblige a changer les fonctions publiques virtuelles ?
    0 ?
    Si la classe est bien pensée à l'origine, elle n'aura pas de difficulté à être "templatisée", si elle doit l'être.

    Le fait qu'il n'est pas possible d'exporter des template est aussi dans la meme ligne.
    Un exemple d'utilité de l'export template ?
    L'export template est plus ou moins équivalent à placer le code c++ des templates dans le .o, donc ça avance à quoi ?

    Aussi, toutes les classes-template de conteneurs de la STL ne sont pas concues pour etre etendues par heritage. Mais dans ce cas ca devrait s'appeler differement ! De dire "les classes on peut les etendre par heritage" puis "ah non pas celles-la" c'est assez tordu je trouve.
    Tu devrais te renseigner sur les notions de sémantique d'entité / de valeur.
    Rapidement :
    Sémantique d'entité -> non copiable, héritables publiquement
    Sémantique de valeur -> copiable, non héritables publiquement, potentiellement héritage privé

    Les classes de la SL sont conçues pour être à sémantique de valeur, pour la plupart (à part les *stream, si je ne me trompe pas). D'où le fait qu'il faut éviter de les hériter publiquement. L'héritage privé reste toutefois une option, mais la composition reste souvent la meilleur idée.

  15. #115
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par Hardwarista Voir le message
    Aussi, toutes les classes-template de conteneurs de la STL ne sont pas concues pour etre etendues par heritage. Mais dans ce cas ca devrait s'appeler differement ! De dire "les classes on peut les etendre par heritage" puis "ah non pas celles-la" c'est assez tordu je trouve.
    Non, il est tout à fait normal qu'une classe "conteneur" ne soit pas héritable, selon le principe même évoqué par LSP

    Après tout: tu spécialise ton conteneur pour qu'il s'adapte à un type de donnée ou à un autre (sans qu'il n'y ait de rapport entre conteneur<int> et conteneur<string> ), mais tu n'hérite pas d'un conteneur : une liste triée n'a, en vertu de LSP absolument pas à hériter d'une liste (non triée), parce que les pré / post conditions / invariants sont différents (tout comme carré n'a absolument pas à hériter de rectangle malgré le fait que, du point de vue des mathématiques, un carré n'est jamais qu'une "rectangle particulier" )

    J'ai presque envie de dire que ta réaction met, encore une fois, en évidence une lacune au niveau de la conception elle-même : le fait qu'une classe puisse avoir une interface identique à une autre n'est jamais qu'un indice (parmis d'autres!!! ) du fait qu'il est peut etre possible (mais loin d'être systématique !!!) d'envisager une relation d'héritage ou l'intégration dans une hiérarchie commune, mais, et c'est là que pose le problème, l'héritage implique qu'il doit etre sémantiquement cohérent d'estimer qu'un objet de la classe fille est bel et bien un objet de la classe parent, et que les pré / post conditions / invariants sont respectés dans les différents sens

    Finalement, je ne suis pas loin de penser que ce qui manque peut etre dans l'enseignement (pas seulement de C++ ) , c'est une approche de la programmation par contrat, durant laquelle on insisterait sur le corrollaire aux pré / post conditions / invariants : le principe de substitution de liskov
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  16. #116
    En attente de confirmation mail

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2004
    Messages
    1 391
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Doubs (Franche Comté)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 391
    Points : 3 311
    Points
    3 311
    Par défaut
    Pour ce qui concerne la méta-prog pré-processeur et template, le sujet étant : "Le C++, un langage orienté débutant". Je pense que ca ne fait pas partie des choses qui devraient être enseigné. Il y a déjà suffisament à apprendre avec :
    -> Impérative
    -> Objet (je rajouterais bien une approche contrat avec)
    -> Générique

    @Ekleog: Non, pas obligé d'utilisé le pré-processeur pour simuler des variadic. L'utilisation du pré-processeur dans la simulation des variadics n'est qu'"user-friendly", c'est pas fondamentale.

    @oodini:
    1/ Si tu veux discuter des compilateurs, alors il faut te tourner vers les ouvrages de référence dans le genre : Dragon Book. Si tu veux plus précis sur certains compilateurs, alors ce sont vers des ouvrages dédié à eux qu'il faut aller (là j'en connais pas).

    Les livres de Sutter/Meyers font livre de recette ? C'est normal, c'est l'objectif voulu : donner un ensemble de conseils pour programmer en C++. Je pense que les livres de BS ne font pas cet effet, et les livres sur des sujets plus spécifique n'ont pas cet effet non plus.

    2/ Pour boost :
    -> La grande majorité est header-only, plus simple à installer c'est dur
    -> Sur tout les systèmes Unix, il se trouve souvent dans les dépots officiels et est accessible via le gestionnaire de paquet
    -> Sur Windows, si tu utilises les outils de Microsoft, alors il existe un installateur Windows classique qui fait l'installation
    -> Dans les autres cas, quand on utilise des outils venant du monde Unix et adaptés ensuite pour Windows, ca ne m'étonne pas que ce soit (un peu) moins simple que dans les autres cas

    @Hardwarista: Je connais pas cet article (par contre le type-erasure je connais), je vais le regarder pour voir.

  17. #117
    En attente de confirmation mail

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2004
    Messages
    1 391
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Doubs (Franche Comté)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 391
    Points : 3 311
    Points
    3 311
    Par défaut
    @Hardwarista: J'ai lu l'article que tu cites (le premier), et je ne suis pas d'accord avec sa vision des choses. Il dit qu'il change les détails internes sans changer l'interface et qu'au final ca impact l'utilisation. Cependant, pour moi, la catégorie des itérateurs retourné fait clairement partie de l'interface (plus exactement du contrat de la classe). Ainsi si tu ne peux plus assurer le contrat en changer les détails internes, c'est de ta faute.

    Par exemple, il dit qu'un code comme it_end - it_begin; ne compilera plus après changement de std::vector vers std::list en interne. C'est vrai, sauf que si dans le contrat de ma classe j'ai spécifié : input_iterator, l'utilisateur n'aurait jamais du écrire it_end - it_begin. Et en effet la complexité passera de constant en linéaire, sauf qu'à nouveau si j'ai indiqué input_iterator dans le contrat de ma classe, l'utilisateur n'avait pas à attendre mieux que linéaire.

    Edit: Cependant son article met en exergue la cohabitation des deux paradigmes : c'est la mise en oeuvre de contrats clair (pour les classes et les fonctions) qui permet le bon fonctionnement du monde générique. Dans les exemples de l'auteur, il n'y a pas de contrat : ca marche mal, dans la S(T)L, tout les contrats sont clairs : ca fonctionne.

  18. #118
    Membre émérite
    Profil pro
    Inscrit en
    Novembre 2004
    Messages
    2 764
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2004
    Messages : 2 764
    Points : 2 704
    Points
    2 704
    Par défaut
    Citation Envoyé par Flob90 Voir le message
    1/ Si tu veux discuter des compilateurs, alors il faut te tourner vers les ouvrages de référence dans le genre : Dragon Book.
    Non non : je parlais de l'environnement de la chaîne de compilation/édition de liens. En général, dans les cours de C, c'est bien couvert, mais étrangement, pas dans ceux du C++.

    Citation Envoyé par Flob90 Voir le message
    Les livres de Sutter/Meyers font livre de recette ? C'est normal, c'est l'objectif voulu : donner un ensemble de conseils pour programmer en C++.
    Oui, mais certains de ces conseils devraient être directement données dans les cours initiaux.

    Citation Envoyé par Flob90 Voir le message
    Je pense que les livres de BS ne font pas cet effet, et les livres sur des sujets plus spécifique n'ont pas cet effet non plus.
    Je ne connais que son livre de référence, et franchement, il faut déjà connaître C++ pour pouvoir le lire, notamment les premiers chapitres.


    Citation Envoyé par Flob90 Voir le message
    2/ Pour boost :
    -> La grande majorité est header-only, plus simple à installer c'est dur
    -> Sur Windows, si tu utilises les outils de Microsoft, alors il existe un installateur Windows classique qui fait l'installation
    Moi, ma première utilisation de Boost (version 1.33, je crois), c'était pour Boost.Thread. Et l'installateur pour Visual est toujours à la bourre par rapport aux numéros de version. On doit donc se taper du Boost.Build ou bootstrap, depuis quelques temps. Et je persiste à dire que pour un débutant, ce n'est pas l'idéal. Il s'agit d'ailleurs d'aller voir sur ce même forum, dans la section Boost, les appels à l'aide pour l'installation...

  19. #119
    En attente de confirmation mail

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2004
    Messages
    1 391
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Doubs (Franche Comté)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 391
    Points : 3 311
    Points
    3 311
    Par défaut
    Citation Envoyé par oodini Voir le message
    Non non : je parlais de l'environnement de la chaîne de compilation/édition de liens. En général, dans les cours de C, c'est bien couvert, mais étrangement, pas dans ceux du C++
    D'accord, c'est peut être lié à un reste de l'approche historique C -> C++ qui veut qu'on ai vu le C (au moins un peu) avant le C++.

    Citation Envoyé par oodini Voir le message
    Oui, mais certains de ces conseils devraient être directement données dans les cours initiaux.
    Alors je suis bien d'accord

    Citation Envoyé par oodini Voir le message
    Moi, ma première utilisation de Boost (version 1.33, je crois), c'était pour Boost.Thread. Et l'installateur pour Visual est toujours à la bourre par rapport aux numéros de version. On doit donc se taper du Boost.Build ou bootstrap, depuis quelques temps. Et je persiste à dire que pour un débutant, ce n'est pas l'idéal. Il s'agit d'ailleurs d'aller voir sur ce même forum, dans la section Boost, les appels à l'aide pour l'installation...
    L'installateur est en retard d'une ou deux version, c'est pas non plus catastrophique comme retard. Et sur le forum, la majorité des demandes d'aide porte sur l'installation de boost pour MinGW sous Windows (ie ma 4° -> dans mon message précédent). La petite difficulté en plus dans ce cas est qu'il faut recompiler avec b2 (et que pour les gens qui débutent et ne connaise que Windows, c'est pas une procédure courante), un peu plus difficile mais pas insurmontable (*).

    (*) D'ailleurs cette difficulté est peut-être lié à ce que tu soulèves comme premier point : une mauvaise connaisance de la chaine de compilation et des outils associés.

  20. #120
    Membre émérite
    Profil pro
    Inscrit en
    Novembre 2004
    Messages
    2 764
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2004
    Messages : 2 764
    Points : 2 704
    Points
    2 704
    Par défaut
    Citation Envoyé par Flob90 Voir le message
    L'installateur est en retard d'une ou deux version, c'est pas non plus catastrophique comme retard.
    Cela dépend de la bibliothèque utilisée. A l'époque, Boost.Thread était assez dynamique, et on a par la suite bossé sur Boost.GIL. Il nous fallait donc les dernières versions. Autant te dire que l'installateur de Visual, je ne l'ai jamais utilisé.

    Citation Envoyé par Flob90 Voir le message
    Et sur le forum, la majorité des demandes d'aide porte sur l'installation de boost pour MinGW sous Windows (ie ma 4° -> dans mon message précédent). La petite difficulté en plus dans ce cas est qu'il faut recompiler, un peu plus difficile mais pas insurmontable (*).
    Je n'ai pas dit que c'était insurmontable. Mais comme on parlait de ce qui est susceptible de décourager les débutants, faire mention de ce point ne me paraît pas incongru.
    Quelqu'un qui vient de Python et qui est habitué à développer sur du multi-plate-formes, et qui pour des problèmes de performances doit se mettre à C++, il est tout de même susceptible d'avoir à se taper l'installation de Boost.Thread, de se faire des scritpts Scons (ou Boost.Build !), de savoir configurer Eclipse CDT avec gdb, etc...
    Par rapport à du Java, tu avoueras que c'est un plus la galère.

    (*) D'ailleurs cette difficulté est peut-être lié à ce que tu soulèves comme premier point : une mauvaise connaisance de la chaine de compilation et des outils associés.[/QUOTE]

Discussions similaires

  1. langage orienté gestion
    Par disneb dans le forum Langages de programmation
    Réponses: 3
    Dernier message: 06/04/2008, 01h06
  2. régles de passage d'un diagramme de classe à un langage orienté objet
    Par lasmarmann dans le forum Diagrammes de Classes
    Réponses: 7
    Dernier message: 22/01/2007, 19h16
  3. [langage C][débutant] un vaisseau qui tire
    Par shinkyo dans le forum GLUT
    Réponses: 12
    Dernier message: 10/06/2006, 16h39
  4. VBA est-il un langage orienté objet ?
    Par Kcirtap dans le forum Général VBA
    Réponses: 5
    Dernier message: 06/12/2005, 10h46
  5. [web] [Que choisir ?] langages orientés web.
    Par otakuMerlin dans le forum Web
    Réponses: 4
    Dernier message: 07/04/2003, 12h13

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo