fonction sleep et compatibilité os

[blacksages]

Bonjour,

en lisant SFML Game Development, page 24 je lis que la fonction "sleep()" n'est pas précise et qu'elle ne devrait pas être utilisée pour un timing minutieux, en regardant le fichier source sur github: https://github.com/SFML/SFML/blob/master/src/SFML/System/Sleep.cpp
je n'ai pas compris pourquoi, je suis remonté à SleepImpl.cpp qui relie ça à l'api de windows: https://github.com/SFML/SFML/blob/master/src/SFML/System/Win32/SleepImpl.cpp, et là encore plus perdu^^
Mais soit, à quoi réfère l'auteur du livre en parlant d'imprécision?

Aussi, dans la foulée, en lisant  SleepImpl.cpp je lis #include <windows.h>, j'apprends que windows.h est une librairie de windows. Je revois la page d'entrée du site sfml et je lis "SFML est multi-plateforme".
D'où ma seconde question: comment avoir cette compatibilité entre différents os si le fichier src appelle du code spécifiquement pour windows?

[Laurent]

Les systèmes d'exploitation fonctionnent avec un ordonnanceur, qui donne plus ou moins de temps aux différents threads et processus en fonction de leur priorité et des coeurs CPU disponibles. En général ces ordonnanceurs fonctionnent par "tranche" de temps (ie. ils changent le processus / thread actif d'un coeur CPU toutes les X millisecondes). Donc, lorsque tu endors un thread avec une fonction du genre "sleep", tu donnes une indication au système d'exploitation sur le moment souhaité pour le réveil, mais ça ne reste qu'une indication. L'ordonnanceur peut très bien décider de réveiller ton thread plus tard. Même si nous faisons le maximum pour que ce timing soit respecté de manière la plus précise possible, en fonction de ce que l'OS est capable de faire, le timing ne sera jamais garanti. C'est pour cela qu'on n'utilise jamais les fonctions de type "sleep" pour gérer des timings précis.

D'où ma seconde question: comment avoir cette compatibilité entre différents os si le fichier src appelle du code spécifiquement pour windows?

On ne compile pas les mêmes fichiers en fonction de l'OS sur lequel se fait cette compilation. Là il s'agit de Win32/SleepImpl.cpp, de même que tu as Unix/SleepImpl.cpp qui gère les Linux & MacOS.

[blacksages]

Merci pour la réponse!

[stewartcristan]

Thanks blacksages, what your asked in this post that was somewhat helpful for me.

[janf]

Aussi, dans la foulée, en lisant  SleepImpl.cpp je lis #include <windows.h>, j'apprends que windows.h est une librairie de windows. Je revois la page d'entrée du site sfml et je lis "SFML est multi-plateforme".
D'où ma seconde question: comment avoir cette compatibilité entre différents os si le fichier src appelle du code spécifiquement pour windows?

C'est toute l'astuce du côté multi-plateforme avec look natif d'une appli de fenêtrage ! Et ça représente beaucoup de boulot aussi. SFML appelle les fonctions natives des OS sur lesquels elle fonctionne, lors de la compilation. Elle abstrait ces fonctions avec une API cohérente qui est la même sur tous les OS.

Le seul autre choix pour faire du multi-plateforme pour une bibliothèque de fenêtrage (mais là je parle plus d'une bibli comme Qt ou WxWidgets, qui ont tous les widgets type "boutons", "barre de défilement" etc.), serait de créer un seul look qui soit le même sur toute les plateformes (ou plusieurs thèmes de looks pourquoi pas). Mais on n'aurait pas le look natif de la plateforme sur laquelle on compile.

On pourrait à la limite tenter d'imiter, de reproduire parfaitement une fenêtre de MacOS (par exemple) avec l'apparence de ses boutons, de ses textes, de ses formulaires... Mais quand demain MacOS change de look, ou si simplement aujourd'hui l'utilisateur choisi un autre thème que celui par défaut pour son OS, on voit tout de suite que notre application n'a pas le look natif.

Donc par exemple dans le cas de la création d'une fenêtre, ou dans le cas de l'ouverture d'un socket, dans notre bibliothèque on écrit une seule classe avec son API, et selon la plateforme sur laquelle on est, la compilation appellera le fichier d'implémentation (***Impl.cpp) correspondant.

Donc le mot "multi-plateforme" ici implique que ça ne fonctionne quand même que sur les plateformes pour lesquelles un grand boulot à été fait : le travail de connaître le fonctionnement des bibliothèques natives de la plateforme et de traduire les appels de ces bibliothèques au sein de fonctions génériques.