|
Managed C++
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++? |
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. |
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)?
|
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. |
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) |
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. |
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?
|
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 |
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.
|
Sad je jasnije.
Hvala. |
| Vreme je GMT +2. Trenutno vreme je 03:55. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.