Questions C++ : Short/Int et inline

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

Citation:

---

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.

Citation:

---

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.

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.

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

Bien s�r que non.

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

Pour l'inlining, oui, �a peut �tre dangereux d'en abuser:
- Les fonctions inline doivent �tre impl�ment�es dans des fichiers en-t�tes => peut augmenter consid�rablement le temps de compilation
- Parce que la fonction appelant est directement remplac� par le corps de la fonction, ceci peut augmenter la taille de l'ex�cutable et peut m�me dans certains cas diminuer les performances
- En g�n�rale, on inline les fonctions tr�s simples et qui ne font pas appel � d'autres fonctions

Je sais que dans beaucoup de cas, tu peux avoir besoin d'un indice sp�cial qui d�signe une valeur invalide, o� souvent -1 est utilis�.

Chez Dassault Systemes, ils utilisent '0' pour �a et les indices valides commencent � 1, mais je trouve �a naze parce que les risques de confusion sont grands.

Ce que tu peux faire, c'est faire une valeur constante UNDEF = static_cast<size_t>(-1).

Ca limitera simplement la taille th�orique de ton tableau � 2^32 - 1, et tu gardes tous les avantages � ne pas avoir � caster avec un size_t, etc...

Citation:

---

Envoy� par loufoque

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

---

Tu peux donner un exemple ?

Exemple trouv� rapidement avec Google
http://msdn.microsoft.com/en-us/library/ms972705.aspx

Bof, l'article parle plus du danger d'utiliser des types trop petits que d'utiliser des non-sign�s.

C'est parce que tu l'as mal compris.

D'apr�s cet article, les unsigned ne sont pas vraiment mieux (cf. exemple du malloc et de l'overflow sur l'unsigned char).

Citation:

---

Envoy� par mister3957

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.

Citation:

---

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.

Citation:

---

Envoy� par Obsidian

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 :aie:

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 ...

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.