Les versions successives des standards peuvent réduire les zones "troubles" parce qu'il y a une convergence qui se fait petit à petit sur les architectures matérielles. Il faut voir que le C avant 1989, ça devait marcher sur un 286 (avec de l'adressage en segment:offset), sur des microcontrôleurs genre PIC16 (architecture 12 bits), et sans doute sur plein d'autres trucs obscurs (machines à pile, microcontrôleurs avec un seul ou deux registres, architecture mémoire avec des banques, représentation des nombres signés autrement que par le complément a 2, exceptions matérielles en cas d'overflow ou de division par 0 ou pas, ...)
Tous ces trucs pas définis ou définis par l'implémentation viennent de là. Il en reste encore aujourd'hui, par exemple un microcontrôleur assez populaire qui se programme en C est le MSP430: pointeurs sur 20 bits, mais registres sur 16, et du coup c'est une des architectures ou size_t ne fait pas la même taille que void*.
Le C, comme le C++, sont avant tout des langages conçus pour la programmation système. C'est à dire des trucs bien bas niveau, directement aux prises avec le matériel. Ils ont aussi trouvé un marché dans tous les machins où la performance est critique.
Pour le reste, il est effectivement beaucoup plus malin de prendre un langage qui garantit un environnement d'exécution identique, quel que soit le CPU en dessous. C'est le cas de Java, par exemple, qui a repris en gros la syntaxe du C (avec des objets) mais spécifié systématiquement tous les comportements. Et aujourd'hui il y a plusieurs autres choix dans ce domaine. Mais ça n'empêche qu'on a toujours besoin d'un langage qui puisse s'adapter au matériel et aux outils utilisés, pour tout ce qui est bas niveau. Et non, tout faire en assembleur n'est pas une option raisonnable :)
[^] # Re: Comme les dieux l'ont voulu
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal CamelCase ou lowercase_with_underscore. Évalué à 5.
Les versions successives des standards peuvent réduire les zones "troubles" parce qu'il y a une convergence qui se fait petit à petit sur les architectures matérielles. Il faut voir que le C avant 1989, ça devait marcher sur un 286 (avec de l'adressage en segment:offset), sur des microcontrôleurs genre PIC16 (architecture 12 bits), et sans doute sur plein d'autres trucs obscurs (machines à pile, microcontrôleurs avec un seul ou deux registres, architecture mémoire avec des banques, représentation des nombres signés autrement que par le complément a 2, exceptions matérielles en cas d'overflow ou de division par 0 ou pas, ...)
Tous ces trucs pas définis ou définis par l'implémentation viennent de là. Il en reste encore aujourd'hui, par exemple un microcontrôleur assez populaire qui se programme en C est le MSP430: pointeurs sur 20 bits, mais registres sur 16, et du coup c'est une des architectures ou size_t ne fait pas la même taille que void*.
Le C, comme le C++, sont avant tout des langages conçus pour la programmation système. C'est à dire des trucs bien bas niveau, directement aux prises avec le matériel. Ils ont aussi trouvé un marché dans tous les machins où la performance est critique.
Pour le reste, il est effectivement beaucoup plus malin de prendre un langage qui garantit un environnement d'exécution identique, quel que soit le CPU en dessous. C'est le cas de Java, par exemple, qui a repris en gros la syntaxe du C (avec des objets) mais spécifié systématiquement tous les comportements. Et aujourd'hui il y a plusieurs autres choix dans ce domaine. Mais ça n'empêche qu'on a toujours besoin d'un langage qui puisse s'adapter au matériel et aux outils utilisés, pour tout ce qui est bas niveau. Et non, tout faire en assembleur n'est pas une option raisonnable :)