Discussion :

[CaptainDangeax]

Hein !? Mais quand tu as des int 32 bits, tes float sont aussi 32 bits ? Normalement, ce sont les double qui sont en 64 bits. Tu as dû modifier quelque chose pour avoir des float 64 bits, non ?

Vérification faite, c'est effectivement float=32bits. Sur µcontrolleur, c'est hyper important de savoir.

Genre ça http://en.cppreference.com/w/c/types/integer ?

Voilà, exactement !

[Médinoc]

Tu es en train de me dire qu'un int64_t serait plus rapide à calculer qu'un int32_t sur les architectures qui ne gère que le 64 bits ?
On gagne le temps de la conversion de 32 en 64 bits c'est ça ?

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).

[Uther]

Sans doute parce que Rust est suffisamment défini pour le résultat de la recompilation n dépende pas de la machine.

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.

Attends, What ??? C'est quoi un int_fast32_t quelqu'un peut m’expliquer ??? Ça existe aussi les les float_fast32_t ? Je suis choqué ! En gros ça revient au même que de compiler en -Ofast ? C'est cool, j'en apprend tous les jours en traînent ici.

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.

Tu es en train de me dire qu'un int64_t serait plus rapide à calculer qu'un int32_t sur les architectures qui ne gère que le 64 bits ?
On gagne le temps de la conversion de 32 en 64 bits c'est ça ?

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.

Pour utiliser une lib, je fais un apt-get, j'ajoute un #include dans le code et une ligne de cmake/pkg-config et c'est réglé. C'est quoi les merveilleuses fonctionnalités que npm/pip/etc... apportent de plus ?

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.

[Bktero]

int_fast32_t est un typedef introduit en C99 ou C11

C'est disponible depuis C99

Tu es en train de me dire qu'un int64_t serait plus rapide à calculer qu'un int32_t sur les architectures qui ne gère que le 64 bits ?
On gagne le temps de la conversion de 32 en 64 bits c'est ça ?

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 :

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];
}

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
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

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.

[Invité]

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.

Je n'ai pas testé tous les OS du monde mais avec cmake et pkg-config, ce n'est pas très difficile d'avoir une config de projet portable sur la plupart des linux et bsd (pour windows, je ne sais pas).

[foetus]

Je n'ai pas testé tous les OS du monde mais avec cmake et pkg-config, ce n'est pas très difficile d'avoir une config de projet portable sur la plupart des linux et bsd (pour windows, je ne sais pas).

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 ?

[Invité]

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

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++.

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 ?

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.

[foetus]

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.

Avec cmake peut-être tu es plus calé que moi. Mais regarde du côté de git lorsque tous tes projets sont versionnés

[Invité]

Avec cmake peut-être tu es plus calé que moi. Mais regarde du côté de git lorsque tous tes projets sont versionnés

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.

[Gugelhupf]

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é :/

[Uther]

Je n'ai pas testé tous les OS du monde mais avec cmake et pkg-config, ce n'est pas très difficile d'avoir une config de projet portable sur la plupart des linux et bsd (pour windows, je ne sais pas).

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.

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++.

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.

[Invité]

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...

[Uther]

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 ....

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.

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...

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.

[Taserface]

Je reste très sceptique...
Cela ne semble pas apporter grand chose, de plus quand je vois qu'ils annoncent 30% de gain de temps de codage alors que l'exemple hello world :

Code :

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

1
2
3
4
5
6
7
8
module hello_world;
 
import stdio as io;
 
func i32 main(i32 argc, char*[] argv) {
    io.printf("Hello World!\n");
    return 0;
}

Comporte plus de mot clé qu'un programme codé en C... On a envie de leur demander un compte rendu exhaustif de leurs tests...
Parce que personnellement je mettrai forcément plus de temps à écrire ce code que le même en C, c'est physique...

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;
}

[transgohan]

Voici l'exemple 5 lignes contre 6

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é.

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;}

Et hop 2 lignes contre 6 !

[Uther]

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é.

[Axel Mattauch]

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++.

[Matthieu76]

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.

Le typage, les types string et les types bool existe déjà en C. À vrai dire ce nouveau langage n'apporte aucun nouveau concept.

[TawalMc]

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

[Taserface]

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é.

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;}

Et hop 2 lignes contre 6 !

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++