Je ne sais pas qui exactement fournit msvcrt (Windows ou MSVC ?)
MSVC
on parle bien de l'écosystème Windows et de ses briques fondamentales fournies par Microsoft.
Ben je trouve que c'est bien de préciser : si on parle de l'ABI, la partie stable et "contractuelle", non la libc ne fait pas partie (de Windows). Tu peux regarder les deux fonctions:
- fopen fopen est marqué "Visual Studio" et chaque version de Visual Studio a sa page)
- CreateFile ne donne pas de compilateur ("desktop only", pour différencier de Metro)
L'éco-système Windows ne contient pas fopen. L'éco-système Visual Studio le contient. La différence est grande, ce n'est pas le nom de l'éditeur qui importe. Visual Studio n'est pas le seul compilo pour Windows.
On évite si on peut. FILE a l'avantage de fournir une gestion bufferisée des fichiers, ce qu'un fd ou un handle ne font pas. Après on peut tout réécrire à la main, mais ce n'est pas une entreprise triviale…
Ce que tu loupes, c'est que la libc de Visual Studio n'est pas la seule! Oui, on est libre, sous Windows, de choisir la libc qu'on veut : Intel, CodeGear, et j'en passe. Tu fais un choix (prendre la libc de Visual Studio), d'autres peuvent faire autrement. le C n'a jamais dit qu'il y avait une ABI fixe.
Bref : tu ne doit pas "éviter si tu peux", tu dois éviter. Le contrat est pour une seule libc, Linux ou Windows, même combat. Tu as la chances d'avoir une seule libc commune à tous tes programmes sous Linux, mais le jour où tu changes de distro et que tu passes de libc.so.5 à libc.sO.6 seulement pour une brique, sans recompiler le reste, bam. Linux aussi.
Si, si, il y échapperait, pour la raison que j'ai donnée plus haut : sur Unix, toutes les bibliothèques chargées dans un processus partagent la même libc
Si je linke un lib à la libc, une autre à μlibc, je te défie de me démontrer que l'autre lib va linker comme par hasard avec libc. Tu te trompes.
La question est sans objet, puisque cette situation ne se produira pas (tu auras une seule libc chargée dans le processus).
C'est faux aussi : ça arrive. Je compile avec libc.so.0 en link, tu compiles avec libc.so.5 en link, les deux libc seront en mémoire. Je te défie aussi de me démontrer le contraire. Ce n'est pas parce que les distro s'amusent à tout recompiler avec la lib que c'est obligatoire. Tu mélanges ce que tu fais généralement avec les possibilités offertes. encore une fois, ce n'est pas parce que toi tu fais un truc, que c'est la seule chose possible. Linux ou Windows, même combat : si tu as le code, tu peux compiler avec la même libc, sinon c'est la merde. Ca n'a absolument rien à voir avec Linux ou Windows, juste la disponibilité du code source et la ferme de compilation que tu t'es mis. Encore une fois, ne pas mélanger les inconvénients et les avantages : les gens ont l'avantage de pouvoir choisir leur libc, ça apporte des inconvénients, si tu veux pas ça sous Windows, interdit l'avantage et l’inconvénient partira.
Résumé :
- Si mêmes contraintes (obliger la même libc partout), Windows et Linux ex-aequo
- Si mêmes autorisations (laisser libre le choix de la lib), Windows et Linux ex-aequo
- La seule différence est l'usage le plus classique, où les linuxiens aiment compiler eux même du source avec un unique (éditeur et version) compilo. Mais tu peux faire la même chose sous Windows aussi si tu as envie. Ca ne peut donc pas être considéré comme défaut de Windows, Windows laisse juste "trop" de libertés et elles sont juste utilisées.
Bref, finalement je vois juste qu'on accuse Windows de laisser trop de libertés aux gens qui ne savent pas lire une documentation… Met la même contraintes que tu fais sous Linux (=tout le monde doit utiliser la même libc, c'est un ordre) que tu n'auras pas le problème que tu cites. Enlève cette contrainte et quand une personne utilisera cet avantage sous Linux, ça pétera aussi.
[^] # Re: Oui, mais.
Posté par Zenitram (site web personnel) . En réponse au journal Self serving. Évalué à 2. Dernière modification le 02 septembre 2012 à 13:14.
MSVC
Ben je trouve que c'est bien de préciser : si on parle de l'ABI, la partie stable et "contractuelle", non la libc ne fait pas partie (de Windows). Tu peux regarder les deux fonctions:
- fopen fopen est marqué "Visual Studio" et chaque version de Visual Studio a sa page)
- CreateFile ne donne pas de compilateur ("desktop only", pour différencier de Metro)
L'éco-système Windows ne contient pas fopen. L'éco-système Visual Studio le contient. La différence est grande, ce n'est pas le nom de l'éditeur qui importe. Visual Studio n'est pas le seul compilo pour Windows.
Ce que tu loupes, c'est que la libc de Visual Studio n'est pas la seule! Oui, on est libre, sous Windows, de choisir la libc qu'on veut : Intel, CodeGear, et j'en passe. Tu fais un choix (prendre la libc de Visual Studio), d'autres peuvent faire autrement. le C n'a jamais dit qu'il y avait une ABI fixe.
Bref : tu ne doit pas "éviter si tu peux", tu dois éviter. Le contrat est pour une seule libc, Linux ou Windows, même combat. Tu as la chances d'avoir une seule libc commune à tous tes programmes sous Linux, mais le jour où tu changes de distro et que tu passes de libc.so.5 à libc.sO.6 seulement pour une brique, sans recompiler le reste, bam. Linux aussi.
Si je linke un lib à la libc, une autre à μlibc, je te défie de me démontrer que l'autre lib va linker comme par hasard avec libc. Tu te trompes.
C'est faux aussi : ça arrive. Je compile avec libc.so.0 en link, tu compiles avec libc.so.5 en link, les deux libc seront en mémoire. Je te défie aussi de me démontrer le contraire. Ce n'est pas parce que les distro s'amusent à tout recompiler avec la lib que c'est obligatoire. Tu mélanges ce que tu fais généralement avec les possibilités offertes. encore une fois, ce n'est pas parce que toi tu fais un truc, que c'est la seule chose possible. Linux ou Windows, même combat : si tu as le code, tu peux compiler avec la même libc, sinon c'est la merde. Ca n'a absolument rien à voir avec Linux ou Windows, juste la disponibilité du code source et la ferme de compilation que tu t'es mis. Encore une fois, ne pas mélanger les inconvénients et les avantages : les gens ont l'avantage de pouvoir choisir leur libc, ça apporte des inconvénients, si tu veux pas ça sous Windows, interdit l'avantage et l’inconvénient partira.
Résumé :
- Si mêmes contraintes (obliger la même libc partout), Windows et Linux ex-aequo
- Si mêmes autorisations (laisser libre le choix de la lib), Windows et Linux ex-aequo
- La seule différence est l'usage le plus classique, où les linuxiens aiment compiler eux même du source avec un unique (éditeur et version) compilo. Mais tu peux faire la même chose sous Windows aussi si tu as envie. Ca ne peut donc pas être considéré comme défaut de Windows, Windows laisse juste "trop" de libertés et elles sont juste utilisées.
Bref, finalement je vois juste qu'on accuse Windows de laisser trop de libertés aux gens qui ne savent pas lire une documentation… Met la même contraintes que tu fais sous Linux (=tout le monde doit utiliser la même libc, c'est un ordre) que tu n'auras pas le problème que tu cites. Enlève cette contrainte et quand une personne utilisera cet avantage sous Linux, ça pétera aussi.