Temat: C++/CLI. Kto jeszcze programuje?

Drogie Koleżanki i Koledzy,

Czy ktoś programuje w C++/CLI oprócz mnie? Czy tylko ja myślę, że to taki dobry język/technologia? Używam go w projektach, gdzie mam do czynienia z natywnym kodem, natomiast muszę wystawić API CLI dla wyższych warstw. Sprawdza się w 100% (jak na razie).
Miałem opory w jego stosowaniu. Ta składnia ... Oczywiście piszę też w C++ oraz C#. Często po kilku tygodniach z C++/CLI po powrocie do C# wydaje mi się, że piszę w jakimś języku ... skryptowym. Myślę sobie "Przecież składnia C# nie może być aż tak łatwa i przejrzysta ;)". W kodzie C++/CLI mam znacznie większą kontrolę nad kodem. Oczywiście można też nieźle "namieszać".W jednym z innych projektów postanowiłem (przez DllImport) importować wszystkie funkcje z bibliotek natywnych. Przy dużej ilości i częstej zmianie API byłem wykończony. Dodatkowo i tak trzeba było czasem pisać wrappera C++ eksportującego, bo część kodu była obiektowa, a obiektu niezarządzanego nie sposób przekazać do C#. Zupełnie inaczej jest w C++/CLI.

Chętnie poznam wasze opinie. W razie potrzeby pomogę doradzę.

P.S. Obawiam się, że nikt nie odpowie.

Temat: C++/CLI. Kto jeszcze programuje?

W C++/CLI pisałem 2 razy w życiu - pierwszy i ostatni :) Po prostu nie trawię tej składni.

Jeśli chodzi o kod natywny czy jakieś inne nisko-poziomowe fiku-miku to nie są to tematy z którymi C# by sobie nie poradził przez marshall'owanie natywnych dll'lek lub kod "unsafe" :)

Temat: C++/CLI. Kto jeszcze programuje?

Maciej Misztal:
W C++/CLI pisałem 2 razy w życiu - pierwszy i ostatni :) Po prostu nie trawię tej składni.

Jeśli chodzi o kod natywny czy jakieś inne nisko-poziomowe fiku-miku to nie są to tematy z którymi C# by sobie nie poradził przez marshall'owanie natywnych dll'lek lub kod "unsafe" :)

Fiku-miku :) I tu jesteś w ogromnym błędzie. Przyznam, że kiedyś też tak myślałem. Otóż w bardzo wielu sytuacjach C# sobie nie radzi, lub nie radzi sobie tak efektywnie jak C++/CLI. C++/CLI wydaje się stworzony do zastosowań native+managed code itd. W C++/CLI masz lepszą kontrolę nad całością rozwiązania. Oczywiście na początku minusem może być fakt, że nie do końca panujesz nad kontekstem wywołania, bo C++/CLI robi to często za nas. Potem (po doświadczeniu) okazuje się że jest to jeden z lepszych "ficzerów". Jego zrozumienie i opanowanie daje dużo swobody. A co do składni - kwestia przyzwyczajenia.
Pierwszy projekt typu managed+unmanaged+firmware+hardware rozpocząłem po stronie łączenie kodów zarządzanego i niezarządzanego właśnie w C#. Głównie przez opinie takie, jak Twoja, że C++/CLI jest zły. Doszedłem szybko do muru. Wydawało mi się, że po prostu dalej się nie da, że .NET ma ograniczenia i koniec.
Kolejny projekt rozpocząłem w C++/CLI i okazało się, że ... nie ma ograniczeń :)

Temat: C++/CLI. Kto jeszcze programuje?

Sławomir Orłowski:
Drogie Koleżanki i Koledzy,

Czy ktoś programuje w C++/CLI oprócz mnie?

Nie zdziwiłbym się, gdyby okazało się, że już tylko Ty programujesz w C++/CLI ;) Sięgając pamięcią przypominam sobie może kilka przypadków kiedy musiałem zrobić coś w C++/CLI. Można by zliczyć te sytuacje na palcach maksymalnie dwóch rąk. Wrażenia jak u reszty populacji - "już wolę w deszczu kopać rowy".

Temat: C++/CLI. Kto jeszcze programuje?

Jarosław D.:

Sławomir Orłowski:
Drogie Koleżanki i Koledzy,

Czy ktoś programuje w C++/CLI oprócz mnie?

Nie zdziwiłbym się, gdyby okazało się, że już tylko Ty programujesz w C++/CLI ;) Sięgając pamięcią przypominam sobie może kilka przypadków kiedy musiałem zrobić coś w C++/CLI. Można by zliczyć te sytuacje na palcach maksymalnie dwóch rąk. Wrażenia jak u reszty populacji - "już wolę w deszczu kopać rowy".

:) Ja również programuję w C# i nie wyobrażam sobie stworzenia aplikacji WindowsForms w C++/CLI. Też wolałbym w deszczu kopać rowy. Ale właśnie oprogramowanie urządzenia USB i wystawienie API do np. WPF C# to jest to, co C++/CLI lubi. Paradoksalnie (wiem, że mi nie uwierzycie) wychodzi to łatwiej i lepiej niż ... w C# (bardzo lubię C#).
W zasadzie to powinienem się cieszyć - jestem jedyny więc ... najlepszy ;)

Temat: C++/CLI. Kto jeszcze programuje?

A zatem - potrzebne moduły w C++/CLI (jeśli z jakichś względów C# nie wystarczy), a logika biznesowa i frontend w C# :)

Grunt, by w pierwszej kolejności dobierać narzędzia stosowanie do potrzeb, a w drugiej kolejności - wedle własnych upodobań.

A że te upodobania bywają różne... sam pamiętam, jak mi na uczelni kółka rysowali ci, którzy pisali w C++ Builderze, a ja w pocie czoła rozkminiałem MFC <łezka> i... 4 bite lata kodowałem w nim aż się kurzyło. Wspierałem się także czystym WinAPI (wygodniej pisało się komunikację w DDE - ktoś jeszcze pamięta, co to było? :)). Potem, gdy dowiedziałem się, że .NET wspiera MFC, byłem przeszczęśliwy ...ale błyskawicznie przerzuciłem się na C# i tak już zostało do dziś.

Ja sobie z kolei nie wyobrażam, jak można pisać cokolwiek dłuższego niż makro Excelowe w VB(.NET) albo Pascalu, zaś mój szef uwielbia Delphiego :P

Oczywiście zawsze dobrze wiedzieć, że są takie czy inne narzędzia.

Temat: C++/CLI. Kto jeszcze programuje?

W zyciu nie mialem z tym do czynienia z C++/CLI generalnie jakos profesjonalnie ominelomisie te galaz jezykow - napisalem jedna funkcje w C - sprawdzanie IBAN dla programu w 4GL ;)

Adrian:
A co do VB(.NET) to mialem taka dewize przez wiekszosc swojej pracy zawodowej ze "nie naucze sie vb!" no i zaczalem pisac w LotusScript na Domino co praktycznie jest VB.... w efekcie i tak czesto siegam do Java'y bo LS (VB) jest jakby ciut ograniczony... a czasem jak mam dosyc Domino i ograniczen to siegam po Python'a :)

Ech... zaspiewal bym cos w ostrym C ale no coz taka praca, koledzy przedemna woleli Domina ukladac zamiast spiewac ;)

Temat: C++/CLI. Kto jeszcze programuje?

Adrian Olszewski:
A zatem - potrzebne moduły w C++/CLI (jeśli z jakichś względów C# nie wystarczy), a logika biznesowa i frontend w C# :)

Myślę, że taka właśnie architektura jest stworzona dla C++/CLI i pod tym względem bronię tego języka. Moim zdaniem nie jest on "kością ogonową" .NET.

Grunt, by w pierwszej kolejności dobierać narzędzia stosowanie do potrzeb, a w drugiej kolejności - wedle własnych upodobań.

Świetnie podsumowanie. Lepiej tego nie można ująć.

A że te upodobania bywają różne... sam pamiętam, jak mi na uczelni kółka rysowali ci, którzy pisali w C++ Builderze, a ja w pocie czoła rozkminiałem MFC <łezka> i... 4 bite lata kodowałem w nim aż się kurzyło. Wspierałem się także czystym WinAPI (wygodniej pisało się komunikację w DDE - ktoś jeszcze pamięta, co to było? :)). Potem, gdy dowiedziałem się, że .NET wspiera MFC, byłem przeszczęśliwy ...ale błyskawicznie przerzuciłem się na C# i tak już zostało do dziś.

Ja sobie z kolei nie wyobrażam, jak można pisać cokolwiek dłuższego niż makro Excelowe w VB(.NET) albo Pascalu, zaś mój szef uwielbia Delphiego :P

Ja zaczynałem aplikacje RAD właśnie w Delphi. Ech VCL w porównaniu do kontrolek dostępnych w .NET 1.1 był jak oaza w porównaniu do Sahary. Object Pascal miał dziwną składnie obiektową - przyznaję. VB to lubią chyba tylko amerykanie (widziałem kiedyś takie badania).

Oczywiście zawsze dobrze wiedzieć, że są takie czy inne narzędzia.

Temat: C++/CLI. Kto jeszcze programuje?

A przypomniało mi się: Wiecie, że w Visual Studio 2010 nie ma IntelliSense dla C++/CLI? Wiem, jest to dowód, że MS ma team C++/CLI gdzieś - ale ja do nich pojadę i im powiem ;)

Temat: C++/CLI. Kto jeszcze programuje?

Ależ nie jest! MS traktuje go poważnie.

C++/CLI is not just an extension of C++ into the managed world. Rather, it represents a fully integrated programming paradigm similar in extent to the earlier integration of the multiple inheritance and generic programming paradigms into the language
http://msdn.microsoft.com/en-us/magazine/cc163852.aspx

I am happy that it makes every feature of the CLI easily accessible from C++ and happy that C++/CLI is a far better language than its predecessor "Managed C++
Bjarne Stroustrup

EDIT: o, nie wiedziałem, że wyciachali IS dla CLI... Dziwne...
EDIT: Tutaj kilka słów develteamu na ten temat: Why We Didn’t Include C++/CLI IntelliSense in Visual Studio 2010. Wygląda na to, że jednak nie było to olanie userów, tylko za dużo mieli z tym problemów i brakło czasu. The good news is that C++/CLI IntelliSense will be in the next version of Visual Studio.

PS: ja mam jeszcze gorzej. Nie wydali edytora raportów do WVD2010 Express :( Trzeba kupić pełną wersję, albo poprzestać na 2008.Adrian Olszewski edytował(a) ten post dnia 05.08.11 o godzinie 12:25

Temat: C++/CLI. Kto jeszcze programuje?

Adrian Olszewski:
Ależ nie jest! MS traktuje go poważnie.

C++/CLI is not just an extension of C++ into the managed world. Rather, it represents a fully integrated programming paradigm similar in extent to the earlier integration of the multiple inheritance and generic programming paradigms into the language
http://msdn.microsoft.com/en-us/magazine/cc163852.aspx

I am happy that it makes every feature of the CLI easily accessible from C++ and happy that C++/CLI is a far better language than its predecessor "Managed C++
Bjarne Stroustrup

O dzięki Ci. Miałem dyskusję wcześniej z kimś, kto twierdził, że MS już nie chce wspierać. Próbowałem mu wytłumaczyć, że chodzi o C++ Managed Extension, a nie C++/CLI, ale jakoś nie miałem argumentów w postaci cytatów. Twoja szybkość googlowania (czy tam bingowania) jest porażająco!

EDIT: o, nie wiedziałem, że wyciachali IS dla CLI... Dziwne...
EDIT: Tutaj kilka słów develteamu na ten temat: Why We Didn’t Include C++/CLI IntelliSense in Visual Studio 2010. Wygląda na to, że jednak nie było to olanie userów, tylko za dużo mieli z tym problemów i brakło czasu. The good news is that C++/CLI IntelliSense will be in the next version of Visual Studio.

To prawda. Mieli problemy, więc nie zamieścili. Nie przesunęli daty releasu. Ale wyobraź sobie, czy zrobiliby tak z C#? "MS: Nie ma IntelliSense w C#. Mieliśmy problemy". Potem NBC News: "Spłonęła siedziba główna Microsoft. Zamaskowani terroryści z dziwnym znaczkiem C# atakują inne siedziby tej firmy krzycząc: zbliża się koniec świata". Moim zdaniem to określa, jak się traktuje developerów C++/CLI. Oczywiście czepiam się trochę, bo jest Visual Assist X ($249) i po sprawie. Wcześniej robiłem coś dosyć głupiego, bo pisałem kod w VS2008 a kompilowałem go w VS2010.

PS: ja mam jeszcze gorzej. Nie wydali edytora raportów do WVD2010 Express :( Trzeba kupić pełną wersję, albo poprzestać na 2008.

Słyszałem właśnie. Kurcze ogólnie mam wrażenie, że VS2010 jest lepsze od VS2008 tylko dla developerów C#. Reszta jest dużo gorsza. Jak sobie włączam VS2008 to działa szybciej, stabilniej. Może to tylko moja subiektywna ocena.

Temat: C++/CLI. Kto jeszcze programuje?

Kwestia tego co kto lubi :) Jeśli miałbym robić jakieś niezarządzane "bebechy" to pewnie zdecydowałbym się na niezarządzaną dll'kę z interface'em w C - konsumowaną przez C#. Wszystko zależy tak na prawdę od przeznaczenia, a z drugiej strony nie ma że "nie da się" :)

Sławomir Orłowski:

Maciej Misztal:
W C++/CLI pisałem 2 razy w życiu - pierwszy i ostatni :) Po prostu nie trawię tej składni.

Jeśli chodzi o kod natywny czy jakieś inne nisko-poziomowe fiku-miku to nie są to tematy z którymi C# by sobie nie poradził przez marshall'owanie natywnych dll'lek lub kod "unsafe" :)

Fiku-miku :) I tu jesteś w ogromnym błędzie. Przyznam, że kiedyś też tak myślałem. Otóż w bardzo wielu sytuacjach C# sobie nie radzi, lub nie radzi sobie tak efektywnie jak C++/CLI. C++/CLI wydaje się stworzony do zastosowań native+managed code itd. W C++/CLI masz lepszą kontrolę nad całością rozwiązania. Oczywiście na początku minusem może być fakt, że nie do końca panujesz nad kontekstem wywołania, bo C++/CLI robi to często za nas. Potem (po doświadczeniu) okazuje się że jest to jeden z lepszych "ficzerów". Jego zrozumienie i opanowanie daje dużo swobody. A co do składni - kwestia przyzwyczajenia.
Pierwszy projekt typu managed+unmanaged+firmware+hardware rozpocząłem po stronie łączenie kodów zarządzanego i niezarządzanego właśnie w C#. Głównie przez opinie takie, jak Twoja, że C++/CLI jest zły. Doszedłem szybko do muru. Wydawało mi się, że po prostu dalej się nie da, że .NET ma ograniczenia i koniec.
Kolejny projekt rozpocząłem w C++/CLI i okazało się, że ... nie ma ograniczeń :)

Temat: C++/CLI. Kto jeszcze programuje?

Maciej Misztal:
Kwestia tego co kto lubi :) Jeśli miałbym robić jakieś niezarządzane "bebechy" to pewnie zdecydowałbym się na niezarządzaną dll'kę z interface'em w C - konsumowaną przez C#. Wszystko zależy tak na prawdę od przeznaczenia, a z drugiej strony nie ma że "nie da się" :)

No i to w standardowych projektach super się sprawdza. Biblioteka w C, "zaciągana" do C#. Jednak przy obiektowym kodzie niezarządzanym zaczyna być pod górkę. Obiektu nie wyeksponujesz bezpośrednio. Trzeba napisać wrapper i "wypłaszczyć". I można wtedy użyć C (w sensie, że nie obiektowe) lub C++/CLI. Wygodniej jest C++/CLI. Masz załatwione od razu API zarządzane i nie musisz się specjalnie troszczyć o cykl życia takiego obiektu, jak to ma miejsce we wrapperze C. Dodatkowo możesz sprawy buforów pośredniczących w transakcjach pomiędzy zarządzanym a niezarządzanym kodem załatwić od razu. Na koniec debugowanie kodu jest wygodniejsze w C++/CLI. To tak na szybko, co mi się przypomniało.

Temat: C++/CLI. Kto jeszcze programuje?

Przyznam szczerze, że nigdy nie spotkałem się z sytuacją gdzie trzeba było napisać coś w natywnym kodzie.

Poruszam się w obrębie aplikacji typu ERP/CRM co może być tego powodem.

Ciekawość jednak mnie zżera dlatego też mam prośbę.
Możesz napisać kilka przykładów z życia wziętych gdzie wypadałoby sięgnąć do rozwiązań opartych o C/C++ (w dowolnej postaci).

Z góry zaznaczam, że potrafię sobie wyobrazić sytuacje gdzie tego typu podejście jest wskazane przy, :
- tworzeniu sterowników,
- tworzeniu engine'u graficznego etc.

Temat: C++/CLI. Kto jeszcze programuje?

Łukasz Szumyło:
Przyznam szczerze, że nigdy nie spotkałem się z sytuacją gdzie trzeba było napisać coś w natywnym kodzie.

Poruszam się w obrębie aplikacji typu ERP/CRM co może być tego powodem.

Ciekawość jednak mnie zżera dlatego też mam prośbę.
Możesz napisać kilka przykładów z życia wziętych gdzie wypadałoby sięgnąć do rozwiązań opartych o C/C++ (w dowolnej postaci).

Z góry zaznaczam, że potrafię sobie wyobrazić sytuacje gdzie tego typu podejście jest wskazane przy, :
- tworzeniu sterowników,
- tworzeniu engine'u graficznego etc.

No właśnie to co napisałeś powyżej :)
Tworzenie sterowników i komunikacja z urządzeniem. Tutaj nawet nie ma specjalnie szans zastosować C#. Jeśli urządzenie nie jest USB, tylko Serial Port, to wtedy C# może być - w końcu ma klasę SerialPort i sama jego obsługa jest prosta. USB to inna bajka.
Obróbka graficzna. Czasem nie wystarczy mocy, czasem pamięci. Ogólnie wygodniej operować na wskaźnikach w tym przypadku (moim zdaniem). W takich operacjach często potrzeba buforów tymczasowych, więc "bezpośrednie" zarządzenie pamięcią jest jak najbardziej wskazane.
Stare rozwiązania dla nowych projektów. Jeśli masz sporo różnego rodzaju kodu niezarządzanego, który działa dobrze, a jego przepisanie do .NET trwałoby wieki, wtedy najlepiej zintegrować go z nowymi rozwiązaniami.
Akwizycja różnego rodzaju danych (np. z kamer CCD). Tutaj zdarza się, że istnieją interfejsy .NET (National Instruments), ale ... kto by ich używał :)
Ogólnie problemy obliczeniowe. Tutaj nie ma się co oszukiwać - C#.NET jest zwyczajnie wolniejszy. Jeśli do tego dochodzi używanie "wspomagaczy", np. Intel Performance Primitives (IPP), to innego wyjścia nie ma.
Kiedyś, kiedyś jak .NET jeszcze był młodziutki zdarzało mi się sięgać po WinAPI. Z różnych powodów. Raz dlatego, że dana funkcjonalność nie była mapowana do .NET. Raz dlatego, że w .NET działała zatrważająco wolno. Przyznam, że teraz to już mi się nie zdarza.
To typy projektów, na które ja się natknąłem w karierze.

Temat: C++/CLI. Kto jeszcze programuje?

Wychodzi na to, że jestem tylko ja ...

Temat: C++/CLI. Kto jeszcze programuje?

Witam,

jestem obecnie w trakcie pisania dużej aplikacji w C++\CLI. Mój wybór na tą technologię padł na skutek moich korzeni wywodzących się z programowania embedded, w którym królował ANSII C, ale nie tylko. W aplikacji wykorzystuję z powodzeniem udogodnienia platformy .NET, jak np WCF do komunikacji klient-serwer, ale także kod natywny, w którym łatwiej mi się obracać, gdy piszę po rejestrach urządzeń embedded zintegrowanych z aplikacją.

Intellisense trochę brakuje, ale można się przyzwyczaić:)

Pozdrawiam,
Krzysiek

Temat: C++/CLI. Kto jeszcze programuje?

Krzysztof Jania:
Witam,

jestem obecnie w trakcie pisania dużej aplikacji w C++\CLI. Mój wybór na tą technologię padł na skutek moich korzeni wywodzących się z programowania embedded, w którym królował ANSII C, ale nie tylko. W aplikacji wykorzystuję z powodzeniem udogodnienia platformy .NET, jak np WCF do komunikacji klient-serwer, ale także kod natywny, w którym łatwiej mi się obracać, gdy piszę po rejestrach urządzeń embedded zintegrowanych z aplikacją.

Intellisense trochę brakuje, ale można się przyzwyczaić:)

Pozdrawiam,
Krzysiek

Nie jestem sam :)
Jeśli przeszkadza Ci brak IntelliSense, to spróbuj Visual Assist X http://www.wholetomato.com/. Co prawda jest gorszy (moim zdaniem) od IntelliSense w VS 2010, ale lepsze to niż nic.

Temat: C++/CLI. Kto jeszcze programuje?

C++/CLI To podstawa u mnie, napisałem w nim cały system zarządzania zamówieniami w naszej firmie. Nie używam jednak zbyt często natywnych bibliotek, w zasadzie tylko w przypadku absolutnej konieczności.

zaczynałem od ANSII C++, może stąd ta decyzja. w C# tez pisze się bardzo przyjemnie. Wszystkie brakujące elementy w C++/CLI można łatwo uzupełnić poprzez napisanie biblioteki dla .NET w C#. Głownie tu chodzi o funkcje sieciowe i związane z wymianą danych ze zdalnymi serwerami.

Jedyną wadę tej platformy na jaką wpadłem, to przy pisaniu operacji asynchronicznych i przemieszczaniu obiektów pomiędzy różnymi elementami, GC czasem nie aktualizuje wszystkich używanych referencji, zwłaszcza jeśli są używane wewnątrz klas.

Temat: C++/CLI. Kto jeszcze programuje?

Krzysztof Furmaniak:
Jedyną wadę tej platformy na jaką wpadłem, to przy pisaniu operacji asynchronicznych i przemieszczaniu obiektów pomiędzy różnymi elementami, GC czasem nie aktualizuje wszystkich używanych referencji, zwłaszcza jeśli są używane wewnątrz klas.

To ciekawe, co piszesz. Mógłbyś dać jakiś konkretny przykład? Bo C++/CLI to tylko język. GC jest elementem .NET Framework i jeśli występuje to w przypadku C++/CLI, to będzie miało również miejsce w C#, VB i innych językach .NET.
Ja sam miałem problem z GC i operacjami asynchronicznymi w C#.NET 2.0. Ciekawe, czy o to samo chodzi.