Discussion :

[JolyLoic]

- le "const int", qui définit l'invariance réelle d'un objet (il peut par exemple être implémenté en ROM)
- et le qualificateur d'accès au travers du pointeur "const int*", qui dit seulement la manière dont on voit la zone pointée (les droits d'accès sont alors modifiables par const_cast).

Il y a un peu cette notion en C++, qui distingue ce qui est constant à la compilation, de ce qui est simplement constant. Un des problèmes étant qu'il est très restrictif ce ce qui est constant à la compilation, et passe à côté de pas mal d'opportunités. Ca devrait s'améliorer un peu dans le prochain standard :
http://www.open-std.org/jtc1/sc22/wg...2007/n2235.pdf

(Edit : J'ai créé un nouveau thread, afin de ne pas encombrer la discussion initiale)

[corrector]

Il y a un peu cette notion en C++, qui distingue ce qui est constant à la compilation, de ce qui est simplement constant. Un des problèmes étant qu'il est très restrictif ce ce qui est constant à la compilation, et passe à côté de pas mal d'opportunités. Ca devrait s'améliorer un peu dans le prochain standard :
http://www.open-std.org/jtc1/sc22/wg...2007/n2235.pdf

Qui introduit le mot-clef constexpr, qui étendra le domaine des expressions constantes (constant expressions). Il ne faut pas confondre avec const, qui indique l'absence de changement de la valeur d'une variable pendant sa durée de vie (mettons, comme une variable en ML!), pas sa connaissance dès la compilation.

Une expression constante entière est requise (entre autres) :

• comme valeur d'un enumérateur :
  

  Code :

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

  enum T { e = integral-const-expr };

• comme valeur d'un case
  

  Code :

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

  case integral-const-expr:

• comme taille d'un tableau primitif :
  

  Code :

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

  int t[integral-const-expr];

• comme argument template non-type entier :
  

  Code :

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

  1
  2
  template <int> class CI {};
  CI<integral-const-expr> xi;

Attention, les paramètre template non-type non-entiers ne sont pas décrits en terme d'expression constantes, mais de façon bien plus restrictive par une liste de formes autorisées :

A template-argument for a non-type, non-template template-parameter shall be one of:

• an integral constant-expression of integral or enumeration type; or
• the name of a non-type template-parameter; or
• the address of an object or function with external linkage, including function templates and function template-id s but excluding non-static class members, expressed as & id-expression where the & is optional if the name refers to a function or array, or if the corresponding template-parameter is a reference; or
• a constant expression that evaluates to a null pointer value (4.10); or
• a constant expression that evaluates to a null member pointer value (4.11); or
• a pointer to member expressed as described in 5.3.1.

Déjà, je vois qu'il y a un oubli dans la liste : le cas d'un lvalue nommée utilisée comme argument d'un template paramétré par une référence a été zappé! C'est assez gros quand même.

Par exemple, ceci n'est pas explicitement autorisé par 14.3.2/1 (sic!) :

Code :

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

1
2
3
templace <float& ref> class CR;
float f;
CR<f> xf;

Les expressions constantes sont utiles dans la valeur initialisation d'une variable globale, ou statique définie non localement :

Code :

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

1
2
3
4
5
6
int gi = 2;
static float sf = 3.;
struct T_pod {
	int a;
	float b;
} t = { 4, 5. };

Les variable gi, sf et t sont (devraient être) initialisées statiquement, c'est à dire avant l'initialisation dynamique, et donc avant l'exécution d'une instruction du programme; autrement dit, il est garanti qu'on ne peut pas observer une de ces variables avant son initialisation à 2, 3., et { 4, 5. } respectivement.

Mais en fait, ce n'est pas exactement ce que je lis :

A reference with static storage duration and an object of POD type with static storage duration can be initialized with a constant expression (5.19); this is called constant initialization.

POD type, cela devrait inclure T_pod ci-dessus. Cependant :

Other expressions are considered constant-expression s only for the purpose of non-local static object initialization (3.6.2). Such constant expressions shall evaluate to one of the following:

• a null pointer value (4.10),
• a null member pointer value (4.11),
• an arithmetic constant expression,
• an address constant expression,
• a reference constant expression,
• an address constant expression for a complete object type, plus or minus an integral constant expression, or
• a pointer to member constant expression

Toutes les formes ont un type primitif (sauf reference constant expression, mais c'est un oubli!), donc aucune forme ne peut initialiser une POD-struct.

Où voyez-vous que l'initialisation par acolades est autorisée? Si une POD-struct ne doit pas être initialisée statiquement, pourquoi parler de POD type et pas de type primitif ou de scalaire ou que sais-je.

Au fait, c'est quoi ce gag :

Arithmetic types (3.9.1), enumeration types, pointer types, and pointer to member types (3.9.2), and cv-qualified versions of these types (3.9.3) are collectively called POD classes

MDR!

Au fait, y a t-il une définition explicite de fundamental type?

(J'arrête avec la nomenclature des type, je suis de plus en plus perdu.)

Aussi, il y a un problème dans le définition des expressions constantes :

Other expressions are considered constant-expression s only for the purpose of non-local static object initialization (3.6.2). Such constant expressions shall evaluate to one of the following:

• ...
• an arithmetic constant expression,
• an address constant expression,
• a reference constant expression,

Ce qui n'a rigoureusement aucun sens, on n'a pas défini encore une expression constante, on ne peut utiliser le résultat de l'évaluation d'une expression (qui a lieu à l'exécution) pour définir un type d'expression. D'ailleurs l'évaluation d'une expression ne donne pas une expression, on ne voit pas comment elle pourrait donner une arithmetic constant expression, ou une address constant expression etc.!

Puisque le C++ n'est pas (pas tout à fait!) un langage à re-écriture, remplaçons evaluate par be :

Other expressions are considered constant-expression s only for the purpose of non-local static object initialization (3.6.2). Such constant expressions shall be to one of the following:
- a null pointer value (4.10),
...

Là encore, ça n'a pas de sens, une expression n'est pas une valeur, voyons la définition de null pointer value :

A null pointer constant can be converted to a pointer type; the result is the null pointer value of that type and is distinguishable from every other value of pointer to object or pointer to function type.

Une null pointer value est donc bien définie non pas comme une expression mais comme une valeur (résultat de l'évaluation d'une expression), donc ce terme ne peut pas être utilisé pour dans le définition de constant expression en 5.19/2.