[débutant]Quel langage choisir?

Fabien LE LEZ

08/01/2004 à 17:43

On Thu, 08 Jan 2004 13:50:51 +0100, Arnaud ARZUFFI
wrote:

Justement, j'arrive pas vraiment à discerner (honte à moi !) : les
pointeurs, aucun problème : des objets alloués par new

Pas spécialement. Les codes suivants sont valides :

int n= 12;
int *ptr= &n;

---
void f (int *);

void g()
{
int n= 12;
f (&n);
}

--
;-)

http://www.gotw.ca/gotw/063.htm
http://www.gotw.ca/gotw/067.htm#2

kanze

09/01/2004 à 13:32

"Michel Michaud" wrote in message
news:<OvfLb.72200$...

Dans news:btjl6q$kaa$, Arnaud

Justement, j'arrive pas vraiment à discerner (honte à moi !) : les
pointeurs, aucun problème : des objets alloués par new, qui ont une
portée plus grande que la méthode, et une durée de vie choisie par
l'utilisateur ; les objets "valeur" pour des objets temporaires, de
durée de vie fonction... par contre, les références, je les utilise
seulement lorsqu'une méthode dans une API me l'impose !

De D&E « References were introduced primarily to support operator
overloading. [...] notational convenience is essential because users
cannot be expected to insert address-of operators if the objects are
large. For example:

a = b - c;

is acceptable (that is, conventional) notation, but

a = &b - &c;

is not. »

Plus généralement, une référence s'impose chaque fois que tu veux la
syntaxe de passe par valeur, mais la sémantique de passe par référence.

Dans ces cas-là, il s'agit la plupart du temps des références const.

Ces considérations justifient (et largement) l'introduction du concepte.
Une fois qu'on l'a, on trouve d'autres utilisations intéressantes -- si
je passe un pointeur à une fonction, je suis obligé à tester pour NULL
dans la fonction (sans exception) ; si je passe une référence, non.

En dehors des paramètres, j'utilise rélativement peu de références :
parfois des choses comme « ostream& » comme membre de classe, mais ce
n'est pas aussi fréquent. (Il faut dire qu'une classe qui contient une
référence ne supporte ni la copie ni l'affectation par défaut, et que
c'est en général difficile à en définir une bonne sémantique si on veut
les déclarer soi-même.)

Ceci dit, ce n'est pas la seule utilité : que ça paraisse bon ou
mauvais aux yeux de certains, le passage de paramètre de sortie en C++
est typiquement fait par des références et il est normal de renvoyer
une référence à partir d'une fonction quand c'est utile.

Là, je ne suis pas tellement d'accord. Dans l'ensemble, la référence
(comme un pointeur, d'ailleurs) ouvre une fenêtre à l'intérieur de la
classe. Il y a des cas (comme les operator[]) où c'est exactement ce
qu'on veut, mais ce sont plutôt des exceptions que la règle.

Dans ces deux cas, des pointeurs pourraient être utilisés, mais la
syntaxe est alors moins naturelle... sauf pour ceux qui viennent de C

Je dirais, à coup de nez, que 80% des références dans mon code, ce sont
des cas où je veux la sémantique d'une passe par valeur, mais que pour
une raison ou une autre (souvent simplement une question de
performance), je ne veux pas une vraie copie.

--
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:<OvfLb.72200$BA6.1460191@news20.bellglobal.com>...

Dans news:btjl6q$kaa$1@news.u-bordeaux.fr, Arnaud

Justement, j'arrive pas vraiment à discerner (honte à moi !) : les
pointeurs, aucun problème : des objets alloués par new, qui ont une
portée plus grande que la méthode, et une durée de vie choisie par
l'utilisateur ; les objets "valeur" pour des objets temporaires, de
durée de vie fonction... par contre, les références, je les utilise
seulement lorsqu'une méthode dans une API me l'impose !

De D&E « References were introduced primarily to support operator
overloading. [...] notational convenience is essential because users
cannot be expected to insert address-of operators if the objects are
large. For example:

a = b - c;

is acceptable (that is, conventional) notation, but

a = &b - &c;

is not. »

Plus généralement, une référence s'impose chaque fois que tu veux la
syntaxe de passe par valeur, mais la sémantique de passe par référence.

Dans ces cas-là, il s'agit la plupart du temps des références const.

Ces considérations justifient (et largement) l'introduction du concepte.
Une fois qu'on l'a, on trouve d'autres utilisations intéressantes -- si
je passe un pointeur à une fonction, je suis obligé à tester pour NULL
dans la fonction (sans exception) ; si je passe une référence, non.

En dehors des paramètres, j'utilise rélativement peu de références :
parfois des choses comme « ostream& » comme membre de classe, mais ce
n'est pas aussi fréquent. (Il faut dire qu'une classe qui contient une
référence ne supporte ni la copie ni l'affectation par défaut, et que
c'est en général difficile à en définir une bonne sémantique si on veut
les déclarer soi-même.)

Ceci dit, ce n'est pas la seule utilité : que ça paraisse bon ou
mauvais aux yeux de certains, le passage de paramètre de sortie en C++
est typiquement fait par des références et il est normal de renvoyer
une référence à partir d'une fonction quand c'est utile.

Là, je ne suis pas tellement d'accord. Dans l'ensemble, la référence
(comme un pointeur, d'ailleurs) ouvre une fenêtre à l'intérieur de la
classe. Il y a des cas (comme les operator[]) où c'est exactement ce
qu'on veut, mais ce sont plutôt des exceptions que la règle.

Dans ces deux cas, des pointeurs pourraient être utilisés, mais la
syntaxe est alors moins naturelle... sauf pour ceux qui viennent de C

Je dirais, à coup de nez, que 80% des références dans mon code, ce sont
des cas où je veux la sémantique d'une passe par valeur, mais que pour
une raison ou une autre (souvent simplement une question de
performance), je ne veux pas une vraie copie.

--
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

Vous avez filtré cet utilisateur ! Consultez son message

"Michel Michaud" wrote in message
news:<OvfLb.72200$...

Dans news:btjl6q$kaa$, Arnaud

Justement, j'arrive pas vraiment à discerner (honte à moi !) : les
pointeurs, aucun problème : des objets alloués par new, qui ont une
portée plus grande que la méthode, et une durée de vie choisie par
l'utilisateur ; les objets "valeur" pour des objets temporaires, de
durée de vie fonction... par contre, les références, je les utilise
seulement lorsqu'une méthode dans une API me l'impose !

De D&E « References were introduced primarily to support operator
overloading. [...] notational convenience is essential because users
cannot be expected to insert address-of operators if the objects are
large. For example:

a = b - c;

is acceptable (that is, conventional) notation, but

a = &b - &c;

is not. »

Plus généralement, une référence s'impose chaque fois que tu veux la
syntaxe de passe par valeur, mais la sémantique de passe par référence.

Dans ces cas-là, il s'agit la plupart du temps des références const.

Ces considérations justifient (et largement) l'introduction du concepte.
Une fois qu'on l'a, on trouve d'autres utilisations intéressantes -- si
je passe un pointeur à une fonction, je suis obligé à tester pour NULL
dans la fonction (sans exception) ; si je passe une référence, non.

En dehors des paramètres, j'utilise rélativement peu de références :
parfois des choses comme « ostream& » comme membre de classe, mais ce
n'est pas aussi fréquent. (Il faut dire qu'une classe qui contient une
référence ne supporte ni la copie ni l'affectation par défaut, et que
c'est en général difficile à en définir une bonne sémantique si on veut
les déclarer soi-même.)

Ceci dit, ce n'est pas la seule utilité : que ça paraisse bon ou
mauvais aux yeux de certains, le passage de paramètre de sortie en C++
est typiquement fait par des références et il est normal de renvoyer
une référence à partir d'une fonction quand c'est utile.

Là, je ne suis pas tellement d'accord. Dans l'ensemble, la référence
(comme un pointeur, d'ailleurs) ouvre une fenêtre à l'intérieur de la
classe. Il y a des cas (comme les operator[]) où c'est exactement ce
qu'on veut, mais ce sont plutôt des exceptions que la règle.

Dans ces deux cas, des pointeurs pourraient être utilisés, mais la
syntaxe est alors moins naturelle... sauf pour ceux qui viennent de C

Je dirais, à coup de nez, que 80% des références dans mon code, ce sont
des cas où je veux la sémantique d'une passe par valeur, mais que pour
une raison ou une autre (souvent simplement une question de
performance), je ne veux pas une vraie copie.

--
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

09/01/2004 à 13:46

Gabriel Dos Reis wrote in message
news:...

writes:
| Gabriel Dos Reis wrote in message
| news:...
| > writes:

| > | Pourquoi, pourquoi et pourquoi. Le nom du type générique, c'est
| > | std::vector. C'est vrai que les : ne sont pas permis dans les
| > | symboles en général, mais std::vector n'est pas un symbole
| > | général. Quant aux paramètres de types : c'est un type dérivé,
| > | de même que par exemple

| > « type dérivé » n'est plus utilisé depuis je ne sais quand.

| 2002, au moins:-).

1997 au moins.

C'était un typo, et je voulais dire 2000. Parce que j'ai ici un document
daté de 2000 qui en parle -- ISO 9899::1999. Je vois que je me suis
trompé de date de toute façon, mais l'émoticon n'y était pas pour rien.
Je suis sûr que dans certains cercles, l'expression est encore courante.

| Mais je suppose que ton énoncé se limite au C++, où ça pourrait
| prêter réelement à confusion.

étant donné qu'on est sur fr.comp.lang.C++ et qu'il est fait mention
de classe dérivée, je ne sais pas ce que tu veux imaginer d'autres.

Étant donné qu'on parle de la langue (français ou anglais), et non du
langage (C++ ou d'autre), ce n'est pas clair que ton énoncé se limitait
à un milieu aussi restreint. Ta référence à des classes dérivées le
laisse penser, mais je trouve que de mettre les points sur les i ne nuit
à rien.

Ce n'était pas vraiment pour te contradire, sauf en plaisantant.

| (La norme C parle toujours des « derived types ».)

Mais la norme C ne parle pas de classe dérivée, n'est-il pas ?

| Je trouve que l'expression « composite » suggère un peu trop l'idée
| qu'il y a plus d'un type plus primitif en jeu (mais la suggestion
| est bien présente aussi dans « compound type », quoique moins
| forte). J'aime bien « type composé ». Mais je laisserai la décision
| à des vrais francophones.

| > | int* ; c'est plutôt normal que le nom du type de base se
| > | retrouve dans le type dérivé, il me semble. Et quant au
| > | constructeur : pourquoi est-ce qu'il faut en parler tout de
| > | suite ?

| > Dans ce context il faut distinguer le nom d'un type fundamental
| > (identificateur) du type qu'il désigne ; autrement cela devient
| > confus.

| Un type composé est composé sur la base d'un ou de plusieurs types ;
| on

M. de Lapalisse ne dit pas le contraire.

(Un de ces jours, il va falloir que quelqu'un m'explique qui est ce M.
de Lapalisse dont tu parles de temps en temps. D'après les contextes, je
crois qu'il y a une subtilité de la culture française, ou francophone,
qui m'échappe.)

Mais cela passe, je crois, à côté de ce que je disais.

Oui est non. Si on considère la première phrase que tu as écris :
« 'type dérivé' n'est plus utilisé depuis je ne sais quand », c'est
manifeste que la phrase n'est pas complète -- il manque un « en parlant
de C++ », ou quelque chose de semblable. Parce que l'énoncé, tel que tu
l'as écrit, prète à confusion.

--
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 <gdr@integrable-solutions.net> wrote in message
news:<m3smirnxe3.fsf@uniton.integrable-solutions.net>...

kanze@gabi-soft.fr writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
| news:<m3n090ujlv.fsf@uniton.integrable-solutions.net>...
| > kanze@gabi-soft.fr writes:

| > | Pourquoi, pourquoi et pourquoi. Le nom du type générique, c'est
| > | std::vector. C'est vrai que les : ne sont pas permis dans les
| > | symboles en général, mais std::vector n'est pas un symbole
| > | général. Quant aux paramètres de types : c'est un type dérivé,
| > | de même que par exemple

| > « type dérivé » n'est plus utilisé depuis je ne sais quand.

| 2002, au moins:-).

1997 au moins.

C'était un typo, et je voulais dire 2000. Parce que j'ai ici un document
daté de 2000 qui en parle -- ISO 9899::1999. Je vois que je me suis
trompé de date de toute façon, mais l'émoticon n'y était pas pour rien.
Je suis sûr que dans certains cercles, l'expression est encore courante.

| Mais je suppose que ton énoncé se limite au C++, où ça pourrait
| prêter réelement à confusion.

étant donné qu'on est sur fr.comp.lang.C++ et qu'il est fait mention
de classe dérivée, je ne sais pas ce que tu veux imaginer d'autres.

Étant donné qu'on parle de la langue (français ou anglais), et non du
langage (C++ ou d'autre), ce n'est pas clair que ton énoncé se limitait
à un milieu aussi restreint. Ta référence à des classes dérivées le
laisse penser, mais je trouve que de mettre les points sur les i ne nuit
à rien.

Ce n'était pas vraiment pour te contradire, sauf en plaisantant.

| (La norme C parle toujours des « derived types ».)

Mais la norme C ne parle pas de classe dérivée, n'est-il pas ?

| Je trouve que l'expression « composite » suggère un peu trop l'idée
| qu'il y a plus d'un type plus primitif en jeu (mais la suggestion
| est bien présente aussi dans « compound type », quoique moins
| forte). J'aime bien « type composé ». Mais je laisserai la décision
| à des vrais francophones.

| > | int* ; c'est plutôt normal que le nom du type de base se
| > | retrouve dans le type dérivé, il me semble. Et quant au
| > | constructeur : pourquoi est-ce qu'il faut en parler tout de
| > | suite ?

| > Dans ce context il faut distinguer le nom d'un type fundamental
| > (identificateur) du type qu'il désigne ; autrement cela devient
| > confus.

| Un type composé est composé sur la base d'un ou de plusieurs types ;
| on

M. de Lapalisse ne dit pas le contraire.

(Un de ces jours, il va falloir que quelqu'un m'explique qui est ce M.
de Lapalisse dont tu parles de temps en temps. D'après les contextes, je
crois qu'il y a une subtilité de la culture française, ou francophone,
qui m'échappe.)

Mais cela passe, je crois, à côté de ce que je disais.

Oui est non. Si on considère la première phrase que tu as écris :
« 'type dérivé' n'est plus utilisé depuis je ne sais quand », c'est
manifeste que la phrase n'est pas complète -- il manque un « en parlant
de C++ », ou quelque chose de semblable. Parce que l'énoncé, tel que tu
l'as écrit, prète à confusion.

--
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

Vous avez filtré cet utilisateur ! Consultez son message

Gabriel Dos Reis wrote in message
news:...

writes:
| Gabriel Dos Reis wrote in message
| news:...
| > writes:

| > | Pourquoi, pourquoi et pourquoi. Le nom du type générique, c'est
| > | std::vector. C'est vrai que les : ne sont pas permis dans les
| > | symboles en général, mais std::vector n'est pas un symbole
| > | général. Quant aux paramètres de types : c'est un type dérivé,
| > | de même que par exemple

| > « type dérivé » n'est plus utilisé depuis je ne sais quand.

| 2002, au moins:-).

1997 au moins.

C'était un typo, et je voulais dire 2000. Parce que j'ai ici un document
daté de 2000 qui en parle -- ISO 9899::1999. Je vois que je me suis
trompé de date de toute façon, mais l'émoticon n'y était pas pour rien.
Je suis sûr que dans certains cercles, l'expression est encore courante.

| Mais je suppose que ton énoncé se limite au C++, où ça pourrait
| prêter réelement à confusion.

étant donné qu'on est sur fr.comp.lang.C++ et qu'il est fait mention
de classe dérivée, je ne sais pas ce que tu veux imaginer d'autres.

Étant donné qu'on parle de la langue (français ou anglais), et non du
langage (C++ ou d'autre), ce n'est pas clair que ton énoncé se limitait
à un milieu aussi restreint. Ta référence à des classes dérivées le
laisse penser, mais je trouve que de mettre les points sur les i ne nuit
à rien.

Ce n'était pas vraiment pour te contradire, sauf en plaisantant.

| (La norme C parle toujours des « derived types ».)

Mais la norme C ne parle pas de classe dérivée, n'est-il pas ?

| Je trouve que l'expression « composite » suggère un peu trop l'idée
| qu'il y a plus d'un type plus primitif en jeu (mais la suggestion
| est bien présente aussi dans « compound type », quoique moins
| forte). J'aime bien « type composé ». Mais je laisserai la décision
| à des vrais francophones.

| > | int* ; c'est plutôt normal que le nom du type de base se
| > | retrouve dans le type dérivé, il me semble. Et quant au
| > | constructeur : pourquoi est-ce qu'il faut en parler tout de
| > | suite ?

| > Dans ce context il faut distinguer le nom d'un type fundamental
| > (identificateur) du type qu'il désigne ; autrement cela devient
| > confus.

| Un type composé est composé sur la base d'un ou de plusieurs types ;
| on

M. de Lapalisse ne dit pas le contraire.

(Un de ces jours, il va falloir que quelqu'un m'explique qui est ce M.
de Lapalisse dont tu parles de temps en temps. D'après les contextes, je
crois qu'il y a une subtilité de la culture française, ou francophone,
qui m'échappe.)

Mais cela passe, je crois, à côté de ce que je disais.

Oui est non. Si on considère la première phrase que tu as écris :
« 'type dérivé' n'est plus utilisé depuis je ne sais quand », c'est
manifeste que la phrase n'est pas complète -- il manque un « en parlant
de C++ », ou quelque chose de semblable. Parce que l'énoncé, tel que tu
l'as écrit, prète à confusion.

--
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

09/01/2004 à 15:26

writes:

| Gabriel Dos Reis wrote in message
| news:...
| > writes:
| > | Gabriel Dos Reis wrote in message
| > | news:...
| > | > writes:
|
| > | > | Pourquoi, pourquoi et pourquoi. Le nom du type générique, c'est
| > | > | std::vector. C'est vrai que les : ne sont pas permis dans les
| > | > | symboles en général, mais std::vector n'est pas un symbole
| > | > | général. Quant aux paramètres de types : c'est un type dérivé,
| > | > | de même que par exemple
|
| > | > « type dérivé » n'est plus utilisé depuis je ne sais quand.
|
| > | 2002, au moins:-).
|
| > 1997 au moins.
|
| C'était un typo, et je voulais dire 2000. Parce que j'ai ici un document
| daté de 2000 qui en parle -- ISO 9899::1999.

Ce document n'est pas la définition de C++ -- et n'y est même pas inclus.
Mais, comme visiblement tu n'as pas dû t'en rendre compte, nous sommes sur
fr.comp.lang.c++ et je parlais de C++ (dans un message ou on parle de
class derivee, std::vector, ... de quel autre langage pouvait-il etre
question ?)

| Je vois que je me suis
| trompé de date de toute façon, mais l'émoticon n'y était pas pour rien.
| Je suis sûr que dans certains cercles, l'expression est encore courante.
|
| > | Mais je suppose que ton énoncé se limite au C++, où ça pourrait
| > | prêter réelement à confusion.
|
| > étant donné qu'on est sur fr.comp.lang.C++ et qu'il est fait mention
| > de classe dérivée, je ne sais pas ce que tu veux imaginer d'autres.
|
| Étant donné qu'on parle de la langue (français ou anglais), et non du
| langage (C++ ou d'autre), ce n'est pas clair que ton énoncé se limitait
| à un milieu aussi restreint. Ta référence à des classes dérivées le
| laisse penser, mais je trouve que de mettre les points sur les i ne nuit
| à rien.

Sauf qu'il ne le fait pas :-(

| Ce n'était pas vraiment pour te contradire, sauf en plaisantant.

Je NE pensais PAS que tu contredisais. Ton message me donnait
l'impression de divaguer. Un message qui contredit donne en general
un signe qu'il considere le message auquel il repond dans son
contexte.

[...]

| > M. de Lapalisse ne dit pas le contraire.
|
| (Un de ces jours, il va falloir que quelqu'un m'explique qui est ce M.
| de Lapalisse dont tu parles de temps en temps. D'après les contextes, je
| crois qu'il y a une subtilité de la culture française, ou francophone,
| qui m'échappe.)
|
| > Mais cela passe, je crois, à côté de ce que je disais.
|
| Oui est non.

c'est profond.

| Si on considère la première phrase que tu as écris :
| « 'type dérivé' n'est plus utilisé depuis je ne sais quand », c'est
| manifeste que la phrase n'est pas complète -- il manque un « en parlant
| de C++ », ou quelque chose de semblable. Parce que l'énoncé, tel que tu
| l'as écrit, prète à confusion.

Bouah ha ha. Quand tu lis une phrase, il faut la lire dans son
contexte. Cela fait partie du B A BA que nous enseignons aux eleves.
Tu as une facheuse habitude a lire les phrases hors contexte et
ensuite a enoncer des trivialites (au motif que tu veux mettre les
points sur les i -- qui en avaient deja, ce qui tend a les confondre
avec un i trema). Si confusion il y a , c'est toi qui les introduit.

Avant de repondre, je suggere que tu lises l'integralite du message,
dans son contexte et que tu remontes deux ou trois messages plus
haut.

-- Gaby

kanze@gabi-soft.fr writes:

| Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
| news:<m3smirnxe3.fsf@uniton.integrable-solutions.net>...
| > kanze@gabi-soft.fr writes:
| > | Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
| > | news:<m3n090ujlv.fsf@uniton.integrable-solutions.net>...
| > | > kanze@gabi-soft.fr writes:
|
| > | > | Pourquoi, pourquoi et pourquoi. Le nom du type générique, c'est
| > | > | std::vector. C'est vrai que les : ne sont pas permis dans les
| > | > | symboles en général, mais std::vector n'est pas un symbole
| > | > | général. Quant aux paramètres de types : c'est un type dérivé,
| > | > | de même que par exemple
|
| > | > « type dérivé » n'est plus utilisé depuis je ne sais quand.
|
| > | 2002, au moins:-).
|
| > 1997 au moins.
|
| C'était un typo, et je voulais dire 2000. Parce que j'ai ici un document
| daté de 2000 qui en parle -- ISO 9899::1999.

Ce document n'est pas la définition de C++ -- et n'y est même pas inclus.
Mais, comme visiblement tu n'as pas dû t'en rendre compte, nous sommes sur
fr.comp.lang.c++ et je parlais de C++ (dans un message ou on parle de
class derivee, std::vector, ... de quel autre langage pouvait-il etre
question ?)

| Je vois que je me suis
| trompé de date de toute façon, mais l'émoticon n'y était pas pour rien.
| Je suis sûr que dans certains cercles, l'expression est encore courante.
|
| > | Mais je suppose que ton énoncé se limite au C++, où ça pourrait
| > | prêter réelement à confusion.
|
| > étant donné qu'on est sur fr.comp.lang.C++ et qu'il est fait mention
| > de classe dérivée, je ne sais pas ce que tu veux imaginer d'autres.
|
| Étant donné qu'on parle de la langue (français ou anglais), et non du
| langage (C++ ou d'autre), ce n'est pas clair que ton énoncé se limitait
| à un milieu aussi restreint. Ta référence à des classes dérivées le
| laisse penser, mais je trouve que de mettre les points sur les i ne nuit
| à rien.

Sauf qu'il ne le fait pas :-(

| Ce n'était pas vraiment pour te contradire, sauf en plaisantant.

Je NE pensais PAS que tu contredisais. Ton message me donnait
l'impression de divaguer. Un message qui contredit donne en general
un signe qu'il considere le message auquel il repond dans son
contexte.

[...]

| > M. de Lapalisse ne dit pas le contraire.
|
| (Un de ces jours, il va falloir que quelqu'un m'explique qui est ce M.
| de Lapalisse dont tu parles de temps en temps. D'après les contextes, je
| crois qu'il y a une subtilité de la culture française, ou francophone,
| qui m'échappe.)
|
| > Mais cela passe, je crois, à côté de ce que je disais.
|
| Oui est non.

c'est profond.

| Si on considère la première phrase que tu as écris :
| « 'type dérivé' n'est plus utilisé depuis je ne sais quand », c'est
| manifeste que la phrase n'est pas complète -- il manque un « en parlant
| de C++ », ou quelque chose de semblable. Parce que l'énoncé, tel que tu
| l'as écrit, prète à confusion.

Bouah ha ha. Quand tu lis une phrase, il faut la lire dans son
contexte. Cela fait partie du B A BA que nous enseignons aux eleves.
Tu as une facheuse habitude a lire les phrases hors contexte et
ensuite a enoncer des trivialites (au motif que tu veux mettre les
points sur les i -- qui en avaient deja, ce qui tend a les confondre
avec un i trema). Si confusion il y a , c'est toi qui les introduit.

Avant de repondre, je suggere que tu lises l'integralite du message,
dans son contexte et que tu remontes deux ou trois messages plus
haut.

-- Gaby

Vous avez filtré cet utilisateur ! Consultez son message

writes:

| Gabriel Dos Reis wrote in message
| news:...
| > writes:
| > | Gabriel Dos Reis wrote in message
| > | news:...
| > | > writes:
|
| > | > | Pourquoi, pourquoi et pourquoi. Le nom du type générique, c'est
| > | > | std::vector. C'est vrai que les : ne sont pas permis dans les
| > | > | symboles en général, mais std::vector n'est pas un symbole
| > | > | général. Quant aux paramètres de types : c'est un type dérivé,
| > | > | de même que par exemple
|
| > | > « type dérivé » n'est plus utilisé depuis je ne sais quand.
|
| > | 2002, au moins:-).
|
| > 1997 au moins.
|
| C'était un typo, et je voulais dire 2000. Parce que j'ai ici un document
| daté de 2000 qui en parle -- ISO 9899::1999.

Ce document n'est pas la définition de C++ -- et n'y est même pas inclus.
Mais, comme visiblement tu n'as pas dû t'en rendre compte, nous sommes sur
fr.comp.lang.c++ et je parlais de C++ (dans un message ou on parle de
class derivee, std::vector, ... de quel autre langage pouvait-il etre
question ?)

| Je vois que je me suis
| trompé de date de toute façon, mais l'émoticon n'y était pas pour rien.
| Je suis sûr que dans certains cercles, l'expression est encore courante.
|
| > | Mais je suppose que ton énoncé se limite au C++, où ça pourrait
| > | prêter réelement à confusion.
|
| > étant donné qu'on est sur fr.comp.lang.C++ et qu'il est fait mention
| > de classe dérivée, je ne sais pas ce que tu veux imaginer d'autres.
|
| Étant donné qu'on parle de la langue (français ou anglais), et non du
| langage (C++ ou d'autre), ce n'est pas clair que ton énoncé se limitait
| à un milieu aussi restreint. Ta référence à des classes dérivées le
| laisse penser, mais je trouve que de mettre les points sur les i ne nuit
| à rien.

Sauf qu'il ne le fait pas :-(

| Ce n'était pas vraiment pour te contradire, sauf en plaisantant.

Je NE pensais PAS que tu contredisais. Ton message me donnait
l'impression de divaguer. Un message qui contredit donne en general
un signe qu'il considere le message auquel il repond dans son
contexte.

[...]

| > M. de Lapalisse ne dit pas le contraire.
|
| (Un de ces jours, il va falloir que quelqu'un m'explique qui est ce M.
| de Lapalisse dont tu parles de temps en temps. D'après les contextes, je
| crois qu'il y a une subtilité de la culture française, ou francophone,
| qui m'échappe.)
|
| > Mais cela passe, je crois, à côté de ce que je disais.
|
| Oui est non.

c'est profond.

| Si on considère la première phrase que tu as écris :
| « 'type dérivé' n'est plus utilisé depuis je ne sais quand », c'est
| manifeste que la phrase n'est pas complète -- il manque un « en parlant
| de C++ », ou quelque chose de semblable. Parce que l'énoncé, tel que tu
| l'as écrit, prète à confusion.

Bouah ha ha. Quand tu lis une phrase, il faut la lire dans son
contexte. Cela fait partie du B A BA que nous enseignons aux eleves.
Tu as une facheuse habitude a lire les phrases hors contexte et
ensuite a enoncer des trivialites (au motif que tu veux mettre les
points sur les i -- qui en avaient deja, ce qui tend a les confondre
avec un i trema). Si confusion il y a , c'est toi qui les introduit.

Avant de repondre, je suggere que tu lises l'integralite du message,
dans son contexte et que tu remontes deux ou trois messages plus
haut.

-- Gaby

Michel Michaud

09/01/2004 à 17:45

Dans news:,

"Michel Michaud" wrote in message
news:<OvfLb.72200$...
Ceci dit, ce n'est pas la seule utilité : que ça paraisse bon ou
mauvais aux yeux de certains, le passage de paramètre de sortie en
C++ est typiquement fait par des références et il est normal de
renvoyer une référence à partir d'une fonction quand c'est utile.

Là, je ne suis pas tellement d'accord. Dans l'ensemble, la référence

[...]

Dans ces deux cas, des pointeurs pourraient être utilisés, mais la
syntaxe est alors moins naturelle... sauf pour ceux qui viennent
de C

Tu viens de C, non ? CQFD :-)

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

Loïc Joly

09/01/2004 à 19:59

Gabriel Dos Reis wrote:

Loïc Joly writes:

| > J'aime
| > bien « type composé ». Mais je laisserai la décision à des vrais
| > francophones.
|
| "Type composé" a l'avantage de faire un parallèle avec l'expression
| mot composé, et un int * s'écrit bien de façon semblable à un
| "haut-parleur", et pourtant dans les deux cas, l'objet référé n'est
| pas l'association des différents éléments en jeu, mais une autre
| notion.

Tiens. Tu maintiens la même chose pour "X", où

struct X { };

ou

typedef int* X;

?

J'ai reréfléchi pendant mon sommeil, et je me suis dit que j'avais
oublié une chose : Dans l'expression "mot composé", c'est le signifiant
qui est composé, alors que dans l'expression "type composé", c'est le
signifié. Maintenant, je me rabattrai donc plus vers l'expression
"déclaration de type composée". Est-ce que ça répond à ta remarque ?

--
Loïc

Loïc Joly

09/01/2004 à 20:04

wrote:

M. de Lapalisse ne dit pas le contraire.

(Un de ces jours, il va falloir que quelqu'un m'explique qui est ce M.
de Lapalisse dont tu parles de temps en temps. D'après les contextes, je
crois qu'il y a une subtilité de la culture française, ou francophone,
qui m'échappe.)

Le Maréchal de La Palice s'illustra dans les guerres d'Italie avant de
mourir à Pavie en 1525. Ses soldats, pleins d'admiration, chantaient ses
hauts faits en ramenant son corps : " Hélas, La Palice est mort, il est
mort devant Pavie, hélas s'il n'était pas mort, il ferait encore en vie
". A cette époque, la calligraphie entre le F et le S était proche. Le
dernier vers devint : " il serait encore en vie ". La première "
Lapalissade " était née et la célébrité du maréchal assurée.

LAPALISSADE, subst. fém.
Affirmation ou réflexion niaise par laquelle on exprime une évidence ou
une banalité. Synon. truisme, vérité de La Palisse.

--
Loïc

Gabriel Dos Reis

12/01/2004 à 09:27

Loïc Joly writes:

| Gabriel Dos Reis wrote:
|
| > Loïc Joly writes:
| >
| > | > J'aime
| > | > bien « type composé ». Mais je laisserai la décision à des vrais
| > | > francophones.
| > |
| > | "Type composé" a l'avantage de faire un parallèle avec l'expression
| > | mot composé, et un int * s'écrit bien de façon semblable à un
| > | "haut-parleur", et pourtant dans les deux cas, l'objet référé n'est
| > | pas l'association des différents éléments en jeu, mais une autre
| > | notion.
| >
| > Tiens. Tu maintiens la même chose pour "X", où
| >
| > struct X { };
| >
| > ou
| >
| > typedef int* X;
| >
| > ?
|
| J'ai reréfléchi pendant mon sommeil,

commen tu fais ? ;-)

| et je me suis dit que j'avais
| oublié une chose : Dans l'expression "mot composé", c'est le signifiant
| qui est composé, alors que dans l'expression "type composé", c'est le
| signifié. Maintenant, je me rabattrai donc plus vers l'expression
| "déclaration de type composée". Est-ce que ça répond à ta remarque ?

Oui :-)

-- Gaby

[débutant]Quel langage choisir?

8 réponses

Veuillez sélectionner un problème