C-toxcore: Fügen Sie keine betriebssystemspezifischen Header in .h-Dateien ein
Derzeit enthält network.h viele plattformspezifische Header (wie u.h , windows.h und unistd.h ). Wir sollten diese auf eine einzelne Datei (oder einige Dateien) beschränken.
Ich schlage vor, dass wir eine dünne Abstraktion zu den OS-Einrichtungen für das Netzwerk erstellen und eine andere zu denen für die monotone Uhr. Wir könnten dann eine Datei pro Plattformtyp haben (zB ${module}_win32.c , _unix.c , _osx.c , _posix.c , ...) und diese bedingt gemäß Präprozessor kompilieren Symbole, so wie wir es bereits tun. Der Nachteil ist, dass es etwas mehr Deklarationsaufwand bedeutet, da sich diese #ifdef s derzeit in Funktionen befinden, die für jede Plattform neu definiert werden müssen. Der Vorteil ist, dass der Code selbst keine oder nur wenige #ifdef s enthält und der plattformspezifische Code in einer Reihe kleiner Dateien statt (wie jetzt) in einer 1100-Zeilen-Datei, die Plattformabstraktionen mit Anwendungscode.
iphydf
Alle 5 Kommentare
Hört sich gut an
nurupo
am 12. Sept. 2016
Wie wäre es mit einer "System"-Schnittstelle, die durch ein "Windows-System" und ein "Posix-System" und ein "Testsystem" implementiert werden kann? Das Testsystem könnte in Unit-Tests verwendet werden und simuliert ein System, ohne tatsächlich Systemaufrufe durchzuführen.
iphydf
am 18. Dez. 2016
Ich stimme dem Umsetzungsvorschlag nicht zu. Ich würde viel lieber alle Funktionen in einer einzigen Datei {network,time,...}.c , wobei #ifdef s verwendet wird, um Funktionen einzuschließen, die für jede Plattform anders geschrieben werden müssen.
Der Vorteil dieser Methode gegenüber separaten Dateien besteht darin, dass wir den gesamten plattformspezifischen Code als statische Funktion erzwingen und eine einzige API für die höheren Toxcore-Ebenen bereitstellen können. Alle Details zur Plattformimplementierung sind in einer einzigen Datei leicht einsehbar. Plattformbesonderheiten erfordern Abstraktion und Handhabung innerhalb einer einzelnen Datei, anstatt über mehrere Dateien hinweg. Es wird auch die Pflege der Datei cmakelists.txt erleichtern (Sie beginnt bereits, uns zu entgehen.) Und spätere Überprüfung mit unserem aktuellen Überprüfungssystem.
GrayHatter
am 30. Dez. 2016
Nicht vollständig behoben
Diadlo
am 27. Jan. 2017
@GrayHatter stimmte zu. Lassen Sie uns eine einzelne Datei haben, die die Betriebssystemspezifikationen implementiert.
Ich hebe die @Diadlo vorerst auf. Ich denke, dies ist ein großartiger Fehler, an dem neue Mitwirkende arbeiten können, da er einen Großteil der Codebasis und des Netzwerkcodes offenlegt. Es ist ein etwas interessantes Refactoring, das keinen Einfluss auf die Funktionalität hat und daher einfacher zu testen ist.
iphydf
am 16. Jan. 2018
Verwandte Themen
tox-user
·
9Kommentare
MrSorcus
·
10Kommentare
zetok
·
3Kommentare
zoff99
·
4Kommentare
SkyzohKey
·
8Kommentare
Hilfreichster Kommentar
Wie wäre es mit einer "System"-Schnittstelle, die durch ein "Windows-System" und ein "Posix-System" und ein "Testsystem" implementiert werden kann? Das Testsystem könnte in Unit-Tests verwendet werden und simuliert ein System, ohne tatsächlich Systemaufrufe durchzuführen.