Sur TA machine, un int est codé sur 4 octets. Pourquoi ne pas essayer: sizeof(char) sizeof(short) peu utilisé sizeof(int) sizeof(float) sizeof(long long) sizeof(double) sizeof(char *) pointeur vers un char sizeof(n'importe quel type *) Crée-toi des structures et utilises sizeof() pour en savoir la longueur. ...
C'est simplement que dans la norme (annexe E), INT_MAX est défini à +32767, ce qui tient sur 2 octets. 2 octets est donc la taille minimale d'un int suivant la norme.
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
2 octets, c'est sur les machines d'autrefois. C'est un cours ancien ?
Non, pourquoi ? Je travaille sur du matériel récent sur lequel un entier fait 16 bits.
Je pense que la définition de l'entier est d'abord liée au matériel. Si la définition a la vie dure est probablement dû au fait que, même de nos jours, les applications avec des processeur 16 ou 32 bits n'ont pas tout à fait disparues. Ce qui motive suffisamment pour essayer de conserver une bonne rétrocompatibilité.
C'est pourquoi les définitions sont généralement du genre : "Au moins X octets" et que TYPE_MAX reste prudent en appliquant un "qui peut le plus peut le moins".
Pas uniquement au matériel mais aussi suivant les OS qui ont un data model différent y compris sur les mêmes proc →
rétrocompatibilité au détriment de portabilité. Mais c'est aussi pour cela que la norme introduit des alias de types imposant une largeur (pour les plateformes sur lesquelles on peut le faire).
On peut maintenant choisir via les stdint un intN_t où N peut valoir 8,16,32 ou 64 (avec d'autres alias pour d'autres contraintes comme le signe, …).
Il faut aussi savoir qu'un int peut-être de 64 bits mais d'un seul octet (c'est plutôt peu commode, mais la norme l'autorise).
- Edité par markand il y a 16 minutes
Quand je vois qu'il y a 4 normes 64 bits (j'ai déjà été emmerdé par cela dans le passé), je fulmine que tous ces gars ne se soient pas mis d'accord. On va se trimbaler des boulets à vie à cause de leurs conneries....
Quand je vois qu'il y a 4 normes 64 bits (j'ai déjà été emmerdé par cela dans le passé), je fulmine que tous ces gars ne se soient pas mis d'accord. On va se trimbaler des boulets à vie à cause de leurs conneries....
Et du char signé ou non signé par défaut on en parle ?
git is great because Linus did it, mercurial is better because he didn't.
Quand je vois qu'il y a 4 normes 64 bits (j'ai déjà été emmerdé par cela dans le passé), je fulmine que tous ces gars ne se soient pas mis d'accord. On va se trimbaler des boulets à vie à cause de leurs conneries....
Et du char signé ou non signé par défaut on en parle ?
Alors si je ne dis pas de conneries (mais reprend moi si c'est le cas), les char signés/non signés datent de ... oula... l'ère préhistorique non ?
Une époque ou on débutait quelque chose, et on ne savait pas du tout ce que ça allait donner. Si j'ai raison, je trouve ça pardonnable. On se traîne des boulets, ça a des conséquences, mais on ne pouvait pas tellement anticiper.
par contre, les normes LP64, LLP64 etc .... La on savait très bien qu'en en créant plusieurs, on allait au devant d'un bordel pour la portabilité car on avait déjà pas mal de recul en programmation pour connaître tout un tas de soucis de portabilité, et le fait que quelque chose d'équerre est largement plus simple à maintenir.
C'est pour cela qu'on été introduit les stdint (→ dans la norme)… si on a besoin d'entiers de taille déterminée. Un problème similaire est apparu a la création des wchar … et on a eu droit aux uchar. Et c'est clair que c'est un peu un plat de nouilles les histoires d'encodage.
On pouvait anticiper les problèmes, encore fallait-il le vouloir.
La normalisation du langage C a été tardive. Elle a constitué essentiellement à sauvegarder les interêts des membres du comité de normalisation (marchands de compilateurs !), en légalisant ce que les compilateurs existants faisaient déjà.
Et en cas de divergences : "dépendant de l'implémentation" ou, quand c'est impossible : "comportement indéfini".
Donc il ne fallait pas compter dessus pour choisir un jeu de caractères (ascii/ebcdic), ou une représentation des nombres. Déja, dire si les char sont signés ou pas...
On s'est bien amusés avec, mais il est grand temps d'arrêter de développer en C.
- Edité par michelbillaud 15 novembre 2022 à 7:53:50
On s'est bien amusés avec, mais il est grand temps d'arrêter de développer en C.
Tu n'as pas tort que le C est vieillissant, mais je ne peux m'empêcher de penser à cette page, qui dit combien d'énergie nécessite un programme, selon les différents langages.
Et dans une période ou l'énergie devient le nerf de la guerre, je me demande si on ne va pas faire volte face un jour par rapport à ce qu'on fait aujourd'hui : du gaspillage totale de mémoire, de la complexité à installer des machines virtuelles, et tout ça....
Alors après bien sur, par rapport à ce que pompe un écran, ce que consomme un programme c'est que dalle aussi...
Bonsoir, et pour afficher les valeurs des 4 octets qui le constituent en bases 10 et en bases 16 sans tableau comment fait-on ? en C
- Edité par fbbfoizebjiofzeujiof il y a environ 13 heures
Le plus simple ? à mon avis :
#include <stdio.h>
int main()
{
int a=-4096;
printf("%08X", a);
return 0;
}
michelbillaud a écrit:
[...]
Donc il ne fallait pas compter dessus pour choisir un jeu de caractères (ascii/ebcdic), ou une représentation des nombres. Déja, dire si les char sont signés ou pas...
[…]
C'est compliqué … un héritage vieux de 50 ans et tout ça … Mais il y a des progrès. Le principal étant externe : unicode. Mais le principal reste le choix fait par la plateforme cible sur lequel aucun standard n'a d'influence.
michelbillaud a écrit:
[…]
On s'est bien amusés avec, mais il est grand temps d'arrêter de développer en C.
- Edité par michelbillaud il y a environ 1 heure
À nouveau oui … mais c'est une question d'héritage et tout ça. Il est temps (et cette tendance est bien engagée) de ne plus utiliser C pour de nouveaux projets mais arrêter de développer en C est sans doute un vœu pieux.
On s'est bien amusés avec, mais il est grand temps d'arrêter de développer en C.
Tu n'as pas tort que le C est vieillissant, mais je ne peux m'empêcher de penser à cette page, qui dit combien d'énergie nécessite un programme, selon les différents langages.
Et dans une période ou l'énergie devient le nerf de la guerre, je me demande si on ne va pas faire volte face un jour par rapport à ce qu'on fait aujourd'hui : du gaspillage totale de mémoire, de la complexité à installer des machines virtuelles, et tout ça....
Alors après bien sur, par rapport à ce que pompe un écran, ce que consomme un programme c'est que dalle aussi...
- Edité par Fvirtman il y a environ 4 heures
Je ne pense pas que la comparaison de savoir quel langage coûte le plus cher en énergie pour faire tourner hello world soit pertinente !
Déjà, y a rien qui va : on ne compare pas des langages, mais des programmes écrits dans ces langages, dans une certaine implémentation.
Et c'est pas parce que M. Michu va faire tourner son petit programme python 3 fois chez lui que ça va faire une différence supérieure à epsilon. Il y a des chances que les compilations et recompilations + l'usage de son IDE (qui passe son temps à recompiler à la volée pour détecter les erreurs) aient coûté beaucoup plus cher pour développer la même chose en C. Si on veut faire le bilan énérgétique...
Ca me parait un truc bidon, une distraction qui tenterait par exemple de faire oublier que les cryptomonnaies, les blockchains à la mode etc sont basées sur la consommation effrénée d'énergie pour "miner" des trucs (dont la valeur est liée au fait qu'il faut faire beaucoup de calculs pour les produire).
Et puis c'est pas le principal problème aujourd'hui. On commence à se rendre compte que les trucs programmés avec des langages de cowboy sans vérification de mémoire, ça pose un énorme problème de sécurité, allant jusqu'à la sécurité nationale dans un contexte international où certains acteurs hostiles se font un plaisir d'exploiter les failles, qui permettent de paralyser l'infrastructure économique d'un pays.
- Edité par michelbillaud 15 novembre 2022 à 13:09:58
Est-ce qu'une solution ne serait pas de créer une nouvelle version de C "mieux", et qui ne cherche pas à être compatible avec les anciennes ? Comme le Python 3 par rapport au Python 2 ?
Il parait qu'il existe environ 800 milliards de lignes de code en Cobol dans le monde. Alors passons en Cobol ... Et on peut programmer en imbécile dans n'importe quel langage, même en C++
Le Tout est souvent plus grand que la somme de ses parties.
Cobol est un langage de niche (programmes de gestion), étonnamment bien conçu pour l'époque. Une grosse niche, mais une niche quand même, et c'est rarement un bon choix pour faire autre chose (c'est pas avec ça qu'on va réécrire OpenSSL !)
> Et on peut programmer en imbécile dans n'importe quel langage, même en C++
on va pas mettre ne doute les compétences et la conscience professionnelle des programmeurs C/C++. On constate juste que ce sont ces langages qui posent le plus de problèmes, parce qu'ils sont spécialement piégeux, y compris pour des pros qualifiés. Et apparemment, c'est pas remédiable, d'où la recommandation de la NSA (et pas que).
> Est-ce qu'une solution ne serait pas de créer une nouvelle version de C "mieux"
Une solution à quel problème ? En vue, il y a
maintenance évolutive (et corrective) des projets existants en C
recyclage des programmeurs C qui ont toujours programmé en C et qu'il n'y avait pas de problème et c'est pas maintenant que je vais changer à 10 ans de la retraite
Il y a déjà d'autres langages qui conviennent pour ça. Le hic: on peut rapidement avoir l'impression (fausse) de savoir programmer en C parce que c'est un langage apparemment simple. Les autres langages (Rust par exemple), l'apprentissage est plus raide. On n'a rien sans rien. Par exemple, personne n'imaginerait une initiation à la programmation qui commencerait par Rust comme premier langage.
- Edité par michelbillaud 15 novembre 2022 à 16:29:58
Le langage C est un langage intéressant pour certains besoins (voir par exemple lien donné par Fvirtman).
Il y a plein de gens qui ont appris à programmer en C.
Mais il y a des soucis, par exemple les 'char' qui sont signés ou pas, qui sont de l'ASCII ou de l'Unicode, les 'int' qui font 4 octets ou pas, etc. Ces soucis ont été expliqués plus haut (sauvegarder les intérêts de membres des comités de normalisation, etc.)
Michelbillaud : tu dis qu'il y a d'autres langages pour ça. Ben oui mais je trouve que ce serait plus simple de ne pas changer de langage. C'est juste mon avis. J'aimerais bien un "C en mieux", ce qui nécessite de casser la compatibilité avec les programmes existants. En Python, ils l'ont fait. (Je me doute que personne ne suivra mon avis, c'est juste pour discuter (et espérer qu'on me dise : c'est en train de se faire...))
Je laisse les professionnels de C++ dire si ils ont envie d'adopter un truc de ce genre. On veut bien changer, mais à condition que ça reste pareil ? :-)
- Edité par michelbillaud 15 novembre 2022 à 17:51:39
J'ai programmé longtemps en C et j'aime beaucoup le C. Mais j'ai récemment apris plus ou moins en parallèle le Python et le C++ Je constate que je code toujours mon C à la manière de C et C++ ou Python d'une toute autre façon.
- Edité par PierrotLeFou 15 novembre 2022 à 18:06:29
Le Tout est souvent plus grand que la somme de ses parties.
Liens utiles pour le C++
Le Tout est souvent plus grand que la somme de ses parties.
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Bonhomme !! | Jeu de plateforme : Prototype.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
git is great because Linus did it, mercurial is better because he didn't.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
git is great because Linus did it, mercurial is better because he didn't.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Le Tout est souvent plus grand que la somme de ses parties.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.