C++ n'est rien d'autre qu'une spécification sur le langage. Il n'y a pas d'implémentation de référence ou quoi que ce soit. Il n'y a pas de moyen standard pour compiler et lancer un logiciel. Le langage ne dicte par exemple pas que ton système doit supporter les bibliothèques dynamiques, et tu a des systèmes ou ce n'est pas le cas. Tu à des systèmes ou ton implémentation de la norme C++ est incomplète (pas d'exception, par exemple).
À partir de ce moment là, tu à un gros problème à gérer, rien que pour compiler et lancer un logiciel sans dépendances. Il te faut un système de build bloaté pour supporter plusieurs systèmes, plusieurs compilos (avec des bugs divers et variés) les architectures éxotiques sans virgule flottante matérielle, les bibliothèques standard avec plus ou moins de lacunes (parfois causées simplement par les limitations matérielles), la cross compilation (greuh), et ne parlons pas des options de compilation.
En fait, tu te retrouve avec tout les problèmes qu'ont les systèmes de builds, les distributions et les gestionnaires de paquets avec les logiciels C depuis 20 ans. Et à ce que je sache, personne n'a pour l'instant résolu le problème pour Windows, ou il y a encore plus de segmentation avec les compilos Visual C++ incompatibles entre eux.
Alors oui, quand je dit que ça fait double emploi avec $PACKAGE_MANAGER, c'est que c'est vraiment le cas, puisque ça en est un.
La seule vraie solution à ce problème, ça serait une meta distribution générique qui s'intègre avec tout les OS qui existent. Or on sais très bien que ça va poser encore plus de problème que ça va n'en résoudre.
[^] # Re: le dilemme du dev
Posté par Batchyx . En réponse à la dépêche La bibliothèque SDL est sortie en version 2.0. Évalué à 7.
C++ n'est rien d'autre qu'une spécification sur le langage. Il n'y a pas d'implémentation de référence ou quoi que ce soit. Il n'y a pas de moyen standard pour compiler et lancer un logiciel. Le langage ne dicte par exemple pas que ton système doit supporter les bibliothèques dynamiques, et tu a des systèmes ou ce n'est pas le cas. Tu à des systèmes ou ton implémentation de la norme C++ est incomplète (pas d'exception, par exemple).
À partir de ce moment là, tu à un gros problème à gérer, rien que pour compiler et lancer un logiciel sans dépendances. Il te faut un système de build bloaté pour supporter plusieurs systèmes, plusieurs compilos (avec des bugs divers et variés) les architectures éxotiques sans virgule flottante matérielle, les bibliothèques standard avec plus ou moins de lacunes (parfois causées simplement par les limitations matérielles), la cross compilation (greuh), et ne parlons pas des options de compilation.
En fait, tu te retrouve avec tout les problèmes qu'ont les systèmes de builds, les distributions et les gestionnaires de paquets avec les logiciels C depuis 20 ans. Et à ce que je sache, personne n'a pour l'instant résolu le problème pour Windows, ou il y a encore plus de segmentation avec les compilos Visual C++ incompatibles entre eux.
Alors oui, quand je dit que ça fait double emploi avec
$PACKAGE_MANAGER, c'est que c'est vraiment le cas, puisque ça en est un.La seule vraie solution à ce problème, ça serait une meta distribution générique qui s'intègre avec tout les OS qui existent. Or on sais très bien que ça va poser encore plus de problème que ça va n'en résoudre.