Discussion :

[Alp]

un #define du genre "#define MAX_SIZE 50" est à portée globale. Pour peux que tu inclues le fichier ou quoi, MAX_SIZE sera défini. Et tu peux très facilement définir un MAX_SIZE ailleurs qui va peut se retrouver au final écrasé ou vice-versa.

Alors qu'avec static const, si tu rédéfinis ta variable dans un autre fichier, et si tu inclues le premier, tu auras une erreur de compilo. Tu contrôles ainsi à la fois la valeur (tu es sûr qu'elle ne bougera pas malgré des étourderies) mais aussi le typage ...

[Mat007]

Salut,

Je crois bien que l'utilisation de static dans ce cas de figure est déprécié en C++...
Ainsi il est conseillé de faire simplement :

Code :

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

const int i = 0;

Cela dit comme il ne faut jamais poluer le namespace par défaut il faut toujours, si c'est dans un .cpp utiliser un namespace anonyme :

Code :

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

1
2
3
4
namespace
{
  const int i = 0;
}

Et dans un .h utiliser un vrai namespace :

Code :

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

1
2
3
4
namespace my_namespace
{
  const int i = 0;
}

Ca permet d'éviter les collisions de nom.

Ca vaut aussi pour les fonctions locales à une unité de compilation...

MAT.

[Alp]

En effet, static est déprécié dans ce cas.

Un const suffit.

[zais_ethael]

Dites, chtite question, ça sert à quoi un namespace anonyme? C'est la première fois que je vois ça...

[Laurent Gomila]

Ca sert à limiter la portée de ce qui y est déclaré à l'unité de compilation dans laquelle cela se trouve. En C pour faire ça on utilise static.

[zais_ethael]

Si j'ai bien compris, ça permet de déclarer deux fonctions portant le même nom avec les mêmes arguments dans deux .cpp différents sans que ça pose problème au link?

[Jean-Marc.Bourguet]

Si j'ai bien compris, ça permet de déclarer deux fonctions portant le même nom avec les mêmes arguments dans deux .cpp différents sans que ça pose problème au link?

oui.

[JolyLoic]

Formellement, écrire :

Code :

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

1
2
3
namespace {
  // Code
}

Est équivalent à écrire :

Code :

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

1
2
3
4
namespace ipgvjnisepgqgvnerhfgev { // Identifiant unique généré par le compilo
  // Code
}
using namespace ipgvjnisepgqgvnerhfgev;

[yan]

question sur le typedef, c'est du C ou du C++??
d'aprés ce post http://www.developpez.net/forums/sho...d.php?t=402693
c'est du C.
DU coup comment faire cela en C++ :

Code C++ :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
template <class T> 
class A
{
.
.
.
}
 
 
typedef A<char> A_CHAR
typedef A<int> A_INT

[koala01]

Ca fait partie de ce fameux "sous ensemble"...

En fait, en C, le fait de déclarer une structure ne déclare pas un type correspondant pour la cause...ce qui n'est pas le cas en C++.

Mais il est parfaitement légal de déclarer typedef afin de permettre, par exemple, une écriture plus simple et plus "parlante"

Code :

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

1
2
3
4
5
 
typedef struct mastruct
{
    /*..*/
} montype;

est typiquement C, alors que

Code :

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

1
2
 
typedef std::vector<std::string> StringArray;

sera typiquement C++

[yan]

Ca fait partie de ce fameux "sous ensemble"...

En fait, en C, le fait de déclarer une structure ne déclare pas un type correspondant pour la cause...ce qui n'est pas le cas en C++.

Mais il est parfaitement légal de déclarer typedef afin de permettre, par exemple, une écriture plus simple et plus "parlante"

Code :

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

1
2
3
4
5
 
typedef struct mastruct
{
    /*..*/
} montype;

est typiquement C, alors que

Code :

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

1
2
 
typedef std::vector<std::string> StringArray;

sera typiquement C++

ça me rassure. merci
Comme quoi ce n'est pas si évidente de séparer ce qui est du C de ce qui est du C++

[yan]

Bonjour,
ce code en C++

Code C++ :

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

1
2
3
4
5
6
7
 
if (test1() ||test2())
{
.
.
.
}

va exécuter en premier test1() et :
- si vrai : ne va pas appeler test2
- si faux : va appeler test2

Je voulais juste savoir si c'est bien la même chose en C.

De même

Code c++ :

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

x = ++n * --n;

as un comportement indefinie en C++. Es bien pareil en C?
Merci

[koala01]

Le problème du || est la table de vérité qu'il implique en algèbre de bool:

Code :

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

1
2
3
4
5
6
 
a    b    a||b    a&&b
0    0      0       0
1    0      1       0
0    1      1       0
1    1      1       1

Je ne suis pas sur qu'il y ai quoi que ce soit qui permette d'assurer que la première expression est testée avant la deuxième (aux connaisseurs de la norme: qu'en dit elle )

Ce qui est sur, c'est que, si la première expression testée donne un vrai, il n'y a aucune raison d'aller voir plus loin pour un OU (étant donné que la deuxième expression n'a aucune espèce d'importance: le résultat est VRAI d'office ), et que, si la première expression testée donne un faux, on sera tout aussi sur du résultat avec un ET (étant donné que le résultat de la deuxième expression n'a aucune importance: le résultat est FAUX d'office )

Par contre, les choses changent si la première expression testée est fausse dans le cadre un OU, ou vraie dans le cadre d'un ET...

Pour être en mesure de fournir un résultat, il nous faut... tester la deuxième expression, dont dépendra le résultat final

[Matthieu Brucher]

Normalement, pour le ou et le et logique, la première expression est testée. Si elle vaut vraie pour le ou, le test s'arrête, de même si elle vaut faux pour le et logique.
En revanche, je ne suis pas sûr que la norme indique laquelle des deux fonctions est exécutée en premier ou si le secodne est exécutée si le test doit s'arrêter.
Enfin, pour

Code :

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

x = ++n * --n;

, rien n'indique quelle expression est calculée en premier. D'ailleurs ICC donne un warning pour ce genre de chose, et ça devient lourd parfois

[Jean-Marc.Bourguet]

Normalement, pour le ou et le et logique, la première expression est testée. Si elle vaut vraie pour le ou, le test s'arrête, de même si elle vaut faux pour le et logique.
En revanche, je ne suis pas sûr que la norme indique laquelle des deux fonctions est exécutée en premier ou si le secodne est exécutée si le test doit s'arrêter.

Oui, c'est garanti.

Enfin, pour

Code :

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

x = ++n * --n;

, rien n'indique quelle expression est calculée en premier. D'ailleurs ICC donne un warning pour ce genre de chose, et ça devient lourd parfois

Non seulement l'ordre d'evaluation n'est pas specifie (ce qui restreintrait les reponses possibles mais forcerait l'implementation a un choix limite de comportement) mais le comportement est indefini en C comme en C++ (donc l'implementation peut reellement faire n'importe quoi).

[yan]

Citation:
Envoyé par Miles Voir le message
Normalement, pour le ou et le et logique, la première expression est testée. Si elle vaut vraie pour le ou, le test s'arrête, de même si elle vaut faux pour le et logique.
En revanche, je ne suis pas sûr que la norme indique laquelle des deux fonctions est exécutée en premier ou si le secodne est exécutée si le test doit s'arrêter.

Oui, c'est garanti.

Ouf, j'ai eu peur. J'utilise beaucoup cette propriété dans mes code..
D'ailleur, es ce plustôt du C ou du C++.

[koala01]

Ouf, j'ai eu peur. J'utilise beaucoup cette propriété dans mes code..

Comme sans doute tout le monde (qui n'a jamais du faire un test sur plusieurs conditions distinctes )

Le fait était surtout de savoir ce qu'en pense la norme, et là, il n'y a pas beaucoup de monde par ici qui puisse se targuer de la connaître "à fond" (ou ne serait-ce que de manière suffisante ))

D'ailleur, es ce plustôt du C ou du C++.

C'est de l'algèbre de Bool... Tout simplement ...

Et par conséquent, ce n'est pas relié à un langage particulier

[yan]

C'est de l'algèbre de Bool... Tout simplement ...

Et par conséquent, ce n'est pas relié à un langage particulier

Code :

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

1
2
 
if (A() || B()) {...}

Rien n'oblige à ce que A soit appeler avant B, sauf le compilateur ou le langage

[koala01]

Excuses moi, je partais sur une mauvaise interprétation de ta question...

J'étais parti sur une question plus du genre de "les ET logiques et les OU logiques, il sont plus C ou plus C++ "

Mais dans l'ensemble, ma réponse reste valable, car un test sur expressions multiples reste tout à fait soumis à l'algèbre de Bool dans le sens ou

Code :

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

1
2
3
4
5
6
 
if ( fonctiona()  || fonctionb()   &&  fonctionc())
         ^                  ^               ^
         |                  |               |
      vrai/faux   OU   vrai/faux   ET     vrai/faux
         A        OU      B        ET       C

se réduit réellement à l'algèbre de Bool, avec les règles de priorités qui en découlent et qui sont:

D'abord le ET logique (B && C), et on met le résultat en balance avec OU A
ce qui donne une table de vérité de l'ordre de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
            BC      
B  C  |   B&&C   A  |  BC+A
0  0  |     0    0  |    0
0  1  |     0    0  |    0
1  0  |     0    0  |    0
1  1  |     1    0  |    1
0  0  |     0    1  |    1
0  1  |     0    1  |    1
1  0  |     0    1  |    1
1  1  |     1    1  |    1

[screetch]

je pense qu'il manque toujours l'info importante!!

supposons que functiona, functionb et functionc aient des effets de bords, alors

Code :

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

1
2
 
if(functiona() || functionb() && functionc())

D'abord functionb() est appelé, si elle renvoie false alors functiona(9 est appelé. Quel que soit le resultat, functionc() n'est pas appelé et son effet de bord non executé!

ca s'appelle la "lazy evaluation", ca doit pas etre le terme technique mais en tous cas ca parle mieux comme ca : a partir du moment ou tu peux deduire le resultat tu ne lances pas l'evaluation de la suite.