> ...le problème vient du fait que beaucoup de gens travestissent l'usage initial des opérateurs, [...]. Dans mon cas, « << » sert réellement à décaler mon objet vers la gauche
C'est quoi "l'usage initial" de l'opérateur "<<" ?
Car dire que c'est "décaler un objet vers la gauche" n'est pas super précis et ne peut etre une spécification.
De plus regarde "cout" et "cin", on ne peut pas dire aussi simplement que l'on décale la "sortie" vers la gauche ou "l'entrée" vers la droite (a part en approximant d'un facon plus que douteuse ...).
Il y à eu un long thread sur la mailling list de SmallEiffel sur la surcharge d'oppérateur pour info ...
Mon avis perso: La surcharge d'opérateur ca à l'air super mais il faut voir un peu plus loin ... Si a chaque signe "+" ou "<<" je doit recomprendre ce qu'a fait le concepteur, ca va etres ingérable. Garder cette surcharge à un nombre limité de cas et au plus courant me semble le meilleur copromis (String est dans ce cas).
> Le Java [...], mais bon nombre de facette du développement objet ont été volontairement éllipsés ...
au passage: s/éllipsés/eclipsés ... et sans jeux de mots ;)
> surcharge des opérateurs ...
C'est discutable, la surcharge existe pour le type le plus "lourd" (String). Ajouter ce comportement pour une infime partie des besoins réel n'était peut-etres pas leur objetifs premier ...
(au passage, la surcharge d'opérateur n'est pas un facette du "développement objet")
>...héritage multiple ...
La il y a aussi des problèmes "techniques": Ajouter l'héritage multiple aurrait obligé d'ajouter un mécanisme pour solutionner les problèmes qu'il apporte (à moins de ne riens faire comme en C++, mais bon a partir d'un moment fau etres sérieux ...), du coup le tout aurrait peut-etres était un peu lourd pour un langage ce voulant simple ...
Ensuite l'implémentation de l'héritage multiple est un peu plus couteuse en termes de ressources
donc il ont dut effectuer un choix ...
> ...template ...
La c'est clair qu'ils ce sont méchament gofré les gars ...
(au passage, la généricitée n'est pas un facette du "développement objet")
[^] # Re: Problèmes de compilation g++ (suite)
Posté par thecat . En réponse au journal Problèmes de compilation g++ (suite). Évalué à 0.
C'est quoi "l'usage initial" de l'opérateur "<<" ?
Car dire que c'est "décaler un objet vers la gauche" n'est pas super précis et ne peut etre une spécification.
De plus regarde "cout" et "cin", on ne peut pas dire aussi simplement que l'on décale la "sortie" vers la gauche ou "l'entrée" vers la droite (a part en approximant d'un facon plus que douteuse ...).
Il y à eu un long thread sur la mailling list de SmallEiffel sur la surcharge d'oppérateur pour info ...
Mon avis perso: La surcharge d'opérateur ca à l'air super mais il faut voir un peu plus loin ... Si a chaque signe "+" ou "<<" je doit recomprendre ce qu'a fait le concepteur, ca va etres ingérable. Garder cette surcharge à un nombre limité de cas et au plus courant me semble le meilleur copromis (String est dans ce cas).
> Le Java [...], mais bon nombre de facette du développement objet ont été volontairement éllipsés ...
au passage: s/éllipsés/eclipsés ... et sans jeux de mots ;)
> surcharge des opérateurs ...
C'est discutable, la surcharge existe pour le type le plus "lourd" (String). Ajouter ce comportement pour une infime partie des besoins réel n'était peut-etres pas leur objetifs premier ...
(au passage, la surcharge d'opérateur n'est pas un facette du "développement objet")
>...héritage multiple ...
La il y a aussi des problèmes "techniques": Ajouter l'héritage multiple aurrait obligé d'ajouter un mécanisme pour solutionner les problèmes qu'il apporte (à moins de ne riens faire comme en C++, mais bon a partir d'un moment fau etres sérieux ...), du coup le tout aurrait peut-etres était un peu lourd pour un langage ce voulant simple ...
Ensuite l'implémentation de l'héritage multiple est un peu plus couteuse en termes de ressources
donc il ont dut effectuer un choix ...
> ...template ...
La c'est clair qu'ils ce sont méchament gofré les gars ...
(au passage, la généricitée n'est pas un facette du "développement objet")