J'aurai besoin des lumières des âmes charitables.
j'aimerais apprendre un langage de programmation, et en particulier le C++.
Mais je connais très peu de choses en programmation.
Ma question est la suivante:
-Peut on commencer directement par l'apprentissage du C++, ou dois-je passer
par un autre langage avant (tel que le C).
-Est il possible d'apprendre depuis des ouvrages traitant du sujet, de
manière autodidacte? Si oui Quel sont les ouvrages les plus pédagogiques ou
les plus adaptés pour un autodidacte?
"Alexandre" wrote in message news:<3ffb0ff4$0$7160$...
[...]
Le langage C++ ne comporte pas d'API standard pour interface graphique dans sa spécification et les API de collections comme la STL sont souvent d'une lourdeur syntaxique...
surtout pour un débutant !!! Difficile d'expliquer à qqn que std::vector<int> V(10); est bcp mieux que int V[10];
Pour un débutant, ils sont tous les deux nouveaux. Alors, si on ne lui montre que le premier, il va probablement trouver que c'est verbose (ce qui est vrai), mais pour la reste, je ne vois pas de problème.
alors que syntaxiquement c'est pas clair, qu'il faut déjà avoir compris la notion d'espace de noms, de paramètre de type, de constructeur...
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 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 ?
-- 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
"Alexandre" <alex.g@netcourrier.com> wrote in message
news:<3ffb0ff4$0$7160$626a54ce@news.free.fr>...
[...]
Le langage C++ ne comporte pas d'API standard pour interface
graphique dans sa spécification et les API de collections comme la
STL sont souvent d'une lourdeur syntaxique...
surtout pour un débutant !!! Difficile d'expliquer à qqn que
std::vector<int> V(10);
est bcp mieux que
int V[10];
Pour un débutant, ils sont tous les deux nouveaux. Alors, si on ne lui
montre que le premier, il va probablement trouver que c'est verbose (ce
qui est vrai), mais pour la reste, je ne vois pas de problème.
alors que syntaxiquement c'est pas clair, qu'il faut déjà avoir
compris la notion d'espace de noms, de paramètre de type, de
constructeur...
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
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 ?
--
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
"Alexandre" wrote in message news:<3ffb0ff4$0$7160$...
[...]
Le langage C++ ne comporte pas d'API standard pour interface graphique dans sa spécification et les API de collections comme la STL sont souvent d'une lourdeur syntaxique...
surtout pour un débutant !!! Difficile d'expliquer à qqn que std::vector<int> V(10); est bcp mieux que int V[10];
Pour un débutant, ils sont tous les deux nouveaux. Alors, si on ne lui montre que le premier, il va probablement trouver que c'est verbose (ce qui est vrai), mais pour la reste, je ne vois pas de problème.
alors que syntaxiquement c'est pas clair, qu'il faut déjà avoir compris la notion d'espace de noms, de paramètre de type, de constructeur...
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 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 ?
-- 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
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. Cela prète à confusion avec « classe derivée. » Le terme correct est « compound type » -- que je traduirais pas « type composite » (« type composé » ?).
| 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.
-- Gaby
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. Cela
prète à confusion avec « classe derivée. » Le terme correct est
« compound type » -- que je traduirais pas « type composite » (« type
composé » ?).
| 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.
| 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. Cela prète à confusion avec « classe derivée. » Le terme correct est « compound type » -- que je traduirais pas « type composite » (« type composé » ?).
| 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.
-- Gaby
adebaene
"Alexandre" wrote in message news:<3ffb0ff4$0$7160$...
Les langages "agréables" pour débuter sont, par exemple, Python ou Java (Je
mentionne Java par démagogie, parce que le langage est assez élégant, mais je trouve l'API épouvantable).
Oui, et puis si on a du mal à comprendre la POO, c'est pas l'idéal, Java ;-)
(si quelqu'un pouvait m'expliquer la nécessité d'existence simultanée des objets "valeurs", des références et des pointeurs sur objets plutôt que seulement des références ?).
Objets valeurs : essentiels pour travailler "bas niveau".
Ca veut dire quoi "bas niveau" dans ce contexte?
Il me semble que tu oublies le plus important : les variables par valeur permettent de contrôler la durée de vie de l'objet de manière automatique, et ouvrent par ce biais la possibilité d'idiomes extrêmement utiles comme RAII.
Et puis, passer un
bool par référence constante c'est plus lourd ;-) Objets références : pratiques pour éviter de passer un pointeur sur un paramètre out, pratique pour éviter des copies, etc... Objets pointeurs : est-ce utile de préciser l'interet des pointeurs ? Ben oui c'est utile, j'aimerais savoir à quoi tu penses exactement...
Arnaud MVP - VC
"Alexandre" <alex.g@netcourrier.com> wrote in message news:<3ffb0ff4$0$7160$626a54ce@news.free.fr>...
Les langages "agréables" pour débuter sont, par exemple, Python ou Java
(Je
mentionne Java par démagogie, parce que le langage est assez élégant, mais
je trouve l'API épouvantable).
Oui, et puis si on a du mal à comprendre la POO, c'est pas l'idéal, Java ;-)
(si quelqu'un pouvait m'expliquer la nécessité d'existence simultanée des
objets "valeurs", des références et des pointeurs sur objets plutôt que
seulement des références ?).
Objets valeurs : essentiels pour travailler "bas niveau".
Ca veut dire quoi "bas niveau" dans ce contexte?
Il me semble que tu oublies le plus important : les variables par
valeur permettent de contrôler la durée de vie de l'objet de manière
automatique, et ouvrent par ce biais la possibilité d'idiomes
extrêmement utiles comme RAII.
Et puis, passer un
bool par référence constante c'est plus lourd ;-)
Objets références : pratiques pour éviter de passer un pointeur sur un
paramètre out, pratique pour éviter des copies, etc...
Objets pointeurs : est-ce utile de préciser l'interet des pointeurs ?
Ben oui c'est utile, j'aimerais savoir à quoi tu penses exactement...
"Alexandre" wrote in message news:<3ffb0ff4$0$7160$...
Les langages "agréables" pour débuter sont, par exemple, Python ou Java (Je
mentionne Java par démagogie, parce que le langage est assez élégant, mais je trouve l'API épouvantable).
Oui, et puis si on a du mal à comprendre la POO, c'est pas l'idéal, Java ;-)
(si quelqu'un pouvait m'expliquer la nécessité d'existence simultanée des objets "valeurs", des références et des pointeurs sur objets plutôt que seulement des références ?).
Objets valeurs : essentiels pour travailler "bas niveau".
Ca veut dire quoi "bas niveau" dans ce contexte?
Il me semble que tu oublies le plus important : les variables par valeur permettent de contrôler la durée de vie de l'objet de manière automatique, et ouvrent par ce biais la possibilité d'idiomes extrêmement utiles comme RAII.
Et puis, passer un
bool par référence constante c'est plus lourd ;-) Objets références : pratiques pour éviter de passer un pointeur sur un paramètre out, pratique pour éviter des copies, etc... Objets pointeurs : est-ce utile de préciser l'interet des pointeurs ? Ben oui c'est utile, j'aimerais savoir à quoi tu penses exactement...
Arnaud MVP - VC
kanze
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:-). Mais je suppose que ton énoncé se limite au C++, où ça pourrait prêter réelement à confusion. (La norme C parle toujours des « derived types ».)
Cela prète à confusion avec « classe derivée. » Le terme correct est « compound type » -- que je traduirais pas « type composite » (« type composé » ?).
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 indique la composition au moyen de divers opérateurs et mots clés du langage. Donc, à partir d'int, on peut faire des choses comme : int*, int (*)(), etc. Où std::vector<int>, std::list<int>, etc. -- dans la mesure que le langage offre plusieurs structures de composition, je ne vois pas où il y a un problème d'utiliser des symbols (à la place des opérateurs) pour les spécifier.
AMHA, c'est à mon avis une amélioration par rapport à C, et bien que verbose, je préfère std::vector<int> a à int a[N] -- quelque chose comme le int [N] a de Java serait à la rigueur acceptable s'il n'y avait pas d'autre structures de collection. Mais dans l'ensemble, je préfère la syntaxe des déclarations en Pascal : a: ARRAY [ IndexType ] OF INTEGER (ou il faut que IndexType soit un type « subrange »).
-- 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:<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:-). Mais je suppose que ton énoncé se limite au C++, où
ça pourrait prêter réelement à confusion. (La norme C parle toujours
des « derived types ».)
Cela prète à confusion avec « classe derivée. » Le terme correct est «
compound type » -- que je traduirais pas « type composite » (« type
composé » ?).
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
indique la composition au moyen de divers opérateurs et mots clés du
langage. Donc, à partir d'int, on peut faire des choses comme : int*,
int (*)(), etc. Où std::vector<int>, std::list<int>, etc. -- dans la
mesure que le langage offre plusieurs structures de composition, je ne
vois pas où il y a un problème d'utiliser des symbols (à la place des
opérateurs) pour les spécifier.
AMHA, c'est à mon avis une amélioration par rapport à C, et bien que
verbose, je préfère std::vector<int> a à int a[N] -- quelque chose comme
le int [N] a de Java serait à la rigueur acceptable s'il n'y avait pas
d'autre structures de collection. Mais dans l'ensemble, je préfère la
syntaxe des déclarations en Pascal : a: ARRAY [ IndexType ] OF INTEGER
(ou il faut que IndexType soit un type « subrange »).
--
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
| 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:-). Mais je suppose que ton énoncé se limite au C++, où ça pourrait prêter réelement à confusion. (La norme C parle toujours des « derived types ».)
Cela prète à confusion avec « classe derivée. » Le terme correct est « compound type » -- que je traduirais pas « type composite » (« type composé » ?).
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 indique la composition au moyen de divers opérateurs et mots clés du langage. Donc, à partir d'int, on peut faire des choses comme : int*, int (*)(), etc. Où std::vector<int>, std::list<int>, etc. -- dans la mesure que le langage offre plusieurs structures de composition, je ne vois pas où il y a un problème d'utiliser des symbols (à la place des opérateurs) pour les spécifier.
AMHA, c'est à mon avis une amélioration par rapport à C, et bien que verbose, je préfère std::vector<int> a à int a[N] -- quelque chose comme le int [N] a de Java serait à la rigueur acceptable s'il n'y avait pas d'autre structures de collection. Mais dans l'ensemble, je préfère la syntaxe des déclarations en Pascal : a: ARRAY [ IndexType ] OF INTEGER (ou il faut que IndexType soit un type « subrange »).
-- 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
Loïc Joly
wrote:
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).
Moi aussi.
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.
Ce n'est pas évident de traduire ce genre de terme. Une autre possibilité serait de s'éloigner un peu de l'anglais pour une expression comme "type construit".
-- Loïc
kanze@gabi-soft.fr wrote:
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).
Moi aussi.
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.
Ce n'est pas évident de traduire ce genre de terme. Une autre
possibilité serait de s'éloigner un peu de l'anglais pour une expression
comme "type construit".
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).
Moi aussi.
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.
Ce n'est pas évident de traduire ce genre de terme. Une autre possibilité serait de s'éloigner un peu de l'anglais pour une expression comme "type construit".
-- Loïc
Gabriel Dos Reis
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;
?
| Ce n'est pas évident de traduire ce genre de terme. Une autre | possibilité serait de s'éloigner un peu de l'anglais pour une | expression comme "type construit".
-- Gaby
Loïc Joly <loic.actarus.joly@wanadoo.fr> 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;
?
| Ce n'est pas évident de traduire ce genre de terme. Une autre
| possibilité serait de s'éloigner un peu de l'anglais pour une
| expression comme "type construit".
| > 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;
?
| Ce n'est pas évident de traduire ce genre de terme. Une autre | possibilité serait de s'éloigner un peu de l'anglais pour une | expression comme "type construit".
-- Gaby
Gabriel Dos Reis
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.
| 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.
| (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. Mais cela passe, je crois, à côté de ce que je disais.
| indique la composition au moyen de divers opérateurs et mots clés du | langage. Donc, à partir d'int, on peut faire des choses comme : int*, | int (*)(), etc. Où std::vector<int>, std::list<int>, etc. -- dans la | mesure que le langage offre plusieurs structures de composition, je ne | vois pas où il y a un problème d'utiliser des symbols (à la place des | opérateurs) pour les spécifier.
???
-- Gaby
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.
| 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.
| (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. Mais cela passe, je crois, à
côté de ce que je disais.
| indique la composition au moyen de divers opérateurs et mots clés du
| langage. Donc, à partir d'int, on peut faire des choses comme : int*,
| int (*)(), etc. Où std::vector<int>, std::list<int>, etc. -- dans la
| mesure que le langage offre plusieurs structures de composition, je ne
| vois pas où il y a un problème d'utiliser des symbols (à la place des
| opérateurs) pour les spécifier.
| 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.
| 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.
| (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. Mais cela passe, je crois, à côté de ce que je disais.
| indique la composition au moyen de divers opérateurs et mots clés du | langage. Donc, à partir d'int, on peut faire des choses comme : int*, | int (*)(), etc. Où std::vector<int>, std::list<int>, etc. -- dans la | mesure que le langage offre plusieurs structures de composition, je ne | vois pas où il y a un problème d'utiliser des symbols (à la place des | opérateurs) pour les spécifier.
???
-- Gaby
Arnaud ARZUFFI
Loïc Joly wrote:
Pour moi, ces trois concepts répondent à des besoins différents. Peux-tu développer en quoi tu les trouve redondants, afin que je puisse mieux comprendre ton point de vue (et éventuellement sortir des contre-arguments).
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 !
-- Arnaud ARZUFFI
Loïc Joly wrote:
Pour moi, ces trois concepts répondent à des besoins différents. Peux-tu
développer en quoi tu les trouve redondants, afin que je puisse mieux
comprendre ton point de vue (et éventuellement sortir des
contre-arguments).
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 !
Pour moi, ces trois concepts répondent à des besoins différents. Peux-tu développer en quoi tu les trouve redondants, afin que je puisse mieux comprendre ton point de vue (et éventuellement sortir des contre-arguments).
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 !
-- Arnaud ARZUFFI
Arnaud ARZUFFI
Willy wrote:
Java (Je mentionne Java par démagogie, parce que le langage est assez élégant, mais je trouve l'API épouvantable).
Pourquoi ?
Un extrême lourdeur pour effectuer des actions élémentaires : pour écrire dans un fichier (c'est basique pourtant !), l'étudiant devra connaître les exceptions, et manipuler toutes ces classes (BufferedWriter, OutputStreamWriter et compagnie...) Effectivement, l'architecture est assez élégante, mais je me rappelle que lorsque j'ai découvert Java, j'ai souffert avec ces choses...
-- Arnaud ARZUFFI
Willy wrote:
Java (Je mentionne Java par démagogie, parce que le langage est assez
élégant, mais je trouve l'API épouvantable).
Pourquoi ?
Un extrême lourdeur pour effectuer des actions élémentaires : pour écrire
dans un fichier (c'est basique pourtant !), l'étudiant devra connaître les
exceptions, et manipuler toutes ces classes (BufferedWriter,
OutputStreamWriter et compagnie...) Effectivement, l'architecture est assez
élégante, mais je me rappelle que lorsque j'ai découvert Java, j'ai
souffert avec ces choses...
Java (Je mentionne Java par démagogie, parce que le langage est assez élégant, mais je trouve l'API épouvantable).
Pourquoi ?
Un extrême lourdeur pour effectuer des actions élémentaires : pour écrire dans un fichier (c'est basique pourtant !), l'étudiant devra connaître les exceptions, et manipuler toutes ces classes (BufferedWriter, OutputStreamWriter et compagnie...) Effectivement, l'architecture est assez élégante, mais je me rappelle que lorsque j'ai découvert Java, j'ai souffert avec ces choses...
-- Arnaud ARZUFFI
Michel Michaud
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. »
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. Dans ces deux cas, des pointeurs pourraient être utilisés, mais la syntaxe est alors moins naturelle... sauf pour ceux qui viennent de C !
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
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. »
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. Dans ces deux cas, des pointeurs pourraient être utilisés,
mais la syntaxe est alors moins naturelle... sauf pour ceux qui
viennent de C !
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
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. »
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. Dans ces deux cas, des pointeurs pourraient être utilisés, mais la syntaxe est alors moins naturelle... sauf pour ceux qui viennent de C !
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
