64 bits et C++

En même temps, pour une fois que le language suit exactement la sémantique... on va pas râler...

Un char est un caractère.
Un short est un entier-court.
Un int un entier.
Un long un entier long.

Point barre.

Maintenant, pour lire/écrire des données, personne ne devrait utiliser ces types. Comme décrit précédemment, tous les compilos proposent des types de longeur fixe.
Si on veut lire un entier codé sur 4 octets, on utilise un int32, jamais un int !
Et une taille de fichier ca ne renvoit jamais un long, mais un unsigned int64 ! :D

Citation:

---

Envoyé par doccpu

Et ?

---

C'est loin de couvrir tout ce qui existe.

Citation:

---

Donc il faudrais peut etre voir a reviser le sois disant "standard" qui ne l'est pas puisqu'il n'y a alors plus de taille fixe (a par peut etre le char (8bit)).

---

Le char fait au moins 8 bits. J'ai déjà signalé que j'ai utilisé une implémentation de C avec un char de 9 bits. Et sur cette architecture, imposer un char de 8 bits aurait été tout à fait stupide.

Citation:

---

Je suis dans le traitement de signal audio et si la norme est telle que vous la decrivez je ne pourais jamais passer en 64bit puisque nous on travaille sur des long de 32 bit, et que si ce parametre change d'une implementation a l'autre on aura des tailles d'echantillons variables d'un processeur a l'autre on vas avoir des surprises en mode 64 bit dans le traitement.

---

Windows est à ma connaissance le seul endroit où les long font 32 bits avec un processeur 64 bits. Pour autant que je le sache, Unix et les mainframe d'IBM utilisent des long de 64 bits.

Citation:

---

et desolé d'avoir trollé mais le standard est lui même trop laid !

---

Si tu veux du Java ou du C#, tu sais où les trouver.

Citation:

---

Le jour ou j'apprend l'assembleur je refais tout les standards et l'informatique sera beaucoup plus stable !

---

Apprend plusieurs assembleurs, il y a moins de variété d'autrefois, mais toujours plus que tu n'as l'air de le penser.

Citation:

---

Envoyé par doccpu

donc si je fais

Code:

---

char* c = new char[x];

---

je n'obtiendrais pas 8 * x bits dans mon tableau ?

---

Sur les processeurs adressables par octets (où chaque octet a une adresse), c'est bien le comportement que tu vas optenir.

Sur les processeurs adressables par byte mais avec des bytes de longueur autre qu'un octet... je n'en connais pas qui ont une implémentation du C ou du C++; et ceux que je connais avaient des bytes de 6 bits. On ne peut alors faire une implémentation conforme pour eux en utilisant un byte == un char.

Sur des processeurs adressables par mot, on a le choix. Soit faire un char=un mot et alors tes chars font plus que 8 bits. Soit utiliser pour char* une paire adresse, byte dans le mot. Alors tes char auront comme taille un diviseur de la taille du mot (il y a eu des machines comme cela avec des mots de 12, 16, 18, 24, 32, 36, 48, 60 bits).

Citation:

---

Envoyé par JolyLoic

C'est justement pour assurer une portabilité que les tailles des différents types peuvent varier d'un compilateur à l'autre, d'un environnement à l'autre.

---

La portabilité aurait été bien meilleure avec des tailles fixes. Mais l'utilisabilité sur des architectures qui étaient alors loin d'être exotiques (pour rappel, il fut un temps ou sur Arpanet les machines 36 bits étaient les plus nombreuses) n'aurait pas été bonne ni d'un point de vue performance, ni d'un point de vue interopératibilité avec les autres programmes faits pour ces environnements.

Citation:

---

Envoyé par nicroman

En même temps, pour une fois que le language suit exactement la sémantique... on va pas râler...

Un char est un caractère.

---

euh ? ASCII, ANSI, UTF8, UTF16, ISO, ....?

Citation:

---

Envoyé par nicroman

[...]
Maintenant, pour lire/écrire des données, personne ne devrait utiliser ces types. Comme décrit précédemment, tous les compilos proposent des types de longeur fixe.
Si on veut lire un entier codé sur 4 octets, on utilise un int32, jamais un int !
Et une taille de fichier ca ne renvoit jamais un long, mais un unsigned int64 ! :D

---

Allez expliquer ca a nos profs de lycées ainsi que Bjarne Stroustrup (le createur du C++) qui nous apprennent en premier lieux que le char represente 256 valeurs et est codé sur 8 bits, et nous apprennent a utiliser tous les "types intrinseques" du C++(char, short, int, long, long long, float, double et long double) sans faire la moindre allusion aux types fixes (int8, int16, int32, int64 et int128).(Je ne connait pas les correspondances fixes pour les flotants)
Enfin changer les regles en cours de route n'est jamais bon en programation :)

Citation:

---

Envoyé par Jean-Marc.Bourguet

Si tu veux du Java ou du C#, tu sais où les trouver.

---

merci j'en vien,

Citation:

---

Envoyé par Jean-Marc.Bourguet

Apprend plusieurs assembleurs, il y a moins de variété d'autrefois, mais toujours plus que tu n'as l'air de le penser.

---

-intel(cisc)
-motorola (microcontroleur risc)
-Spark (sun si je ne m'abuse)

Quoi d'autre ? (je ne compte ni les microcontroleurs de calculettes, ni les processeurs de consoles dediés, ni les microcontroleurs de telephones portables, ni les microcontroleurs d'automates programables genre siemens, shneider ou télémecanique).

Classiques :
- Intel x86 - du 186 au C2D, avec toutes les variantes -
- AMD64
- Itanium
- PowerPC
"Moins" classiques :
- 68000
- la série des SPARCs
- ...
DSP :
- TIs
- ADs
- ...
Et là, ce sont des processeurs couremment utilisés et j'en oublie pas mal.

Citation:

---

Envoyé par doccpu

euh ? ASCII, ANSI, UTF8, UTF16, ISO, ....?

---

C'est non spécifié. La conception date d'avant les jeux larges (Unicode, JIS, ...) et donc char ne convient généralement pas pour eux, mais dans un système où c'est adapté, rien n'empècherait de le faire. Pour les systèmes où char ne convient pas pour les jeux larges, il y a wchar_t.

Citation:

---

Allez expliquer ca a nos profs de lycées

---

Je ne fais pas confiance à un prof de lycée pour m'expliquer le C++.

Citation:

---

ainsi que Bjarne Stroustrup (le createur du C++) qui nous apprennent en premier lieux que le char represente 256 valeurs et est codé sur 8 bits,

---

Référence? Je doute fortement que BS ait jamais indiqué que char faisait dans toutes les implémentations 8 bits avec 256 valeurs. J'ai par exemple

Citation:

---

Envoyé par The C++ Programming Language, 2nd Edition, p 50

The integer type char is the most suitable for holding and manipulating characters on a given computer; it is typically an 8-bit byte.

---

C'est moi qui ai mis typically en gras, ce mot indique bien qu'autre chose est possible (en connaissant l'importance des PDP-10 au moment de la conception du C et du C++, ce n'est pas étonnant). Tiens, sur la même page on a

Citation:

---

This is what is guaranteed about sizes of fundamental types:

1 == sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)
sizeof(float) <= sizeof(double) <= sizeof(long double)
sizeof(I) == sizeof(signed I) == sizeof(unsigned I)

where I can be char, short, int or long. In addition, it is guaranteed that a char has at least 8 bits, a short at least 16 bits and a long at least 32 bits... assuming more is hazardous.

---

Citation:

---

Envoyé par doccpu

et nous apprennent a utiliser tous les "types intrinseques" du C++(char, short, int, long, long long, float, double et long double) sans faire la moindre allusion aux types fixes (int8, int16, int32, int64 et int128).

---

Ces types fixes ne sont pas standards. Il est de bonne pratique d'en définir si on a besoin de taille fixe. Il est vraissemblable que la prochaine version du C++ aura les types de taille fixe introduits en C99 (int8_t, int_least_8_t , int_fast_8_t, etc -- j'ai un doute sur l'orthographe de ces derniers)

Citation:

---

Envoyé par doccpu

merci j'en vien,



-intel(cisc)
-motorola (microcontroleur risc)
-Spark (sun si je ne m'abuse)

Quoi d'autre ?

---

Comme processeur encore vendu? Commencons par l'architecture la plus ancienne: Unisys continue a vendre sa série 2200, un descendant de la série Univac 1100, machine 36 bits, adressable par mot, complément à 1. Une des bêtes encore vendue les plus étranges d'après les critères actuels.

Dans le genre ancêtre, on a aussi les descendant de l'IBM 360 (je ne me retrouve pas dans la nomenclature actuelle d'IBM). C'est l'architecture qui a établit le standard d'utiliser des machines adressables par byte avec des bytes de 8 bits.

Intel doit encore vendre au moins trois lignes architecturales à usage général: x86 et ia64.

Dans les processeurs RISC, on a POWER, Sparc, MIPS, ARM qui continuent à être développé. PA-RISC et Alpha sont sur la pente descendante, ou même au-dela.

Mais si on cherche de la variété, il faut aller voir dans les DSP. On y trouve toujours des machines dont le modèle diffère de celui établit par l'IBM 360, en particulier de l'adressage par mot et des tailles qui ne sont pas dans la série 8, 16, 32, 64.

Citation:

---

(je ne compte ni les microcontroleurs de calculettes, ni les processeurs de consoles dediés, ni les microcontroleurs de telephones portables, ni les microcontroleurs d'automates programables genre siemens, shneider ou télémecanique).

---

On peut avoir une idée de pourquoi?

Aprés ce petit intermede (musical ?), je rebondi sur 2 messages intéressants évoqués dans les toutes premières pages du post.

Citation:

---

Envoyé par outs

D'un autre coté on en avait pas vraiment besoin avant vu que ce n'est que récement que l'on peut acheter plus de 4Go de mémoire pour un prix raisonnable.

---

Trop cher = j'en ai pas besoin.
Pas cher = j'en ai besoin.

Etrange comme équation ... tu ne confondrais pas besoin et envie ?

Citation:

---

Envoyé par SuperCed

Le 64 bits sert dans 2 cas :
- performances lorsqu'on travaille sur de très grands entiers
(relativement rare)
- besoin d'adresser plus de 4 Go de RAM à un seul processus.

---

4Go c'est énorme en tant que tel. Qui aura besoin d'avoir autant de place mémoire ? Un DVD ok ça fait bien 6Go, mais qu'il soit stocké entièrement en mémoire ou sur disque, le traitement vidéo il prendra le même temps. Donc du coup pour l'utilisateur aucun gain.

Avoir beaucoup en RAM principale, je ne vois guerre d'utilité que pour certains traitements calculs mathématiques demandant beaucoup de "déploiement" mémoire.

Pour le tout un chacun, un Pentium 3 à plus d'1GHz ou un Athlon équivalent suffit pour une utilisation standard. Donc du 64bts, c'est bien pour des personnes qui ont besoin d'espace mémoire et de vitesse -> les professionnels.

Citation:

---

Envoyé par mchk0123

4Go c'est énorme en tant que tel. Qui aura besoin d'avoir autant de place mémoire ? Un DVD ok ça fait bien 6Go, mais qu'il soit stocké entièrement en mémoire ou sur disque, le traitement vidéo il prendra le même temps.

---

Le montage video est la seule application "personnelle" que je vois utiliser autant de memoire.

Les applications professionnelles par contre... j'ai un collegue qui est en relation directe avec des clients -- et donc travaille sur leurs donnees -- qui se plaint de ne pas avoir de machine disponible avec plus de 64 Go de memoire.

Le montage audio aussi peut être à la limite des 4Go, avec une tonne de samples chargés en mémoire, la limite peut être très vite atteinte :(

Je serais tenté de dire qu'en temps qu'usage privé, faire du montage vidéo sur des vidéos RAW (ie. non préalablement encodées) c'est du suicide :kill:

La bonne pratique étant d'encoder l'ensemble des prises de vues, puis de faire du montage de samples ensuite. Le format AVI est pil-poil adapté à ce genre de manipulations (pas besoin de ré-encoder pour faire du montage).

Pour un usage professionnel en montage vidéo ça se comprendrais mieux.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Je ne fais pas confiance à un prof de lycée pour m'expliquer le C++.

---

Pour la plupart t'a bin raison. Il y à cependant quelques exceptions après le bac.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Référence? Je doute fortement que BS ait jamais indiqué que char faisait dans toutes les implémentations 8 bits avec 256 valeurs.

---

Dans "Guide du développeur C/C++" de sa main, cela est écrit.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Ces types fixes ne sont pas standards. Il est de bonne pratique d'en définir si on a besoin de taille fixe. Il est vraissemblable que la prochaine version du C++ aura les types de taille fixe introduits en C99 (int8_t, int_least_8_t , int_fast_8_t, etc -- j'ai un doute sur l'orthographe de ces derniers)

---

1) Ils ne sont pas standards donc documenté nulle part.
2) Où est-ce donc dit ?
3) Il serais temps que se soit fais !

Citation:

---

Envoyé par Jean-Marc.Bourguet

Comme processeur encore vendu? Commencons par l'architecture la plus ancienne: Unisys continue a vendre sa série 2200, un descendant de la série Univac 1100, machine 36 bits, adressable par mot, complément à 1. Une des bêtes encore vendue les plus étranges d'après les critères actuels.

Dans le genre ancêtre, on a aussi les descendant de l'IBM 360 (je ne me retrouve pas dans la nomenclature actuelle d'IBM). C'est l'architecture qui a établit le standard d'utiliser des machines adressables par byte avec des bytes de 8 bits.

Intel doit encore vendre au moins trois lignes architecturales à usage général: x86 et ia64.

Dans les processeurs RISC, on a POWER, Sparc, MIPS, ARM qui continuent à être développé. PA-RISC et Alpha sont sur la pente descendante, ou même au-dela.

Mais si on cherche de la variété, il faut aller voir dans les DSP. On y trouve toujours des machines dont le modèle diffère de celui établit par l'IBM 360, en particulier de l'adressage par mot et des tailles qui ne sont pas dans la série 8, 16, 32, 64.



On peut avoir une idée de pourquoi?

---

1) Je ne m'intéresse qu'aux processeurs que j'ai vu tourner sur des PC
2) YAKADMENDER je ne m'intéresse qu'aux processeurs pouvant supporter un OS complet. A vrais dire même les 680X0 me parraissent un peu limite mais ça n'engage que moi. En ce qui concernent les dsp je n'ai pas le niveau en math pour les gérer je laisse ça aux physiciens qui en ont plus besoins que moi.

Citation:

---

Envoyé par mchk0123

Trop cher = j'en ai pas besoin.
Pas cher = j'en ai besoin.

Etrange comme équation ... tu ne confondrais pas besoin et envie ?

...

Avoir beaucoup en RAM principale, je ne vois guerre d'utilité que pour certains traitements calculs mathématiques demandant beaucoup de "déploiement" mémoire.

---

1) Je dirais plutôt que notre ami est commercial ou ingénieur voir les 2. Un techno se fout de ce que cela coûte du moment que sa fonctionne bien.

2) tu a comparer les temps d'acces des 2 modes un support physique sera toujours énormément plus lent que de la ram donc quant tes traitements auront besoins d'aller y chercher une information ce sera plus vite fais en ram que sur un disque physique

Citation:

---

Envoyé par Jean-Marc.Bourguet

Le montage video est la seule application "personnelle" que je vois utiliser autant de memoire.

Les applications professionnelles par contre... j'ai un collegue qui est en relation directe avec des clients -- et donc travaille sur leurs donnees -- qui se plaint de ne pas avoir de machine disponible avec plus de 64 Go de memoire.

---

threading, traitement du son, de l'image, du signal en general, aquisition de données, traitement en temps reels, serveur de base de données, sans parler des jeux en 3D temps réels MMOG ...
plein de domaines seraient avantagé d'avoir plus de ram :)

Citation:

---

Envoyé par doccpu

threading, traitement du son, de l'image, du signal en general, aquisition de données, traitement en temps reels, serveur de base de données, sans parler des jeux en 3D temps réels MMOG ...
plein de domaines seraient avantagé d'avoir plus de ram :)

---

Les MMPORG n'ont pas besoin d'autant de mémoire, et encore heureux ! Tout comme le traitement du son, il ne faut pas exagérer ! (et serveur de base de données, ce n'est pas vraiment une application personnelle, traitement temps réels non plus)

Citation:

---

Les MMPORG n'ont pas besoin d'autant de mémoire, et encore heureux !

---

Les serveurs, si.