Discussion :

[salseropom]

Bonjour, je développe un code avec Visual 2005 et j'ai un problème que je n'ai encore jamais rencontré.

Voici mon code qui pose souci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
	for(int i = ibegin ; i < iend ; i += step)
	{
		_def.push_back(lambda[i]);
		_sigma.push_back(sigma[i]);
		_t.push_back(temps[i]);
		_T.push_back(Tcarac);
		_V.push_back(vitesse_moy);
	}

_def, _sigma, _t, _T, _V, lambda, sigma, temps sont des std::vector<double>, Tcarac et vitesse_moy sont des doubles

Le problème est le suivant : au début, _def, _sigma, _t, _T et _V sont vides. J'arrive dans ma boucle for(). Au moment où je suis à la ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
_t.push_back(temps[i]);

_t se remplit de la valeur temps[i] (donc c'est normal) mais _T aussi !

si je mets la ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
_t.push_back(temps[i]);

en commentaire, _T ne se remplit pas de la valeur Tcarac (donc _T est toujours vide)

si je renomme _T en _TT (par exemple), le problème disparaît (_t se remplit de la valeur temps[i] et _TT de la valeur Tcarac : bref le comportement est normal).

Quelqu'un aurait-il une idée ?

Merci d'avance

[Jean-Marc.Bourguet]

Quelqu'un aurait-il une idée ?

Regarder la sortie du preprocesseur? _T et _V sont des noms reserves dans tous les contextes, _def, _sigma, _t dans certains, ca ne m'etonnerais pas qu'un entete les utilise pour un objectif rentrant en conflit avec toi.

[salseropom]

ok, j'ai renommé ma variable _t par _tps et le problème a disparu. Je devais bien avoir un conflit de variable.

Ceci dit, que je renomme _t en _tps ou _T en _TT, le problème a disparu. Je trouve que c'est bizarre...

[zul]

Les noms commençant par _ et __ sont réservé pour les compilateurs / STL. A ne pas utiliser sous peine de comportements étranges (et dépendant du compilateur).

[salseropom]

Les noms commençant par _ et __ sont réservé pour les compilateurs / STL. A ne pas utiliser sous peine de comportements étranges (et dépendant du compilateur).

Aïe, dans tous mes programmes, tous les attributs de mes classes commençent par un underscore... Ca me servira de leçon...

En gros, pour reconnaître une variable si elle est un attribut de ma classe ou non, le mieux est donc de la faire terminer par un underscore (et non de la faire commencer).

Comment faites-vous pour différencier un attribut d'une classe d'une "simple" variable ? Quelle convention utilisez-vous ?

Merci

[dragonjoker59]

La convention que j'utilise :
membre de classe : m_typeNomVariable
variable globale : g_typeNomVariable
variable locale : l_typeNomVariable
paramètre de fonction : p_typeNomVariable

exemples :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
std::string m_strNom;
int g_iProgramID;
double l_dPrecision;
const std::string & p_strNouveauNom

[Jean-Marc.Bourguet]

Les noms commençant par _ et __ sont réservé pour les compilateurs / STL. A ne pas utiliser sous peine de comportements étranges (et dépendant du compilateur).

Les noms contenant un double underscore (pas uniquement au debut) sont reserves dans tous les contextes.

Les regles sont un peu plus complexes pour les noms commencant par un seul underscore. La seule exception que je retiens c'est que comme nom de membre ca passe si le caractere qui suit est une minuscule, parce que c'est une convention commune -- meme si je ne l'applique pas.

Aïe, dans tous mes programmes, tous les attributs de mes classes commençent par un underscore... Ca me servira de leçon...

Voir ci-dessus.

En gros, pour reconnaître une variable si elle est un attribut de ma classe ou non, le mieux est donc de la faire terminer par un underscore (et non de la faire commencer).

C'est une autre convention.

Comment faites-vous pour différencier un attribut d'une classe d'une "simple" variable ? Quelle convention utilisez-vous ?

Quelques conventions que j'ai vues:
- _ en prefixe
- _ en suffixe
- my/our en prefixe (permet en plus de differentier statique ou pas)
- m_ en prefixe
- pas de marquage particulier, les noms locaux sont declares suffisemment pres, les autres noms sont marques.

[JolyLoic]

Personnellement, j'ai vu tout ce qu'à indiqué Jean-Marc (plus du g_ pour les globales), y compris mélangé à diverses autres variante (notation hongroise ou assimilée).

J'ai tendance à préférer les myXxxxx, qui présentent un avantage : Le nom de variable se prononce aisément à voix haute quand on discute du conde entre collègues.

[Jean-Marc.Bourguet]

J'ai tendance à préférer les myXxxxx, qui présentent un avantage : Le nom de variable se prononce aisément à voix haute quand on discute du conde entre collègues.

C'est ce que j'utilise dans mes projets perso.

[koala01]

Salut,

Il y a, à vrai dire, à peu près autant de conventions de nommage que de programmeurs / d'équipe de développement

Mon avis est qu'il y a effectivement des conventions plus intéressantes que d'autres, mais que ce qui importe surtout, c'est de la suivre (au moins au niveau du projet) une fois qu'elle a été définie.

Parce qu'il faut avouer que, si tu passe sans cesse d'une notation à l'autre au sein d'un seul et même projet, cela deviendra rapidement le bordel intégral.

Pour le reste, il faut avouer que l'argument sur la facilité de prononciation de Loic se tient, mais que, bien souvent, le seul fait de déclarer les noms locaux suffisamment près de leur lieu d'utilisation devrait déjà permettre d'éviter toute confusion

De plus, la convention de nommage des variables dépend également grandement de celle utilisée pour les noms de fonctions!

A titre d'exemple, je préfères personnellement avoir un accesseur nommé name() plutôt qu'un accesseur nommé getName(), même si je n'imposerai jamais cette vision des choses à quiconque (du moins, en dehors des cas où le choix est de ma responsabilité).

Le résultat immédiat de cette préférence est qu'il faudra bien trouver un moyen de faire la distinction entre l'accesseur et le membre qu'il est sensé renvoyé

Ma "fainéantise naturelle" me pousse à utiliser l'underscore en postfixe, mais, encore une fois, ce n'est qu'une préférence personnelle

Tout cela pour dire que les conventions de nommages méritent un débat global (qui prendra l'ensemble des aspects en compte) et général (auquel participeront l'ensemble des développeurs d'une équipe), mais qu'il sera particulièrement difficile de faire ressortir des règles générales aussi bien sur un forum que dans une réunion qui serait dédiée au sujet