Ma question est totalement hors sujet mais je sais qu'il y a ici des
personnes compétentes pour y répondre; me rediriger le cas échéant.
Dans un langage du type C++, quelles sont les différences (s'il y en a)
entre
1.
* une fonction
* une routine (le mon anglais a-t-il le même sens en français ?)
* une procédure
* une commande
2.
* un paramètre
* un argument
3.
* une classe
* une structure
Merci et bonne année.
--
Philippe Ivaldi.
http://piprim.tuxfamily.org/
Dans l'utilisation de tous les jours (en dehors de la norme, donc), je crois que la plupart des gens ne comprenent pas des unions quand on parle des classes. Faut dire aussi que dans l'utilisation de tous les jours, on ne
rencontre pas très souvent "union".
Dans l'utilisation de tous les jours d'il y a vingt ou vingt-cinq ans, quand la mémoire était comptée, c'était un peu plus fréquent. Mais on parlait aussi un peu moins souvent de classes et de C++. C'est logique qu'on utilise de moins en moins les unions vu que c'était
une astuce pour faire du polymorphisme sans posséder de langage objet. Aujourd'hui on utiliserait une classe polymorphe dont chaque descendant ne possèderait que l'information utile.
Dans l'utilisation de tous les jours (en dehors de
la norme, donc), je crois que la plupart des gens ne comprenent
pas des unions quand on parle des classes.
Faut dire aussi que dans l'utilisation de tous les jours, on ne
rencontre pas très souvent "union".
Dans l'utilisation de tous les jours d'il y a vingt ou vingt-cinq ans,
quand la mémoire était comptée, c'était un peu plus fréquent. Mais on
parlait aussi un peu moins souvent de classes et de C++.
C'est logique qu'on utilise de moins en moins les unions vu que c'était
une astuce pour faire du polymorphisme sans posséder de langage objet.
Aujourd'hui on utiliserait une classe polymorphe dont chaque descendant
ne possèderait que l'information utile.
Dans l'utilisation de tous les jours (en dehors de la norme, donc), je crois que la plupart des gens ne comprenent pas des unions quand on parle des classes. Faut dire aussi que dans l'utilisation de tous les jours, on ne
rencontre pas très souvent "union".
Dans l'utilisation de tous les jours d'il y a vingt ou vingt-cinq ans, quand la mémoire était comptée, c'était un peu plus fréquent. Mais on parlait aussi un peu moins souvent de classes et de C++. C'est logique qu'on utilise de moins en moins les unions vu que c'était
une astuce pour faire du polymorphisme sans posséder de langage objet. Aujourd'hui on utiliserait une classe polymorphe dont chaque descendant ne possèderait que l'information utile.
Fabien LE LEZ
On Thu, 03 Jan 2008 14:02:47 +0100, Aris :
C'est logique qu'on utilise de moins en moins les unions vu que c'était une astuce pour faire du polymorphisme sans posséder de langage objet. Aujourd'hui on utiliserait une classe polymorphe dont chaque descendant ne possèderait que l'information utile.
L'avantage de l'union, c'est que l'utilisation peut changer en cours de route, sans avoir à recréer l'objet.
On Thu, 03 Jan 2008 14:02:47 +0100, Aris <aris@badcode.be>:
C'est logique qu'on utilise de moins en moins les unions vu que c'était
une astuce pour faire du polymorphisme sans posséder de langage objet.
Aujourd'hui on utiliserait une classe polymorphe dont chaque descendant
ne possèderait que l'information utile.
L'avantage de l'union, c'est que l'utilisation peut changer en cours
de route, sans avoir à recréer l'objet.
C'est logique qu'on utilise de moins en moins les unions vu que c'était une astuce pour faire du polymorphisme sans posséder de langage objet. Aujourd'hui on utiliserait une classe polymorphe dont chaque descendant ne possèderait que l'information utile.
L'avantage de l'union, c'est que l'utilisation peut changer en cours de route, sans avoir à recréer l'objet.
Aris
Le nom correct d'un bloc de programme qu'on écrit est une fonction. Routine et procédure pourraient être synonymes.
Une commande est un élément de base, inclus dans le langage. (if, while, return, ...)
Ah, je voulais en parler mais j'ai oublié. Je nomme ces mots-clés (if, while, return) plutôt des instructions du langage que des commandes. Mais il faut reconnaître que c'est un peu ambigu car on appelle aussi « instruction », par exemple, l'affectation « a = b = 5; ».
[ Suivi positionné vers fr.comp.lang.c++ ] En fait vous faites un abus de langage. if, return, while, return, =,
etc. ne sont rien de plus que des mots-clefs qui ont une certaine sémantique selon l'endroit où ils se trouvent. On appelle une instruction ce que vous avez dit : a=b=c; (avec le ;. Sans le ;, c'est une expression) une instruction est donc une expression suivie de ; ou bien if(expression) instruction ou bien if(expression) instruction else instruction etc. même l'instruction vide (;) est une instruction. par contre ne sont pas des instructions les déclarations de fonction, méthodes, variables, constantes & co.
Le nom correct d'un bloc de programme qu'on écrit est une fonction. Routine
et procédure pourraient être synonymes.
Une commande est un élément de base, inclus dans le langage. (if, while,
return, ...)
Ah, je voulais en parler mais j'ai oublié. Je nomme ces mots-clés (if,
while, return) plutôt des instructions du langage que des commandes.
Mais il faut reconnaître que c'est un peu ambigu car on appelle aussi
« instruction », par exemple, l'affectation « a = b = 5; ».
[ Suivi positionné vers fr.comp.lang.c++ ]
En fait vous faites un abus de langage. if, return, while, return, =,
etc. ne sont rien de plus que des mots-clefs qui ont une certaine
sémantique selon l'endroit où ils se trouvent.
On appelle une instruction ce que vous avez dit : a=b=c; (avec le ;.
Sans le ;, c'est une expression)
une instruction est donc une expression suivie de ; ou bien
if(expression) instruction ou bien
if(expression) instruction else instruction
etc.
même l'instruction vide (;) est une instruction.
par contre ne sont pas des instructions les déclarations de fonction,
méthodes, variables, constantes & co.
Le nom correct d'un bloc de programme qu'on écrit est une fonction. Routine et procédure pourraient être synonymes.
Une commande est un élément de base, inclus dans le langage. (if, while, return, ...)
Ah, je voulais en parler mais j'ai oublié. Je nomme ces mots-clés (if, while, return) plutôt des instructions du langage que des commandes. Mais il faut reconnaître que c'est un peu ambigu car on appelle aussi « instruction », par exemple, l'affectation « a = b = 5; ».
[ Suivi positionné vers fr.comp.lang.c++ ] En fait vous faites un abus de langage. if, return, while, return, =,
etc. ne sont rien de plus que des mots-clefs qui ont une certaine sémantique selon l'endroit où ils se trouvent. On appelle une instruction ce que vous avez dit : a=b=c; (avec le ;. Sans le ;, c'est une expression) une instruction est donc une expression suivie de ; ou bien if(expression) instruction ou bien if(expression) instruction else instruction etc. même l'instruction vide (;) est une instruction. par contre ne sont pas des instructions les déclarations de fonction, méthodes, variables, constantes & co.
Aris
On Thu, 03 Jan 2008 14:02:47 +0100, Aris :
C'est logique qu'on utilise de moins en moins les unions vu que c'était une astuce pour faire du polymorphisme sans posséder de langage objet. Aujourd'hui on utiliserait une classe polymorphe dont chaque descendant ne possèderait que l'information utile.
L'avantage de l'union, c'est que l'utilisation peut changer en cours de route, sans avoir à recréer l'objet.
Oui c'est sûr. Mais un des gros defauts qui font que j'hésiterais à
l'utiliser (= je ne l'utiliserai QUE si c'est indispensable pour gagner des performances quand c'est indispensable) c'est qu'il n'y a pas la moindre vérification runtime sur le contenu. Ce qui fait en fait qu'on a un transtypage totalement implicite et non vérifiable. Et généralement un switch devant pour pouvoir choisir (switch est du O(n) alors qu'un appel de méthode virtuelle est en O(1)).
Donc même niveau performances j'ai des doutes.
On Thu, 03 Jan 2008 14:02:47 +0100, Aris <aris@badcode.be>:
C'est logique qu'on utilise de moins en moins les unions vu que c'était
une astuce pour faire du polymorphisme sans posséder de langage objet.
Aujourd'hui on utiliserait une classe polymorphe dont chaque descendant
ne possèderait que l'information utile.
L'avantage de l'union, c'est que l'utilisation peut changer en cours
de route, sans avoir à recréer l'objet.
Oui c'est sûr. Mais un des gros defauts qui font que j'hésiterais à
l'utiliser (= je ne l'utiliserai QUE si c'est indispensable pour gagner
des performances quand c'est indispensable) c'est qu'il n'y a pas la
moindre vérification runtime sur le contenu. Ce qui fait en fait qu'on a
un transtypage totalement implicite et non vérifiable. Et généralement
un switch devant pour pouvoir choisir (switch est du O(n) alors qu'un
appel de méthode virtuelle est en O(1)).
C'est logique qu'on utilise de moins en moins les unions vu que c'était une astuce pour faire du polymorphisme sans posséder de langage objet. Aujourd'hui on utiliserait une classe polymorphe dont chaque descendant ne possèderait que l'information utile.
L'avantage de l'union, c'est que l'utilisation peut changer en cours de route, sans avoir à recréer l'objet.
Oui c'est sûr. Mais un des gros defauts qui font que j'hésiterais à
l'utiliser (= je ne l'utiliserai QUE si c'est indispensable pour gagner des performances quand c'est indispensable) c'est qu'il n'y a pas la moindre vérification runtime sur le contenu. Ce qui fait en fait qu'on a un transtypage totalement implicite et non vérifiable. Et généralement un switch devant pour pouvoir choisir (switch est du O(n) alors qu'un appel de méthode virtuelle est en O(1)).
Donc même niveau performances j'ai des doutes.
Olivier Miakinen
Le 03/01/2008 14:07, Aris me répondait :
Une commande est un élément de base, inclus dans le langage. (if, while, return, ...)
Ah, je voulais en parler mais j'ai oublié. Je nomme ces mots-clés (if, while, return) plutôt des instructions du langage que des commandes. Mais il faut reconnaître que c'est un peu ambigu car on appelle aussi « instruction », par exemple, l'affectation « a = b = 5; ».
En fait vous faites un abus de langage. if, return, while, return, =, etc. ne sont rien de plus que des mots-clefs qui ont une certaine sémantique selon l'endroit où ils se trouvent. [...]
Oui, absolument.
Le 03/01/2008 14:07, Aris me répondait :
Une commande est un élément de base, inclus dans le langage. (if, while,
return, ...)
Ah, je voulais en parler mais j'ai oublié. Je nomme ces mots-clés (if,
while, return) plutôt des instructions du langage que des commandes.
Mais il faut reconnaître que c'est un peu ambigu car on appelle aussi
« instruction », par exemple, l'affectation « a = b = 5; ».
En fait vous faites un abus de langage. if, return, while, return, =,
etc. ne sont rien de plus que des mots-clefs qui ont une certaine
sémantique selon l'endroit où ils se trouvent.
[...]
Une commande est un élément de base, inclus dans le langage. (if, while, return, ...)
Ah, je voulais en parler mais j'ai oublié. Je nomme ces mots-clés (if, while, return) plutôt des instructions du langage que des commandes. Mais il faut reconnaître que c'est un peu ambigu car on appelle aussi « instruction », par exemple, l'affectation « a = b = 5; ».
En fait vous faites un abus de langage. if, return, while, return, =, etc. ne sont rien de plus que des mots-clefs qui ont une certaine sémantique selon l'endroit où ils se trouvent. [...]
Oui, absolument.
Ph. Ivaldi
Merci à tous pour vos explications. -- Philippe Ivaldi. http://piprim.tuxfamily.org/
Merci à tous pour vos explications.
--
Philippe Ivaldi.
http://piprim.tuxfamily.org/
