C'est une question de point de vue, évidement. Pour ma part, j'aime le C++ parce qu'il me permet justement de faire ces choses là, et je trouve que c'est nécessaire lorsque l'on veut réellement définir de nouveaux types. Sinon ce ne sont que des fonctions et des structures, avec règles de nommage locales. Et en ce qui concerne les opérateurs, le problème vient du fait que beaucoup de gens travestissent l'usage initial des opérateurs, souvent à tort et à travers. Dans mon cas, « << » sert réellement à décaler mon objet vers la gauche.
Exemple, la concaténation des chaines en Java avec l'opérateur "+". Ce serait sympa de pouvoir exprimer un objet de la même façon sans avoir à systématiquement passer par un .getString(). Autre exemple - ambassadeur du développement C++ - : les nombres complexes. C'est typiquement un objet qui doit se comporter comme un réel lorsque sa partie imaginaire est nulle, et qui se mélange aux équations traditionnelles. C'est impossible à faire proprement en Java, dans lequel on se mélange déjà les pattes entre opérateur = et méthodes .equal() à cause des références, sans entrer dans un cas de figure comme le nôtre. Bref, le Java oriente très judicieusement le problème de façon à favoriser les cas de figures les plus courants, mais en aucun le résoud.
Le Java est un très bon langage en soi, et pour l'usage pour lequel il a été conçu (portabilité + rapidité de développement), mais bon nombre de facette du développement objet ont été volontairement éllipsés (surcharge des opérateurs, héritage multiple, template ...). L'effet pervers vient du fait que beaucoup de gens, aujourd'hui s'orientent Java parce que toutes les difficultés sont officiellement masquées par le standard. « L'héritage multiple finirait par poser trop de problème, spécialement si toutes les classes dérivent de Object. Pas de problème, on n'a qu'a interdire l'héritage multiple ! ». Soit, mais tôt ou tard, le travail devra être fait quand même, et inexorablement, on finira par rencontrer un problème équivalent.
[^] # Re: Problèmes de compilation g++ (suite)
Posté par Obsidian . En réponse au journal Problèmes de compilation g++ (suite). Évalué à 1.
C'est une question de point de vue, évidement. Pour ma part, j'aime le C++ parce qu'il me permet justement de faire ces choses là, et je trouve que c'est nécessaire lorsque l'on veut réellement définir de nouveaux types. Sinon ce ne sont que des fonctions et des structures, avec règles de nommage locales. Et en ce qui concerne les opérateurs, le problème vient du fait que beaucoup de gens travestissent l'usage initial des opérateurs, souvent à tort et à travers. Dans mon cas, « << » sert réellement à décaler mon objet vers la gauche.
Exemple, la concaténation des chaines en Java avec l'opérateur "+". Ce serait sympa de pouvoir exprimer un objet de la même façon sans avoir à systématiquement passer par un .getString(). Autre exemple - ambassadeur du développement C++ - : les nombres complexes. C'est typiquement un objet qui doit se comporter comme un réel lorsque sa partie imaginaire est nulle, et qui se mélange aux équations traditionnelles. C'est impossible à faire proprement en Java, dans lequel on se mélange déjà les pattes entre opérateur = et méthodes .equal() à cause des références, sans entrer dans un cas de figure comme le nôtre. Bref, le Java oriente très judicieusement le problème de façon à favoriser les cas de figures les plus courants, mais en aucun le résoud.
Le Java est un très bon langage en soi, et pour l'usage pour lequel il a été conçu (portabilité + rapidité de développement), mais bon nombre de facette du développement objet ont été volontairement éllipsés (surcharge des opérateurs, héritage multiple, template ...). L'effet pervers vient du fait que beaucoup de gens, aujourd'hui s'orientent Java parce que toutes les difficultés sont officiellement masquées par le standard. « L'héritage multiple finirait par poser trop de problème, spécialement si toutes les classes dérivent de Object. Pas de problème, on n'a qu'a interdire l'héritage multiple ! ». Soit, mais tôt ou tard, le travail devra être fait quand même, et inexorablement, on finira par rencontrer un problème équivalent.