Discussion :

[Mac LAK]

insert fait ce qu'il dit : il insère, point barre. il n'ecrase pas.

Bon, on va donc reprendre... Via [], tu peux insérer ou remplacer (suivant ce qui existe) une valeur. Bref, tu as un ajout inconditionnel, ou une lecture.

Pour le reste, je viens de vérifier... Faut dire aussi que j'utilise tellement peu find/insert - tellement c'est barbare - que ça doit bien faire deux ans que je n'ai pas écrit une seule ligne avec ces méthodes.

Via insert, tu ne peux pas écraser la valeur, et tu dois adopter un comportement spécial si la valeur existe déjà (d'où le find) afin de la remplacer.
Donc, pour écraser une valeur : sans find avant le insert, et sans utiliser [], tu fais comment ? Tu la vires inconditionnellement avant de l'insérer ? Dans tous les cas, c'est une usine à gaz qui demande d'éplucher la doc des deux fonctions pour être certain de ce qu'elles font. Via [], tu t'en sers comme d'un tableau, le sens est évident en fonction de la position de l'élément indexé (L ou R-value). Le code est également plus concis, plus lisible, et tu te passe des itérateurs.

Je ne te disais pas de l'utiliser, mais de le regarder.

Veni, vidi, reparti... C'est loin de m'avoir convaincu de lâcher mon RAD.

Maintenant, s'il pouvait exister un framework genre wpf en C++ (bien que tu exagères les difficultés de debug, la barrière managé/natif étant assez transparente de ce point de vue là), je m'y pencherais sûrement.

C++/CLI est là pour ça. Par contre, la barrière est plus lourde que tu ne le crois : tu ne peux attacher qu'un seul débugger à l'exécutable, soit en mode managé, soit en mode natif. Quand tu arrives au wrapping managé/natif (importation DLL ou appel vers le managé), ton debugger ne permet plus de tracer dans le source, hélas : il voit la fonction de "l'autre monde" comme quelque chose d'atomique, et ton debugger ne passe pas automatiquement du mode managé au mode natif et réciproquement.
Très pénible quand on fait du debug de wrappers... OK, c'est un cas particulier, mais il se trouve que je suis passé en plein dedans pour avoir développé, justement, des interfaces C#/C++ générales (et générées).

[Invité]

Mais, encore une fois, tu change la sémantique d'un opérateur...

Je faisais cette chose parce que tu avais objecté "et si un noob écrit if(collection.size = ...)"
Alors oui ca arrive à tout le monde une fois l'an, mais de là à dire que ca arrivera plus souvent avec les propriétés car on fait plus d'affectation, je trouve ca irréaliste. Mais c'est pas grave, on est là pour enculer des mouches.

En plus, tu te goure durement dans l'implémentation que tu en donnes...

Oui, en fait il faut enlever le return. Ca devrait marcher ensuite. Et bonne soirée, j'ai encore du travail à faire, du genre à rendre Demeter malheureuse.

[koala01]

On m'objecte un problème improbable, j'y réponds une réponse improbable.

Un problème improbable... Tu aimes bien rire, toi...

L'oubli d'un égal lorsque l'on fait un test est une des erreurs sans doute les plus courantes que l'on puisse rencontrer...

[Invité]

*this = a ? >_< ... kaboum

Arg, c'était sévèrement faux. Bon, vous avez saisi l'idée.

[koala01]

Je faisais cette chose parce que tu avais objecté "et si un noob écrit if(collection.size = ...)"
Alors oui ca arrive à tout le monde une fois l'an, mais de là à dire que ca arrivera plus souvent avec les propriétés car on fait plus d'affectation, je trouve ca irréaliste. Mais c'est pas grave, on est là pour enculer des mouches.

Le fait est que, l'oubli d'un caractère arrive à tout le monde, parce que l'on est fatigué, pressé ou distrait, et que ce n'est absolument pas un erreur de newbies.

Effectivement, il faut être newbies pour ne pas s'en apercevoir lorsque l'on est confronté à une erreur de ce type, mais, là intervient la principale différence entre une fonction size() constante et une propriété (RW) portant le même nom...

Avec la première le code

Code :

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

if(tab.size()=someUnsignedInt)

te renverra une erreur de compilation, alors que, avec la deuxième, le même code

Code :

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

if(tab.size=someUnsignedInt)

sera, non seulement accepté, mais aura, en plus, un comportement tout à fait différent.

Et, bien évidemment, tu peux n'en ressentir les effets que... tres loin de tout appel de la fonction dans laquelle tu aura placé ce test.

Or, si tu cherche la raison d'un comportement incohérent "à des kilomètres" de la cause, newbies ou pas, tu auras le plus grand mal à remarquer cette faute de frappe

Oui, en fait il faut enlever le return. Ca devrait marcher ensuite. Et bonne soirée, j'ai encore du travail à faire, du genre à rendre Demeter malheureuse.

C'est bien pire que cela...

le concept de "copy and swap", ca te dis quelque chose

[screetch]

Le code est également plus concis, plus lisible, et tu te passe des itérateurs.

Dixit le mec qui ne sait pas ce que fait operator[]
c'est une blague, n'est-ce pas ?????????
c'est vraiment difficile de continuer ici si tu ne fais pas un effort.

pour le reste c'est hors sujet

[deadalnix]

C'est vrai, les iterrator sont tellement clairs, il n'y a pas de doutes la dessus.

[screetch]

vous etes juste entrés en mode "attaque de moulins a vent". un retour a la discussion initiale serait bienvenu, honnêtement.

[koala01]

C'est vrai, les iterrator sont tellement clairs, il n'y a pas de doutes la dessus.

Je crois détecter une certaine pointe d'ironie dans ta remarque, alors...

D'un point de vue de l'utilisation, effectivement, ils sont on ne peut plus clairs:

• ++ permet de passer au suivant
• -- (s'il est opportun pour le conteneur envisagé) permet de passer au précédent
• * ou -> permet d'accéder à l'objet
• const_iterator s'assure que l'objet n'est pas modifié
• iterator donne l'opportunité de modifier l'objet

on peut difficilement faire plus simple, non

Ensuite, il y a, effectivement, la verbosité nécessaire si l'on ne passe pas par une alias de type..

Il est vrai que le code

Code :

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

1
2
3
4
std::vector<unTypeDonne> tab;
/*...*/
std::vector<unTypeDonne>::iterator it=tab.begin();
/*...*/

est assez long à écrire, et pas forcément lisible, mais, si tu rajoute un ou deux alias de type:

Code :

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

1
2
3
4
5
6
typedef std::vector<unTypeDonne> MonTab;
typedef typename std::vector<unTypeDonne>::iterator iterator;
MonTab tab;
/*...*/
iterator it=tab.begin();
/*...*/

c'est plutot expressif, non

Mieux, du moment que tu utilise une collection dont les possibilités sont compatible avec une autre (list et vector, par exemple), il te suffit de modifier le premier alias de type pour que ton code fonctionne avec l'autre collection, sans devoir rien changer d'autre

[Lavock]

Honnêtement, amha, je sais pas comment va penser l'utilisateur... Et je sais pas si il va trouver plus naturelle une propriété ou une fonction... Et je trouve que vous avez du culot de vouloir imposé votre "bonne" version des choses.

[edit] [strike]Cela dit, obligé de plussoyer l'avant dernière remarque de Koala... Si on peut mettre l'erreur bêtes dès la compile (et avec un message claire), c'est d'autant mieux.[/strike] La remarque de Ponce qui suit remet la balance à 0. Cela dit, ce n'est PAS le débat.

De toute façon, les propriétés sont qu'un outils. Pas encore obligé de les utiliser à ce que je sache. Le fait même qu'un langage les "propose" le rend, force est de constater, plus complet.

J'ai envie de dire que le débat ne porte pas sur si la feature vous plaît ou pas, mais si le gain de possibilité entre C++ et D va attirer des gens.

Du coup, moi là, la question que je me pose, c'est qu'est-ce qu'on peut faire en C++ qu'on ne peut pas faire en D? La question à souvent était abordé dans l'autre sens, mais pas tellement dans celui-ci. Or c'est seulement en répondant à cette question que l'on pourra déterminer si le D peut être considérer comme un successeur ou "juste" comme un autre langage.

[Invité]

Effectivement, il faut être newbies pour ne pas s'en apercevoir lorsque l'on est confronté à une erreur de ce type, mais, là intervient la principale différence entre une fonction size() constante et une propriété (RW) portant le même nom...

Le problème de la faute de frappe qui transforme == en = ne se pose que dans les langages qui convertissent implicitement tout et n'importe quoi en boolean. Autrement dit... C et C++

[Invité]

Du coup, moi là, la question que je me pose, c'est qu'est-ce qu'on peut faire en C++ qu'on ne peut pas faire en D? La question à souvent était abordé dans l'autre sens, mais pas tellement dans celui-ci. Or c'est seulement en répondant à cette question que l'on pourra déterminer si le D peut être considérer comme un successeur ou "juste" comme un autre langage.

- En C++ la philosophie est complètement différente,
- tu peux manipuler des objets par valeur,
- tu peux choisir finement le type de smart-pointer que tu veux et tes objets ne descendent pas tous d'une même classe mère.
- tu peux utiliser l'héritage multiple ce qui permet les fameux schémas en diamants infaisable autrement.
- généralement les compilos C++ optimisent 2x mieux et il est plutôt rare d'y trouver des bugs
- c'est beaucoup plus "sur" de développer en C++ du coup qu'en D, qui n'est utilisé commercialement que dans très peu de cas.
- C++ c'est la STL, Boost, et plein de librairies bien testées

Un avantage de C++ c'est aussi qu'il comporte suffisament de détail et de complications pour que tu n'aies jamais fini d'apprendre.


En ce qui concerne C++1x par rapport à D2, il aura:
- constructeurs virtuels
- template typedef
- la closure où ont spécifie exactement ce qu'on met dedans
- énumérations fortement typées
- user defined literals
- nullptr
- ...

et c'est tout je crois

[Emmanuel Deloget]

(C'est pénible ce "quote" qui enlève les "quote" de niveau supérieur...)

Même pas : le "re" sous-entends que l'opération est une modification à chaud, et non pas une primo-allocation. Pour faire plus clair, c'est comme si tu me disais que tu utilises realloc à la place de malloc de façon constante. Le nom serait exact si c'était "setsize", et non pas "resize"... Et une documentation est nécessaire pour savoir si les éléments sont conservés ou pas : on va donc l'appeler "setsizewithelementconservationexceptifsizeisreduced"... Ouais, super.

Là, j'en suis sûr, c'est de la mauvaise foi

Si c'est la même chose, en quoi le définir en accès unique est-il un problème ?

J'ai pas eu le sentiment d'écrire que c'était la même chose. Je pensais même essayer de démontrer que non, ce n'est pas la même chose, et que l'utilisation de fonctions pour effectuer des actions a plus de sens que l'utlisation de propriétés.

Avoir l'équivalent, en terme d'unicité d'accès, sans utiliser de propriétés revient à déclarer une sous-classe très fortement imbriquée dans sa classe parent, contrôlant justement tous les aspects liés à la taille.

Là je dois être un poil idiot, mais je ne vois pas ou tu veux en venir.

C'est plus simple dans le sens où tu n'as qu'un seul accès pour un concept donné, donc inutile de chercher à côté s'il existe autre chose : tout est là.
Je ne vois pas en quoi écrire "myClass.Size = 20 ;" est difficile à comprendre d'un point de vue syntaxique, ou même sémantique... La taille du machin est mise à 20, point, c'est simple et net.

Simple ? Net ? Ah bon.

Quelques questions :
1) est-ce qu'une action particulière est effectuée ? Parce que ça ne me dit pas qu'une action particulière est effectuée, si ce n'est l'affectation.
2) Est-ce que Size est une propriété ou une variable dont on a laissé imprudemment (ou au contraire avec beaucoup de sagesse peut-être) l'accès à tous ?
3) ce code peut-il renvoyer un code d'erreur ? Parce que si ça se trouve, je ne peux pas me permettre de traiter des exceptions dans la section de code qui l'utilise.

Maintenant, je repose les même questions avec une fonction resize().

1) ben à priori, une fonction particulière est effectuée. C'est dit dans le nom de la fonction.
2) Euh, c'est une fonction. Publique.
3) si ma fonction resize() échoue, on peut imaginer qu'un code d'erreur va être retourné (évidemment, je ne parle pas des fonctions équivalentes de la C++SL). Je n'ai pas besoin de traiter une exception.

Que d'avantages !

Pour le développeur ? Bien entendu... La philo Unix est même basée sur un principe similaire, d'ailleurs. Mais pour l'utilisateur, par contre, non : c'est au contraire quelque chose de crucial.

Euh... non. La philosophie (des utilitaire) d'Unix n'est basé sur rien de concret. C'est même une horreur tellement il n'y a rien derrière.

Si tu veux une analogie, c'est la différence entre une aide façon Windows (avec index, recherche, etc.) et une aide façon manpage. Dans le premier cas, tu peux chercher en fonction du but désiré. Dans le second, il vaut mieux connaître le nom de la fonction pour en avoir l'aide.

(Ou connaitre les options en ligne de commande de man ; mais ce n'est pas le débat).
Tiens, soyons fous et caricatural : imaginons que j'ai une base de donnée accessible via une interface I. Je veux rajouter une fonctionnalité de recherche. Quelle est la meilleure manière de faire :

1. ajouter une fonction recherche, qui prends en paramètre une expression de recherche et qui renvoie une liste de résultats trouvés ?
2. ajouter deux propriétés
   
   1. ExpressionRecherche
   2. ResultatRecherche
   
   Et expliquer à mes bagnards que changer la valeur de ExpressionRecherche a une influence directe sur le contenu de ResultatRecherche ?

J'ai dans ma petite idée que je saurais quelle méthode choisir, et dans la petite idée que tu va essayer de me démontrer que ta méthode serait mieux.

Pour ma part, j'ai les deux casquettes à la fois : je développe des API pour les autres, et j'en utilise moi-même (y compris les miennes, bien sûr). Je sais aussi que ça vaut le coup de passer 5% de temps de plus sur le dév, pour faire de "l'inutile" fonctionnel, mais qui me permettra d'avoir une paix royale par la suite sur l'utilisation.

Je fais ça aussi. Je sais par expérience que créer une interface simple est une tâche très compliquée. Ce n'est pas pour autant que je vais faire des compromis avec ce que je pense être une opinion argumentée et logique. Ajouter une fonction au nom évocateur n'est pas plus compliqué que d'ajouter une propriété.

Côté code interne à la classe ?? Mais quel besoin as-tu d'y mettre les mains pour l'utiliser, de façon générale ??

Ou est-ce que j'ai parlé de code interne ?

Quant aux données intrinsèques... C'est impossible d'avoir, de façon constante et systématique, l'absence totale de publication d'éléments intrinsèques. La taille d'un container devra forcément être publiée d'une façon ou d'une autre, un itérateur est une manière également de parcourir la structure interne d'une classe, etc. Si l'on raisonne sur le FOND et non pas sur la FORME, l'exposition de données intrinsèques est obligatoire.

Et bien, heu, non. Je n'aurais pas de fichier de configuration sur mon projet, je n'aurais exposé aucune donnée intrinsèque. Et si je l'ai fait, c'est uniquement parce que j'ai jugé, dans un moment de faiblesse, que c'est suffisamment idiomatique pour être pardonnable.

Pour le reste, j'ai plus de facilité à suivre les données que les actions, au contraire. Heureusement, la plupart des informaticiens sont à peu près bons en maths.

Si tu veux dire par là qu'une bonne majorité est capable ne pas se mélanger les pédales entre addition et multiplication, je suis d'accord avec toi. Si tu prétends qu'une bonne partie maitrise les notions exposées par Galois dans ses Anales de Mathématiques Pures et Appliquées, j'ai un léger doute. Mais tu as peut-être raison.

Pour les non-informaticiens, j'ai souvent moins de mal à leur représenter les concepts inclus dans une classe sous forme d'entité pouvant être manipulée que sous forme d'actions élémentaires incluses dans la classe parent.

Oui, ça mérite même un billet de ma part. Si je présente à un individu lambda un design ontologique, il aura beaucoup de facilité à le comprendre. Si j'essaie de transformer ce design en code, je vais droit dans le mur - parce que l'approche ontologique est nécessairement limitée. Le même problème se pose dans d'autres domaines liés au code. "goto" est plus compréhensible que l'appel de fonctions - ça ne veux pas dire que c'est mieux. Le code de liste chainée pondue par un étudiant en 1ère année d'info sera simple à comprendre, ça ne veut pas dire que sa liste chainée aura les même qualités que celle présente dans la C++SL.

Encore une fois, il s'agit de passer outre la dualité simplicité/simplisme, pas de l'exploiter. De manière générale, les architecture qu'on prétend "idiot-proof" sont aussi "user-proof" à long terme.

Heu... Ne me dis pas que tu ne distingues pas une L-Value d'une R-Value, quand même.

Bon, je me suis mal exprimé (argh). Une propriété, à moins que je ne me trompe, n'est ni une R-value, ni une L-value. C'est une propriété. L'accès en lecture et l'accès en écriture ne ressemble en rien à l'utilisation d'une L-value. Le fonctionnement de ces deux accès peut être extrêmement différent.

Ce n'est pas la même chose de lire et écrire une entité, même si ce sont bien entendu des opérations complémentaires. Je ne vois pas en quoi son rôle n'est pas unique...

Que dit-on d'une chose qui a deux fonctions différentes ? Combien de rôles a-t-elle ?

Tout comme une fonctionnalité peut être effectuée de plusieurs manières différentes sur les containers STL, par exemple : tu peux faire un erase() ou un resize(0), c'est pareil : où est l'unicité de la fonction, dans ce cas ??

resize(0) redimensionne le tableau pour qu'il contienne 0 élément. erase(begin(), end()) efface les éléments qui sont situés entre begin() et end(). clear() supprime tous les éléments du tableau. Le résultat de ces actions est le même, ce qui ne veut pas dire que ces fonctions ont plusieurs rôles. Ce sont deux notions indépendantes.

Ou le contraire : ça t'évite d'avoir plusieurs noms redondants pour décrire un concept unique. A condition d'arrêter de voir une propriété comme un attribut bête et méchant, et de la prendre en tant que concept, bien sûr.

Une propriété n'est PAS un attribut, même si elle s'utilise de la même manière. Ce serait aussi idiot que de dire qu'une fonction C et une fonction macro (préprocesseur) sont la même chose, juste parce qu'elles ont des parenthèses et des paramètres.

Je suis entièrement d'accord sur ce point. Chaque outil a une fonction (tiens, comme c'est étrange ).

Certes. Derrière, par contre, tu oublies que l'on a aussi des contraintes budgétaires, calendaires,techniques et humaines. OK, c'est idéaliste, mais c'est justement pour ça que ce n'est pas applicable. En pratique, ce n'est d'ailleurs pas de l'idéalisme, mais de l'utopie.

Je ne dirais pas le contraire. Mais en même temps, mon rôle en tant qu'architecte logiciel n'est pas juste de trouver des solutions à un problème mais trouver des solutions optimales au vu des contraintes (budgétaires, techniques...) qui s'appliquent à ce problème particulier. Et dans mon métier, taper dans l'idéalisme permet de développer des idées qui vont dans le bon sens. Développer des concepts, réfléchir sur le sens des outils qui sont à notre disposition, transmettre mes connaissances dans ce domaine particulier, tout cela fait partie de mes attributions.

Justement, tu as dis le mot : "simples"... Réussir à transformer une problématique complexe en un programme performant, on sait tous que c'est tout sauf trivial (et ceci que l'on soit collé au matériel ou dans les domaines de très haut niveau, d'ailleurs).

Le plus souvent, on arrive à un résultat performant, certes, mais difficile d'utilisation. Quel est le besoin qui pousse la plupart des dévs à se contenter de ceci, au lieu de simplifier les interfaces pour l'utilisateur et donc de "simplifier" le problème général pour celui qui utilise la boîte noire ?

Quand je dis simple, je fais référence à des problèmes qui sont effectivement simples pour moi (et pour bien d'autres), parce que j'ai déjà passé pas mal de temps à cogiter sur le sujet. Ca ne veux pas forcément dire que ce sont des problèmes simples. Un exemple parmi d'autres : stockés sur mon disque dur, une librairie qui encapsule l'aspect GUI de Windows, tout en restant simple d'utilisation. Ou l'encapsulation d'API 3D (DX + OpenGL). Ce sont des problèmes que je considère comme simple maintenant, parce que j'ai passé des mois - voire pour certains des années à affiner les concepts sous-jacents de manière à avoir une code très light, performant, et simple comme bonjour à utiliser. Ce sont des projets de type test-bed, et j'utilise les connaissances acquises pendant leur développement pour avancer dans mes capacité de modélisation objet.

Un problème simple est un problème qui admet une solution simple et élégante. Ca ne veut pas dire qu'il est résolu simplement - ça, c'est un problème trivial.

Tout dépend de ce que tu appelles "taille mirobolante".

Pour l'instant, environ 20,000 lignes de code (hors lignes blanches et lignes de commentaire ; parce que doxygen, ça prends une place folle dans un fichier...). Ca reste quand même très modeste. En même temps, si le client me donne 3 ans pour faire un projet, il sera nécessairement plus gros - mais ça ne veux pas dire que je vais sacrifier ma façon de faire sur l'autel de la pseudo-simplification.

Pour ma part, on est une vingtaine en permanence sur le projet, qui dure depuis presque 10 ans, et avec un turn-over énorme. Crois-moi, dans ce genre de cas, tu cherches au maximum à simplifier les interfaces d'utilisation, quitte à rendre le code interne (mais normalement caché) un peu plus difficile d'accès. De toutes façons, il est nettement plus souvent utilisé que modifié, donc ça convient très bien de privilégier l'utilisation à la modification.

Je ne vais pas critiquer ça. Je critique le fait d'utiliser des propriétés, qui selon moi (et ça n'engage que moi) ne simplifie en rien le code client.

D'un point de vue "conception interne de la classe et méthodes à développer", les propriétés ne simplifient RIEN. Par contre, elles simplifient l'utilisation de la classe, en centralisant les points d'accès et en simplifiant les appels. Ce n'est que de la syntaxe, la sémantique est très exactement la même que les accesseurs, mutateurs ou attributs suivant ce que l'on décide de mettre en propriété. Cela ne t'empêche pas de faire ce que tu veux (elles n'ont rien d'obligatoire), et permet de méchamment simplifier des interfaces qui pourraient devenir franchement infectes. Bref, où est le problème ??

Le problème c'est que, perdu que tu est dans ta défense des propriétés, tu ne vois pas le problème. Tu le dis toi même, la sémantique des accesseurs/mutateurs et celle des propriétés sont quasi-identique. Un peu d'historique ici ou de lecture de mon blog montre que je n'aime pas non plus les accesseurs. J'ai, je pense, des bonnes raisons de ne pas les aimer.

Là, j'ai l'impression de voir un remake du bon vieux troll "caster le malloc en C" : on hurle sur quelque chose qui ne gêne que les puristes, simplifie la vie des utilisateurs (et je rappelle que l'on code pour que ce soit utilisé, hein, pas pour mettre en vitrine), et pour lesquels les "désavantages" sont des problèmes largement plus issus de la conception que de l'implémentation...

Ben justement, mon métier à moi c'est plus la conception que l'implémentation. L'implémentation vient en second, et elle est relativement simple si la conception est solide. De même, toujours si la conception est solide, le résultat sera non seulement simple d'utilisation mais aussi logique et (j'y reviens) expressif. Mon idéal est une librairie dont l'utilisation ne nécessite pas de commentaires dans le code client. Son interface doit être complètement explicite. Si son utilisation implique des cas d'erreur, elle doit faire en sorte que le maximum soit détectée au moment de la compilation.

J'obtiens des résultats que je juge substantiellement de meilleure qualité que le code que j'ai l'habitude de voir ici et là. Et, par un hasard que je ne saurais expliquer, mes clients disent la même chose. Mes clients se foutent des choix technico-philosophiques que je fais. Ca ne m'empêche pas de les faire, parce que ce faisant, je me simplifie le travail et je simplifie la tâche de ceux qui vont utiliser mon travail.

Alors non, on ne débat pas de choses qui n'intéresse que les puristes. On débat de choses qui intéressent tout le monde parce qu'elles touchent aux notions les plus profondes de l'architecture et la programmation professionnelle, mais le message se perd aisément, noyé qu'il est sous les remous provoqués par ceux qui ne perçoivent pas les raisons sous-jacente à ce débat. Au final, oui, ça devient un combat de puriste, parce qu'il faut sans cesse aller expliquer le moindre petit mot utilisé, la moindre formulation, la moindre base d'idée, et sans cesse relier le sujet à d'autres qui n'ont pourtant que peu de relations avec lui, tout ça pour n'arriver à rien - parce que ceux que ça pourrait intéressé ne peuvent plus suivre la conversation, et ceux que ça n'intéresse pas du tout veulent absolument la continuer, histoire de prouver que leur manière de faire est suffisamment bonne.

Si vous jugez votre manière de faire suffisamment bonne, continuez à faire comme vous le souhaitez.

Si vous souhaitez améliorer vos pratiques mais que pour une raison X ou Y vous ne le pouvez pas, ça ne vous empêche pas de garder au fond de votre esprit que les propriétés telles que C# (par exemple) les présente sont une fausse bonne idée. Quoi qu'en disent ceux qui les utilisent.

Et maintenant, il y a Dr House, donc je suis pris

[Lavock]

@ponce :
Merci bien pour ses infos. On peut donc considérer que, à défaut d'être meilleur ou pire, D est surtout un nouveau langage. D'après ce qui s'en dit, je préfère mon bon vieux C++, mais j'espère que D remplacera quelques autre langage que je juge "poubellitique" >< !

[deadalnix]

c'est plutot expressif, non

Ou comment faire des conteners, mais quand même utiliser un truc qui marche comme les pointeurs (n'est pas plus safe d'ailleurs) mais plus long à écrire.

Je te renvoie à la conf iterrator must go si tu veux avoir une idée de mon point de vue. Je trouve l'approche des slices (intégrée dans D) bien plus intelligentes. Et ayant les mêmes qualités de généricité que les iterrator. C'est juste moins verbeux et plus safe.

Code :

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

1
2
3
4
A[] tab;
foreach(ref a; tab){
    //. . .
}

C'est quand même bien plus concis souple, et en plus, c'est safe.

[deadalnix]

Au passage, parmis les choses que j'apprécie en D, c'est la possibilité de coder les test en même temps que le code facilement. Ça permet de faire les choses bien. On a une batterie d'outils interessants pour ça :
- unittest
- invariant
- in/out

[Goten]

Ou comment faire des conteners, mais quand même utiliser un truc qui marche comme les pointeurs (n'est pas plus safe d'ailleurs) mais plus long à écrire.

Je te renvoie à la conf iterrator must go si tu veux avoir une idée de mon point de vue. Je trouve l'approche des slices (intégrée dans D) bien plus intelligentes. Et ayant les mêmes qualités de généricité que les iterrator. C'est juste moins verbeux et plus safe.

Code :

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

1
2
3
4
A[] tab;
foreach(ref a; tab){
    //. . .
}

C'est quand même bien plus concis souple, et en plus, c'est safe.

La sémantique de pointeur est voulue, avec que tu le veuilles ou non plus de "safety". Et les iterators ne sont pas propres au C++ après tout, c'est juste un DP du GoF comme un autre. Sa veut pas dire qu'ils sont parfait loin de là, je suis d'accord avec pas mal de points qu'avancent Alexandreiscu, mais son concept de range n'est pas non plus parfait et à l'heure actuelle je suis pas sur que ça réponde a tout les besoins en C++..
Bref, j'ai relu le topic, y'a énormément de mauvaise foi, pas mal _et sa, ça me surprend_ d'attaques personnelles (on peut ne pas avoir les mêmes opinions aimaient sa technologie sans se foutre sur la gueule non?).
Et je rejoins lavock, ça part en digression sur une feature unique (voir un panel de feature) alors que la question de départ est est ce que le D a de l'avenir face au C++...

[deadalnix]

Je sais bien que la sémantique de pointeur est voulue. Et ça me parrait naturel d'un point de vue historique, les idée qui sont proche de ce que l'on connais viennent d'abords.

C'est justement le genre de truc dont on peut se rendre compte, avec le recul, que ce n'était pas des si bonnes idées que cela.

Je crois que c'est ça finalement la force du D. Se servir des expérience passée pour proposer autre chose de mieux. Quelque chose qui s'exprime de façon concise, qui limite le risque d'erreurs, et qui est intelligible intellectuellement.

[Invité]

la question de départ est est ce que le D a de l'avenir face au C++...

Face au C++, probablement pas.
Face à d'autres langages, peut-être.

[Goten]

Je sais bien que la sémantique de pointeur est voulue. Et ça me parrait naturel d'un point de vue historique, les idée qui sont proche de ce que l'on connais viennent d'abords.

C'est justement le genre de truc dont on peut se rendre compte, avec le recul, que ce n'était pas des si bonnes idées que cela.

Je crois que c'est ça finalement la force du D. Se servir des expérience passée pour proposer autre chose de mieux. Quelque chose qui s'exprime de façon concise, qui limite le risque d'erreurs, et qui est intelligible intellectuellement.

Et là je peux qu'être d'accord avec toi. Beaucoup de choses qui auraient pu paraitre trop radicale et qui sont adopté parce qu'on sait que c'est mieux.. et c'est une bonne chose. C'est aussi peut être ce qui fait que D "fera peur", tout comme à l'heure actuelle le C++ moderne (je parle de traits / policies et autre technique à base de templates) peut faire peur en entreprise...

ps : ce topic aura au moins servi à me donnée une furieuse envie de me pencher plus sur le D. (j'attends avec impatience le bouquin d'AA.)