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

Sławomir Orłowski:

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.

Problem powstał przy tworzeniu managera galerii internetowej. Program łączy się serwerem on-line, pobiera dane asynchronicznie - tutaj na szczęście wszystko działa. Problem powstał przy konstruowaniu mechanizmu pobierania danych do miniatur zdjęć. Z racji, że niektóre sekcje zawierają około 220 ts elementów potrzebne było stworzenie mechanizmu, który utrzymywałby w pamięci tylko te elementy na których użytkownik aktualnie pracuje. zbiór był ograniczony do około 1000 obiektów. Każdy obiekt zawierał klucz obrazka, sam obrazek, oraz adres elementu listy, do którego był przypisany. Podczas pobierania danych asynchronicznie przekazywany był ten obiekt, aby pobrać odpowiedni obrazek z serwera. wszystko było ok, do czasu aż GC nie posprzątał i nie poukładał danych w pamięci. Po tym procesie, wszystkie referencje do przypisanych elementów nie zostały zaktulizowane. Z racji, że tylko proces główny może zmieniać elementy UI, cała operacja kontroli pamięci podręcznej była wykonywana w osobnym procesie. O szczegółach szerzej możemy porozmawiać na PW, sam mechanizm jest dość skomplikowany, a tutaj tylko przedstawiam ogólny zarys o co chodziło. Dodatkowo jest jeszcze jedna niedogodność, ale na razie dotyczy tylko C# jak zauważyłem - jakikolwiek wyjątek się pojawi w osobnym procesie, proces się zakańcza, niezależnie od tego, czy wyjątek zostanie przechwycony, czy nie.

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

Krzysztof Furmaniak:

Sławomir Orłowski:

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.

Problem powstał przy tworzeniu managera galerii internetowej. Program łączy się serwerem on-line, pobiera dane asynchronicznie - tutaj na szczęście wszystko działa. Problem powstał przy konstruowaniu mechanizmu pobierania danych do miniatur zdjęć. Z racji, że niektóre sekcje zawierają około 220 ts elementów potrzebne było stworzenie mechanizmu, który utrzymywałby w pamięci tylko te elementy na których użytkownik aktualnie pracuje. zbiór był ograniczony do około 1000 obiektów. Każdy obiekt zawierał klucz obrazka, sam obrazek, oraz adres elementu listy, do którego był przypisany. Podczas pobierania danych asynchronicznie przekazywany był ten obiekt, aby pobrać odpowiedni obrazek z serwera. wszystko było ok, do czasu aż GC nie posprzątał i nie poukładał danych w pamięci. Po tym procesie, wszystkie referencje do przypisanych elementów nie zostały zaktulizowane. Z racji, że tylko proces główny może zmieniać elementy UI, cała operacja kontroli pamięci podręcznej była wykonywana w osobnym procesie. O szczegółach szerzej możemy porozmawiać na PW, sam mechanizm jest dość skomplikowany, a tutaj tylko przedstawiam ogólny zarys o co chodziło. Dodatkowo jest jeszcze jedna niedogodność, ale na razie dotyczy tylko C# jak zauważyłem - jakikolwiek wyjątek się pojawi w osobnym procesie, proces się zakańcza, niezależnie od tego, czy wyjątek zostanie przechwycony, czy nie.

No to wracam do gry :) Odgrzewam tematy:
w C++/CLI użyć trzeba pin_ptr i GC nie fragmentuje pamięci, która jest zarezerwowana dla obiektu znajdującego się pod wskazanym adresem. W C# jest fixed.

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

C++/CLI jest niezastapiony jako interfejs c++ => c# (jak chcemy z native c++ uruchomic modul w C#)

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

Nie liczy się tylko użyteczność ale i elegancja języka a c++.cli jest elegancki. Tak jak śpiew w niektórych naturalnych językach jest nie do przyjęcia, tak samo z językami programowania. Po prostu wtedy rośnie wydajność i niezawodność programisty. Ostatecznie najbardziej wydajne są asemblery i macro asemblery ale nie cieszą się zbytnią sympatią programistów.Kryterium elegancji jest trudno obliczalne ale ma znaczenie. Po co używać IDE kiedy może to załatwić pierwszy lepszy edytor ogólnego przeznaczenia.