GUI og C++

[Moskus]

Hei!

 

Jeg har endelig fått ut finger'n og lest et par mursteiner om C++ (iallfall én murstein), og jeg er imponert (om du kan kalle det det) over graden av kontroll man har sammenlignet med VB som jeg er vant til.

 

Jeg har klart meg med VB (.NET i de siste årene) ganske lenge nå, men skal (med tid og stunder) i gang med et par prosjekter som krever mer hastighet og tilgang til hardware enn man klarer å få til med .NET.

 

Det jeg har lest om C++ til nå har i hovedsak omhandlet console-programmer. Noe som jeg forstår godt, jeg gjorde det samme da jeg begynte med VB. Men i VB er forskjellen ganske liten mellom Windows- og console-programmer. Optimist som jeg er tenkte jeg "det kan jo ikke være så galt", så jeg startet ett nytt prosjekt i VS 2005 med GUI.

 

Resultatet var at jeg hadde lyst til å løpe skrikende ut og senke PCen midtfjords...

 

 

Med andre ord:

Jeg trenger å tilegne meg kunnskaper om GUI-programmering i C++ (dvs. for Windows ). Gjerne forskjeller mellom Win32, ATL, CLR og MFC, og hva som er best, enklest eller mest effektivt å bruke.

 

Har du et tips om en bok, så si gjerne i fra!

Har du linker, så post dem gjerne!

 

 

På forhånd takk for hjelpen!

 

 

 

EDIT: For dem som lurer: Jeg har prøvd å søke, men det er ikke så enkelt når man ikke vet helt hva man leter etter...

Endret 21. juni 2006 av moskus

[lnostdal]

dropp Win32, MFC, ATL, etc. .. de er alle avlegs og "grusomme" - jeg orker ikke gå inn på forskjeller og slikt

 

bruk heller portable og gode GUI-biblioteker som f.eks. QT eller GTK (som har C++-bindinger i form av gtkmm)

 

GTK er kjapt å komme i gang med: http://www.gtk.org/tutorial/ .. eller om du foretrekker C++-versjonen av GTK: http://gtkmm.sourceforge.net/docs/gtkmm-2....html/index.html

 

(man kan bruke C-biblioteker fra C++ om man ønsker .. d.v.s. at man kan bruke GTK-biblioteket fra C++ i stedet for gtkmm-biblioteket)

 

edit:

som en bonus om du kombinerer ting som QT eller GTK/gtkmm med OpenGL så vil programvaren (d.v.s. GUI-delen i det minste; dog følger det med litt verktøy i hver av disse som faller utenfor "GUI-ting" - tråding og slikt) du utvikler "automatisk" være triviell å porte til andre platformer; Mac, Linux og andre

Endret 21. juni 2006 av lnostdal

[kjetil7]

Du vil oppleve at GUI i C++ er tungvint i forhold til .NET Forms. Hvis du virkelig vil gå vekk fra .NET Forms må du være villig til å bruke mye tid på det. Og du vil oppleve at produktiviteten går betraktelig ned.

 

For å ta noen av begrepene først:

 

Win32: regner med at du mener Windows API. Dette er den mest direkte måten å kommunisere med Windows på (hvis vi ser bort fra driverutvikling). Dvs. at dette er måten med teoretisk minst overhead i forhold til å lage vinduer o.l. Kan være tungvint å jobbe med spesielt for utrente.

 

MFC: GUI-bibliotek som wrapper Windows API. Gjør det enklere å lage GUI med C++.

 

ATL: C++ bibliotek for å forenkle utvikling av og med COM. Har noen GUI-klasser og er generelt en tynnere wrapper rundt Windows API enn MFC (dvs. raskere og "lettere").

 

WTL: et tillegg til ATL for å gjøre GUI-utvikling enklere i C++ (i forhold til ren ATL). Meget tynn wrapper og er meget rask, men du trenger litt kjennskap til hvordan Windows fungerer (dvs. Windows API).

 

CLR: den virtuelle maskinen som er grunnlaget for alle .NET-programmer. Tilsvarer Javas virtual machine som begge kjører en form for såkalt byte code.

 

 

For å gjøre utvikling av GUI noe mindre smertefull bør du bruke et bibliotek. Det mest vanlige for Windows er MFC og følger med Visual Studio (ikke Express tror jeg - kommer muligens med Platform SDK). Ellers finnes det et lite overbygg på ATL som heter WTL (Windows Template Library). For å bruke WTL bør du ha gode kunnskaper av hvordan Windows fungerer.

 

Ellers finnes det noen såkalte flerplatformbiblioteker som blant annet wxWidgets og Qt. wxWidgets ligner litt på MFC, mens Qt bruker litt andre mekanismer. Qt koster forøvrig skjorta hvis du skal lage kommersiell software.

 

Så hva ville jeg gjort? Personlig foretrekker jeg ATL/WTL, men da er du avhengig av å ha litt kjennskap til Windows API. Hvis du ikke har det, ville jeg gått for MFC eller wxWidgets. Qt styrer jeg unna av flere grunner. Jeg liker hverken signal/slot systemet deres eller lisensen. MFC er helt greit siden du ikke er avhengig av et flerplatformbibliotek (selv om flere på forumet her sikkert vil være uenig av ymse idelogiske grunner). Dessuten fungerer det "rett fra boksen" etter installasjonen av Visual Studio med mindre du bruker en Express-versjon.

 

Ressurser og nedlastinger:

 

MFC: følger med Visual Studio.

ATL: følger med Visual Studio og Platform SDK.

WTL: http://wtl.sourceforge.net

wxWidgets: http://www.wxwidgets.org

Qt: http://www.trolltech.no

 

Bra ressurser for utvikling med MFC, ATL/WTL og Windows generelt: http://www.codeproject.com og http://www.codeguru.com.

[abcd423417984]

For å vinkle det litt på en annen måte; Du kan kode .NET i C++. Da kan du bruke C++ rett frem i det GUI-biblioteket du er vant til fra VB. Mao du har all kunnskapen som skal til allerede.

[kjetil7]

Ja, og er muligens det beste alternativet. Men jeg forstod det slik at han ønsket å kode native-GUI.

 

Det skjer det mye på GUI-fronten på Windows om dagen. XAML og .NET Framework 3.0 vil revolusjonere GUI-utvikling på Windows. Og jeg ville ærlig talt holdt meg til .NET og heller brukt ressursene mine på å sette meg inn i XAML og de nye verktøyene som kommer.

 

Men dette er altså ikke native-kode. Alt dette vil kjøres av CLR.

[abcd423417984]

Ja, og er muligens det beste alternativet. Men jeg forstod det slik at han ønsket å kode native-GUI.

6351075[/snapback]

 

Ok. Isåfall har jeg misforstått. Men uansett hva han velger så vil han i en viss grad være avhengig av eksterne biblioteker. Når Windows Vista kommer så er det bare .NET som gjelder. WinFX (som visstnok er .NET framework 3.0) blir jo DET api'et som Vista tilrettelegger for utviklere. Da ser jeg ikke lenger noen grunn til å lete etter noe native.

[Moskus]

Takk til begge to for mye god informasjon!

Jeg skal i første omgang prøve GTK og WTL, så får vi se om jeg klarer å holde motet oppe.

 

En tredje mulighet er jo å skrive DLLer i C++ for så å kalle det fra et .NET program (C# eller VB), men jeg vet ikke om jeg får samme tilgang til hardware? Vil det gå like raskt? Jeg ser den store fordelen .NET har introdusert for å lage Forms, så jeg vil ikke på død og liv bort fra den, men ser meg om etter andre muligheter.

 

Jeg ser i hovedsak tre "typer" program som er aktuelle for meg:

- MonteCarlo-simulering. Går betydelig kjappere i et C++ console-program enn i et VB.net console-program

- Mer direkte tilgang til hardware, i mitt tilfelle: Lydkort

- Lage en ToDay-plugin for Pocket PC som henter input fra andre programmer jeg styrer/lager

 

GTK fungerer vel i praksis kun på datamaskiner/laptoper. Kan man bruke WTL for programmer på Pocket PC?

[Moskus]

Ja, og er muligens det beste alternativet. Men jeg forstod det slik at han ønsket å kode native-GUI.

6351075[/snapback]

 

Ok. Isåfall har jeg misforstått. Men uansett hva han velger så vil han i en viss grad være avhengig av eksterne biblioteker. Når Windows Vista kommer så er det bare .NET som gjelder. WinFX (som visstnok er .NET framework 3.0) blir jo DET api'et som Vista tilrettelegger for utviklere. Da ser jeg ikke lenger noen grunn til å lete etter noe native.

6351123[/snapback]

 

Det var egentlig løsninger for native GUI jeg var ute etter.

 

Og det er forsåvidt sant at .NET gjør det mye enklere. Og visstnok vil WinFX være en betydelig del av Vista. Men 1) alle kommer ikke automatisk til å oppgradere til Vista og 2) andre plattformer kommer jo neppe til å støtte det (og andre plattformer skal vel ikke så mye lenger enn til MS eget OS for Pocket PC). Microsoft selv bruker jo ikke .NET så mye som jeg synes de burde (etter de har proklamert hvor genialt det er).

 

Ikke misforstå: Jeg synes egentlig at .NET er genialt!

Men programmene skrevet for .NET bruker litt mye minne, og programmer som skal kjøre på mer begrensete systemer kan få problemer med å bare starte det.

[lnostdal]

ang. lyd så vet jeg http://www.openal.org/ er mye brukt ( http://www.openal.org/titles.html ); og også denne er portabel

 

vet ikke om noen har portet GTK til PocketPC; etter et kjapt google-søk ser det dårlig ut .. om du i stedet går for en annen platform finnes dog både GTK, QT og flere alternativer og muligheter (edit: en helt annen retning her er forresten Java - som også kjører på noen av disse småmaskinene/platformene)

 

for noen år siden var jeg foresten borti VCe for PocketPC-platformen; sjeldent har jeg vært borti noe så buggete .. etter det har jeg heldigvis holdt meg til vanlige desktop/notebook-maskiner, men om jeg noen gang skal jobbe på/mot slike platformer igjen vet i hvertfall jeg hvilken retning jeg helt garantert ikke skal ta

 

dette med hastighet løser jeg ved å kode alt i høynivåspråk først, for så helt til slutt å luke ut småbitene i programmet som må optimaliseres ved å skrive dem om i C .. jeg gjør gjerne dette ved å flytte mainloopen (redraw-handling f.eks.) over til C-siden og ha callbacks/hooks på høynivåsiden som da blir kallt en sjelden gang i blant .. bruker du f.eks. GTK og Python (PyGTK) så har de allerede laget det på denne måten

 

nevner dette for jeg synes du bør ha slikt i bakhodet - det er bortkastet tid å hakke alt for mye C/C++ i dag

 

(husk også at om du skriver biblioteker i C++ fremfor C så er det vanskeligere/umulig å bruke dette fra høynivåspråk uten videre; man må ha et "flatt" C-interface i bibliotekene)

Endret 21. juni 2006 av lnostdal

[Moskus]

nevner dette for jeg synes du bør ha slikt i bakhodet - det er bortkastet tid å hakke alt for mye C/C++ i dag

 

(husk også at om du skriver biblioteker i C++ fremfor C så er det vanskeligere/umulig å bruke dette fra høynivåspråk uten videre; man må ha et "flatt" C-interface i bibliotekene)

6351365[/snapback]

Det er vel fremdeles mye programvare som skrives i C++?

Iallfall så blir nok veldig mange programmer innen mitt fagfelt skrevet i C++ (utenom dem jeg må skrive selv), ser det dukker opp "Visual C++"-feilmeldinger i ny og ne.

 

Hva betyr det å "ha et 'flatt' C-interface i bibliotekene"? Husk; jeg er amatør.

[abcd423417984]

Hva betyr det å "ha et 'flatt' C-interface i bibliotekene"? Husk; jeg er amatør.

6351595[/snapback]

 

bare deklarer funksjonene som extern "C" så går det nok bra. Saken er at språk har forskjellige måter å koble sammen moduler på. Det går på f.eks. rekkefølge parametere blir sendt med i funksjons-kall og hvilken tilleggsinformasjon som er nødvendig.

 

Eksemplet mitt her går på C. Der pushes parameterne som skal være med til et funksjonskall på stacken med SISTE parameter først. Dette er slik at første parameter skal være lettest tilgjengelig på stacken når man er inni funksjonskallet. C legger også returverdien tilbake på stacken og må hentes ut etter funksjonskallets slutt for at ikke stacken skal være endret. Andre språk gjør dette på en annen måte.

Endret 21. juni 2006 av invictus

[lnostdal]

veldig kort betyr det at du i den delen av biblioteket du ønsker å gjøre tilgjengelig fra høynivåspråk ikke kan bruke C++-spesifike ting relatert til f.eks. klasser/typer og annet; altså den biten som skal kalles/brukes må kun ha "C-ting i deklarasjonen sin" (edit: og som invictus nevner så sikrer `extern "C"' at funksjoner er tilgjengelige, men det er fortsatt en del ting man må passe på)

 

nå vet ikke jeg hvilket fagfelt du jobber med, men om du hakker på småplatformer så brukes C og C++ (mye QT) fortsatt

 

litt offtopic (..og kanskje mer tilbake på dette med vanlige platformer):

om man tenker at "C++ blir fortsatt mye brukt" så er det riktig på en måte - men jeg tror det er på grunn av ting som allerede eksisterer .. altså det er fordi tingen allerede er skrevet i C/C++ fra gammelt av

 

jeg tror nye prosjekter som blir startet i dag (bør ta) tar andre retninger .. ting som Mono gjør at C# er aktuellt under Gnome/Linux; hadde C# og Mono eksistert (eller vært like modent) for 5 år siden så hadde man kunne sagt at "C# blir mye brukt i dag" tror jeg .. Mono og GTK# begynner å se veldig bra ut, og det begynner å dukke opp en del applikasjoner i større prosjekter som f.eks. Gnome som bruker slike høynivåspråk/løsninger .. jeg tror Novell og Gnome gjør noe veldig lurt her (selv om jeg som Lisp-hakker står på sidelinjen og titter på )

 

edit: har også lyst til å nevne Python og PyGTK igjen, det kan hende dette er bedre enn Mono og GTK# - og jeg brukte Mono kun som eksempel på en høynivå-løsning

 

uansett, ved å bruke høynivåspråk sparer man tid, og siden de aller fleste (alle?) OS+drivere/maskinvareting i dag allerede er skrevet for en i C som man kan kalle fra høynivåspråk, har man intet å miste ved å bruke høynivåspråk kombinert med muligheten til å siden kunne luke ut deler av koden man har funnet v.h.a. profilering som man ønsker å optimalisere ved å skrive disse om i C helthelt tilslutt

Endret 21. juni 2006 av lnostdal