String - Surdéfinition de l'opérateur(+)

Bonjour,

Je débute en Java, pas tout à fait, j'ai lu et fais la majorité des exemples de "Programmer en Java" de Claude D.

Ma question portant sur l'opérateur (+).
Pourquoi est-il possible d'écrire le code suivant ?

String s1 = new String("Bonjour ");
String s2 = new String("monsieur");

String s3 = s1 + s2;

En me référant à mes connaissances du C++, il semble que pour la classe String, l'opérateur (+) est surdéfini.

Si tel est le cas, quel est le prototype de cette surdéfinition ?
Dans le cas contraire, en vertue de quoi cette écriture est-elle possible ?

Merci d'avance.
Cordialement

Il n'y a pas de surcharge d'opérateur en java.

L'addition de deux String fait partie des specifications du langage

Tout d'abord merci de votre réponse.

Je poursuis ... pour comprendre.

String est une classe comme une autre, ce n'est donc pas un type de base de Java.

Pourquoi l'addition de deux String fait-elle partie des spécifications ?

Merci d'avance.

Cordialement

la classe String est un cas particulier. Son usage est tellement courant qu'elle a eu droit a certain petit bonus par rapport aux classes normales.

un objet de classe String est immuable, donc toute actions ou methodes dessus te renvoi un nouvel objet de classe String.

si je me plante pas :

Code:

---

1 2	String s3 = s1 + s2;

---

c'est la meme chose que ca :

Code:

---

1 2	String s3 = new StringBuffer(s1).append(s2).toString();

---

La classe String fait partie du specification du langage, comme la classe Object par exemple (cf §4.3.3 des specifications du langage).
L'operateur + sur String est decrit dans le §15.18.1

Utiliser l'operateur + sur les String peut amener java, en théorie, a creer des String intermediaires. Par exemple, en ecrivant a+b+c, on a une string de creer pour a+b, puis pour l'addition du resultat de a+b avec c.
Une recommandation de la spec préconise que le compilateur remplace dans ce cas l'operation par l'utilisation de StringBuffer, comme l'a ecrit eclesia.

Voila un lien sur les specs du langage : ici

Tu y trouveras d'autres subtilités comme par exemple l'outboxing.

Bonsoir,

Merci à tous les deux.

A bientôt, très certainement pour d'autres questions.

Cordialement.:lol:

je suis pas sur a 100% mais je tente quand meme :
String s3 = new String (a.concat(b) );
ou a et b sont deux autres chaines
désolé pour les fautes s'il y en a:?

Citation:

---

Envoyé par Sanguko

Une recommandation de la spec préconise que le compilateur remplace dans ce cas l'operation par l'utilisation de StringBuffer, comme l'a ecrit eclesia.

---

C'est quelques chose qu'il faut garder a l'esprit quand on concatene beaucoup de chaines : il ne s'agit que d'une recommandation. Le compilateur de Sun la suit, mais le compilateur d'un kit de devel d'un autre vendeur ou d'une JVM qui serait plus conservatrice sur la quantite d'objets crees (ex : sur mobile) pourrait ne pas la suivre. C'est pour cela qu'il faut quand meme faire attention a l'utilisation du + et quand il y en a trop preferer l'utilisation manuelle (et bien controlee, il ne faut pas non-plus faire n'importe quoi avec) des StringBuilder/StringBuffer.

Bonjour bouye,

Sauf le respect, votre réponse est hors sujet, eu égard à ma question initiale.

Ce qui me préoccupe en tant que "vieux" développeur, débutant en Java, c'est l’orthogonalité de ce langage.
En effet, la surcharge des OPERATOR est, à mon humble avis, bien plus fondamentale que la surcharge des méthodes relativement au concept d’abstraction de données qui précède le concept de l’orientée objet.

Je trouve donc dommage de laisser à penser que la surcharge des opérateurs fait partie du langage alors que ce n’est qu’un cas particulier de la classe String.

Ce n’est pas bien gênant, le Java a bien d’autres attraits.

Cordialement.

Ce topic pouvant etre lu par d'autres personnes, y compris des debutants, cette remarque tendait a montrer du doigt un des points faibles de la specification (et de toutes les specifications en general) : cette "optimisation" est optionnelle et laissee a la discretion et a la charge de l'implementeur du compilateur.

Donc dans un code standard, lors d'une mauvaise utilisation du "+", cela peut ammener de mauvaises performances du programme (creation d'un enorme nombre d'objet, etc...) suivant le compilateur utilise (toutes les platformes n'utilisent pas le compilateur de Sun, bien au contraire). Il ne faut donc pas prendre l'usage du "+", lors de la concatenation de deux chaines, a la legere.

Concernant la surcharge des operateurs en general (pas forcement sur la class String), une modification de celle-ci est envisagee pour Java 7 ou une version ulterieure mais pour permettre les operations sur les BigDecimal, voir http://tech.puredanger.com/java7#bigdecimal

Citation:

---

Envoyé par bouye

C'est quelques chose qu'il faut garder a l'esprit quand on concatene beaucoup de chaines : il ne s'agit que d'une recommandation.

---

Tout à fait d'accord.

Citation:

---

Envoyé par bouye

Le compilateur de Sun la suit, mais le compilateur d'un kit de devel d'un autre vendeur ou d'une JVM qui serait plus conservatrice sur la quantite d'objets crees (ex : sur mobile) pourrait ne pas la suivre.

---

Je suis un peu étonné qu'il y ait des compilateurs java spécifiques pour mobile. Tu penses à un compilateur en particulier? En général, c'est les packages et la vm qui sont spécifiques.

Citation:

---

Envoyé par bouye

C'est pour cela qu'il faut quand meme faire attention a l'utilisation du + et quand il y en a trop preferer l'utilisation manuelle (et bien controlee, il ne faut pas non-plus faire n'importe quoi avec) des StringBuilder/StringBuffer.

---

A noter qu'il existe des outils (PMD, FindBugs, ...) qui permettent de trouver les erreurs les plus courantes, et notamment les creations d'objet inutiles.

Citation:

---

Envoyé par slashbrus

Ce qui me préoccupe en tant que "vieux" développeur, débutant en Java, c'est l’orthogonalité de ce langage.
En effet, la surcharge des OPERATOR est, à mon humble avis, bien plus fondamentale que la surcharge des méthodes relativement au concept d’abstraction de données qui précède le concept de l’orientée objet.

Je trouve donc dommage de laisser à penser que la surcharge des opérateurs fait partie du langage alors que ce n’est qu’un cas particulier de la classe String.

---

J'ai fait du C++, et honnêtement, la surcharge des operateurs a été plus un handicap qu'un atout. Cette surchage a toujours nécessité la définition de règles, voir de vérifications automatiques.
En java, ca ne m'a pas manqué, mais je n'ai jamais eu à traiter les BigDecimal, ni d'ailleurs des complexes.

Citation:

---

Envoyé par Sanguko

Je suis un peu étonné qu'il y ait des compilateurs java spécifiques pour mobile. Tu penses à un compilateur en particulier? En général, c'est les packages et la vm qui sont spécifiques.

---

Dans les specs il n'y a aucune obligation sur l'implémentation (si ce n'est produire un résultat final identique) : http://java.sun.com/docs/books/jls/t...html#15.18.1.2

Donc c'est fort possible...



Attention toutefois car l'opérateur + n'est pas à proscrire, et il ne correspond pas forcément à l'utilisation de StringBuffer/StringBuilder...

En effet le compilateur peut effectuer aussi des optimisations à la compilation en concaténant les constantes (chaines ou numériques connus à la compilation). Ainsi par exemple le code suivant :

Code:

---

1 2	String str1 = "A" + "B"; String str2 = "PI = " + Math.PI; // Math.PI est une constante

---

Est strictement identique au code suivant (avec le compilateur de Sun, mais surement aussi avec la plupart des compilateur) :

Code:

---

1 2	String str1 = "AB"; String str2 = "PI = 3.141592653589793";

---

:arrow: Plus aucune concaténation à l'exécution !

Citation:

---

Envoyé par Sanguko

J'ai fait du C++, et honnêtement, la surcharge des operateurs a été plus un handicap qu'un atout. Cette surchage a toujours nécessité la définition de règles, voir de vérifications automatiques.
En java, ca ne m'a pas manqué, mais je n'ai jamais eu à traiter les BigDecimal, ni d'ailleurs des complexes.

---

Pour moi il y a 2 gros domaine où la surcharge est vraiment intérressante :

• Pour la concaténation de String bien sûr...
• Pour la manipulation des valeurs numériques, avec les opérations de bases (ajout/suppression, multiplication/division , comparaison).

L'absence de ce second cas peut-être "problématique" en Java lorsqu'on manipule des nombres avec des BigDecimal...

Sinon les autres surcharges ne sont vraiment utile que de manière anecdoctique et sont plus souvent source de "problème"...


a++

Citation:

---

Envoyé par adiGuba

Dans les specs il n'y a aucune obligation sur l'implémentation (si ce n'est produire un résultat final identique) : http://java.sun.com/docs/books/jls/t...html#15.18.1.2
Donc c'est fort possible...

---

Si tu parles du resultat à l'execution, ok. Le bytecode est différent d'un compilateur à l'autre.

L'objet de ma remarque était plutot de la curiosité. Je ne connais les compilateurs :javac, jikes (et gcj), utilisables pour J2ME, JSE ou JEE. J'étais curieux de savoir s'il en existait d'autres.

Citation:

---

Envoyé par Sanguko

Si tu parles du resultat à l'execution, ok. Le bytecode est différent d'un compilateur à l'autre.

---

Oui oui je parle bien du résultat final à l'exécution et non pas du bytecode généré par le compilateur ;)

a++

A priori, les JVM/JDK fournis par SGI, HP, Apple, IBM, etc... non-seulement pour leurs OS respectifs mais aussi parfois en version Windows n'utilisent pas le javac (et autres outils de compilation) de Sun, ce qui parait normal puisque Sun ne fourni javac que pour les JVM qu'ils produisent eux : Windows 32/64, Linux 32/64 et Solaris x86 et Sparc.

Mac OS utilise javac

Oui, .......................... fait par Apple. Ce n'est pas parce qu'un programme s'appelle javac qu'il vient automatiquement de chez Sun. Fut un temps IBM produisait egalement des JDK pour Windows et leur compilateur donnait des optimisations (et parfois egalement des bugs) differents de celui de Sun. Leur JVM etait egalement plus veloce ; a l'epoque de la 1.3.x, je preferrais develloper sur leur JDK et utiliser leur VM pour l'execution car c'etait bien plus rapide que chez Sun.

j'avais zappé le "de Sun" dans ton post.. :/

Un compilateur java n'utilisant pas de ressources spécifiques à un système, j'imagine qu'il s'agit pour la plupart des cas (en tout cas pour les Unix) d'un portage d'un compilateur existant (sauf pour IBM).