j'apprends C++, et je suis confronté à ce pb : passer un tableau à une
fonction, voilà un code sans utilité mais qui permet de mettre mon pb en
avant : je reçois le message d'erreur suivant: Unresolved external
'ChangerVal(int)' referenced from module prog1.cpp
#include <iostream.h>
#include <conio.h>
"Michaël Monerau" a écrit dans le message de news:pNXdb.181752$
Je n'ai pourtant que 16 ans :-)
J'aurais aimé pouvoir m'interesser à des choses comme le C++ quand j'avais 16 ans...
Il est bien, le petit ;)
Chris
Luc Hermitte
"Christophe Lephay" wrote in news:bl9g0c$idf$:
En quoi est-ce que : int tab[2] ; est plus difficile pour un débuttant que : std::vector< int > tab( 2 ) ; ? C'est une blague ?
En fait, il y a une différence entre apprendre et comprendre. Si std::vector< int > tab( 2 ) est plus dur à apprendre, l'utilisation de vector ne nécessite par contre aucune compréhension particulière. C'est exactement le contraire de int tab[ 2 ] qui s'apprend très facilement, mais qui nécessite énormément de sueur avant d'en comprendre le fonctionnement, avec le problème qu'on s'expose à de sévères migraines tant qu'on ne le maitrise pas...
Je ne dirais pas ça comme ça, bien que globalement d'accord avec le message. La parfaite compréhension de "std::vector<int>" demande de connaitre plus de choses que pour "int tab[2]". En revanche, avec std::vector<>, il n'est pas nécessaire d'avoir une parfaite compréhension de ce type pour avoir moins de galères qu'avec les tableaux à la C.
Sa force est de justement donner au C++ des outils pour atteindre un niveau d'abstraction plus élévé, qui est propice à l'étude du C++ (d'un point de vue débutant) ; plutôt que de connaitre la décomposition en micro-instructions de la traduction assembleur de tel ou tel code C++. [Savoir comment ça marche est important, mais loin d'être critique pour tout le monde.]
C'est ça que je trouve interressant : avec le C++, on dispose d'outils pour l'apprentissage qui se rapprochent de ceux que l'on peut avoir en Ada.
-- Luc Hermitte <hermitte at free.fr> FAQ de <news:fr.comp.lang.c++> : <http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/> Dejanews : <http://groups.google.com/advanced_group_search>
"Christophe Lephay" <christophe-lephay@wanadoo.fr> wrote in
news:bl9g0c$idf$1@news-reader1.wanadoo.fr:
En quoi est-ce que :
int tab[2] ;
est plus difficile pour un débuttant que :
std::vector< int > tab( 2 ) ; ?
C'est une blague ?
En fait, il y a une différence entre apprendre et comprendre. Si
std::vector< int > tab( 2 ) est plus dur à apprendre, l'utilisation de
vector ne nécessite par contre aucune compréhension particulière.
C'est exactement le contraire de int tab[ 2 ] qui s'apprend très
facilement, mais qui nécessite énormément de sueur avant d'en
comprendre le fonctionnement, avec le problème qu'on s'expose à de
sévères migraines tant qu'on ne le maitrise pas...
Je ne dirais pas ça comme ça, bien que globalement d'accord avec le
message. La parfaite compréhension de "std::vector<int>" demande de
connaitre plus de choses que pour "int tab[2]".
En revanche, avec std::vector<>, il n'est pas nécessaire d'avoir une
parfaite compréhension de ce type pour avoir moins de galères qu'avec les
tableaux à la C.
Sa force est de justement donner au C++ des outils pour atteindre un
niveau d'abstraction plus élévé, qui est propice à l'étude du C++ (d'un
point de vue débutant) ; plutôt que de connaitre la décomposition en
micro-instructions de la traduction assembleur de tel ou tel code C++.
[Savoir comment ça marche est important, mais loin d'être critique pour
tout le monde.]
C'est ça que je trouve interressant : avec le C++, on dispose d'outils
pour l'apprentissage qui se rapprochent de ceux que l'on peut avoir en
Ada.
--
Luc Hermitte <hermitte at free.fr>
FAQ de <news:fr.comp.lang.c++> :
<http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/>
Dejanews : <http://groups.google.com/advanced_group_search>
En quoi est-ce que : int tab[2] ; est plus difficile pour un débuttant que : std::vector< int > tab( 2 ) ; ? C'est une blague ?
En fait, il y a une différence entre apprendre et comprendre. Si std::vector< int > tab( 2 ) est plus dur à apprendre, l'utilisation de vector ne nécessite par contre aucune compréhension particulière. C'est exactement le contraire de int tab[ 2 ] qui s'apprend très facilement, mais qui nécessite énormément de sueur avant d'en comprendre le fonctionnement, avec le problème qu'on s'expose à de sévères migraines tant qu'on ne le maitrise pas...
Je ne dirais pas ça comme ça, bien que globalement d'accord avec le message. La parfaite compréhension de "std::vector<int>" demande de connaitre plus de choses que pour "int tab[2]". En revanche, avec std::vector<>, il n'est pas nécessaire d'avoir une parfaite compréhension de ce type pour avoir moins de galères qu'avec les tableaux à la C.
Sa force est de justement donner au C++ des outils pour atteindre un niveau d'abstraction plus élévé, qui est propice à l'étude du C++ (d'un point de vue débutant) ; plutôt que de connaitre la décomposition en micro-instructions de la traduction assembleur de tel ou tel code C++. [Savoir comment ça marche est important, mais loin d'être critique pour tout le monde.]
C'est ça que je trouve interressant : avec le C++, on dispose d'outils pour l'apprentissage qui se rapprochent de ceux que l'on peut avoir en Ada.
-- Luc Hermitte <hermitte at free.fr> FAQ de <news:fr.comp.lang.c++> : <http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/> Dejanews : <http://groups.google.com/advanced_group_search>
Christophe Lephay
"Luc Hermitte" a écrit dans le message de news:
"Christophe Lephay" wrote in news:bl9g0c$idf$:
En fait, il y a une différence entre apprendre et comprendre. Si std::vector< int > tab( 2 ) est plus dur à apprendre, l'utilisation de vector ne nécessite par contre aucune compréhension particulière. C'est exactement le contraire de int tab[ 2 ] qui s'apprend très facilement, mais qui nécessite énormément de sueur avant d'en comprendre le fonctionnement, avec le problème qu'on s'expose à de sévères migraines tant qu'on ne le maitrise pas...
Je ne dirais pas ça comme ça, bien que globalement d'accord avec le message. La parfaite compréhension de "std::vector<int>" demande de connaitre plus de choses que pour "int tab[2]". En revanche, avec std::vector<>, il n'est pas nécessaire d'avoir une parfaite compréhension de ce type pour avoir moins de galères qu'avec les tableaux à la C.
Quand je parlais de compréhension, je pensais à celle *nécessaire* en vue d'une utilisation correcte plutôt qu'à une compréhension intime, notemment celle relevant de la façon dont vector est implémenté (je suis donc d'accords avec toi)...
Chris
"Luc Hermitte" <hermitte@free.fr.invalid> a écrit dans le message de
news:Xns9406104B08556isyfur@127.0.0.1...
"Christophe Lephay" <christophe-lephay@wanadoo.fr> wrote in
news:bl9g0c$idf$1@news-reader1.wanadoo.fr:
En fait, il y a une différence entre apprendre et comprendre. Si
std::vector< int > tab( 2 ) est plus dur à apprendre, l'utilisation de
vector ne nécessite par contre aucune compréhension particulière.
C'est exactement le contraire de int tab[ 2 ] qui s'apprend très
facilement, mais qui nécessite énormément de sueur avant d'en
comprendre le fonctionnement, avec le problème qu'on s'expose à de
sévères migraines tant qu'on ne le maitrise pas...
Je ne dirais pas ça comme ça, bien que globalement d'accord avec le
message. La parfaite compréhension de "std::vector<int>" demande de
connaitre plus de choses que pour "int tab[2]".
En revanche, avec std::vector<>, il n'est pas nécessaire d'avoir une
parfaite compréhension de ce type pour avoir moins de galères qu'avec les
tableaux à la C.
Quand je parlais de compréhension, je pensais à celle *nécessaire* en vue
d'une utilisation correcte plutôt qu'à une compréhension intime, notemment
celle relevant de la façon dont vector est implémenté (je suis donc
d'accords avec toi)...
En fait, il y a une différence entre apprendre et comprendre. Si std::vector< int > tab( 2 ) est plus dur à apprendre, l'utilisation de vector ne nécessite par contre aucune compréhension particulière. C'est exactement le contraire de int tab[ 2 ] qui s'apprend très facilement, mais qui nécessite énormément de sueur avant d'en comprendre le fonctionnement, avec le problème qu'on s'expose à de sévères migraines tant qu'on ne le maitrise pas...
Je ne dirais pas ça comme ça, bien que globalement d'accord avec le message. La parfaite compréhension de "std::vector<int>" demande de connaitre plus de choses que pour "int tab[2]". En revanche, avec std::vector<>, il n'est pas nécessaire d'avoir une parfaite compréhension de ce type pour avoir moins de galères qu'avec les tableaux à la C.
Quand je parlais de compréhension, je pensais à celle *nécessaire* en vue d'une utilisation correcte plutôt qu'à une compréhension intime, notemment celle relevant de la façon dont vector est implémenté (je suis donc d'accords avec toi)...
Chris
M.B.
"Christophe Lephay" a écrit dans le message news: bl9tmd$ar6$
Pas selon l'expérience de ceux qui ont testé les deux approches...
Ceux qui ont ...
Encore faut-il en trouver pour le leur demander, car ca ne semble pas etre ton cas.
(comme quoi c'est toujours la pratique qui tranche, quelque soit la vraisemblance de la théorie).
Heureusement ...
MB
"Christophe Lephay" <christophe-lephay@wanadoo.fr> a écrit dans le message
news: bl9tmd$ar6$1@news-reader4.wanadoo.fr...
Pas selon l'expérience de ceux qui ont testé les deux approches...
Ceux qui ont ...
Encore faut-il en trouver pour le leur demander, car ca ne semble pas
etre ton cas.
(comme quoi c'est toujours la pratique qui tranche, quelque soit la
vraisemblance de la théorie).
"Christophe Lephay" a écrit dans le message news: bl9tmd$ar6$
Pas selon l'expérience de ceux qui ont testé les deux approches...
Ceux qui ont ...
Encore faut-il en trouver pour le leur demander, car ca ne semble pas etre ton cas.
(comme quoi c'est toujours la pratique qui tranche, quelque soit la vraisemblance de la théorie).
Heureusement ...
MB
kanze
"M.B." wrote in message news:<bl9fll$d48$...
a écrit dans le message news:
En quoi est-ce que : int tab[2] ; est plus difficile pour un débuttant que : std::vector< int > tab( 2 ) ; ?
C'est une blague ?
En quoi est-ce que ce serait une blague ? Le nombre de caractères n'est pas forcement égal à la complexité. Et l'utilisation de « int tab[2] » est extrèmement complexe, à cause des conversions implicites et le fait qu'il introduit l'arithmétique sur des pointeurs.
Quant aux références, c'est bien la seule façon à gérer des tableaux en C++, sans introduire des pointeurs, et surtout, l'arithmétique sur des pointeurs. Et alors ça, c'est bien quelque chose que je n'aimerais pas mettre au début d'un cours pour débuttant.
L'auteur de la question initiale a repondu en disant 'merci' la ou il fallait.
Tu veux dire : après l'explication erronée ?
-- 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
"M.B." <mbinder@magicnet.com> wrote in message
news:<bl9fll$d48$1@news-reader2.wanadoo.fr>...
<kanze@gabi-soft.fr> a écrit dans le message news:
d6652001.0309282315.3c36652a@posting.google.com...
En quoi est-ce que :
int tab[2] ;
est plus difficile pour un débuttant que :
std::vector< int > tab( 2 ) ;
?
C'est une blague ?
En quoi est-ce que ce serait une blague ? Le nombre de caractères n'est
pas forcement égal à la complexité. Et l'utilisation de « int tab[2] »
est extrèmement complexe, à cause des conversions implicites et le fait
qu'il introduit l'arithmétique sur des pointeurs.
Quant aux références, c'est bien la seule façon à gérer des tableaux
en C++, sans introduire des pointeurs, et surtout, l'arithmétique
sur des pointeurs. Et alors ça, c'est bien quelque chose que je
n'aimerais pas mettre au début d'un cours pour débuttant.
L'auteur de la question initiale a repondu en disant 'merci' la ou il
fallait.
Tu veux dire : après l'explication erronée ?
--
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
En quoi est-ce que : int tab[2] ; est plus difficile pour un débuttant que : std::vector< int > tab( 2 ) ; ?
C'est une blague ?
En quoi est-ce que ce serait une blague ? Le nombre de caractères n'est pas forcement égal à la complexité. Et l'utilisation de « int tab[2] » est extrèmement complexe, à cause des conversions implicites et le fait qu'il introduit l'arithmétique sur des pointeurs.
Quant aux références, c'est bien la seule façon à gérer des tableaux en C++, sans introduire des pointeurs, et surtout, l'arithmétique sur des pointeurs. Et alors ça, c'est bien quelque chose que je n'aimerais pas mettre au début d'un cours pour débuttant.
L'auteur de la question initiale a repondu en disant 'merci' la ou il fallait.
Tu veux dire : après l'explication erronée ?
-- 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
"M.B." wrote in message news:<bl9h5v$7qp$...
"Christophe Lephay" a écrit dans le message news: bl9gms$h2k$
"M.B." a écrit dans le message de news:bl9g97$f87$
On ne peut pas apprendre un langage informatique sans le comprendre, c'est ridicule et grotesque.
Mais en général, il faut commencer par apprendre et la compréhension vient après. C'est assez peu fréquent que la compréhension apparaisse par génération spontanée.
Particulièrement, la compréhension des tableaux de type C nécessitent pas mal de pré-requis, notemment en termes d'organisation de la mémoire. L'avantage de vector, c'est qu'il ne nécessite pas de tels pré-requis. On pourra demander à l'élève de comprendre un peu mieux l'organisation de la mémoire à un moment plus opportun qu'au tout début de son apprentissage...
Je suis me toujours farouchement opposé a ce type d'enseignement. On commence par comprendre la structure interne d'un calculateur, sa memoire, son micro, ses peripheriques, ses bus, ses adresses et ses donnees.
Pourquoi pas commencer par la structure des électrons et la physique quantique, pendant qu'on y est. C'est vrai que la formation finira par prendre une soixantaine d'années, après lesquelles on a un élève qui n'intéresse aucun employeur.
Je crois qu'il faut partir de la base qu'on n'arrivera jamais à enseigner tout ce qu'il faut savoir. Alors, pour commencer, il faudrait apprendre aux élèves de penser et d'apprendre eux-même ce dont ils ont besoin, quand ils en ont besoin. (C-à-d une façon bien mathématique à penser, et une maîtrise parfaite de leur langue maternelle.) Par la suite, on choisit des abstractions -- en général, un aprentissage de toute la structure interne du processeur est une abstraction bien trop bas pour quelqu'un qui va par la suite écrire des programmes commerciaux.
Apres la programmation est beaucoup plus facile et apprendre et a comprendre. Je n'envisage pas un seul instant de tenter d'enseigner la programmation a des gens qui ne savent pas comment fonctionne un ordinateur. C'est voué a l'echec. Au premier bug du genre 'Stack Overflow' ils sont coincés.
Dans cette demarche,
int tab[2] est beaucoup plus simple a comprendre que std::vector<int> tab (2)
Si le problème est d'écrire un compilateur, le C est un langage plus facile que le C++. Mais un programmeur qui pense à ce niveau quand il écrit des applications n'est pas un bon programmeur. Le type dérivé « tableau » existe en plusieurs formes en C++. La plus naturelle, et la plus facile à utiliser, c'est bien std::vector<T>. L'écriture est un peu bizarre, quand on le compare à d'autres langages (« array [n] of T », etc.), mais je crois que ce n'est pas le seul cas en C++.
Si on va apprendre le C++ aux débuttants de la programmation, autant que faire leur apprendre correctement.
-- 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
"M.B." <mbinder@magicnet.com> wrote in message
news:<bl9h5v$7qp$1@news-reader5.wanadoo.fr>...
"Christophe Lephay" <christophe-lephay@wanadoo.fr> a écrit dans le
message news: bl9gms$h2k$1@news-reader2.wanadoo.fr...
"M.B." <mbinder@magicnet.com> a écrit dans le message de
news:bl9g97$f87$1@news-reader2.wanadoo.fr...
On ne peut pas apprendre un langage informatique sans le
comprendre, c'est ridicule et grotesque.
Mais en général, il faut commencer par apprendre et la compréhension
vient après. C'est assez peu fréquent que la compréhension
apparaisse par génération spontanée.
Particulièrement, la compréhension des tableaux de type C
nécessitent pas mal de pré-requis, notemment en termes
d'organisation de la mémoire. L'avantage de vector, c'est qu'il ne
nécessite pas de tels pré-requis. On pourra demander à l'élève de
comprendre un peu mieux l'organisation de la mémoire à un moment
plus opportun qu'au tout début de son apprentissage...
Je suis me toujours farouchement opposé a ce type d'enseignement. On
commence par comprendre la structure interne d'un calculateur, sa
memoire, son micro, ses peripheriques, ses bus, ses adresses et ses
donnees.
Pourquoi pas commencer par la structure des électrons et la physique
quantique, pendant qu'on y est. C'est vrai que la formation finira par
prendre une soixantaine d'années, après lesquelles on a un élève qui
n'intéresse aucun employeur.
Je crois qu'il faut partir de la base qu'on n'arrivera jamais à
enseigner tout ce qu'il faut savoir. Alors, pour commencer, il faudrait
apprendre aux élèves de penser et d'apprendre eux-même ce dont ils ont
besoin, quand ils en ont besoin. (C-à-d une façon bien mathématique à
penser, et une maîtrise parfaite de leur langue maternelle.) Par la
suite, on choisit des abstractions -- en général, un aprentissage de
toute la structure interne du processeur est une abstraction bien trop
bas pour quelqu'un qui va par la suite écrire des programmes
commerciaux.
Apres la programmation est beaucoup plus facile et apprendre et a
comprendre. Je n'envisage pas un seul instant de tenter d'enseigner la
programmation a des gens qui ne savent pas comment fonctionne un
ordinateur. C'est voué a l'echec. Au premier bug du genre 'Stack
Overflow' ils sont coincés.
Dans cette demarche,
int tab[2] est beaucoup plus simple a comprendre que std::vector<int>
tab (2)
Si le problème est d'écrire un compilateur, le C est un langage plus
facile que le C++. Mais un programmeur qui pense à ce niveau quand il
écrit des applications n'est pas un bon programmeur. Le type dérivé
« tableau » existe en plusieurs formes en C++. La plus naturelle, et la
plus facile à utiliser, c'est bien std::vector<T>. L'écriture est un peu
bizarre, quand on le compare à d'autres langages (« array [n] of T »,
etc.), mais je crois que ce n'est pas le seul cas en C++.
Si on va apprendre le C++ aux débuttants de la programmation, autant que
faire leur apprendre correctement.
--
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
"Christophe Lephay" a écrit dans le message news: bl9gms$h2k$
"M.B." a écrit dans le message de news:bl9g97$f87$
On ne peut pas apprendre un langage informatique sans le comprendre, c'est ridicule et grotesque.
Mais en général, il faut commencer par apprendre et la compréhension vient après. C'est assez peu fréquent que la compréhension apparaisse par génération spontanée.
Particulièrement, la compréhension des tableaux de type C nécessitent pas mal de pré-requis, notemment en termes d'organisation de la mémoire. L'avantage de vector, c'est qu'il ne nécessite pas de tels pré-requis. On pourra demander à l'élève de comprendre un peu mieux l'organisation de la mémoire à un moment plus opportun qu'au tout début de son apprentissage...
Je suis me toujours farouchement opposé a ce type d'enseignement. On commence par comprendre la structure interne d'un calculateur, sa memoire, son micro, ses peripheriques, ses bus, ses adresses et ses donnees.
Pourquoi pas commencer par la structure des électrons et la physique quantique, pendant qu'on y est. C'est vrai que la formation finira par prendre une soixantaine d'années, après lesquelles on a un élève qui n'intéresse aucun employeur.
Je crois qu'il faut partir de la base qu'on n'arrivera jamais à enseigner tout ce qu'il faut savoir. Alors, pour commencer, il faudrait apprendre aux élèves de penser et d'apprendre eux-même ce dont ils ont besoin, quand ils en ont besoin. (C-à-d une façon bien mathématique à penser, et une maîtrise parfaite de leur langue maternelle.) Par la suite, on choisit des abstractions -- en général, un aprentissage de toute la structure interne du processeur est une abstraction bien trop bas pour quelqu'un qui va par la suite écrire des programmes commerciaux.
Apres la programmation est beaucoup plus facile et apprendre et a comprendre. Je n'envisage pas un seul instant de tenter d'enseigner la programmation a des gens qui ne savent pas comment fonctionne un ordinateur. C'est voué a l'echec. Au premier bug du genre 'Stack Overflow' ils sont coincés.
Dans cette demarche,
int tab[2] est beaucoup plus simple a comprendre que std::vector<int> tab (2)
Si le problème est d'écrire un compilateur, le C est un langage plus facile que le C++. Mais un programmeur qui pense à ce niveau quand il écrit des applications n'est pas un bon programmeur. Le type dérivé « tableau » existe en plusieurs formes en C++. La plus naturelle, et la plus facile à utiliser, c'est bien std::vector<T>. L'écriture est un peu bizarre, quand on le compare à d'autres langages (« array [n] of T », etc.), mais je crois que ce n'est pas le seul cas en C++.
Si on va apprendre le C++ aux débuttants de la programmation, autant que faire leur apprendre correctement.
-- 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
"Michaël Monerau" wrote in message news:<AwXdb.181511$...
wrote:
void ChangerVal(int tab[2])
donc là, tu définis la fonction, mais avec comme argument un tableau de int !
Pas vraiment. Là, il définit une fonction avec comme argument un pointeur vers un int.
Je ne voulais pas l'embrouiller avec des pointeurs, s'il en est aux tableaux... Mais, c'est vrai que c'est peut-être mieux de mettre les mots justes dès le début.
Peut-être, mais... Dès qu'il déclare la fonction, il est devant le problème : comme tu as dis par la suite, ça ne marche pas comme pour les int tout court.
Et ici, fais attention... Tu passes le tableau par valeur.
Non, il ne le passe pas par valeur. Il y a un tas de sombres histoires qui se passent derrière son dos, qui fait que d'une part, il a défini une fonction qui prend un pointeur (et non un tableau), et que d'autre part, des tableaux se convertissent en pointeur dans pas mal de contexte, et finalement, on tripôte avec l'arithmétique sur des pointeurs dans la fonction.
C'est ce que je dis dans la phrase suivante, mais pas aussi poussé, c'est un débutant... Ne l'embrouillons pas :-) Il aura le temps de voir ça après ! Mais c'est vrai que les vector sont beaucoup plus simples ici.
C'est effectivement ça que je voulais dire aussi. Qu'on le veuille ou non, quand on se sert des int[], on finit par avoir affaire à des pointeurs et à l'arithmétique sur pointeur. Tôt ou tard, il va falloir qu'il ait affaire aux pointeurs, mais ce n'est pas le premier sujet que j'aborderais non plus. Et moi-même, je n'utilise l'arithmétique sur pointeurs que quand j'écris des ramasse-miettes ou des choses de ce genre, de très bas niveau -- je l'évite autant que se peut au niveau applicatif.
Une des qualités essentielles d'un bon informaticien, c'est de pouvoir traiter des abstractions. Et un des grands problèmes de C, c'est que l'abstraction d'un tableau est cassée -- on voit trop l'implémentation derrière. Alors, dans la mésure qu'on a un alternatif, mieux vaut commencer par lui.
T'as de la chance que ce soit un pointeur qui soit passé à la place du tableau...
Je ne sais pas si c'est ce que j'appelle de la chance.
Je voulais dire : "t'as de la chance, ça ferait bien le résultat que tu attends (i.e. modifier le tableau donné en argument par l'appelant), mais c'est un cas particulier".
J'ai compris ce que tu voulais dire:-). Seulement, je considère que quand quelque chose marche par hazard, quand il n'aurait pas dû marcher, ce n'est pas de la chance. Ça ne fait que cacher des erreurs (dans le programme, ou dans ce cas-ci, dans la façon de penser). Et plus une erreur apparaît tard, plus il coûte cher de la corriger. Dans le programme, c'est sûr, mais j'imagine que c'est aussi vrai pour les erreurs dans la façon de penser.
-- 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
"Michaël Monerau" <cort@meloo.com> wrote in message
news:<AwXdb.181511$hd6.2307261@news.chello.at>...
kanze@gabi-soft.fr wrote:
void ChangerVal(int tab[2])
donc là, tu définis la fonction, mais avec comme argument un
tableau de int !
Pas vraiment. Là, il définit une fonction avec comme argument un
pointeur vers un int.
Je ne voulais pas l'embrouiller avec des pointeurs, s'il en est aux
tableaux... Mais, c'est vrai que c'est peut-être mieux de mettre les
mots justes dès le début.
Peut-être, mais... Dès qu'il déclare la fonction, il est devant le
problème : comme tu as dis par la suite, ça ne marche pas comme pour les
int tout court.
Et ici, fais attention... Tu passes le tableau par valeur.
Non, il ne le passe pas par valeur. Il y a un tas de sombres
histoires qui se passent derrière son dos, qui fait que d'une part,
il a défini une fonction qui prend un pointeur (et non un tableau),
et que d'autre part, des tableaux se convertissent en pointeur dans
pas mal de contexte, et finalement, on tripôte avec l'arithmétique
sur des pointeurs dans la fonction.
C'est ce que je dis dans la phrase suivante, mais pas aussi poussé,
c'est un débutant... Ne l'embrouillons pas :-) Il aura le temps de
voir ça après ! Mais c'est vrai que les vector sont beaucoup plus
simples ici.
C'est effectivement ça que je voulais dire aussi. Qu'on le veuille ou
non, quand on se sert des int[], on finit par avoir affaire à des
pointeurs et à l'arithmétique sur pointeur. Tôt ou tard, il va falloir
qu'il ait affaire aux pointeurs, mais ce n'est pas le premier sujet que
j'aborderais non plus. Et moi-même, je n'utilise l'arithmétique sur
pointeurs que quand j'écris des ramasse-miettes ou des choses de ce
genre, de très bas niveau -- je l'évite autant que se peut au niveau
applicatif.
Une des qualités essentielles d'un bon informaticien, c'est de pouvoir
traiter des abstractions. Et un des grands problèmes de C, c'est que
l'abstraction d'un tableau est cassée -- on voit trop l'implémentation
derrière. Alors, dans la mésure qu'on a un alternatif, mieux vaut
commencer par lui.
T'as de la chance que ce soit un pointeur qui soit passé à la place
du tableau...
Je ne sais pas si c'est ce que j'appelle de la chance.
Je voulais dire : "t'as de la chance, ça ferait bien le résultat que
tu attends (i.e. modifier le tableau donné en argument par
l'appelant), mais c'est un cas particulier".
J'ai compris ce que tu voulais dire:-). Seulement, je considère que
quand quelque chose marche par hazard, quand il n'aurait pas dû marcher,
ce n'est pas de la chance. Ça ne fait que cacher des erreurs (dans le
programme, ou dans ce cas-ci, dans la façon de penser). Et plus une
erreur apparaît tard, plus il coûte cher de la corriger. Dans le
programme, c'est sûr, mais j'imagine que c'est aussi vrai pour les
erreurs dans la façon de penser.
--
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
"Michaël Monerau" wrote in message news:<AwXdb.181511$...
wrote:
void ChangerVal(int tab[2])
donc là, tu définis la fonction, mais avec comme argument un tableau de int !
Pas vraiment. Là, il définit une fonction avec comme argument un pointeur vers un int.
Je ne voulais pas l'embrouiller avec des pointeurs, s'il en est aux tableaux... Mais, c'est vrai que c'est peut-être mieux de mettre les mots justes dès le début.
Peut-être, mais... Dès qu'il déclare la fonction, il est devant le problème : comme tu as dis par la suite, ça ne marche pas comme pour les int tout court.
Et ici, fais attention... Tu passes le tableau par valeur.
Non, il ne le passe pas par valeur. Il y a un tas de sombres histoires qui se passent derrière son dos, qui fait que d'une part, il a défini une fonction qui prend un pointeur (et non un tableau), et que d'autre part, des tableaux se convertissent en pointeur dans pas mal de contexte, et finalement, on tripôte avec l'arithmétique sur des pointeurs dans la fonction.
C'est ce que je dis dans la phrase suivante, mais pas aussi poussé, c'est un débutant... Ne l'embrouillons pas :-) Il aura le temps de voir ça après ! Mais c'est vrai que les vector sont beaucoup plus simples ici.
C'est effectivement ça que je voulais dire aussi. Qu'on le veuille ou non, quand on se sert des int[], on finit par avoir affaire à des pointeurs et à l'arithmétique sur pointeur. Tôt ou tard, il va falloir qu'il ait affaire aux pointeurs, mais ce n'est pas le premier sujet que j'aborderais non plus. Et moi-même, je n'utilise l'arithmétique sur pointeurs que quand j'écris des ramasse-miettes ou des choses de ce genre, de très bas niveau -- je l'évite autant que se peut au niveau applicatif.
Une des qualités essentielles d'un bon informaticien, c'est de pouvoir traiter des abstractions. Et un des grands problèmes de C, c'est que l'abstraction d'un tableau est cassée -- on voit trop l'implémentation derrière. Alors, dans la mésure qu'on a un alternatif, mieux vaut commencer par lui.
T'as de la chance que ce soit un pointeur qui soit passé à la place du tableau...
Je ne sais pas si c'est ce que j'appelle de la chance.
Je voulais dire : "t'as de la chance, ça ferait bien le résultat que tu attends (i.e. modifier le tableau donné en argument par l'appelant), mais c'est un cas particulier".
J'ai compris ce que tu voulais dire:-). Seulement, je considère que quand quelque chose marche par hazard, quand il n'aurait pas dû marcher, ce n'est pas de la chance. Ça ne fait que cacher des erreurs (dans le programme, ou dans ce cas-ci, dans la façon de penser). Et plus une erreur apparaît tard, plus il coûte cher de la corriger. Dans le programme, c'est sûr, mais j'imagine que c'est aussi vrai pour les erreurs dans la façon de penser.
-- 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
M.B.
a écrit dans le message news:
Si on va apprendre le C++ aux débuttants de la programmation, autant que faire leur apprendre correctement.
Le mieux est d'essayer et de voir le resultat.
MB
<kanze@gabi-soft.fr> a écrit dans le message news:
d6652001.0309300017.1614ef41@posting.google.com...
Si on va apprendre le C++ aux débuttants de la programmation, autant que
faire leur apprendre correctement.
"M.B." a écrit dans le message de news:blba2u$g17$
"Christophe Lephay" a écrit dans le message news: bl9tmd$ar6$
Pas selon l'expérience de ceux qui ont testé les deux approches...
Ceux qui ont ...
"Accelerated C++" (Koenig & Moo) est un ouvrage qui semble faire référence en terme de didactique et, dans tous les cas, un moyen de partager [une partie d'] une telle expérience...
Chris
"M.B." <mbinder@magicnet.com> a écrit dans le message de
news:blba2u$g17$1@news-reader3.wanadoo.fr...
"Christophe Lephay" <christophe-lephay@wanadoo.fr> a écrit dans le message
news: bl9tmd$ar6$1@news-reader4.wanadoo.fr...
Pas selon l'expérience de ceux qui ont testé les deux approches...
Ceux qui ont ...
"Accelerated C++" (Koenig & Moo) est un ouvrage qui semble faire référence
en terme de didactique et, dans tous les cas, un moyen de partager [une
partie d'] une telle expérience...
"M.B." a écrit dans le message de news:blba2u$g17$
"Christophe Lephay" a écrit dans le message news: bl9tmd$ar6$
Pas selon l'expérience de ceux qui ont testé les deux approches...
Ceux qui ont ...
"Accelerated C++" (Koenig & Moo) est un ouvrage qui semble faire référence en terme de didactique et, dans tous les cas, un moyen de partager [une partie d'] une telle expérience...