Coding with Titans

so breaking things happens constantly, but never on purpose

Aktualne prace nad TytanNET

Projekt ten zajmuje mi już ponad rok czasu i ciągle zauważam jak wiele drobnych rzeczy może wpływać na wydajność oraz jakość pracy. To, czemu aktualnie poświęcam najwięcej uwagi – to automatyczne generowanie kodu w Visual Studio.

W aktualnym założeniu - kod ten powstaje w oparciu o relacje pomiędzy modułami w projekcie i nie wnosi żadnej funkcjonalności prócz “przepisania” typów (klas i struktur) z jednego API na inne (czytaj: C/C++ na C#/VB.NET, a kiedyś może i odwrotnie). Kod taki dla programisty jest raczej nużący i mało ciekawy, a sam proces bardzo podatny na błędy. W większości dają one o sobie znać dopiero podczas działania programu. Propozycją jest tutaj odpowiedni analizator, który załatwi w jednym kroku całą sprawę, przeglądając wejściową bibliotekę, odczyta z niej publiczne dane i udostępni generatorowi.

Przykład z życia: tworzymy moduł .NET, który zajmie się testowaniem middleware’u napisanego w C/C++. Wspieramy leciwy już projekt, a idąc z duchem czasu zauważamy, że testy dużo lepiej pisze się i utrzymuje w .NET – zwłaszcza mając pod ręką Microsoft Test Framework.

Wszystkie metody/funkcje i typy trzeba wówczas “ręcznie” przepisać z uwzględnieniem składni języka docelowego. Koszt ogromny i to tylko po to, aby móc te metody wywołać. Pomijamy na ten czas fakt, iż jeśli wspieramy jednocześnie wersję desktop .NET Framework 2.0+ i embedded CF .NET 2.0+, to zawsze pojawiają się małe, choć istotne różnice, o których trzeba pamiętać.

Wersję “beta” rozwiązania, które czyta eksportowane funkcje bezpośrednio z plików COFF (*.dll, *.exe) będzie można niedługo podziwiać w TytanNET v0.20.