Discussion :

[Awakening]

Bonjour,

J'ai un probl�me mineur. je suis entrain de faire une classe Maths ayant plein de constantes (PI en float, PI/2 en float, PI en double, PI/2 en double etc).

Mais l'ennuie c'est que je ne voudrai pas que les constantes cr�es soient dans mon fichier binaire. Oui je gagnerais une cinquantaine d'octet mais j'y tiens. :]
Je ne voudrais pas avoir recours au #define tout simplement parce que je souhaiterais appeler la constante avec "Math::MyValue".

Est-ce qu'un b�te "inline static const float MyValue = 3.14f" fonctionne ?
Ou encore mettre mes valeurs dans un namespace "Math" ?

Merci.

[screetch]

tant que tu ne prends pas l'addresse d'une variable, un static const float ne prend pas de place (s'il est dans un header. s'il est dans un cpp alors le linker doit avoir son adresse).
il est possible que tu doives le mettre dans un namespace cependant (je sais pas si c'est legal de definir un static const float lors de la declaration)
sinn le plus simple: tester, compiler les deux versions

[Awakening]

Je note �a. Merci beaucoup !

Je vais faire des testes plus tard et je posterai les r�sultats ici.

[3DArchi]

Salut

(s'il est dans un header. s'il est dans un cpp alors le linker doit avoir son adresse).

Je ne sais pas ce que tu entends par l�. Mais si l'adresse n'est jamais explicitement prise et en mode release le linker nettoyant les symboles non r�f�renc�s, les static const ne devraient pas se retrouver dans l'ex�cutable final. En tout �tat de cause, � v�rifier.

[screetch]

Je voulais dire: si la variable est dans un fichier cppet r�f�renc�e dans un autre fichier cpp alors le linker devra sans doute l'ajouter dans l'ex�cutable
Si la constante est dans un fichier header alors elle sera �limin�e.

[oodini]

Mais ce comportement est-il d�fini dans la norme ?

[screetch]

non, c'est l'impl�mentation des compilateurs.
Dans la norme, rien n'est indiqu� sur la taille des executables, de toutes facons, donc pas possible de la brandir comme preuve

[Emmanuel Deloget]

non, c'est l'impl�mentation des compilateurs.
Dans la norme, rien n'est indiqu� sur la taille des executables, de toutes facons, donc pas possible de la brandir comme preuve

La seule chose que la norme dit, c'est que d�s lors qu'on prends l'adresse d'une constante, le compilateur doit le d�tecter et d�finir la zone m�moire o� la valeur est stock�e. Par contre, tant que tu ne prends pas son adresse, elle n'a pas besoin d'en avoir, et le compilateur a tout a fait le droit de ne pas stocker la constante.

[Luc Hermitte]

Et vu le besoin que l'on a des adresses des constantes, je ne vois pas trop o� est le probl�me.
Elle sont g�n�ralement �limin�es^Winlin�es, o� qu'elles se trouvent d�finies.
Pour des infos plus pr�cises, et justes surtout, je dirai de jeter un coup d'oeil au TR18015 sur les perfs (dispo sur le site du commit� de standardisation). Les constantes y sont trait�es dans mes souvenirs.

[loufoque]

Tu peux aussi mettre les constantes sous forme hexad�cimale avec un static const uint32_t ou uint64_t, et du coup elles prendront 0 m�moire...

[Luc Hermitte]

Quel rapport avec l'hexa ?