C-toxcore: Ne pas inclure d'en-têtes spécifiques au système d'exploitation dans les fichiers .h
Actuellement, network.h inclut un grand nombre d'en-têtes spécifiques à la plate-forme (comme u.h , windows.h et unistd.h ). Nous devrions les limiter à un seul fichier (ou à quelques fichiers).
Je suggère que nous créions une abstraction fine sur les installations du système d'exploitation pour la mise en réseau, et une autre sur celles pour l'horloge monotone. Nous pourrions alors avoir un fichier par type de plate-forme (par exemple ${module}_win32.c , _unix.c , _osx.c , _posix.c , ...) et les compiler conditionnellement selon le préprocesseur symboles, comme nous le faisons déjà. L'inconvénient est que c'est un peu plus de temps de déclaration, car actuellement ces #ifdef sont des fonctions internes qui devront être redéfinies pour chaque plate-forme. L'avantage est qu'il n'y a pas ou peu de #ifdef dans le code lui-même, et le code spécifique à la plate-forme est dans un ensemble de petits fichiers au lieu (comme c'est le cas actuellement) dans un fichier de 1100 lignes mélangeant les abstractions de la plate-forme avec code d'application.
iphydf
Tous les 5 commentaires
Ça a l'air bien
nurupo
le 12 sept. 2016
Que diriez-vous de créer une interface « système » qui peut être implémentée par un « système Windows » et un « système posix » et un « système de test » ? Le système de test peut être utilisé dans des tests unitaires et simule un système sans réellement faire d'appels système.
iphydf
le 18 déc. 2016
Je ne suis pas d'accord sur la suggestion de mise en œuvre. Je préférerais de loin voir toutes les fonctions dans un seul fichier {network,time,...}.c , avec des #ifdef utilisés pour envelopper les fonctions qui doivent être écrites différemment pour chaque plate-forme.
Les avantages de cette méthode par rapport à des fichiers séparés sont que nous pouvons forcer tout le code spécifique à la plate-forme en tant que fonction statique et exposer une seule API pour les niveaux supérieurs de toxcore. Tous les détails de mise en œuvre de la plate-forme seront facilement visibles à partir d'un seul fichier. Les particularités de la plate-forme nécessiteront une abstraction et une gestion dans un seul fichier, au lieu de plusieurs fichiers. Cela facilitera également la maintenance du fichier cmakelists.txt (il commence déjà à nous échapper.) Et une révision ultérieure, avec notre système de révision actuel.
GrayHatter
le 30 déc. 2016
Pas complètement réparé
Diadlo
le 27 janv. 2017
@GrayHatter a accepté. Ayons un seul fichier implémentant les spécificités du système d'exploitation.
Je désassigne @Diadlo pour l'instant. Je pense que c'est un excellent bogue sur lequel travailler pour les nouveaux contributeurs, car il donne une exposition à une grande partie de la base de code et du code réseau. C'est une refactorisation quelque peu intéressante qui n'a aucun impact sur les fonctionnalités, elle est donc plus facile à tester.
iphydf
le 16 janv. 2018
Questions connexes
iphydf
·
10Commentaires
zoff99
·
7Commentaires
ovalseven8
·
11Commentaires
fabionar
·
5Commentaires
DataMaster-2501
·
6Commentaires
Commentaire le plus utile
Que diriez-vous de créer une interface « système » qui peut être implémentée par un « système Windows » et un « système posix » et un « système de test » ? Le système de test peut être utilisé dans des tests unitaires et simule un système sans réellement faire d'appels système.