Windows 8 wprowadza WinRT, który jest podobny do .NET, ale niezarządzany. Dlaczego jest niezarządzany? Czy to problem z wydajnością? Czy to oznacza, że wyrzucanie elementów bezużytecznych nie jest odpowiednie dla interfejsów API niższego poziomu?
c#
.net
windows-8
windows-runtime
user380719
źródło
źródło
Odpowiedzi:
WinRT jest zamiennikiem starego Winapi opartego na C. Jest to interfejs API, który musi być użyteczny w wielu środowiskach wykonawczych. 20 lat temu współdziałanie z interfejsem API C było stosunkowo łatwe. To się zmieniło od tego czasu, COM stał się uniwersalnym klejem w drugiej połowie lat 90. Praktycznie każde środowisko uruchomieniowe języka, które jest powszechnie używane w systemie Windows, obsługuje model COM.
Moduł odśmiecania pamięci to szczegół implementacji języka uruchomieniowego. Na przykład moduł zbierający dla platformy .NET bardzo różni się od modułu zbierającego dla języka JavaScript. Obiekty natywne utworzone w obu muszą przestrzegać bardzo ścisłych zasad kolekcjonera. Co z kolei oznacza, że musieliby tworzyć wersje WinRT, które są specyficzne dla każdego środowiska uruchomieniowego języka. To nie wystarczy, nawet firma tak duża jak Microsoft nie może sobie pozwolić na stworzenie i obsługę określonej wersji WinRT dla każdego powiązania językowego. Nie jest też konieczne, biorąc pod uwagę, że języki te już obsługują COM.
Obecnie najlepszym powiązaniem dla WinRT jest C ++, ponieważ model COM działa wydajniej z jawnym zarządzaniem pamięcią. Z dużą pomocą nowych rozszerzeń kompilatora C ++, które czynią go automatycznym, bardzo podobnym do starego _com_ptr_t ze składnią podobną do C ++ / CLI, aby tego uniknąć. Powiązanie z językami zarządzanymi jest stosunkowo proste, ponieważ środowisko CLR ma już doskonałą obsługę międzyoperacyjną COM. WinRT przyjął również format metadanych .NET. Ahaik, na dzień dzisiejszy nie wykonano żadnej pracy nad zarządzanymi kompilatorami.
EDYCJA: Larry Osterman, znany programista i bloger firmy Microsoft, zostawił dość dobry komentarz w usuniętej odpowiedzi. Zacytuję to tutaj, aby go zachować:
źródło
IInspectablena wykonywanie takich rzeczy, jak zapytanie obiektu o jego rzeczywisty typ klasy lub listę wszystkich obsługiwanych interfejsów, a z plikami winmd można rzutować metadane WinRT dla tego wszystkiego do Reflection ). Pliki winmd nie nadają się do natychmiastowego użycia jako zespoły międzyoperacyjne, CLR musi je specjalnie obsługiwać.WinRT jest niezarządzany, ponieważ ma być zamiennikiem Win32 - najniższego poziomu dostępnego dla programistów API dla Windows. Niezarządzany interfejs API jest nadal najbardziej potencjalnie wydajnym interfejsem, który może zostać ujawniony deweloperowi, a rozumowanie jest takie, że zawsze będzie można umieścić na nim zarządzany interfejs API, co jest dokładnie tym, co robią „projekcje”.
Oznacza to również, że programiści C ++ mogą używać WinRT bez przeskakiwania przez obręcze, które wprowadza C ++ / CLI (patrz http://www2.research.att.com/~bs/bs_faq.html#CppCLI ). Oznacza to jednak, że nadal będziesz musisz studiować COM, jeśli chcesz korzystać z WinRT.
Prawdziwe pytanie brzmi: „dlaczego COM jest konieczny? dlaczego Microsoft musiał to wymyślić? Ponieważ zwykły C ++ bez wszystkich dodatkowych udogodnień COM jest nieadekwatny do prawdziwej pracy OOP, a twierdzenia Stroustrupa o C ++ zapewniającym „przenośność” są bardzo nieszczere w świetle rzeczywistości roboczej. Zobacz http://webmechs.com/webpress/2011/11/c-versus-objective-c-as-api-substrate/
źródło