Jakie są plusy i minusy pisania aplikacji C#/XAML vs. C++/XAML WinRT w Windows8? [zamknięte]

Question

Jakie są plusy i minusy pisania aplikacji C#/XAML vs. C++/XAML WinRT w Windows8? [zamknięte]

Chciałbym przejść do ścieżki przeniesienia komponentu WPF / Silverlight do Windows 8. Dla niektórych kontekstów komponent jest wykresem WPF w czasie rzeczywistym , który wykorzystuje mieszankę renderowania WPF / XAML i bitmapy w celu osiągnięcia wysokiej wydajności.

Chciałbym, aby komponent był kompatybilny z Metro, np. używany w trybie metro, jak również w trybie desktopowym. Dużo czytam o tworzeniu aplikacji C++ / WinRT W Windows 8 jak i C#/XAML, ale jakie są różnice między tymi dwoma frameworkami?

Czy są jakieś ograniczenia jeśli wybierzesz C # / XAML zamiast C++ / XAML? Rozważ również, że przeniesienie z C# / Xaml w .NET4. 0 do Windows8 byłoby o wiele łatwiejsze, gdybym mógł trzymać się C#/XAML, jednak czy będę w stanie stworzyć w pełni funkcjonalny komponent Metro przy użyciu tej metody?

Twoje uwagi/sugestie mile widziane.

Edit:

Jeśli głosujesz za zamknięciem tego wątku, dodaj komentarz dlaczego. To ważne pytanie, ma +6 głosy, cztery odpowiedzi i jeden faworyt. Wydaje się rozsądne, aby zatrzymać to dla mnie!

33

c++windows-8 xaml microsoft-metro

Author: CCovey, 2012-04-05

Source

4 answers

Z perspektywy XAML staje się wyborem języka. Stos interfejsu XAML jest taki sam, niezależnie od tego, który język kodu wybierzesz tutaj. W zależności od celu aplikacji może mieć większy sens używanie C++ , jeśli potrzebujesz korzyści płynących z tego, co zapewnia ten język.

Mamy również możliwość mieszania DirectX i XAML teraz w Win8 i to zwykle oznacza C++ -- jednak z projektów takich jak SharpDX, który nadal nie jest całkowicie poprawny (tak Wiem, że będziesz płacić za wydajność hit w DirectX do owijania w kod zarządzany...Tylko zaznaczam, że da się to zrobić).

Wydaje się, że twoje pytanie dotyczy stworzenia komponentu wielokrotnego użytku, który może być używany na pulpicie i Metro. Może to być nieco trudne, w zależności od tego, jak go zaprojektujesz, ze względu na to, jak pewne zmiany były wymagane do tego, jak zasoby(np.xaml) są ładowane z lokalizacji pliku w porównaniu z osadzonym zasobem.

3

Author: Tim Heuer,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-04-05 16:27:46

Jedyną zaletą, jaką przychodzi mi do głowy użycie C++ / XAML, jest to, że szybkość jest ważna dla Twojego projektu. Zaletą C# / XAML jest to, że jest znacznie łatwiejsze do Kodowania, zwłaszcza jeśli projekt jest już w C#.

Do tej pory nie ma możliwości stworzenia aplikacji, która będzie skierowana zarówno na Metro, jak i na pulpit w Windows 8.

Mam nadzieję, że to pomoże.

2

Author: Kobe,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-04-05 16:29:22

Cóż inni mogą wiedzieć więcej, ale na podstawie Odpowiedzi Microsoftu na pytanie, które postawiłem w okolicach czasu ogłoszenia WinRT:

WinRT jest protokołem i zestawem natywnych API, pozwalających każdemu językowi pozostać wiernym istniejącemu środowisku wykonywania-Chakra dla JavaScript, CLR dla C# i CRT / raw dla C++.

To sugeruje podobne kompromisy wydajności do tego, czego obecnie doświadczamy przy użyciu kodu natywnego CLR, aby uzyskać dostęp do tego, co jest zasadniczo natywnym API kodu (WinRT). Ale nie mogę się doczekać empirycznych badań nad tym, aby zobaczyć, jak różni się WinRT.

2

Author: ZeroBugBounce,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-04-05 16:36:05

score 22 · Accepted Answer

Widzę różnicę jako wybór projektu, niż osobiste preferencje języka. Preferencje byłyby bardziej związane z VB vs C#. Ogólnie rzecz biorąc, te same różnice występują w każdej aplikacji, w której wybierzesz C++ lub. NET.

C++ da ci szybszy czas uruchamiania. IIRC,. NET 4.5 ma możliwości auto NGENing (Nie wiem, jak to jest związane z aplikacjami metro), więc może to pomóc złagodzić typowe powolne czasy uruchamiania aplikacji. NET.

C++ da ci mniejsze ogólne zużycie pamięci ponieważ nie korzysta z Garbage collector. Staje się to coraz ważniejsze na urządzeniach ograniczonych zasobami, takich jak tablety. IIRC,. NET 4.5 ma więcej ograniczeń w przerwach GC (które mogą powodować studder UI UI), nadal są rzeczywistością z zarządzanym kodem.

Ponieważ. NET i C++ używają tego samego frameworka WinRT, prawdopodobnie nie będzie zbyt dużej różnicy w interakcji z platformą XAML / WinRT (technicznie szybsza interakcja z obiektami WinRT przez C++, ale hit jest naprawdę małe), ale oczywiście twój kod użytkownika będzie na ogół szybszy w C++ niż. NET.

C++ jest na ogół trudniejszy do inżynierii wstecznej, nawet w porównaniu z zaciemnionym kodem.NET. Chociaż sprytni złodzieje mogą ukraść Twoje IP niezależnie od tego.

Ponieważ. NET został stworzony jako pierwszy dla wygody programistów i produktywności programistów, będziesz miał więcej wygodnych opcji w architekturze aplikacji (np. narzędzia oparte na odbiciu, takie jak DI/IoC).

Iteracja kod aplikacji może być łatwiejszy dzięki. NET, ponieważ. NET kompiluje się szybciej niż C++, ale poprawnie utworzone projekty C++ można znacznie ograniczyć.

Czyste projekty. NET mogą obsługiwać "dowolny procesor", co oznacza, że Twoja aplikacja może działać na wszystkich obsługiwanych platformach WinRT. Projekty C++ będziesz musiał po prostu przekompilować do wsparcia ARM, x86/64. Jeśli aplikacja. NET zależy od niestandardowego komponentu C++, będziesz musiał skompilować dla każdej architektury.

Ponieważ WinRT został stworzony z od podstaw, aby wspierać wiele języków, Moja propozycja dla programistów, że arent wygodne z C++ jest trzymać się. NET, ale zbadać obszary, które korzystają z C++. Microsoft wykonał świetną robotę z projekcjami /CX i większość programistów C# powinna być w stanie znaleźć drogę. Moja propozycja dla programistów C++ to trzymać się C++ i uzyskać wszystkie zalety C++.