mboost-dp1
Hjælp til GUI i c++
lazyfoo.net viser hvordan man kan lave det med SDL. Man skal bare have en DLL fil sammen med sin exe for at det kan køre, men SDL er nok det nemmeste. I hvert fald meget nemmere end win32 api'en imo :)
Personligt har jeg altid syntes, at det var meget tilfredsstillende at programmere GUI i win32-api. Men hvis du kun har 3 dage, så skal du nok finde på noget andet. Hvis du derimod kan tage dig til takke med en Document/View-tankegang, så kan MFC løse opgaven for dig, i løbet af kort tid. Især hvis du bruger Visual Studio. Men MFC kan stadigvæk være lidt svær at læse op på 3 dage. Jeg kender ikke umiddelbart SDL, så jeg kan ikke sige noget om indlæringstiden for det.
Du har ikke tilfældigvis beskæftiget dig lidt med 3D-programmering? Via OpenGL GLUT vil du i løbet af ret kort tid kunne lave det du søger. (Tilmed med noget 3D-grafik.) Derudover er der også mange nemme tutorials til dette og det kan forøvrigt køres på alle platforme.
Du har ikke tilfældigvis beskæftiget dig lidt med 3D-programmering? Via OpenGL GLUT vil du i løbet af ret kort tid kunne lave det du søger. (Tilmed med noget 3D-grafik.) Derudover er der også mange nemme tutorials til dette og det kan forøvrigt køres på alle platforme.
illishar (5) skrev:Jeg kender ikke umiddelbart SDL, så jeg kan ikke sige noget om indlæringstiden for det.
Det er forholdsvist simpelt i forhold til mange andre APIer. Ulempen er at det også er ret low-level så der er lidt manuelt arbejde med at lave visse ting, som man tit har brug for.
I princippet skal han vel bare lave en keylistener der opdatere positionen af en label/button på et Window.
Det meste komplexe må jo så være keylisteneren, da man kan lave resten med MFC, med omkring.. 30 linjers kode?
At man så skal bruge 30 linjer mere til at overbevise compileren om at den skal compile, eller håbe på at ens IDE gør det for en, er jo så en anden sag.
Ellers kunne man lave det i C# med Visual Studio, og så vil det tage omkring 10 minutter. GUI og C++ er 2 ting som ikke bør forbindes uden det er absolut nødvendigt.
Det meste komplexe må jo så være keylisteneren, da man kan lave resten med MFC, med omkring.. 30 linjers kode?
At man så skal bruge 30 linjer mere til at overbevise compileren om at den skal compile, eller håbe på at ens IDE gør det for en, er jo så en anden sag.
Ellers kunne man lave det i C# med Visual Studio, og så vil det tage omkring 10 minutter. GUI og C++ er 2 ting som ikke bør forbindes uden det er absolut nødvendigt.
#10
GUI og C++, kan da sagtens forbindes til vidunderlige løsninger. Bare fordi at Microsoft lavede lort i den med MFC, og wxwidgets just heller ikke var bomben, er det da langt fra det samme som at det kan diskvalificere c++ til gui apps.
Hvad er det lige i C++ som du mener gør det ubrugeligt til GUI?
GUI og C++, kan da sagtens forbindes til vidunderlige løsninger. Bare fordi at Microsoft lavede lort i den med MFC, og wxwidgets just heller ikke var bomben, er det da langt fra det samme som at det kan diskvalificere c++ til gui apps.
Hvad er det lige i C++ som du mener gør det ubrugeligt til GUI?
#11
Man kan vel ikke kalde C++ ubrugeligt til GUI.
Trods alt er en ganske stor del af de GUI folk bruger kodet i C++!
Men det skillset der kræves for de fleste af de nævnte GUI frameworks er absolut ikke for begyndere.
Det er meget nemmere at bixe en GUI i Java, .NET etc..
Og selv med erfarne udviklere er det ofte mere cost efficient at vælge noget andet end C/C++ til GUI.
Man kan vel ikke kalde C++ ubrugeligt til GUI.
Trods alt er en ganske stor del af de GUI folk bruger kodet i C++!
Men det skillset der kræves for de fleste af de nævnte GUI frameworks er absolut ikke for begyndere.
Det er meget nemmere at bixe en GUI i Java, .NET etc..
Og selv med erfarne udviklere er det ofte mere cost efficient at vælge noget andet end C/C++ til GUI.
#12
Arne du har da ret i at nogle af de frameworks der findes har en højindlæringskurve, men det tager jeg faktisk ikke som noget direkte negativt. Det skiller vel nærmere bare fårene fra bukkene. (sat på spidsen)
Og et framework som Qt, er i min optik hvertfald, lige så nemt at gå til som .NET og hvad det andre ellers hedder. Udbudet af C++ frameworks er faktisk acceptabelt, og jeg synes de fleste af dem holdere et fint niveau, det er nok nærmere udviklerne der bruger dem som ikke gør :)
Men mangel på nemme frameworks, kan jeg ikke se diskvalificere C++ som sprog til GUI udvikling. Og slet ikke isårn en grad at det "ikke bør forbindes uden det er absolut nødvendigt".
Men set ud fra et projektledelses synspunkt kan det godt være at Java eller .NET vinder, blandt andet fordi det nok alt andet lige er nemmere at skaffe gode folk og nemmere at sætte ny-uddannede ind i det, da de fleste nok har større erfaring i Java eller .NET.
Men har du et team dygtige C++ folk overfor et team dygtige C# folk, så tror jeg umiddelbart at det bliver samme kvalitet og hastighed i udviklingstid. Eller som vi plejede at sige, C# folkene når 80% før os, men vi rammer 95% før dem. Og så kommer vi cirka sammentidigt i mål. Forstået på den måde at mange umiddelbare ting i .NET gør det nemt at nå 80% af opgaven, men så skal der finpudses og vupti så tager det længere tid. (Men det er baseret på survey of one, dvs mine erfaringer)
Men i disse moderne agile tider, så er det jo klart det er fordelagtigt (umiddelbart) at nå 80% hurtigt.
Arne du har da ret i at nogle af de frameworks der findes har en højindlæringskurve, men det tager jeg faktisk ikke som noget direkte negativt. Det skiller vel nærmere bare fårene fra bukkene. (sat på spidsen)
Og et framework som Qt, er i min optik hvertfald, lige så nemt at gå til som .NET og hvad det andre ellers hedder. Udbudet af C++ frameworks er faktisk acceptabelt, og jeg synes de fleste af dem holdere et fint niveau, det er nok nærmere udviklerne der bruger dem som ikke gør :)
Men mangel på nemme frameworks, kan jeg ikke se diskvalificere C++ som sprog til GUI udvikling. Og slet ikke isårn en grad at det "ikke bør forbindes uden det er absolut nødvendigt".
Men set ud fra et projektledelses synspunkt kan det godt være at Java eller .NET vinder, blandt andet fordi det nok alt andet lige er nemmere at skaffe gode folk og nemmere at sætte ny-uddannede ind i det, da de fleste nok har større erfaring i Java eller .NET.
Men har du et team dygtige C++ folk overfor et team dygtige C# folk, så tror jeg umiddelbart at det bliver samme kvalitet og hastighed i udviklingstid. Eller som vi plejede at sige, C# folkene når 80% før os, men vi rammer 95% før dem. Og så kommer vi cirka sammentidigt i mål. Forstået på den måde at mange umiddelbare ting i .NET gør det nemt at nå 80% af opgaven, men så skal der finpudses og vupti så tager det længere tid. (Men det er baseret på survey of one, dvs mine erfaringer)
Men i disse moderne agile tider, så er det jo klart det er fordelagtigt (umiddelbart) at nå 80% hurtigt.
Du skal også finpudse din C++ kode, det er måske bare ikke så gennemsigtig.
Problemet med GUI libs i C++ er helt klart deres artitektur. Hvorfor jeg ikke kan lave GUI ligeså nemt (med ligeså lidt kode) som i C# tyder på et dårlig API design.
Samt manglen på ordenlig GUI builder til simple applications.
Problemet med GUI libs i C++ er helt klart deres artitektur. Hvorfor jeg ikke kan lave GUI ligeså nemt (med ligeså lidt kode) som i C# tyder på et dårlig API design.
Samt manglen på ordenlig GUI builder til simple applications.
Du skal teknisk set skrive mindre kode, og har bedre udviklingsværktøjer (læs: IDE) til C# / .NET, så de burde blive færdig før C++ folkene.lorenzen (13) skrev:Men har du et team dygtige C++ folk overfor et team dygtige C# folk, så tror jeg umiddelbart at det bliver samme kvalitet og hastighed i udviklingstid.
Så absolut da, da vi alle ved hvordan kunder har det med at ændre på kravenen som vinden blæser.lorenzen (13) skrev:Men i disse moderne agile tider, så er det jo klart det er fordelagtigt (umiddelbart) at nå 80% hurtigt.
Windkappe:
http://www.rawmaterialsoftware.com/juce/
Hvis din kunde ændrer krav, så er du vel ligeglad? Det skal kunden jo betale for...
Det er da nok den største omgang bull jeg længe har hørt!
For det første, så afhænger det 100% af hvilket program du skal skrive; .NET og C++ opererer i to helt forskellige domæner.
For det andet, så er IDE'et sgu da LANGT fra den væsentligste ting, eller du bruger måske aldrig en debugger? Desuden kan du jo customize langt de fleste IDE'er så at bruge et IDE som måleparameter for udvikling og udviklingsværktøjer er ikke smart.
http://www.rawmaterialsoftware.com/juce/
Hvis din kunde ændrer krav, så er du vel ligeglad? Det skal kunden jo betale for...
Du skal teknisk set skrive mindre kode, og har bedre udviklingsværktøjer (læs: IDE) til C# / .NET, så de burde blive færdig før C++ folkene.
Det er da nok den største omgang bull jeg længe har hørt!
For det første, så afhænger det 100% af hvilket program du skal skrive; .NET og C++ opererer i to helt forskellige domæner.
For det andet, så er IDE'et sgu da LANGT fra den væsentligste ting, eller du bruger måske aldrig en debugger? Desuden kan du jo customize langt de fleste IDE'er så at bruge et IDE som måleparameter for udvikling og udviklingsværktøjer er ikke smart.
Typisk argument fra en C++ udvikler, ja.lorenzen (16) skrev:Eller måske en dårlig udvikler ;)
Når det kommer til stykket så er dårlig API design ret så eksisterende, og jeg synes bestemt ikke at GUI APIs til C++ er lavet med særlig meget omtanke.
Eksemplet var jo netop samme type application, med lige dygtige udviklerer. Derfor må det sprog med den mest flexible arkitektur og syntax jo vinde.Whoever (15) skrev:Det er da nok den største omgang bull jeg længe har hørt! For det første, så afhænger det 100% af hvilket program du skal skrive; .NET og C++ opererer i to helt forskellige domæner.
Dit udviklingsmiljø er faktisk ret væsenligt. Debuggeren er jo netop en del af IDEet, og du vil vel ikke komme og påstå at C++ APIs generet er plaget af god exception håndtering og stacktraces, vil du nu? ;)Whoever (15) skrev:For det andet, så er IDE'et sgu da LANGT fra den væsentligste ting, eller du bruger måske aldrig en debugger? Desuden kan du jo customize langt de fleste IDE'er så at bruge et IDE som måleparameter for udvikling og udviklingsværktøjer er ikke smart.
Men det overrasker mig igen ikke at en C++ udvikler vil mene at hans udviklingsmiljø er irrelevant, når de normalt foretrækker at skrive det i en form of text-editor ala. emacs, og skide højt og helligt på ordenlig projekt håndtering.
Windcape (17) skrev:
Når det kommer til stykket så er dårlig API design ret så eksisterende, og jeg synes bestemt ikke at GUI APIs til C++ er lavet med særlig meget omtanke.
Er vi ikke lidt generaliserende?
Jeg må indrømme der er nogle API's der ikke ligefrem virker gennemtænkte, men der findes altså også en del meget gennemtænkte som f.eks. gtkmm og Qt. Måske skulle du kigge lidt på dem?
Hør nu lige ffs, debugeren er IKKE en del af IDE'et og har aldrig været det! Og heller ikke i VS.
FYI foretrækker jeg VS som IDE, men det er en vane sag, som er aldeles subjektiv.
Når du nu åbenbart kender så meget til C# og C++ arkitekturen, så forklar mig venligst hvorfor C# har en mere flesksibel arkitektur end C++?
Hvis du synes C++ er dårligt designet, så har du ikke forstået C++. Jeg koder ikke specielt meget i C++ længere (benytter primært C# til desktop og server kode, og J2ME til mobile), men hvis der er en ting jeg har lært af den tid jeg har brugt på C++, så er det, at mulighederne i C++ er ufattelig store (og at jeg, til trods for en del erfaring, kun lige er nået et enkelt dyk ned under toppen).
Iøvrigt er denne diskussion fuldstændig afmarcheret. Du sammenligner ikke C# med C++! Du sammenligner .NET med C++ og diverse eksterne libraries. Det har intet med hinanden at gøre. .NET er et framework, C# og C++ er to programmeringssprog. Hvis du vil sammenligne, så hold dig til at sammenligne sprogene.
FYI foretrækker jeg VS som IDE, men det er en vane sag, som er aldeles subjektiv.
Når du nu åbenbart kender så meget til C# og C++ arkitekturen, så forklar mig venligst hvorfor C# har en mere flesksibel arkitektur end C++?
Hvis du synes C++ er dårligt designet, så har du ikke forstået C++. Jeg koder ikke specielt meget i C++ længere (benytter primært C# til desktop og server kode, og J2ME til mobile), men hvis der er en ting jeg har lært af den tid jeg har brugt på C++, så er det, at mulighederne i C++ er ufattelig store (og at jeg, til trods for en del erfaring, kun lige er nået et enkelt dyk ned under toppen).
Iøvrigt er denne diskussion fuldstændig afmarcheret. Du sammenligner ikke C# med C++! Du sammenligner .NET med C++ og diverse eksterne libraries. Det har intet med hinanden at gøre. .NET er et framework, C# og C++ er to programmeringssprog. Hvis du vil sammenligne, så hold dig til at sammenligne sprogene.
Faktisk så er den største forskel på C# (.NET) og C++ (unmanaged), garbage collectoren. Hvilket også er grunden til at C# "vinder" når det kommer til udviklingstid og vedligehold. Mange diskuterer i et væk hvorvidt OO-kode, aktør-drevet, linær, funktionel, whatever er det bedste mht. udviklingsperformance. Men i virkeligheden har garbage collectoren langt større indflydelse på denne, end forskellene på de forskellige kode-modeller ;)
Bortset fra det #1, når du nu siger C++, vil det så være snyd at bruge managed C++? I så fald kan du uden synderlig indlæring, kunne bruge VS til at lave din GUI. (Og du får stadigvæk lov til, at bruge timevis på at lede efter pointere og mem, der endnu ikke er ryddet op ;)
Bortset fra det #1, når du nu siger C++, vil det så være snyd at bruge managed C++? I så fald kan du uden synderlig indlæring, kunne bruge VS til at lave din GUI. (Og du får stadigvæk lov til, at bruge timevis på at lede efter pointere og mem, der endnu ikke er ryddet op ;)
lorenzen (13) skrev:
Arne du har da ret i at nogle af de frameworks der findes har en højindlæringskurve, men det tager jeg faktisk ikke som noget direkte negativt. Det skiller vel nærmere bare fårene fra bukkene. (sat på spidsen)
Og et framework som Qt, er i min optik hvertfald, lige så nemt at gå til som .NET og hvad det andre ellers hedder. Udbudet af C++ frameworks er faktisk acceptabelt, og jeg synes de fleste af dem holdere et fint niveau, det er nok nærmere udviklerne der bruger dem som ikke gør :)
Men mangel på nemme frameworks, kan jeg ikke se diskvalificere C++ som sprog til GUI udvikling. Og slet ikke isårn en grad at det "ikke bør forbindes uden det er absolut nødvendigt".
C++ er et svært sprog. Jeg kan umiddelbart kun komme i tanke om et sprog som er vanskeliger et amestre (Ada specielt Ada95).
Og den med at man bare skal hyre gode udviklere holder ikke. I større sammenhæng gælde de store tals lov også for programmører. Ansætter man 100 programmører, så får man 5 rigtigt gode + 20 gode + 50 mellem + 20 ringe + 5 katastrofer.
Kodes der i C++ så er der 25 som er produktive. Kodes der i C# eller Java, så er der 75 som er produktive.
Hvis man skal lave GUI i C++ så skal der være en speciel begrundelse for det.
Den klassiske business app med et par forme med nogle data felter og en submit button er billigere at få lavet i C# eller Java.
lorenzen (13) skrev:Men set ud fra et projektledelses synspunkt kan det godt være at Java eller .NET vinder, blandt andet fordi det nok alt andet lige er nemmere at skaffe gode folk og nemmere at sætte ny-uddannede ind i det, da de fleste nok har større erfaring i Java eller .NET.
Det er først de sidste få år, at det er blevet almindeligt med nyuddannede IT folk som ikke har lært C++. Det er ikke mangel på folk der har lært lidt C++ der er problemet. Det er mangel på dygtige folk der er problemet.
Windcape (17) skrev:Men det overrasker mig igen ikke at en C++ udvikler vil mene at hans udviklingsmiljø er irrelevant, når de normalt foretrækker at skrive det i en form of text-editor ala. emacs, og skide højt og helligt på ordenlig projekt håndtering.
Nu vil jeg nok mene at projekt håndtering er helt uafhængig af IDE.
Med en undtagelse: hvis IDE bruges til de officielle builds og unit tests, så er den helt gal med projektet.
illishar (22) skrev:Faktisk så er den største forskel på C# (.NET) og C++ (unmanaged), garbage collectoren. Hvilket også er grunden til at C# "vinder" når det kommer til udviklingstid og vedligehold. Mange diskuterer i et væk hvorvidt OO-kode, aktør-drevet, linær, funktionel, whatever er det bedste mht. udviklingsperformance. Men i virkeligheden har garbage collectoren langt større indflydelse på denne, end forskellene på de forskellige kode-modeller ;)
Bortset fra det #1, når du nu siger C++, vil det så være snyd at bruge managed C++? I så fald kan du uden synderlig indlæring, kunne bruge VS til at lave din GUI. (Og du får stadigvæk lov til, at bruge timevis på at lede efter pointere og mem, der endnu ikke er ryddet op ;)
Manglende GC er et af de store problemer. Men der er også andre: manglende check på array indexes, mulighed for nogle meget suspekte type casts o.s.v..
#26
Det er værd at bemærke at disse ting ikke kun er svagheder men også styrker ved C++.
Manglende GC gør det nemmere at skrive realtime porgrammer.
Manglende check på array indexes og suspekte type casts kan være nødvendige når man skal kode noget specielt hardware eller OS nært.
Men de er ulemper ved traditionel GUI programmering.
Det er værd at bemærke at disse ting ikke kun er svagheder men også styrker ved C++.
Manglende GC gør det nemmere at skrive realtime porgrammer.
Manglende check på array indexes og suspekte type casts kan være nødvendige når man skal kode noget specielt hardware eller OS nært.
Men de er ulemper ved traditionel GUI programmering.
arne_v (27) skrev:Manglende GC gør det nemmere at skrive realtime porgrammer.
hvor mange kunder burger et realtime OS, som du kan skrive dine realtime porgrammer til ?
liste med alle realtime OS ...
http://en.wikipedia.org/wiki/List_of_real-time_ope...
Hmm?arne_v (25) skrev:Nu vil jeg nok mene at projekt håndtering er helt uafhængig af IDE.
Med en undtagelse: hvis IDE bruges til de officielle builds og unit tests, så er den helt gal med projektet.
Både Eclipse og Visual Studio har da rigtig god support for Unit Testing (C#s måde at lave dem på er helt klart smarterer end Javas)
Og hvorfor vil du ikke benytte MSBuild til releases?
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund