Habe nun für das Projekt ein github Repository eingerichtet (mein letztes freies Repository bei github, denn man hat nur fünf kostenlose).
https://github.com/rplantiko/swepar/
Grund dafür war vor allem die Sorge um Datenverlust: Da ich mittlerweile schon recht viele Änderungen gemacht habe, würde mich ein Datenverlust weit zurückwerfen.
Als nächstes werde ich mich mit der Logik für den Dateinamen beschäftigen. Auch da finde ich für meinen Geschmack zu viel Code vor. Es darf nicht schwer sein, aus einer Planetennummer und einem Datum das relevante Ephemeridenfile zu ermitteln.
Was mich noch stört: Das Durchschleusen fataler Fehler durch die Aufrufhierarchie. Ein fataler Fehler ist es z.B., wenn ein Ephemeridenfile nicht geöffnet werden kann. Nur um diesen Fall abzubilden, enthät der Aufruf jeder Funktion lästigen Boilerplate-Code: Nämlich das Entgegennehmen des Return-Codes und das Verlassen der aktuellen Stack-Ebene, falls es sich um einen fatalen Fehler handelt.
Alternative wäre der C-Vorläufer zu throw: Die Funktion longjmp(), mit der ich bei fatalen Fehlern direkt zu der höchstmöglichen Stackebene springen kann. Dies werde ich gewissermassen als eine private Version von throw für sweph.c einführen.
Die globale Datenstruktur struct swe_data swed, die so ziemlich alles enthält, was in sweph.c Rang und Namen hat (und auch so manche No-Name-Daten, die man vielleicht guten Gewissens herausschmeissen kann), wird nun noch auf oberster Stackebene verwendet - beim Einsprung aus den API-Funktionen swe_calc etc., die aus Kompatibilitätsgründen nicht die Möglichkeit bieten können, einen Zeiger auf diese Struktur als Parameter mitzugeben. Ansonsten gibt es in meiner Version von sweph.c (also in test_calc_reduce.c) keine direkten Zugriffe mehr auf diese globale Struktur.
Keine Kommentare:
Kommentar veröffentlichen