In article <49857132$0$9397$,
Etienne Rousee wrote:
>Gégé a écrit :
>> Du coup dans la déclaration de mes fonctions
> >il faut que j'utilise std::string ;
>"string" seulement, si dans le cpp, tu mets le
>"using namespace std;" avant le "#include ...".
Mauvais conseil, tres mauvais conseil.
Un fichier d'entetes qui depend de facon aussi directe de la
maniere dont il est inclus, c'est une excellente recette pour
trouver les emmerdes.
In article <49857132$0$9397$ba4ac...@news.orange.fr>,
Etienne Rousee <etie...@rousee.org> wrote:
>Gégé a écrit :
>> Du coup dans la déclaration de mes fonctions
> >il faut que j'utilise std::string ;
>"string" seulement, si dans le cpp, tu mets le
>"using namespace std;" avant le "#include ...".
Mauvais conseil, tres mauvais conseil.
Un fichier d'entetes qui depend de facon aussi directe de la
maniere dont il est inclus, c'est une excellente recette pour
trouver les emmerdes.
In article <49857132$0$9397$,
Etienne Rousee wrote:
>Gégé a écrit :
>> Du coup dans la déclaration de mes fonctions
> >il faut que j'utilise std::string ;
>"string" seulement, si dans le cpp, tu mets le
>"using namespace std;" avant le "#include ...".
Mauvais conseil, tres mauvais conseil.
Un fichier d'entetes qui depend de facon aussi directe de la
maniere dont il est inclus, c'est une excellente recette pour
trouver les emmerdes.
On Sun, 1 Feb 2009 10:41:30 +0000 (UTC), (Marc
Espie):
>Un fichier d'entetes qui depend de facon aussi directe de la
>maniere dont il est inclus, c'est une excellente recette pour
>trouver les emmerdes.
Yep. Un en-tête doit être autosuffisant, tout en ayant aussi
peu d'effets secondaires que possible.
Donc :
- dans un .h, écrire systématiquement std::string, etc., et ne
pas utiliser "using namespace" ni "using std::string".
- dans un .cpp, tu peux, si tu y tiens vraiment, écrire
"using namespace std" après le dernier #include.
Je me contente quant à moi d'introduire uniquement les noms que
j'utilise beaucoup dans ce .cpp. Par exemple :
using std::string;
using std::vector;
Ces règles obligent à écrire "std::" un peu plus souvent que
tu le voudrais, mais évite bien des emmerdes.
On Sun, 1 Feb 2009 10:41:30 +0000 (UTC), es...@lain.home (Marc
Espie):
>Un fichier d'entetes qui depend de facon aussi directe de la
>maniere dont il est inclus, c'est une excellente recette pour
>trouver les emmerdes.
Yep. Un en-tête doit être autosuffisant, tout en ayant aussi
peu d'effets secondaires que possible.
Donc :
- dans un .h, écrire systématiquement std::string, etc., et ne
pas utiliser "using namespace" ni "using std::string".
- dans un .cpp, tu peux, si tu y tiens vraiment, écrire
"using namespace std" après le dernier #include.
Je me contente quant à moi d'introduire uniquement les noms que
j'utilise beaucoup dans ce .cpp. Par exemple :
using std::string;
using std::vector;
Ces règles obligent à écrire "std::" un peu plus souvent que
tu le voudrais, mais évite bien des emmerdes.
On Sun, 1 Feb 2009 10:41:30 +0000 (UTC), (Marc
Espie):
>Un fichier d'entetes qui depend de facon aussi directe de la
>maniere dont il est inclus, c'est une excellente recette pour
>trouver les emmerdes.
Yep. Un en-tête doit être autosuffisant, tout en ayant aussi
peu d'effets secondaires que possible.
Donc :
- dans un .h, écrire systématiquement std::string, etc., et ne
pas utiliser "using namespace" ni "using std::string".
- dans un .cpp, tu peux, si tu y tiens vraiment, écrire
"using namespace std" après le dernier #include.
Je me contente quant à moi d'introduire uniquement les noms que
j'utilise beaucoup dans ce .cpp. Par exemple :
using std::string;
using std::vector;
Ces règles obligent à écrire "std::" un peu plus souvent que
tu le voudrais, mais évite bien des emmerdes.
Fabien LE LEZ a écrit :- dans un .h, écrire systématiquement std::string, etc., et ne pas
utiliser "using namespace" ni "using std::string".
Et en utilisant la technique des namespaces anonymes ça te dérange aussi ?
namespace projet
{
namespace {
using std::string ;
class machin
{
protected:
string nom ;
//...
} ;
}
}
Ça permet d'éviter la pollution du namespace global tout en permettant
d'éviter de rendre le code trop lourd à la lecture.
Fabien LE LEZ a écrit :
- dans un .h, écrire systématiquement std::string, etc., et ne pas
utiliser "using namespace" ni "using std::string".
Et en utilisant la technique des namespaces anonymes ça te dérange aussi ?
namespace projet
{
namespace {
using std::string ;
class machin
{
protected:
string nom ;
//...
} ;
}
}
Ça permet d'éviter la pollution du namespace global tout en permettant
d'éviter de rendre le code trop lourd à la lecture.
Fabien LE LEZ a écrit :- dans un .h, écrire systématiquement std::string, etc., et ne pas
utiliser "using namespace" ni "using std::string".
Et en utilisant la technique des namespaces anonymes ça te dérange aussi ?
namespace projet
{
namespace {
using std::string ;
class machin
{
protected:
string nom ;
//...
} ;
}
}
Ça permet d'éviter la pollution du namespace global tout en permettant
d'éviter de rendre le code trop lourd à la lecture.
Jean-Marc Bourguet a écrit :Qu'est-ce que ça t'apporte par rapport à
project::string n'existe pas (normalement) avec le namespace anonyme,
alors qu'il existe dans ta version.
Jean-Marc Bourguet a écrit :
Qu'est-ce que ça t'apporte par rapport à
project::string n'existe pas (normalement) avec le namespace anonyme,
alors qu'il existe dans ta version.
Jean-Marc Bourguet a écrit :Qu'est-ce que ça t'apporte par rapport à
project::string n'existe pas (normalement) avec le namespace anonyme,
alors qu'il existe dans ta version.
Mickaël Wolff writes:
> Fabien LE LEZ a écrit :
>> - dans un .h, écrire systématiquement std::string, etc., et ne pas
>> utiliser "using namespace" ni "using std::string".
> Et en utilisant la technique des namespaces anonymes ça te
> dérange aussi ?
> namespace projet
> {
> namespace {
> using std::string ;
> class machin
> {
> protected:
> string nom ;
> //...
> } ;
> }
> }
> Ça permet d'éviter la pollution du namespace global tout
> en permettant d'éviter de rendre le code trop lourd à la
> lecture.
Qu'est-ce que ça t'apporte par rapport à
namespace projet
{
using std::string ;
class machin
{
protected:
string nom ;
//...
} ;
}
Mickaël Wolff <mickael.wo...@laposte.net> writes:
> Fabien LE LEZ a écrit :
>> - dans un .h, écrire systématiquement std::string, etc., et ne pas
>> utiliser "using namespace" ni "using std::string".
> Et en utilisant la technique des namespaces anonymes ça te
> dérange aussi ?
> namespace projet
> {
> namespace {
> using std::string ;
> class machin
> {
> protected:
> string nom ;
> //...
> } ;
> }
> }
> Ça permet d'éviter la pollution du namespace global tout
> en permettant d'éviter de rendre le code trop lourd à la
> lecture.
Qu'est-ce que ça t'apporte par rapport à
namespace projet
{
using std::string ;
class machin
{
protected:
string nom ;
//...
} ;
}
Mickaël Wolff writes:
> Fabien LE LEZ a écrit :
>> - dans un .h, écrire systématiquement std::string, etc., et ne pas
>> utiliser "using namespace" ni "using std::string".
> Et en utilisant la technique des namespaces anonymes ça te
> dérange aussi ?
> namespace projet
> {
> namespace {
> using std::string ;
> class machin
> {
> protected:
> string nom ;
> //...
> } ;
> }
> }
> Ça permet d'éviter la pollution du namespace global tout
> en permettant d'éviter de rendre le code trop lourd à la
> lecture.
Qu'est-ce que ça t'apporte par rapport à
namespace projet
{
using std::string ;
class machin
{
protected:
string nom ;
//...
} ;
}
Sinon, c'est une « using declaration » ; c'est comme si
std::string était en fait déclaré dans projet::<anonyme>.
Sinon, c'est une « using declaration » ; c'est comme si
std::string était en fait déclaré dans projet::<anonyme>.
Sinon, c'est une « using declaration » ; c'est comme si
std::string était en fait déclaré dans projet::<anonyme>.
Gégé a écrit :Du coup dans la déclaration de mes fonctions
>il faut que j'utilise std::string ;
"string" seulement, si dans le cpp, tu mets le
"using namespace std;" avant le "#include ...".et dans le cpp je mets un using namespace?
Oui, si tu veut éviter le "std::" et que tu ne
prévois pas de problèmes de conflits de noms.
Gégé a écrit :
Du coup dans la déclaration de mes fonctions
>il faut que j'utilise std::string ;
"string" seulement, si dans le cpp, tu mets le
"using namespace std;" avant le "#include ...".
et dans le cpp je mets un using namespace?
Oui, si tu veut éviter le "std::" et que tu ne
prévois pas de problèmes de conflits de noms.
Gégé a écrit :Du coup dans la déclaration de mes fonctions
>il faut que j'utilise std::string ;
"string" seulement, si dans le cpp, tu mets le
"using namespace std;" avant le "#include ...".et dans le cpp je mets un using namespace?
Oui, si tu veut éviter le "std::" et que tu ne
prévois pas de problèmes de conflits de noms.
Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
In article ,
Marc Boyer wrote:Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Une bonne partie de l'informatique, c'est cense etre faire des choses
qui marchent de facon previsible.
99% de ce qu'on fait est debile, c'est le 1% restant qui presente
de l'interet.
Il faut s'arranger pour que les 99% soient les plus simples possibles,
de facon mecanique, ce qui veut dire prendre des automatismes corrects.
(comme presenter son code toujours de la meme facon, verifier les appels
systemes qui peuvent echouer, ne pas laisser passer de warnings a la
compilation).
Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Je ne vois pas l'interet de s'encombrer la tete avec plusieurs facons
de faire du code. On s'en prend une qui est correcte et on s'y tient.
In article <slrngodgcn.396.Marc.Boyer@gavarnie.cert.fr>,
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:
Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Une bonne partie de l'informatique, c'est cense etre faire des choses
qui marchent de facon previsible.
99% de ce qu'on fait est debile, c'est le 1% restant qui presente
de l'interet.
Il faut s'arranger pour que les 99% soient les plus simples possibles,
de facon mecanique, ce qui veut dire prendre des automatismes corrects.
(comme presenter son code toujours de la meme facon, verifier les appels
systemes qui peuvent echouer, ne pas laisser passer de warnings a la
compilation).
Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Je ne vois pas l'interet de s'encombrer la tete avec plusieurs facons
de faire du code. On s'en prend une qui est correcte et on s'y tient.
In article ,
Marc Boyer wrote:Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Une bonne partie de l'informatique, c'est cense etre faire des choses
qui marchent de facon previsible.
99% de ce qu'on fait est debile, c'est le 1% restant qui presente
de l'interet.
Il faut s'arranger pour que les 99% soient les plus simples possibles,
de facon mecanique, ce qui veut dire prendre des automatismes corrects.
(comme presenter son code toujours de la meme facon, verifier les appels
systemes qui peuvent echouer, ne pas laisser passer de warnings a la
compilation).
Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Je ne vois pas l'interet de s'encombrer la tete avec plusieurs facons
de faire du code. On s'en prend une qui est correcte et on s'y tient.
Marc Espie wrote:
> In article ,
> Marc Boyer wrote:
>> Ce qui suppose de savoir comment va se dérouler
>> la suite de la vie de ce code, ce qui est raisonnable
>> si on sait qu'on va jeter le code à la fin du TP,
>> un peu moins si on envisage que ce code soit utilisé
>> pour de vrai, maintenu, ré-utilisé, adapté...
> Euh, mauvaise logique, changer de logique.
> Une bonne partie de l'informatique, c'est cense etre faire des choses
> qui marchent de facon previsible.
> 99% de ce qu'on fait est debile, c'est le 1% restant qui presente
> de l'interet.
> Il faut s'arranger pour que les 99% soient les plus simples possibles,
> de facon mecanique, ce qui veut dire prendre des automatismes corrects.
> (comme presenter son code toujours de la meme facon, verifier les appels
> systemes qui peuvent echouer, ne pas laisser passer de warnings a la
> compilation).
> Si tu autorises les gens a prendre des habitudes differentes "parce que
> c'est juste un TP", tu les formes a faire du code qui marchera mal.
Un TP est un temps limité. Je comprends qu'il soit souhaitable de se
concentrer sur les objectifs du TP plutôt que de passer du temps sur
l'aspect qualité (qui est une mesure assez vague). En plus, le message est
plus clair si il n'est pas parasité par des considérations secondes par
rapport à ce qui doit être démontré.
Marc Espie wrote:
> In article <slrngodgcn.396.Marc.Boyer@gavarnie.cert.fr>,
> Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:
>> Ce qui suppose de savoir comment va se dérouler
>> la suite de la vie de ce code, ce qui est raisonnable
>> si on sait qu'on va jeter le code à la fin du TP,
>> un peu moins si on envisage que ce code soit utilisé
>> pour de vrai, maintenu, ré-utilisé, adapté...
> Euh, mauvaise logique, changer de logique.
> Une bonne partie de l'informatique, c'est cense etre faire des choses
> qui marchent de facon previsible.
> 99% de ce qu'on fait est debile, c'est le 1% restant qui presente
> de l'interet.
> Il faut s'arranger pour que les 99% soient les plus simples possibles,
> de facon mecanique, ce qui veut dire prendre des automatismes corrects.
> (comme presenter son code toujours de la meme facon, verifier les appels
> systemes qui peuvent echouer, ne pas laisser passer de warnings a la
> compilation).
> Si tu autorises les gens a prendre des habitudes differentes "parce que
> c'est juste un TP", tu les formes a faire du code qui marchera mal.
Un TP est un temps limité. Je comprends qu'il soit souhaitable de se
concentrer sur les objectifs du TP plutôt que de passer du temps sur
l'aspect qualité (qui est une mesure assez vague). En plus, le message est
plus clair si il n'est pas parasité par des considérations secondes par
rapport à ce qui doit être démontré.
Marc Espie wrote:
> In article ,
> Marc Boyer wrote:
>> Ce qui suppose de savoir comment va se dérouler
>> la suite de la vie de ce code, ce qui est raisonnable
>> si on sait qu'on va jeter le code à la fin du TP,
>> un peu moins si on envisage que ce code soit utilisé
>> pour de vrai, maintenu, ré-utilisé, adapté...
> Euh, mauvaise logique, changer de logique.
> Une bonne partie de l'informatique, c'est cense etre faire des choses
> qui marchent de facon previsible.
> 99% de ce qu'on fait est debile, c'est le 1% restant qui presente
> de l'interet.
> Il faut s'arranger pour que les 99% soient les plus simples possibles,
> de facon mecanique, ce qui veut dire prendre des automatismes corrects.
> (comme presenter son code toujours de la meme facon, verifier les appels
> systemes qui peuvent echouer, ne pas laisser passer de warnings a la
> compilation).
> Si tu autorises les gens a prendre des habitudes differentes "parce que
> c'est juste un TP", tu les formes a faire du code qui marchera mal.
Un TP est un temps limité. Je comprends qu'il soit souhaitable de se
concentrer sur les objectifs du TP plutôt que de passer du temps sur
l'aspect qualité (qui est une mesure assez vague). En plus, le message est
plus clair si il n'est pas parasité par des considérations secondes par
rapport à ce qui doit être démontré.