Discussion :

[Jilasse]

Bonjour à tous,

Dans la phrase "lorsque les types sont définis par forçage, tout ce qui est suffisamment grand pour contenir une valeure sur 4 octets peut jouer le role de pointeur non typé".

Qu'est-ce qui est " suffisamment grand " ?
Et type de valeure (adresse mem ou type de donné entier, craractère)?

Merci

[Bousk]

Salut,

ça voudrait dire qu'un pointeur tient sur 4 octets, et ça me parait au moins faux. C'est certainement vrai sur les systèmes 32bits, et dans les programmes compilés en 32 bits, plus vraiment avec des programmes compilés en 64 bits où un pointeur peut s'étendre sur 8 octets.
D'où que tu sortes cette affirmation, tu peux probablement considérer cette source fausse.
Les seuls types sûrs pour contenir un pointeur quelconque sont std::intptr_t ou std::uintptr_t définis dans cstdint et void*.
Et bien sûr il est toujours mieux d'avoir des pointeurs typés.

[Bktero]

Un code comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
float valeur = 42;
float* pointeur = &valeur;
int adresse = (int) &valeur;

En partant du principe que sizeof(float*) <= sizeof(int), tu peux stocker la valeur de 'pointeur' dans 'adresse' (qui est '&valeur'). Ce principe est peut-être faux comme l'explique très bien Bousk. En admettant qu'il soit vrai, 'pointeur' et 'adresse' contient la même chose : l'adresse de 'valeur'. Par contre, 'pointeur' sait que ce qui est pointé est un 'float' (*), contrairement à 'adresse'. Tu as donc bien forcé le type avec le cast (int) et tu te retrouves avec un genre de pointeur non-typé. Ce qui ne sert pas à grand chose... On va préférer utiliser des void* ou intptr_t.

(*) C'est l'essence même d'un pointeur : son type indique le type pointé, sa valeur donne l'adresse d'un objet de ce type (normalement, mais on peut toujours faire du sale comme ceci : float valeur; int* pointeur = (int*) &valeur; et à ce moment là il y a incohérence entre le type supposé et le type réel de l'objet pointé).

[Jilasse]

Merci ça m'a beaucoup aidé

[foetus]

Je passais par là , et je me demande si cela ne pouvait pas être "autre chose", une chose que j'ai vu en embarqué mais je n'en suis pas sûr

Attention, code qui nécessite de maîtriser le 32/ 64 bits

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
void one_function(int param) {
    unsigned int id = (unsigned int) param;
//  or
    char c = (char) param;
//  char c = (char) param & 0xff;
//  or
    int* handle = (int*) param;
//  or
    My_Struct* one_struct = (My_Struct*) param;
//  or
    float val = (float) param;
}

[sambia39]

Bonjour,
En langage C/C++, les pointeurs n'ont pas une taille fixe. Tout simplement parce que la taille d'un pointeur dépend de plusieurs choses à commencer par l'architecture de la machine, le système d'exploitation et voir même le compilateur. Cependant, de façon générale, la taille d'un pointeur est égale à la taille d'un mot machine.

Comme là souligner @Bousk pour un ordinateur 32 bits, la taille du pointeur peut être de 4 octets et pour les ordinateurs 64 bits cela peut être égale 8 octets. Il y a également la situation dans laquelle où l'on trouve un sur une architecture 64 bits un système d'exploitation 32 bits et dans ce cas-là les pointeurs auront une taille non pas égale à l'architecture machine 64 bits mais un mot correspond à une architecture 32 bits (4 octets) parce que le système d'exploitation qui s'exécute sur cette architecture est de 32 bits. Cas contraire (64 bits) , vous aurez une taille de pointeur pouvant s'étendre sur 8 octets.
Il y a des cas (architecture spécifique) où on peut avoir des pointeurs dont peut importe leur type, ils auront sans exception la même taille sauf les pointeurs de fonction.

à bientôt

[foetus]

En langage C/C++, les pointeurs n'ont pas une taille fixe.

Le problème, c'est la taille d'un entier
Sur une plateforme 32 bits, c'est 32 bits (des rares fois c'est 16 bits), un long 32 bits et un long long 64 bits.
Alors que sur une plateforme 64 bits

• un entier c'est soit 32 bits (LLP64 ou LP64) soit 64 bits (ILP64 ou SILP64)
• un long c'est soit 32 bits (LLP64) soit 64 bits (LP64 ou ILP64 ou SILP64)

Donc, assumer que la taille d'un entier et/ ou d'un long est la même qu'un pointeur, ne fonctionne que si on n'utilise des compilateurs avec lesquels on maîtrise le 32/ 64 bits.

[sambia39]

Je n’ai pas trop compris ce que vous avez voulu dire par

Donc, assumer que la taille d'un entier et/ ou d'un long est la même qu'un pointeur, ne fonctionne que si on n'utilise des compilateurs avec lesquels on maîtrise le 32/ 64 bits.


À ce que je sache, ILP64 veut dire qu'un int, long et les pointeurs ont tous une même taille, qui correspond au mot machine (64 bits) et ILP32 int, longet les pointeurs sont tous de 32 bits. Tout dépend donc du modèle adopté et non si l’on utilise des compilateurs avec lesquels on maîtrise le 32/64 bits. Où alors je n’ai absolument pas compris votre réponse ?

[foetus]

Tout dépend donc du modèle adopté et non si l’on utilise des compilateurs avec lesquels on maîtrise le 32/64 bits. Où alors je n’ai absolument pas compris votre réponse ?

Justement , le modèle dépend du système d'exploitation : LLP64 c'est Windows, LP64 c'est Unix/ Linux et ILP64/ SILP64 ce sont les stations de travail.

Et cela dépend aussi [un peu] du compilateur : parce que si on n'a un compilateur qui ne compile qu'en 32 bits pas de problème. Mais si on a un compilateur qui compile en 64 bits [surtout par défaut], on peut avoir des problèmes pour un projet multiplateformes.

Trouvé sur Internet :

It also makes the key point that a lot of programmers from the ILP32 era made assumptions that sizeof(int) == sizeof(long) == sizeof(void*) which would not hold true for the LP64/LLP64 era.

[sambia39]

Justement , le modèle dépend du système d'exploitation : LLP64 c'est Windows, LP64 c'est Unix/ Linux et ILP64/ SILP64 ce sont les stations de travail.

Et cela dépend aussi [un peu] du compilateur : parce que si on n'a un compilateur qui ne compile qu'en 32 bits pas de problème. Mais si on a un compilateur qui compile en 64 bits [surtout par défaut], on peut avoir des problèmes pour un projet multiplateformes.

Trouvé sur Internet :

Non ce que vous dites est faux. Le modèle ne dépend pas du système d’exploitation, mais de l’architecture et n’est absolument pas dédié à un système d’exploitation donné tout simplement parce que n’importe quels types de systèmes d’exploitation s’exécutant sur une architecture donnée a le choix d’utiliser/prendre en charge n’importe quel type de modèle correspondant à l'architecture sur laquelle il s’exécute. Exemple : sous une architecture 64 bits, un système d’exploitation peut tout à fait prendre un des modèles suivants LP64, LLP64, IL32LLP64 ou SILP64 . Et un système d’exploitation a également la possibilité de prendre en charge différents modèles. C’est par exemple le cas du système d’exploitation 64 bits de chez Microsoft, il peut soit prendre en charge LLP64 ou IL32LLP64 à cause de l'architecture machine et peut également adopter d’autres modèles comme LP64 et I32LP64 à travers Cygwin. (Un autre exemple Solaris utilise LP64 et I32LP64).

Quant à GNU/Linux 64 bits, il aurait pu utiliser le modèle LLP64. Rien ne les empêche de l’utiliser et ça pourrait avoir un certain avantage tel que la compatibilité/ portabilité, à noter que LP64 est le modèle utilisé sans dire imposé pour tout ce qui est de la famille Unix, à savoir Solaris, HP UX , Mac OS, BSD dont FreeBSD sur une architecture 64 bits .

Comme les modèles de données diffèrents d’un système d’exploitation à un autre, les pointeurs n’ont donc pas une taille fixe ; raison pour laquelle je suis d’accord avec @Bousk sur le fait qu’il faut utiliser soit un intptr_t ou std::uintptr_t pour ne plus se soucier de la taille des pointeurs. Au passage, il a été mis à disposition un ensemble de types entiers dont les définitions sont cohérentes d'une machine à l'autre et indépendantes des systèmes d'exploitation et autres particularités d'implémentation. Il définit, via des typedef, des types entiers de différentes tailles ce qui permet une portabilité des applications entre les plates-formes.

Donc rien n’est figé et dédié à un système d’exploitation ou station de travail donnée si l’on maîtrise des compilateurs avec lesquels on maîtrise le 32/64 bits.

À bientôt,

[Médinoc]

Le modèle n'est pas dédié à un système d'exploitation, mais les fabricants de chaque système d'exploitation ont choisi un modèle et s'y tiennent.
Windows est en LLP64 pas seulement parce que le compilo Microsoft est réglé ainsi, mais parce que l'API Windows est exposée et documentée selon ce modèle. Quant à Cygwin, c'est plus une couche de compatibilité qu'un simple compilateur; pratiquement un système dans le système.

à noter que LP64 est le modèle utilisé sans dire imposé pour tout ce qui est de la famille Unix, à savoir Solaris, HP UX , Mac OS, BSD dont FreeBSD sur une architecture 64 bits .

C'est bien ce que disait fœtus, même s'il le formulait mal.

[Sve@r]

Bonjour

mais on peut toujours faire du sale comme ceci : float valeur; int* pointeur = (float*) &valeur; et à ce moment là il y a incohérence entre le type supposé et le type réel de l'objet pointé).

Je pense que tu as salement écrit ton sale (est-ce que "non sale" = "propre" ? ). A mon avis, pour faire ce que je crois que tu tentes de faire, tu aurais dû écrire float valeur; int* pointeur = (int*) &valeur;...

[Bktero]

En fait les 2 bouts de code étaient faux... J'ai corrigé.