Initialisation de membres static const

Version imprimable

14/01/2008, 00h05
NiamorH

Initialisation de membres static const
Bonjour,

ma question est : Pourquoi ne peut-on initialiser que les membres static const de type entier ?

A l'intérieur de ma classe :
Code:

1 2 static size_t const maxOscs_ = 3; static float const maxWide_ = 0.2f;
maxWide_ ne peut pas être initialisé... pour quelle raison technique ?

Merci.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#include <iostream>
 
 
class MaClasse {
	public :
	static size_t const maxOscs_ = 3;
	static float  const maxWide_ = 0.2f;
};
 
 
int main () {
 
	std::cout << "Valeurs : " << MaClasse::maxOscs_ << " et " << MaClasse::maxWide_ << std::endl;
 
	return 0;
}

Chez moi ça compile et ça affiche les bonnes valeurs.

14/01/2008, 01h17
NiamorH

Pas sous visual 2005 et Comeau online semble etre d'accord :

Citation:

Your Comeau C/C++ test results are as follows:

Comeau C/C++ 4.3.9 (Mar 27 2007 17:24:47) for ONLINE_EVALUATION_BETA1
Copyright 1988-2007 Comeau Computing. All rights reserved.
MODE:strict errors C++ noC++0x_extensions

"ComeauTest.c", line 7: error: a member of type "const float" cannot have an
in-class initializer
static float const maxWide_ = 0.2f;
^

1 error detected in the compilation of "ComeauTest.c".

In strict mode, with -tused, Compile failed
Hit the Back Button to review your code and compile options.
Compiled with C++0x extensions DISabled.

Qu'est ce que tu utilises ?
14/01/2008, 09h50
koala01

Salut,

Il n'y a, normalement, rien qui empeche de déclarer une variable static const de type entier...

Après tout, la S(T)L en fourmille (3 rien que dans basic_string)...

Le tout étant, sans doute, de veiller à l'initialisation correcte de ces variables (voir la FAQ pour plus d'infos) ;)

Code:

1 2 3 4 5 6 class MaClasse { public : static size_t const maxOscs_ = 3; static float const maxWide_ = 0.2f; };
ne fonctionne pas mais
Code:

1 2 3 4 5 6 7 8 class MaClasse { public : static size_t const maxOscs_; static float const maxWide_; }; size_t MaClasse::maxOscs_ = 3; float MaClasse::maxWide_ = 0.2f;
ceci fonctionne parfaitement, et ce quelque soit le type (int, float, void* etc etc)

aux erreurs d'inattention pres, je crois que c'est la bonne forme.

14/01/2008, 10h32
MatRem

Citation:

Pourquoi ne peut-on initialiser que les membres static const de type entier ?

C'est aussi le comportement de gcc 4 (avec -pedantic), et a priori c'est ce qui est définit dans la norme (d'après le langage c++, bjarne stroustrup).
Par contre je n'en connais pas la raison.

Bjarne Stroustrup semble l'expliquer ici, mais j'ai pas bien saisi:
http://www.research.att.com/~bs/bs_faq2.html#in-class
14/01/2008, 10h35
NiamorH

Koala, mon problème n'est que pour les floats :

Citation:

Envoyé par NiamorH

ma question est : Pourquoi ne peut-on initialiser que les membres static const de type entier ?

screetch, c'est déjà ce que j'ai fait, mais ce n'est pas ma question.

Ok MatRem je vais voir ce lien. Je me demande bien ce qui pourrais faire obstacle à cette écriture.
14/01/2008, 10h41
Emmanuel Deloget

Citation:

Envoyé par koala01

Salut,

Il n'y a, normalement, rien qui empeche de déclarer une variable static const de type entier...

Après tout, la S(T)L en fourmille (3 rien que dans basic_string)...

Le tout étant, sans doute, de veiller à l'initialisation correcte de ces variables (voir la FAQ pour plus d'infos) ;)

Seuls les static const d'un type intégral (enum, bool, char, short, int, long) peuvent être initialisés dans la classe. Tous les autres (float, double, classe, types composés, ...) sont initialisés hors classe.

Cf. section 9.2 §4 du standard C++:
A member-declarator can contain a constant-initializer only if it declares a static member (9.4) of const integral or const enumeration type, see 9.4.2.

Au niveau des raisons techniques qui ont poussé le comité de normalisation à faire ce choix, je ne les connais pas. Mais je parie qu'elles sont bonnes ;)
14/01/2008, 13h34
screetch

Citation:

Envoyé par NiamorH

screetch, c'est déjà ce que j'ai fait, mais ce n'est pas ma question.

dans ce cas la pose la question autrement, il manque des mots cles dans ta phrase pour la comprendre. tu veux initialiser des variables static const "inline" dans la classe et tu veux savoir pourquoi on peut le faire avec des entiers mais pas avec des float.

parce que c'est possible d'initialiser des static const float.
14/01/2008, 14h42
befalimpertinent

Citation:

Envoyé par Bjarne Stroustrup

class Y {
const int c3 = 7; // error: not static
static int c4 = 7; // error: not const
static const float c5 = 7; // error: not integral
};
[...]
So why do these inconvenient restrictions exist? A class is typically declared in a header file and a header file is typically included into many translation units. However, to avoid complicated linker rules, C++ requires that every object has a unique definition. That rule would be broken if C++ allowed in-class definition of entities that needed to be stored in memory as objects. See D&E for an explanation of C++'s design tradeoffs.
http://www.research.att.com/~bs/bs_faq2.html#in-class

Donc en gros ça serait pour garantir l'unicité de la définition de l'objet. Mais je ne vois pas ce qui différencie un entier d'un non-entier et qui permet à l'entier de ne pas brisé cette règle.
14/01/2008, 15h32
NiamorH

Je reconnais screetch, ma question n'était pas claire au départ.

Citation:

That rule would be broken if C++ allowed in-class definition of entities that needed to be stored in memory as objects. See D&E for an explanation of C++'s design tradeoffs.

Les flottants ont peut-être une réprésentation plus complexe que les entiers, mais pour un type primitif, ça m'étonne. Il reste évasif sur le sujet pour que l'on aille acheter son livre...
14/01/2008, 16h12
Sylvain Togni
Les variables constantes de type intégral peuvent être déclarer en-ligne tout simplement pour permettre de les utiliser comme taille de tableau :
Code:

1 2 3 4 class Y { static int const n = 7; char tab[n]; };
14/01/2008, 16h21
screetch

je pense que c'est en partie car l'implementation des flottants n'est pas garantie, on ne peut pas s'en servir dans la conception du programme. par exemple, il est interdit d'avoir un parametre de template de type "float". en effet le code compilé pourrait etre different d'une implementation de float a l'autre.

c'est plus une supposition qu'une raison, mais en revanche je suis quasi sur que c'est pour la meme raison que les float en parametre de template.
14/01/2008, 16h26
NiamorH

Je pense aussi que c'est la même raison, mais la représentation des entiers diffère aussi non ? Big/Little Endian

Par curiosité, j'aimerais bien comparer deux choix d'implémentation des floats.
14/01/2008, 16h27
ac_wingless

Deux choses sur ce sujet:
(1) pour quelles raisons historiques les membres statiques constants initialisés dans la classe doivent-ils être triviaux?
(2) en quoi ces raisons historiques diffèrent-elles entre les types entiers et flottants pour justifier leur différence de traitement?

Les initialisations de membres statiques constants sont triviaux pour des raisons de performance des implémentations de l'époque remontant aux premiers essais menés avec cfront (ici, Wiki dirait qu'il n'y manque une citation... désolé je sais plus où j'ai lu ça, je crois dans le bouquin de Stroustrup sur l'historique de conception du C++, il explique comment il essayait de compiler des fonctions marquées const avant de re-compiler...). En particulier, dans les délibérations du futur C++0x, qui prévoit la résolution de ce problème antique et devenant de plus en plus ridicule avec le temps, on reconnait que "Clearly, a compiler might have to “remember” a lot of values, but then memories on systems running compilers tend to be correspondingly large these days. Also, this kind of “compile-time data bloat” can occur only as the result of explicit use of constexpr for large arrays." (proposition N2235). C++0x introduit donc un nouveau mot-clé constexpr, qui est défini de façon très intelligente et systématique dans tout le langage, y compris étendu aux constructeurs de classes. On pourra donc utiliser des objets complexes personnels en tant que constantes statiques "inline" de classe.

La différence de traitement historique entre les entiers et les flottants est que, contrairement aux entiers, les expressions complexes faisant intervenir des nombres flottants ne sont pas suffisamment clairement définies, même en utilisant la conformité avec les normes IEEE. Ce problème a été résolu (ou plus exactement caché sous le tapis) en s'inspirant de la méthode du comité C99, à savoir (ISO 99 §6.6): "[#5] An expression that evaluates to a constant is required in several contexts. If a floating expression is evaluated in the translation environment, the arithmetic precision and range shall be at least as great as if the expression were being evaluated in the execution environment.". On voit le problème: une constante double stockée sur 64 bits compilée sur architecture x87 sera plus précise qu'une implémentation sur autre architecture, à cause des calculs intermédiaires sur 80 bits. Plus précise, et donc parfois différente, à source identique (!!).

A noter que ce problème n'est pas pire que ce qui se produit déjà à l'exécution aujourd'hui. Pour ceux qui ont déjà été confrontés à des soucis de précision numérique, l'option /fp des compilateurs MS est cruciale et permet justement de jongler avec ces fameux arrondis 80 ==> 64 bits. C'est évidemment délicat d'avaliser ça au niveau de la définition d'un standard, mais finalement les deux comités (C et C++) ont franchi le pas.
14/01/2008, 16h42
Jean-Marc.Bourguet
Citation:

Envoyé par NiamorH

Les flottants ont peut-être une réprésentation plus complexe que les entiers, mais pour un type primitif, ça m'étonne.

La possibilite d'avoir de definir des static const int dans la classe a ete faite pour un cas d'utilisation: la taille de tableau ou on a besoin d'une expression constante en remplacement du hack utilisant les enum. Il n'y a pas d'expression flottante constante, donc d'une part la justification principale disparait et surtout le moyen utilise pour definir la feature aussi:
Code:

1 2 3 4 5 6 int f(); struct s { static int const i1 = f(); static int const i2; }; int const s::i2 = f();
La definition de i1 n'est pas correcte car f() n'est pas une expression constante. Il n'y a pas d'expression constante flottante, donc aucun moyen de definir un static float const dans la classe.

Citation:

Il reste évasif sur le sujet pour que l'on aille acheter son livre...

J'ai pas trop cherche, mais j'ai pas trouve la section ou il traite de ce point.
14/01/2008, 16h50
Jean-Marc.Bourguet

Dans les problèmes lies a l'évaluation des expressions flottantes, il y a encore d'autres problèmes que les différences entre l'environnement de développement et celui d'exécution; il y a aussi le fait que l'environnement d'exécution peut être inconnu: la norme IEEE 754 permet en effet de spécifier au runtime un certain nombre de caractéristiques, dont le mode d'arrondi. Si la plus grosse partie de l'environnement d'exécution peut être émulé, ceci ne le peut pas.