Discussion :

[Kirilenko]

C'est sûr, quand tu n'as besoin d'aucune portabilité, les fonctions de l'API peuvent être utilisée de manière importante car plus diverses (du bas niveau, du haut niveau du point de vue utilisateur). Mais bon, la nécessité d'écrire un code portable est vraiment importante. Ne serait-ce sur pour sa propre relecture du code, la maintenance d'autres personnes. La programmation est souvent basée sur le partage. C'est comme les protocoles réseaux, si tu utilises des inconnus personne ne te comprend et ton code est classé comme trop exotique pour être intéressant.

[souviron34]

C'est sûr, quand tu n'as besoin d'aucune portabilité, les fonctions de l'API peuvent être utilisée de manière importante car plus diverses (du bas niveau, du haut niveau du point de vue utilisateur). Mais bon, la nécessité d'écrire un code portable est vraiment importante.

J'ajouterais :

surtout pour soi-même

Car vu l'effort passé en général à écrire un (bon) programme, il est un peu dommage d'avoir à le ré-écrire chaque fois qu'on change de plateforme, et/ou chaque fois que le fabricant change de version (ce qui, sur Win, est assez rapide : les API win32 de Win95 sont-elles 100% compatibles avec celle de Win98, avec celles de Win2000, avc celle de XP, avec celle de Vista, avec celles de Win7 ?????????????). Pendant ce temps les API C (surtout standard) n'ont absolument pas bougé...

Mes programmes C de 1989 continuent à tourner aujourdhui sur Linux dernière version, et sur cygwin.. (mis à part les sockets/signaux, qui nécessitent du travail sur cygwin ou windows, mais aucune modification sur Linux par rapport à des HP ou des SUN de 1996).

Je crois, Baccali, si on ajoute à cette discussion la discussion sur la norme, qe tu ne te rends pas du tout compte du problème de la pérennité, qui est bien plus important que la "portabilité", et qui est assuré au mieux par C et sa librairie standard....(ainsi que par la connaissance du K&R et pas la dernire version de la norme).

[Bktero]

Souviron traque Baccali

[baccali]

J'ajouterais :

surtout pour soi-même

J'avais bien compris que c'était la seule chose qui t'intéressait!

Car vu l'effort passé en général à écrire un (bon) programme, il est un peu dommage d'avoir à le ré-écrire chaque fois qu'on change de plateforme, et/ou chaque fois que le fabricant change de version (ce qui, sur Win, est assez rapide : les API win32 de Win95 sont-elles 100% compatibles avec celle de Win98, avec celles de Win2000, avc celle de XP, avec celle de Vista, avec celles de Win7 ?????????????). Pendant ce temps les API C (surtout standard) n'ont absolument pas bougé...

Et je peux savoir ce que tu entends par API C? L'API Windows ou Linux n'en est pas une?. N'était ce pas toi qui soulignait à juste titre dans la discussion sur la norme qu'une politique quasi nécessaire en programmation est la rétro compatibilité? Tu cites Windows c'est on ne peut plus mal choisis comme exemple. Windows s'assure autant que possible qu'un code créé sur une de leur API marchera toujours dans la suivante. Pour te le prouver, je ne te parlerai que des fonctions "extended", du support encore effectifs des fonctions 16 bits sur Win32 et des programmes Windows 98 toujours succeptible de marcher sur Windows 7! Donc je ne sais pas à qui tu veux faire croire que les OS sont aussi instables alors que la librairie standard est une valeur sûre (dans la nouvelle norme fgets a totalement disparu)! Déjà tu les aurais codé avec l'API native tes sockets, tu n'aurais pas eut à les retravailler et tu n'aurais eut qu'à modifier qu'un module de ton code et ton Makefile. C'est aussi çà "l'effort passé à faire un (bon) programme!"

Mes programmes C de 1989 continuent à tourner aujourdhui sur Linux dernière version, et sur cygwin.. (mis à part les sockets/signaux, qui nécessitent du travail sur cygwin ou windows, mais aucune modification sur Linux par rapport à des HP ou des SUN de 1996).
Je crois, Baccali, si on ajoute à cette discussion la discussion sur la norme, qe tu ne te rends pas du tout compte du problème de la pérennité, qui est bien plus important que la "portabilité", et qui est assuré au mieux par C et sa librairie standard....(ainsi que par la connaissance du K&R et pas la dernire version de la norme).

J'ai bien compris que tu veux débattre seulement pour débattre et sans message de fond mais tu te relis des fois, juste histoire de vérifier que tu n'es pas en contradiction avec toi même? Parce qu'entre :

C'est sûr, quand tu n'as besoin d'aucune portabilité,... Mais bon, la nécessité d'écrire un code portable est vraiment importante.

Et çà

J'ajouterais :

surtout pour soi-même
...
Je crois, Baccali, si on ajoute à cette discussion la discussion sur la norme, qe tu ne te rends pas du tout compte du problème de la pérennité, qui est bien plus important que la "portabilité"

Ton discour a vachement dévié! Sans compter les contradictions avec ce que tu soutiens sur la norme où là tu dis qu'on s'en fiche de la norme, alors qu'ici elle assure soudainement la pérénité de ton code.

Mais si il fallait vraiment parler de la pérénité vs la portabilité (et ce sera mon seul message là dessus), c'est bien beau que tes programmes de 89 tournent toujours. Mais vas vendre un logiciel fait en 89 qui marche lentement alors que d'autre font du "refactoring" de leur programme, utilisent des API natives plutôt et font avancer l'informatique en général! Donc je te le répète : Le monde de l'informatique est beaucoup plus vaste que le clavier et l'écran de souviron34.

Souviron traque Baccali

C'est clair! j'ai un fan

[souviron34]

Et je peux savoir ce que tu entends par API C?

Au cas ou tu ne le saurais pas, API est "Application Programming Interface"....

API C signifie donc la défintion de l'appel des fonctions de la biblothèque standard...

L'API Windows ou Linux n'en est pas une?

Je ne connais pas vraiment "d'API Linux"..

Quant à l'API Windows, elle a voulu remplacer toutes les biblothèques standards, et, à part pour des questions de performances, a été largement abandonnée....

Déjà tu les aurais codé avec l'API native tes sockets, tu n'aurais pas eut à les retravailler et tu n'aurais eut qu'à modifier qu'un module de ton code et ton Makefile.

Quand tu sauras de quoi tu parles, on en reparlera...

Les sockets n'existent sur Windows que depuis 2002...

Sur unix ils existent depuis ... minimum 1985...

Les serveurs Web Windows jusqu'en 2002 fonctionnaient en boucle infinie en lecture toutes les secondes sur le port...

Les serveurs Web de base des débuts du Web vers 1990-1994) fonctionnaient avec des sockets asynchrones, chose dont Windows ne permettait pas l'utilisation, à moins de leur passer un id de fenêtre (un WindowHabdle).. ce qui violait la séparation en couches ISO et toute l'architecture de l'ensemble des applis fonctionnant sur les autres systèmes... (et donc à base de bibliothèques en couches)

Alors tu me fais rigoler....

C'est clair! j'ai un fan

Je pense juste que tu es tellement orgueilleux et pétri de certitudes que cela ne vaut pas la peine de discuter avec toi.

Alors ciao..

Je ne répondrai plus à aucun de tes messages sur ce genre de sujets..

[baccali]

API C signifie donc la défintion de l'appel des fonctions de la biblothèque standard...

Je ne connais pas vraiment "d'API Linux"..

http://en.wikipedia.org/wiki/Linux_Kernel_API

Mes programmes C de 1989 continuent à tourner aujourdhui sur Linux dernière version, et sur cygwin.. ([I][I]mis à part les sockets/signaux, qui nécessitent du travail sur cygwin ou windows,

Les sockets n'existent sur Windows que depuis 2002...

Ou j'ai mal compris quelque chose mais bon, on pourra pas trop m'en vouloir...

Alors ciao..

[Médinoc]

Là, je ne résiste pas à m'interposer tant certaines énormités sont échangées.

Je ne connais pas vraiment "d'API Linux"...

Là, soit tu fais exprès d'être idiot pour ne pas comprendre l'abus de langage pour POSIX, soit tu t'offusques de cet abus de langage au point de commettre des actes dépravés sur des insectes volants.

Les sockets n'existent sur Windows que depuis 2002...

Ahem.

Les serveurs Web de base des débuts du Web vers 1990-1994) fonctionnaient avec des sockets asynchrones, chose dont Windows ne permettait pas l'utilisation, à moins de leur passer un id de fenêtre (un WindowHabdle).. ce qui violait la séparation en couches ISO et toute l'architecture de l'ensemble des applis fonctionnant sur les autres systèmes... (et donc à base de bibliothèques en couches)

WSAAsyncSelect() est une chose, mais select() et WSAEventSelect() en sont une autre...

http://en.wikipedia.org/wiki/Linux_Kernel_API

On ne parle pas de programmation kernel-mode ici.

Donc je ne sais pas à qui tu veux faire croire que les OS sont aussi instables alors que la librairie standard est une valeur sûre (dans la nouvelle norme fgets a totalement disparu)!

Windows a eu des breaking changes, tu sais. InitCommonControlsEx(ICC_WIN95_CLASSES) en est un, il y en a un autre dans la gestion des menus... Sans compter les breaking changes de .Net, vu qu'il ne s'agit pas là de l'API donnée par windows.
De plus, l'API "Native" de Windows, celle qui est non-documentée, est celle qui est subjecte à changement. L'API Win32 est déjà une surcouche.
Et fgets() existe toujours, plus forte que jamais. Même gets() n'a pas "totalement disparu", elle a été dépréciée.

PS: On ne peut pas anticiper la portabilité. Tu peux toujours te retrouver à devoir réutiliser un ancien code, donc il vaut toujours mieux qu'il soit aussi portable que possible.
Et n'oublie pas:

"Premature optimization is the root of all evil."

[Médinoc]

Et tiens, un dernier argument en faveur de la biliothèque standard:

• Le strcat() standard est une fonction intrinsic, traduite directement en code assembleur optimisé.
• Le StrCat() de L'API Windows est une fonction dans la DLL shlwapi.dll, dont elle est forcément appelée par un pointeur de fonction, jamais inlinée. Elle sera donc forcément plus lente.

[souviron34]

Ou j'ai mal compris quelque chose mais bon, on pourra pas trop m'en vouloir...

Là, je ne résiste pas à m'interposer tant certaines énormités sont échangées.


Là, soit tu fais exprès d'être idiot pour ne pas comprendre l'abus de langage pour POSIX, soit tu t'offusques de cet abus de langage au point de commettre des actes dépravés sur des insectes volants.

API ????

Je me répète : les OS ont des systèmes de commandes, divers et variés..On n'a jamais appelé "API" les commandes unix, ni les commandes VMS, ou MVS...

Certains ont fourni des moyens de dialoguer, voire modifier, certaines valeurs ou fonctions du Kernel, mais le terme "API" n'a jamais été utilisé pour ça, que tout récemment par les développeurs principalement de Linux dans ses diverses distrbutions..

Pour Unix, personne ne parlait d'API, mais de Unix Système V, de Unix BSD, ou de Unix/Posix..

Ahem.


WSAAsyncSelect() est une chose, mais select() et WSAEventSelect() en sont une autre...

C'est exact je sais , mais l'association avec des WindowMessage et la non-compatibilité des winsock.h/winsock2.h avec les stuctures uilisées dans l'ensemble des "flavours" de unix n'en faisait de vraies notions de sockets, en termes de couche indépendante, ce que c'est devenu depuis le début des années 2000.

Encore une fois, il suffit de regarder les exemples de serveur Web Windows jusqu'en 2001...

Je me suis cassé la tête sur ce point en 99, alors que j'avais une biblo de sockets juste au dessus du protocole, avec 6 couches de biblos par dessus... Impossible à porter sans faire traverser des WindowHandle dans toutes les couches...

Windows a eu des breaking changes, tu sais. InitCommonControlsEx(ICC_WIN95_CLASSES) en est un, il y en a un autre dans la gestion des menus...

Sans parler des limites des FAR....

PS: On ne peut pas anticiper la portabilité. Tu peux toujours te retrouver à devoir réutiliser un ancien code, donc il vaut toujours mieux qu'il soit aussi portable que possible.
Et n'oublie pas:

[Jean-Marc.Bourguet]

API ????

Je me répète : les OS ont des systèmes de commandes, divers et variés..On n'a jamais appelé "API" les commandes unix, ni les commandes VMS, ou MVS...

Certains ont fourni des moyens de dialoguer, voire modifier, certaines valeurs ou fonctions du Kernel, mais le terme "API" n'a jamais été utilisé pour ça, que tout récemment par les développeurs principalement de Linux dans ses diverses distrbutions..

Pour Unix, personne ne parlait d'API, mais de Unix Système V, de Unix BSD, ou de Unix/Posix..

En 1990, dans son bouquin Unix Network Programming, R.W. Stevens utilisait API pour désigner l'interface fournie par les sockets et la TLI de System V.

[baccali]

Salut Médinoc,

On ne parle pas de programmation kernel-mode ici.

Moi si sur ce point là parce que le terme API n'est pas réservé qu'au User-mode. Pour moi c'est un tout. La politique est la même lorsqu'ils releasent leurs APIs, que ce soit kernel-mode ou user-mode.

Windows a eu des breaking changes, tu sais. InitCommonControlsEx(ICC_WIN95_CLASSES) en est un, il y en a un autre dans la gestion des menus... Sans compter les breaking changes de .Net, vu qu'il ne s'agit pas là de l'API donnée par windows.
De plus, l'API "Native" de Windows, celle qui est non-documentée, est celle qui est subjecte à changement. L'API Win32 est déjà une surcouche.
Et fgets() existe toujours, plus forte que jamais. Même gets() n'a pas "totalement disparu", elle a été dépréciée.

Justement ton code n'est pas sensé utiliser les fonctions non documentées. Et les fonctions Windows aussi restent deprecated pendant un bon bout de temps avant d'être retirée, tout comme la libC. donc tu as le temps de voir venir!

Et de façon plus générale, merci lorsque vous donnez un argument de donner un ARGUMENT et non une énigme! Lacher un nom de fonction ou une macro n'est pas forcément significatif de votre pensée pour tout le monde.

La fonction InitCommonControlsEx() est toujours implémentée aujourd'hui. En quoi cela casses-t-il les codes?

Bon l'autre hors sujet avec ses pointeurs FAR, comme d'habitude à parler pour rien dire d'intéressant, je répondrais lorsqu'il me montrera un bout de code cassé par les limites de FAR ( à moins qu'il addresse directement les emplacement mémoire depuis le 16 bit ou autre dans ses applis. -.-" ).

Deuxièmement, que ce soit sur Linux, sur Windows, la libc etc... Lors d'un changement de version, il y'a toujours des modifications, c'est le but d'un changement de version. Ils te garantissent une rétro-compatibilité mais dans de TRES RARES cas, cela n'est pas toujours possible (à moins de simuler un comportement).

D'ailleurs ça me fait aussi doucement rigoler quand souviron dit que ce n'est que Windows qui change aussi vite ses API. Lorsqu'on connait à quoi servent les chiffres dans kernel 2.4, 2.6, 2.2 etc... et qu'on compare les intervalles de sorties de ces noyaux alors que NT est là depuis plus de 10 ans...!

De plus, quand tu qualifies .Net de "breaking-change" c'est un peu "totalement" faux! Changement oui, mais comme il est introduit en parallèle des autres technos ton code ne l'utilise pas mais n'est pas cassé. Par exemple, pour re Le .Net est là mais les fonctions que ton programme en COM utilise sont toujours là. Donc tu as deux solutions :
_ Soit tu décides que ton code ne dois pas changer du tout comme souviron et tu ne fais que le maintenir lorsqu'il est obsolète ( ce qui, en général, demande exponentiellement moins de temps que de coder ton appli).
_ Soit tu décides que telle ou telle nouveauté ou technologie est plus avantageuse, ne serait ce que pour des raisons de perf, et tu as encore moins de changement et de maintenance à faire au fil des version.
Mais comme je l'ai dit, parfois la rétro-compatibilité n'est pas toujours possible, un exemple valable que tu aurais pu me sortir Medinoc, c'est les applications en mode plein écran qui devront être modifié pour utiliser Metro. Mais ça on le sait depuis longtemps donc sans compter que si tu décides de faire le strict minimum tu n'as pas grand chose à modifier, si tu décides de refaire tout le code de ton UI tu as encore le temps.

PS: On ne peut pas anticiper la portabilité. Tu peux toujours te retrouver à devoir réutiliser un ancien code, donc il vaut toujours mieux qu'il soit aussi portable que possible.
Et n'oublie pas:

C'est vrai, je suis tout à fait d'accord avec toi. Seulement force est de constater qu'en l'état actuel des choses tu as un choix à faire entre la portabilité et l'efficacité de tes codes. Et comme on l'a vu lorsque je discutait avec Melem, lorsque tu veux faire des applis un minimum poussée, genre qui utilisent le multi-threading (chose quasi-incontournable aujourd'hui), tu retombes dans 99,9 % des cas sur l'API native ou une "third-party library". Donc perso moi je préfère écrire du code portable (et par portable je veux dire inter-système) seulement quand je sais que le bout de code va me resservir. Par exemple, quand j'ai le temps je suis en train de faire un IDE (mais surtout utilisé pour son extension vsStudio) basée sur du COM, une sorte d'amélioration de vim, sensé permettre la programmation "inter-système" (utilisation d'intellisense pour les protos comme les pages du man, compilation et debugging à distance par ssh etc....). A quoi me servirait de faire du code portable ici!

Par contre je suis aussi sur un projet qui permet de faire du reverse-ingenering automatiquement d'un certain OS et de certaines appli du même vendeur dispo sur windows comme sur Linux. Là du code portable est d'ordre (et encore, pas toute les parties).

Donc il faut relativiser!

PS: Je pense que tu loupes l'important dans ta citation, à savoir PREMATURE. Sinon elle est HS et même totalement erronée.

[Médinoc]

Pour InitCommonControlsEx(): Un programme compilé pour un ancien Windows marchera sans problème pour XP, mais un programme compilé en voulant profiter du "style XP" (tout en voulant rester compatible avec les versions précédentes) aura des problèmes s'il n'appelle pas cette fonction avec le flag ICC_WIN95_CLASSES... Mais si tu veux compiler pour rester compatible avec les anciens Windows, le flag n'existe pas!
Il y a un autre conflit de ce genre avec les fonctions d'édition de menu, mais je ne l'ai plus en tête.

De plus, quand tu qualifies .Net de "breaking-change" c'est un peu "totalement" faux!

Ce n'est pas ce que j'ai dit. Je parlais de ceci: Breaking changes d'une version de .Net à une autre. Ou ceci, quand Microsoft prend des libertés (ou les perd) avec les standards.

PS: Si tu n'as pas fait de profiling avant pour savoir si c'est l'usage des fonctions standard qui ralentit ton programme, alors utiliser d'autres fonctions à la place est une optimisation prématurée.

[baccali]

Pour InitCommonControlsEx(): Un programme compilé pour un ancien Windows marchera sans problème pour XP, mais un programme compilé en voulant profiter du "style XP" (tout en voulant rester compatible avec les versions précédentes) aura des problèmes s'il n'appelle pas cette fonction avec le flag ICC_WIN95_CLASSES... Mais si tu veux compiler pour rester compatible avec les anciens Windows, le flag n'existe pas!
Il y a un autre conflit de ce genre avec les fonctions d'édition de menu, mais je ne l'ai plus en tête.

Mais cela ne change rien au fait que le programme fonctionnera. Le style des fenêtres et autres soucis de cet ordre importent peu tant que ton appli apporte ce qu'elle est sensé apporter à ton entreprise.
De plus sur cet exemple précis, si on parle de RETRO-compatibilité c'est bien pour une raison. Tu ne peux pas te plaindre parce que ton jeu PS3 ne marche pas ou a de moins bonnes perf sur une PS2. L'inverse, par contre, est moins "logique" et gérer ses problèmes est de toute façon ingérable.

Ce n'est pas ce que j'ai dit. Je parlais de ceci: Breaking changes d'une version de .Net à une autre. Ou ceci, quand Microsoft prend des libertés (ou les perd) avec les standards.

Autant pour moi, j'ai mal compris! Par contre, j'ai parcouru les liens (très bons liens d'ailleurs!), et je n'ai rien vu de choquant qui t'obligerait à jetter ton code à la poubelle. Que ce soit en .Net ou pour VC.

D'ailleurs, si il fallait vraiment être "pointilleu", pour les problèmes non relatifs à .Net, on parle là d'un problème de compilation et non du système. Ce n'est pas parce que gcc ne supporte pas tel ou tel usage, syntaxe ou autre que la faute en revient à Linux. Ce sont deux choses bien différentes.

Et c'est pareil dans un certains sens pour le .Net (qui au passage est une tech assez instable, je ne baserai pas mes serveurs dessus pour le moment mais pourquoi pas!). Ces breaking-changes s'apparentent plus à des patch et bug-track qu'à des changements majeurs.

Et dans la plupart des cas, que ce soit pour le .Net ou le reste, tu ne modifies même pas 1% de code pour t'adapter (quand il ne s'agit pas d'une option passé au compilo comme beaucoup de "breaking-changes" signalés pour VC). Donc c'est un peu injuste de traiter le système lui-même d'instable avec çà tu ne penses pas?!

PS: Si tu n'as pas fait de profiling avant pour savoir si c'est l'usage des fonctions standard qui ralentit ton programme, alors utiliser d'autres fonctions à la place est une optimisation prématurée.

C'est juste. Mais tout d'abord perso je n'ai pas que des problèmes de rapidité quand j'optimise mes codes. Le TLS sur lequel j'alloue ma mémoire est plus important si il diminue les chances des heap corruption ou les fonctions secure ou strsafe gérant l'unicode de microsoft (tchar.h n'étant pas dans le standard) sont des valeurs plus sûres pour moi que la rapidité d'exécution. Et j'en passe!

Mais pour en revenir au sujet, je ne trouve pas que ta citation ait un rapport avec le sujet (sans vouloir te vexer!) ou alors c'est soit toi, soit elle que je n'ai pas compris. Je ne pense pas qu'utiliser l'API native du système plutôt que la libc ait quelque chose à voir avec de l'optimisation (mis à part si tu es vraiment en train de faire un brouillon de brouillon pour une présentation intrermédiaire ou des tests et que tu te sens mieux avec la libc). Tout dépend de ton besoin, du cas de figure, de ton environnement et, à moindre mesure lorsque tu n'es pas tout seul sur un projet, de tes "affinités" de programmeurs. Problème de portabilité mis à part, la libc sert tout au plus, AMHA, à simplifier ton code (mis à part pour certaines fonctions, genre math.h, que tu ne retrouves pas sur le système mais sur d'autres lib. Là j'utilise la libc en général, mais rarement dans un soucis de portabilité.).

Mais encore une fois j'ai peut-être mal compris le fond de ta pensée.

[Médinoc]

Sur InitCommonControlsEx(), je ne pense pas qu'on puisse parler de code qui fonctionne quand les "problèmes" en question sont l'absence des contrôle standards: Les appels à MessageBox() échouent, et une boîte de dialogue sans le style DS_NOFAILCREATE ne sera jamais affichée non plus.

Je ne pense pas qu'utiliser l'API native du système plutôt que la libc ait quelque chose à voir avec de l'optimisation

C'est pourtant comme ça que tu l'avais présenté à un moment donné.

Pour strsafe, tu as raison, mais là, ce n'est pas utiliser l'API Windows "pour l'amour de le faire": C'est utiliser l'API Windows parce qu'elle offre des fonctionnalités utiles non-présentes dans la bibliothèque standard.

(par contre, le sprintf_s() de secure est une mauvaise plaisanterie pour ceux qui attendaient le malloc(snprintf(NULL, 0, "blabla")+1) du standard C99)

[baccali]

Sur InitCommonControlsEx(), je ne pense pas qu'on puisse parler de code qui fonctionne quand les "problèmes" en question sont l'absence des contrôle standards: Les appels à MessageBox() échouent, et une boîte de dialogue sans le style DS_NOFAILCREATE ne sera jamais affichée non plus.

J'ai dû louper quelques chose parce que je comprends vraiment pas! Tu l'as dit toi même, un code sur windows 95 marchera sur windows XP alors pourquoi dis-tu maintenant que ça ne marcherait pas?

C'est pourtant comme ça que tu l'avais présenté à un moment donné.

Non. Ou du moins si, mais tu pars d'un principe qui n'est pas le mien. Si on pars de ton principe, que ce soit sur windows ou Linux, je n'ai qu'à coder avec une librairie encore plus "facile à utiliser", puis revenir sur la libc, puis sur l'API native.

Pour strsafe, tu as raison, mais là, ce n'est pas utiliser l'API Windows "pour l'amour de le faire": C'est utiliser l'API Windows parce qu'elle offre des fonctionnalités utiles non-présentes dans la bibliothèque standard.

Voilà ce que je dis depuis le début! Il ne s'agit pas non plus d'utiliser la libc "pour l'amour de le faire" (surtout que comme je l'ai souligné plusieurs fois, utiliser la libc reviendra dans 90 % des cas à mélanger les 2 APIs. C'est pas une mauvaise chose en soit mais j'évite autant que possible. Mélanger le moins d'environnement possible évite d'avoir à surveiller 10 000 sources d'infos pour tracker les bugs)

[souviron34]

je ne dirai qu'une chose :

dit-on qu'une chose est portable si il faut éditer des fichiers en incluant :

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
#ifdef __WIN32
....
#else
.
#endif

Poser la question est y répondre

[Médinoc]

Dans ce cas, aucun OS n'est portable, et surtout pas Linux.

Au moins, Windows n'a pas besoin d'exécuter toute une suite de tests avant de pouvoir compiler un code source.

[souviron34]

Dans ce cas, aucun OS n'est portable, et surtout pas Linux.

je parlais du sujet : biblio standard, et de l'argument suivant lequel c'était mieux d'utiliser l'API....

Un programme C utilisant le librairie standard compilera normalement sans modifications qu'on soit su un HP, un Linux un NEC, une Silicon, un PC, une workstarion, un Mac...

Il faudra éventuellement ajouter des options de compil, mais pas modifier le source..

[baccali]

Ah ouai c'était technique quand même! D'ailleurs j'ai toujours pas compris