Un doute existenciel a propos du parcours de liste dans une boucle 'for'

Alain Gaillard

28/09/2006 à 11:35

Vector<Integer> numbers = new Vector<Integer>(10, 10);
Object object = new String("toto");
numbers.add((Integer) object);

qui levera un CastClassException à l'exécution, parce qu'il y
a bien vérification dynamique.

C'est peu problable qu'on essaie d'optimiser du code qui lève
des exceptions. Surtout des RuntimeException. (Et ici, aussi,
l'exception a lieu en dehors de l'objet Vector<Integer>.)

Avant de parler optimisation (ce que de toutes façon le compilo ne fera
pas ;) tu trouves normal que ce code soit compilé. Tu parles d'une
généricité. Tu dit vector de Integer, tu lui balances une Steing et il
trouve ça normal....

Je remarque aussi qu'une fois de plus, ils n'ont pas appris des
erreurs du C++.

En effet bien que disant le contraire.

Ça fait longtemps, par exemple, qu'on sait que
le choit de <...> comme syntaxe n'est pas des plus heureux.

Ah ça...

En effet. Ça, je ne savais pas.

Si j'ai bien compris, ils ont adopté tout ce qui était mauvais
dans les templates C++ : la syntaxe <...> et la convention que
le paramètre soit un seul caractère majuscule, et ont ignoré
tout ce qui était intéressant, comme l'idée que le template
lui-même n'est pas un type, mais n'en devient un que quand il
est instantié.

Oui tu as très très bien compris.

--
Alain

Alain Gaillard

28/09/2006 à 11:37

Non sommes bien d'accord sur ce point.

Lire: Nous somme bien d'accord sur ce point

--
Alain

Jean-Marc Bourguet

28/09/2006 à 13:05

"kanze" writes:

Bref les génériques en java c'est plus de l'ordre du sucre
syntaxique qu'autre chose et on est bien loin de C++

Certes, mais pour d'autres raisons -- je ne crois pas qu'il
y a des paramètres non-type, ni des spécialisations
explicites, par exemple.

"spécialisation explicite" est un concept, paradigme, ..., C++
donc en effet on le rencontre en C++

C'est un concept qu'on retrouve effectivement en C++. Mais c'est
un concept assez général, qu'on pourrait aussi rétrouver dans
d'autres langages (peut-être sous un autre nom). Ça
m'étonnerait, d'ailleurs, qu'il ne soit pas présent dans
d'autres langages.

Je n'en connais pas (ni Eiffel, ni Ada, ni Modula-3, ni -- pour autant que
je le sache -- la famille ML; tous permettent une implémentation partagée,
bien qu'en Ada95 ce soit pénible). Je serais curieux de voir un autre
langage où c'est le cas.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

kanze

28/09/2006 à 18:28

Jean-Marc Bourguet wrote:

"kanze" writes:

Bref les génériques en java c'est plus de l'ordre du sucre
syntaxique qu'autre chose et on est bien loin de C++

Certes, mais pour d'autres raisons -- je ne crois pas qu'il
y a des paramètres non-type, ni des spécialisations
explicites, par exemple.

"spécialisation explicite" est un concept, paradigme, ..., C++
donc en effet on le rencontre en C++

C'est un concept qu'on retrouve effectivement en C++. Mais c'est
un concept assez général, qu'on pourrait aussi rétrouver dans
d'autres langages (peut-être sous un autre nom). Ça
m'étonnerait, d'ailleurs, qu'il ne soit pas présent dans
d'autres langages.

Je n'en connais pas (ni Eiffel, ni Ada, ni Modula-3, ni --
pour autant que je le sache -- la famille ML; tous permettent
une implémentation partagée, bien qu'en Ada95 ce soit
pénible). Je serais curieux de voir un autre langage où c'est
le cas.

Je n'en connais pas non plus, mais je sais qu'en général,
Stroustrup a préféré adopter les idées éprouvées que de se
lancer dans l'expérimentation spéculative. Et il n'y a
certainement rien dans le concept qui le rendrait impossible
dans d'autres langages.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Sylvain

28/09/2006 à 18:49

kanze wrote on 28/09/2006 10:18:

Le « JIT >>, c'est un nom commercial, publicitaire.

non!

Apparamment, Sun ne l'a pas protégé comme marque déposée, comme
je croyais, mais c'est bien une expression du marketing, qui ne
veut rien dire sur le plan technique.

"just in time", "compiler" ne veulent rien dire "techniquement" ??
tu nous fais pas un blocage là ?

Sun a introduit le 'JIT compiler' en 1997 (Juin 97) avec la version
1.1.3 du JDK et JRE; il était "commercialement" présenté comme le "Java
Performance Pack" (JPP), disponible alors que sous Win32.

A partir de la 1.1.6 (Mai 98), le JPP est remplacé par un simple add-on
("jit update") sous la forme d'une librarie (dll ou .so); à partir de la
1.1.7 (Aout 98) cette librairie est en standard dans le JDK ou JRE.

si tu veux signifier par "expression du marketting" le fait que le
marketting Sun devait faire face à cette époque à de nombreux griefs
concernant les performances d'une appli. Java, alors soit le JPP était
une blabla commercial ... basé sur un élément technique nommé JIT
compiler, qui - sans parler (ne les connaissant pas) des langages
expérimentaux - n'existait (ce JIT) nul part ailleurs.

qui levera un CastClassException à l'exécution, parce qu'il y
a bien vérification dynamique.

C'est peu problable qu'on essaie d'optimiser du code qui lève
des exceptions. Surtout des RuntimeException.

?!? si on en était capable on pourrait préférer, non optimiser un code
qui va planter, mais plutôt le détecter à la compil.

Et ici, l'exception a lieu en dehors de l'objet Vector<Integer>.

tout à fait.

Je remarque aussi qu'une fois de plus, ils n'ont pas appris des
erreurs du C++. Ça fait longtemps, par exemple, qu'on sait que
le choit de <...> comme syntaxe n'est pas des plus heureux.

heureux les tokens simples à écrire ...

C'est un concept qu'on retrouve effectivement en C++. Mais c'est
un concept assez général, qu'on pourrait aussi rétrouver dans
d'autres langages (peut-être sous un autre nom). Ça
m'étonnerait, d'ailleurs, qu'il ne soit pas présent dans
d'autres langages.

moi si (cela m'étonnerait).

Si j'ai bien compris, ils ont adopté tout ce qui était mauvais
dans les templates C++ : la syntaxe <...> et la convention que
le paramètre soit un seul caractère majuscule

comment ????? tu es sur d'avoir pratiqué ?

le code suivant où 'TypeName' n'est pas une lettre majuscule est valide:

class Stack<TypeName>
{
protected Object[] elementData;
protected int elementCount;
protected int capacity;

public Stack(int capacity) {
this.elementData = new Object[capacity];
this.capacity = capacity;
}
public synchronized void add(TypeName obj) {
if (elementCount == capacity)
throw new ArrayIndexOutOfBoundsException();
elementData[elementCount++] = obj;
}
public synchronized TypeName get(int index) {
if (index >= elementCount)
throw new ArrayIndexOutOfBoundsException(index);
return (TypeName) elementData[index];
}
}

cet autre exemple, où 'numerical' ne contient aucune majuscule et doit
appartenir à un héritage donné est également valide:

class Pool<numerical extends Number>
{
protected Object[] elementData;
protected int elementCount;
protected int capacity;

public Pool(int capacity) {
this.elementData = new Object[capacity];
this.capacity = capacity;
}
public synchronized void add(numerical obj) {
if (elementCount == capacity)
throw new ArrayIndexOutOfBoundsException();
elementData[elementCount++] = obj;
}
public synchronized numerical get(int index) {
if (index >= elementCount)
throw new ArrayIndexOutOfBoundsException();
return (numerical) elementData[index];
}
}

ce typage de l'argument permets une autre sorte de spécialisation:

Pool<String> p; // est invalide

Pool<Integer> p1 = new Pool<Integer>(5); // valide
p1.add(1); // valide
p1.add(3.14); // invalide

et

Pool<Number> p2 = new Pool<Number>(5); // valide
p2.add(1); // valide
p2.add(3.14); // valide

et ont ignoré tout ce qui était intéressant,comme l'idée
que le template lui-même n'est pas un type, mais n'en
devient un que quand il est instantié.

pouf, pouf, je ne l'aurais pas indiqué comme une différence sémantique
forte que tu ne l'aurais surement pas cité ...

une classe paramétrée (as per Java) n'est pas un template (as per ISO
14882, 19768, 24737, ...) donc ça tombe bien c'est une vrai classe (au
sens convertible en byte-code et compréhensible pour un class loader).

je considère même que cette forme de spécialisation est plus
avantageuse du fait même qu'elle tire parti de l'héritage.

Ça ne fait pas la même chose. Quand il convient, on peut faire
la même chose en C++, à condition que la classe de base
l'autorise.

oui, à condition, que l'on puisse hériter d'une classe template, on a
déjà dit que ce n'était pas le cas pour les classes de la STL, non ?

Ici, évidemment, je suppose qu'il s'agit d'un
exemple d'une possibilité, pris un peu au hazard, et non d'un
exemple réel d'une chose qu'on voudrait faire.

comme indiqué! si tu as un meilleur exemple où une spécialisation
explicite sert à quelque chose, indique-le, nous verrons comme couvrir
l'équivalent en Java.

une chose qu'on voudrait faire. Parce qu'en ce qui me concerne

au passage, je note le glissement: "on voudrait" -> "me concerne"; ce
qui ne te concernes pas ne peut pas être voulu ?

[..] Et qu'évidemment, dans une classe Vector bien conçue en
Java, get serait final.

certainement pas. ta vision, tes attentes, ne sont pas l'"évidence".

Sylvain.

kanze wrote on 28/09/2006 10:18:

Le « JIT >>, c'est un nom commercial, publicitaire.

non!

Apparamment, Sun ne l'a pas protégé comme marque déposée, comme
je croyais, mais c'est bien une expression du marketing, qui ne
veut rien dire sur le plan technique.

"just in time", "compiler" ne veulent rien dire "techniquement" ??
tu nous fais pas un blocage là ?

Sun a introduit le 'JIT compiler' en 1997 (Juin 97) avec la version
1.1.3 du JDK et JRE; il était "commercialement" présenté comme le "Java
Performance Pack" (JPP), disponible alors que sous Win32.

A partir de la 1.1.6 (Mai 98), le JPP est remplacé par un simple add-on
("jit update") sous la forme d'une librarie (dll ou .so); à partir de la
1.1.7 (Aout 98) cette librairie est en standard dans le JDK ou JRE.

si tu veux signifier par "expression du marketting" le fait que le
marketting Sun devait faire face à cette époque à de nombreux griefs
concernant les performances d'une appli. Java, alors soit le JPP était
une blabla commercial ... basé sur un élément technique nommé JIT
compiler, qui - sans parler (ne les connaissant pas) des langages
expérimentaux - n'existait (ce JIT) nul part ailleurs.

qui levera un CastClassException à l'exécution, parce qu'il y
a bien vérification dynamique.

C'est peu problable qu'on essaie d'optimiser du code qui lève
des exceptions. Surtout des RuntimeException.

?!? si on en était capable on pourrait préférer, non optimiser un code
qui va planter, mais plutôt le détecter à la compil.

Et ici, l'exception a lieu en dehors de l'objet Vector<Integer>.

tout à fait.

Je remarque aussi qu'une fois de plus, ils n'ont pas appris des
erreurs du C++. Ça fait longtemps, par exemple, qu'on sait que
le choit de <...> comme syntaxe n'est pas des plus heureux.

heureux les tokens simples à écrire ...

C'est un concept qu'on retrouve effectivement en C++. Mais c'est
un concept assez général, qu'on pourrait aussi rétrouver dans
d'autres langages (peut-être sous un autre nom). Ça
m'étonnerait, d'ailleurs, qu'il ne soit pas présent dans
d'autres langages.

moi si (cela m'étonnerait).

Si j'ai bien compris, ils ont adopté tout ce qui était mauvais
dans les templates C++ : la syntaxe <...> et la convention que
le paramètre soit un seul caractère majuscule

comment ????? tu es sur d'avoir pratiqué ?

le code suivant où 'TypeName' n'est pas une lettre majuscule est valide:

class Stack<TypeName>
{
protected Object[] elementData;
protected int elementCount;
protected int capacity;

public Stack(int capacity) {
this.elementData = new Object[capacity];
this.capacity = capacity;
}
public synchronized void add(TypeName obj) {
if (elementCount == capacity)
throw new ArrayIndexOutOfBoundsException();
elementData[elementCount++] = obj;
}
public synchronized TypeName get(int index) {
if (index >= elementCount)
throw new ArrayIndexOutOfBoundsException(index);
return (TypeName) elementData[index];
}
}

cet autre exemple, où 'numerical' ne contient aucune majuscule et doit
appartenir à un héritage donné est également valide:

class Pool<numerical extends Number>
{
protected Object[] elementData;
protected int elementCount;
protected int capacity;

public Pool(int capacity) {
this.elementData = new Object[capacity];
this.capacity = capacity;
}
public synchronized void add(numerical obj) {
if (elementCount == capacity)
throw new ArrayIndexOutOfBoundsException();
elementData[elementCount++] = obj;
}
public synchronized numerical get(int index) {
if (index >= elementCount)
throw new ArrayIndexOutOfBoundsException();
return (numerical) elementData[index];
}
}

ce typage de l'argument permets une autre sorte de spécialisation:

Pool<String> p; // est invalide

Pool<Integer> p1 = new Pool<Integer>(5); // valide
p1.add(1); // valide
p1.add(3.14); // invalide

et

Pool<Number> p2 = new Pool<Number>(5); // valide
p2.add(1); // valide
p2.add(3.14); // valide

et ont ignoré tout ce qui était intéressant,comme l'idée
que le template lui-même n'est pas un type, mais n'en
devient un que quand il est instantié.

pouf, pouf, je ne l'aurais pas indiqué comme une différence sémantique
forte que tu ne l'aurais surement pas cité ...

une classe paramétrée (as per Java) n'est pas un template (as per ISO
14882, 19768, 24737, ...) donc ça tombe bien c'est une vrai classe (au
sens convertible en byte-code et compréhensible pour un class loader).

je considère même que cette forme de spécialisation est plus
avantageuse du fait même qu'elle tire parti de l'héritage.

Ça ne fait pas la même chose. Quand il convient, on peut faire
la même chose en C++, à condition que la classe de base
l'autorise.

oui, à condition, que l'on puisse hériter d'une classe template, on a
déjà dit que ce n'était pas le cas pour les classes de la STL, non ?

Ici, évidemment, je suppose qu'il s'agit d'un
exemple d'une possibilité, pris un peu au hazard, et non d'un
exemple réel d'une chose qu'on voudrait faire.

comme indiqué! si tu as un meilleur exemple où une spécialisation
explicite sert à quelque chose, indique-le, nous verrons comme couvrir
l'équivalent en Java.

une chose qu'on voudrait faire. Parce qu'en ce qui me concerne

au passage, je note le glissement: "on voudrait" -> "me concerne"; ce
qui ne te concernes pas ne peut pas être voulu ?

[..] Et qu'évidemment, dans une classe Vector bien conçue en
Java, get serait final.

certainement pas. ta vision, tes attentes, ne sont pas l'"évidence".

Sylvain.

Vous avez filtré cet utilisateur ! Consultez son message

kanze wrote on 28/09/2006 10:18:

Le « JIT >>, c'est un nom commercial, publicitaire.

non!

Apparamment, Sun ne l'a pas protégé comme marque déposée, comme
je croyais, mais c'est bien une expression du marketing, qui ne
veut rien dire sur le plan technique.

"just in time", "compiler" ne veulent rien dire "techniquement" ??
tu nous fais pas un blocage là ?

Sun a introduit le 'JIT compiler' en 1997 (Juin 97) avec la version
1.1.3 du JDK et JRE; il était "commercialement" présenté comme le "Java
Performance Pack" (JPP), disponible alors que sous Win32.

A partir de la 1.1.6 (Mai 98), le JPP est remplacé par un simple add-on
("jit update") sous la forme d'une librarie (dll ou .so); à partir de la
1.1.7 (Aout 98) cette librairie est en standard dans le JDK ou JRE.

si tu veux signifier par "expression du marketting" le fait que le
marketting Sun devait faire face à cette époque à de nombreux griefs
concernant les performances d'une appli. Java, alors soit le JPP était
une blabla commercial ... basé sur un élément technique nommé JIT
compiler, qui - sans parler (ne les connaissant pas) des langages
expérimentaux - n'existait (ce JIT) nul part ailleurs.

qui levera un CastClassException à l'exécution, parce qu'il y
a bien vérification dynamique.

C'est peu problable qu'on essaie d'optimiser du code qui lève
des exceptions. Surtout des RuntimeException.

?!? si on en était capable on pourrait préférer, non optimiser un code
qui va planter, mais plutôt le détecter à la compil.

Et ici, l'exception a lieu en dehors de l'objet Vector<Integer>.

tout à fait.

Je remarque aussi qu'une fois de plus, ils n'ont pas appris des
erreurs du C++. Ça fait longtemps, par exemple, qu'on sait que
le choit de <...> comme syntaxe n'est pas des plus heureux.

heureux les tokens simples à écrire ...

C'est un concept qu'on retrouve effectivement en C++. Mais c'est
un concept assez général, qu'on pourrait aussi rétrouver dans
d'autres langages (peut-être sous un autre nom). Ça
m'étonnerait, d'ailleurs, qu'il ne soit pas présent dans
d'autres langages.

moi si (cela m'étonnerait).

Si j'ai bien compris, ils ont adopté tout ce qui était mauvais
dans les templates C++ : la syntaxe <...> et la convention que
le paramètre soit un seul caractère majuscule

comment ????? tu es sur d'avoir pratiqué ?

le code suivant où 'TypeName' n'est pas une lettre majuscule est valide:

class Stack<TypeName>
{
protected Object[] elementData;
protected int elementCount;
protected int capacity;

public Stack(int capacity) {
this.elementData = new Object[capacity];
this.capacity = capacity;
}
public synchronized void add(TypeName obj) {
if (elementCount == capacity)
throw new ArrayIndexOutOfBoundsException();
elementData[elementCount++] = obj;
}
public synchronized TypeName get(int index) {
if (index >= elementCount)
throw new ArrayIndexOutOfBoundsException(index);
return (TypeName) elementData[index];
}
}

cet autre exemple, où 'numerical' ne contient aucune majuscule et doit
appartenir à un héritage donné est également valide:

class Pool<numerical extends Number>
{
protected Object[] elementData;
protected int elementCount;
protected int capacity;

public Pool(int capacity) {
this.elementData = new Object[capacity];
this.capacity = capacity;
}
public synchronized void add(numerical obj) {
if (elementCount == capacity)
throw new ArrayIndexOutOfBoundsException();
elementData[elementCount++] = obj;
}
public synchronized numerical get(int index) {
if (index >= elementCount)
throw new ArrayIndexOutOfBoundsException();
return (numerical) elementData[index];
}
}

ce typage de l'argument permets une autre sorte de spécialisation:

Pool<String> p; // est invalide

Pool<Integer> p1 = new Pool<Integer>(5); // valide
p1.add(1); // valide
p1.add(3.14); // invalide

et

Pool<Number> p2 = new Pool<Number>(5); // valide
p2.add(1); // valide
p2.add(3.14); // valide

et ont ignoré tout ce qui était intéressant,comme l'idée
que le template lui-même n'est pas un type, mais n'en
devient un que quand il est instantié.

pouf, pouf, je ne l'aurais pas indiqué comme une différence sémantique
forte que tu ne l'aurais surement pas cité ...

une classe paramétrée (as per Java) n'est pas un template (as per ISO
14882, 19768, 24737, ...) donc ça tombe bien c'est une vrai classe (au
sens convertible en byte-code et compréhensible pour un class loader).

je considère même que cette forme de spécialisation est plus
avantageuse du fait même qu'elle tire parti de l'héritage.

Ça ne fait pas la même chose. Quand il convient, on peut faire
la même chose en C++, à condition que la classe de base
l'autorise.

oui, à condition, que l'on puisse hériter d'une classe template, on a
déjà dit que ce n'était pas le cas pour les classes de la STL, non ?

Ici, évidemment, je suppose qu'il s'agit d'un
exemple d'une possibilité, pris un peu au hazard, et non d'un
exemple réel d'une chose qu'on voudrait faire.

comme indiqué! si tu as un meilleur exemple où une spécialisation
explicite sert à quelque chose, indique-le, nous verrons comme couvrir
l'équivalent en Java.

une chose qu'on voudrait faire. Parce qu'en ce qui me concerne

au passage, je note le glissement: "on voudrait" -> "me concerne"; ce
qui ne te concernes pas ne peut pas être voulu ?

[..] Et qu'évidemment, dans une classe Vector bien conçue en
Java, get serait final.

certainement pas. ta vision, tes attentes, ne sont pas l'"évidence".

Sylvain.

Jean-Marc Bourguet

28/09/2006 à 19:08

"kanze" writes:

Jean-Marc Bourguet wrote:
"kanze" writes:

Bref les génériques en java c'est plus de l'ordre du sucre
syntaxique qu'autre chose et on est bien loin de C++

Certes, mais pour d'autres raisons -- je ne crois pas qu'il
y a des paramètres non-type, ni des spécialisations
explicites, par exemple.

"spécialisation explicite" est un concept, paradigme, ..., C++
donc en effet on le rencontre en C++

C'est un concept qu'on retrouve effectivement en C++. Mais c'est
un concept assez général, qu'on pourrait aussi rétrouver dans
d'autres langages (peut-être sous un autre nom). Ça
m'étonnerait, d'ailleurs, qu'il ne soit pas présent dans
d'autres langages.

Je n'en connais pas (ni Eiffel, ni Ada, ni Modula-3, ni --
pour autant que je le sache -- la famille ML; tous permettent
une implémentation partagée, bien qu'en Ada95 ce soit
pénible). Je serais curieux de voir un autre langage où c'est
le cas.

Je n'en connais pas non plus, mais je sais qu'en général,
Stroustrup a préféré adopter les idées éprouvées que de se
lancer dans l'expérimentation spéculative. Et il n'y a
certainement rien dans le concept qui le rendrait impossible
dans d'autres langages.

Rien. Sauf que je serais curieux de voir comment un autre langage ferait,
pour avoir une meilleure idée de ce qui est essentiel et de ce qui est
accidentel dans le système.

Il y a à mon avis peut de chance qu'un tel langage soit le produit de la
recherche académique -- le système des templates de C++ s'accorde assez mal
avec ce que je connais du travail des théoriciens (écrivant cela, ça me
rappelle que je dois toujours lire à fond le papier de Stroustrup et de
Gaby).

C++ templates are similar to type parameters, but are actually a
form of macro-expansion, with very different properties.
Luca Cardelli

Il a raison, mais je trouve domage de ne pas examiner plus les propritétés
des templates en C++.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

"kanze" <kanze@gabi-soft.fr> writes:

Jean-Marc Bourguet wrote:

"kanze" <kanze@gabi-soft.fr> writes:

Bref les génériques en java c'est plus de l'ordre du sucre
syntaxique qu'autre chose et on est bien loin de C++

Certes, mais pour d'autres raisons -- je ne crois pas qu'il
y a des paramètres non-type, ni des spécialisations
explicites, par exemple.

"spécialisation explicite" est un concept, paradigme, ..., C++
donc en effet on le rencontre en C++

C'est un concept qu'on retrouve effectivement en C++. Mais c'est
un concept assez général, qu'on pourrait aussi rétrouver dans
d'autres langages (peut-être sous un autre nom). Ça
m'étonnerait, d'ailleurs, qu'il ne soit pas présent dans
d'autres langages.

Je n'en connais pas (ni Eiffel, ni Ada, ni Modula-3, ni --
pour autant que je le sache -- la famille ML; tous permettent
une implémentation partagée, bien qu'en Ada95 ce soit
pénible). Je serais curieux de voir un autre langage où c'est
le cas.

Je n'en connais pas non plus, mais je sais qu'en général,
Stroustrup a préféré adopter les idées éprouvées que de se
lancer dans l'expérimentation spéculative. Et il n'y a
certainement rien dans le concept qui le rendrait impossible
dans d'autres langages.

Rien. Sauf que je serais curieux de voir comment un autre langage ferait,
pour avoir une meilleure idée de ce qui est essentiel et de ce qui est
accidentel dans le système.

Il y a à mon avis peut de chance qu'un tel langage soit le produit de la
recherche académique -- le système des templates de C++ s'accorde assez mal
avec ce que je connais du travail des théoriciens (écrivant cela, ça me
rappelle que je dois toujours lire à fond le papier de Stroustrup et de
Gaby).

C++ templates are similar to type parameters, but are actually a
form of macro-expansion, with very different properties.
Luca Cardelli

Il a raison, mais je trouve domage de ne pas examiner plus les propritétés
des templates en C++.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Vous avez filtré cet utilisateur ! Consultez son message

"kanze" writes:

Jean-Marc Bourguet wrote:
"kanze" writes:

Bref les génériques en java c'est plus de l'ordre du sucre
syntaxique qu'autre chose et on est bien loin de C++

Certes, mais pour d'autres raisons -- je ne crois pas qu'il
y a des paramètres non-type, ni des spécialisations
explicites, par exemple.

"spécialisation explicite" est un concept, paradigme, ..., C++
donc en effet on le rencontre en C++

C'est un concept qu'on retrouve effectivement en C++. Mais c'est
un concept assez général, qu'on pourrait aussi rétrouver dans
d'autres langages (peut-être sous un autre nom). Ça
m'étonnerait, d'ailleurs, qu'il ne soit pas présent dans
d'autres langages.

Je n'en connais pas (ni Eiffel, ni Ada, ni Modula-3, ni --
pour autant que je le sache -- la famille ML; tous permettent
une implémentation partagée, bien qu'en Ada95 ce soit
pénible). Je serais curieux de voir un autre langage où c'est
le cas.

Je n'en connais pas non plus, mais je sais qu'en général,
Stroustrup a préféré adopter les idées éprouvées que de se
lancer dans l'expérimentation spéculative. Et il n'y a
certainement rien dans le concept qui le rendrait impossible
dans d'autres langages.

Rien. Sauf que je serais curieux de voir comment un autre langage ferait,
pour avoir une meilleure idée de ce qui est essentiel et de ce qui est
accidentel dans le système.

Il y a à mon avis peut de chance qu'un tel langage soit le produit de la
recherche académique -- le système des templates de C++ s'accorde assez mal
avec ce que je connais du travail des théoriciens (écrivant cela, ça me
rappelle que je dois toujours lire à fond le papier de Stroustrup et de
Gaby).

C++ templates are similar to type parameters, but are actually a
form of macro-expansion, with very different properties.
Luca Cardelli

Il a raison, mais je trouve domage de ne pas examiner plus les propritétés
des templates en C++.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Sylvain

28/09/2006 à 19:15

Alain Gaillard wrote on 28/09/2006 11:35:

Vector<Integer> numbers = new Vector<Integer>(10, 10);
Object object = new String("toto");
numbers.add((Integer) object);

C'est peu problable qu'on essaie d'optimiser du code qui lève
des exceptions. Surtout des RuntimeException. (Et ici, aussi,
l'exception a lieu en dehors de l'objet Vector<Integer>.)

Avant de parler optimisation (ce que de toutes façon le compilo ne fera
pas ;) tu trouves normal que ce code soit compilé. Tu parles d'une
généricité. Tu dit vector de Integer, tu lui balances une Steing et il
trouve ça normal....

qui a dit que c'était "normal" ?? et que signifie ici normalité ?

l'écriture: numbers.add((Integer) new String("toto")); est refusé par le
compilo qui sait que String ne peut être casté en Integer (par
définition de ces classes); c'est pour cela que je passais par un upcast
en Object pour bypasser les controles du compilo, il n'est pas "normal"
de faire ainsi, c'est un artifice d'écriture pour illustrer les tests
dynamiques qui existent indépendamment de toute considération JITisque -
mais l'exemple est non pertinent car le cast levant l'exception est fait
avant l'appel à la méthode add.

l'optimisation à la compilation se limite à quelque libertés sur la
constant pool / pile; un code invalide (pouvant être vu comme tel) n'a
pas à être optimisé mais plutôt refusé.

pour autant et pour répondre à cette "horreur" ou ferait-on cela en C++,
il se trouve qu'en C++, on écrit, compile ET exécute sans détection
d'erreur:

class T {};
class Q {};

std::vector<T*> v;
v.push_back(new T);
v.push_back((T*) new Q);

void* item = v[0];
item = v[1];

pour un template typé c'est dommage, mais peut être qu'ici la lettre
majuscule ne veut rien dire d'autre que 'void'; est-ce "normal" ?...

Sylvain.

Alain Gaillard

28/09/2006 à 19:41

Le « JIT >>, c'est un nom commercial, publicitaire.

non!

Apparamment, Sun ne l'a pas protégé comme marque déposée, comme
je croyais, mais c'est bien une expression du marketing, qui ne
veut rien dire sur le plan technique.

"just in time", "compiler" ne veulent rien dire "techniquement" ??
tu nous fais pas un blocage là ?

Sun a introduit le 'JIT compiler' en 1997 (Juin 97) avec la version
1.1.3 du JDK et JRE; il était "commercialement" présenté comme le "Java
Performance Pack" (JPP), disponible alors que sous Win32.

A partir de la 1.1.6 (Mai 98), le JPP est remplacé par un simple add-on
("jit update") sous la forme d'une librarie (dll ou .so); à partir de la
1.1.7 (Aout 98) cette librairie est en standard dans le JDK ou JRE.

si tu veux signifier par "expression du marketting" le fait que le
marketting Sun devait faire face à cette époque à de nombreux griefs
concernant les performances d'une appli. Java, alors soit le JPP était
une blabla commercial ... basé sur un élément technique nommé JIT
compiler, qui - sans parler (ne les connaissant pas) des langages
expérimentaux - n'existait (ce JIT) nul part ailleurs.

Tu es un vrai historien du JIT toi :-)

Si j'ai bien compris, ils ont adopté tout ce qui était mauvais
dans les templates C++ : la syntaxe <...> et la convention que
le paramètre soit un seul caractère majuscule

comment ????? tu es sur d'avoir pratiqué ?

Je pense que James se réfère à ce qu'il voit dans la Javadoc. Par
exemple java.util Class Stack<E>

C'est juste une convention. Je ne suis pas sûr qu'il soit interdit de
mettre plus qu'une majuscule en C++ d'ailleurs. Enfin je dis ça sans
être sûr. Comme tout le monde j'ai tellement l'habitude de ne mettre
qu'une majuscule. Mais je n'ai pas à l'esprit un passage de la norme qui
dise que l'on doive se limiter à cela.

Les gourous ici présents qui connaissent la norme par coeur ne
manqueront pas de me corriger si je me gourre :-)

--
Alain

Sylvain

28/09/2006 à 20:07

Alain Gaillard wrote on 28/09/2006 19:41:

Tu es un vrai historien du JIT toi :-)

je faisais pas mal de Java à cette époque et j'ai utilisé tous les JDK
de 1.0.2 (Juin 96) à 1.2.2 (Juillet 99) - je suis passé à Java2 comme
tout le monde mais je n'ai plus le besoin de rentrer dans des détails.

l'histoire des compilo JIT a suivi l'usage fait de Java; il a été
invoqué comme l'indispensable élément à Swing par exemple; c'est une
erreur, AWT comme Swing (un peu moins pour Swing) reposent sur des
représentations natives (les classes peer); le compilo JIT était (et
reste) indispensable pour les bêtes petites opérations de loop,
affectation, passage de paramètre, retour d'un type non primitif (Java
n'a pas de temporaire (vite pris sur la pile), ce point créé une vraie
lourdeur d'exécution).

Sylvain.

Gabriel Dos Reis

29/09/2006 à 05:06

"kanze" writes:

| Jean-Marc Bourguet wrote:
| > "kanze" writes:
|
| > >> >> Bref les génériques en java c'est plus de l'ordre du sucre
| > >> >> syntaxique qu'autre chose et on est bien loin de C++
|
| > >> > Certes, mais pour d'autres raisons -- je ne crois pas qu'il
| > >> > y a des paramètres non-type, ni des spécialisations
| > >> > explicites, par exemple.
|
| > >> "spécialisation explicite" est un concept, paradigme, ..., C++
| > >> donc en effet on le rencontre en C++
|
| > > C'est un concept qu'on retrouve effectivement en C++. Mais c'est
| > > un concept assez général, qu'on pourrait aussi rétrouver dans
| > > d'autres langages (peut-être sous un autre nom). Ça
| > > m'étonnerait, d'ailleurs, qu'il ne soit pas présent dans
| > > d'autres langages.
|
| > Je n'en connais pas (ni Eiffel, ni Ada, ni Modula-3, ni --
| > pour autant que je le sache -- la famille ML; tous permettent
| > une implémentation partagée, bien qu'en Ada95 ce soit
| > pénible). Je serais curieux de voir un autre langage où c'est
| > le cas.
|
| Je n'en connais pas non plus, mais je sais qu'en général,
| Stroustrup a préféré adopter les idées éprouvées que de se
| lancer dans l'expérimentation spéculative.

De sa propre bouche, il a apprit beaucoup de choses de Ada, en
particulier de ne pas copier Ada. De plus, selon ses propres
termes, lorsqu'il a proposé les paramètres « non-type », il a
rencontré *beaucoup* de résistance.
Plusieurs fois, il m'a raconté l'une des « fameuses » discussions
qu'il a eu avec Dave MacQueen (de Standard ML, travaillant dans le
même labo) à propos des paramètres « nont-ypes » (absente des langages
de la famille ML) et leurs réductions.

| Et il n'y a
| certainement rien dans le concept qui le rendrait impossible
| dans d'autres langages.

En effet. On le toruve trivialement dans les langages qui supportent
la notion de « dependent types » (pas exactement la même chose qu'en
C++) -- où les types peuvent être paramétrés par des valeurs.
On le retrouve dans Epigram (assez recent), mais aussi dans Axiom (et
donc Aldor). Mais, je ne pense pas que BS avait connaissance du
projet Axiom à l'epoque -- il m'a toujours dit qu'autoriser les
arguments « non-types » lui semblait une chose naturelle qui relevait
de l'évidence.

Note cependant que les « generics » de Java ne supportent pas les
« non-types »

-- Gaby

"kanze" <kanze@gabi-soft.fr> writes:

| Jean-Marc Bourguet wrote:
| > "kanze" <kanze@gabi-soft.fr> writes:
|
| > >> >> Bref les génériques en java c'est plus de l'ordre du sucre
| > >> >> syntaxique qu'autre chose et on est bien loin de C++
|
| > >> > Certes, mais pour d'autres raisons -- je ne crois pas qu'il
| > >> > y a des paramètres non-type, ni des spécialisations
| > >> > explicites, par exemple.
|
| > >> "spécialisation explicite" est un concept, paradigme, ..., C++
| > >> donc en effet on le rencontre en C++
|
| > > C'est un concept qu'on retrouve effectivement en C++. Mais c'est
| > > un concept assez général, qu'on pourrait aussi rétrouver dans
| > > d'autres langages (peut-être sous un autre nom). Ça
| > > m'étonnerait, d'ailleurs, qu'il ne soit pas présent dans
| > > d'autres langages.
|
| > Je n'en connais pas (ni Eiffel, ni Ada, ni Modula-3, ni --
| > pour autant que je le sache -- la famille ML; tous permettent
| > une implémentation partagée, bien qu'en Ada95 ce soit
| > pénible). Je serais curieux de voir un autre langage où c'est
| > le cas.
|
| Je n'en connais pas non plus, mais je sais qu'en général,
| Stroustrup a préféré adopter les idées éprouvées que de se
| lancer dans l'expérimentation spéculative.

De sa propre bouche, il a apprit beaucoup de choses de Ada, en
particulier de ne pas copier Ada. De plus, selon ses propres
termes, lorsqu'il a proposé les paramètres « non-type », il a
rencontré *beaucoup* de résistance.
Plusieurs fois, il m'a raconté l'une des « fameuses » discussions
qu'il a eu avec Dave MacQueen (de Standard ML, travaillant dans le
même labo) à propos des paramètres « nont-ypes » (absente des langages
de la famille ML) et leurs réductions.

| Et il n'y a
| certainement rien dans le concept qui le rendrait impossible
| dans d'autres langages.

En effet. On le toruve trivialement dans les langages qui supportent
la notion de « dependent types » (pas exactement la même chose qu'en
C++) -- où les types peuvent être paramétrés par des valeurs.
On le retrouve dans Epigram (assez recent), mais aussi dans Axiom (et
donc Aldor). Mais, je ne pense pas que BS avait connaissance du
projet Axiom à l'epoque -- il m'a toujours dit qu'autoriser les
arguments « non-types » lui semblait une chose naturelle qui relevait
de l'évidence.

Note cependant que les « generics » de Java ne supportent pas les
« non-types »

-- Gaby

Vous avez filtré cet utilisateur ! Consultez son message

"kanze" writes:

| Jean-Marc Bourguet wrote:
| > "kanze" writes:
|
| > >> >> Bref les génériques en java c'est plus de l'ordre du sucre
| > >> >> syntaxique qu'autre chose et on est bien loin de C++
|
| > >> > Certes, mais pour d'autres raisons -- je ne crois pas qu'il
| > >> > y a des paramètres non-type, ni des spécialisations
| > >> > explicites, par exemple.
|
| > >> "spécialisation explicite" est un concept, paradigme, ..., C++
| > >> donc en effet on le rencontre en C++
|
| > > C'est un concept qu'on retrouve effectivement en C++. Mais c'est
| > > un concept assez général, qu'on pourrait aussi rétrouver dans
| > > d'autres langages (peut-être sous un autre nom). Ça
| > > m'étonnerait, d'ailleurs, qu'il ne soit pas présent dans
| > > d'autres langages.
|
| > Je n'en connais pas (ni Eiffel, ni Ada, ni Modula-3, ni --
| > pour autant que je le sache -- la famille ML; tous permettent
| > une implémentation partagée, bien qu'en Ada95 ce soit
| > pénible). Je serais curieux de voir un autre langage où c'est
| > le cas.
|
| Je n'en connais pas non plus, mais je sais qu'en général,
| Stroustrup a préféré adopter les idées éprouvées que de se
| lancer dans l'expérimentation spéculative.

De sa propre bouche, il a apprit beaucoup de choses de Ada, en
particulier de ne pas copier Ada. De plus, selon ses propres
termes, lorsqu'il a proposé les paramètres « non-type », il a
rencontré *beaucoup* de résistance.
Plusieurs fois, il m'a raconté l'une des « fameuses » discussions
qu'il a eu avec Dave MacQueen (de Standard ML, travaillant dans le
même labo) à propos des paramètres « nont-ypes » (absente des langages
de la famille ML) et leurs réductions.

| Et il n'y a
| certainement rien dans le concept qui le rendrait impossible
| dans d'autres langages.

En effet. On le toruve trivialement dans les langages qui supportent
la notion de « dependent types » (pas exactement la même chose qu'en
C++) -- où les types peuvent être paramétrés par des valeurs.
On le retrouve dans Epigram (assez recent), mais aussi dans Axiom (et
donc Aldor). Mais, je ne pense pas que BS avait connaissance du
projet Axiom à l'epoque -- il m'a toujours dit qu'autoriser les
arguments « non-types » lui semblait une chose naturelle qui relevait
de l'évidence.

Note cependant que les « generics » de Java ne supportent pas les
« non-types »

-- Gaby

Un doute existenciel a propos du parcours de liste dans une boucle 'for'

10 réponses

Veuillez sélectionner un problème