Discussion :

[Uther]

La raison de l'utilisation du C le plus utilisé , c'est que c'est le langage le plus utilisé par les étudiants voila l'explication

Et s'il est tant appris par les étudiant c'est aussi parce qu’il est historiquement très utilisé dans l'industrie particulièrement pour tout ce qui touche au bas niveau et à l'UNIX.

Faire des calculs 32 bits sur du 8/16 bits te prendra forcément beaucoup plus de temps que de faire un calcul sur 8 bits

Dans l'exemple que tu cites, c'est en effet plus rapide. Mais ça ne sera pas forcément vrai dans tous les cas. Il y a par exemple sur certains processeurs des opérations plus rapides avec des opérandes de taille plus petites que le mot habituel.
Si tu veux vraiment te soucier d'optimiser au mieux ton programme il vaut beaucoup mieux être sur de la taille de chacun de tes types et adapter au cas par cas si l'optimisation du compilateur ne suffit pas.

Par contre les types de taille variable peuvent donner de gros problèmes de fiabilité lors du portage. Dans ton exemple où tu recompiles directement en 8/16 bit du code conçu pour du 32 bit qui utilise "int" , le risque est énorme. Tu peux te retrouver avec des erreurs dues à des débordements dans du code qui marchait pourtant très bien en 32 bit. Avant de se soucier d'avoir un code rapide, il faut se soucier d'avoir un code qui marche.

[Kannagi]

Exact , comme le MIPS qui gère facilement les 32 bits mais est plus lent sur les 8/16 bits.
Mais dans le fond cela revient au même , le int est un indice pour le programmeur de la taille du registre optimal
Et faire du i32 ne permettra jamais au compilo de savoir si tu as besoin que de 16 bits ou non sauf s'il est devin (ou qu'il exécute ton code dans tout les cas possible est regarde si y'a un débordement , ce que ne fait aucun compilateur , parce que cela voudrait dire que le compilateur à un émulateur intégrer :p )

Par contre les types de taille variable peuvent donner de gros problèmes de fiabilité lors du portage. Dans ton exemple où tu recompiles directement en 8/16 bit du code conçu pour du 32 bit qui utilise "int" , le risque est énorme. Tu peux te retrouver avec des erreurs dues à des débordements dans du code qui marchait pourtant très bien en 32 bit. Avant de se soucier d'avoir un code rapide, il faut se soucier d'avoir un code qui marche.

Ce n'est pas un souci , si tu veux absolument du 32 bits , alors il existe stdint , (qui utilisera le long ou long long pour définir des tailles plus grande que le int en général).

Mais ce n'est pas un souci du C , mais bien du programmeur qui ferait l'erreur de penser que int = 32 bits

[Uther]

Exact , comme le MIPS qui gère facilement les 32 bits mais est plus lent sur les 8/16 bits.
Mais dans le fond cela revient au même , le int est un indice pour le programmeur de la taille du registre optimal

Sauf que justement non, int ne garantit pas que le registre est optimal. Mais surtout comme sa taille n'est pas déterminé, on n'est pas sur qu'il fonctionnera correctement si on change d'architecture. La priorité de la portabilité c'est quand même que ça marche.

Ce n'est pas un souci , si tu veux absolument du 32 bits , alors il existe stdint , (qui utilisera le long ou long long pour définir des tailles plus grande que le int en général).

En effet et si tu veux des types généralement optimaux mais qui respectent quand même la taille minimale dont tu as besoin, tu les as aussi dans stdint (int_fastXX_t), ce qui est bien plus portable que d'utiliser directement int/short/long...

[jopopmk]

Oyoy, c'est moi ou l'article est plus proche d'un comparaison entre CLang et C2Lang (compilo) qu'entre C et C2 (langages) ?

Sinon j'ai rien contre la multitude de langages, c'est comme les religions, chacun fait ce qu'il veut
Perso ce C2 j'achète pas. J'ai quelques idées en tête que j'aimerais voir arriver en C, mais rien que le C2 me propose.

[Bktero]

Sauf que justement non, int ne garantit pas que le registre est optimal. Mais surtout comme sa taille n'est pas déterminé, on n'est pas sur qu'il fonctionnera correctement si on change d'architecture. La priorité de la portabilité c'est quand même que ça marche.

'int' n'est-il pas censé être le type de la taille naturelle du processeur ? 32 bits sur un proc 32 bits, 16 sur 16 bits, etc. 'int' n'est-il pas censé être donc le type le plus rapide, celui qui se met facilement dans le registre, celui qui se lit en RAM sans avoir besoin de masque décalage ou de risquer des accès non alignés ?

En effet et si tu veux des types généralement optimaux mais qui respectent quand même la taille minimale dont tu as besoin, tu les as aussi dans stdint (int_fastXX_t), ce qui est bien plus portable que d'utiliser directement int/short/long...

J'avoue que ces types sont complètement ignorés (y compris par moi, alors que je sais très bien qu'il existe et qu'ils sont portables...)

[Uther]

'int' n'est-il pas censé être le type de la taille naturelle du processeur ? 32 bits sur un proc 32 bits, 16 sur 16 bits, etc. 'int' n'est-il pas censé être donc le type le plus rapide, celui qui se met facilement dans le registre, celui qui se lit en RAM sans avoir besoin de masque décalage ou de risquer des accès non alignés ?

La notion de "taille naturelle du processeur" est subjective. Par exemple sur l'architecture x86_64, le "int" fait généralement 32 bit. Cela s'explique parce que ça simplifiait les portages et que certaines opérations sont quand même plus rapides en 32 bit, même si ça ne parait pas naturel.

Utiliser "int" est souvent optimal, mais ça n'est pas garanti par la norme. Le choix de la taille par défaut des types primitifs est assez libre et chaque compilateur peux faire ses choix en fonction de ses priorités entre compatibilité, rapidité et logique. Par exemple, "long" ne fait pas la même taille avec MSVC (32 bits) et GCC ou Clang (64 bits).

[mister3957]

Y'a un truc que je ne comprends pas, c'est que le C ou le C++ n'ont pas de gestionnaire de paquets.

En Java il y a Maven, .Net a NuGet, NodeJS a NPM, Python a PIP etc. et rien pour C/C++.

Pour moi si il doit y avoir une évolution dans l'écosystème C/C++ c'est pas "pouvoir programmer plus vite", mais un gestionnaire de paquets pour maîtriser les versions, les déploiement, les dépendances etc.

Il y a eu quelques projets pour ça, mais flop. Est-ce que c'est parce que ce n'est pas suivi / supporté ? Ou des contraintes particulières ?

[ternel]

Pour le gestionnaire de paquets officiel, c'est directement lié au fait que ces deux langages sont définis par une norme, et non une implémentation de référence.

De fait, il y a plusieurs fournisseurs officiels de compilateurs, et aucun ne peut prétendre être plus "officiel" que les autres.

[koyosama]

Y'a un truc que je ne comprends pas, c'est que le C ou le C++ n'ont pas de gestionnaire de paquets.

En Java il y a Maven, .Net a NuGet, NodeJS a NPM, Python a PIP etc. et rien pour C/C++.

Pour moi si il doit y avoir une évolution dans l'écosystème C/C++ c'est pas "pouvoir programmer plus vite", mais un gestionnaire de paquets pour maîtriser les versions, les déploiement, les dépendances etc.

Il y a eu quelques projets pour ça, mais flop. Est-ce que c'est parce que ce n'est pas suivi / supporté ? Ou des contraintes particulières ?

Si ils en ont, mais ils sont pas aussi utilisé que dans les autres languages. Et surtout certains gestionnaires de paquets sont un peu difficile à utiliser, le gestionnaire de paquets Linux et homebrew sur Mac par exemple sont des gestionnaires de paquets pour C et C++. Ce n'est pas aussi flagrant, mais c'est à toi de te démerder pour les incorporer dans ton projets. Généralement ils sont tous dans /usr/local/include ... enfin normalement.

Sous Windows tu peux aussi le faire mais tu devras utiliser chocolatey ou autre.

Ubuntu travailler sur snappy, ou si tu veux snap pour faire des sortes de conteneurs comme sur docker ou les packages java, ou encore npm pour pouvoir isolé les dépendances.
Les packages de libs C existe depuis bien des lustres, d'ailleurs ou des choses que t'apprend en cours. Après des lib C, j'en ai plein sur mon homebrew tous les jours qui se mettent à jour. Paquet de ci, de ça, des fois cela me tente de faire du C ou C++ juste pour ça.

[CaptainDangeax]

Boujour à tous.

C'est très bien de supprimer les types int, float, char et tout le toutim. J'ai un PC sous Linux, quand je fais du C, int c'est 32 bits et float, 64. Puis après, je fais du C sur µcontrolleur Atmel ou PIC, et selon que c'est un PIC16, PIC18 ou PIC24, la taille du int n'est pas la même. Alors, redéfinir les types avec un truc BIEN CLAIR où l'on a la taille en bits, je suis pour. Par contre, ça fait ENCORE un enfant de C ; on a déjà C++, C#, D et maintenant C2... Quelle dispersion !

[Matthieu76]

J'ai un PC sous Linux, quand je fais du C, int c'est 32 bits et float, 64.

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 ?

[Invité]

Alors, redéfinir les types avec un truc BIEN CLAIR où l'on a la taille en bits, je suis pour.

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

[Uther]

Y'a un truc que je ne comprends pas, c'est que le C ou le C++ n'ont pas de gestionnaire de paquets.

Il y a selon moi plusieurs raisons à ça, aucune n'est rédhibitoire, mais mises ensemble, elles expliquent que les gestionnaires de paquets ont eu du mal a prendre.

Comme dit ternel, il n'y a pas de référence absolue, ce qui complexifie l’émergence d'une solution standard acceptée par tous. Ceci dit, ça n'est pas impossible de dépasser ça non plus : Maven n'a pas été créé par Sun/Oracle, il me semble que c'est également le cas de NuGet.

Le fait que C/C++ ne supporte pas clairement la notion de module (et même pas les namespaces dans le cas de C) ne simplifie pas les chose non plus. On peut faire avec mais ça n'est pas aussi simple que dans certains langages.

Enfin, ça reste subjectif et difficile a mesurer, mais je pense qu'il y a aussi en partie la force de l'habitude. C et C++ sont des langages qui ont une longue histoire et pas mal d'usage dans des domaines qui apprécient la stabilité. Les développeurs sont assez ancrés dans leurs habitudes et ils sont général assez méfiant des nouveau principes, à l'opposé des utilisateurs de certains langages (JavaScript typiquement) qui ont tendance à tout essayer, quitte à s’éparpiller dans tous les sens.

Pour moi si il doit y avoir une évolution dans l'écosystème C/C++ c'est pas "pouvoir programmer plus vite", mais un gestionnaire de paquets pour maîtriser les versions, les déploiement, les dépendances etc.

En effet mais le fait que le C2 gère les modules va dans le sens de simplifier la mise en place de tout ça.

[frfancha]

Y'a un truc que je ne comprends pas, c'est que le C ou le C++ n'ont pas de gestionnaire de paquets.
En Java il y a Maven, .Net a NuGet, NodeJS a NPM, Python a PIP etc. et rien pour C/C++.

Ben c'est simple, Java, C#, Javascript et Python sont interpretés (via machine virtuelle pour Java et C#), C pas.
Utiliser des paquets en c impliquerait de recompiler du code sur ta machine avec toutes les erreurs et difficultés.

D'un autre côté on peut aussi dire que le C vient avec un paquet gigantesque et naturel: les API de l'OS...

[Uther]

Ce n'est pas insurmontable non plus. Le langage Rust a un système de paquets intégré qui marche parfaitement bien en les recompilant.

[frfancha]

Ce n'est pas insurmontable non plus. Le langage Rust a un système de paquets intégré qui marche parfaitement bien en les recompilant.

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

[Matthieu76]

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

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.

[Médinoc]

int_fast32_t est un typedef introduit en C99 ou C11, qui signifie "le type entier signé d'au moins 32 bits le plus rapide à gérer pour l'architecture ciblée". En gros, selon différentes architectures 64 bits, ce typedef vaudra int32_t ou int64_t.


Edit:
Je ne saisis pas la logique de l'argument "Les systèmes embarqués sont programmés en C, donc C2 est plus approprié que C++." Quel rapport? C2 semble avoir encore moins de compatibilité avec les codes source C que C++, et vu qu'il est compilé directement sur LLVM plutôt que transpilé en C, il n'a pas non plus de "lien spécial" au C par rapport à C++!

[Matthieu76]

En gros, selon différentes architectures 64 bits, ce typedef vaudra int32_t ou int64_t.

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 ?

[Invité]

Y'a un truc que je ne comprends pas, c'est que le C ou le C++ n'ont pas de gestionnaire de paquets.

En Java il y a Maven, .Net a NuGet, NodeJS a NPM, Python a PIP etc. et rien pour C/C++.

Pour moi si il doit y avoir une évolution dans l'écosystème C/C++ c'est pas "pouvoir programmer plus vite", mais un gestionnaire de paquets pour maîtriser les versions, les déploiement, les dépendances etc.

Il y a eu quelques projets pour ça, mais flop. Est-ce que c'est parce que ce n'est pas suivi / supporté ? Ou des contraintes particulières ?

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 ?

Sinon, je ne connais pas trop mais il y a aussi conan et meson qui commencent à être assez utilisables.