Bonjour,
Mon problème est peut-être plus C que C++, mais je le fais facilement
apparaître avec new[], et de plus c'est la réponse de la norme C++ qui
m'intéresse le plus.
Si on définit une variable pointeur de fonction :
int(*pF)(double, double) = NULL;
on a la facilité d'utiliser ou non, indifféremment, les opérateurrs * et & ,
ou plus exactement on a exceptionnellement la possibilité de les omettre :
int fonct(double x, double y) {return (int)(x * y);}
...
pF = &fonct;
pF = fonct;
...
x = pF(4.0, 2.0);
x = (*pF)(4.0, 2.0);
Question : qu'en dit la norme ? (pas pu trouver)
Si je désire un tableau de fonctions dont la taile sera déterminée à
l'exécution, je dois faire :
int(**pF)(double, double) = NULL;
Ensuite, en C comme en C++ :
int n = 12;
pF = (int(**)(double, double))malloc(n * sizeof(int(*)(double, double)));
x = pF[4](4.0, 2.0);
Pas beau, puisque pF n'a pas le même type dans les deux lignes, mais logique
au vu de ce qui précède.
Passons au new[] :
pF = new (int(*)(double, double))[n];
La famille du Gnou accepte, et le résultat est celui attendu. Chez Borland,
c'est non., conversion de type impossible
Les Gnou interprètent pF en fonction de l'appel de malloc() ou de new[], pas
Borland. Je ne suis pas contre, je préfèrerais même que ne soient pas
autorisées les facilités initiales, donc que le typedef s'impose de
lui-même.
Question : Qu'en dit la norme ? Qui a raison ?
Bien entendu, un typedef s'impose, et tout rentre dans l'ordre.
typedef int(*Fonc_Type)(double, double);
Fonc_Type* pF1;
Fonc_Type* pF2;
int n = 12;
pF1 = (Fonc_Type*) malloc(n * sizeof(Fonc_Type));
pF2 = new Fonc_Type[n];
pF1[5] = f1;
pF2[6] = f2;
En fait, si j'avais Ritchie devant moi, je lui demanderais pourquoi, dans son langage original, on peut écrire v pour &v[0] au lieu d'exiger & comme pour les fonctions... La solution ANSI me semble plus uniforme.
???
Ton interrogation signifie quoi dans ce cas-ci ? Tu dois t'ennuyer un peu (ça me surprend) si tu veux qu'on essaie de deviner. Mais
non pas vraiment -- inventer de nouveaux outils pour C++ est un travail a plein.
C'est bien ce que je pensais. Et ça doit être assez intéressant en plus... Chanceux ! (j'espère que tu te sens privilégié un peu)
bon, on peut jouer. Je vais supposer que tu ne comprends pas mon questionnement, mais évidemment tu me diras que ce n'est pas que tu voulais dire... Je reformule quand même et je pose une question sérieuse, qui m'intéresse. Pourquoi a-t-on besoin de la conversion implicite du nom d'un vecteur en adresse de son premier élément, plus que de la conversion du nom d'une fonction en adresse de cette fonction ?
Mais, on N'a PAS BESOIN de cette conversion. C'est une plaie qu'il aurait fallu ne pas multiplier par un facteur plus grand que 1.
Oui, je suis d'accord. Mais la question demeure... (sans réponse en fait, car on n'a pas Ritchie devant nous :-)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:m3vfnlw5kd.fsf@uniton.integrable-solutions.net, Gabriel Dos
"Michel Michaud" <mm@gdzid.com> writes:
En fait, si j'avais Ritchie devant moi, je lui demanderais
pourquoi, dans son langage original, on peut écrire v pour
&v[0] au lieu d'exiger & comme pour les fonctions... La
solution ANSI me semble plus uniforme.
???
Ton interrogation signifie quoi dans ce cas-ci ? Tu dois t'ennuyer
un peu (ça me surprend) si tu veux qu'on essaie de deviner. Mais
non pas vraiment -- inventer de nouveaux outils pour C++ est un
travail a plein.
C'est bien ce que je pensais. Et ça doit être assez intéressant
en plus... Chanceux ! (j'espère que tu te sens privilégié un peu)
bon, on peut jouer. Je vais supposer que tu ne comprends pas mon
questionnement, mais évidemment tu me diras que ce n'est pas que
tu voulais dire... Je reformule quand même et je pose une question
sérieuse, qui m'intéresse. Pourquoi a-t-on besoin de la conversion
implicite du nom d'un vecteur en adresse de son premier élément,
plus que de la conversion du nom d'une fonction en adresse de
cette fonction ?
Mais, on N'a PAS BESOIN de cette conversion. C'est une plaie qu'il
aurait fallu ne pas multiplier par un facteur plus grand que 1.
Oui, je suis d'accord. Mais la question demeure... (sans réponse
en fait, car on n'a pas Ritchie devant nous :-)
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
En fait, si j'avais Ritchie devant moi, je lui demanderais pourquoi, dans son langage original, on peut écrire v pour &v[0] au lieu d'exiger & comme pour les fonctions... La solution ANSI me semble plus uniforme.
???
Ton interrogation signifie quoi dans ce cas-ci ? Tu dois t'ennuyer un peu (ça me surprend) si tu veux qu'on essaie de deviner. Mais
non pas vraiment -- inventer de nouveaux outils pour C++ est un travail a plein.
C'est bien ce que je pensais. Et ça doit être assez intéressant en plus... Chanceux ! (j'espère que tu te sens privilégié un peu)
bon, on peut jouer. Je vais supposer que tu ne comprends pas mon questionnement, mais évidemment tu me diras que ce n'est pas que tu voulais dire... Je reformule quand même et je pose une question sérieuse, qui m'intéresse. Pourquoi a-t-on besoin de la conversion implicite du nom d'un vecteur en adresse de son premier élément, plus que de la conversion du nom d'une fonction en adresse de cette fonction ?
Mais, on N'a PAS BESOIN de cette conversion. C'est une plaie qu'il aurait fallu ne pas multiplier par un facteur plus grand que 1.
Oui, je suis d'accord. Mais la question demeure... (sans réponse en fait, car on n'a pas Ritchie devant nous :-)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Michel Michaud
Dans news:,
L'uniformité souhaitable serait que tous les types fonctionnent de la même manière -- que ce soit un int, une classe, une table ou une fonction. Pour des raisons historiques, les tables en C sont des types éstrophiées. On a discuté la possibilité de corriger ce problème en C++, mais le consensus était plutôt de l'ordre que c'était impossible sans rompre complètement avec C, et que ce
Je sais qu'on est dans fclc++, mais mon argument portait en fait sur le langage C (en gros, je suis d'accord qu'il faut permettre la conversion implicite en adresse, en C, pour des raisons d'uniformité. En C++, je crois qu'il faudrait tout enlever les conversions implicites ou la permettre aussi sur les pointeurs de fonction membre... En fait, j'aimerais mieux enlever toutes les conversions implicites, y compris celles de base comme double -> int !)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:d6652001.0401090500.1ef33520@posting.google.com,
L'uniformité souhaitable serait que tous les types fonctionnent de
la même manière -- que ce soit un int, une classe, une table ou une
fonction. Pour des raisons historiques, les tables en C sont des
types éstrophiées. On a discuté la possibilité de corriger ce
problème en C++, mais le consensus était plutôt de l'ordre que
c'était impossible sans rompre complètement avec C, et que ce
Je sais qu'on est dans fclc++, mais mon argument portait en
fait sur le langage C (en gros, je suis d'accord qu'il faut
permettre la conversion implicite en adresse, en C, pour des
raisons d'uniformité. En C++, je crois qu'il faudrait tout
enlever les conversions implicites ou la permettre aussi sur
les pointeurs de fonction membre... En fait, j'aimerais mieux
enlever toutes les conversions implicites, y compris celles de
base comme double -> int !)
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
L'uniformité souhaitable serait que tous les types fonctionnent de la même manière -- que ce soit un int, une classe, une table ou une fonction. Pour des raisons historiques, les tables en C sont des types éstrophiées. On a discuté la possibilité de corriger ce problème en C++, mais le consensus était plutôt de l'ordre que c'était impossible sans rompre complètement avec C, et que ce
Je sais qu'on est dans fclc++, mais mon argument portait en fait sur le langage C (en gros, je suis d'accord qu'il faut permettre la conversion implicite en adresse, en C, pour des raisons d'uniformité. En C++, je crois qu'il faudrait tout enlever les conversions implicites ou la permettre aussi sur les pointeurs de fonction membre... En fait, j'aimerais mieux enlever toutes les conversions implicites, y compris celles de base comme double -> int !)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Gabriel Dos Reis
"Michel Michaud" writes:
| >> bon, on peut jouer. Je vais supposer que tu ne comprends pas mon | >> questionnement, mais évidemment tu me diras que ce n'est pas que | >> tu voulais dire... Je reformule quand même et je pose une question | >> sérieuse, qui m'intéresse. Pourquoi a-t-on besoin de la conversion | >> implicite du nom d'un vecteur en adresse de son premier élément, | >> plus que de la conversion du nom d'une fonction en adresse de | >> cette fonction ? | > | > Mais, on N'a PAS BESOIN de cette conversion. C'est une plaie qu'il | > aurait fallu ne pas multiplier par un facteur plus grand que 1. | | Oui, je suis d'accord. Mais la question demeure... (sans réponse | en fait, car on n'a pas Ritchie devant nous :-)
Hmm, je crois que j'ai repondu : on n'en a pas besoin. Par contre a la question : pourquoi est-elle la ? La reponse est accident historique.
-- Gaby
"Michel Michaud" <mm@gdzid.com> writes:
| >> bon, on peut jouer. Je vais supposer que tu ne comprends pas mon
| >> questionnement, mais évidemment tu me diras que ce n'est pas que
| >> tu voulais dire... Je reformule quand même et je pose une question
| >> sérieuse, qui m'intéresse. Pourquoi a-t-on besoin de la conversion
| >> implicite du nom d'un vecteur en adresse de son premier élément,
| >> plus que de la conversion du nom d'une fonction en adresse de
| >> cette fonction ?
| >
| > Mais, on N'a PAS BESOIN de cette conversion. C'est une plaie qu'il
| > aurait fallu ne pas multiplier par un facteur plus grand que 1.
|
| Oui, je suis d'accord. Mais la question demeure... (sans réponse
| en fait, car on n'a pas Ritchie devant nous :-)
Hmm, je crois que j'ai repondu : on n'en a pas besoin.
Par contre a la question : pourquoi est-elle la ? La reponse est
accident historique.
| >> bon, on peut jouer. Je vais supposer que tu ne comprends pas mon | >> questionnement, mais évidemment tu me diras que ce n'est pas que | >> tu voulais dire... Je reformule quand même et je pose une question | >> sérieuse, qui m'intéresse. Pourquoi a-t-on besoin de la conversion | >> implicite du nom d'un vecteur en adresse de son premier élément, | >> plus que de la conversion du nom d'une fonction en adresse de | >> cette fonction ? | > | > Mais, on N'a PAS BESOIN de cette conversion. C'est une plaie qu'il | > aurait fallu ne pas multiplier par un facteur plus grand que 1. | | Oui, je suis d'accord. Mais la question demeure... (sans réponse | en fait, car on n'a pas Ritchie devant nous :-)
Hmm, je crois que j'ai repondu : on n'en a pas besoin. Par contre a la question : pourquoi est-elle la ? La reponse est accident historique.
-- Gaby
Michel Michaud
Dans news:, Gabriel Dos
"Michel Michaud" writes:
tu voulais dire... Je reformule quand même et je pose une question sérieuse, qui m'intéresse. Pourquoi a-t-on besoin de la conversion implicite du nom d'un vecteur en adresse de son premier élément, plus que de la conversion du nom d'une fonction en adresse de cette fonction ?
Mais, on N'a PAS BESOIN de cette conversion. C'est une plaie qu'il aurait fallu ne pas multiplier par un facteur plus grand que 1.
Oui, je suis d'accord. Mais la question demeure... (sans réponse en fait, car on n'a pas Ritchie devant nous :-)
Hmm, je crois que j'ai repondu : on n'en a pas besoin. Par contre a la question : pourquoi est-elle la ? La reponse est accident historique.
Je comprends bien pourquoi la conversion des vecteurs est là, mais ce n'est pas exactement ma question, si tu relis bien. Je ne demandais pas pourquoi on a besoin de la conversion dans le cas des vecteurs, mais bien pourquoi on en avait « plus » besoin que celle des fonctions i.e. pourquoi Ritchie a mis l'une mais pas l'autre. J'imagine qu'il n'y avait peut-être pas de pointeur sur fonction en B, ou que le simple nom de la fonction, sans appel explicite avec (), signifiait autre chose (comme un appel ! à la Pascal).
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:m3k741au4h.fsf@uniton.integrable-solutions.net, Gabriel Dos
"Michel Michaud" <mm@gdzid.com> writes:
tu voulais dire... Je reformule quand même et je pose une
question sérieuse, qui m'intéresse. Pourquoi a-t-on besoin de la
conversion implicite du nom d'un vecteur en adresse de son
premier élément, plus que de la conversion du nom d'une fonction
en adresse de cette fonction ?
Mais, on N'a PAS BESOIN de cette conversion. C'est une plaie qu'il
aurait fallu ne pas multiplier par un facteur plus grand que 1.
Oui, je suis d'accord. Mais la question demeure... (sans réponse
en fait, car on n'a pas Ritchie devant nous :-)
Hmm, je crois que j'ai repondu : on n'en a pas besoin.
Par contre a la question : pourquoi est-elle la ? La reponse est
accident historique.
Je comprends bien pourquoi la conversion des vecteurs est là,
mais ce n'est pas exactement ma question, si tu relis bien. Je
ne demandais pas pourquoi on a besoin de la conversion dans
le cas des vecteurs, mais bien pourquoi on en avait « plus »
besoin que celle des fonctions i.e. pourquoi Ritchie a mis
l'une mais pas l'autre. J'imagine qu'il n'y avait peut-être
pas de pointeur sur fonction en B, ou que le simple nom de la
fonction, sans appel explicite avec (), signifiait autre chose
(comme un appel ! à la Pascal).
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
tu voulais dire... Je reformule quand même et je pose une question sérieuse, qui m'intéresse. Pourquoi a-t-on besoin de la conversion implicite du nom d'un vecteur en adresse de son premier élément, plus que de la conversion du nom d'une fonction en adresse de cette fonction ?
Mais, on N'a PAS BESOIN de cette conversion. C'est une plaie qu'il aurait fallu ne pas multiplier par un facteur plus grand que 1.
Oui, je suis d'accord. Mais la question demeure... (sans réponse en fait, car on n'a pas Ritchie devant nous :-)
Hmm, je crois que j'ai repondu : on n'en a pas besoin. Par contre a la question : pourquoi est-elle la ? La reponse est accident historique.
Je comprends bien pourquoi la conversion des vecteurs est là, mais ce n'est pas exactement ma question, si tu relis bien. Je ne demandais pas pourquoi on a besoin de la conversion dans le cas des vecteurs, mais bien pourquoi on en avait « plus » besoin que celle des fonctions i.e. pourquoi Ritchie a mis l'une mais pas l'autre. J'imagine qu'il n'y avait peut-être pas de pointeur sur fonction en B, ou que le simple nom de la fonction, sans appel explicite avec (), signifiait autre chose (comme un appel ! à la Pascal).
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
kanze
"Michel Michaud" wrote in message news:<QgCLb.107883$...
Dans news:, Gabriel Dos
"Michel Michaud" writes:
tu voulais dire... Je reformule quand même et je pose une question sérieuse, qui m'intéresse. Pourquoi a-t-on besoin de la conversion implicite du nom d'un vecteur en adresse de son premier élément, plus que de la conversion du nom d'une fonction en adresse de cette fonction ?
Mais, on N'a PAS BESOIN de cette conversion. C'est une plaie qu'il aurait fallu ne pas multiplier par un facteur plus grand que 1.
Oui, je suis d'accord. Mais la question demeure... (sans réponse en fait, car on n'a pas Ritchie devant nous :-)
Hmm, je crois que j'ai repondu : on n'en a pas besoin. Par contre a la question : pourquoi est-elle la ? La reponse est accident historique.
Je comprends bien pourquoi la conversion des vecteurs est là, mais ce n'est pas exactement ma question, si tu relis bien. Je ne demandais pas pourquoi on a besoin de la conversion dans le cas des vecteurs, mais bien pourquoi on en avait « plus » besoin que celle des fonctions i.e. pourquoi Ritchie a mis l'une mais pas l'autre. J'imagine qu'il n'y avait peut-être pas de pointeur sur fonction en B, ou que le simple nom de la fonction, sans appel explicite avec (), signifiait autre chose (comme un appel ! à la Pascal).
Strictement parlant, il n'y avait pas de pointeur à fonction en B, parce qu'il n'y avait pas de pointer (ni d'autre type) en B. Dans le « Users'Reference to B » (http://cm.bell-labs.com/cm/cs/who/dmr/kbman.html), je n'arrive pas (rapidement) à déterminer s'il fallait prendre l'adresse d'une fonction ou non avec l'opérateur &, mais c'est sûr qu'on pouvait les appeler indirectement sans l'opérateur * -- un des exemples dans le document est : (b? f:g[i] )(1, x>1)
Dans la contexte de B, ça se comprend. En revanche, je ne sais pas pourquoi, quand ils ont passé de B en C, ils ont changé les fonctions, et non les tableaux. Logiquement, avec le typage plus fort de C, on s'attendrait à ce que les deux changent.
Pour ceux que ça intéresse, il y a pas mal de renseignements historiques sur C et Unix à la site de Dennis Ritchie (http://www.cs.bell-labs.com/who/dmr/index.html). Ou dans la section sur l'histoire à http://www.lysator.liu.se/c/.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Michel Michaud" <mm@gdzid.com> wrote in message
news:<QgCLb.107883$BA6.2077562@news20.bellglobal.com>...
Dans news:m3k741au4h.fsf@uniton.integrable-solutions.net, Gabriel Dos
"Michel Michaud" <mm@gdzid.com> writes:
tu voulais dire... Je reformule quand même et je pose une
question sérieuse, qui m'intéresse. Pourquoi a-t-on besoin de la
conversion implicite du nom d'un vecteur en adresse de son
premier élément, plus que de la conversion du nom d'une fonction
en adresse de cette fonction ?
Mais, on N'a PAS BESOIN de cette conversion. C'est une plaie qu'il
aurait fallu ne pas multiplier par un facteur plus grand que 1.
Oui, je suis d'accord. Mais la question demeure... (sans réponse en
fait, car on n'a pas Ritchie devant nous :-)
Hmm, je crois que j'ai repondu : on n'en a pas besoin. Par contre a
la question : pourquoi est-elle la ? La reponse est accident
historique.
Je comprends bien pourquoi la conversion des vecteurs est là,
mais ce n'est pas exactement ma question, si tu relis bien. Je
ne demandais pas pourquoi on a besoin de la conversion dans
le cas des vecteurs, mais bien pourquoi on en avait « plus »
besoin que celle des fonctions i.e. pourquoi Ritchie a mis
l'une mais pas l'autre. J'imagine qu'il n'y avait peut-être
pas de pointeur sur fonction en B, ou que le simple nom de la
fonction, sans appel explicite avec (), signifiait autre chose
(comme un appel ! à la Pascal).
Strictement parlant, il n'y avait pas de pointeur à fonction en B, parce
qu'il n'y avait pas de pointer (ni d'autre type) en B. Dans le
« Users'Reference to B »
(http://cm.bell-labs.com/cm/cs/who/dmr/kbman.html), je n'arrive pas
(rapidement) à déterminer s'il fallait prendre l'adresse d'une fonction
ou non avec l'opérateur &, mais c'est sûr qu'on pouvait les appeler
indirectement sans l'opérateur * -- un des exemples dans le document
est :
(b? f:g[i] )(1, x>1)
Dans la contexte de B, ça se comprend. En revanche, je ne sais pas
pourquoi, quand ils ont passé de B en C, ils ont changé les fonctions,
et non les tableaux. Logiquement, avec le typage plus fort de C, on
s'attendrait à ce que les deux changent.
Pour ceux que ça intéresse, il y a pas mal de renseignements historiques
sur C et Unix à la site de Dennis Ritchie
(http://www.cs.bell-labs.com/who/dmr/index.html). Ou dans la section sur
l'histoire à http://www.lysator.liu.se/c/.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Michel Michaud" wrote in message news:<QgCLb.107883$...
Dans news:, Gabriel Dos
"Michel Michaud" writes:
tu voulais dire... Je reformule quand même et je pose une question sérieuse, qui m'intéresse. Pourquoi a-t-on besoin de la conversion implicite du nom d'un vecteur en adresse de son premier élément, plus que de la conversion du nom d'une fonction en adresse de cette fonction ?
Mais, on N'a PAS BESOIN de cette conversion. C'est une plaie qu'il aurait fallu ne pas multiplier par un facteur plus grand que 1.
Oui, je suis d'accord. Mais la question demeure... (sans réponse en fait, car on n'a pas Ritchie devant nous :-)
Hmm, je crois que j'ai repondu : on n'en a pas besoin. Par contre a la question : pourquoi est-elle la ? La reponse est accident historique.
Je comprends bien pourquoi la conversion des vecteurs est là, mais ce n'est pas exactement ma question, si tu relis bien. Je ne demandais pas pourquoi on a besoin de la conversion dans le cas des vecteurs, mais bien pourquoi on en avait « plus » besoin que celle des fonctions i.e. pourquoi Ritchie a mis l'une mais pas l'autre. J'imagine qu'il n'y avait peut-être pas de pointeur sur fonction en B, ou que le simple nom de la fonction, sans appel explicite avec (), signifiait autre chose (comme un appel ! à la Pascal).
Strictement parlant, il n'y avait pas de pointeur à fonction en B, parce qu'il n'y avait pas de pointer (ni d'autre type) en B. Dans le « Users'Reference to B » (http://cm.bell-labs.com/cm/cs/who/dmr/kbman.html), je n'arrive pas (rapidement) à déterminer s'il fallait prendre l'adresse d'une fonction ou non avec l'opérateur &, mais c'est sûr qu'on pouvait les appeler indirectement sans l'opérateur * -- un des exemples dans le document est : (b? f:g[i] )(1, x>1)
Dans la contexte de B, ça se comprend. En revanche, je ne sais pas pourquoi, quand ils ont passé de B en C, ils ont changé les fonctions, et non les tableaux. Logiquement, avec le typage plus fort de C, on s'attendrait à ce que les deux changent.
Pour ceux que ça intéresse, il y a pas mal de renseignements historiques sur C et Unix à la site de Dennis Ritchie (http://www.cs.bell-labs.com/who/dmr/index.html). Ou dans la section sur l'histoire à http://www.lysator.liu.se/c/.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
kanze
"Michel Michaud" wrote in message news:<rcBLb.107745$...
Dans news:,
L'uniformité souhaitable serait que tous les types fonctionnent de la même manière -- que ce soit un int, une classe, une table ou une fonction. Pour des raisons historiques, les tables en C sont des types éstrophiées. On a discuté la possibilité de corriger ce problème en C++, mais le consensus était plutôt de l'ordre que c'était impossible sans rompre complètement avec C, et que ce
Je sais qu'on est dans fclc++, mais mon argument portait en fait sur le langage C
Pas de problème. Je sais que le C++ n'existe pas dans un vide, et à moi, au moins, le contexte historique m'intéresse. J'ai simplement ajouté une indication sur l'attitude de certaines personnes sur la question. (Malheureusement, je ne me rappelle plus exactement qui -- il me semble que Tom Plum en faisait partie, mais je ne le jurerais pas.)
(en gros, je suis d'accord qu'il faut permettre la conversion implicite en adresse, en C, pour des raisons d'uniformité.
D'uniformité avec quoi ? Avec des struct ? Avec des types de bases ? Pourquoi priviléger l'uniformité avec l'exception ?
En C++, je crois qu'il faudrait tout enlever les conversions implicites ou la permettre aussi sur les pointeurs de fonction membre... En fait, j'aimerais mieux enlever toutes les conversions implicites, y compris celles de base comme double -> int !)
En ce qui concerne les conversions du type double -> int, tu n'es pas seul. Il me semble même que même Stroustrup s'est exprimé en ce sens. En revanche, int -> long ? Si je concevais un langage de zéro, je ne crois pas qu'il supporterait ce genre de conversion non plus. Mais ce langage ne serait ni C ni C++, et je vois mal un effort de l'éliminer de C ou de C++.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Michel Michaud" <mm@gdzid.com> wrote in message
news:<rcBLb.107745$BA6.2038713@news20.bellglobal.com>...
Dans news:d6652001.0401090500.1ef33520@posting.google.com,
L'uniformité souhaitable serait que tous les types fonctionnent de
la même manière -- que ce soit un int, une classe, une table ou une
fonction. Pour des raisons historiques, les tables en C sont des
types éstrophiées. On a discuté la possibilité de corriger ce
problème en C++, mais le consensus était plutôt de l'ordre que
c'était impossible sans rompre complètement avec C, et que ce
Je sais qu'on est dans fclc++, mais mon argument portait en
fait sur le langage C
Pas de problème. Je sais que le C++ n'existe pas dans un vide, et à moi,
au moins, le contexte historique m'intéresse. J'ai simplement ajouté une
indication sur l'attitude de certaines personnes sur la question.
(Malheureusement, je ne me rappelle plus exactement qui -- il me semble
que Tom Plum en faisait partie, mais je ne le jurerais pas.)
(en gros, je suis d'accord qu'il faut permettre la conversion
implicite en adresse, en C, pour des raisons d'uniformité.
D'uniformité avec quoi ? Avec des struct ? Avec des types de bases ?
Pourquoi priviléger l'uniformité avec l'exception ?
En C++, je crois qu'il faudrait tout enlever les conversions
implicites ou la permettre aussi sur les pointeurs de fonction
membre... En fait, j'aimerais mieux enlever toutes les conversions
implicites, y compris celles de base comme double -> int !)
En ce qui concerne les conversions du type double -> int, tu n'es pas
seul. Il me semble même que même Stroustrup s'est exprimé en ce sens. En
revanche, int -> long ? Si je concevais un langage de zéro, je ne crois
pas qu'il supporterait ce genre de conversion non plus. Mais ce langage
ne serait ni C ni C++, et je vois mal un effort de l'éliminer de C ou de
C++.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Michel Michaud" wrote in message news:<rcBLb.107745$...
Dans news:,
L'uniformité souhaitable serait que tous les types fonctionnent de la même manière -- que ce soit un int, une classe, une table ou une fonction. Pour des raisons historiques, les tables en C sont des types éstrophiées. On a discuté la possibilité de corriger ce problème en C++, mais le consensus était plutôt de l'ordre que c'était impossible sans rompre complètement avec C, et que ce
Je sais qu'on est dans fclc++, mais mon argument portait en fait sur le langage C
Pas de problème. Je sais que le C++ n'existe pas dans un vide, et à moi, au moins, le contexte historique m'intéresse. J'ai simplement ajouté une indication sur l'attitude de certaines personnes sur la question. (Malheureusement, je ne me rappelle plus exactement qui -- il me semble que Tom Plum en faisait partie, mais je ne le jurerais pas.)
(en gros, je suis d'accord qu'il faut permettre la conversion implicite en adresse, en C, pour des raisons d'uniformité.
D'uniformité avec quoi ? Avec des struct ? Avec des types de bases ? Pourquoi priviléger l'uniformité avec l'exception ?
En C++, je crois qu'il faudrait tout enlever les conversions implicites ou la permettre aussi sur les pointeurs de fonction membre... En fait, j'aimerais mieux enlever toutes les conversions implicites, y compris celles de base comme double -> int !)
En ce qui concerne les conversions du type double -> int, tu n'es pas seul. Il me semble même que même Stroustrup s'est exprimé en ce sens. En revanche, int -> long ? Si je concevais un langage de zéro, je ne crois pas qu'il supporterait ce genre de conversion non plus. Mais ce langage ne serait ni C ni C++, et je vois mal un effort de l'éliminer de C ou de C++.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Gabriel Dos Reis
"Michel Michaud" writes:
| Dans news:, Gabriel Dos | > "Michel Michaud" writes: | >>>> tu voulais dire... Je reformule quand même et je pose une | >>>> question sérieuse, qui m'intéresse. Pourquoi a-t-on besoin de la | >>>> conversion implicite du nom d'un vecteur en adresse de son | >>>> premier élément, plus que de la conversion du nom d'une fonction | >>>> en adresse de cette fonction ? | >>> | >>> Mais, on N'a PAS BESOIN de cette conversion. C'est une plaie qu'il | >>> aurait fallu ne pas multiplier par un facteur plus grand que 1. | >> | >> Oui, je suis d'accord. Mais la question demeure... (sans réponse | >> en fait, car on n'a pas Ritchie devant nous :-) | > | > Hmm, je crois que j'ai repondu : on n'en a pas besoin. | > Par contre a la question : pourquoi est-elle la ? La reponse est | > accident historique. | | Je comprends bien pourquoi la conversion des vecteurs est là, | mais ce n'est pas exactement ma question, si tu relis bien. Je | ne demandais pas pourquoi on a besoin de la conversion dans | le cas des vecteurs, mais bien pourquoi on en avait « plus »
et je répondais que qu'on n'en a pas besoin. A fortiori, on n'en a pas « plus » besoin.
| besoin que celle des fonctions i.e. pourquoi Ritchie a mis | l'une mais pas l'autre. J'imagine qu'il n'y avait peut-être | pas de pointeur sur fonction en B, ou que le simple nom de la | fonction, sans appel explicite avec (), signifiait autre chose | (comme un appel ! à la Pascal).
-- Gaby
"Michel Michaud" <mm@gdzid.com> writes:
| Dans news:m3k741au4h.fsf@uniton.integrable-solutions.net, Gabriel Dos
| > "Michel Michaud" <mm@gdzid.com> writes:
| >>>> tu voulais dire... Je reformule quand même et je pose une
| >>>> question sérieuse, qui m'intéresse. Pourquoi a-t-on besoin de la
| >>>> conversion implicite du nom d'un vecteur en adresse de son
| >>>> premier élément, plus que de la conversion du nom d'une fonction
| >>>> en adresse de cette fonction ?
| >>>
| >>> Mais, on N'a PAS BESOIN de cette conversion. C'est une plaie qu'il
| >>> aurait fallu ne pas multiplier par un facteur plus grand que 1.
| >>
| >> Oui, je suis d'accord. Mais la question demeure... (sans réponse
| >> en fait, car on n'a pas Ritchie devant nous :-)
| >
| > Hmm, je crois que j'ai repondu : on n'en a pas besoin.
| > Par contre a la question : pourquoi est-elle la ? La reponse est
| > accident historique.
|
| Je comprends bien pourquoi la conversion des vecteurs est là,
| mais ce n'est pas exactement ma question, si tu relis bien. Je
| ne demandais pas pourquoi on a besoin de la conversion dans
| le cas des vecteurs, mais bien pourquoi on en avait « plus »
et je répondais que qu'on n'en a pas besoin. A fortiori, on n'en a pas
« plus » besoin.
| besoin que celle des fonctions i.e. pourquoi Ritchie a mis
| l'une mais pas l'autre. J'imagine qu'il n'y avait peut-être
| pas de pointeur sur fonction en B, ou que le simple nom de la
| fonction, sans appel explicite avec (), signifiait autre chose
| (comme un appel ! à la Pascal).
| Dans news:, Gabriel Dos | > "Michel Michaud" writes: | >>>> tu voulais dire... Je reformule quand même et je pose une | >>>> question sérieuse, qui m'intéresse. Pourquoi a-t-on besoin de la | >>>> conversion implicite du nom d'un vecteur en adresse de son | >>>> premier élément, plus que de la conversion du nom d'une fonction | >>>> en adresse de cette fonction ? | >>> | >>> Mais, on N'a PAS BESOIN de cette conversion. C'est une plaie qu'il | >>> aurait fallu ne pas multiplier par un facteur plus grand que 1. | >> | >> Oui, je suis d'accord. Mais la question demeure... (sans réponse | >> en fait, car on n'a pas Ritchie devant nous :-) | > | > Hmm, je crois que j'ai repondu : on n'en a pas besoin. | > Par contre a la question : pourquoi est-elle la ? La reponse est | > accident historique. | | Je comprends bien pourquoi la conversion des vecteurs est là, | mais ce n'est pas exactement ma question, si tu relis bien. Je | ne demandais pas pourquoi on a besoin de la conversion dans | le cas des vecteurs, mais bien pourquoi on en avait « plus »
et je répondais que qu'on n'en a pas besoin. A fortiori, on n'en a pas « plus » besoin.
| besoin que celle des fonctions i.e. pourquoi Ritchie a mis | l'une mais pas l'autre. J'imagine qu'il n'y avait peut-être | pas de pointeur sur fonction en B, ou que le simple nom de la | fonction, sans appel explicite avec (), signifiait autre chose | (comme un appel ! à la Pascal).
-- Gaby
Michel Michaud
Dans news:,
(http://cm.bell-labs.com/cm/cs/who/dmr/kbman.html), je n'arrive pas (rapidement) à déterminer s'il fallait prendre l'adresse d'une fonction ou non avec l'opérateur &, mais c'est sûr qu'on pouvait les appeler indirectement sans l'opérateur * -- un des exemples dans le document est : (b? f:g[i] )(1, x>1)
Intéressant !
Dans la contexte de B, ça se comprend. En revanche, je ne sais pas pourquoi, quand ils ont passé de B en C, ils ont changé les fonctions, et non les tableaux. Logiquement, avec le typage plus fort de C, on s'attendrait à ce que les deux changent.
Alors tu penses comme moi, au niveau de l'uniformité.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:d6652001.0401120000.120325a4@posting.google.com,
(http://cm.bell-labs.com/cm/cs/who/dmr/kbman.html), je n'arrive pas
(rapidement) à déterminer s'il fallait prendre l'adresse d'une
fonction ou non avec l'opérateur &, mais c'est sûr qu'on pouvait
les appeler indirectement sans l'opérateur * -- un des exemples
dans le document est :
(b? f:g[i] )(1, x>1)
Intéressant !
Dans la contexte de B, ça se comprend. En revanche, je ne sais pas
pourquoi, quand ils ont passé de B en C, ils ont changé les
fonctions, et non les tableaux. Logiquement, avec le typage plus
fort de C, on s'attendrait à ce que les deux changent.
Alors tu penses comme moi, au niveau de l'uniformité.
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
(http://cm.bell-labs.com/cm/cs/who/dmr/kbman.html), je n'arrive pas (rapidement) à déterminer s'il fallait prendre l'adresse d'une fonction ou non avec l'opérateur &, mais c'est sûr qu'on pouvait les appeler indirectement sans l'opérateur * -- un des exemples dans le document est : (b? f:g[i] )(1, x>1)
Intéressant !
Dans la contexte de B, ça se comprend. En revanche, je ne sais pas pourquoi, quand ils ont passé de B en C, ils ont changé les fonctions, et non les tableaux. Logiquement, avec le typage plus fort de C, on s'attendrait à ce que les deux changent.
Alors tu penses comme moi, au niveau de l'uniformité.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Michel Michaud
Dans news:,
"Michel Michaud" wrote in message news:<rcBLb.107745$...
En C++, je crois qu'il faudrait tout enlever les conversions implicites ou la permettre aussi sur les pointeurs de fonction membre... En fait, j'aimerais mieux enlever toutes les conversions implicites, y compris celles de base comme double -> int !)
En ce qui concerne les conversions du type double -> int, tu n'es pas seul. Il me semble même que même Stroustrup s'est exprimé en ce sens. En revanche, int -> long ? Si je concevais un langage de zéro, je ne crois pas qu'il supporterait ce genre de conversion non plus. Mais ce langage ne serait ni C ni C++, et je vois mal un effort de l'éliminer de C ou de C++.
En fait, int->long me paraît acceptable. C'est surtout les conversions implicites avec perte possible que je trouve inacceptable, mais heureusement, les bons compilateurs vont pouvoir te donner des avertissements.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:d6652001.0401120011.2231e8cd@posting.google.com,
"Michel Michaud" <mm@gdzid.com> wrote in message
news:<rcBLb.107745$BA6.2038713@news20.bellglobal.com>...
En C++, je crois qu'il faudrait tout enlever les conversions
implicites ou la permettre aussi sur les pointeurs de fonction
membre... En fait, j'aimerais mieux enlever toutes les conversions
implicites, y compris celles de base comme double -> int !)
En ce qui concerne les conversions du type double -> int, tu n'es
pas seul. Il me semble même que même Stroustrup s'est exprimé en ce
sens. En revanche, int -> long ? Si je concevais un langage de
zéro, je ne crois pas qu'il supporterait ce genre de conversion non
plus. Mais ce langage ne serait ni C ni C++, et je vois mal un
effort de l'éliminer de C ou de C++.
En fait, int->long me paraît acceptable. C'est surtout les
conversions implicites avec perte possible que je trouve
inacceptable, mais heureusement, les bons compilateurs vont
pouvoir te donner des avertissements.
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
"Michel Michaud" wrote in message news:<rcBLb.107745$...
En C++, je crois qu'il faudrait tout enlever les conversions implicites ou la permettre aussi sur les pointeurs de fonction membre... En fait, j'aimerais mieux enlever toutes les conversions implicites, y compris celles de base comme double -> int !)
En ce qui concerne les conversions du type double -> int, tu n'es pas seul. Il me semble même que même Stroustrup s'est exprimé en ce sens. En revanche, int -> long ? Si je concevais un langage de zéro, je ne crois pas qu'il supporterait ce genre de conversion non plus. Mais ce langage ne serait ni C ni C++, et je vois mal un effort de l'éliminer de C ou de C++.
En fait, int->long me paraît acceptable. C'est surtout les conversions implicites avec perte possible que je trouve inacceptable, mais heureusement, les bons compilateurs vont pouvoir te donner des avertissements.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
kanze
"Michel Michaud" wrote in message news:<NXzMb.6253$...
Dans news:,
[...]
Dans la contexte de B, ça se comprend. En revanche, je ne sais pas pourquoi, quand ils ont passé de B en C, ils ont changé les fonctions, et non les tableaux. Logiquement, avec le typage plus fort de C, on s'attendrait à ce que les deux changent.
Alors tu penses comme moi, au niveau de l'uniformité.
Non. En B, il y avait une sorte d'uniformité. Quand ils ont introduit le typage, pour en faire C, ils en ont introduit une autre sorte. Sauf pour des pointeurs. Permettre pf() n'améliore pas l'uniformité -- il crée deux exceptions (deux cas des types de seconde classe), à la place d'une.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Michel Michaud" <mm@gdzid.com> wrote in message
news:<NXzMb.6253$881.772398@news20.bellglobal.com>...
Dans news:d6652001.0401120000.120325a4@posting.google.com,
[...]
Dans la contexte de B, ça se comprend. En revanche, je ne sais pas
pourquoi, quand ils ont passé de B en C, ils ont changé les
fonctions, et non les tableaux. Logiquement, avec le typage plus
fort de C, on s'attendrait à ce que les deux changent.
Alors tu penses comme moi, au niveau de l'uniformité.
Non. En B, il y avait une sorte d'uniformité. Quand ils ont introduit le
typage, pour en faire C, ils en ont introduit une autre sorte. Sauf pour
des pointeurs. Permettre pf() n'améliore pas l'uniformité -- il crée
deux exceptions (deux cas des types de seconde classe), à la place
d'une.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Michel Michaud" wrote in message news:<NXzMb.6253$...
Dans news:,
[...]
Dans la contexte de B, ça se comprend. En revanche, je ne sais pas pourquoi, quand ils ont passé de B en C, ils ont changé les fonctions, et non les tableaux. Logiquement, avec le typage plus fort de C, on s'attendrait à ce que les deux changent.
Alors tu penses comme moi, au niveau de l'uniformité.
Non. En B, il y avait une sorte d'uniformité. Quand ils ont introduit le typage, pour en faire C, ils en ont introduit une autre sorte. Sauf pour des pointeurs. Permettre pf() n'améliore pas l'uniformité -- il crée deux exceptions (deux cas des types de seconde classe), à la place d'une.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
