Bonjour à tous,
Plus j'avance plus je me dis que la bibliothèque standard du C sert à rien à part pour des "Hello World!". Qu'en pensez-vous ?
Cordialement.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Que peut-on faire avec la bibliothèque standard du C ?
Bonjour à tous,
Plus j'avance plus je me dis que la bibliothèque standard du C sert à rien à part pour des "Hello World!". Qu'en pensez-vous ?
Cordialement.
Je n'ai pas compris. Tu veux dire que la bibliothèque standard du C ne sert à rien d'autre qu'à écrire des petits programmes qui ne servent à rien ? C'est que tu ne connaisses alors pas encore assez le C.
Pas cool de mettre mes compétences en C sur le tapis! Tu réussis à faire quelque chose de plus poussé qu'une calculatrice seulement avec la libc toi? Sous UNIX tout est fichier, c'est beau, c'est bien mais sur d'autres systèmes si tu comptes seulement sur la libc tu vas t'amuser! Ne serait-ce que les threads ne sont pas gérés par la libc donc j'ai un peu exagéré en parlant de petits programmes mais le principe est là! Le réseau n'est pas non plus intégré à la libc. Lorsque que tu veux exploiter correctement le système sur lequel ton programme tourne tu dois te tourner vers autre chose, les fonctions du système lui même. (Win32/POSIX etc...). C'est pour cela que je dis que la libc ne sert pas à grand chose. Si tu veux créer une application portable basée sur la libc, c'est possible, tant que ton appli ne dépasse pas le stade de la calculatrice!
Je ne mets pas tes compétences C sur le tapis. Tu es sans doute compétent, sinon tu ne te serais pas posé toutes ces questions. Tu n'as par contre pas encore assez d'expérience, de ton propre aveu, et c'est pour cela que tu es venu nous voir. Alors, j'essaie juste de te corriger lorsqu'il le faut.Pas cool de mettre mes compétences en C sur le tapis!
Ok. Voici quelques idées d'applications 100% portables que tu peux réaliser en C standard :Tu réussis à faire quelque chose de plus poussé qu'une calculatrice seulement avec la libc toi?
- des outils de développement : compilateurs, interpréteurs, assembleurs, etc.
- des outils de traitement de données :
--- traitement de l'information : algorithmes de compression, de chiffrement, de déchiffrement, etc.
--- manipulation de fichiers : convertisseurs de fichiers (wav <-> wma <-> mp3 <-> etc., bmp <-> jpg <-> gif <-> png <-> etc., divx <-> flv <-> mp4 <-> etc., ...), logiciels de compression (déjà évoqué plus haut), parseurs (parseurs de xml, gestionnaires de fichiers de conf, ...), etc.
--- exploitation de données : des sgbd (systèmes de gestion de bases de données), des dictionnaires, des traducteurs, etc.
- des logiciels de calcul scientifique (du genre matlab, R, etc.)
- des applications ludiques (jeux)
- des interfaces logiciel-matériel (contrôle de périphérique, accès à des ressources physiques, etc.)
Je peux étendre la liste si ces exemples ne te suffisent pas.
Euh, généralement ça, c'est tout sauf standard.- des interfaces logiciel-matériel (contrôle de périphérique, accès à des ressources physiques, etc.)
Pour le reste, je suis d'accord avec toi
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Si tu réussis à faire tout çà avec des applis un minimum potables qui ne mettent pas 10 000 ans à faire une seule opération avec un seul thread, je veux que tu me donnes des cours de prog! Le pire c'est que tu as osé mettre un IDE dans tes exemples alors que je suis en train d'en développé un en ce moment! Ton prix sera le mienEnvoyé par Melem
Ouai sauf que la on parles SUS/POSIX et non libc
- Sur la portabilité : dis-moi ce qui m'empêcherait de réaliser de telles applis de manière 100% portable, avec seulement la lib C. Quelle fonctionnalité me manquerait-il ?Si tu réussis à faire tout çà avec des applis un minimum potables qui ne mettent pas 10 000 ans à faire une seule opération avec un seul thread, je veux que tu me donnes des cours de prog! Le pire c'est que tu as osé mettre un IDE dans tes exemples alors que je suis en train d'en développé un en ce moment! Ton prix sera le mien
- Sur la performance : pourquoi ça mettrait 10 000 ans à faire une seule opération ? Le C est un langage compact qui génère du code très performant. Si le C ne peut pas le faire, quel langage le ferait alors ? Je te fais remarquer que toutes les applis que j'ai cité ci-dessus en plus ont déjà existé à l'époque du DOS et des processeurs 16 bits (à part certains convertisseurs de fichiers parce que le format n'existait même pas encore à l'époque ...) et ça ne mettait pas 10 000 ans à faire une opération. On peut faire ces applis en C standard ET avec des performances très élevées ! C'est pour ça que le C a été créé ...
- Sur les threads : les threads servent surtout à faire autre chose pendant qu'une opération bloquante est également en cours. Multithreader son application n'augmente pas du tout les performances. Tout au contraire, ça décroît les performances. Si tu voulais parler de parallélisation, oui, ça permet d'accroître les peroformances lorsque l'algorithme est parallélisable. Mais va voir un programmeur VB6 par exemple et demande-lui s'il utilise la parallélisation dans ses applications. Ses applis tournent-elles à raison de 10 000 ans / opération ? Alors pourquoi un programme C tournerait moins vite ?
Donc content qu'on soit d'accord, la libc sert à rendre des applis portables tant qu'elles restent basiques
On est donc obligé d'utiliser des threads pour que ton appli soit utilisable ou non? CQFD
PS : Sous DOS, une tache a TOUT le système pour elle lorsqu'elle s'exécute, jusqu'à ce qu'elle se termine. Avec un proc actuel 32 ou 64 bits et avec rien que 4 GIGA de ram à disposition, rajoute moi un GPU et au diable les threads, je te programme un méga jeux 6D!
Et au fait, utiliser une interface graphique ne veut aucunement dire que tu fais du multithread! Windows interromps ton thread pour appeler une fonction du même THREAD (en général), pour que son message puisse être traité DANS LE MEME THREAD aucun context switch autre que pour les appels système et aucun thread n'est généré. Techniquement tu restes dans ton winmain mais tu es juste dans la proc que tu as fourni pour la gestion des messages. Il est tout à fait possible de maintenir une appli graphique sans utiliser de threads.
pour la deuxième fois, Je ne me permettrai pas de remettre tes compétences ou ton expérience en doute mais j'ai l'impression que tu as tendance à me prendre de haut parce que j'en ai moins que toi! (Ou peut-être parce que je pose des questions?). Si tel est le cas tu devrais éviter ce genre de préjugé parce que qu'un jour malheureusement tu risques de tomber sur quelqu'un qui ne s'est peut-être pas lancé dans la programmation même dès le départ, mais qui a attendu d'avoir une excellente connaissance de son environnement de travail et même préférer faire de l'admin système, pas mal de débogages et hacks (dans le vrai sens du terme) et même quelques stages en réseau avant de toucher au moindre compilo. Je ne déballerai pas ma vie, ce n'est pas mon genre, et j'avoues qu'il est fort probable que je n'ai pas autant d'expérience que toi dans le monde du travail, mais saches que je ne débarques pas non plus!
Cordialement.
- Premièrement, où est-ce que tu as vu que j'ai dit qu'on peut écrire un IDE de la monstruosité de Visual Studio avec la bibliothèque standard du C seulement ?Dis moi comment tu réussis à créer un IDE comme visual studio qui vas vérifier et résoudre les macros dans tous les headers, sauvegarder les fichiers nécessaire, mettre à jour le GUI, tenir à jour les modifs faites dans ton fichier par rapport à l'original et compiler ou debugger ton code tout en te permettant de taper 2 lettres d'affilé sans attendre 5 secondes? Là tu m'étonnes sérieux! Sur un simple fichier c'est encore supportable mais sur un gros projet de 100 voir 1000 headers de 20000 lignes chaqu'un + ton code source de 50 modules si tu utilises les threads seulement pour une raison de blocage bonne chance!
- Deuxièmement, l'utilisation des threads dans ton exemple correspond bien au cas que j'ai évoqué où il est intéressant d'utiliser les threads : on ne va pas attendre la fin du pasring des headers avant de pouvoir faire autre chose = > thread. On ne va pas attendre la fin de la compilation pour pouvoir faire autre chose => process ou thread. A quoi servirait par contre les threads dans les exemples d'applications que j'ai citées ? Turbo C fonctionnait bien sous dos sans multithreading, zip et unzip fonctionnaient bien sous dos sans multithreading, oracle et dbase fonctionnaient bien sous dos sans multithreading, matlab fonctionnait bien sous dos sans multithreading, tu veux d'autres exemples ? La raison pour laquelle on a besoin de multithreading dans un logiciel comme visual studio c'est-à-cause de l'interface graphique : On veut que l'interface graphique soit utilisable pendant qu'une autre opération se déroule en tâche de fond, pas parce qu'un gros logiciel a systématiquement besoin d'être multithreadé.
Tu ne sais vraiment pas de quoi tu parles.Ps : pour les opérations bloquante les entrées/sorties asynchrone existent et les threads sont toujours le plus utilisées!
Dis moi comment tu réussis à créer un IDE comme visual studio qui vas vérifier et résoudre les macros dans tous les headers ou la bdd, sauvegarder les fichiers nécessaire, mettre à jour le GUI, tenir à jour les modifs faites dans ton fichier par rapport à l'original, faire un truc genre intellisense et compiler ou debugger ton code tout en te permettant de taper 2 lettres d'affilé sans attendre 5 secondes et avec un programme qui tourne de façon linéaire, monothread? Là tu m'étonnes sérieux! Sur un simple fichier c'est encore supportable mais sur un gros projet de 100 voir 1000 headers de 20000 lignes chaqu'un + ton code source de 50 modules si tu utilises les threads seulement pour une raison d'opération bloquante bonne chance!
Ps : pour les opérations bloquante les entrées/sorties asynchrone existent et les threads sont toujours le plus utilisées!
Ton "sous Unix tout est fichier", il me fait bien marrer quand je vois que chaque object de synchronisation utilise une fonction d'attente différente (sem_wait / semop, mq_wait, wait/waitpid, etc.).
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Il faut reconnaître les limites de la bibliothèque standard du C
En comparaison avec d'autres langages (par exemple Java), la bibliothèque standard C de la norme ISO est minuscule. Elle fournit un jeu élémentaire de fonctions mathématiques, de manipulation de chaînes de caractères, de conversion de types, et d'entrée/sortie maniant les fichiers et les terminaux. Elle n'inclut pas de base standard de « types de conteneurs » comme le fait la Bibliothèque de Modèles Standard C++ (Standard Template Library) du langage C++). Elle laisse de côté les interfaces graphiques (Graphical User Interface, abr. GUI), les outils réseau, les fonctions de synchronisation entre tâches, et la profusion d'autres fonctionnalités que Java fournit en standard. L'avantage principal d'une petite bibliothèque standard est qu'il est beaucoup plus facile de fournir un environnement fonctionnel pour C ISO que pour les autres langages, et le portage d'applications en langage C vers de nouvelles plateformes est donc relativement rapide.
Cependant Affirmation grave
Cher Baccali, je pense que c'est une affirmation grave et minimaliste sur une langue qui a fait ses preuves depuis de longues années et qui est la base de beaucoup de langages aujourd'hui!
Vous haïssez le C à ce point pour le banaliser de la sorte!
Il est vrai que la bibliothèque standard du C est l'une des plus "compactes" mais comme on le dit souvent: "petit marteau casse grand cailloux"... seulement il faut savoir comment l'attraper, c'est à dire comment l'utiliser.
Pour certains cette "compacité" est un atout pour d'autres c'est un défaut mais ceux qui savent s'en servir font des exploits avec!
Répondre avec citation
Partager