Overstap van C++/MFC naar C#/.Net, ervaringen?

[Verwijderd]

Bij het bedrijf waar ik werk worden momenteel alle applicaties ontwikkeld in C++/MFC. Echter, qua techiek is MFC aardig aan het verouderen en in .Net zitten eigenlijk vaak al de zaken die we in de loop der jaren in onze eigen 'Common' libraries gestopt hebben (en .Net bevat uiteraard nog veeeel meer handige componenten).

Nu ben ik aan het uitzoeken of het zinvol is om een keer een nieuwe applicatie te gaan ontwikkelen in C#/.Net om hier gewoon eens gevoel voor te krijgen (en wat in-house ervaring want we hebben al wat stagiaires gehad die geen C++ kenden maar wel C#).

De applicatie die we op het oog hebben als test project is een beeldverwerkings applicatie die zou gebruik moeten gaan maken van de OpenCV library (misschien verpakt in een C++ .dll die via het Platform Invoke mechanisme gebruikt moet worden). In eerste instantie is C# dan bedoeld voor de GUI.

Nu voordat we hier aan gaan beginnen ben ik wel benieuwd naar ervaringen van andere die het migratie pad naar C#/.Net ook doorlopen hebben (of er misschien nog middenin zitten?)

Waar zijn jullie tegenaan gelopen en wat is meegevallen en/of tegengevallen?

[Verwijderd]

Hmm, niemand hier die eerst programmeerde in C++ en nu C# gebruikt en daar een mening over heeft??

[__fred__]

Ik ben wel vanuit c++ en delphi in C# gaan programmeren. Voor mij was Borland Builder en Delphi al een verademing t.o.v. de MFC, omdat dingen die eerst 1000 regels code in MFC kostten, nu in 100 regels m.b.v. de VCL opgelost konden worden. De opstap naar .NET was niet zo heel groot, gewoon een kwestie van de library een beetje leren kennen en het winforms gedeelte leek vrij veel op de VCL componenten.

Wat betreft de taal geeft C# een wat cleaner gevoel dan C++. Ik dacht dat ik pointers zou gaan missen, maar dat valt mee. Ik ben met .NET 1.0 begonnen, iets wat ik toen vooral miste waren template classes, maar dat is opgelost met Generics. Multiple inheritance is iets wat je zult moeten ontberen, maar dat mis ik niet heel erg. Voor mijn gevoel ben ik nog steeds niet blij met de JIT compiler en de IL, wat mij betreft had .NET direct naar native code mogen compileren, maar daar heb je nu ngen voor. Verder heb ik een haat liefde verhouding met de Garbage Collector. Het is heel relaxed om niet meer over deallocation te hoeven nadenken, maar er zit twee addertjes onder het gras: Objecten die native of shared resources gebruiken moeten Expliciet gedisposed worden, dus moet je er nog steeds over nadenken. Vooral beginnende .NET-ters willen dat nog wel eens vergeten in mijn team. En als je ergens vanuit een live object een referentie houdt naar een object waarvan je dacht dat ie out of scope was, dan heb je alsnog een memory leak. Dat gebeurt dus wel eens hier. Dus je ontkomt nog steeds niet aan een goede memory profiler.

Dingen die voor mij prettig waren: Geen forward declaraties meer, geen gezeik met precompiled headers, geen idioot lange compilatietijden, betere foutmeldingen van de compiler, automatische boundchecks, geen zoektochten meer naar random gedrag als je weer eens een boolean vergeten bent te initialiseren, een waarschuwing als je een GUI object perongeluk van een andere thread dan de hoofdthread benadert. Etc. etc.

Voor openCV is trouwens een .NET wrapper die je misschien een hoop tijd kan besparen, maar ik weet niet of het een beetje compleet en van goede kwaliteit is.
http://code.google.com/p/opencvdotnet/

[Verwijderd]

Ik heb aardig wat ervaring met het omzetten en gebruiken van bestaande C++ applicaties vanuit C#. Op zicht is dit goed te doen wij zijn tegen de volgende zaken aangelopen.

- Onze COM componenten (ATL) waren niet compleet, de IDL was niet compleet gedocumenteerd [oleautomation] attribuut vergeten etc. Gebruik maken van types van argumenten op interfaces die niet te marshalen waren via de standaard marshaler. In het gebruik binnen C++ gaf dit geen problemen echter toen we via COM interop gingen werken gaf dit problemen.

- Het gebruiken van Com interop of Pinvoke is traag. Doe wat performance testjes voordat je dit inzet. Je kan altijd een eigen managed C++ component inzetten voor de interface (je hebt dan wat meer controle).

- Het zetten van een referentie naar een COM component vanuit een .Net project genereerd onder water een soort proxy die je mee moet installeren met je applicatie. Deze proxy heeft altijd het versie nummer 1.0. Dit kan leiden tot wat installatie problemen etc (niet updaten van de proxy).

- Implementeer binnen je classe in .Net die het COM object gebruikt een IDispose interface en gebruik Marshal.ReleaseComObject() voor het releasen. Officieel schijnt de garbage collector het te doen maar dat kan wel eens lang duren.

Misschien dat je ipv een dll een ATL COM component zou kunnen maken voor de communicatie naar de unmanaged wereld. Ik weet dat dit wat makkelijker werkt vanuit .Net dan met pinvoke. Je zit dan wel weer met registreren e.d.

[Verwijderd]

__fred__ schreef op maandag 15 oktober 2007 @ 10:23:
Voor openCV is trouwens een .NET wrapper die je misschien een hoop tijd kan besparen, maar ik weet niet of het een beetje compleet en van goede kwaliteit is.
http://code.google.com/p/opencvdotnet/

Als eerste bedankt voor de uitleg! Erg duidelijk en het sterkt me in mijn voornemen om het gewoon eens te gaan proberen. De argumenten kan ik ook goed gebruiken in verdere discussies hier in het bedrijf.

Dat opencvdotnet had ik ook al gevonden. Helaas is de ontwikkeling ervan gestopt maar de sourcecode is gelukkig beschikbaar zodat ik zelf eventueel nog verder kan gaan met het inbouwen van de functionaliteit zoals ik die nodig heb.

Ik kwam laatst ook op codeproject het AForge framework tegen (ook te vinden op code.google.com op http://code.google.com/p/aforge/). Dit ziet er ook goed uit hoewel ik een beetje bang ben voor de performance maar het is zeker het proberen waard.

[Verwijderd]

Verwijderd schreef op dinsdag 16 oktober 2007 @ 15:07:
Ik heb aardig wat ervaring met het omzetten en gebruiken van bestaande C++ applicaties vanuit C#. Op zicht is dit goed te doen wij zijn tegen de volgende zaken aangelopen.

- Onze COM componenten (ATL) waren niet compleet, de IDL was niet compleet gedocumenteerd [oleautomation] attribuut vergeten etc. Gebruik maken van types van argumenten op interfaces die niet te marshalen waren via de standaard marshaler. In het gebruik binnen C++ gaf dit geen problemen echter toen we via COM interop gingen werken gaf dit problemen.

Daar was ik ook al bang voor ja. Gewoon integers en strings als argumenten doorgeven zal geen probleem zijn, alleen de uitgebreidere structs/classes wel...

- Het gebruiken van Com interop of Pinvoke is traag. Doe wat performance testjes voordat je dit inzet. Je kan altijd een eigen managed C++ component inzetten voor de interface (je hebt dan wat meer controle).

Ok, daar moet ik dan inderdaad eens mee gaan testen. Het programma moet interlaced 50 fields per seconde verwerken (en tonen op het scherm) maar ik kan hier wel wat smokkelen door bijvoorbeeld alleen de 'even' frames te laten zien.

- Het zetten van een referentie naar een COM component vanuit een .Net project genereerd onder water een soort proxy die je mee moet installeren met je applicatie. Deze proxy heeft altijd het versie nummer 1.0. Dit kan leiden tot wat installatie problemen etc (niet updaten van de proxy).

Kijk, dit is ook iets om in de gaten te houden, (ik kan me ook niet herinneren dat dit in de 70-536 exam guide in de interoperability stukken beschreven stond, grr ).

- Implementeer binnen je classe in .Net die het COM object gebruikt een IDispose interface en gebruik Marshal.ReleaseComObject() voor het releasen. Officieel schijnt de garbage collector het te doen maar dat kan wel eens lang duren.

Ik had ook al gehoord dat soms die garbage collector zijn eigen gang gaat en dat het niet mogelijk was om hem/haar tijdens wat performance kritische stukjes even te 'suspenden'. Zit hier ook een kern van waarheid in?

Jij ook erg bedankt voor je input!

[Verwijderd]

Verwijderd schreef op woensdag 17 oktober 2007 @ 11:26:
[...]
Ik had ook al gehoord dat soms die garbage collector zijn eigen gang gaat en dat het niet mogelijk was om hem/haar tijdens wat performance kritische stukjes even te 'suspenden'. Zit hier ook een kern van waarheid in?

Het is niet mogelijk om hem stil te zetten (voorzover ik weet). Er zijn wel twee soorten garbage collectors nl. de server en de workstation variant, wellicht is het handig om te kijken wat de verschillen zijn en welke je wilt gaan gebruiken. Het is namelijk in te stellen via een configuratie file van je applicatie. Het kan dus voor jouw applicatie volkomen terecht zijn om de server variant te gaan gebruiken. Ik heb geen goed zicht over de applicatie dus kan daar niets over zeggen.

Verder zou ik mezelf niet te druk maken over de garbage collector. De meeste generaties (generatie 0 collects) duren op een gemiddelde pc zo'n 10ms. Mocht je bezig zijn met een applicatie waarbij de timing wellicht erg belangrijk is. Dan kan je ook nog besluiten om zelf de garbage collector te starten op tijden dat het jouw uitkomt.

Wat je dan zou kunnen doen is meten hoe lang het duurt voordat de garbage collector langskomt en dan vervolgens zelf in je applicatie de helft van die tijd nemen en dan de collect starten. GC.Collect();
Dit wordt wel afgeraden door Microsoft omdat de garbage collector zelf tuned is. Maar soms in kritische applicaties heb je geen keuze.

succes met de applicatie.