Managed C++

[dee]

Na jedno pitanje nikako da si u glavi poslozim odgovor pa ako tko ima kakvo smisleno objasnjenje, nek podijeli.

Dakle, zasto bi itko pozelio pisati managed C++?

[Gruja]

To je najbrži put ako imaš puno već napisanog C++ koda koji hoćeš da integrišeš u neki .Net projekat.
Drugi razlog je ako hoćeš nešto više da radiš direktno sa Win API-jem, za stvari koje nisu pokrivene framework-om. Može to i iz drugih managed jezika ali ovde već imaš gotove WINAPI strukture, samo uključiš odgovarajući header.

[dee]

Koliko sam ja shvatio Windows Interop Services omogucavaju i koristenje unmanaged koda unutar managed okoline. Zasto onda ne koristiti to (pogotovo za kod koji je vec napisan)?

[DejanVesic]

Prosto, dobijaš najbolje od oba sveta. Ako si iskusan C++ programer, onda:

- možeš iskoristiti postojeći source kao osnovu kao i tvoje znanje jezika
- dobijaš prednosti .Net sveta (garbage collection, assembly management, bolji security model, više deployment opcija, gomilu gotovih biblioteka itd)

Naravno, ovo ako treba da praviš / učestvuješ u .Net projektu koji nije heavy orijentisan na IO / device drivers - iako ti možeš da ovo radiš i u .Net-u, prelazak između granica managed / Win32 je prosto previše skup.

[dee]

Pitanje se zapravo rodilo jer pisati C++ za managed okolinu zvuci kao pucati si u nogu jer unmanaged kod moze postojati i sam za sebe, a istovremeno moze biti i koristen iz managed okoline.

Drugim rijecima, nije li pisanje C++ koda za .NET limitirano na ono sto framework moze? Samim tim i redukcija mogucnosti C++? A istovremeno, iz frameworka se moze koristiti unmanaged eksterni kod normalno pa mi je tesko zamisliti slucaj gdje bi managed C++ imao svrhu jer, ako se i radi ovo sto pricas (IO & so) onda ni sam .NET nije najbolji izbor. Ili?

(Ovo ne tvrdim vec pitam posto nemam iskustva a zvuci mi nelogicno)

[DejanVesic]

Kao što rekoh - ako se radi u okviru .Net projekta nešto u C++ (iz bilo kog razloga) a da pritom taj kod ne pristupa low-level stvarima (hardver), potpuno ima smisla raditi u managed C++. Pri tom, kada kažem "low-level" baš mislim na hardver, a ne na File IO (koji sasvim lepo radi i u .Net Frameworku).

Ako se pak radi na low-level stvarima i van .Net projekta - onda unmanaged C++

Da je jedno od dva rešenja bolje (unmanaged / managed C++), ono drugo ne bi ni postojalo :-)

Jezik / framework biraš prema problemu koji rešavaš i prema znanju onog ko problem treba da reši.

[dee]

Mozes li navesti neki konkretan primjer gdje bi bilo bolje unutar .NET projekta koristiti managed C++, a da to ne bi bilo moguce/dobro izvesti pozivanjem unmanaged koda iz .NET projekta? I, naravno, zasto ne tako?

[DejanVesic]

Hm, hajde da probam opet:

- ako imam programera koji zna C++
- ako je projekat (ostatak projekta) u .Net Frameworku
- ako se ne pristupa direktno hardveru

ONDA

- će programer raditi u managed C++

JER

- je pozivanje preko InterOp-a (WIN32) SKUPO i u datom slučaju POTPUNO NEPOTREBNO.

Pozdrav,
Dejan

[Dragi Tata]

Evo primera: Imaš 10 godina staru C++ aplikaciju (npr sa MFC-om) koja lepo vrši posao i nema nikakvog smisla da se raspiše od početka u C#u, ali treba da koristiš nove .NET komponente (bilo iz frejmvorka ili 3rd party). Možeš da koristiš recimo COM za to, a možeš i C++/CLI. Ovaj drugi pristup ume da bude daleko lakši i prijatniji, posebno ako treba da debuguješ nešto.

[dee]

Sad je jasnije.

Hvala.