Jag har fått i uppdrag att göra ett C++-program för simulering av realtidsdata (med OPC). Jag kan C++ men har jobbat mest med C (massa gammla program att uppdatera). Jag har dessutom på min fritid jobbat en hel del med C# och VB.NET.
Men nu undrar jag vilken teknik jag ska försöka lära mig för denna uppgift om jag vill ha det hyfsat snabbt (ska kunna hantera 1000-tals världen på en gång). Ska jag försöka lära mig MFC eller ska jag använda .NET? Jag är lite orolig för hastigheten i .NET, tror ni det har någon betydelse?

Till saken hör att det framework jag använder INTE är skriver med .NET. Där används istället ren C++ och WIN32API

Någonstans där jag snabbt kan få grunderna i MFC eller Managed C++

MFC är en förlegad teknik, och överlag ganska otrevlig. Frågan är snarare vad du ska göra.
Behöver du ett grafiskt gränssnitt, eller klarar du dig med en konsoll?

Behöver du grafiskt för C++, finns det i princip tre varianter att gå i windows:
1. MFC eller WinAPI (MFC är i stort sett bara en wrapper av WinAPI). Otrevligt, klumpigt, fult, men effektivt. Extremt låst till windows, inte speciellt lätt att uppdatera etc.

2. .NET, det blir ju lite segare, eftersom det inte körs "rent nativt". Finns mycket information för, och stor hype kring. Det är hyfsat lätt att skapa användargränssnitt etc. Inte jättelåst till windows, men det är ju inte direkt anpassat för något annat.

3. Kör med ett fristående grafiskt bibliotek; det finns ganska mycket (QT, vxwidgets, osv.). Beroende på vad du kör för bibiliotek så är kan det variera från ganska segt till identisk snabbhet som WinAPI. Fördelen är att du får portabel kod, och ofta är det gaska snyggt frikopplat så att det känns mycket renare än MFC eller WinAPI, och det kan vara gynnsamt på kodskrivarhastigheten.

Sen finns också:
4. Kör Java; funkar överallt, är välanvänt etc. Har i mycket samma layout som .NET. Men guuuuud så seeeeegt.

Att lära mig MFC är inget jag gärna vill göra med tanke på att det är så förlegat. WIN32API kan jag visserligen redan, men känns ju lite omständligt.

Men efter diskussion med kolleger har jag bestämt mig för att göra själva användargränssnittet i .NET och den tidskritiska delen i unmaged C++. Kollegerna kör med MFC nu och har inte haft tid att lära sig .NET, och de ser det som positivt att jag introducera denna tekniken i verksamheten.

Jag jobbade på mitt förra jobb i ett projekt där hanterade stora mängder geografiska data och hade stora krav på prestande.
Projektet var implementerat helt i C++ på Windows, men jag gjorde en del tester av att portera beräkningsintensiva delar (geografiska beräkningar) samt en enkel simuleringsmotor till C# för att kolla prestandan, och sanningen var den att C# var snäppet snabbare än C++ i många lägen.
C# (och alla andra CLR-baserade språk) kan ju alltid optimera för den processorn som de kör på just nu eftesom IL-koden översätts så sent som möjligt till maskinkod, men C++ måste gissa på en processor redan vid kompilering.

Dock så skall man tänka på att minnesförbrukningen är större i C#.

Mitt råd: implementera allt i C#. Om du sedan tycker att det går segt, flytta då över kritiska delar (se till att du har mätt upp detta med en profiler, gissa INTE) till unmanaged C++.

/Andreas

Frågan är då vilken kompilator du använde för C++-varianten...?
Inte VC6, gissar jag?
För det är i många avseenden en ganska dålig kompilator.

Om jag väljer att göra allt i Managed C++ hur blir det då med gränssnittet mot det OPC-framework jag ska använda? Den är skriven i Unmaged C++ och all data måste ju konverteras fram och tillbaka. Som jag förstår det måste data kopieras i minnet, och det borde belasta processorn en hel del med tanke på att det är 1000-tals realtidsdata som ska skickas. Eller vad anser ni?

Men hur blir det då att använda C# i den delen jag väljer att göra med .NET? Har det några fördelar mot Managed C++? Jag kan C# så för mig blir det ju lättare, men mina kollegor kan det inte.


PS. Jag använder Visual Studio.NET 2002 och snart 2003 (De är lite försiktiga med nya program här)

Fördelen med C++ är ju att du kan antingen använda native eller CLR kod. Det är ju bara att kompilera den tidskritiska delen till CLR eller native och se vilket som är snabbast. CLR kod från C++ är dessutom mer optimerad än CLR kod från C#.

(Skippa managed C++ för det är redan "depreciated", använd C++/CLI istället)

GUI är lite klurigare och många olika begrepp finns
- Win32 är det du redan kan
- Windows Forms är det som finns i .Net biblioteket
- Windows Vista har ett nytt API som skiljer sig från båda.

MFC hanterar både Win32 och Windows Forms men är ganska gammalt och struligt att använda. Om det finns stor erfarenhet inom företaget på MFC så kan det dock vara ett alternativ. (Om jag förstått diskussionerna korrekt så verkar C++ folk hoppa över Windows Forms och gå direkt till Windows Vista API:et)

Windows Forms har fördelen att det fungerar på samma sätt i alla .Net språk (VB, C#, C++/CLI)

Jag skulle helst vilja använda C++/CLI förstås, men jag får bara VS.NET 2003 och får därför hålla mig till Managed C++ :-(
Och de olika begreppen för GUI känner jag redan till. Jag är ju ändå C#-programmerare och har även på skoj tittat lite på Windows Vista tidigare (av det som finns att se än).

Visst finns det kompetens för MFC på avdelningen jag jobbar på, men jag måste ju ändå lära mig det och det tar ju tid.

Men hur gör jag enklast om jag vill jämföra prestanda på programmet om jag kompilera det med .NET och utan?

Kompilerade hela framworket och ett demoprogram med .NET (gick efter lite pill med inställningar och rättigheter). Jag testade sedan med bara 30 signaler och programmet gick då i genomsnitt 4% långsamare än om jag kompilerade det utan .NET

Svar till tidigare postare: prestandatesterna jag gjorde var med VS.NET 2003 både i C# och C++. Man hade kanske kunnat krysta ur litet mer prestanda med t.ex. Intels kompilator (jag vet iofs inte vem som är snabbast nu för tiden), men jag är inte säker på det.

Om vi dessutom nu bara pratar om 4% prestandaskillnad så känns det som att det inte är något snack om saken. Utvecklingstiden misstänker jag halveras (beror såklart på en massa andra saker, men hanldar det dessutom om GUI så är det inget snack om saken), så det känns inte ekonomiskt försvarbart att utveckla i icke managed språk vid de tillfällen man kan välja.

/Andreas

Men nu pratar du enbart om MS-orienterade grejer. Ska du ha några som helst garantier för att dina grejer ska funka på andra plattformar så är det fristående bibliotek du ska köra.

Ett modernt designat fristående API är minst lika lättarbetat som .NETs, och utvecklingstiderna bör absolut vara snarlika så fort man är över tröskeln.

Hade jag kunnat mer om hardcore-parallellprogrammering så hade jag säkert kunnat motivera det bättre, men jag har aningar om att det är mycket bättre lämpat att göra det i språk där man har bättre lågnivåmöjligheter, såsom C++.