membres d'une base dépendante ?

Gabriel Dos Reis

05/10/2004 à 07:47

Dimitri Papadopoulos-Orfanos writes:

| Hi,
|
| > Ceux d'entre vous dont le souci premier est d'écrire des programmes
| > qui marchent auraient dû savoir que « this->f() » marche dans
| > les deux cas (recherche de noms en deux phases ou non).
|
| Hum, comment peut-on le savoir ?

Je répondais littéralement à James. (Et j'aurais aimé que tu eûsses
laissé le passage de James).

Et pour comprendre la réponse, il faut se souvenir que James aime à se
vanter qu'à partir de 1993-1994, il participait aux travaux de
normalisation de C++ et en ce sens avait l'information à sa
disposition.
... ah ben non, il n'était pas dans le comité qui s'occupait des
templates, et donc, il était dispensé de savoir ce qui s'y discute... <G>.

Mais, il y avait le D&E. Ah mais, en tant que professionnel sérieux, il
n'est pas tenu de se mettre au courant des évolutions d'un de ses
outils principaux de travail. <G>.

-- Gaby

kanze

05/10/2004 à 09:17

(Daveed Vandevoorde) wrote in message
news:...

wrote:
[...]
Je crois que tout le monde reconnaissait que la solution CFront
était un hack.

Mal implemente, en plus :-(

Un hack bien utile, évidemment ; ceux de nous qui avaient implémenté
des classes génériques à la base de <generic.h> en attendait avec
impatience.

(Trivia: Cfront 3.0 etait une version essentiellement inutilisable
du au grand nombre de bogues.

C'est le cas habituel des vrai .0, malheureusement.

J'espere que non ;-) Beaucoup de .0 on en effet trop de bogues, mais
Cfront 3.0 etait literalement inutilisable.

Je me place à l'époque. Avec g++ 1.49, qui n'appelait pas les
destructeurs sur des variables locales quand on quittait une fonction
par un return. Avec je ne sais pas quelle version de Zortech, qui
testait un paramètre caché supplémentaire dans le constructeur, pour
savoir s'il fallait initialiser les bases virtuelles, mais qui ne
générait pas le code pour le passer à l'appel du constructeur. Et j'en
passe des meilleurs. Inutilisable est rélatif.

Ceci dit, je n'ai jamais essayé des templates avec CFront 3.0. Avec
CFront 3.0.1, si, et là, je peux dire que malgré les problèmes, par
rapport à <generic.h>... Je sais que déjà à l'époque, tu t'intéressais à
ce qu'on appelle aujourd'hui la méta-programmation, mais moi, à
l'époque, mon but principal, c'était de pouvoir me débarasser de
<generic.h>, pour ArrayOf, AssocArrayOf, DLListOf et RefCntPtr. Mes
exigences étaient bien plus bas.

Encore que quand tu considères ce dont on avait l'habitude à
l'époque... (Jusqu'en 94 environ, je comptais deux boggues dans le
compilateur pour chaque erreur dans mon propre code. Avec des
compilateurs « stabiles ».)

Ah, la bonne epoque... ;-)

N'est-ce pas ? En ce qui concerne la qualité des compilateurs, on en a
fait du progrès, même s'il en reste à faire. Mais on a encore le
problème qu'il n'y a pas deux compilateurs qui implémentent le même
sous-ensemble de la norme. Ce qui ne rend pas la vie plus facile non
plus.

La version 3.0.1 corrigait les problemes les plus grossiers, et
fut le premier compilo a vraiment permettre l'exploration des
templates. Neanmoins, de beaucoup de points de vues,
l'implementation Cfront des templates etait un "hack" que la
plupart des implementation ulterieures etaient forcees d'imiter.)

Parce que c'était CFront. Le compilateur « officiel ».

C'est intéressant de savoir l'histoire de CFront maintenant. Mais il
ne faut pas oublier qu'à l'époque, c'était le compilateur qui
sortait de AT&T. La référence. Les (ré)vendeurs n'ont certainement
pas tiré notre attention sur le faut que ce n'était plus l'oeuvre de
l'équipe Bell Labs.

Oui, malheureusement. En fait, c'est un cas ou le standard est arrive
"trop tard". Ou, en d'autres termes, ou "standardiser la pratique
existante" n'etait pas la bonne chose a faire.

Il faut bien une pratique pour pouvoir standardiser. On peut pas
travailler dans la vide, et le but final d'une norme, c'est bien un but
pratique. C'est un problème délicat, en fait -- trop tôt, et on n'a pas
l'expérience nécessaire pour être sûr d'avoir fait le bon choix, trop
tard, et les gens sont déjà verouillés dans des technologies
propriétaires, trop pour en changer. Stroustrup a bien hésité à dire
trop sur les templates dans l'ARM, parce qu'il n'en avait pas assez
d'expérience. (Et je parie que John Spicer aurait bien préféré pouvoir
implémenter export, au moins en partie, avant qu'il soit adopté par la
norme.) Dans le cas de C++ :

- En général, la norme est arrivée trop tard. Il nous la fallait déjà
avant 1995. Mais dans l'ensemble, les fournisseurs ont joué le jeux.
Pour la plupart, ils sont restés compatibles même dans l'absence de
la norme, et ils ont essayé à fournir des chemins de migration quand
la norme n'a pas suivie la pratique existante (par exemple, la
portée d'une variable dans un for).

- En ce qui concerne les templates, il y a eu un problème véritable,
pour plusieurs raisons. Surtout, je crois, c'est qu'on (les
utilisateurs) en avait vraiment besoin. En urgence -- <generic.h>
n'est vraiment pas une solution viable, et c'était déjà clair en
1990 que faire hériter tout d'Object n'était pas une bonne solution.
Et donc, on n'a pas voulu attendre que la technologie se stabilise.
Et disons le clair, pour implémenter mes quatre classes ci-dessus,
ce que faisait CFront ou Borland était largement suffisant. Du coup,
la précipitation des fournisseurs, à une époque où peut-être il
aurait mieux fallu expérimenter un peu plus. Pour bien savoir ce qui
était mieux.

Même aujourd'hui, en restrospect, je ne sais pas quelle solution il
aurait fallu adopter. Je connais bien les problèmes de ce qu'on a fait,
parce que je les vis tous les jours. D'un côté, je me dis qu'il aurait
fallu une norme rapide (disons 1995), quitte à laisser les templates,
les exceptions, et la bibliothèque standard (sauf iostream) pour plus
tard. Réalistiquement, en revanche, je ne crois pas qu'on aurait pû
sortir une norme sans au moins une classe de string et une classe de
vecteur -- et réalistiquement, en sachant qu'il existe une technologie
de templates, aussi primitive soit-elle, est-ce qu'on aurait pû
normaliser une classe vecteur qui n'est pas templaté (disons sur la base
de <generic.h>). Et évidemment, il fallait changer new pour qu'il lève
une exception le plus tôt possible -- je crois que tout le monde (même
moi) est d'accord que c'est un changement nécessaire, mais il casse tout
le code existant, et plus on traine à le faire, plus il y a du code à
casser.

Parfois je me dis que de toute façon, les templates, ce n'est pas
l'outil idéal pour la méta-programmation, qu'on peut faire mieux. Et
qu'il aurait été préférable à simplement normaliser ce que faisait
CFront, avec tout ses défauts, parce que ça suffit pour les classes de
collections et les utilisations simples, et que comme ça, on prend le
temps pour dévélopper un outil de méta-programmation plus convenable.

Mais c'est de la spéculation. On sait les résultats des choix qu'on a
fait. On n'en sait jamais des choix qu'on n'a pas fait.

--
James Kanze GABI Software http://www.gabi-soft.fr
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

google@vandevoorde.com (Daveed Vandevoorde) wrote in message
news:<52f2f9cd.0410041443.1804e44d@posting.google.com>...

kanze@gabi-soft.fr wrote:
[...]

Je crois que tout le monde reconnaissait que la solution CFront
était un hack.

Mal implemente, en plus :-(

Un hack bien utile, évidemment ; ceux de nous qui avaient implémenté
des classes génériques à la base de <generic.h> en attendait avec
impatience.

(Trivia: Cfront 3.0 etait une version essentiellement inutilisable
du au grand nombre de bogues.

C'est le cas habituel des vrai .0, malheureusement.

J'espere que non ;-) Beaucoup de .0 on en effet trop de bogues, mais
Cfront 3.0 etait literalement inutilisable.

Je me place à l'époque. Avec g++ 1.49, qui n'appelait pas les
destructeurs sur des variables locales quand on quittait une fonction
par un return. Avec je ne sais pas quelle version de Zortech, qui
testait un paramètre caché supplémentaire dans le constructeur, pour
savoir s'il fallait initialiser les bases virtuelles, mais qui ne
générait pas le code pour le passer à l'appel du constructeur. Et j'en
passe des meilleurs. Inutilisable est rélatif.

Ceci dit, je n'ai jamais essayé des templates avec CFront 3.0. Avec
CFront 3.0.1, si, et là, je peux dire que malgré les problèmes, par
rapport à <generic.h>... Je sais que déjà à l'époque, tu t'intéressais à
ce qu'on appelle aujourd'hui la méta-programmation, mais moi, à
l'époque, mon but principal, c'était de pouvoir me débarasser de
<generic.h>, pour ArrayOf, AssocArrayOf, DLListOf et RefCntPtr. Mes
exigences étaient bien plus bas.

Encore que quand tu considères ce dont on avait l'habitude à
l'époque... (Jusqu'en 94 environ, je comptais deux boggues dans le
compilateur pour chaque erreur dans mon propre code. Avec des
compilateurs « stabiles ».)

Ah, la bonne epoque... ;-)

N'est-ce pas ? En ce qui concerne la qualité des compilateurs, on en a
fait du progrès, même s'il en reste à faire. Mais on a encore le
problème qu'il n'y a pas deux compilateurs qui implémentent le même
sous-ensemble de la norme. Ce qui ne rend pas la vie plus facile non
plus.

La version 3.0.1 corrigait les problemes les plus grossiers, et
fut le premier compilo a vraiment permettre l'exploration des
templates. Neanmoins, de beaucoup de points de vues,
l'implementation Cfront des templates etait un "hack" que la
plupart des implementation ulterieures etaient forcees d'imiter.)

Parce que c'était CFront. Le compilateur « officiel ».

C'est intéressant de savoir l'histoire de CFront maintenant. Mais il
ne faut pas oublier qu'à l'époque, c'était le compilateur qui
sortait de AT&T. La référence. Les (ré)vendeurs n'ont certainement
pas tiré notre attention sur le faut que ce n'était plus l'oeuvre de
l'équipe Bell Labs.

Oui, malheureusement. En fait, c'est un cas ou le standard est arrive
"trop tard". Ou, en d'autres termes, ou "standardiser la pratique
existante" n'etait pas la bonne chose a faire.

Il faut bien une pratique pour pouvoir standardiser. On peut pas
travailler dans la vide, et le but final d'une norme, c'est bien un but
pratique. C'est un problème délicat, en fait -- trop tôt, et on n'a pas
l'expérience nécessaire pour être sûr d'avoir fait le bon choix, trop
tard, et les gens sont déjà verouillés dans des technologies
propriétaires, trop pour en changer. Stroustrup a bien hésité à dire
trop sur les templates dans l'ARM, parce qu'il n'en avait pas assez
d'expérience. (Et je parie que John Spicer aurait bien préféré pouvoir
implémenter export, au moins en partie, avant qu'il soit adopté par la
norme.) Dans le cas de C++ :

- En général, la norme est arrivée trop tard. Il nous la fallait déjà
avant 1995. Mais dans l'ensemble, les fournisseurs ont joué le jeux.
Pour la plupart, ils sont restés compatibles même dans l'absence de
la norme, et ils ont essayé à fournir des chemins de migration quand
la norme n'a pas suivie la pratique existante (par exemple, la
portée d'une variable dans un for).

- En ce qui concerne les templates, il y a eu un problème véritable,
pour plusieurs raisons. Surtout, je crois, c'est qu'on (les
utilisateurs) en avait vraiment besoin. En urgence -- <generic.h>
n'est vraiment pas une solution viable, et c'était déjà clair en
1990 que faire hériter tout d'Object n'était pas une bonne solution.
Et donc, on n'a pas voulu attendre que la technologie se stabilise.
Et disons le clair, pour implémenter mes quatre classes ci-dessus,
ce que faisait CFront ou Borland était largement suffisant. Du coup,
la précipitation des fournisseurs, à une époque où peut-être il
aurait mieux fallu expérimenter un peu plus. Pour bien savoir ce qui
était mieux.

Même aujourd'hui, en restrospect, je ne sais pas quelle solution il
aurait fallu adopter. Je connais bien les problèmes de ce qu'on a fait,
parce que je les vis tous les jours. D'un côté, je me dis qu'il aurait
fallu une norme rapide (disons 1995), quitte à laisser les templates,
les exceptions, et la bibliothèque standard (sauf iostream) pour plus
tard. Réalistiquement, en revanche, je ne crois pas qu'on aurait pû
sortir une norme sans au moins une classe de string et une classe de
vecteur -- et réalistiquement, en sachant qu'il existe une technologie
de templates, aussi primitive soit-elle, est-ce qu'on aurait pû
normaliser une classe vecteur qui n'est pas templaté (disons sur la base
de <generic.h>). Et évidemment, il fallait changer new pour qu'il lève
une exception le plus tôt possible -- je crois que tout le monde (même
moi) est d'accord que c'est un changement nécessaire, mais il casse tout
le code existant, et plus on traine à le faire, plus il y a du code à
casser.

Parfois je me dis que de toute façon, les templates, ce n'est pas
l'outil idéal pour la méta-programmation, qu'on peut faire mieux. Et
qu'il aurait été préférable à simplement normaliser ce que faisait
CFront, avec tout ses défauts, parce que ça suffit pour les classes de
collections et les utilisations simples, et que comme ça, on prend le
temps pour dévélopper un outil de méta-programmation plus convenable.

Mais c'est de la spéculation. On sait les résultats des choix qu'on a
fait. On n'en sait jamais des choix qu'on n'a pas fait.

--
James Kanze GABI Software http://www.gabi-soft.fr
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

Vous avez filtré cet utilisateur ! Consultez son message

(Daveed Vandevoorde) wrote in message
news:...

wrote:
[...]
Je crois que tout le monde reconnaissait que la solution CFront
était un hack.

Mal implemente, en plus :-(

Un hack bien utile, évidemment ; ceux de nous qui avaient implémenté
des classes génériques à la base de <generic.h> en attendait avec
impatience.

(Trivia: Cfront 3.0 etait une version essentiellement inutilisable
du au grand nombre de bogues.

C'est le cas habituel des vrai .0, malheureusement.

J'espere que non ;-) Beaucoup de .0 on en effet trop de bogues, mais
Cfront 3.0 etait literalement inutilisable.

Je me place à l'époque. Avec g++ 1.49, qui n'appelait pas les
destructeurs sur des variables locales quand on quittait une fonction
par un return. Avec je ne sais pas quelle version de Zortech, qui
testait un paramètre caché supplémentaire dans le constructeur, pour
savoir s'il fallait initialiser les bases virtuelles, mais qui ne
générait pas le code pour le passer à l'appel du constructeur. Et j'en
passe des meilleurs. Inutilisable est rélatif.

Ceci dit, je n'ai jamais essayé des templates avec CFront 3.0. Avec
CFront 3.0.1, si, et là, je peux dire que malgré les problèmes, par
rapport à <generic.h>... Je sais que déjà à l'époque, tu t'intéressais à
ce qu'on appelle aujourd'hui la méta-programmation, mais moi, à
l'époque, mon but principal, c'était de pouvoir me débarasser de
<generic.h>, pour ArrayOf, AssocArrayOf, DLListOf et RefCntPtr. Mes
exigences étaient bien plus bas.

Encore que quand tu considères ce dont on avait l'habitude à
l'époque... (Jusqu'en 94 environ, je comptais deux boggues dans le
compilateur pour chaque erreur dans mon propre code. Avec des
compilateurs « stabiles ».)

Ah, la bonne epoque... ;-)

N'est-ce pas ? En ce qui concerne la qualité des compilateurs, on en a
fait du progrès, même s'il en reste à faire. Mais on a encore le
problème qu'il n'y a pas deux compilateurs qui implémentent le même
sous-ensemble de la norme. Ce qui ne rend pas la vie plus facile non
plus.

La version 3.0.1 corrigait les problemes les plus grossiers, et
fut le premier compilo a vraiment permettre l'exploration des
templates. Neanmoins, de beaucoup de points de vues,
l'implementation Cfront des templates etait un "hack" que la
plupart des implementation ulterieures etaient forcees d'imiter.)

Parce que c'était CFront. Le compilateur « officiel ».

C'est intéressant de savoir l'histoire de CFront maintenant. Mais il
ne faut pas oublier qu'à l'époque, c'était le compilateur qui
sortait de AT&T. La référence. Les (ré)vendeurs n'ont certainement
pas tiré notre attention sur le faut que ce n'était plus l'oeuvre de
l'équipe Bell Labs.

Oui, malheureusement. En fait, c'est un cas ou le standard est arrive
"trop tard". Ou, en d'autres termes, ou "standardiser la pratique
existante" n'etait pas la bonne chose a faire.

Il faut bien une pratique pour pouvoir standardiser. On peut pas
travailler dans la vide, et le but final d'une norme, c'est bien un but
pratique. C'est un problème délicat, en fait -- trop tôt, et on n'a pas
l'expérience nécessaire pour être sûr d'avoir fait le bon choix, trop
tard, et les gens sont déjà verouillés dans des technologies
propriétaires, trop pour en changer. Stroustrup a bien hésité à dire
trop sur les templates dans l'ARM, parce qu'il n'en avait pas assez
d'expérience. (Et je parie que John Spicer aurait bien préféré pouvoir
implémenter export, au moins en partie, avant qu'il soit adopté par la
norme.) Dans le cas de C++ :

- En général, la norme est arrivée trop tard. Il nous la fallait déjà
avant 1995. Mais dans l'ensemble, les fournisseurs ont joué le jeux.
Pour la plupart, ils sont restés compatibles même dans l'absence de
la norme, et ils ont essayé à fournir des chemins de migration quand
la norme n'a pas suivie la pratique existante (par exemple, la
portée d'une variable dans un for).

- En ce qui concerne les templates, il y a eu un problème véritable,
pour plusieurs raisons. Surtout, je crois, c'est qu'on (les
utilisateurs) en avait vraiment besoin. En urgence -- <generic.h>
n'est vraiment pas une solution viable, et c'était déjà clair en
1990 que faire hériter tout d'Object n'était pas une bonne solution.
Et donc, on n'a pas voulu attendre que la technologie se stabilise.
Et disons le clair, pour implémenter mes quatre classes ci-dessus,
ce que faisait CFront ou Borland était largement suffisant. Du coup,
la précipitation des fournisseurs, à une époque où peut-être il
aurait mieux fallu expérimenter un peu plus. Pour bien savoir ce qui
était mieux.

Même aujourd'hui, en restrospect, je ne sais pas quelle solution il
aurait fallu adopter. Je connais bien les problèmes de ce qu'on a fait,
parce que je les vis tous les jours. D'un côté, je me dis qu'il aurait
fallu une norme rapide (disons 1995), quitte à laisser les templates,
les exceptions, et la bibliothèque standard (sauf iostream) pour plus
tard. Réalistiquement, en revanche, je ne crois pas qu'on aurait pû
sortir une norme sans au moins une classe de string et une classe de
vecteur -- et réalistiquement, en sachant qu'il existe une technologie
de templates, aussi primitive soit-elle, est-ce qu'on aurait pû
normaliser une classe vecteur qui n'est pas templaté (disons sur la base
de <generic.h>). Et évidemment, il fallait changer new pour qu'il lève
une exception le plus tôt possible -- je crois que tout le monde (même
moi) est d'accord que c'est un changement nécessaire, mais il casse tout
le code existant, et plus on traine à le faire, plus il y a du code à
casser.

Parfois je me dis que de toute façon, les templates, ce n'est pas
l'outil idéal pour la méta-programmation, qu'on peut faire mieux. Et
qu'il aurait été préférable à simplement normaliser ce que faisait
CFront, avec tout ses défauts, parce que ça suffit pour les classes de
collections et les utilisations simples, et que comme ça, on prend le
temps pour dévélopper un outil de méta-programmation plus convenable.

Mais c'est de la spéculation. On sait les résultats des choix qu'on a
fait. On n'en sait jamais des choix qu'on n'a pas fait.

--
James Kanze GABI Software http://www.gabi-soft.fr
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

kanze

05/10/2004 à 09:28

Dimitri Papadopoulos-Orfanos wrote
in message news:<4161b690$0$15753$...

Ceux d'entre vous dont le souci premier est d'écrire des programmes
qui marchent auraient dû savoir que « this->f() » marche dans les
deux cas (recherche de noms en deux phases ou non).

Hum, comment peut-on le savoir ?

Tu es censé être membre du comité de normalisation, et de lire en détail
tous les papiers qui y sortent.

Sérieusement, tu n'es certainement pas seul.

Je sais bien que nul n'est censé ignorer la loi, mais de là à demander
aux programmeurs C++ de comprendre la norme C++... Si c'était le cas,
il n y'aurait plus beaucoup de prorgammeurs C++.

En passant, si tu développes en C++, la loi, ce n'est pas la norme, mais
les spécifications de ton compilateur. Parce que malheureusement, les
implémenteurs des compilateurs ignorent allegrement la norme ; ils la
citent à l'occasion qu'un changement dans le compilateur casse ton code,
mais ils n'en implémentent que bon leur semble, au gré de leurs propres
volentés.

J'aimais bien le C++ quand j'étais plus jeune et que je travaillais
avec une poignée de gens qui comprennaient les très nombreuses
subtilités de ce langage. Avec l'âge, le recul, la nécessité de
travailler avec des programmeurs moins pointus, de maintenir du vieux
code, etc. eh bien je ne conseillerais à personne de démarrer un
nouveau projet en C++.

Je te comprends, mais que sont les alternatifs ? Java ne marche pas. Et
trouver les environements de développement Ada 95 n'est pas toujours
facile.

Mieux vaut utiliser Java, C#, Python ou Objective-C, avec
éventuellement C/C++ pour les parties à optimiser.

Java ne marche pas, C# est propriétaire, Objective-C est mort (et ne
donnait de toute façon pas la sécurité des types) et Python n'est qu'un
langage de script -- je ne le connais pas bien, mais je doute qu'il
convient pour de gros projets.

C'est vraiment terrible de travailler avec un langage qui nécessite
des études de "droit du langage informatique" pour faire des
programmes qui tiennent plus de deux-trois ans.

Il reste qu'il y en a un grand sous-ensemble qui marche, et qui n'est
pas si difficile que ça à utiliser. Considérons quelque chose comme la
résolution du surcharge, par exemple. Moi-même, je serais obligé à me
rétourner à la norme chaque fois pour en savoir les règles exactes ;
elles sont de loin trop compliquées pour pouvoir être appliquer dans la
programmation quotidienne. MAIS... tant que tu ne fais que les choses
raisonables, sans pousser, elles donnent des résultats intuitivement
corrects, et en tout cas tout à fait acceptables. Du coup, je n'y pense
même pas, et mes programmes marchent quand même.

--
James Kanze GABI Software http://www.gabi-soft.fr
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

Dimitri Papadopoulos-Orfanos <dpo.remove@club-internet.decoy.fr> wrote
in message news:<4161b690$0$15753$7a628cd7@news.club-internet.fr>...

Ceux d'entre vous dont le souci premier est d'écrire des programmes
qui marchent auraient dû savoir que « this->f() » marche dans les
deux cas (recherche de noms en deux phases ou non).

Hum, comment peut-on le savoir ?

Tu es censé être membre du comité de normalisation, et de lire en détail
tous les papiers qui y sortent.

Sérieusement, tu n'es certainement pas seul.

Je sais bien que nul n'est censé ignorer la loi, mais de là à demander
aux programmeurs C++ de comprendre la norme C++... Si c'était le cas,
il n y'aurait plus beaucoup de prorgammeurs C++.

En passant, si tu développes en C++, la loi, ce n'est pas la norme, mais
les spécifications de ton compilateur. Parce que malheureusement, les
implémenteurs des compilateurs ignorent allegrement la norme ; ils la
citent à l'occasion qu'un changement dans le compilateur casse ton code,
mais ils n'en implémentent que bon leur semble, au gré de leurs propres
volentés.

J'aimais bien le C++ quand j'étais plus jeune et que je travaillais
avec une poignée de gens qui comprennaient les très nombreuses
subtilités de ce langage. Avec l'âge, le recul, la nécessité de
travailler avec des programmeurs moins pointus, de maintenir du vieux
code, etc. eh bien je ne conseillerais à personne de démarrer un
nouveau projet en C++.

Je te comprends, mais que sont les alternatifs ? Java ne marche pas. Et
trouver les environements de développement Ada 95 n'est pas toujours
facile.

Mieux vaut utiliser Java, C#, Python ou Objective-C, avec
éventuellement C/C++ pour les parties à optimiser.

Java ne marche pas, C# est propriétaire, Objective-C est mort (et ne
donnait de toute façon pas la sécurité des types) et Python n'est qu'un
langage de script -- je ne le connais pas bien, mais je doute qu'il
convient pour de gros projets.

C'est vraiment terrible de travailler avec un langage qui nécessite
des études de "droit du langage informatique" pour faire des
programmes qui tiennent plus de deux-trois ans.

Il reste qu'il y en a un grand sous-ensemble qui marche, et qui n'est
pas si difficile que ça à utiliser. Considérons quelque chose comme la
résolution du surcharge, par exemple. Moi-même, je serais obligé à me
rétourner à la norme chaque fois pour en savoir les règles exactes ;
elles sont de loin trop compliquées pour pouvoir être appliquer dans la
programmation quotidienne. MAIS... tant que tu ne fais que les choses
raisonables, sans pousser, elles donnent des résultats intuitivement
corrects, et en tout cas tout à fait acceptables. Du coup, je n'y pense
même pas, et mes programmes marchent quand même.

--
James Kanze GABI Software http://www.gabi-soft.fr
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

Vous avez filtré cet utilisateur ! Consultez son message

Dimitri Papadopoulos-Orfanos wrote
in message news:<4161b690$0$15753$...

Ceux d'entre vous dont le souci premier est d'écrire des programmes
qui marchent auraient dû savoir que « this->f() » marche dans les
deux cas (recherche de noms en deux phases ou non).

Hum, comment peut-on le savoir ?

Tu es censé être membre du comité de normalisation, et de lire en détail
tous les papiers qui y sortent.

Sérieusement, tu n'es certainement pas seul.

Je sais bien que nul n'est censé ignorer la loi, mais de là à demander
aux programmeurs C++ de comprendre la norme C++... Si c'était le cas,
il n y'aurait plus beaucoup de prorgammeurs C++.

En passant, si tu développes en C++, la loi, ce n'est pas la norme, mais
les spécifications de ton compilateur. Parce que malheureusement, les
implémenteurs des compilateurs ignorent allegrement la norme ; ils la
citent à l'occasion qu'un changement dans le compilateur casse ton code,
mais ils n'en implémentent que bon leur semble, au gré de leurs propres
volentés.

J'aimais bien le C++ quand j'étais plus jeune et que je travaillais
avec une poignée de gens qui comprennaient les très nombreuses
subtilités de ce langage. Avec l'âge, le recul, la nécessité de
travailler avec des programmeurs moins pointus, de maintenir du vieux
code, etc. eh bien je ne conseillerais à personne de démarrer un
nouveau projet en C++.

Je te comprends, mais que sont les alternatifs ? Java ne marche pas. Et
trouver les environements de développement Ada 95 n'est pas toujours
facile.

Mieux vaut utiliser Java, C#, Python ou Objective-C, avec
éventuellement C/C++ pour les parties à optimiser.

Java ne marche pas, C# est propriétaire, Objective-C est mort (et ne
donnait de toute façon pas la sécurité des types) et Python n'est qu'un
langage de script -- je ne le connais pas bien, mais je doute qu'il
convient pour de gros projets.

C'est vraiment terrible de travailler avec un langage qui nécessite
des études de "droit du langage informatique" pour faire des
programmes qui tiennent plus de deux-trois ans.

Il reste qu'il y en a un grand sous-ensemble qui marche, et qui n'est
pas si difficile que ça à utiliser. Considérons quelque chose comme la
résolution du surcharge, par exemple. Moi-même, je serais obligé à me
rétourner à la norme chaque fois pour en savoir les règles exactes ;
elles sont de loin trop compliquées pour pouvoir être appliquer dans la
programmation quotidienne. MAIS... tant que tu ne fais que les choses
raisonables, sans pousser, elles donnent des résultats intuitivement
corrects, et en tout cas tout à fait acceptables. Du coup, je n'y pense
même pas, et mes programmes marchent quand même.

--
James Kanze GABI Software http://www.gabi-soft.fr
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

Arnaud Meurgues

05/10/2004 à 09:57

wrote:

Java ne marche pas, C# est propriétaire,

J'ai du mal à voir en quoi C# est plus propriétaire que Java.

--
Arnaud
(Supprimez les geneurs pour me répondre)

Marc Boyer

05/10/2004 à 09:59

Dimitri Papadopoulos-Orfanos wrote:

J'aimais bien le C++ quand j'étais plus jeune et que je travaillais avec
une poignée de gens qui comprennaient les très nombreuses subtilités de
ce langage. Avec l'âge, le recul, la nécessité de travailler avec des
programmeurs moins pointus, de maintenir du vieux code, etc. eh bien je
ne conseillerais à personne de démarrer un nouveau projet en C++. Mieux
vaut utiliser Java, C#, Python ou Objective-C, avec éventuellement C/C++
pour les parties à optimiser.

Pas Ada ?

Marc Boyer
--
La contractualisation de la recherche, c'est me donner de l'argent pour
faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce
que je sais faire, je le fais sans moyens...

Gabriel Dos Reis

05/10/2004 à 15:25

Marc Boyer writes:

| Dimitri Papadopoulos-Orfanos wrote:
| > J'aimais bien le C++ quand j'étais plus jeune et que je travaillais avec
| > une poignée de gens qui comprennaient les très nombreuses subtilités de
| > ce langage. Avec l'âge, le recul, la nécessité de travailler avec des
| > programmeurs moins pointus, de maintenir du vieux code, etc. eh bien je
| > ne conseillerais à personne de démarrer un nouveau projet en C++. Mieux
| > vaut utiliser Java, C#, Python ou Objective-C, avec éventuellement C/C++
| > pour les parties à optimiser.
|
| Pas Ada ?

Ada est mort, ou sur le point de l'être.

-- Gaby

Gabriel Dos Reis

05/10/2004 à 15:34

writes:

[...]

| N'est-ce pas ? En ce qui concerne la qualité des compilateurs, on en a
| fait du progrès, même s'il en reste à faire. Mais on a encore le
| problème qu'il n'y a pas deux compilateurs qui implémentent le même
| sous-ensemble de la norme.

Tu viens de dire dans un autre message qu'il y a un sous-ensemble
stable qui marche. Comment peux-tu avoir un sous-ensemble stable qui
marche si tu n'as pas deux compilateurs qui implémente le même
sous-ensemble de la norme ?

[...]

| Parfois je me dis que de toute façon, les templates, ce n'est pas
| l'outil idéal pour la méta-programmation, qu'on peut faire mieux. Et

C'est un non-argument.
Les templates de la norme n'ont pas été normalisés ou conçus avec le
but de faire de la méta-programmation.

-- Gaby

Marc Boyer

05/10/2004 à 16:12

Gabriel Dos Reis wrote:

Marc Boyer writes:
|
| Pas Ada ?

Ada est mort, ou sur le point de l'être.

Tu as un communiqué de son médecin traitant à faire valoir ?
Les derniers échos que j'avais eut sur le sujet étaient
au contraire que le support de gnat était depuis quelques
années de très bonne qualité.
Mais tu as surement des informations plus fiables que les
miennes.

Marc Boyer
--
La contractualisation de la recherche, c'est me donner de l'argent pour
faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce
que je sais faire, je le fais sans moyens...

Gabriel Dos Reis

05/10/2004 à 18:13

Marc Boyer writes:

| Gabriel Dos Reis wrote:
| > Marc Boyer writes:
| >|
| >| Pas Ada ?
| >
| > Ada est mort, ou sur le point de l'être.
|
| Tu as un communiqué de son médecin traitant à faire valoir ?

Plus ou moins, mais tu n'es pas qualifié pour le voir :-)

| Les derniers échos que j'avais eut sur le sujet étaient
| au contraire que le support de gnat était depuis quelques
| années de très bonne qualité.
| Mais tu as surement des informations plus fiables que les
| miennes.

La santé du langage Ada ne se limite pas à la santé de Gnat.

Il faut voir ce qu'ils appellent ici le « user base ».

Les traditionnels gros utilisateurs « industriels » l'abandonnent.
Et évidemment, cela provoque un accès de fièvre jaune dans des
quatiers généraux de corporations qui ont basé leur survie sur Ada.

-- Gaby
PS : au fait, l'engin sur Mars mouline C++, il est aussi commandé par
C++ sur Terre. Et il est possible que C++ aille sur Jupiter aussi.

Marc Boyer

06/10/2004 à 09:21

Gabriel Dos Reis wrote:

Marc Boyer writes:
| Gabriel Dos Reis wrote:
| > Ada est mort, ou sur le point de l'être.
|
| Tu as un communiqué de son médecin traitant à faire valoir ?

Plus ou moins, mais tu n'es pas qualifié pour le voir :-)

J'adore ce genre de réponse.

| Les derniers échos que j'avais eut sur le sujet étaient
| au contraire que le support de gnat était depuis quelques
| années de très bonne qualité.
| Mais tu as surement des informations plus fiables que les
| miennes.

La santé du langage Ada ne se limite pas à la santé de Gnat.

Non surement pas en effet, mais disposer d'une implémentation
libre et de qualité me semble tout de même un atout pour un
langage.

Il faut voir ce qu'ils appellent ici le « user base ».

Là, je ne suis plus.

Les traditionnels gros utilisateurs « industriels » l'abandonnent.
Et évidemment, cela provoque un accès de fièvre jaune dans des
quatiers généraux de corporations qui ont basé leur survie sur Ada.

Ca, j'imagine bien.

PS : au fait, l'engin sur Mars mouline C++, il est aussi commandé par
C++ sur Terre. Et il est possible que C++ aille sur Jupiter aussi.

Fortran était déjà allé autour de Jupiter il me semble, non ?
En fait, sans connaitre les critères de choix de C++ pour ses
missions, je ne suis pas tellement convaincu. Il n'y a que sur
fclc++ que j'en entendu des justifications rationnelles au
choix d'un langage.
Dans les industriels rencontrés au jour le jour, le choix
d'un langage par rapport à un projet m'a toujours parus
globalement irrationnel (sauf le "on change pas, car celui
là, on le connait bien").

Marc Boyer
--
La contractualisation de la recherche, c'est me donner de l'argent pour
faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce
que je sais faire, je le fais sans moyens...

membres d'une base dépendante ?

10 réponses

Veuillez sélectionner un problème