b'\n_START_ARTICLE_\nC++/CLI\n_START_SECTION_\nZmiany w stosunku do  Managed Extensions for C++\n_START_PARAGRAPH_\nW przeciwie\xc5\x84stwie do Managed C++, b\xc4\x99d\xc4\x85cego \xc5\x9bcis\xc5\x82ym rozszerzeniem C++ (ze s\xc5\x82owami kluczowymi jak __gc czy __value), C++/CLI jest uznawany za osobny j\xc4\x99zyk. Z tego powodu dokonano wielu znacznych zmian w sk\xc5\x82adni._NEWLINE_Wiele nie\xc5\x9bcis\xc5\x82o\xc5\x9bci w sk\xc5\x82adni, jak na przyk\xc5\x82ad r\xc3\xb3\xc5\xbcne dzia\xc5\x82anie jednego operatora new() w Managed C++, zosta\xc5\x82o rozdzielonych: w C++/CLI zarz\xc4\x85dzane typy danych s\xc4\x85 tworzone nowym operatorem gcnew. Poza tym w C++/CLI dost\xc4\x99pne s\xc4\x85 typy generyczne (oparte na szablonach j\xc4\x99zyka C#)._NEWLINE_W Managed C++ istnia\xc5\x82y dwa rodzaje wska\xc5\xbanik\xc3\xb3w: __nogc - zwyczajne wska\xc5\xbaniki z C++ oraz __gc - wska\xc5\xbaniki dzia\xc5\x82aj\xc4\x85ce na typach zarz\xc4\x85dzanych z .NET. W C++/CLI jedyny typ wska\xc5\xbanika to zwyk\xc5\x82y wska\xc5\xbanik C++, a zarz\xc4\x85dzane typy z .NET s\xc4\x85 odwo\xc5\x82ywane przez "uchwyty", z now\xc4\x85 sk\xc5\x82adni\xc4\x85 NazwaKlasy^ zamiast NazwaKlasy*. To rozr\xc3\xb3\xc5\xbcnienie jest najbardziej przydatne gdy mieszany jest kod natywny i zarz\xc4\x85dzany; pozwala na szybk\xc4\x85 identyfikacj\xc4\x99, kt\xc3\xb3re obiekty dzia\xc5\x82aj\xc4\x85 pod od\xc5\x9bmiecaczem .NET, a kt\xc3\xb3re musz\xc4\x85 by\xc4\x87 r\xc4\x99cznie usuwane.\n_START_SECTION_\nFinalizatory\n_START_PARAGRAPH_\nKolejn\xc4\x85 zmian\xc4\x85 w C++/CLI jest sk\xc5\x82adnia finalizatora !NazwaKlasy() - specjalnego niedeterministycznego destruktora, kt\xc3\xb3ry jest uruchamiany, gdy obiekt ma zosta\xc4\x87 zniszczony w ramach dzia\xc5\x82ania od\xc5\x9bmiecacza._NEWLINE_Deterministyczny destruktor ~NazwaKlasy() jest t\xc5\x82umaczony przez kompilator jako wype\xc5\x82nienie metody Dispose() interfejsu IDisposable. Niedeterministyczny destruktor dziedziczy z metody Finalize() bazowej klasy Object._NEWLINE_Deterministyczny destruktor powinien by\xc4\x87 u\xc5\xbcywany, gdy istnieje potrzeba zwolnienia niezarz\xc4\x85dzanych zasob\xc3\xb3w lub zasob\xc3\xb3w ca\xc5\x82ego systemu (po\xc5\x82\xc4\x85czenia sieciowe, strumienie plik\xc3\xb3w itp.). W innych przypadkach powinien wystarczy\xc4\x87 finalizator. Je\xc5\xbceli jest u\xc5\xbcywany deterministyczny destruktor, programista powinien tworzy\xc4\x87 finalizator, kt\xc3\xb3ry tylko sprawdza czy destruktor zosta\xc5\x82 ju\xc5\xbc wykonany i je\xc5\xbceli nie zosta\xc5\x82, powinien wykona\xc4\x87 go (by unikn\xc4\x85\xc4\x87 mo\xc5\xbcliwych wyciek\xc3\xb3w niezarz\xc4\x85dzanej pami\xc4\x99ci/zasob\xc3\xb3w).'