Je n'affirme pas péremptoirement qu'une telle architecture 64 bits existe (ou est utilisée de manière courante), mais c'est la théorie.
Et la même chose s'applique à des types comme int_fast16_t (qui selon l'architecture pourrait être 16, 32 ou 64 bits) etc.
À mon avis, ce n'est pas tant sur les coûts de conversion qu'on gagne, que sur les coûts de décalage (pour les contraintes d'aligmenent -- par exemple, imagine un int16_t à l'adresse 0x10006; une architecture 64 bits peut avoir besoin de lire toute la zone de 0x10000 à 0x10007, puis décaler la valeur lue de 24 bits).
En effet le Rust a beau ne pas être normalisé comme le C++, une de ses grande force est qu'il ne dispose pas de comportement volontairement indéfini dans son fonctionnement de base. Mais il autorise cependant des blocs "unsafe" qui permettent de s'extraire de certaine de ces règles strictes si besoin (assembleur inline, interfacage avec C, appel systèmes, ...), ce qui fait que les application Rust ne sont pas forcément totalement portables.
A l'inverse, C et C++ sont standardisés mais leur spécification laisse beaucoup de liberté aux implémenteurs, ce qui rend l'écriture de code portable, plus complexe, mais pas impossible pour autant. De nombreuses bibliothèques sont tout a fait portable et pourraient se retrouver facilement accessibles dans un dépot.
Ces types ne font qu'une seule chose : employer le type que le compilateur trouve de manière générale le plus efficace et qui fait au moins la taille demandée. Ils ne remplaceront pas toutes les optimisations faites par -Ofast.
Par exemple les processeurs x86 et x86_64 les opérations sur les registres 32bit sont généralement aussi rapide, voire plus rapides qu'avec des registres de taille inférieures (pour des raison techniques que je ne maitrise pas). Donc les types int_fast8_t à int_fast32_t devraient tous être sur 32 bit (bien que je n'aie pas vérifié). Par contre int_fast64_t fera bien 64 bit, même si ce n'est pas la taille optimale.
Ce genre de chose n'est pas une règle stricte et ça dépend vraiment des processeur et des opérations effectuées. Il peut arriver en effet que des types plus petits soient paradoxalement plus lent a traiter, mais l'inverse est possible aussi.
Par exemples sur x86_64, qui est pourtant considéré comme un processeur 64 bit, les multiplications et les divisions sont plus rapides en 32 bit.
La portabilité. Ta solution certes assez simple, mais spécifique à ton Linux. C'est lourd de devoir multiplier l'effort de créer et maintenir un package par le nombre de distributions, sans compter les OS qui n'ont pas ce genre de système.
C'est disponible depuis C99
Le but du C est d'être adaptable à beaucoup de processeurs, des plus classiques comme x86 aux plus exotiques. Pour cela, la norme laisse beaucoup de libertés, que beaucoup voient comme des flous artistiques. C'est voulu. Ce n'est pas à l'avantage du développeur sur une plateforme donnée mais c'est à l'avantage des gens qui écrivent des compilateurs. Il est possible qu'il existe des plateformes où tous les types intxx_fast_t fassent 64 bits. On gagne souvent le temps d'accès au bus car le processeur pourra lire une donnée de 64 bits avec une instruction simple alors qu'une donnée en 32 bits pourra demander en plus des masques et/ou des décalages.
Pour exemple, voici un code C :
Et voici son assembleur obtenu pour un processeur ARM (avec gcc7 en -O1 sur le site https://godbolt.org/):
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17 #include <stddef.h> #include <stdint.h> extern int16_t fixed[2]; extern int_fast16_t fast[2]; long get_fixed(size_t i) { return fixed[i]; } long get_fast(size_t i) { return fast[i]; } int main() { return sizeof fast[0]; }
C'est un processeur 32 bits. Le main te montre qu'il retourne 4 (placé dans le registre r0) donc sizeof int_fast16_t est 4. Si tu compares l'assembleur des 2 fonctions, tu vois qu'il y a deux instructions (lsl = logical shift left et ldrsh = load sign half word) pour la première alors qu'il n'y en a qu'un (ldr = load word) pour la seconde. On voit ainsi que les 2 types ne sont pas traités pareil, cela peut mené à des différences de performances.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 get_fixed(unsigned int): ldr r3, .L3 lsl r0, r0, #1 ldrsh r0, [r3, r0] bx lr .L3: .word fixed get_fast(unsigned int): ldr r3, .L6 ldr r0, [r3, r0, lsl #2] bx lr .L6: .word fast main: mov r0, #4 bx lr
La portabilité n'implique pas que le fait que le projet a les bonnes bibliothèques et/ ou cadriciels, mais aussi les bonnes version de ces derniers
Et ensuite tu as des cas assez complexes comme par exemple, du code (souvent du code maison) qui se retrouve dans X projets et que ce code évolue : comment mettre à jour les X projets avec le moins de risques de casses possibles ?
Ben si on a des distributions avec des logithèques, c'est justement pour avoir un ensemble de lib dans des versions compatibles. Et les gestionnaires comme pip ou npm ne sont pas parfaits non plus car on se retrouve à devoir trouver des versions compatibles entre elles, ce que font justement les mainteneurs de distribs pour les libs c/c++.
Oh mon dieu quel problème insurmontable ! Ah bah non en fait, il suffit de régler l'option CMAKE_INSTALL_PREFIX avec un dossier local et d'exporter deux variables d'environnement.
Bah justement, c'est encore plus facile : il suffit d'inclure ta dépendance comme submodule git (tu peux même spécifier la version ou le commit) et tu peux importer le cmake du submodule dans celui de ton projet principal. Et à utiliser c'est simplissime : git clone --recursive puis cmake puis make et voila.
Bon, je vais ajouter mon grain de sel à cette discussion
J'ai rapidement survolé la doc de C2lang et je trouve le langage plutôt sympa :
- Les types dont nous connaissons les plages permettent de faciliter la sérialisation (en partant du principe qu'on respecte toujours le même endianness).
- Le langage propose un paradigme objet léger avec les "struct functions", je suis preneur.
- L'idée des modules me plait, je suppose que cela permet implicitement de pouvoir utiliser un type qu'on ne déclarera que plus tard dans le code.
À vu d'oeil, ce qui manque dans C2lang, c'est un concept léger de generics/template.
Ce qui me dérange surtout avec le C, ce n'est pas le langage en lui-même mais les outils avec lesquels on l'utilise, et je pointe du doigt son manque de gestionnaire de paquet comme l'a remonté @mister3957 .
@ternel , un outil comme Maven n'est pas "officiel" (il n'est pas fournit par Sun/Oracle, il est géré par la fondation Apache) et c'est pourtant la référence dans l'univers Java, idem avec npm pour l'univers NodeJS. Pourquoi n'a-t-on pas de gestionnaire de paquet en C (et C++) ? Pourquoi est-ce que l'univers du C (et C++) n'a pas un projet :
- Qui permet via une architecture prédéfinie d'avoir un répertoire pour écrire son code, un répertoire pour écrire ses tests unitaires, un répertoire pour générer son build, un répertoire pour récupérer les libs du gestionnaire de paquet, et bien sur un fichier statique de gestion à la racine pour déclarer ses dépendances.
- D'utilitaire qui via de simples commandes permet de gérer le cycle de vie du projet.
- Qui possède un repository distant contenant les dépendances compilés (c'est-à-dire les linkers et librairies ".a" , ".dll" etc) de chaque projet, en fonction de l'OS, du compilateur, de l'architecture 32bits/64bits que nous pourrions indiquer dans le fichier statique de gestion.
- Qui possède un repository distant contenant le mirror du code source de chaque projet et gérant les linkers, en fonction de l'OS, du compilateur, de l'architecture 32bits/64bits que nous pourrions indiquer dans le fichier statique de gestion.
Derrière le C tu as quand même de beaux gros projets comme Linux, git, PostgreSQL, SQLite. Et puis même dans les projets C++ tu te rends comptes qu'une partie est codé en C. On n'entend pas beaucoup parler du langage C parce que les entreprises ne s'engagent pas à le promouvoir, mais même si on pense qu'il n'est plus d'actualité on l'utilise toujours, il suffit de voir Google coder son propre OS fuschia en C.
Derrière chaque langage très répandu tu as une grande entreprise (en tant que créateur ou utilisateur interne) :
- COBOL et SQL : IBM
- C et C++ : AT&T Bell Laboratories
- Java : Sun/Oracle
- C# et VB : Microsoft
- Objective-C et Swift : Apple
- Go : Google
- JS : Les fournisseurs de navigateur (Microsoft, Google, Apple, Mozilla etc)
D et C2lang restent des langages de garage à coté :/
En effet, avoir des outils de build portables simplifie les choses, mais ça ne va pas jusqu'au bout de la chaine. Si tu veux distribuer ta bibliothèque sur plusieurs distributions, il te faudra un ou plusieurs packages deb, rpm, ... que tu devra faire ajouter aux dépôts des différentes distributions que tu veux supporter. En dehors de Linux, c'est encore un autre problème, vu que l'OS n'a généralement pas d'outil de distribution standard qui résolve les dépendances.
L’intérêt de npm, maven, ... c'est que tu n'as qu'un seul dépôt, que tu gères toi même, et qui sauf cas particulier marchera directement pour tous les OS.
Tous les outils du genre que je connais savent bien sur gérer les dépendances en prenant en compte les numéros de version compatibles. C'est le minimum qu'on attend de ces outils.
Je ne connais pas suffisamment npm et pip , ce sont peut être des exceptions, mais ça me surprendrait quand même beaucoup.
Oui, tu n'as qu'un seul dépôt... enfin un seul pour js, un seul pour python, idem pour ruby, rust... et pas vraiment en fait, car avec python tu as pip mais aussi conda et en js tu peux passer par npm mais aussi bower et ....
Quant au "ça marche pour tous les OS", déjà c'est pas toujours le cas et ensuite ça implique souvent des builds très génériques avec compilation non-optimisée pour ton système et duplication des dépendances (genre plusieurs versions d'un même paquet voire plusieurs copies de la même version). Sans parler que généralement il faut passer par un système d'environnement virtuel tellement il y a de risques de conflits sinon...
En effet, le système des dépôt par langage est surtout pratique pour les distributeurs de bibliothèque vu qu'il ont un contrôle total sur leur dépôt. Alors que les dépots gérés pour la distribution sont en théorie plus pratiques pour l'utilisateur, surtout si l'on doit mélanger les langages.
Le problème c'est que à l'usage, j'ai très régulièrement des problèmes de bibliothèques qui me manquent, ou pas disponibles dans la version dont j'ai besoin. Le principe de laisser chaque distribution gérer ses package a ses limites. Une distribution ne peux tout simplement pas gérer toutes les bibliothèques possibles, c'est un travail trop énorme. En permettant aux auteurs de bibliothèque de gérer ça eux même, on a bien moins de soucis.
Certes mais c'est des problèmes qui ne sont pas spécifiques aux gestionnaires de paquets par langages.
Bien évidement que si ta bibliothèque n'est pas faite pour gérer le multiplateforme ou n'est pas optimisée pour ça il n'y aura pas de miracle. Par contre une fois que tu l'as packagé en respectant la structure standard, elle devrait pouvoir s'installer sans problème.
Voici l'exemple 5 lignes contre 6
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 #include <stdio.h> int main(int argc, char* argv[]){ printf("Hello Word\n"); return 0; }
Va falloir détailler un peu ton argumentation car je peux aussi écrire des phrases (ou des lignes de code) sans jamais retourner à la ligne et ainsi obtenir moins de ligne qu'un autre.
Ce n'est pas le nombre de ligne que je ciblais dans mon commentaire mais la verbosité.
Et hop 2 lignes contre 6 !
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 #include <stdio.h> int main(int argc, char* argv[]){printf("Hello Word\n");return 0;}
Je pense pas que le nombre de mot clé a taper ait la moindre incidence sur la vitesse de codage : on passe généralement bien plus de temps a lire et réfléchir au code qu'à le taper.
Avoir un code clair et bien structuré fait gagner bien plus de temps que les fractions de secondes utilisées a saisir des mots clé.
Je me permets d'apporter un commentaire de débutant C/C++.
En premier lieu, tout nouveau langage candidat qui apporte une nouvelle variante est un élément supplémentaire de confusion. Le C (et je pense qu'il en est de même de tous les langages à leur création) était problématique parce que diverses branches voisines se ressemblaient mais n'étaient pas totalement compatibles. Une des forces majeures d'un langage est sa standardisation, permettant un apprentissage unique, une documentation cohérente et des soutiens convergents, une expérience cumulative.
C est déclaré "vieillissant mais incontournable" de ci, de là. Je ne comprends pas.
De ma lorgnette, il est facile de programmer les applications dévolues au C avec un sous-ensemble de C++, donc sans avoir à apprendre tous les concepts de C++ (soit dit en passant, ce serait une action positive d'expliciter ce C++-- comme noyau élémentaire de C++).
On profite de quelques caractéristiques de C++, comme le typage (donc débogage facilité), les strings (même si on n'a pas vraiment à savoir ce qu'est la techno. objet), le type bool (dont la modestie n'en apporte pas moins une meilleure lisibilité du code), et j'en passe. On peut trouver quelques points qui grattent un peu (par exemple les casts, peut-être les cout/cin?).
En ce qui concerne les programmes de bas niveau, je ne peux pas être catégorique en ce qui concerne la prise en compte de contraintes matérielles, mais reste persuadé que ce C++-- devrait permettre les mêmes choses, avec des performances équivalentes au C (que ce soit en C, C2 ou C++, le programmeur doit avoir une prescience du fonctionnement du compilateur).
Personnellement, n'ayant pas le temps d'apprendre 36 langages (même si j'ai cotoyé de l'octal, de l'assembleur, du Fortran, du Pascal) je me limite au C++ ISO (pour l'instant je me limite à C++11).
Avant d'avoir l'expérience de divers langages, il est impossible de faire un choix raisonné entre deux langages voisins. Je m'offusque donc a priori de cette nouvelle variante syntaxique, même si "ce langage [..] devrait être facile à apprendre pour les programmeurs en C".
NON. Justement il est très long d'acquérir des réflexes sur des règles syntaxiques (les ',' ';" '{}' '||' etc...). qui se ressemblent mais sont différentes à la marge.
Si C2 apporte des concepts intéressants dans la chaîne de compilation/build (je ne peux en juger), alors il serait plus utile de contribuer à une évolution du C++.
Salut je suis un fan de C et C++ ( l'embarqué) et j'aimerais que vous me proposer des sites sur lesquels je pourrai apprendre le C2. MERCI
Là n'est pas ce que je veux dire pour afficher un "Hello World" on a besoin que de l'import de la bibliothèque stdio.h or dans l'exemple fourni avec le C2 on a une déclaration de module(que je ne connais pas) et un import de bibliothèque je pense un message et un return alors qu'en C un include un affichage et un return.
Ceci étant dit je pense que ce langage n'a pas lieu d'être on a vu plusieurs langages dérivés du C et apporter d'autres paradigmes de programmation mais aucun n'a su le remplacer.
Un autre paradigme, un nouveau concept peut être discutable mais la version amélioré du C reste C++
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager