2009-04-01 9 views
8

C++/CLI jest bardzo potężnym językiem. Jest to jedyny język CLR, w którym można płynnie łączyć kod zarządzany i niezarządzany. Ilu programistów (na tej stronie) używa tego języka? W jakich projektach go używasz? Czy jest to adaptacja starego kodu lub stworzenie oryginalnego oprogramowania? Czy możesz porównać stary Managed C++ z nowym C++/CLI? Co sądzisz o obecnej jakości i przyszłości C++/CLI?Proszę opisać doświadczenie korzystania z Microsoft C++/CLI

Odpowiedz

5

Użyłem C++/CLI do projektu symulacyjnego. Mój silnik symulacyjny, który wykonuje rzeczywiste obliczenia, był istniejącą bazą kodu napisaną w C++. Potrzebowałem do tego interfejsu front-end GUI, który z powodzeniem kodowałem w C++/CLI.

Moim zdaniem, język jest równie łatwy do kodowania jak C#, choć z lekką nieporęcznością składniową. To powiedziawszy, składnia jest znacznie prostsza niż ta, którą Microsoft wymyślił wcześniej.

Jedną z najpotężniejszych cech C++/CLI musi być możliwość przekompilowania istniejącego natywnego kodu C++ do MSIL. Oczywiście może wystąpić czkawka, ale w przypadku większości aplikacji powinno to być bezproblemowe ćwiczenie.

Jeśli chodzi o przydatność C++/CLI, myślę, że pozostanie to ściśle językiem dla współdziałania z C++. Jeśli piszesz zupełnie nową aplikację, nie ma absolutnie żadnego powodu, aby wybrać C++/CLI zamiast, powiedzmy, C#. Jak już wspomniałem, jest on nieco bardziej niezręczny w użyciu niż ten drugi.

3

C++/CLI był wyjątkowo prosty do wprowadzenia CLR into FreeSWITCH. O wiele łatwiejsze niż radzenie sobie z hostingiem API lub używanie Mono.

Ostatni raz przed tym użyłem zarządzanego C++ w 2003 roku. Pamiętam, że to trochę boli i nie działa tak płynnie.

+1

Zastanawiam się, czy można używać funkcji C++/CLI w mieszaniu kodu zarządzanego i niezarządzanego w aplikacjach wieloplatformowych? Lub jest to możliwe tylko w wersji Windows? – macropas

+0

Ostatni sprawdziłem, Mono go nie obsługuje. – MichaelGG

8

Użyłem go do napisania cienkich warstw integracji kodu zarządzanego i natywnego. To wszystko.

Najbardziej znaną unikalną cechą tego urządzenia jest możliwość bezproblemowego zagłębiania się w niezarządzanym kodzie i modyfikowania (lub przypadkowego uszkodzenia) jakiejkolwiek części pamięci w całym procesie - to nie jest zaleta w programowaniu ogólnym, ale kiedy jest to potrzebne , wspaniale. Ale myślę, że będę go coraz mniej potrzebować. Możesz skompilować C++/CLI z flagą/pure, ale wtedy naprawdę staje się zupełnie nowym językiem.

Istnieją dwa inne duże unikalne cechy choć:

  • destruktory, które robią coś pożytecznego. W języku C# destruktor jest finalizatorem. W C++ jest to właściwy, deterministycznie nazywany destruktor. Oznacza to, że C++/CLI ma najbardziej kompletną infrastrukturę do pracy z IDisposable. C# pomaga tylko klientom (za pomocą instrukcji przy użyciu instrukcji), ale tylko C++/CLI pomaga również implementorom. Mam nadzieję, że być może pewnego dnia C# zaabsorbuje tę funkcję.

  • Szablony do pisania kaczkami, które mogą być używane razem z generycznymi CLI. Kolejna rzecz, która byłaby bardzo przydatna w języku C#, chociaż można by ją sprawić dużo płynniej bez historycznego bagażu.

Ale C# jest wystarczająco dobre bez dwóch ostatnich rzeczy, których nie mam ochoty używać C++/CLI ogólnie.

+1

Czy chcesz powiedzieć, że C++ ma większą kontrolę nad GC i możliwe jest natychmiastowe zwolnienie pamięci? – macropas

+2

W C++/CLI można przydzielić i zwolnić pamięć tak jak w tradycyjnym C++, a destruktor C++ jest automatycznie narażony na działanie CLR jako Dispose(), tj. Można wykonywać prawdziwe C++ RAII z ​​obiektami .NET. Ale nie masz większej kontroli nad GC - możesz tylko określić, gdzie jest używany, a gdzie nie. – OregonGhost

+1

@macropas - OregonGhost jest poprawny; jeśli przez GC masz na myśli GC CLR, to C++/CLI nie ma nad nim większej kontroli niż jakikolwiek inny język. –

4

Używamy intensywnie C++/CLI.Użyliśmy go do przeciągnięcia starzejącej się aplikacji MFC do wieku .Net, abyśmy mogli teraz napisać najbardziej nową funkcjonalność w C# i zintegrować ją ze starszym kodem MFC za pomocą C++/CLI, zarówno poprzez pakowanie klas natywnych, jak i pisanie nowych zarządzanych obiektów biznesowych. . W naszych starych zestawach wciąż tworzymy nowe funkcje w C++/CLI.

Nie mam doświadczenia z "zarządzanym C++", ale C++/CLI jest przyjemnością w użyciu w porównaniu do MFC i Visual C++. . Ma znacznie czystszą składnię niż zarządzane C++ lub Visual C++ i nie mieliśmy żadnych problemów, aby nawet młodsi twórcy mogli z niej skorzystać.

Jest bardzo mało interesujących zachowań w C++/CLI, np. Kiedy przekazujesz natywny obiekt do metody na zarządzanej klasie, umieszcza on cienki otoczony opakowaniem wokół natywnego obiektu (niewidoczny dla programisty) tylko w celu nawiązywania połączenia, ale ta podkładka jest prywatna dla użytkownika, więc nie można jej wywołać z zewnątrz. Są na to sposoby, jak zawsze, ale kilka razy nas zaskoczyło.

Używamy Visual Assist X do wspomagania refaktoryzacji (akceptowalne), MbUnit/Gallio do testowania jednostek zarządzanych klas i NMock lub RhinoMocks dla naszego szyderczego frameworka.

Ogólnie rzecz biorąc, powiedziałbym, że język uratował nasz produkt i pozwala nam wykorzystać wszystkie nowe ekscytujące rzeczy, które dzieją się w świecie programowania. Gdybyśmy nadal używali wyłącznie Visual C++/MFC, mielibyśmy problemy z rekrutacją deweloperów i byliby znacznie bardziej ograniczeni w wyborze COTS niż używamy .Net.