Discussion :

[Garulfo]

[...]
parce qu'une fois qu'on a acquis certaines connaissances, le langage peut être vu comme un "détail" syntaxique

Ca dépend pas mal du langage et des connaissances préalables tout de même... [...]

Je suis en accord avec vous deux. Le but d'un bacc (d'une licence pour la France) est de préparer ces connaissances préalables de toutes façons à l'acquisition des langages. Un tel diplôme universitaire forme à comprendre et assimiler les concepts et non à apprendre tel ou tels langages, ce qui est en soi inutile — ça devient un « détail syntaxique » — et impossible — il y a trop à apprendre pour maîtriser un langage en trois ans même à temps complet. Le background est aussi important. D'ailleurs, autant il peut nous apporter — je connais C, C++, Java, Objective-C… passer à C# ne devrait pas être trop difficile — autant il peut être une plaie — je fais de l'impératif 24h/24, difficile de me mettre au fonctionnel —; sans parler des éventuelles mauvaises habitudes qui sont toujours plus difficiles à perdre que les bonnes habitudes. Et là je parle aussi en connaissance de cause

[hegros]

Ne te focalise pas sur le System qui est une classe, et non une instance. Elle définit, au même titre que std en C++ un espace de nommage, dont l'attribut public 'out' est constant (final). D'ailleurs en java 1.5 il est possible d'écrire cela :

Code :

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

1
2
3
4
5
6
7
8
import static java.lang.System.out;

public class Toto {
public static void main(String[] args) {
    out.println("Hello world");
}
}

Il est difficile de dire que System est au même titre que l'espace de nommage en C++ d'une part parce que System.java définit une classe System, certes final et static, et d'autre part parce que pour ma part l'équivalent de l'espace de nommage en JAVA c'est le package. Enfin c'est une façon de concevoir les espaces de noms avec les classes et membre final et static en java qui est partagé ?

Aussi, que la donnée membre soit constante ou finale cela ne change rien dans l'absolu. C'est le fait qu'elle soit static qui change effectivement la conception parce que sinon se serait une violation pure et simple du principe de l'encapsulation. Les accesseurs et mutateurs s'est une façon transparente de briser l'encapsulation (il y en a qui ont autant de accesseurs/mutateurs que de données membre mais dans ce cas autant tout mettre public et évitez le verbage)sauf pour un certain nombre de cas comme les DTO et les EJB ?

[koala01]

Ca dépend pas mal du langage et des connaissances préalables tout de même... Je suis relativement sûr que je serais capable de maitriser bien plus que les bases de C# en une trentaine d'heure, alors qu'un programmeur moyen issu d'une Java school essayant d'apprendre Haskell mettra bien plus qu'une trentaine d'heure avant d'acquérir un sens basique du langage.

(NB : je ne suis pas un surhomme, j'ai juste une connaissance de C, Java et un éventail relativement large de langages exotiques (dont certains dont C# s'est inspiré pour ses fonctionnalités "originales", Haskell entre autres), une fondation en algorithmique et structures de données, ainsi que des bonnes bases théoriques et pratiques en théorie des langages)

--
Jedaï

Effectivement, le temps d'apprentissage "des bases" est fortement dépendant des connaissances préalables...

Mais, là où je voulais surtout en venir (pour mettre Alp et Hergos d'accord), c'est qu'il y a une belle différence entre "connaitre les bases", voire "se sentir à l'aise" avec un langage et pouvoir considérer "qu'on le maitrise", et surtout qu'on ne peut pas décemment attendre d'une personne qui sort des études de maitriser réellement l'ensemble des langages qu'il a pu croiser durant celles-ci

Ce n'est pas un problème ni d'enseignant ni d'étudiant, c'est parce que, avec en moyenne 34 à 36 semaines de cours par an, il est difficile d'étudier un langage particulier "en profondeur"

[Alp]

Effectivement, le temps d'apprentissage "des bases" est fortement dépendant des connaissances préalables...

Mais, là où je voulais surtout en venir (pour mettre Alp et Hergos d'accord), c'est qu'il y a une belle différence entre "connaitre les bases", voire "se sentir à l'aise" avec un langage et pouvoir considérer "qu'on le maitrise", et surtout qu'on ne peut pas décemment attendre d'une personne qui sort des études de maitriser réellement l'ensemble des langages qu'il a pu croiser durant celles-ci

Ce n'est pas un problème ni d'enseignant ni d'étudiant, c'est parce que, avec en moyenne 34 à 36 semaines de cours par an, il est difficile d'étudier un langage particulier "en profondeur"

Sauf que tu ne nous mets pas d'accord.
Le point d'hegros était que +- tous les profs n'apportent rien, n'enseignent pas vraiment quelque chose de significatif, ce à quoi j'ai fait objection.

[kpouer]

Si il y a un point positif du C++ qui a été perdu(et qui ne sera probablement pas récupéré par la suite) en Java c'est bien la surcharge des opérateurs.

Question de point de vue, de l'autre coté en java quand tu fais un + tu sais exactement ce que ca va faire, quand tu fais un = tu sais exactement ce qui se passe, en c++ tu ne le maitrise pas (si tu utilise une librairie que tu n'as pas fait toi même je veux dire), il peut y avoir toute une tringlerie derrière sans que tu n'en ai la moindre idée.
Ca a des avantages mais aussi des inconvénients je trouve

Il est difficile de dire que System est au même titre que l'espace de nommage en C++ d'une part parce que System.java définit une classe System, certes final et static, et d'autre part parce que pour ma part l'équivalent de l'espace de nommage en JAVA c'est le package. Enfin c'est une façon de concevoir les espaces de noms avec les classes et membre final et static en java qui est partagé ?

Pas tout a fait, dans un package tu ne peux pas déclarer de variables, tu ne peux déclarer que des classes, donc une classe peut être aussi comparée a un espace de nommage pour des constantes

[Alp]

Question de point de vue, de l'autre coté en java quand tu fais un + tu sais exactement ce que ca va faire, quand tu fais un = tu sais exactement ce qui se passe, en c++ tu ne le maitrise pas (si tu utilise une librairie que tu n'as pas fait toi même je veux dire), il peut y avoir toute une tringlerie derrière sans que tu n'en ai la moindre idée.
Ca a des avantages mais aussi des inconvénients je trouve

Tout comme n'importe quelle fonction/classe. Si tu n'as pas la doc, ou les commentaires, aucun moyen d'être sûr de ce qu'elle fait.
Imagine une fonction membre "connecte()" qui retournerait un booléen.
Est-ce qu'elle permet de dire si tu es connecté, ou alors essaye-t-elle de se connecter quelquepart et retournait true si elle y arrive, false sinon ?

En C++, tu peux écrire +,- pour des vecteurs et l'intégrer directement. Tu peux assigner des vecteurs, utiliser +=, et j'en passe.

Tu ne peux pas dire que c'est inutile ou dangereux. Le seul risque c'est le manque de documentation, mais en général, dans un contexte professionnel ou dans un contexte opensource, tu disposes de la doc nécessaire, voir de developer guide, etc.

[hegros]

Pas tout a fait, dans un package tu ne peux pas déclarer de variables, tu ne peux déclarer que des classes, donc une classe peut être aussi comparée a un espace de nommage pour des constantes

Tu pourrais nous refaire ton raccourci en ralenti, c'est le passage une classe constante = espace de nommage parce qu'en C++ dans un espace de nommage cette particularité du tout en statique n'existe pas donc est-ce vraiment comparable ? A mon avis non.

Aussi pour l'illisibilité de code ce n'est pas lié à la surcharge d'un opérateur, puisque cela peut largement l'améliorer selon le contexte, mais au programmeur c'est trés pratique ou plus amusant d'écrire voiture+=moteur; que d'écrire à la sauce java voiture.setMoteur(moteur); (l'exemple est bidon mais cela peut-être plus facile à écrire ou maintenir...)

[Luc Hermitte]

Question de point de vue, de l'autre coté en java quand tu fais un + tu sais exactement ce que ça va faire, quand tu fais un = tu sais exactement ce qui se passe

Bien essayé, mais mauvais exemples. [100 pages, on va bientôt y arriver. On le tient le troll!]

+ est surchargé en Java pour faire autre chose qu'additionner des entiers.

Quant à =, cela me rappelle cette vieille polémique... (ou encore...). Peut-on vraiment dire que l'on sait ce que cela fait devant l'ignorance des plus répandues relative aux mécanismes véritablement mis en œuvre ? Oui, le mécanisme est simple, c'est le même qu'en C. Mais combien l'ont véritablement compris ?

[kpouer]

Tout comme n'importe quelle fonction/classe. Si tu n'as pas la doc, ou les commentaires, aucun moyen d'être sûr de ce qu'elle fait.
Imagine une fonction membre "connecte()" qui retournerait un booléen.
Est-ce qu'elle permet de dire si tu es connecté, ou alors essaye-t-elle de se connecter quelquepart et retournait true si elle y arrive, false sinon ?

En C++, tu peux écrire +,- pour des vecteurs et l'intégrer directement. Tu peux assigner des vecteurs, utiliser +=, et j'en passe.

Tu ne peux pas dire que c'est inutile ou dangereux. Le seul risque c'est le manque de documentation, mais en général, dans un contexte professionnel ou dans un contexte opensource, tu disposes de la doc nécessaire, voir de developer guide, etc.

Ben au moins en java quand je fais = je suis certain que je vais pas dupliquer un objet en mémoire, je suis sur du cout de l'appel, je ne dis pas que ca peut être pratique de surcharger les opérateurs mais ca a aussi des défauts

Tu pourrais nous refaire ton raccourci en ralenti, c'est le passage une classe constante = espace de nommage parce qu'en C++ dans un espace de nommage cette particularité du tout en statique n'existe pas donc est-ce vraiment comparable ? A mon avis non.

ce que j'ai dit c'est que on ne peut pas dire namespace = package puisque dans un package on ne peut pas déclarer de variables, je dis qu'une classe peut s'apparenter a un namespace dans le sens ou on peut y créer des variables, mais s'apparenter ne veut pas dire strictement identique bien sur

Bien essayé, mais mauvais exemples. [100 pages, on va bientôt y arriver. On le tient le troll!]

+ est surchargé en Java pour faire autre chose qu'additionner des entiers.

Ca n'a rien d'un troll, le + n'est pas surchargeable par un programmeur en java, on sait exactement ce qu'il fait pour les nombres et pour les objets

Quant à =, cela me rappelle cette vieille polémique... (ou encore...). Peut-on vraiment dire que l'on sait ce que cela fait devant l'ignorance des plus répandues relative aux mécanismes véritablement mis en œuvre ? Oui, le mécanisme est simple, c'est le même qu'en C. Mais combien l'ont véritablement compris ?

euh si je prend le cas du c++, dès qu'on manipule un objet et non plus son pointeur ca devient beaucoup moins simple puisqu'on passe par l'opérateur = qui aura peut être été surchargé non ?
edit: sinon cet article sur javadude pour moi c'est un peu de l'ergotage et de l'enfonçage de portes ouvertes, si un développeur java ne sait pas comment fonctionnent les passages de variables et affectations c'est grave.
D'ailleurs c'est souvent des questions que me posent des développeurs c/c++ devant se mettre au java, comment passer une référence en paramètre pour qu'une fonction y colle un objet, bref appliquer les méthodes d'un autre langage au java

[Furikawari]

edit: sinon cet article sur javadude pour moi c'est un peu de l'ergotage et de l'enfonçage de portes ouvertes, si un développeur java ne sait pas comment fonctionnent les passages de variables et affectations c'est grave.

hmm là je pense que tu te fourres le doigt dans l'oeil et que nombre de programmeurs java ne se sont même pas posés la question. Même si ça peut te paraître aberrant (pour moi ça l'est en tout cas ) beaucoup de "programmeurs" ne se posent pas de questions sur les mécanismes mis en oeuvre par le langage qu'ils utilisent (pour java comme pour tous les langages), et c'est une des raisons qui font que tant de mauvais code voit le jour...

[kpouer]

Ah ba oui mais si on prend comme exemple des développeurs incompétents pour comparer les langages on s'en sort pas

[Alp]

Ah ba oui mais si on prend comme exemple des développeurs incompétents pour comparer les langages on s'en sort pas

Pourtant ce seraient le même genre de développeurs qui seraient pas foutus de comprendre ce que fait telle surcharge d'opérateur en C++ Ou qui mettraient le bazar dans la gestion de mémoire d'un programme C++...

[kpouer]

Pourtant ce seraient le même genre de développeurs qui seraient pas foutus de comprendre ce que fait telle surcharge d'opérateur en C++ Ou qui mettraient le bazar dans la gestion de mémoire d'un programme C++...

Qui foutrai le bazard dans la gestion de mémoire oui probablement, qui ne comprend pas ce que fait une surcharge d'opérateur je suis pas d'accord.
C'est pas une question de ne pas comprendre c'est une question de ne pas avoir l'information, c'est pas la même chose

[Alp]

Qui foutrai le bazard dans la gestion de mémoire oui probablement, qui ne comprend pas ce que fait une surcharge d'opérateur je suis pas d'accord.
C'est pas une question de ne pas comprendre c'est une question de ne pas avoir l'information, c'est pas la même chose

J'applaudis ta mauvaise foi

L'information on ne te la cache pas. Suffit que le mec cherche dans la doc. S'il ne le fait pas, c'est qu'il n'est pas rigoureux ou qu'il n'en a rien à faire, auquel cas il a choisi le mauvais métier.

[kpouer]

J'applaudis ta mauvaise foi

Si tu le prend comme ca c'est pas la peine de discuter

[Alp]

Si tu le prend comme ca c'est pas la peine de discuter

Sincèrement, une surcharge d'opérateur, c'est un cas particulier de la surcharge de fonctions. C'est documenté au même titre que les fonctions. Je ne vois pas pourquoi ça serait de la faute du langage ou de quelqu'un/quelque chose d'autre que le développeur s'il ne va pas regarder ce qu'il fait (au passage, en général c'est soit très bien documenté, soit évident, soit les deux... un opérateur + surchargé pour les nombres complexes, y'aura pas de grandes surprises, il n'essaiera pas de sérialiser puis envoyer un nombre complexe par le réseau, ou toute autre chose de ce genre...)/

[hegros]

ce que j'ai dit c'est que on ne peut pas dire namespace = package puisque dans un package on ne peut pas déclarer de variables, je dis qu'une classe peut s'apparenter a un namespace dans le sens ou on peut y créer des variables, mais s'apparenter ne veut pas dire strictement identique bien sur

Le package se rapproche plus de l'espace de nommage qu'une classe constante et static. Une classe c'est une classe. La particularité de l'espace de nommage c'est de regrouper des classes instanciables(pas toutes constante ou static) et c'est effectivement ce que permet de faire package.

[kisitomomotene]

Le package se rapproche plus de l'espace de nommage qu'une classe constante et static. Une classe c'est une classe. La particularité de l'espace de nommage c'est de regrouper des classes instanciables(pas toutes constante ou static) et c'est effectivement ce que permet de faire package.

Mais pourquoi spéculer sur ce qui est clair et précis? En java, une classe n'est pas seulement une "fabrique" d'objet, mais a aussi la fonctionnalité d'espace de nommage, exactement comme les packages. Donc une fonctionnalité commune aux packages et aux classes dans Java, c'est qu'ils peuvent servir d'espace de nommage.

[Uther]

Les namespace ne correspondent pas a la façon Java de découper un projet. La véritable notion de délimitation du code en différents espaces est en effet normalement la responsabilité des package en Java.
La notion de variable en dehors d'une classe n'existant pas en Java on a recours a un membre statique d'une classe. Donc en effet si on veut absolument recouper les fonctionnalités des namespace du C++, il faut tenir compte à la fois des packages et membres statique des classes.

Ce débat peut être sans fin : Java a sa logique et C++ la sienne. Vous avez tous les deux raison ou tord suivant que l'on regarde d'un point de vue d'un programmeur C++ ou Java.

Pour en revenir au sujet, cout est un objet de l'espace std, out est un membre statique final de la classe java.lang.System. Leur fonctionnement et leur encapsulation est donc quasiment identique.

[hegros]

Mais pourquoi spéculer sur ce qui est clair et précis? En java, une classe n'est pas seulement une "fabrique" d'objet, mais a aussi la fonctionnalité d'espace de nommage, exactement comme les packages. Donc une fonctionnalité commune aux packages et aux classes dans Java, c'est qu'ils peuvent servir d'espace de nommage.

C'est clair pour toi et tes camarades bravo félicitation c'est une question de partage de point de vue, je trouve plus élégant la façon dont en c++ avec la surcharge d'opérateur on peut simplement afficher un texte à l'écran tandis qu'en java l'approche est déjà relativement plus complexe à appréhender.

Aussi ce qui manque au C++, peut-être un option existe mais pas à ma connaissance, par rapport à JAVA c'est les exceptions obligatoires à traiter signalées par le compilateur.

Alors est-ce que cela a existé, existe ou existera prochainement ?

Exemple basic : dans le main appel d'une méthode d'une classe qui peut générer une exception en JAVA cela ressemblerait à

Code :

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

void m()throw MonException{throw new MonException("");}

Question : Est-ce que le compilateur c++ 'standard' me génère une erreur si dans le main il n'y a pas un bloc try-catch qui encadre comme dans par exemple

Code :

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

main(){ A a=new A(); a.m();return 0;}

avec m un code semblable au code JAVA au dessus.


Si cela n'est pas possible est-ce qu'il y a des explications et raisons qui ont guidés ce choix sinon est-ce que cela reste possible pour une extension d'un compilateur (il se pourrait bien que la réponse soit dans la faq)