Discussion :

[mister3957]

Bonjour � tous,


Je suis en train de mapper des donn�es de base de donn�es avec des membres C++, et j'ai des donn�es qui vont de 1 � 10 par l�.

Est-ce que je les met dans un unsigned short ou un unsigned int ?
Unsigned, la compteur commen�ant � 1, la valeur 0 suffira pour indiquer que la donn�e n'est pas positionn�e (pas besoin de -1) mais int ou short... je suis all� faire un tour dans les types du C++ et je me rend compte que ce sont les m�mes...

A moins que j'utilise un unsigned char ? Vous feriez quoi ?


Et autre chose concernant les fonctions inline. J'ai vu que c'�tait un peu les macro du C++, pour g�n�rer le code de la fonction inline directement � l'appel, comme les macro, mais en conservant le type.
J'ai lu �galement que si l'on en mettait pas, le compilateur allait en assigner intelligemment, et que si on en met trop le compilateur en refuserai.

Si �a ne fait que remplacer du code, on perd en temps de compilation j'imagine, mais on y gagne en ex�cution, c'est dangeureux d'en abuser ?


Merci

A bient�t

[NairodDorian]

Est-ce que je les met dans un unsigned short ou un unsigned int ?

Les processeurs x86 pr�f�rent travaill�s avec 32 bits ou 8 bits mais pas avec 16 bits. Donc unsigned char ou unsigned int mais surement pas unsigned short sinon le compilateur g�n�rera syst�matique movsz. Quand � moi je te conseil unsigned int.

c'est dangeureux d'en abuser ?

En g�n�ral on inline pas tout est n'importe quoi. Un bon compilo d�cidera seul si c'est vraiment utile que t'es d�clar� ta fonction inline. Si t'es d�butant laisse boss� le compilo surtout si t'as MSC++ avec l'option /GL.

[Sylvain Togni]

Moi je part du principe qu'en C++ si l'on a besoin d'un entier on utilise int, sauf si on a une bonne raison pour utiliser autre chose.

Ici je ne vois pas l'int�r�t d'utiliser un non-sign� par exemple, � part augmenter la probabilit� d'un bug du � l'arithm�tique plus compliqu�e des non-sign�s.

[mister3957]

Utiliser des entiers non sign�s est plus long � l'ex�cution ?

[NairodDorian]

Bien s�r que non.

[loufoque]

Utiliser des entiers sign�s pour des indexes �a fait des bugs de s�curit� �vidents.

[Obsidian]

Je suis en train de mapper des donn�es de base de donn�es avec des membres C++, et j'ai des donn�es qui vont de 1 � 10 par l�. A moins que j'utilise un unsigned char ? Vous feriez quoi ?

Tout d�pend de la quantit� de donn�es que tu as � stocker en m�moire. Moi, personnellement, pour compter de 1 � 10, j'utiliserais all�grement un unsigned char, voire m�me un partitionnement bit � bit dans une structure. Par contre, je conserverais quand m�me int pour toutes les variables � de travail � (indices de boucles, etc.) de fa�on � respecter le format du bus et des registres du processeur.

Et autre chose concernant les fonctions inline. J'ai vu que c'�tait un peu les macro du C++, pour g�n�rer le code de la fonction inline directement � l'appel, comme les macros [...] Si �a ne fait que remplacer du code, on perd en temps de compilation j'imagine, mais on y gagne en ex�cution, c'est dangeureux d'en abuser ?

Attention � ne pas confondre. Les � macros � existent en C et C++. Les inline s'�valuent de la m�me fa�on que les fonctions ordinaires mais leur code est dupliqu� directement plut�t qu'appel�es en utilisant la pile. Je ne pense pas que le surco�t en temps de compilation soit vraiment mesurable, � moins d'utiliser des fonctions inline g�antes, ce qui n'aurait pr�cis�ment aucun sens.

Il n'est pas sp�cialement dangereux de les utiliser sauf dans un cas (b�te) : celui o� une fonction serait tellement r�pandue que l'on voudrait augmenter les perfs en diminuant le temps d'appel � chaque fois. On risque surtout de factoriser l'augmentation en taille et �a peut �tre dramatique pour un gain en vitesse quasi-nul.

Pour le reste, les cas o� inline sont utiles sont tellement pr�cis que l'on peut affirmer sans risque : � si tu ne sais pas � quoi �a sert, tu n'en as probablement pas besoin �.

Les cas o� inline peut �tre int�ressant est lorsque qu'une fonction simple est appel�e dans une boucle. On gagne la dur�e du saut � chaque passage et le code ins�r� au milieu de l'environnement peut-�tre optimis� par le compilo (registres), on �vite de vider le contenu du pipe-line, etc.

� examiner au cas par cas, donc.

[zabibof]

Je ne pense pas que le surco�t en temps de compilation soit vraiment mesurable

Bien s�r, �a n'a aucun impact sur le temps de compilation quand tu modifies l'impl�mentation d'une fonction inline qui se trouve dans un fichier en-t�te "includ�" par 50 autres fichiers en-t�tes

[Obsidian]

C'est ce que j'explique dans mon troisi�me paragraphe.

Et m�me l�, malgr� tout, quand tu te retrouves � inclure une fonction inline dans cinquante fichiers d'ent�te, d�j�, il doit y avoir quelque chose de pas correct, � mon avis, mais surtout, si ta fonction inline est suffisamment cons�quente pour ralentir la compilation, c'est qu'elle ne doit pas �tre inline.

� moins que tu parles des d�pendences entre les fichiers � la compilation et, dans ce cas, ce n'est pas le fait que la fonction soit inline qui provoque la recompilation en cascade ...

[screetch]

si c'est pour le stockage ca peut valoir le cout de sauver un octet ou deux par structure. sinon, il vaut mieux utiliser la plus grande capacit� pour eviter de se retrouver avec des maths fausses. et n'utiliser signed int que si le resultat est vraiment sign�.
Au niveau generation de code, ca ne changera rien, et c'est au compilateur d'effectuer ce genre d'operations correctement, pas a celui qui ecrit.