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!
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.
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 ?
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!
- 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!
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.
Basique ou pas n'est pas le problème. Tu ne peux pas écrire un logiciel aussi basique que le bloc-notes avec seulement la bibliothèque standard du C, mais tu peux écrire un logiciel aussi complexe qu'un sgbd.Donc content qu'on soit d'accord, la libc sert à rendre des applis portables tant qu'elles restent basiques
Pas du tout. Je te demande de prendre un exemple d'application dans la liste que je t'ai fourni et de me dire pourquoi sans thread l'application mettrait 10 000 ans à faire une opération.On est donc obligé d'utiliser des threads pour que ton appli soit utilisable ou non?
Je n'ai pas compris ce que tu voulais dire par là. Moi ce que je voulais dire par contre c'est qu'on peut développer des applications complexes qui tournent bien même sur des processeurs 16 bits monocoeur sans hyperthreading cadencés à moins de 100 MHz et sans threads, et donc qui ne tourneraient pas plus mal sur nos machines actuelles. De nos jours, on a la possibilité de les de les doter d'interfaces graphiques, d'exploiter le multitâche, le multithreading et la parallélisation mais ça ne veut en aucun cas dire qu'une application monothreadée par exemple c'est systématiquement de la m**de. Et la question était peut-on réaliser des applications utiles et 100% portables avec seulement la bibliothèque standard du C, réponse : oui, pas "est-il possible de développer tous les types d'applications avec seulement la bibliothèque standard du C" ni "les applications écrites avec seulement la lib C sont-elles plus rapides que les applications qui exploitent d'autres bibliothèques en plus", réponse : non évidemment.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! çà fait plus de 10 ans qu'on est passé sur des systèmes préemptifs et tu cites encore ces exemples avec sérieu?
C'est difficile de se retrouver dans toutes ses discussions!
Si justement c'était çà ma question tu peux vérifier! Je demande quel est l'avantage à utiliser la libC plutôt que l'API Win32 et c'est pour çà que j'en ai conclut que tu peux faire ce que tu veux avec la libC mais tant qu'on en demande pas trop à son appli. Un sgbd sous Windows rien qu'avec la libC, avec un seul threadAutant travailler avec des fichiers textes car je pense que tout l'avantage d'un SGbd sera perdu!
Tu rigoles ou c'est de la mauvaise foie? Et l'IDE
Ce que j'ai voulut dire c'est que tu prends des IDE ou je ne sais quoi qui fonctionnaient sous DOS mais faut voir les conditions dans lesquelles elles faisaient leur boulot et ce qu'on attendait d'une application en ce temps là!
Maintenant je n'ai pas dit qu'une application avec un seul thread c'est à jeter. L'appli que j'utilise le plus c'est cmd.exe et je ne m'en plains pas! Mais que si tu veux faire une application poussée/correcte aujourd'hui, tu devras forcément revenir à l'API native, posix ou sus sous UNIX et Win32 sous Windows. à la différence que cette dernière n'inclut pas la libc dans ses standards. Donc je le répète ma question ce n'était pas "Que peut-on faire avec la libC", c'était "Que me conseillez vous d'utiliser" et la réponse que j'ai pour l'instant c'est "Tu n'y comprends tu ne sais pas de quoi tu parles! Tu peux faire ce que tu veux avec la libC, (ce qui déjà n'est pas vrai!) on s'en fout des performances ou quoi, ton appli sera portable ( ce dont je me fous un peu!)". Par contre j'en ai déduit que la libC avait ses avantages lorsque tu cherches de la portabilité mais puisque de toute façon la plupart du temps je serai obligé de revenir à l'API Native du système, autant prendre l'habitude de programmer avec de suite pour ne pas être perdu le moment venu! Mais je n'en utiliserai pas moins la libc et elle n'est pas descendu dans mon estime.
Ca, ça se passe ici. Ici, on parle des applications 100% portables utiles que l'on peut réaliser avec seulement la bibliothèque standard du C.
Ta logique est mauvaise baccali. Ce n'est pas parce que la libc n'offre pas les fonctions avancées que tu cherches, qu'elle ne sert à rien d'utile. En l'occurrence toutes les libs qui offrent des fonctionnalités avancées (comme la libpthread pour reprendre ton exemple) utilisent la libc.
La libc, c'est la gestion de la mémoire, c'est les I/O, c'est les manipulations de chaine... Toute choses dont personne ne peut se passer.
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!
Salut,
Là, il y a mauvaise foi manifeste, ça:
ce n'est pas la même chose que ça:
La portabilité va devenir de plus en plus incontournable avec les tablettes et les téléphones, sans parler des futurs besoins pas encore inventés, mais ils y a déjà des gens qui y pensent à comment nous y rendre accros.
C'est un dialogue de sourds. Tu parles de la forme alors que Melem te parles du fond. Un truc qui a besoin de ressources, un encodeur mp3 par exemple, ça s'écrit idéalement en C, pour les performances. Ensuite, on peut le mettre dans une DLL, lui mettre un bel emballage graphique en ce que tu veux et pourquoi pas l'API windows. Après, on peut croire que l'on programme l'API windows, mais le vrai travail est fait en C.
A+
Pfeuh
La libc est la base du C et comme son nom l'indique, c'est une base qui servira à faire d'autres choses. J'utilise en ce moment la libusb qui est écrite en C et je présume qu'elle utilise la libC.
On compare à Java ? On compare surtout la multitude de classes écrites avec Java (et non à la base de Java). Dans ce cas, parlons de toute les librairies disponibles pour faire du langage C !
La portabilité est compliquée ? Normal que ce soit plus difficile d'être portable quand on génère du code machine directement (et non du byte code pour une JVM, JVM qui ne doit pas facile à porter je pense).
+1
Code : Sélectionner tout - Visualiser dans une fenêtre à part Là, il y a mauvaise foi manifeste, ça
Resalut à tous,
j'arrive un peu tard mais comme le post date et que le dialogue original a été éclaté en plusieurs partie par Melem, j'ai eut du mal à tout suivre.
En fait dans mon message original je demandais quel était l'avantage d'utiliser la libc plutôt que l'API native du système sous-jacent.
D'où l'apparente mauvaise foi souligné par Pfeuh
Mais je ne minimise aucunement le C, c'est mon langage préféré et celui dans lequel je bosse exclusivement (quand je suis pas sous windev au boulot!). Tout ce que je disais, c'est que lorsqu'on n'a pas besoin de faire du code portable, il est souvent plus "efficace" d'utiliser l'API du système plutôt que la libc, pour peu qu'on sache ce que l'on fait. Il est même très souvent impossible de ne se reposer que sur la libc lorsqu'on veut faire des applis poussées donc pourquoi ne pas utiliser l'API native dès le départ?
Prenons le cas du multithreading. Discipline qui n'est prise en charge que par la dernière norme qui vient à peine de sortir. Avant cela, si on souhaitait en faire, il fallait forcément passer par l'API sous-jacente. (et au passage, ce n'est pas l'API windows ou UNIX qui est basé sur du C, mais l'inverse. La libc n'est que la garantie que ses fonctions seront retrouvée lors d'un changement de système mais ces fonctions utilisent les fonctions de l'API native).
Donc je disais juste (ou plutôt me demandais juste, à l'époque) que la libc est très utile, lorsque la portabilité est un soucis majeur de portabilité mais qu'en dehors de ça valait mieux utiiser l'API du système. (Ca a un peu dérapé et j'exagérais un peu quand je disais qu'elle servait à rien mais le message de fond c'est çà!)
Cordialement.
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.
Répondre avec citation
Partager