Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 04/04/2010, à 15:36

Le Farfadet Spatial

Une autre approche du C++ standard

Salut à tous !

   J'en ai déjà parlé de-ci, de-là : au vu de la trop grande tendance des livres et des tutoriels visant à présenter C++ à enseigner en réalité un sabir C with classes, j'ai commencé à rassembler des notes pour essayer de proposer une approche de C++ qui soit, autant que possible, plus conforme avec le standard. J'en profite également pour opter pour une approche qui change un peu de celle présentée en général.

   Bon, c'est un énorme travail, qui ne sera pas fini de sitôt. Cela dit, je prends en compte le conseil de Linus TORVALDS : « publiez tôt ». J'ai donc déposé une version très préliminaire de ce travail, que vous trouverez à l'adresse suivante :

[edit]
   Le document est désormais géré via Darcs, voici l'adresse du dépôt :

http://le-bars.net/yoann/repos/livre-C++/

   Pour se contenter de lire le PDF, télécharger le fichier suivant :

http://le-bars.net/yoann/repos/livre-C++/livre-C++.pdf
[/edit]

   Je n'en suis encore vraiment qu'à une première ébauche très incomplète, différents points sont encore remplis de manière un peu aléatoire, il manque également des explications des algorithmes avec des schémas. À l'inverse, on pourra s'étonner que la préface est déjà rédigée (encore qu'elle ne soit pas finie elle non-plus), mais il me semblait important d'indiquer où je voulais en venir dès le départ. Cela dit, il est déjà possible de discuter de l'approche.

   Je mettrais de nouvelles versions en ligne de temps à autre, de manière aléatoire, mais je préviendrais.

   N'hésitez pas à faire les retours qui vous sembleront pertinent.

   À bientôt.

   Le Farfadet Spatial

Dernière modification par Le Farfadet Spatial (Le 30/07/2010, à 19:50)

Hors ligne

#2 Le 04/04/2010, à 15:45

helly

Re : Une autre approche du C++ standard

Excellente idée !! smile
C'est toi même qui m'a appris que ce que je pensais être du c++ n'en était pas !!
Ton truc m'interresse , je vais y jetter un oeil wink


Archlinux-wmii-dwb.
Un problème résolu ? Faites le savoir en mettant [résolu] à côté du titre de votre topic.
Un problème non résolu ? Faites le savoir en insultant ceux qui cherchent à vous aider.
Un site bleu super remasterised©, un wiki cherchant des volontaires pour traduire un site.

Hors ligne

#3 Le 04/04/2010, à 15:52

Michel Leunen

Re : Une autre approche du C++ standard

Le Farfadet Spatial a écrit :

J'en ai déjà parlé de-ci, de-là : au vu de la trop grande tendance des livres et des tutoriels visant à présenter C++ à enseigner en réalité un sabir C with classes

Oui et le premier programme que tu présentes il y a:

int main ( void ) {

En C++, on ne met pas void dans les paramètres de la fonction même si c'est main.
C'est en C qu'on écrit cela.


Michel Leunen
http://linux.leunen.com

Hors ligne

#4 Le 04/04/2010, à 16:16

Le Farfadet Spatial

Re : Une autre approche du C++ standard

Salut à tous !

Michel Leunen a écrit :

En C++, on ne met pas void dans les paramètres de la fonction même si c'est main.

D'une part, je ne me souviens pas dans la norme actuelle d'avoir vu quelque chose qui aille dans le sens de ce que tu dis. J'ai peut-être mal lu.

   D'autre part, avec l'arrivée de C++ 1x, en C++, selon que l'on mettra « void » ou non, on aura soit à utiliser « () », soit rien :

void f (void) {}
f();

Ou bien :

void  f () {}
f;

Du coup, en mettant « void », on s'assure qu'avec la nouvelle norme le fonctionnement sera le même qu'avec l'ancienne.

   Bien sûr, je peux me tromper, mais c'est là la raison pour laquelle j'ai procédé ainsi.

   À bientôt.

   Le Farfadet Spatial

Hors ligne

#5 Le 04/04/2010, à 17:08

Michel Leunen

Re : Une autre approche du C++ standard

Je n'ai pas dit qu'il était interdit de mettre void dans la parameters list d'une fonction sans paramètre. L'usage veut qu'on ne le mette pas en C++ simplement parce que void n'est pas un paramètre et que pour rester cohérent, il vaut mieux ne pas le mettre.
En plus, si C++ autorise à mettre void dans une fonction sans paramètre, c'est pour rester compatible avec le C.
Dans la norme:

The parameter list (void) is equivalent to the empty parameter list.
This special case is intended for C compatibility,...


Michel Leunen
http://linux.leunen.com

Hors ligne

#6 Le 04/04/2010, à 17:25

Link31

Re : Une autre approche du C++ standard

Eh bien, c'est une excellente idée, bien que très ambitieuse vu la taille du document... En tout cas, ça fait plaisir de voir un cours de C++ qui démarre dans la bonne direction.

Cependant :

Au sujet du (void) dans la liste des paramètres, personnellement ça ne me plaît pas vraiment... C'est clairement un reliquat du C, où comme tu le sais certainement les fonctions avec une liste de paramètres vide acceptent n'importe quel nombre d'arguments, et les fonctions avec (void) n'en acceptent pas. En C++, cela n'a plus de raison d'être, et c'est même une une entorse à la syntaxe du langage, qui n'est là que pour la compatibilité avec le C.
Par contre, je n'étais pas au courant de ce fonctionnement en C++-?x dont tu parles. Si tu pouvais citer le document exact où cela est spécifié, ça m'intéresserait beaucoup.

D'un point de vue esthétique et de lisibilité, je te conseillerais aussi de changer la police de caractères que tu utilises pour les exemples de code. Celle-ci est vraiment mal proportionnée, les " et les ' sont trop similaires, elle supporte mal le copier-coller (les |_| ne sont pas forcément là pour aider)... Personnellement, je te propose d'utiliser le package listings avec la police DejaVu Sans Mono ou une police proche.

Enfin, je trouve que l'index en fin de document qui référence les "if", "==", et autres "namespace" a peu d'intérêt wink

Hors ligne

#7 Le 04/04/2010, à 18:36

Le Farfadet Spatial

Re : Une autre approche du C++ standard

Salut à tous !

Link31 a écrit :

Eh bien, c'est une excellente idée, bien que très ambitieuse vu la taille du document...

Tu m'étonnes, ça va être un sacré boulot ! Raison pour laquelle j'ai tout intérêt à présenter la version très préliminaire.

En tout cas, ça fait plaisir de voir un cours de C++ qui démarre dans la bonne direction.

Hé bien, merci. D'ailleurs, merci à tous ceux qui veulent bien jeter un œil.

   Concernant le « void », je dois reconnaître que je ne m'attendais pas à ce que l'on vienne titiller là-dessus, surtout parce qu'il y a d'autres partis pris qui me semble plus surprenants.

   Bien sûr, je sais bien que ce n'est pas vraiment l'usage et tout le reste. Cela dit, ça ne change fondamentalement rien dans le code et, surtout, mon idée est d'éviter que, au vu de la réaction de la nouvelle norme que j'ai évoquée, sur d'autres point on vienne d'un coup me dire : « mais, ça ne fonctionne pas ». Du coup, pour rester cohérent partout, j'ai mis « void » dans « main ». Cela dit :

Par contre, je n'étais pas au courant de ce fonctionnement en C++-?x dont tu parles. Si tu pouvais citer le document exact où cela est spécifié, ça m'intéresserait beaucoup.

Justement, je n'ai pas retrouvé dans l'immédiat. Cela dit, je n'ai pas repris l'intégralité des plus de 1300 pages, je le reconnais.

   En tout cas, je ne l'ai pas inventé. Toutefois, j'ai pu mal comprendre quelque chose, ou bien cela a pu être abandonné. Bon, je me donne un jour ou deux pour retrouver, sinon je sors ça du document et on verra bien quand la nouvelle norme sortira.

D'un point de vue esthétique et de lisibilité, je te conseillerais aussi de changer la police de caractères que tu utilises pour les exemples de code. Celle-ci est vraiment mal proportionnée, les " et les ' sont trop similaires, elle supporte mal le copier-coller (les |_| ne sont pas forcément là pour aider)... Personnellement, je te propose d'utiliser le package listings avec la police DejaVu Sans Mono ou une police proche.

Les « |_| », je les garde, parce que même si cela rend le copier-coller un peu plus délicat, cela permet d'éviter les ambiguïtés. Pour le reste, très bien, je vais prendre cela en compte.

Enfin, je trouve que l'index en fin de document qui référence les "if", "==", et autres "namespace" a peu d'intérêt wink

Je ne sais pas, ça peut être utile lorsque l'on recherche une notion. Qu'en pense les autres qui ont regardé le document ?

   À bientôt.

   Le Farfadet Spatial

Hors ligne

#8 Le 04/04/2010, à 18:40

Michel Leunen

Re : Une autre approche du C++ standard

Le Farfadet Spatial a écrit :

Concernant le « void », je dois reconnaître que je ne m'attendais pas à ce que l'on vienne titiller là-dessus, surtout parce qu'il y a d'autres partis pris qui me semble plus surprenants.

C'est parce que je n'ai fait que lire le début wink
Non, ça m'a frappé parce que tu disais que les autres bouquins parlaient du C++ en faisant référence au C et que tu voulais faire autrement. Et le premier bout de code que tu donnes fait clairement référence au C avec ce void dans la liste des paramètres.


Michel Leunen
http://linux.leunen.com

Hors ligne

#9 Le 04/04/2010, à 18:43

Le Farfadet Spatial

Re : Une autre approche du C++ standard

Salut à tous !

Michel Leunen a écrit :

C'est parce que je n'ai fait que lire le début wink

Lis la suite, il y a des chances que tu sois surpris !

   Cela dit, tu peux également ne pas avoir le temps.

Et le premier bout de code que tu donnes fait clairement référence au C avec ce void dans la liste des paramètres.

Non, ce n'est pas une référence au C, encore une fois c'est dû à cette évolution que j'ai (peut être par erreur) vu venir dans C++.

   À bientôt.

   Le Farfadet Spatial

Hors ligne

#10 Le 04/04/2010, à 19:08

eiger

Re : Une autre approche du C++ standard

Bonsoir,

Bon courage pour ce travail qui risque d'être long !

J'ai commencé à lire ton document, et j'aurais une remarque : je ne suis pas persuadé qu'aborder la taille du type "int" dès le premier exemple soit forcément une bonne idée. D'autant plus qu'un "int" n'est pas nécessairement codé sur 64 bits sur une machine 64 bits. La plupart des systèmes dérivés d'Unix utilisent le modèle LP64, dans lequel les int restent sur 32 bits.

Concernant l'histoire des fonctions sans paramètres appelées sans parenthèses, je serais également intéressé par la référence. J'avoue que ça me surprend beaucoup.

Hors ligne

#11 Le 04/04/2010, à 19:22

Le Farfadet Spatial

Re : Une autre approche du C++ standard

Salut à tous !

eiger a écrit :

J'ai commencé à lire ton document, et j'aurais une remarque : je ne suis pas persuadé qu'aborder la taille du type "int" dès le premier exemple soit forcément une bonne idée. D'autant plus qu'un "int" n'est pas nécessairement codé sur 64 bits sur une machine 64 bits. La plupart des systèmes dérivés d'Unix utilisent le modèle LP64, dans lequel les int restent sur 32 bits.

Oui, tout à fait.

   C'est un problème pour moi : j'hésite encore sur la bonne façon de présenter les entiers, en réalité tous les types. Il me semble important de bien passer le message que tous les types ont des limites et que leurs représentations changent d'un système à l'autre. Pour l'instant, j'ai choisi cette présentation là, mais je n'y suis pas cramponné et conscient de ses limites : par exemple, toi, quelle présentation ferais-tu ?

Concernant l'histoire des fonctions sans paramètres appelées sans parenthèses, je serais également intéressé par la référence. J'avoue que ça me surprend beaucoup.

Oui, je cherche, mais ça reste difficile de chercher rapidement de tels détails dans le brouillon de nouvelle norme.

   Bon, en tout cas, il semble que, finalement, opter d'abord pour une approche fonctionnelle et retarder fortement la présentation des boucles et des variables ne surprend personne. Hé bien, tant mieux !

   À bientôt.

   Le Farfadet Spatial

Hors ligne

#12 Le 04/04/2010, à 19:56

Karl_le_rouge

Re : Une autre approche du C++ standard

En l'état, ça me semble un très bon début.

Pour l'histoire du void, Stroustrup et Herb Sutter recommandent de ne rien mettre dans la signature d'une fonction sans paramètres, mais c'est une affaire de goût personnel. Dans la norme, on utilise indifféremment les deux.

Juste une remarque, pour les comparaisons d'égalité, il vaut mieux recommander l'idiome valeur == variable, en cas d'oubli d'un '=', le compilateur signalera l'erreur, ça me semble intéressant pour les débutants.

Une typo page 31
> Exception inattendue

> Oui, je cherche, mais ça reste difficile de chercher rapidement de tels détails dans le brouillon de nouvelle norme.

Faut regarder dans la partie déclarateur (20 à 30 pages), mais il me semble que c'est réservé à la définition de pointeurs de fonction dans certains cas.

Hors ligne

#13 Le 04/04/2010, à 21:14

Link31

Re : Une autre approche du C++ standard

Le Farfadet Spatial a écrit :

Bon, en tout cas, il semble que, finalement, opter d'abord pour une approche fonctionnelle et retarder fortement la présentation des boucles et des variables ne surprend personne. Hé bien, tant mieux !

Hmm, peut-être qu'on n'est pas tous capables d'avoir un avis objectif là-dessus, du moins ceux d'entre nous qui sont déjà développeurs...

Karl_le_rouge a écrit :

Juste une remarque, pour les comparaisons d'égalité, il vaut mieux recommander l'idiome valeur == variable, en cas d'oubli d'un '=', le compilateur signalera l'erreur, ça me semble intéressant pour les débutants.

Les compilateurs dignes de ce nom affichent également un avertissement sur les conditions du type "variable = valeur" (on peut toujours forcer l'affectation avec une paire de parenthèses supplémentaire). Ce n'est pas forcément nécessaire de conseiller une écriture qui va à l'encontre du sens commun.

Hors ligne

#14 Le 04/04/2010, à 22:06

gilbert

Re : Une autre approche du C++ standard

hello,

Je viens de le lire et ce que je peux dire : joli boulot jusqu'à présent :-)

Il y a juste un petit truc sur lequel j'aimerai bien apporter mon retour. Bon d'abord je ne suis pas informaticien, donc je ne vois peut-être pas les choses de la même façon.. enfin c'est donc un regard extérieur.

Cela concerne la récursivité. Bon je sais que pour comprendre la récursivité, il faut d'aboird avoir compris la récursivité lol

Je trouve que l'exemple donné (l'exponentiation de x par un entier) n'est pas forcément le meilleur. En effet, ça peut perturber le lecteur qui se demande quel est le gain par rapport à un simple traitement itératif. En effet, je pense que la récursivité simple ne se justifie pas en programmation, et qu'elle n'a de vrai intérêt que lorsqu'elle est multiple ou mutuelle. La relation de Pascal est à mon avis une bien meilleure illustration de la récursivité.

Sinon une question bête. Pourquoi débranchement conditionnel et non pas branchement ? Le Program Counter se Branche à une nouvelle adresse lors d'un traitement conditionel, il ne se débranche pas.

Bonne continuation.

ah oui et juste... on peut avoir le .tex ? wink


Simplement moi-même..

Hors ligne

#15 Le 04/04/2010, à 22:07

Le Farfadet Spatial

Re : Une autre approche du C++ standard

Salut à tous !

Karl_le_rouge a écrit :

Juste une remarque, pour les comparaisons d'égalité, il vaut mieux recommander l'idiome valeur == variable, en cas d'oubli d'un '=', le compilateur signalera l'erreur, ça me semble intéressant pour les débutants.

Pour le coup, je ne suis pas trop partant : je trouve que ce n'est pas naturel. De plus, au vu de ce qui est déjà rédigé, pour l'instant il n'y a pas de variable, uniquement des constantes, avec lesquelles le problème ne se pose pas. Justement, l'un des messages que je voudrais faire passer, c'est d'utiliser le moins possible de variables.

Karl_le_rouge a écrit :

Une typo page 31
> Exception inattendue

Merci.

Karl_le_rouge a écrit :

Faut regarder dans la partie déclarateur (20 à 30 pages), mais il me semble que c'est réservé à la définition de pointeurs de fonction dans certains cas.

Merci également.

Link31 a écrit :

Hmm, peut-être qu'on n'est pas tous capables d'avoir un avis objectif là-dessus, du moins ceux d'entre nous qui sont déjà développeurs...

Justement, c'est la raison pour laquelle je m'attendais à une forte opposition à ce sujet.

   À bientôt.

   Le Farfadet Spatial

Hors ligne

#16 Le 04/04/2010, à 22:25

Le Farfadet Spatial

Re : Une autre approche du C++ standard

Salut à tous !

gilbert a écrit :

Je trouve que l'exemple donné (l'exponentiation de x par un entier) n'est pas forcément le meilleur. En effet, ça peut perturber le lecteur qui se demande quel est le gain par rapport à un simple traitement itératif. En effet, je pense que la récursivité simple ne se justifie pas en programmation, et qu'elle n'a de vrai intérêt que lorsqu'elle est multiple ou mutuelle. La relation de Pascal est à mon avis une bien meilleure illustration de la récursivité.

La première version de l'exponentiation que je donne est un algorithme en O(n), mais dès la deuxième version, c'est du O(log n) -- oui, je vais l'indiquer dans le texte, en détaillant. Tu ne peux pas obtenir un aussi bon algorithme d'exponentiation en itératif, sauf à dé-récurser l'algorithme que je donne, mais c'est alors peu lisible et ne change fondamentalement rien en termes de performances, d'autant que les compilateurs modernes sont capables de dé-récurser automatiquement.

   Est-ce que tu commences à voir l'intérêt de la récursivité ?

   Parfois, l'approche impérative permet de bons algorithmes, parfois il est préférable d'utiliser une approche récursive. De plus, utiliser l'exponentiation comme modèle va me permettre d'utiliser le même exemple pour la généricité et les spécialisations en fonction du type. Je n'en ai pas fini avec l'exponentiation !

Sinon une question bête. Pourquoi débranchement conditionnel et non pas branchement ? Le Program Counter se Branche à une nouvelle adresse lors d'un traitement conditionel, il ne se débranche pas.

C'est une erreur de ma part. Je corrige.

ah oui et juste... on peut avoir le .tex ? wink

Il y a plusieurs fichiers...

   J'essayerais de créer un serveur Mercurial lorsque j'aurais mis en place ma nouvelle infrastructure de serveurs.

   À bientôt.

   Le Farfadet Spatial

Hors ligne

#17 Le 04/04/2010, à 22:41

gilbert

Re : Une autre approche du C++ standard

Le Farfadet Spatial a écrit :

Salut à tous !

gilbert a écrit :

Je trouve que l'exemple donné (l'exponentiation de x par un entier) n'est pas forcément le meilleur. En effet, ça peut perturber le lecteur qui se demande quel est le gain par rapport à un simple traitement itératif. En effet, je pense que la récursivité simple ne se justifie pas en programmation, et qu'elle n'a de vrai intérêt que lorsqu'elle est multiple ou mutuelle. La relation de Pascal est à mon avis une bien meilleure illustration de la récursivité.

La première version de l'exponentiation que je donne est un algorithme en O(n), mais dès la deuxième version, c'est du O(log n) -- oui, je vais l'indiquer dans le texte, en détaillant.
   Est-ce que tu commences à voir l'intérêt de la récursivité ?

Oui la croissance de l'ordre est bien plus modérée, ça c'est un fait, mais pour les deux, lorsque n tend vers l'infini, l'ordre aussi tend vers l'infini... Or dans certains problèmes de récursivités multiples, on arrive, lorsque n tend vers l'infini, à faire converger l'ordre vers une constante, car la courbe forme une asymptote horizontale à l'infini, et c'est là justement qu'elle prend pleinement son sens par rapport à un traitement itératif qui lui diverge fortement.

Je pars fouiller mes cours, je pense (j'espère vraiment) que je vais retrouver mon petit exemple.


Simplement moi-même..

Hors ligne

#18 Le 04/04/2010, à 23:42

Le Farfadet Spatial

Re : Une autre approche du C++ standard

Salut à tous !

gilbert a écrit :

Oui la croissance de l'ordre est bien plus modérée, ça c'est un fait, mais pour les deux, lorsque n tend vers l'infini, l'ordre aussi tend vers l'infini...

Si on calcule une puissance 40, on passe de l'ordre de 40 cycles à de l'ordre de 5 cycles. C'est tout de même essentiel. Passer d'un algorithme en O(n) à un algorithme O(log n), ce n'est pas du tout anodin, tu ne peux pas dire que ce n'est pas important, ni même que c'est un simple détail.

   Après, on peut parler d'algorithmes étranges, mais je ne pense pas que ce soit une bonne idée lorsque l'on découvre un langage.

   À bientôt.

   Le Farfadet Spatial

Hors ligne

#19 Le 05/04/2010, à 12:10

valAa

Re : Une autre approche du C++ standard

Salut,
typo p.4

En programmation, les bibliothèques consistent en divers éléments qui ont déjà été programmer et qui permettent au développeurs ne pas avoir à refaire ce qui est déjà fait dans ces bibliothèques.

Bon courage pour la suite, tu te lances dans un sacré boulot.

Hors ligne

#20 Le 05/04/2010, à 13:28

gilbert

Re : Une autre approche du C++ standard

Le Farfadet Spatial a écrit :

Salut à tous !

gilbert a écrit :

Oui la croissance de l'ordre est bien plus modérée, ça c'est un fait, mais pour les deux, lorsque n tend vers l'infini, l'ordre aussi tend vers l'infini...

Si on calcule une puissance 40, on passe de l'ordre de 40 cycles à de l'ordre de 5 cycles. C'est tout de même essentiel. Passer d'un algorithme en O(n) à un algorithme O(log n), ce n'est pas du tout anodin, tu ne peux pas dire que ce n'est pas important, ni même que c'est un simple détail.

Tout à fait, je ne dis pas que c'est anodin, je dis simplement qu'on peut faire plus fort encore :-)

J'ai retrouvé mon exemple, il nous a été montré avec MATLAB, mais je ne pense pas qu'il y aie de différence significative avec du c++.

Il n'est pas si différent. Il consiste à calculer a^b où a et b sont des réels. On sait que a^b = exp(ln(a)*b). Si on veut évaluer cette expression, bien entendu sans utiliser cmath, il faut faire la série de taylor de exp(ln(a)*b). On choisit une tolérance, qui est, pour une méthode itérative, la différence, en valeur absolue, entre la valeur calculée au pas k et la valeur vraie de l'expression. Bien entendu, on ne connait pas la vraie valeur, puisqu'on cherche à la calculer.. Une bonne approximation est donc d'utiliser la difflrence, en valeur absolue, entre la valeur au pas k et la valeur au pas k-1.

Pour un a et b un donné, si on restreint toujours plus notre tolérance, l'ordre de croissance d'une méthode itérative va commencer à croître polynomialement, alors qu'avec une méthode récursive va converger.

J'ouvre une parenthèse : ça amène tout de même un petit soucis inhérent au calcul numérique en informatique, cette méthode ne fonctionnera jamais si on choisit une tolérance de 10^-200 si on travaille avec des nombres de l'ordre de 10^200 car l'ensemble des flottants n'est pas dense!

Dans tout ton cours tu associes les variables de type double à des réels. Je pense que là il faut faire très attention. Les doubles ne sont pas des réels mais bien des flottants et ça mérite d'être expliqué dans tout bon cours de programmation.  IF est un ensemble et non un corps comme IR et ils n'ont pas les même propriétés. La commutativité est respectée, mais pas l'associativité ni la distributivité.

essayez un code du genre :

double a=1;
double b=1;
while (a+b != a) {
   b /= 2.0;
}

Avec un tel code, si on travaillait avec des réels, on ne devrait jamais sortir de la boucle, or on finit bien par en sortir. Ce qui prouve qu'on ne travaille pas avec des réels.

Essayez aussi :

double a = 1.6e-19;
std::cout << ( (1+a) - 1) / a << std::endl;

résultat surprenant...

Voilà, ces deux exemples devraient suffire à mettre en garde les programmeurs du risque de travailler avec des doubles.

Et en ce sens, faire attention avec l'écriture mathématique dans le cours. Remplacer les IR par des IF.
Je ferme ma parenthèse :-)

A+

Dernière modification par gilbert (Le 05/04/2010, à 13:32)


Simplement moi-même..

Hors ligne

#21 Le 05/04/2010, à 13:33

Le Farfadet Spatial

Re : Une autre approche du C++ standard

Salut à tous !

valAa a écrit :

typo p.4

En programmation, les bibliothèques consistent en divers éléments qui ont déjà été programmer et qui permettent au développeurs ne pas avoir à refaire ce qui est déjà fait dans ces bibliothèques.

Oups ! Merci.

   À bientôt.

   Le Farfadet Spatial

Hors ligne

#22 Le 05/04/2010, à 13:48

Le Farfadet Spatial

Re : Une autre approche du C++ standard

Salut à tous !

gilbert a écrit :

IF est un ensemble et non un corps comme IR et ils n'ont pas les même propriétés. La commutativité est respectée, mais pas l'associativité ni la distributivité.

Hé bien, si tu t'intéresses aux problèmes de la représentation des nombres réels sur ordinateur, je t'invite à consulter mon mémoire de maîtrise. D'ailleurs, nous avions discuté à l'époque : http://forum.ubuntu-fr.org/viewtopic.ph … 3#p2725463 et quelques messages qui suivent (il y avait aussi celui-ci).

Les doubles ne sont pas des réels mais bien des flottants et ça mérite d'être expliqué dans tout bon cours de programmation.

Quelle est la présentation que tu ferais ?

   Cela dit, l'exemple de l'exponentiation, j'y ai bien réfléchi et il me permet de faire une progression complète depuis les bases jusqu'à la généricité et la méta-programmation, ce n'est pas un exemple choisi au hasard.

   À bientôt.

   Le Farfadet Spatial

Dernière modification par Le Farfadet Spatial (Le 05/04/2010, à 13:55)

Hors ligne

#23 Le 05/04/2010, à 13:56

gilbert

Re : Une autre approche du C++ standard

ahah, drôle wink je ne me rappelais plus de cette conversation... Je vais commencer par lire ton mémoire parce que oui, ça m'intéresse. Après je verrai comment on peut présenter ça.. Il faut faire attention que ça ne soit pas trop mathématique, car je ne pense pas non plus qu'il faille être mathématicien pour apprendre à programmer. Mais il faut néanmoins quelque rigueur pour bien présenter les choses telles qu'elles sont.

ça demande réfléxion.. Je repasserai quand j'aurais quelque chose de pas trop stupide à proposer.

A+


Simplement moi-même..

Hors ligne

#24 Le 05/04/2010, à 14:09

Le Farfadet Spatial

Re : Une autre approche du C++ standard

Salut à tous !

gilbert a écrit :

Je vais commencer par lire ton mémoire parce que oui, ça m'intéresse.

Il n'est pas parfait, mais fait néanmoins une présentation de pas mal des problèmes. Je ne l'ai pas donné pour me faire mousser, mais je trouve que, sur les erreurs de calculs, tu ne te focalises pas sur le plus essentiel -- cela dit, je te rassure, rares sont ceux, même excellents programmeurs, qui ont vraiment conscience des problèmes d'arrondis et moi-même je ne fais pas le malin. D'ailleurs, dans ton message précédent, tu parles plus ou moins d'une précision de 200 chiffres, mais, en double précision IEEE 754, on ne peut guère espérer plus de 13 ou 14 chiffres significatifs. Et encore, 7 chiffres significatifs est déjà bien.

Il faut faire attention que ça ne soit pas trop mathématique, car je ne pense pas non plus qu'il faille être mathématicien pour apprendre à programmer.

Moi non plus. Cela dit, je fais appel à des notions de mathématiques étudiées en seconde, d'une part. D'autre part, si je propose bien de découvrir le C++, je ne pense pas qu'il s'agisse du bon langage pour débuter la programmation.

Je repasserai quand j'aurais quelque chose de pas trop stupide à proposer.

Hé bien, je suis bien entendu preneur de toutes suggestions. Cela dit, j'indique, page 6, que les « double » ne sont pas les nombres réels.

   À bientôt.

   Le Farfadet Spatial

Hors ligne

#25 Le 05/04/2010, à 15:29

®om

Re : Une autre approche du C++ standard

Je suis en train de lire, juste une petite coquille, page 4 (ou page 12 pdf, vu que les numéros ne sont pas les mêmes) :

En programmation, les bibliothèques consistent en divers éléments qui ont déjà été
programméS et qui permettent auX développeurs

Dernière modification par ®om (Le 05/04/2010, à 15:30)

Hors ligne