Comme le dit le sujet, j'=E9cris ce post pour parler et d=E9battre autour d=
e l'apprentissage et l'enseignement _moderne_ du C++.
En effet, comme vous le savez sans doute, dans la majorit=E9 des cursus inf=
ormatiques (tout du moins, en France), l'on retrouve toute une partie sur l=
'apprentissage de la programmation, et sur le C++.
De mon point de vue, il s'agit de l'un des langages les plus complexes =E0 =
appr=E9hender, ce qui rend son enseignement tr=E8s d=E9licat. Les cours dis=
pens=E9s dans les diff=E9rentes =E9coles se doivent d'=EAtre rigoureux, en =
r=E9duisant le plus possible les approximations que l'on pourrait y trouver=
.
Cependant, de ma propre constatation, au sein du corps enseignant, rares so=
nt les enseignants =E0 se tenir au gout du jour (l'informatique =E9tant un =
secteur =E9voluant tr=E8s vite), et =E0 imposer une r=E9elle rigueur dans l=
es cours dispens=E9s aux =E9l=E8ves. Au final, on se retrouve donc avec un =
cours plut=F4t approximatif, aux exemples mal choisis et idioms et pratique=
s courantes pas toujours respect=E9es.
C'est pour cela que je souhaite instaurer le d=E9bat, avec des personnes d'=
exp=E9rience, venant de l'industrie m=EAme, et ayant dans la plupart des ca=
s vu =E9voluer le langage, voire son enseignement (dans les diff=E9rents bo=
uquins, cours, ...). En outre, avec l'arriv=E9e r=E9cente du nouveau standa=
rd C++11, cela risque de remettre pas mal de choses et de cours en question=
.
Pensez-vous qu'il est pour l'instant trop pr=E9matur=E9 d'introduire certai=
nes notions et fonctionnalit=E9s de C++11 dans les cours actuels ? Pensez-v=
ous que cela rentre dans le cadre de la =AB renaissance =BB du C++, et doit=
donc faire parti de l'enseignement moderne du C++ ? A l'heure actuelle, ra=
res sont les bouquins ayant =E9t=E9 mis =E0 jour pour C++11 (=E0 part les b=
ouquins faisant =E9tat de TR1). Cela ne risque donc t-il pas de poser un pr=
obl=E8me au niveau des ressources disponibles pour les =E9tudiants ?
D'autre part, certains cours de C++ se basent et supposent, de la part des =
=E9tudiants, qu'ils poss=E8dent d=E9j=E0 des bases en C. Ainsi, ces cours r=
eposent sur des notions acquises en C. Pensez-vous qu'aujourd'hui, en 2011,=
cela a t-il encore r=E9ellement un sens ? Scott Meyers nous disait que l'u=
tilisation de C++ rassemblait 4 entit=E9s :
- le C
- L'orient=E9 objet
- La programmation g=E9n=E9rique avec les templates
- la STL
Est-il donc encore, en 2011, r=E9ellement productif et justifi=E9 de passer=
par la case =AB C =BB avant d'introduire le C++ ?=20
Enfin, si aujourd'hui, on vous demandait d'enseigner le C++, quelles seraie=
nt les lignes directrices de votre cours ? Quel serait le =AB plan =BB de v=
otre cours ? Passeriez-vous du temps pour =AB v=E9rifier =BB les acquis du =
C, ou bien vous concentreriez-vous exclusivement sur le C++, ses pratiques =
et ses idioms en =E9voquant les parties h=E9rit=E9es du C lorsqu'il le faut=
?
Si je pose ces questions, c'est car j'aimerais r=E9colter l'avis de personn=
es ayant pass=E9 de nombreuses ann=E9es dans l'industrie, et non pas seulem=
ent dans le domaine accad=E9mique. Les deux ne sont, selon moi, pas incompa=
tible, et peuvent travailler ensemble.
Parce que je ne vois pas comment attaquer brutalement le C++ sans avoir quelques connaissances sur des langages plus simple.
C'est toi qui envisageait de ne pas parler de langages :
À l'extrème limite, un cours de C++ devrait être un cours de programmation objet indépendant de tout langage
espie
In article , Fabien LE LEZ wrote:
Ce que je voulais dire, c'est que pour ces profs-là, une chaîne de caractères s'écrit :
char* p= new char [taille];
i.e. une copie exacte de code C, mais en remplaçant "malloc()" par "new".
Alors qu'on devrait enseigner d'abord std::string, et laisser les histoires de char* pour les derniers chapitres.
J'ai pas encore eu le temps de lire en detail la norme 2011, mais au moins en C++98, des que tu veux interagir avec le systeme, t'es bien oblige de te farcir des char *.
Rappel: les std::string de 98 etaient un rajout un peu de derniere minute, et par exemple, il n'y a meme pas de constructeur de fichier qui prend un std::string en parametre... ca fait un peu pitie.
Du coup, les chausse-trappes a la .c_str prennent une importance quelque peu disproportionnee, mais malheureusement justifiee...
In article <7cuge7dcf9ap2ap63dt6r6m87bspb9e79a@4ax.com>,
Fabien LE LEZ <usenet19@x.edulang.com> wrote:
Ce que je voulais dire, c'est que pour ces profs-là, une chaîne de
caractères s'écrit :
char* p= new char [taille];
i.e. une copie exacte de code C, mais en remplaçant "malloc()" par
"new".
Alors qu'on devrait enseigner d'abord std::string, et laisser les
histoires de char* pour les derniers chapitres.
J'ai pas encore eu le temps de lire en detail la norme 2011, mais au moins
en C++98, des que tu veux interagir avec le systeme, t'es bien oblige de
te farcir des char *.
Rappel: les std::string de 98 etaient un rajout un peu de derniere minute, et
par exemple, il n'y a meme pas de constructeur de fichier qui prend un
std::string en parametre... ca fait un peu pitie.
Du coup, les chausse-trappes a la .c_str prennent une importance quelque
peu disproportionnee, mais malheureusement justifiee...
Ce que je voulais dire, c'est que pour ces profs-là, une chaîne de caractères s'écrit :
char* p= new char [taille];
i.e. une copie exacte de code C, mais en remplaçant "malloc()" par "new".
Alors qu'on devrait enseigner d'abord std::string, et laisser les histoires de char* pour les derniers chapitres.
J'ai pas encore eu le temps de lire en detail la norme 2011, mais au moins en C++98, des que tu veux interagir avec le systeme, t'es bien oblige de te farcir des char *.
Rappel: les std::string de 98 etaient un rajout un peu de derniere minute, et par exemple, il n'y a meme pas de constructeur de fichier qui prend un std::string en parametre... ca fait un peu pitie.
Du coup, les chausse-trappes a la .c_str prennent une importance quelque peu disproportionnee, mais malheureusement justifiee...
Parce que je ne vois pas comment attaquer brutalement le C++ sans avoir quelques connaissances sur des langages plus simple. Attaquer par el C++, c'est faisable, mais c'est tout de même ardu.
JKB
ca va etre beaucoup moins casse-bonbons en C++2011 qu'en 98, hein. Une fois qu'on pourra faire vraiment plus que le cours theorique, et qu'on sera certain qu'en lachant les etudiants sur du projet, ils vont tomber sur des trucs existants, et pas sur un bout de bibliotheque encore manquante a emuler a la main...
In article <slrnjeh9aq.mpi.jkb@rayleigh.systella.fr>,
JKB <jkb@koenigsberg.invalid> wrote:
Parce que je ne vois pas comment attaquer brutalement le C++ sans
avoir quelques connaissances sur des langages plus simple. Attaquer
par el C++, c'est faisable, mais c'est tout de même ardu.
JKB
ca va etre beaucoup moins casse-bonbons en C++2011 qu'en 98, hein. Une fois
qu'on pourra faire vraiment plus que le cours theorique, et qu'on sera
certain qu'en lachant les etudiants sur du projet, ils vont tomber sur des
trucs existants, et pas sur un bout de bibliotheque encore manquante a emuler
a la main...
Parce que je ne vois pas comment attaquer brutalement le C++ sans avoir quelques connaissances sur des langages plus simple. Attaquer par el C++, c'est faisable, mais c'est tout de même ardu.
JKB
ca va etre beaucoup moins casse-bonbons en C++2011 qu'en 98, hein. Une fois qu'on pourra faire vraiment plus que le cours theorique, et qu'on sera certain qu'en lachant les etudiants sur du projet, ils vont tomber sur des trucs existants, et pas sur un bout de bibliotheque encore manquante a emuler a la main...
Lucas Levrel
Le 14 décembre 2011, Wykaaa a écrit :
Fabien LE LEZ a écrit :
Comparé au passage par valeur, le passage par référence constante n'est qu'une optimisation, que le compilo devrait se charger de faire lui-même.
Oui, le compilo devrait le faire lui-même, je n'ai pas dit autre chose. Ca devrait être le défaut. Pourquoi ? Parce que à chaque passage par valeur d'une instance de classe qui comporte un constructeur de copie, celui-ci est appelé alors que dans la majorité des cas ce n'est pas nécessaire. J'ai vu un programme ou, en transformant tous les passages par valeurs en références constante, on a gagné presque 30% en temps d'exécution !
Est-ce que le passage par référence constante est plus efficace que le passage par valeur pour les types « élémentaires » (je ne connais pas le terme canonique) char, int, float, double ?
-- LL
Le 14 décembre 2011, Wykaaa a écrit :
Fabien LE LEZ a écrit :
Comparé au passage par valeur, le passage par référence constante
n'est qu'une optimisation, que le compilo devrait se charger de faire
lui-même.
Oui, le compilo devrait le faire lui-même, je n'ai pas dit autre chose. Ca
devrait être le défaut.
Pourquoi ?
Parce que à chaque passage par valeur d'une instance de classe qui comporte
un constructeur de copie, celui-ci est appelé alors que dans la majorité des
cas ce n'est pas nécessaire.
J'ai vu un programme ou, en transformant tous les passages par valeurs en
références constante, on a gagné presque 30% en temps d'exécution !
Est-ce que le passage par référence constante est plus efficace que le
passage par valeur pour les types « élémentaires » (je ne connais pas le
terme canonique) char, int, float, double ?
Comparé au passage par valeur, le passage par référence constante n'est qu'une optimisation, que le compilo devrait se charger de faire lui-même.
Oui, le compilo devrait le faire lui-même, je n'ai pas dit autre chose. Ca devrait être le défaut. Pourquoi ? Parce que à chaque passage par valeur d'une instance de classe qui comporte un constructeur de copie, celui-ci est appelé alors que dans la majorité des cas ce n'est pas nécessaire. J'ai vu un programme ou, en transformant tous les passages par valeurs en références constante, on a gagné presque 30% en temps d'exécution !
Est-ce que le passage par référence constante est plus efficace que le passage par valeur pour les types « élémentaires » (je ne connais pas le terme canonique) char, int, float, double ?
-- LL
Lucas Levrel
Le 14 décembre 2011, Wykaaa a écrit :
JKB a écrit :
DEC C++, au moins sur VMS en version VAX. Qu'est-ce que je gagne ?
Effectivement. Je l'avais oublié celui-là. De plus, VMS est un des meilleurs OS que j'ai connu.
Tu gagnes ma considération et c'est beaucoup ;-)
Je crois qu'il préférerait gagner une participation à FreeVMS !
-- LL
Le 14 décembre 2011, Wykaaa a écrit :
JKB a écrit :
DEC C++, au moins sur VMS en version VAX. Qu'est-ce que je gagne ?
Effectivement. Je l'avais oublié celui-là. De plus, VMS est un des meilleurs
OS que j'ai connu.
Tu gagnes ma considération et c'est beaucoup ;-)
Je crois qu'il préférerait gagner une participation à FreeVMS !
DEC C++, au moins sur VMS en version VAX. Qu'est-ce que je gagne ?
Effectivement. Je l'avais oublié celui-là. De plus, VMS est un des meilleurs OS que j'ai connu.
Tu gagnes ma considération et c'est beaucoup ;-)
Je crois qu'il préférerait gagner une participation à FreeVMS !
-- LL
JKB
Le Thu, 15 Dec 2011 10:02:27 +0100, Lucas Levrel écrivait :
Le 14 décembre 2011, Wykaaa a écrit :
Fabien LE LEZ a écrit :
Comparé au passage par valeur, le passage par référence constante n'est qu'une optimisation, que le compilo devrait se charger de faire lui-même.
Oui, le compilo devrait le faire lui-même, je n'ai pas dit autre chose. Ca devrait être le défaut. Pourquoi ? Parce que à chaque passage par valeur d'une instance de classe qui comporte un constructeur de copie, celui-ci est appelé alors que dans la majorité des cas ce n'est pas nécessaire. J'ai vu un programme ou, en transformant tous les passages par valeurs en références constante, on a gagné presque 30% en temps d'exécution !
Est-ce que le passage par référence constante est plus efficace que le passage par valeur pour les types « élémentaires » (je ne connais pas le terme canonique) char, int, float, double ?
J'aurais tendance à dire que ça dépend de l'architecture (et du type et du nombre de piles utilisées, voire de la fenêtre de registres et de problèmes rigolo d'alignement des données en mémoire...). Typiquement, sur du sparc, la réponse est non tant qu'on ne dépasse pas huit arguments de même type. Si on dépasse ces huit arguments, il vaut mieux utiliser une référence constante parce qu'on sort de la fenêtre. Sur du x86, ça va dépendre de l'ABI (en 32 bits, il y a une foultitude d'ABI concurrentes alors qu'en 64 bits, un esprit sage a réussi à limiter ce nombre à ... 1 !). Sous VMS, DEC C et C++ optimisent un peu dans le dos de l'utilisateur. C'est vrai sur VAX parce que l'assembleur est vraiment bien fichu (il connaît même directement les listes chaînées), mais je n'ai pas regardé sur mon Alpha le code généré.
Il n'y a donc pas de réponse simple à cette question, mais dans le doute...
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Thu, 15 Dec 2011 10:02:27 +0100,
Lucas Levrel <lucas.levrel@u-pec.fr> écrivait :
Le 14 décembre 2011, Wykaaa a écrit :
Fabien LE LEZ a écrit :
Comparé au passage par valeur, le passage par référence constante
n'est qu'une optimisation, que le compilo devrait se charger de faire
lui-même.
Oui, le compilo devrait le faire lui-même, je n'ai pas dit autre chose. Ca
devrait être le défaut.
Pourquoi ?
Parce que à chaque passage par valeur d'une instance de classe qui comporte
un constructeur de copie, celui-ci est appelé alors que dans la majorité des
cas ce n'est pas nécessaire.
J'ai vu un programme ou, en transformant tous les passages par valeurs en
références constante, on a gagné presque 30% en temps d'exécution !
Est-ce que le passage par référence constante est plus efficace que le
passage par valeur pour les types « élémentaires » (je ne connais pas le
terme canonique) char, int, float, double ?
J'aurais tendance à dire que ça dépend de l'architecture (et du type
et du nombre de piles utilisées, voire de la fenêtre de registres et
de problèmes rigolo d'alignement des données en mémoire...).
Typiquement, sur du sparc, la réponse est non tant qu'on ne dépasse
pas huit arguments de même type. Si on dépasse ces huit arguments,
il vaut mieux utiliser une référence constante parce qu'on sort de
la fenêtre. Sur du x86, ça va dépendre de l'ABI (en 32 bits, il y a
une foultitude d'ABI concurrentes alors qu'en 64 bits, un esprit sage
a réussi à limiter ce nombre à ... 1 !). Sous VMS, DEC C et C++
optimisent un peu dans le dos de l'utilisateur. C'est vrai sur VAX parce
que l'assembleur est vraiment bien fichu (il connaît même directement
les listes chaînées), mais je n'ai pas regardé sur mon Alpha le code
généré.
Il n'y a donc pas de réponse simple à cette question, mais dans le
doute...
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Thu, 15 Dec 2011 10:02:27 +0100, Lucas Levrel écrivait :
Le 14 décembre 2011, Wykaaa a écrit :
Fabien LE LEZ a écrit :
Comparé au passage par valeur, le passage par référence constante n'est qu'une optimisation, que le compilo devrait se charger de faire lui-même.
Oui, le compilo devrait le faire lui-même, je n'ai pas dit autre chose. Ca devrait être le défaut. Pourquoi ? Parce que à chaque passage par valeur d'une instance de classe qui comporte un constructeur de copie, celui-ci est appelé alors que dans la majorité des cas ce n'est pas nécessaire. J'ai vu un programme ou, en transformant tous les passages par valeurs en références constante, on a gagné presque 30% en temps d'exécution !
Est-ce que le passage par référence constante est plus efficace que le passage par valeur pour les types « élémentaires » (je ne connais pas le terme canonique) char, int, float, double ?
J'aurais tendance à dire que ça dépend de l'architecture (et du type et du nombre de piles utilisées, voire de la fenêtre de registres et de problèmes rigolo d'alignement des données en mémoire...). Typiquement, sur du sparc, la réponse est non tant qu'on ne dépasse pas huit arguments de même type. Si on dépasse ces huit arguments, il vaut mieux utiliser une référence constante parce qu'on sort de la fenêtre. Sur du x86, ça va dépendre de l'ABI (en 32 bits, il y a une foultitude d'ABI concurrentes alors qu'en 64 bits, un esprit sage a réussi à limiter ce nombre à ... 1 !). Sous VMS, DEC C et C++ optimisent un peu dans le dos de l'utilisateur. C'est vrai sur VAX parce que l'assembleur est vraiment bien fichu (il connaît même directement les listes chaînées), mais je n'ai pas regardé sur mon Alpha le code généré.
Il n'y a donc pas de réponse simple à cette question, mais dans le doute...
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
void f(int x, int& y) { y = 5; std::cout << x << 'n'; }
et
void f(int const& x, int& y) { y = 5; std::cout << x << 'n'; }
vont afficher quelque chose de different pour
int x = 42; f(x, x);
Et j'ai deja vu le probleme sur du "vrai" code.
Pourquoi, cette optimisation n'est pas toujours pertinente. Voir par exemple http://cpp-next.com/archive/2009/08/want-speed-pass-by-value
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index. html Site de usenet-fr: http://www.usenet-fr.news.eu.org
void f(int x, int& y) {
y = 5;
std::cout << x << 'n';
}
et
void f(int const& x, int& y) {
y = 5;
std::cout << x << 'n';
}
vont afficher quelque chose de different pour
int x = 42;
f(x, x);
Et j'ai deja vu le probleme sur du "vrai" code.
Pourquoi, cette optimisation n'est pas toujours pertinente. Voir par
exemple http://cpp-next.com/archive/2009/08/want-speed-pass-by-value
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index. html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
void f(int x, int& y) { y = 5; std::cout << x << 'n'; }
et
void f(int const& x, int& y) { y = 5; std::cout << x << 'n'; }
vont afficher quelque chose de different pour
int x = 42; f(x, x);
Et j'ai deja vu le probleme sur du "vrai" code.
Pourquoi, cette optimisation n'est pas toujours pertinente. Voir par exemple http://cpp-next.com/archive/2009/08/want-speed-pass-by-value
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index. html Site de usenet-fr: http://www.usenet-fr.news.eu.org
C'est un moyen simple pour avoir un alias. Il y en a d'autres plus realistes. Tu peux arguer en faveur d'une approche plus fonctionnelle et dependant moins d'un etat, je ne te contredirai pas. Mais passer de la a dire que le compilateur doit changer la semantique de ton programme, je ne suis pas d'accord. On n'est pas dans un cas ou la semantique n'est pas clairement specifiee, elle l'est. Le compilateur ne doit l'ignorer sous pretexte d'optimisation.
Et quelle est la difference fondamentale? Si tu transformes un passage par valeur en un passage par reference, tu supposes que tu n'as pas d'alias. Que ce soit pour des types simples ou des classes.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index. html Site de usenet-fr: http://www.usenet-fr.news.eu.org
C'est un moyen simple pour avoir un alias. Il y en a d'autres plus
realistes. Tu peux arguer en faveur d'une approche plus fonctionnelle
et dependant moins d'un etat, je ne te contredirai pas. Mais passer de
la a dire que le compilateur doit changer la semantique de ton
programme, je ne suis pas d'accord. On n'est pas dans un cas ou la
semantique n'est pas clairement specifiee, elle l'est. Le compilateur
ne doit l'ignorer sous pretexte d'optimisation.
Et quelle est la difference fondamentale? Si tu transformes un passage
par valeur en un passage par reference, tu supposes que tu n'as pas
d'alias. Que ce soit pour des types simples ou des classes.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index. html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
C'est un moyen simple pour avoir un alias. Il y en a d'autres plus realistes. Tu peux arguer en faveur d'une approche plus fonctionnelle et dependant moins d'un etat, je ne te contredirai pas. Mais passer de la a dire que le compilateur doit changer la semantique de ton programme, je ne suis pas d'accord. On n'est pas dans un cas ou la semantique n'est pas clairement specifiee, elle l'est. Le compilateur ne doit l'ignorer sous pretexte d'optimisation.
Et quelle est la difference fondamentale? Si tu transformes un passage par valeur en un passage par reference, tu supposes que tu n'as pas d'alias. Que ce soit pour des types simples ou des classes.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index. html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Fabien LE LEZ
On Thu, 15 Dec 2011 09:35:12 +0000 (UTC), JKB :
mais dans le doute...
... on fait au plus simple, puis on optimise là où le profiler te dit d'optimiser.
On Thu, 15 Dec 2011 09:35:12 +0000 (UTC), JKB
<jkb@koenigsberg.invalid>:
mais dans le
doute...
... on fait au plus simple, puis on optimise là où le profiler te dit
d'optimiser.
... on fait au plus simple, puis on optimise là où le profiler te dit d'optimiser.
Fabien LE LEZ
On Wed, 14 Dec 2011 15:41:48 +0000 (UTC), (Marc Espie):
J'ai pas encore eu le temps de lire en detail la norme 2011, mais au moins en C++98, des que tu veux interagir avec le systeme, t'es bien oblige de te farcir des char *.
[...] par exemple, il n'y a meme pas de constructeur de fichier qui prend un std::string en parametre... ca fait un peu pitie.
Du coup, les chausse-trappes a la .c_str [...]
Au moins au début du cours, on peut considérer .c_str() comme une incantation magique. Par ailleurs, il s'agit de "char const*", ce qui est tout de même plus facile à gérer, puisque std::string s'occupe de l'allocation dynamique, de la vérification des bornes, etc.
On Wed, 14 Dec 2011 15:41:48 +0000 (UTC), espie@lain.home (Marc
Espie):
J'ai pas encore eu le temps de lire en detail la norme 2011, mais au moins
en C++98, des que tu veux interagir avec le systeme, t'es bien oblige de
te farcir des char *.
[...]
par exemple, il n'y a meme pas de constructeur de fichier qui prend un
std::string en parametre... ca fait un peu pitie.
Du coup, les chausse-trappes a la .c_str [...]
Au moins au début du cours, on peut considérer .c_str() comme une
incantation magique.
Par ailleurs, il s'agit de "char const*", ce qui est tout de même plus
facile à gérer, puisque std::string s'occupe de l'allocation
dynamique, de la vérification des bornes, etc.
On Wed, 14 Dec 2011 15:41:48 +0000 (UTC), (Marc Espie):
J'ai pas encore eu le temps de lire en detail la norme 2011, mais au moins en C++98, des que tu veux interagir avec le systeme, t'es bien oblige de te farcir des char *.
[...] par exemple, il n'y a meme pas de constructeur de fichier qui prend un std::string en parametre... ca fait un peu pitie.
Du coup, les chausse-trappes a la .c_str [...]
Au moins au début du cours, on peut considérer .c_str() comme une incantation magique. Par ailleurs, il s'agit de "char const*", ce qui est tout de même plus facile à gérer, puisque std::string s'occupe de l'allocation dynamique, de la vérification des bornes, etc.
