• [^] # Re: Pourquoi du théorie des patch c'est bien

    Posté par . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 4.

    Ok pour les I/O, mais le souvent couvre-t-il aussi les calculs alors? Par exemple les divisions par puissances de 2?
    Ou l'acces a la memoire, que tu consideres le role principal du C (pour moi, le role de C n'est pas de manipuler la memoire, mais de faire des programmes portables et performants qui font quelque chose, peu importe quoi, l'acces memoire etant un moyen, non une fin)?

    Pour ce qui est de la "double API"... d'un cote y'a posix (et non unix, qui est un OS, pas un standard) de l'autre C, ce sont des outils differents, et ce point (les acces aux fichiers) se comprends facilement: open est bas niveau, moins portable que fopen (puisque pas forcement implemente par les os non posix), et plus souple. Bref, ce ne sont pas des doublons.

    Au final, j'ai l'impression que tu te concentres sur des details d'implementation pour dire qu'on ne peut faire les choses que d'une facon avec ces outils... tiens, un exemple de plusieurs facons de faire un truc avec posix: effectuer plusieurs choses en "meme temps". Multi-thread ou multi-process. Pour communiquer? Entre la memoire partagee, les sockets et les signaux, y'a du choix.
    Certes, il y a de grosses differences entre leurs roles et capacites (surtout pour les signaux, pour lesquels envoyer un message complexe necessiterait enormement de code, vu que je ne crois pas qu'il soit possible d'attacher une info, mais c'est faisable, en construisant un systeme qui utiliserait un signal pour envoyer 1, un autre pour les 0... ce serait moche, oui, mais faisable a priori) mais le point est la: ces outils permettent d'echanger des messages.
    Tiens en parlant de sockets: poll, epoll, select ou eselect? Ces fonctions font la meme chose, avec diverses limitations ou avantages.

    Voila qui devrait aider a ce que tu comprennes mes doutes.