Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ Specialisation de templates et types prédéfinis

Specialisation de templates et types prédéfinis

29 réponses
Avatar
diego-olivier.fernandez-pons
Bonjour,

Comme mon code C/C++ doit tourner sur une multitude de plateformes
=E9tranges, je red=E9finis les types pr=E9d=E9finis (bool, int, float) avec
=E9ventuellement suivant des plateformes des cast affreux (typedef float
myInt) pour contourner les multiples bugs des plateformes/compilateurs
(machines 64 bits avec entiers 32 bits, machines avec entiers 16 bits,
etc.)

Mais du coup le syst=E8me de types est totalement perdu dans la
sp=E9cialisation des templates :

template <typename T> class Array {...} // tableau de pointeurs sur des
objets

// optimisations classiques avec les types natifs "unboxed"
template <> class Array <myBool> {...}
template <> class Array <myInt> {...}
template <> class Array <myFloat> {...}

Oui mais avec myInt =3D myFloat =3D float, le compilateur se perd.
Forc=E9ment.

Quelqu'un sait comment expliquer au compilateur que je veux qu'en
machine myInt =3D myFloat mais syntaxiquement myInt !=3D myFloat ?

Diego Olivier
Signaler un problème avec ce contenu

9 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
Gabriel Dos Reis
James Kanze writes:

[...]

| > | Je constate que sous Linux, g++ a effectivement choisi une
| > | taille de 12 pour long double, c-à-d qu'il enforce un
| > | alignement de 4. Je ne connais pas les raisons de ce choix,
|
| > As-tu pensé, une seconde, que GCC *ne fait qu'implémenter*
| > l'ABI définit pour la plateforme cible ?
|
| Je n'accuse personne. Je sais que les raisons derrière tel ou
| tel choix peuvent être légion. Tout ce que je dis, c'est que
| c'est un chois qui n'a pas de sens *pour* *les* *hardware*
| *modernes* -- il pourrait bien se justifer pour les 80386, par
| exemple.

1) Je n'ai vu personne dire que tu accusais quelqu'un.

2) Tu n'expliques toujours pas pourquoi le choix 10 est meilleur
que 12 sachant que l'alignement naturel est 4. Il me paraît
évident que si on considère qu'on peut avoir des tableaux de
long double -- ce qui n'est pas exactement une stupide idée --
alors un sizeof de 10 n'est pas meilleur 13, alors que 12
présente nettement un avantage indéniables : tous les élements
du tableau sont alignés.

| N'oublie pas le contexte de la discussion, non plus.

Mais je n'oublie pas le contexte de la discussion. Bien au contraire.
Quand tu affirmes sans sourciller « il n'y a aucune justification
technique », alors il me semble que tu as perdu contact avec la réalité.
N'essaie pas de distraire plus.

Ah, au fait, un double dans une structure n'a pas un alignement 8,
c'est plutôt 4. Et aussi, les flottants sont convertis en *hardware*
en format 80 bits, ce qui fait pluls que 8 bytes sur cette machine.



-- Gaby
Avatar
Gabriel Dos Reis
James Kanze writes:

| Gabriel Dos Reis wrote:
| > James Kanze writes:
|
| > | Gabriel Dos Reis wrote:
| > | > "kanze" writes:
|
| > | > | wrote:
|
| > | > | > [DOFP]
| > | > | > > Sur une machine raisonnable on a :
| > | > | > > Table of the numbers of bytes used for different data type
| > | > | > > char : 1
| > | > | > > int : 4
| > | > | > > long int : 4
| > | > | > > float : 4
| > | > | > > double : 8
| > | > | > > long double : 12
|
| > | > | > [Kanze]
| > | > | > > Tu as une drôle d'idée de « raisonable ». Je n'ai
| > | > | > > jamais encore vu une machine comme ça ;
|
| > | > | > Ma machine de développement prétend s'appeler Intel
| > | > | > Pentium III 500. Et elle dit même qu'elle a plein de
| > | > | > soeurs et de cousines qui lui ressemblent.
|
| > | > | Au niveau hardware, l'architecture Intel 32 bits a
| > | > | trois tailles de virgule flottant : 4, 8 et 10 bits.
|
| > | > Cela m'étonnerait.
|
| > | Faute de frappe évidente, non ?
|
| > Non. Parce que tout ton raisonement était basé sur ça.
|
| Tu divages, ou quoi ?

Tu t'es vu quand t'as bu ?

| Tout mon raisonement était basé sur le
| fait que les tailles supportées en hardware étaient de 4, de 8
| et de 10 octets. C'était assez clair pour celui qui n'y met pas
| de mauvaise fois.

| > Par contre, cela paraissait une confusion évidente entre bits
| > et bytes et pas seulement une faute de frappe.
|
| > | Changer « bits » en « bytes ».
|
| > | > [...]
|
| > | > | Évidemment, on pourrait en augmenter la taille pour en
| > | > | faire 12 aussi. Ou 11. Ou 13. C'est cependant un choix
| > | > | un peu bizarre.
|
| > | > Lequel est bizarre, 11, 12, ou 13?
|
| > | Tous. Logiquement, on choisira soit 16, pour la vitesse maximum,
| > ^^^^^^^^^^^
|
| > Mais selon *quelle* logique ?
|
| La logique « technique ».

Est-ce qu'il t'a, une seconde, effleuré l'esprit que si on a un
alignement de 4, un sizeof de 10, les accès aux éléments d'un tableau
ne sont pas alignés ?

[...]

| > | soit 10, pour la taille minimum.
|
| > sauf que 10 c'est pas un multiple de quatre -- alignement
| > naturel, sur un x86 32-bit.
|
| C'est quoi, cet alignement « naturel » ? Au niveau hardware, on
| n'impose aucun alignement ; alignement « naturel » est 1.

N'importe quoi.

| Seulement, certains alignements peuvent payer une pénalité de
| performance.

donc certains alignements sont plus naturels que d'autres.

| Lesquels dépendent de la machine,

Oh, c'est un scoop.

| > Maintenant, refais ton raisonement en considérant un sizeof 10
| > et un alignement de 10. Si tu ne vois pas un trou, on arrête
| > la discussion.
|
| J'ai une meilleur idée : fais des mesures des temps d'accès avec
| des alignements de 4, et des alignements de 16. Parce que je ne
| parle pas des raisonements théoriques, mais des temps
| d'exécutions mesurables.

J'ai bien compris que tu ne faisais pas de la théorie -- cela aurait
été une insulte à la notion de théorie vu le type de raisonnement que
tu alignes.

Pour te rafraîchir la mémoire:
# La
# taille des lignes de cache varie, mais elles sont toujours une
# puissance de deux. Or, 12 n'est diviseur d'aucune puissance de
# deux. C'est donc un mauvais choix -- autant que faire, il vaut
# mieux rester à 10.)
^^^^^^^^^^^^^^^^^

Pfff. Pense tableau de long double et dis-nous comment tu alignes tous
les éléments si tu as un sizeof de 10.

-- Gaby
Avatar
Falk Tannhäuser
Gabriel Dos Reis wrote:
Est-ce qu'il t'a, une seconde, effleuré l'esprit que si on a un
alignement de 4, un sizeof de 10, les accès aux éléments d'un tableau
ne sont pas alignés ?


Sur un bus de données de 32 bits, un mot de 10 octets peut
être accédé en 3 cycles, qu'il soit aligné sur une adresse
multiple de 4 (1er et 2ème cycle: 4 octets, 3ème cycle 2 octets)
ou sur une adresse multiple de 4 plus 2 (1er cycle 2 octets,
2ème et 3ème cycle 4 octets). Les Intel x86 (x>=3) ne font-ils
pas ainsi pour accéder des "long double" ?

Falk

Avatar
James Kanze
Gabriel Dos Reis wrote:
James Kanze writes:


[...]


| > | Je constate que sous Linux, g++ a effectivement choisi une
| > | taille de 12 pour long double, c-à-d qu'il enforce un
| > | alignement de 4. Je ne connais pas les raisons de ce choix,


| > As-tu pensé, une seconde, que GCC *ne fait qu'implémenter* l'ABI
| > définit pour la plateforme cible ?


| Je n'accuse personne. Je sais que les raisons derrière tel ou tel
| choix peuvent être légion. Tout ce que je dis, c'est que c'est un
| chois qui n'a pas de sens *pour* *les* *hardware* *modernes* -- il
| pourrait bien se justifer pour les 80386, par exemple.


1) Je n'ai vu personne dire que tu accusais quelqu'un.


2) Tu n'expliques toujours pas pourquoi le choix 10 est meilleur
que 12 sachant que l'alignement naturel est 4.


Évidemment que je ne l'explique pas. Puisque ce que j'essaie à dire,
c'ets que l'alignement naturel n'est pas 4. En fait, je ne sais pas
exactement ce que tu entends là par « alignement naturel », sauf
peut-être un alignement naïvement naturel. Si tu veux que les tableaux
de long double utilisent la moins de place possible, l'alignement
« optimal », pour atteindre ce but, et 2, ce qui donne une taille de 10.
(Mais en rélisant ce que j'ai écrit avant, je constate qu'effectivement,
j'ai melangé taille et alignement pas mal. Alors, je comprends qu'on ne
m'a pas bien compris.) Et que sur une machine moderne, l'alignement
« optimal » de point de vue de la performance, pour tout type supporté
directment en hardware, c'est la puissance de deux supérieur à sa taille
en hardware -- ici donc, 16 (parce que c'est la puissance de deux
supérieur à 10). J'ai du mal à dire que l'un est plus « naturel » que
l'autre, mais l'un est optimal d'un point de vu, et l'autre de l'autre.

Il me paraît évident que si on considère qu'on peut avoir des
tableaux de long double -- ce qui n'est pas exactement une
stupide idée -- alors un sizeof de 10 n'est pas meilleur 13,
alors que 12 présente nettement un avantage indéniables : tous
les élements du tableau sont alignés.


| N'oublie pas le contexte de la discussion, non plus.

Mais je n'oublie pas le contexte de la discussion. Bien au contraire.
Quand tu affirmes sans sourciller « il n'y a aucune justification
technique », alors il me semble que tu as perdu contact avec la
réalité. N'essaie pas de distraire plus.


Ah, au fait, un double dans une structure n'a pas un alignement 8,
c'est plutôt 4.


Ce qui a un impact négatif sur les performances. Alors, pourquoi pas
simplement 2. Voire même 1.

J'ai toujours du mal à comprendre d'où tu tires ce 4. C'était un choix
valide peut-être sur 80386, et encore, je ne suis pas sûr. Mais ça n'a
un rapport à rien au niveau hardware aujourd'hui.

Et aussi, les flottants sont convertis en *hardware* en format 80
bits, ce qui fait pluls que 8 bytes sur cette machine.


Dans les régistres. Le hardware sait adresser des variables flottantes
de 4, de 8 et de 10 octets en mémoire.

--
James Kanze mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Avatar
James Kanze
Falk Tannhäuser wrote:
Gabriel Dos Reis wrote:


Est-ce qu'il t'a, une seconde, effleuré l'esprit que si on a un
alignement de 4, un sizeof de 10, les accès aux éléments d'un tableau
ne sont pas alignés ?



Sur un bus de données de 32 bits, un mot de 10 octets peut être accédé
en 3 cycles, qu'il soit aligné sur une adresse multiple de 4 (1er et
2ème cycle: 4 octets, 3ème cycle 2 octets) ou sur une adresse multiple
de 4 plus 2 (1er cycle 2 octets, 2ème et 3ème cycle 4 octets). Les
Intel x86 (x>=3) ne font-ils pas ainsi pour accéder des "long double"
?


Tout à fait. C'est pour ça que je ne suis pas convaincu qu'un alignement
de 12 se jutifiait même sur 80386.

Aujourd'hui, évidemment, les transferts entre la cache du premier niveau
et le CPU se font sur des largeurs bien plus grand que 32 bits, au moins
sur les machines les plus performantes. Et cette largeur a tendance à
augmenter -- tout ce qu'on peut dire, c'est qu'il y a peu de chances
qu'elle ne soit pas une puissance de 2. Ce qui mène à la conclusion que
l'alignement optimal pour la vitesse est la puissance de deux supérieur
à la taille réele de l'objet.

Dans la pratique, donc, un alignement de 2 (ce qui donne une taille de
10) est optimal en ce qui concerne la place utilisée, et un alignement
de 16 (ce qui donne une taille de 16) pour la vitesse.

--
James Kanze mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34


Avatar
Gabriel Dos Reis
James Kanze writes:

| Gabriel Dos Reis wrote:
| > James Kanze writes:
|
| > [...]
|
| > | > | Je constate que sous Linux, g++ a effectivement choisi une
| > | > | taille de 12 pour long double, c-à-d qu'il enforce un
| > | > | alignement de 4. Je ne connais pas les raisons de ce choix,
|
| > | > As-tu pensé, une seconde, que GCC *ne fait qu'implémenter* l'ABI
| > | > définit pour la plateforme cible ?
|
| > | Je n'accuse personne. Je sais que les raisons derrière tel ou tel
| > | choix peuvent être légion. Tout ce que je dis, c'est que c'est un
| > | chois qui n'a pas de sens *pour* *les* *hardware* *modernes* -- il
| > | pourrait bien se justifer pour les 80386, par exemple.
|
| > 1) Je n'ai vu personne dire que tu accusais quelqu'un.
|
| > 2) Tu n'expliques toujours pas pourquoi le choix 10 est meilleur
| > que 12 sachant que l'alignement naturel est 4.
|
| Évidemment que je ne l'explique pas.

Eh bin, tu devrais.

[...]

| (Mais en rélisant ce que j'ai écrit avant, je constate qu'effectivement,
| j'ai melangé taille et alignement pas mal. Alors, je comprends qu'on ne
| m'a pas bien compris.)

C'est la faute des autres, hein.

[...]

| > Et aussi, les flottants sont convertis en *hardware* en format 80
| > bits, ce qui fait pluls que 8 bytes sur cette machine.
|
| Dans les régistres. Le hardware sait adresser des variables flottantes
| de 4, de 8 et de 10 octets en mémoire.

James, cette phrase à laquelle tu réponds parle du *calcul*, pas juste
de l'adressage.

-- Gaby
Avatar
Gabriel Dos Reis
James Kanze writes:

| Falk Tannhäuser wrote:
| > Gabriel Dos Reis wrote:
|
| >> Est-ce qu'il t'a, une seconde, effleuré l'esprit que si on a un
| >> alignement de 4, un sizeof de 10, les accès aux éléments d'un tableau
| >> ne sont pas alignés ?
|
| > Sur un bus de données de 32 bits, un mot de 10 octets peut être accédé
| > en 3 cycles, qu'il soit aligné sur une adresse multiple de 4 (1er et
| > 2ème cycle: 4 octets, 3ème cycle 2 octets) ou sur une adresse multiple
| > de 4 plus 2 (1er cycle 2 octets, 2ème et 3ème cycle 4 octets). Les
| > Intel x86 (x>=3) ne font-ils pas ainsi pour accéder des "long double"
| > ?
|
| Tout à fait. C'est pour ça que je ne suis pas convaincu qu'un alignement
| de 12 se jutifiait même sur 80386.

Qui a dit alignement de 12 ?

-- Gaby
Avatar
James Kanze
Gabriel Dos Reis wrote:
James Kanze writes:


[...]
| > 2) Tu n'expliques toujours pas pourquoi le choix 10 est meilleur
| > que 12 sachant que l'alignement naturel est 4.


| Évidemment que je ne l'explique pas.


Eh bin, tu devrais.


Pourquoi dois-je expliquer une bêtise qui n'est pas de moi. Ce n'est pas
moi qui a dit que l'alignement naturel est 4. Au contraire, je
dis depuis le début que ce n'est pas le cas.

[...]


| (Mais en rélisant ce que j'ai écrit avant, je constate
| qu'effectivement, j'ai melangé taille et alignement pas mal.
| Alors, je comprends qu'on ne m'a pas bien compris.)


C'est la faute des autres, hein.


Il me semble que j'ai dit exactement le contraire. Je reconnais
que je me suis mal exprimé.

[...]


| > Et aussi, les flottants sont convertis en *hardware* en
| > format 80 bits, ce qui fait pluls que 8 bytes sur cette
| > machine.


| Dans les régistres. Le hardware sait adresser des variables
| flottantes de 4, de 8 et de 10 octets en mémoire.


James, cette phrase à laquelle tu réponds parle du *calcul*,
pas juste de l'adressage.


On parle de l'alignement, non ?

En fait, j'avais bien compris que tu essayais de détourner la
discussion -- c'est généralement le cas chez toi quand tu as
tort. Je sais que les calculs internes se font toujours sur 80
bits. Je sais aussi que ça n'a aucune importance en ce qui
concerne les problèmes d'alignement. Alors, j'ai simplement
rappelé de quoi on parlait.

--
James Kanze mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Avatar
Gabriel Dos Reis
James Kanze writes:

| Gabriel Dos Reis wrote:
| > James Kanze writes:
|
| [...]
| > | > 2) Tu n'expliques toujours pas pourquoi le choix 10 est meilleur
| > | > que 12 sachant que l'alignement naturel est 4.
|
| > | Évidemment que je ne l'explique pas.
|
| > Eh bin, tu devrais.
|
| Pourquoi dois-je expliquer une bêtise qui n'est pas de moi.

C'est vrai, elle n'est pas de toi ; elle de James Kanze.

[...]

| > | > Et aussi, les flottants sont convertis en *hardware* en
| > | > format 80 bits, ce qui fait pluls que 8 bytes sur cette
| > | > machine.
|
| > | Dans les régistres. Le hardware sait adresser des variables
| > | flottantes de 4, de 8 et de 10 octets en mémoire.
|
| > James, cette phrase à laquelle tu réponds parle du *calcul*,
| > pas juste de l'adressage.
|
| On parle de l'alignement, non ?

Oui et *pas exclusivement*. Tu n'as peut-être pas lu le message en
entier avant de presser sur le boutton « send » ?

| En fait, j'avais bien compris que tu essayais de détourner la
| discussion -- c'est généralement le cas chez toi quand tu as
| tort.

Ah ben voyons.

# > C'est la faute des autres, hein.
#
# Il me semble que j'ai dit exactement le contraire. Je reconnais
# que je me suis mal exprimé.

-- Gaby
1 2 3