Czy C ++. Net jest szeroko stosowany?

Z założenia jestem programistą C ++. Przez ostatnie 12 miesięcy robiłem dużo kodowania w C # i byłem mile zaskoczony pragmatycznym podejściem C # (raz przestałem próbować kodować tak, jakby to był „C ++ z odśmiecaniem”).

Niedawno mieliśmy kilku absolwentów i pomagając jednemu z nich zdałem sobie sprawę, że używa ona .Net w C ++. Zapytana, dlaczego, powiedziała, że ​​„jej menedżer powiedział jej, by używała C ++”. Pomijając oczywisty problem z komunikacją, zakładam, że używała .Net, ponieważ jest to jedyna platforma, na którą była narażona.

Następnie natknąłem się na stary projekt starszego programisty, który również używał C ++ do sterowania interfejsem Forms. Teraz napisano by to mniej więcej w czasie, gdy pojawił się .Net, więc zakładam, że było to ćwiczenie z jego strony do zabawy z .Net. To była tylko mała aplikacja narzędziowa.

Po drobnych modyfikacjach w tej aplikacji wydawało mi się, że używanie C ++ do prowadzenia .Net daje najgorsze z obu światów. Brak usuwania śmieci lub bezpieczeństwa pamięci, ale podobnie brak rzeczywistych możliwości prędkości / optymalizacji, ponieważ masz do czynienia z zarządzanym środowiskiem.

Moje pytanie brzmi więc, czy ludzie używają C ++ .Net do jakiegokolwiek dużego samodzielnego (tj. Niezwiązanego z instalacją) kodu produkcyjnego, a jeśli tak, to jakie są tego powody? Przyznaję, że nigdy nie zagłębiałem się głęboko w rozszerzenia C ++ .Net, więc może robię to z przykrością.

C ++. NET (lub, dokładniej, C ++ / CLI) nie mają zbieranie śmieci, tak jak wszystko inne, który działa na szczycie .NET. Aby to osiągnąć, zachowując zgodność z poprawnym C ++, używa ^składni i gcnewwskaźników „śmieciowych” („bezpiecznych”).

C ++ / CLI jest uważany przez wielu za obrzydliwość, jest znacznie bardziej nieprzyjemny w pracy niż właściwy C # lub C ++, a także bardziej skomplikowany niż którykolwiek z nich (po prostu dlatego, że wprowadza złożoność samego C ++ do tabeli i dodaje to, czego potrzeba do pracy z .NET do miksu). Nauka języka C # zwykle opłaca się nawet w ramach jednego średniego projektu. Jest jednak jedna rzecz, której nie może zrobić ani C #, ani natywny C ++: kompilacja istniejącego C ++ na platformie .NET i rozmowa z innymi komponentami .NET.

W związku z tym nie ma większego sensu używanie C ++ / CLI do projektu od zera - wszystko, co można z nim zrobić .NET, można również zrobić w języku C #, z dużo ładniejszą składnią i dodatkowym bezpieczeństwem nieujawniania surowego wskaźniki domyślnie. Najbardziej znanym raison-d'etre jest portowanie istniejących baz kodów do .NET. Firma, która decyduje się na rozpoczęcie korzystania z .NET, ale nie chce (lub nie może z powodu ograniczeń zasobów i czasu) przepisać wszystkie oprogramowanie, które do tej pory wyprodukowała, może używać C ++ / CLI, aby nadal korzystać z istniejącej bazy kodu z minimalnymi zmianami, a następnie przepisz komponenty swojego systemu w języku C # jeden po drugim. Przynajmniej taka jest teoria; Nigdy sam tego nie widziałem w praktyce, więc nie mogę powiedzieć, jak dobrze to działa.

Zauważ również, że sam C # może łączyć się z bibliotekami natywnymi, więc nawet jeśli musisz użyć istniejących baz kodu C ++, niekoniecznie musisz je ponownie skompilować z .NET: często lepszym rozwiązaniem jest połączenie się z nimi przez COM lub P / Invoke. .