Le langage D

[3DArchi]

Envoyé par Klaim

- CTFE

Tu peux préciser stp? Je connais pas cet acronyme...

http://en.wikipedia.org/wiki/Compile_time_function_executionCf : La métaprogrammation en C++

Envoyé par Klaim

- propriétés

Cette feature est pour le moins contestée au niveau C++... a mon avis avec ou sans c'est pas très important.

Je suis aussi très dubitatif avec cette feature.

Envoyé par Klaim

- auto

Sera disponible dans C++0x et est aujourd'hui déjà implémenté dans des compilateurs récents comme gcc 4.4.x (si je me trompe pas) et le prochain vc10 qui devrait être officiellement dispo dans quelques mois et dont la beta est déjà dispo.

Boost.Typeof en attendant

Envoyé par Klaim

- de pas écrire de headers

Je ne comprends pas ce point : tu peux tout a fait coder sans header si tu n'as pas de types communs a tes différents cpp... ?

J'avoue que je ne comprends pas trop non plus. Force de l'habitude ? Peut être, mais j'avoue aimer pouvoir séparer la déclaration dans un fichier d'en-tête de l'implémentation dans un fichier source.

[ponce]

Envoyé par Klaim

Tu peux préciser stp? Je connais pas cet acronyme...

Pouvoir exécuter une fonction à la compilation.
Par exemple: const a = sin(1.5); // a est connue à la compil

Envoyé par Klaim

- arrays ops
Je ne suis pas sur de comprendre non plsu ce que tu entends par là?

Les arrays op potentiellement permettent de vectoriser une boucle.

Code :

1
2
3
 
float[] a, b, c;
a[] = b[] + c[] * 2.f;

Ce qu'on peut faire en mieux en C++ avec des expressions templates, pour être honnête (Eigen).

Envoyé par Klaim

- slices
Là par contre je ne vois pas bien en quoi en D il y a un avantage par rapport a C++, un slice a priori, est de toutes manière dépendant du conteneur ou des fonctions qui l'effectuent non?

Disons que les tableaux dynamiques de D sont des std::vector builtins d'où un gain en expressivité au prix de la généricité.

Envoyé par Klaim

- propriétés

Cette feature est pour le moins contestée au niveau C++... a mon avis avec ou sans c'est pas très important.

C'est sans doute une histoire de goûts, moi je ne peux pas m'en passer. Même si Delphi avait mieux compris les propriétés je trouve.

Envoyé par Klaim

- import

Oui, tout ce qui est module est problématique en C++, visiblement le problème sera (avec de la chance) travaillé pour le TR2 (après c++0x).

Cf plus bas.

Envoyé par Klaim

- auto

Sera disponible dans C++0x et est aujourd'hui déjà implémenté dans des compilateurs récents comme gcc 4.4.x (si je me trompe pas) et le prochain vc10 qui devrait être officiellement dispo dans quelques mois et dont la beta est déjà dispo.

Oui je sais, c'est pour ca que j'ai précisé "aujourd'hui". (C'est d'ailleurs les features les plus faciles à implémenter de C++0x qui sont venues en premier.)

Envoyé par Klaim

- nested functions

Possibles a partir de C++0x via les lambda.

Exact, mais C++0x n'est pas encore là. Les lambdas C++, c'est une très bonne nouvelle mais je n'aime pas l'idée de spécifier quoi mettre dans la closure manuellement.

Envoyé par Klaim

- de pas écrire de headers

Je ne comprends pas ce point : tu peux tout a fait coder sans header si tu n'as pas de types communs a tes différents cpp... ?

En pratique, j'ai des types communs à mes différents cpp et je n'ai jamais codé dans un projet où ca n'arrivait pas. Mais ca m'intéresse si on peut baisser ce couplage.

Envoyé par Klaim

- constexpr ("const")
Ca arrive avec C++0x

On dit C++1x

Envoyé par Klaim

- pas besoin de preprocesseur

Je ne comprends pas non plus : si tu n'utilise pas de commandes de préprocesseur, alors il ne sera pas utilisé. Ou alors j'ai mal compris ce que tu veux dire?

En pratique, tu as besoin du préprocesseur même en ne ciblant qu'une plateforme et qu'un compilateur. Préprocesseur => pas d'auto-complétion fiable et en temps borné (je le constate tous les jours avec VS2008).

Envoyé par Klaim

- compiler en 2 sec un programme en entier (200 ms pour du link incrémental)

C'est clair! D'après ce que j'ai lu sur le net, il se peut que si un systeme de module est mis en place, cela aiderai à largement accélérer la compilation. Mais je n'ai pas suivi les détails, je dis peut être des bêtises. En tout cas, rendre la compilation rapide aiderai grandement au niveau organisations iteratives façon scrum parcequ'on perdrait moins de temps a récupérer une version pour du feedback.

Il me semble que Google a compris cela quand ils ont marketé leur langage Go (que je n'aime pas par ailleurs).

Un système de module en C++ nécessiterait d'exporter des templates, or c'est dur à faire. Ca m'étonnerait que ca vienne dans le compilateur de Microsoft par exemple...

En D, un template n'a pas besoin d'être dans chaque "translation unit".
Le D, c'est comme si une partie de Boost était dans le langage. Pas besoin d'attendre trois plombes que ca compile.

[koala01]

Envoyé par ponce

Pouvoir exécuter une fonction à la compilation.
Par exemple: const a = sin(1.5); // a est connue à la compil

Comme l'a fait remarquer 3DArchi, c'est possible avec la méta programmation, même s'il faut avouer que ce n'est (comme tout ce qui touche à la méta prog un "peu poussée") pas *forcément* tres instinctif comme manière d'envisager les choses

Les arrays op potentiellement permettent de vectoriser une boucle.

Code :

Ce qu'on peut faire en C++ avec des expressions templates.

Là aussi, avec la méta programmation, c'est possible, avec la même remarque que plus haut

Disons que les tableaux dynamiques de D sont des std::vector builtins d'où un gain en expressivité au prix de la généricité.

C'est sans doute une histoire de goûts, moi je ne peux pas m'en passer.

C'est sans doute (surement) que tu as têté à la tétine des propriétés avant d'avoir assimilé les concepts plus ou moins immuables de la programmation OO...

Le concept de propriété est fondamentalement en désaccord avec des règles de POO qui sont souvent, et parfois volontairement, mal interprétées ou passées sous silence par certains langages.

Je pense, entre autres, à la loi demeter

Oui je sais, c'est pour ca que j'ai précisé "aujourd'hui".

Sauf que, même si C++0x (C++1x maintenant), c'est... aujourd'hui, même si la norme n'est pas tout à fait finalisée

Comme l'ont si bien fait remarquer plusieurs personnes, la plupart des compilateurs actuels implémentent déjà une bonne partie des features de la prochaine norme

Exact, mais C++0x n'est pas là. Les lambdas C++ c'est une bonne nouvelle mais je n'aime pas l'idée de spécifier quoi mettre dans la closure manuellement.

Encore une fois, elle a beau ne pas être totalement finalisée, la nouvelle norme est déjà bel et bien là, et rien ne t'empêche, dés à présent, de la respecter dans ton code

En pratique, tu as besoin du préprocesseur même en ne ciblant qu'une plateforme et qu'un compilateur. Préprocesseur => pas d'auto-complétion fiable et en temps borné (je le constate tous les jours avec VS2008).

Absoluement pas...

L'auto-complétion n'est jamais qu'une "facilité fournie" par le traitement de texte intégré à ton environnement de développement...

Le préprocesseur n'est qu'une étape de la compilation qui applique des macros...

Si tu n'utilise pas les macros du préprocesseur, tu peux parfaitement t'en passer

Si un EDI donné a besoin du préprocesseur pour permettre l'auto-complétion, j'aurais presque tendance à dire qu'il est beaucoup trop couplé avec le compilateur

Il me semble que Google a compris cela quand ils ont marketé leur langage Go (que je n'aime pas par ailleurs).

Un système de module en C++ nécessiterait d'exporter des templates, or c'est dur à faire. Ca m'étonnerait que ca vienne dans le compilateur de Microsoft par exemple...

En D, un template n'a pas besoin d'être dans chaque "translation unit".
En D, c'est comme si une partie de Boost était dans le langage. Pas besoin d'attendre trois plombes que ca compile.

C'est à quoi servent, entre autres, les en-têtes précompilées et les bibliothèques

La notion de module est utilisé en quasi permanence chaque fois que tu utilise une bibliothèque externe, que ce soit soit la forme d'une bibliothèque statique ou dynamique...

Maintenant, rien ne t'empêche d'appliquer un raisonnement fort similaire pour tes propres développements, et de "modulariser" ton projet de manière à... créer des bibliothèques qui soient le plus indépendantes les unes des autres...

Evidemment, il faut avouer que cela demande un peu plus d'effort de conception, mais qui oserait prétendre que l'on crée une application comme on écrit une lettre à sa douce

il ne faudrait pas non plus confondre la finalité avec les outils
"pouvoir tout faire" en C++ (même si je ne crois pas que ca soit vrai) voudrait plus dire selon moi que l'on peut réaliser tout type de programme avec les outils dont on dispose
tandis que vous listez tous les outils dont D dispose, ce qui ne dit pas si on peut faire "plus de choses".

[Goten]

+1 avec screetch... surtout que si on part par là, le C++ est turing complet, donnc il peut " tout faire"... Tout comme le BF

[ponce]

Envoyé par koala01

Comme l'a fait remarquer 3DArchi, c'est possible avec la méta programmation, même s'il faut avouer que ce n'est (comme tout ce qui touche à la méta prog un "peu poussée") pas *forcément* tres instinctif comme manière d'envisager les choses

Comment tu calcules un sinus à la compilation avec la méta-programmation ? J'aimerais bien savoir.

Envoyé par koala01

C'est sans doute (surement) que tu as têté à la tétine des propriétés avant d'avoir assimilé les concepts plus ou moins immuables de la programmation OO...

C'est gentil de me prendre de haut mais merci je sais programmer objet... les propriétés, c'est une autre manière d'écrire des getters et setters. Ni plus, ni moins.

Envoyé par koala01

Le concept de propriété est fondamentalement en désaccord avec des règles de POO qui sont souvent, et parfois volontairement, mal interprétées ou passées sous silence par certains langages.

Je pense, entre autres, à la loi demeter

Les propriétés ne violent pas l'encapsulation. C'est une autre syntaxe pour appeler une méthode, point barre. J'ai même vu des cas où ca permettait de remplacer un champ par une méthode où vice-versa de manière transparente (donc augmenter l'encapsulation).

Envoyé par koala01

Comme l'ont si bien fait remarquer plusieurs personnes, la plupart des compilateurs actuels implémentent déjà une bonne partie des features de la prochaine norme

La partie la plus facile. La CTFE c'est une très grosse partie.

Envoyé par koala01

Encore une fois, elle a beau ne pas être totalement finalisée, la nouvelle norme est déjà bel et bien là, et rien ne t'empêche, dés à présent, de la respecter dans ton code

Merci mais j'ai des clients qui attendent, je vais pas coder pour une norme pas finie.

Envoyé par koala01

Si tu n'utilise pas les macros du préprocesseur, tu peux parfaitement t'en passer

Non tu ne peux pas t'en passer en C++.
Cite moi un programme réel sans macros et sans #ifdef

Envoyé par koala01

Si un EDI donné a besoin du préprocesseur pour permettre l'auto-complétion, j'aurais presque tendance à dire qu'il est beaucoup trop couplé avec le compilateur

C'est pourtant ce qui arrive quand parser un fichier nécessite toute la chaîne de compilation.

Envoyé par koala01

La notion de module est utilisé en quasi permanence chaque fois que tu utilise une bibliothèque externe, que ce soit soit la forme d'une bibliothèque statique ou dynamique...

Maintenant, rien ne t'empêche d'appliquer un raisonnement fort similaire pour tes propres développements, et de "modulariser" ton projet de manière à... créer des bibliothèques qui soient le plus indépendantes les unes des autres...

Evidemment, il faut avouer que cela demande un peu plus d'effort de conception, mais qui oserait prétendre que l'on crée une application comme on écrit une lettre à sa douce

Ah les joies de faire des librairies dynamiques en C++... Pas étonnant que les gens s'en tiennent à une interface C.

[ponce]

Envoyé par screetch

tandis que vous listez tous les outils dont D dispose, ce qui ne dit pas si on peut faire "plus de choses".

A mon avis on ne peut strictement rien faire de plus.
EDIT: Mais surtout, il ne fait pas moins comme tous les autres langages proposés comme "remplacement".

Je cherche juste à répondre aux contre-vérités, pas à inciter qui que ce soit à programmer en D (il faut être un peu maso).

[3DArchi]

Envoyé par ponce

Comment tu calcules un sinus à la compilation avec la méta-programmation ? J'aimerais bien savoir.

A priori, avec son développement polynomial si mes souvenirs mathématiques sont bons

[ponce]

Envoyé par 3DArchi

A priori, avec son développement polynomial si mes souvenirs mathématiques sont bons

Exactement, j'avais lu un article là-dessus où ils faisaient ca.

Sauf qu'un développement de Taylor comme ca, non seulement ca converge lentement mais ca ne marche bien qu'autour de zero. Donc ce n'est pas comme si "on pouvait faire ca en méta-programmation".

Si j'ai envie de calculer ca à la compilation en C++:

Code :

1
2
 
sqrt(cos(exp(1) * atan(1.0) * 4.0));

Je vais probablement prendre la calculette plutôt que de calculer la dérivée n-ième (où laisser tomber et faire ca à l'exécution ).

[3DArchi]

Visual (donc hors du langage en lui même) propose les intrinsic, c'est à dire qu'il t'inline le code de fonctions comme sin, cos, etc. à la place de l'appel.

[koala01]

Envoyé par ponce

Comment tu calcules un sinus à la compilation avec la méta-programmation ? J'aimerais bien savoir.

En utilisant les règles des séries...

Je crois d'ailleurs que ce point est expliqué dans l'article sur la méta programmation déjà cité par 3D

C'est gentil de me prendre de haut mais merci je sais programmer objet... les propriétés, c'est une autre manière d'écrire des getters et setters. Ni plus, ni moins.

Je ne voulais absolument pas te prendre de haut, et je te fais mes plus humbles excuses si c'est l'impression que je t'ai donnée.

Ce que je voulais exprimer, c'est que tu as sans doute trop pris l'habitude des propriétés pour te rendre compte que le concept lui-même est sujet à caution, entre autre à cause de demeter.

Et comme les habitudes prises "au bibron" (comprend: quand on débute) sont les plus tenaces...

Les propriétés ne violent pas l'encapsulation. C'est une autre syntaxe pour appeler une méthode, point barre. J'ai même vu des cas où ca permettait de remplacer un champ par une méthode où vice-versa de manière transparente (donc augmenter l'encapsulation).

Tu me confirme ici que tu as une vision déformée de la loi demeter...

S'il est vrai que le concept d'encapsulation est une des composantes de demeter, ce n'est absolument pas le seul point de vue qu'elle aborde.

De plus, tu sembles croire que le seul but de l'encapsulation est... de cacher le contenu d'un objet, et, là encore, ce n'est pas le cas.

Si tu place un accesseur ou pire, un mutateur sur le membre d'une classe, il ne sert souvent pas à grand chose de le placer en visibilité privée pour *soi disant* l'encapsuler...

Demeter dit que, si une classe B utilise (a comme membre un objet du type) une classe C, et que, si une classe A utilise un objet dont le type est un B, la classe A ne devrait absolument rien connaitre... du type C.

Si tu crée une fonction qui renvoit... (une référence sur) un objet de type C, et, pire, si tu manipule depuis ton objet de type A (la référence sur)l'objet de type C renvoyé par ton objet de type B, tu crées une dépendance très forte de ta classe A vis à vis de... la classe C, alors que la seule dépendance réellement subie par la classe A devrait être vis à vis de... B

L'idée poursuivie par l'encapsulation est de réfléchir d'une manière proche de

Je dispose d'un type B qui me fournit l'ensemble des comportements qui me permettent de le gérer sans avoir à m'inquiéter des "détails d'implémentation".

Si B est, entre autres, composé d'un membre de type C, aucun des comportements de B ne doit laisser transparaitre ce fait.

Si une classe A utilise le type B, je fais simplement appel aux comportements de B, et cela me suffit: je n'ai a priori aucun besoin de récupérer le C dans une fonction de A.

Dans l'absolu, je dois pouvoir utiliser une instance de type B dans une fonction de A sans même avoir à m'inquiéter du fait qu'il existe un type C qui est utilisé par B

La partie la plus facile. La CTFE c'est une très grosse partie.

Comme on l'a déjà fait remarquer, cela existe depuis très longtemps, même si cela passe par des traits ou des politiques, et même s'il faut avouer que leur mise en oeuvre n'est pas forcément "instinctive"

Merci mais j'ai des clients qui attendent, je vais pas coder pour une norme pas finie.

Et pourtant...

Si tu ose "prendre le pari" de déjà utiliser les possibilités de la prochaine norme, quitte à ce que cela se fasse à coup de compilation conditionnelle, tu te mets en bonne position pour réagir rapidement aux évolutions futures...

En effet, une fois que la norme sera finalisée et appliquée, il te suffira d'une option de compilation pour être en mesure... de profiter de ses avantages, et, pourquoi pas, de supprimer toute une partie du code qui serait moins efficace.

Cela prend, certes, plus de temps aujourd'hui, mais c'est, très certainement, de nature à t'en faire gagner énormément par la suite...

Sur le court terme, cela ne changera pas grand chose du fait que cela ne te prend que quelques minutes de prendre les deux situations en compte au moment même, mais, sur le long terme, cela te fait gagner un temps précieux parce que tu t'économise le temps important que pourrait nécessiter le fait de tout reprendre (avec les problèmes de refactoring que cela implique) pour adapter ton code à la nouvelle norme

Non tu ne peux pas t'en passer en C++.
Cite moi un programme réel sans macros et sans #ifdef

Dans mes codes, je ne les utilise que comme garde contre les inclusions multiples, ou, comme je viens d'en parler, lorsque je souhaite anticiper sur la prochaine norme...

C'est pourtant ce qui arrive quand parser un fichier nécessite toute la chaîne de compilation.

Si ton éditeur de texte nécessite de passer toute la chaine de compilation en revue pour te fournir l'auto complétion, c'est que, quelque part, il y a un sérieux problème, tu ne crois pas

Ah les joies de faire des librairies dynamiques en C++... Pas étonnant que les gens s'en tiennent à une interface C.

Le problème des bibliothèques dynamique du C++ vient principalement du fait qu'il n'y a pas (encore) d'abi standardisée pour celui-ci (mais il me semble que c'est un des points sur lequel se concentre la nouvelle norme)...

Et puis, il n'y a pas que les bibliothèques dynamiques, dans la vie... le bibliothèques statiques ont pas mal de choses à nous apporter, surtout lorsqu'il s'agit de modulariser un projet

les flottants et doubles ne sont pas supportés par les templates C++.
la raison est que le code est généré sur une machine A et éxécuté sur une machine B qui pourraient donner des résultats différents, donc le code flottant doit être calculé et non inliné.
sinon il faut un compilateur capable d'émuler l'architecture cible, mais là encore, quid des exceptions de virgule flottante?

[ponce]

Envoyé par koala01

Tu me confirme ici que tu as une vision déformée de la loi demeter...

S'il est vrai que le concept d'encapsulation est une des composantes de demeter, ce n'est absolument pas le seul point de vue qu'elle aborde.

De plus, tu sembles croire que le seul but de l'encapsulation est... de cacher le contenu d'un objet, et, là encore, ce n'est pas le cas.

Si tu place un accesseur ou pire, un mutateur sur le membre d'une classe, il ne sert souvent pas à grand chose de le placer en visibilité privée pour *soi disant* l'encapsuler...

Demeter dit que, si une classe B utilise (a comme membre un objet du type) une classe C, et que, si une classe A utilise un objet dont le type est un B, la classe A ne devrait absolument rien connaitre... du type C.

Si tu crée une fonction qui renvoit... (une référence sur) un objet de type C, et, pire, si tu manipule depuis ton objet de type A (la référence sur)l'objet de type C renvoyé par ton objet de type B, tu crées une dépendance très forte de ta classe A vis à vis de... la classe C, alors que la seule dépendance réellement subie par la classe A devrait être vis à vis de... B

Dans ce cas-là j'ai tendance à utiliser la délégation dans mon objet B pour que A ne le manipule pas. J'ai mis du temps à apprendre ça effectivement mais je ne pense plus faire l'erreur.


A mon avis proposer un getter ou setter alors qu'on ne devrait pas (ie. violer Demeter) est orthogonal avec le fait d'utiliser ou non des propriétés, qui sont du sucre syntaxique autour (ou alors tu penses qu'on a jamais besoin de getter ?).

Il y a pire, j'ai vu un langage où chaque définition de champ définissait un getter et un setter automatiquement

Le problème des bibliothèques dynamique du C++ vient principalement du fait qu'il n'y a pas (encore) d'abi standardisée pour celui-ci (mais il me semble que c'est un des points sur lequel se concentre la nouvelle norme)...

J'avoue que c'est la feature qui me plait le plus dans la norme qui vient.

[ponce]

Envoyé par screetch

les flottants et doubles ne sont pas supportés par les templates C++.
la raison est que le code est généré sur une machine A et éxécuté sur une machine B qui pourraient donner des résultats différents, donc le code flottant doit être calculé et non inliné.
sinon il faut un compilateur capable d'émuler l'architecture cible, mais là encore, quid des exceptions de virgule flottante?

C'est effectivement un vrai casse-tête. Par exemple le code flottant ne s'exécute pas exactement pareil à la compilation et à l'exécution en D (plus de précision à la compilation).

[koala01]

Envoyé par ponce

Dans ce cas-là j'ai tendance à utiliser la délégation dans mon objet B pour que A ne le manipule pas. J'ai mis du temps à apprendre ça effectivement mais je ne pense plus faire l'erreur.


A mon avis proposer un getter ou setter alors qu'on ne devrait pas (ie. violer Demeter) est orthogonal avec le fait d'utiliser ou non des propriétés, qui sont du sucre syntaxique autour

Justement, c'est tout le noeud du problème...

Les propriétés n'étant, comme tu le fais remarquer, qu'un "sucre syntaxique" remplaçant les mutateur et accesseurs, tu est tenté de déclarer "propriété" (avec les accesseurs et mutateurs que le terme induit) quelque chose qui... ne devrait pas l'être...

(ou alors tu penses qu'on a jamais besoin de getter ?).

Je pense, en tout cas, que l'on en a besoin suffisemment rarement pour y réfléchir à deux fois avant de décider d'en placer un, c'est certain

Et, si j'admets encore "assez facilement" (alors que tu auras remarqué que je ne suis pas leur meilleur partisan) l'usage d'accesseurs, j'ai, toutes proportions gardées, encore beaucoup plus de mal à admettre les mutateurs.

Or, si tu fournis un mécanisme qui tend à simplifier la mise en oeuvre de comportement qui devraient rester exceptionnels, tu incite de facto à la généralisation de l'utilisation de ces comportements.

Et c'est en cela que j'ai énormément de mal à accepter le concept de propriété.

Il y a pire, j'ai vu un langage où chaque définition de champ définissait un getter et un setter automatiquement

Effectivement, c'est assez choquant de leur part

[ponce]

Envoyé par koala01

Justement, c'est tout le noeud du problème...

Les propriétés n'étant, comme tu le fais remarquer, qu'un "sucre syntaxique" remplaçant les mutateur et accesseurs, tu est tenté de déclarer "propriété" (avec les accesseurs et mutateurs que le terme induit) quelque chose qui... ne devrait pas l'être...
Je pense, en tout cas, que l'on en a besoin suffisemment rarement pour y réfléchir à deux fois avant de décider d'en placer un, c'est certain

C'est vrai que ca risque de banaliser la chose... et ca n'encourage pas à faire émerger une interface claire. Je comprends mieux ce que tu voulais dire.

Envoyé par koala01

Et, si j'admets encore "assez facilement" (alors que tu auras remarqué que je ne suis pas leur meilleur partisan) l'usage d'accesseurs, j'ai, toutes proportions gardées, encore beaucoup plus de mal à admettre les mutateurs.

Je les utilise énormément... particulièrement avec les libraries qui maintiennent un état. C'est certain que ca poserait des problèmes sur des projets plus gros avec beaucoup de personnes

Cela dit, c'est une question de balance entre faire vite et faire bien ; on peut aussi s'en tenir à des conventions qu'on essaye de garder.

Envoyé par koala01

Or, si tu fournis un mécanisme qui tend à simplifier la mise en oeuvre de comportement qui devraient rester exceptionnels, tu incite de facto à la généralisation de l'utilisation de ces comportements.

Tout à fait d'accord. Je trouve d'ailleurs que le C++ est rempli de tels "pièges".

Envoyé par koala01

Et c'est en cela que j'ai énormément de mal à accepter le concept de propriété.

Je suis près à prendre ce risque contre un peu de productivité. Je ne trouve pas que ca soit si problématique en fait.

Quelque part le C++ vient avec l'assertion que chaque partie du code sera réutilisé. De mon côté, j'écris beaucoup de code jetable qui n'aura que quelques utilisations seulement.

(EDIT: la philosophie du C++ est aussi de faire confiance au programmeur ; libre à lui de se tirer une balle dans le pied, non ?)

[koala01]

Envoyé par ponce

Je suis près à prendre ce risque contre un peu de productivité. Je ne trouve pas que ca soit si problématique en fait.

Je préférerais personnellement perdre un peu de temps à assurer une conception correcte...

Le temps passé à assurer une conception correcte est très largement amorti au vu du temps passé en debugage et recherche d'erreur lorsque la conception fait défaut.

Encore une fois, cela implique une vision à terme un peu plus large que... simplement les cinq prochaines minutes

A titre personnel, la première chose que je fais quand on me demande un code, c'est de fumer une cigarette ou de boire un café... pour prendre le temps de réfléchir aux différentes implications de ce qu'on me demande.

A défaut de sortir l'artillerie lourde (schema UML ou nassi schneiderman), pour des petites choses particulièrement limitées dans le temps, cela me permet, au moins, d'avoir une vue d'ensemble avant de commencer à coder, et de gagner énormément de temps par rapport à ceux qui se jettent sur leur clavie et commence à "vomir des lignes de code" sans savoir exactement ce qu'ils doivent faire...

Si tu ne me crois pas, je t'invite à en faire l'expérience par toi même

Quelque part le C++ vient avec l'assertion que chaque partie du code sera réutilisé. De mon côté, j'écris beaucoup de code jetable qui n'aura que quelques utilisations seulement.

Je ne vois pas en quoi un code "jetable" ou "peu réutilisé" ne mérite pas une attention particulière au moment de la conception...

C'est un peu comme si tu estimais devoir faire plus attention en écrivant un système d'exploitation qu'en écrivant une simple calculatrice en ligne de commande: quand on fait quelque chose, même si c'est un "petit projet" qui n'est pas destiné à être récupéré, on le fait bien, ou pas du tout...

J'apprécie énormément les logiciels de qualité, et je présumes que je suis loin d'être le seul.

Si tu te "contente" de fournir quelque chose d'à peine passable, il ne faut pas t'étonner outre mesure si ton concurrent direct, qui fournit quelque chose de meilleure qualité, a plus de succes que toi.

Mais bon, ce n'est qu'un avis qui n'engage que moi... Mais je le partage

(EDIT: la philosophie du C++ est aussi de faire confiance au programmeur ; libre à lui de se tirer une balle dans le pied, non ?)

Je dirais: raison de plus...

Il y a déjà tellement de pièges dans lesquels on risque de tomber, que ce soit au niveau de la conception ou au niveau d'un langage particulier (je vise particulièrement C++ ici), qu'il me semble inutile d'en rajouter "uniquement pour le plaisir"

[ponce]

Envoyé par koala01

Si tu ne me crois pas, je t'invite à en faire l'expérience par toi même
Je ne vois pas en quoi un code "jetable" ou "peu réutilisé" ne mérite pas une attention particulière au moment de la conception...

C'est un peu comme si tu estimais devoir faire plus attention en écrivant un système d'exploitation qu'en écrivant une simple calculatrice en ligne de commande: quand on fait quelque chose, même si c'est un "petit projet" qui n'est pas destiné à être récupéré, on le fait bien, ou pas du tout...

Moi aussi j'aime énormément quand c'est bien fait dans le code.

Mais avoir assez vite quelque chose qui marche, dégage du temps pour une autre qualité justement ; pas forcément la qualité du code, que personne ne voit malheureusement, mais les choses à côté. Il y a aussi des moments où c'est la panique et qu'il faut aller vite (deadlines "presque tenable"...).

Je n'ai pas l'impression que le C++ encourage spécialement à la qualité en fait (qualité dans le sens "pas de bugs"). (EDIT: même si le langage a peu d'influence là dessus)

ce qui m'interesse le plus dans le C++ c'est le code généré pour moi par le compilateur; l'aggrégation de deux classes copiables est copiable, l'héritage aussi, le destructeur qui 95% du temps ne devrait pas être changé (et j'essaye vraiment de m'en tenir a cette règle)
a côté de cela, avoir une propriété ou bien appeler une fonction ne me fait ni chaud ni froid.

[Alp]

Au fait, si on fait une version constexpr de sin, on peut très bien faire ça en C++0x hein ponce.