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.

[zabibof]

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

[HanLee]

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

[Sylvain Togni]

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

Tu peux donner un exemple ?

[loufoque]

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

[Sylvain Togni]

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

[loufoque]

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

[stephl]

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

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