mboost-dp1
unknown
C# er stadig et lille bitte sprog.
JAVA og COBOL er de helt store, hvis man kigger i antal udviklere.
Her er lidt statestik i jobopslag:
http://www.kalonline.dk/stats.txt (det så ikke så pænt ud i normal news format ;] )
C++ er smart fordi at det er crossplatform, og kører uden framework, modsat JAVA og C#
Men dets synstaks er sværer og ikke så simpelt at gå til, man får også hurtigt brug for nogle 3parts biblioteker, hvis man vil undgå at skrive vildt meget kode.
Og så er ikke det mest brugte til f.eks. ERP systemer (ved at f.eks. MOVEX bliver kodet i java), men mere spil (f.eks. WorldOfWarcraft).
JAVA og COBOL er de helt store, hvis man kigger i antal udviklere.
Her er lidt statestik i jobopslag:
http://www.kalonline.dk/stats.txt (det så ikke så pænt ud i normal news format ;] )
C++ er smart fordi at det er crossplatform, og kører uden framework, modsat JAVA og C#
Men dets synstaks er sværer og ikke så simpelt at gå til, man får også hurtigt brug for nogle 3parts biblioteker, hvis man vil undgå at skrive vildt meget kode.
Og så er ikke det mest brugte til f.eks. ERP systemer (ved at f.eks. MOVEX bliver kodet i java), men mere spil (f.eks. WorldOfWarcraft).
vil bare lige sige at tibetansk er heller ikke et meget udbredt sprog at bruge .. subkinesisk er dog et langt mere udbredt sprog,
skal du have et sprog som virkelig giver indtryg skal du prøve VoldsTegnsprog hvor man slår sine tegnsprog på personen man "snakker" med..
skal du have et sprog som virkelig giver indtryg skal du prøve VoldsTegnsprog hvor man slår sine tegnsprog på personen man "snakker" med..
#2 er ikke sikker på hvordan den skal fortolkes.
Men ja, der nok omkring 1 milliard som snakker manderin som hovedsprog, og kun 800000 som snakker engelsk som hovedsprog.
Men der er så samlet 2 milliarder som snakker engelsk som enten hoved eller seconddært sprog, hvor imod at kinserne ikke snakker andet end manderin.
Jeg udvikler både i Java og C++ , dog mest java da jeg er bedst til det. Så indgår jeg vel i både java og c++ statestikken :]
Jeg vil mene at den korrekte måde at måle et sprog i, er at tage antal udviklere (dvs. folk som er ansat af en arbejdsgiver) og sammenligne.
Her vil COBOL og JAVA dog være størst, da men jo ikke koder et nyt system når det gamle fra 1980 virker perfekt endnu :o)
Tilgengæld er der ikke så meget ny udvikle i COBOL mere, og de få som ansættes er til at veligeholde gamle systemer, indtil firmaet køber et nyere (i .NET f.eks.)
Men ja, der nok omkring 1 milliard som snakker manderin som hovedsprog, og kun 800000 som snakker engelsk som hovedsprog.
Men der er så samlet 2 milliarder som snakker engelsk som enten hoved eller seconddært sprog, hvor imod at kinserne ikke snakker andet end manderin.
Jeg udvikler både i Java og C++ , dog mest java da jeg er bedst til det. Så indgår jeg vel i både java og c++ statestikken :]
Jeg vil mene at den korrekte måde at måle et sprog i, er at tage antal udviklere (dvs. folk som er ansat af en arbejdsgiver) og sammenligne.
Her vil COBOL og JAVA dog være størst, da men jo ikke koder et nyt system når det gamle fra 1980 virker perfekt endnu :o)
Tilgengæld er der ikke så meget ny udvikle i COBOL mere, og de få som ansættes er til at veligeholde gamle systemer, indtil firmaet køber et nyere (i .NET f.eks.)
C++ er smart fordi at det er crossplatform, og kører uden framework, modsat JAVA og C#
...den lader vi stå.
C# og Java er for programmering hvad The 3D Gamemaker er for spiludvikling.
Jeg er ikke den store guru indenfor programmering, men umiddelbart appellerer nye sprog som C# og Java mere til mig end C++ gør .. Jeg føler, jeg når hurtigere fra A til B med de to førstnævnte.. jeg ville gerne lære C++, men jeg finder det for komplekst og det virker på mig som et sprog der med tiden er blevet forsøgt moderniseret, men som bare er blevet mere indviklet at udvikle i, fordi man har introduceret flere lag efterhånden.
#5 Jeg er ikke sikker på at Java og COBOL nødvendigvis er de sprog der er flest job i C/C++ er stadig meget udbredt i de mindre synlige systemer, Stort set alle OS'er er stadig C/C++ og maget af det software der ligger inde i elektronik er vel også C/C++
Der er simpelt hen ting du kan med C++ som du aldrig vil kunne med java og C#.
Der er simpelt hen ting du kan med C++ som du aldrig vil kunne med java og C#.
GO BJARNE GO BJARNE GO BJARNE! :D
Som dudsen siger:
Der er muligheder i C++ som C# og slet ikke Java kan give dig.
Til gengæld er time-to-market ofte reduceret når man bruger Java og C#, hvis man eller taler relativt simple applikationer (læs: ikke tidskritiske). Der er selvfølgelig andre årsager også, og sikkert "tungere" årsager (såsom de ansatte man har kun kan Java, eller man skal udvikle til .NET (managed C++ er sgu for grimt)), men bottom line er C++ et yderst veludviklet sprog.
#9
Det er ikke helt rigtigt. C++ blev oprindeligt kaldt "C med klasser" i folkemunde..nørdmunde...Det passer nu heller ikke helt, da C++ er meget mere. Tag f.eks. templates. De giver en kæmpe ekstra dimension til din kode. C#s implementering af templates (generics) er egentlig også ok, skal det lige siges (Javas er elendig...er ikke andet en type casts a la (TYPE)var, hvilket ikke har anden effekt end at virke mere forvirrende end håndkodede typecasts).
Desuden halter det med chips der understøtter java eller .NET kode (sidstnævnte er der lavet, kom i efteråret). Til gengæld er der masser af chips du kan kode i C++ til.
Jeg tror der går laaaaaang tid før man ser Oracle eller lign. lave databaser i Java eller på .NET platformen. Her er run-time enginen alt for langsom, og derfor bruger man C++ (eller ældre sprog).
#6, LOL!!!
Som dudsen siger:
Der er muligheder i C++ som C# og slet ikke Java kan give dig.
Til gengæld er time-to-market ofte reduceret når man bruger Java og C#, hvis man eller taler relativt simple applikationer (læs: ikke tidskritiske). Der er selvfølgelig andre årsager også, og sikkert "tungere" årsager (såsom de ansatte man har kun kan Java, eller man skal udvikle til .NET (managed C++ er sgu for grimt)), men bottom line er C++ et yderst veludviklet sprog.
#9
Det er ikke helt rigtigt. C++ blev oprindeligt kaldt "C med klasser" i folkemunde..nørdmunde...Det passer nu heller ikke helt, da C++ er meget mere. Tag f.eks. templates. De giver en kæmpe ekstra dimension til din kode. C#s implementering af templates (generics) er egentlig også ok, skal det lige siges (Javas er elendig...er ikke andet en type casts a la (TYPE)var, hvilket ikke har anden effekt end at virke mere forvirrende end håndkodede typecasts).
Desuden halter det med chips der understøtter java eller .NET kode (sidstnævnte er der lavet, kom i efteråret). Til gengæld er der masser af chips du kan kode i C++ til.
Jeg tror der går laaaaaang tid før man ser Oracle eller lign. lave databaser i Java eller på .NET platformen. Her er run-time enginen alt for langsom, og derfor bruger man C++ (eller ældre sprog).
#6, LOL!!!
Altså, jeg programmerer selv i C++, men alt det her overrasker mig lidt. At kalde C++ for crossplatform er vel sådanset rigtigt nok, på source niveau, men grunden til det er det er jo at du har implementeret API'erne på den specifikke platform og at du har en compiler der compilerer til den specifikke platform. Altså, hvis det er rigtigt så er alt jo krydsplatform.
Java og C# som begge er gode sprog er binært kompatible, af stortset samme årsag som C++, der bruger man bare en JIT compiler istedetfor.
Synes hele det her crossplatform udtryk bliver misbrugt en hel del. Ethvert sprog kan blive krydsplatform, men det der gør at man betegner et stykke kode som krydsplatform er at man ikke bruger biblioteker og funktioner som endnu ikke er implementeret på en specifik platform, derfor giver det ingen mening at kalde C++ sproget som helhed krydsplatform.
Java og C# som begge er gode sprog er binært kompatible, af stortset samme årsag som C++, der bruger man bare en JIT compiler istedetfor.
Synes hele det her crossplatform udtryk bliver misbrugt en hel del. Ethvert sprog kan blive krydsplatform, men det der gør at man betegner et stykke kode som krydsplatform er at man ikke bruger biblioteker og funktioner som endnu ikke er implementeret på en specifik platform, derfor giver det ingen mening at kalde C++ sproget som helhed krydsplatform.
#11 Nej der er en del C og C++ i de fleste OS'er f.eks. er grunden til at unix er så portabelt er det hovedsageligt er C og senere C++ der ligger bag.
C/C++ er netop så tilpas lowlevel at det kan bruges helt nede på kerne nivou.
Java og C# har kræver både et OS og et runtime for at kører selvom det teoretisk set er mugligt at lave kompilere der kan oversætte til ren maskinkode.
Iøvrigt nogen der ved om GCC-java kan klare den opgave?
C/C++ er netop så tilpas lowlevel at det kan bruges helt nede på kerne nivou.
Java og C# har kræver både et OS og et runtime for at kører selvom det teoretisk set er mugligt at lave kompilere der kan oversætte til ren maskinkode.
Iøvrigt nogen der ved om GCC-java kan klare den opgave?
#13:
Det er ikke helt korrekt.. tjek f.eks www.mono-project.com
Hvis man holder sig fra f.eks Windows.Forms, og bruger f.eks GTK# så kan det godt lade sig gøre at lave crossplatform apps med C#
... hvor C# (.NET) er windows only
Det er ikke helt korrekt.. tjek f.eks www.mono-project.com
Hvis man holder sig fra f.eks Windows.Forms, og bruger f.eks GTK# så kan det godt lade sig gøre at lave crossplatform apps med C#
#15
C# er krydsplatform vha. mono, ligesom Java er det. Igen, alle sprog er krydsplatform hvis du laver en implementation på den platform, i sidste ende skal alt laves om til maskinkode, om det sker vha. en JIT compiler eller en almindelig compiler er vel ikke afgørende i den sammenhæng.
Og husk på at C++ ikke er krydsplatform på samme måde som Java og C#. C# og java er binært kompatible (og source kampatible).
C++ er KUN source kompatibelt.
C# er krydsplatform vha. mono, ligesom Java er det. Igen, alle sprog er krydsplatform hvis du laver en implementation på den platform, i sidste ende skal alt laves om til maskinkode, om det sker vha. en JIT compiler eller en almindelig compiler er vel ikke afgørende i den sammenhæng.
Og husk på at C++ ikke er krydsplatform på samme måde som Java og C#. C# og java er binært kompatible (og source kampatible).
C++ er KUN source kompatibelt.
Faktisk er det også muligt at bruge Windows.Forms med mono (endnu er det en underudviklet implementering).
Jeg synes heller ikke at vi skal glemme at der også er et dotGNU projekt der konkurrerer (tonen udviklerne imellem gør at jeg ikke vil kalde det samarbejde, selvom de låner af hinanden) med mono. dotGNU har også en implementering af Windows.Forms.
Jeg synes heller ikke at vi skal glemme at der også er et dotGNU projekt der konkurrerer (tonen udviklerne imellem gør at jeg ikke vil kalde det samarbejde, selvom de låner af hinanden) med mono. dotGNU har også en implementering af Windows.Forms.
#19
C og C++ er højniveau sprog :)
C# og java er højniveau med binær kompatibilitet, og det er sådanset den eneste grundlæggende forskel.
C og C++ er højniveau sprog :)
C# og java er højniveau med binær kompatibilitet, og det er sådanset den eneste grundlæggende forskel.
#22
Hvilket niveau er det du mener der er imellem C++ og C#? Når vi snakker om C/C++ og ASM, så er forskellen let at få øje på (hvilket den også er imellem ASM og C#, java osv...), der er compileren et abstraktionsniveau, og hvis man har prøvet at kode asm, er det et abstraktionslag man sætter stor pris på.
Hvis vi så tager java og C#, så kunne man selvfølgelig argumentere for at JIT compileren der laver bytecode om til maskinkode er et ekstra abstraktionslag, men som jeg ser det er det eneste du har gjort at udsætte kompileringen, og vha. bytecode gjort denne process mere effektiv.
Men hvis vi snakker om sproget i sig selv, så er der jo ingen forskel på hvad det reelt gør. Hvis det er garbage collection i mener gør forskellen, jamen så findes der også implementationer af det, igen, jeg kan ikke rigtigt se forskellen i selve sproget, derfor vil jeg holde ved mine beskrivelser.
C++ = højniveau sprog
C#, Java = højniveau sprog med binær kompatibilitet
Når det så er sagt, så er det jo en relativt ligegyldig diskussion, og jeg ville ikke have skrevet indlægget hvis det ikke var fordi jeg synes at det har aspekter der er interessant af andre årsager. Men at kalde C/C++ for et lavniveau sprog er et sikkert bevis på at man ALDRIG har kodet i assembler.
Hvilket niveau er det du mener der er imellem C++ og C#? Når vi snakker om C/C++ og ASM, så er forskellen let at få øje på (hvilket den også er imellem ASM og C#, java osv...), der er compileren et abstraktionsniveau, og hvis man har prøvet at kode asm, er det et abstraktionslag man sætter stor pris på.
Hvis vi så tager java og C#, så kunne man selvfølgelig argumentere for at JIT compileren der laver bytecode om til maskinkode er et ekstra abstraktionslag, men som jeg ser det er det eneste du har gjort at udsætte kompileringen, og vha. bytecode gjort denne process mere effektiv.
Men hvis vi snakker om sproget i sig selv, så er der jo ingen forskel på hvad det reelt gør. Hvis det er garbage collection i mener gør forskellen, jamen så findes der også implementationer af det, igen, jeg kan ikke rigtigt se forskellen i selve sproget, derfor vil jeg holde ved mine beskrivelser.
C++ = højniveau sprog
C#, Java = højniveau sprog med binær kompatibilitet
Når det så er sagt, så er det jo en relativt ligegyldig diskussion, og jeg ville ikke have skrevet indlægget hvis det ikke var fordi jeg synes at det har aspekter der er interessant af andre årsager. Men at kalde C/C++ for et lavniveau sprog er et sikkert bevis på at man ALDRIG har kodet i assembler.
Men at kalde C/C++ for et lavniveau sprog er et sikkert bevis på at man ALDRIG har kodet i assembler.
Hvem kalder da C/C++ for lavniveau? Jeg argumenterer for hvorfor jeg mener ASM er et lavniveau, C/C++ mellemniveau og Java/.NET højniveau. Med C++ kan du det hele, abstraktioner/komplekse datatyper som i Java/C# men også pointer/assembler instruktioner og direkte adgang til I/O hvis dette måtte påkræves.
Hvis vi så tager java og C#, så kunne man selvfølgelig argumentere for at JIT compileren der laver bytecode om til maskinkode er et ekstra abstraktionslag, men som jeg ser det er det eneste du har gjort at udsætte kompileringen, og vha. bytecode gjort denne process mere effektiv.
Nu er der ikke særlig mange effektive ting ved hverken bytekode/JIT eller en garbage collector. Du mener altså ikke der er niveauforskel på om man i C/C++ sidder og styrer sin heap med pointere og så Java/C# hvor man er underlagt en non-deterministisk oprydningsprocess og derfor er fuldstændig ligeglad med disse fysiske ressourcer?
#24
Jeg vil nu mene at hele OO aspeket give en niveauforskel, det indfører i hvert fald et abstraktionsniveau. Ser nærmere C som "mellem niveau" og C++ højniveau.
Og du tager fejl vedrørende C#.
For det første er det en kæmpe fejltagelse at sætte C# managed code = non-deterministisk. Der er massere af funktionalitet til at styre hvordan garbagecollection foregår. Og det benyttes i høj grad de fleste steder hvor der kodes i C#.
For det andet er du ikke tvunget til at bruge managed code i C#. Du kan definere udvalge dele af din kode til at være 'unsafe', og så kan du tilgå hukommelsen direkte lige så meget som du lyster.
Har selv kodet en del forskellige sprog på forskellige niveauer fra MIPS og Alpha assembly i den ene ende, til Java og C# i den anden ende. Og C# er et rigtig dejligt sprog, og powerful nok til de meste.
Jeg vil nu mene at hele OO aspeket give en niveauforskel, det indfører i hvert fald et abstraktionsniveau. Ser nærmere C som "mellem niveau" og C++ højniveau.
Og du tager fejl vedrørende C#.
For det første er det en kæmpe fejltagelse at sætte C# managed code = non-deterministisk. Der er massere af funktionalitet til at styre hvordan garbagecollection foregår. Og det benyttes i høj grad de fleste steder hvor der kodes i C#.
For det andet er du ikke tvunget til at bruge managed code i C#. Du kan definere udvalge dele af din kode til at være 'unsafe', og så kan du tilgå hukommelsen direkte lige så meget som du lyster.
Har selv kodet en del forskellige sprog på forskellige niveauer fra MIPS og Alpha assembly i den ene ende, til Java og C# i den anden ende. Og C# er et rigtig dejligt sprog, og powerful nok til de meste.
#24
Okay, glem lavniveau delen, du har ret, der er ingen der har påstået det er lavniveau.
Mht. pointere så har du ret i at java ikke bruger pointere, C# understøtter derimod pointere, du skal godt nok specifikt bede den om det, og så får du nogle meget store advarsler og garbage collection bliver slået fra, men du kan faktisk godt bruge pointere i C#.
Bytecode gør JIT compileringen mere effektiv, vi kan sagtens blive enige om at JIT compilering er møg ineffektivt, jeg argumenterede bare for årsagen til brug af bytecode, hvilket både mono og java bruger.
Det jeg derudover sagde var at der FINDES garbage collection implementationer til C++, dvs. du kan vha. extensions tilføje den slags, du har ret i at det ikke er en del af grundsproget, men som jeg også lige fortalte, der kan du i C# deaktivere garbage collection og tillade pointers, og så er du vel ligeså langt?!
Det jeg prøver at komme frem til er, at sprogene grundlæggende set fungerer på samme måde, de har forskellige features lagt oven på, som i C# og javas tilfælde gør at der er nogen ting man ikke behøver tænke på, men det har ikke noget med sproget i sig selv at gøre, i begge tilfælde kaldes systemfunktioner igennem libraries, den eneste grundlæggende forskel er at det java og C# går via. bytecode og en JIT compiler hvorimod C/C++ går direkte til maskinkode.
Undskyld hvis jeg fik sagt tingene lidt uklart før, jeg kan udemærket godt se ideen i din niveau adskillelse, jeg mener bare ikke der er nogen grund til at lave mellemniveau adskillelse, da sprogene generelt set ikke er meget forskellige, du kan ret let tilføje garbage collection til C++, og du kan uden problemer bruge pointere i C#.
Okay, glem lavniveau delen, du har ret, der er ingen der har påstået det er lavniveau.
Mht. pointere så har du ret i at java ikke bruger pointere, C# understøtter derimod pointere, du skal godt nok specifikt bede den om det, og så får du nogle meget store advarsler og garbage collection bliver slået fra, men du kan faktisk godt bruge pointere i C#.
Bytecode gør JIT compileringen mere effektiv, vi kan sagtens blive enige om at JIT compilering er møg ineffektivt, jeg argumenterede bare for årsagen til brug af bytecode, hvilket både mono og java bruger.
Det jeg derudover sagde var at der FINDES garbage collection implementationer til C++, dvs. du kan vha. extensions tilføje den slags, du har ret i at det ikke er en del af grundsproget, men som jeg også lige fortalte, der kan du i C# deaktivere garbage collection og tillade pointers, og så er du vel ligeså langt?!
Det jeg prøver at komme frem til er, at sprogene grundlæggende set fungerer på samme måde, de har forskellige features lagt oven på, som i C# og javas tilfælde gør at der er nogen ting man ikke behøver tænke på, men det har ikke noget med sproget i sig selv at gøre, i begge tilfælde kaldes systemfunktioner igennem libraries, den eneste grundlæggende forskel er at det java og C# går via. bytecode og en JIT compiler hvorimod C/C++ går direkte til maskinkode.
Undskyld hvis jeg fik sagt tingene lidt uklart før, jeg kan udemærket godt se ideen i din niveau adskillelse, jeg mener bare ikke der er nogen grund til at lave mellemniveau adskillelse, da sprogene generelt set ikke er meget forskellige, du kan ret let tilføje garbage collection til C++, og du kan uden problemer bruge pointere i C#.
C++ er det helt store fortrukne sprog. Windows er programmeret i 95 % c++ og 5 % openGL, samt store spilfirmaer såsom Blizzard vil have c++ programmøre. C++ er også 10 gange hurtigere end java, og java kan ikke lave spil som ex. counter-strike samt warcraft 3!..
DER KOMMER NOK ET NYT SPROG INDEN FOR NOGLE ÅR, SOM BLIVER BEDRE END SPROGENE!
DER KOMMER NOK ET NYT SPROG INDEN FOR NOGLE ÅR, SOM BLIVER BEDRE END SPROGENE!
#28
Er du sikker på Windows er programmeret på %5 OpenGL? Det må jeg nu nok stille mig tvivlende overfor, eftersom MS nok ville bruge Direct3D.
Jeg indrømmer gerne, at jeg ikke aner hvilke sprog, spil bliver skrevet i, men jeg ku forestille mig, det ikke er ren C++.
Er der nogen der ved det?
Er du sikker på Windows er programmeret på %5 OpenGL? Det må jeg nu nok stille mig tvivlende overfor, eftersom MS nok ville bruge Direct3D.
Jeg indrømmer gerne, at jeg ikke aner hvilke sprog, spil bliver skrevet i, men jeg ku forestille mig, det ikke er ren C++.
Er der nogen der ved det?
OpenGL og DirectX er ikke sprog. Jeg vil tro at hvis der er noget der er 95% i Windows så er det C kode, det er ihvertfald ikke C++ da det ville medføre et inkompatibelt design.
#28: Du skal nok lige tjekke faktum inden du udtaler dig .. OpenGL bruges ikke af Microsoft - som ann o. onymose skriver så har de deres egen DirectDraw og Direct3D-extensions. I øvrigt så tvivler jeg på at der benyttes Direct3D på desktop'en
Java og C# for den sags skyld kan godt lave spil som Counterstrike og Warcraft - jeg har set Quake3 lavet i C#, men jeg _tror_ ikke det er særlig brugbart da der er nogle store hastighedsforringelser ved, at koden skal fortolkes gennem en JIT-compiler.
#29: Jeg havde fat i Quake2-sovsen på et tidspunkt.. den kan i øvrigt hentes på ID Softwares hjemmeside og det var en blanding af C og C++
Java og C# for den sags skyld kan godt lave spil som Counterstrike og Warcraft - jeg har set Quake3 lavet i C#, men jeg _tror_ ikke det er særlig brugbart da der er nogle store hastighedsforringelser ved, at koden skal fortolkes gennem en JIT-compiler.
#29: Jeg havde fat i Quake2-sovsen på et tidspunkt.. den kan i øvrigt hentes på ID Softwares hjemmeside og det var en blanding af C og C++
#31 hastigheds forøgelsen ved C++ er meget overvurderet.
Jo JIT engingen og parseren giver en masse overhead men det er ikke et overhead der vokser jo stårrer koden bliver.
Altså Java eller .NET(net er vist værst) bruger noget ram og ligger beslag på nogle CPU cykler men for sådan noget som quake overheader nok under 10%.
Jo JIT engingen og parseren giver en masse overhead men det er ikke et overhead der vokser jo stårrer koden bliver.
Altså Java eller .NET(net er vist værst) bruger noget ram og ligger beslag på nogle CPU cykler men for sådan noget som quake overheader nok under 10%.
#31
Det lyder interessant, ku da være man skulle kigge på den på et tidspunkt.
Edit:
ftp://ftp.idsoftware.com/idstuff/source/quake2.zip hvis andre sku være interesseret :)
Det lyder interessant, ku da være man skulle kigge på den på et tidspunkt.
Edit:
ftp://ftp.idsoftware.com/idstuff/source/quake2.zip hvis andre sku være interesseret :)
Jeg synes at det er lidt af et Moores Law-paradox at man er holdt op med at udvikle effektivt til fordel for nemt.
#35: Du har ret, men jeg kan forestille sommetider kan det bedre betale sig. Det kan være svært at forklare en kunde hvorfor der skal bruges x antal timer på optimering af noget kode, hvis det i kundens øjne ser ud til ud til at virke 100% uden grelle fejl.
Det er der "håndværkerne" adskiller sig fra "købmændene"..
Jeg kan ikke udtale mig så meget omkring det at kode professionelt, for jeg arbejder ikke med programmering på andet end hobbyplan, men jeg kan forestille mig at deadlines osv. tvinger folk til at springe op og falde ned på det med optimeringen.
Det er der "håndværkerne" adskiller sig fra "købmændene"..
Jeg kan ikke udtale mig så meget omkring det at kode professionelt, for jeg arbejder ikke med programmering på andet end hobbyplan, men jeg kan forestille mig at deadlines osv. tvinger folk til at springe op og falde ned på det med optimeringen.
#37: Ja, det gør jeg sq også *G*...nej det var mere proof-of-concept..:-)
Nå, for lige at gøre forvirringen total, så var det Quake2 og det er lavet i Managed C++.NET .. godmorgen Simm! .. link: http://www.vertigosoftware.com/Quake2.htm
men det kunne vel lige så godt være lavet i C#
#38: Med engine, svjh.. :-)
Nå, for lige at gøre forvirringen total, så var det Quake2 og det er lavet i Managed C++.NET .. godmorgen Simm! .. link: http://www.vertigosoftware.com/Quake2.htm
men det kunne vel lige så godt være lavet i C#
#38: Med engine, svjh.. :-)
Det så vidt jeg ved faktisk set at perl programmer kører hurtigere end tilsvarende C programmer simpelt hen forde der er gået så meget arbejde i at optimere parseren, at almindelige c programører med en deadline ikke kan følge med.
I visse situationer kan det værre det samme med java.
Altså selvom teorien siger at C/C++ kan blive hurtigere betyder der ikke at det altid virker sådan.
#37 java og .net runtimes kræver en del ram men når først der er afsat ram og cpu resourcer til JRE'et så det skal der værre plads til, men det er rimeligt statisk, altså java er stort set ligeglad med om den kører et "hello world" program eller quake, java's footprint på systemer er vist stort set det samme
I visse situationer kan det værre det samme med java.
Altså selvom teorien siger at C/C++ kan blive hurtigere betyder der ikke at det altid virker sådan.
#37 java og .net runtimes kræver en del ram men når først der er afsat ram og cpu resourcer til JRE'et så det skal der værre plads til, men det er rimeligt statisk, altså java er stort set ligeglad med om den kører et "hello world" program eller quake, java's footprint på systemer er vist stort set det samme
#39
Okay, ret interessant faktisk. Ifølge siden:
-- altså at det kun er den assembleroptimerede kode der er markant hurtigere end .NET, og native C++ ikke er specielt meget hurtigere. I hvert fald i deres tilfælde. Hmm.
#40
Ingen kan bilde mig ind at "nogle perl/java/BASIC programmer kører hurtigere end tilsvarende C/C++ programmer". En smart C-programmør bruger selvfølgelig et eksternt library, der er lige så optimeret som de libraries som VM'en stiller til rådighed.
Men ja, det forkorter da udviklingstiden hvis man får alt serveret på et sølvfad - selvom min erfaring siger mig, at det ofte medføre at man tænker sig mindre om over hvad det _egentligt_ er man har gang i :)
Nå, for lige at gøre forvirringen total, så var det Quake2 og det er lavet i Managed C++.NET .. godmorgen Simm! .. link: http://www.vertigosoftware.com/Quake2.htm
men det kunne vel lige så godt være lavet i C#
Okay, ret interessant faktisk. Ifølge siden:
Note, the assembly code was disabled for the native and managed versions so both versions are slower than the original Quake version.
-- altså at det kun er den assembleroptimerede kode der er markant hurtigere end .NET, og native C++ ikke er specielt meget hurtigere. I hvert fald i deres tilfælde. Hmm.
#40
Ingen kan bilde mig ind at "nogle perl/java/BASIC programmer kører hurtigere end tilsvarende C/C++ programmer". En smart C-programmør bruger selvfølgelig et eksternt library, der er lige så optimeret som de libraries som VM'en stiller til rådighed.
Men ja, det forkorter da udviklingstiden hvis man får alt serveret på et sølvfad - selvom min erfaring siger mig, at det ofte medføre at man tænker sig mindre om over hvad det _egentligt_ er man har gang i :)
"...og Bjarne Stroustrup sagde ... ik' en skid dit kvaj, han er død, han ligger hjemme i kælderen hos mig .."
#43 "sjov" giver ikke mig smør på brødet ;) Og hvis din kunde skal betale det dobbelte, fordi du synes produktet er bedre efter en optimering, er jeg ikke sikker på at kunden vil være enig.
Jeg kan godt lide de 3 regler om optimering:
1. Don't optimize yet.
2. Don't optimize yet.
3. Don't optimize yet.
Og hvad angår udviklingstid, så er der vel en grund til at mange spilengines har et scriptingsprog ovenpå?
Disclaimer: Jeg udvikler ikke i C/C++, jeg har bedre ting at bruge min tid på ;)
Jeg kan godt lide de 3 regler om optimering:
1. Don't optimize yet.
2. Don't optimize yet.
3. Don't optimize yet.
Og hvad angår udviklingstid, så er der vel en grund til at mange spilengines har et scriptingsprog ovenpå?
Disclaimer: Jeg udvikler ikke i C/C++, jeg har bedre ting at bruge min tid på ;)
#28 Der tager du nu gevaldigt fejl. Mindst 80% af Windows er ren C kode, hele win32 API'et (incl. DirextX) er jo C. C++ udgør vel ca. 15% og dækker over programmer og komplekse kontroller (Toolbar/Rebar) der er kommet til i det sidste årti, hvor MFC har hjulpet til med et abstraktionslag oven på C.
De resterende 5% udgøres af Assembler, Delphi, VB6 mm. fra 3. part applikationer Microsoft har købt. Der står mere omkring emnet i "Programming Windows With MFC" (ISBN: 1572316950) hvis du er intereseret.
Edit: Visual Studio.2003 ser ud til at være skrevet i managed C++.
De resterende 5% udgøres af Assembler, Delphi, VB6 mm. fra 3. part applikationer Microsoft har købt. Der står mere omkring emnet i "Programming Windows With MFC" (ISBN: 1572316950) hvis du er intereseret.
Edit: Visual Studio.2003 ser ud til at være skrevet i managed C++.
#46
Du har ret, det er hurtigere at lave en lille scripting engine end at rette source kode og compile for de ubeslutsomme grafikere og lydfolk hele tiden. Så kan man som programmør koncentrere sig om hvad der er vigtigt, nemlig god, effektiv og robust kode.
Jeg forstår ikke din kritik af C++. Det tager ikke længere tid at udvikle software med C++, når man kan C++. Java og C# er bare endnu højere abstraktionssprog og er derfor nemmere at lære.
Jeg er ikke forretningsmand. Jeg er hacker og koder ikke for at blive rig, men for at få et kick når jeg finder den bedste måde at låse et givent problem på. Jeg ville ikke kunne arbejde et sted hvor sælgerne sælger et produkt, jeg skal stå til ansvar for, som jeg ikke mener er den bedste løsning.
Og hvad angår udviklingstid, så er der vel en grund til at mange spilengines har et scriptingsprog ovenpå?
Du har ret, det er hurtigere at lave en lille scripting engine end at rette source kode og compile for de ubeslutsomme grafikere og lydfolk hele tiden. Så kan man som programmør koncentrere sig om hvad der er vigtigt, nemlig god, effektiv og robust kode.
Jeg forstår ikke din kritik af C++. Det tager ikke længere tid at udvikle software med C++, når man kan C++. Java og C# er bare endnu højere abstraktionssprog og er derfor nemmere at lære.
Jeg er ikke forretningsmand. Jeg er hacker og koder ikke for at blive rig, men for at få et kick når jeg finder den bedste måde at låse et givent problem på. Jeg ville ikke kunne arbejde et sted hvor sælgerne sælger et produkt, jeg skal stå til ansvar for, som jeg ikke mener er den bedste løsning.
#48
Det er nu også for at level designere (eller gameplay designere) kan arbejde effektivt (uden krav om at de skal være 1337 haXors). Og gøre tilgangen til engine'en nemmere (hvilket kan have betydning hvis du vil sælge din engine).
Den bedste løsning behøver ikke være den optimerede. Optimering kan gå ud over læsbarheden og/eller portability, og så sidder du med tydning af koden næste gang der skal pilles i den e.l. Optimering behøver heller ikke være den elegante tilgang.
Lightning fast eller ultra slim behøver altså ikke altid være den bedste løsning. Man har nogle kravspecifikationer og så overholder man dem. Om man gør det med 10% eller 20% er vel så knap så vigtigt, hvis det betyder væsentlige omkostningsforøgelser?
Det må nødvendigvis være et kompromis. Hvis kritiske operationer skrives i Assembler i engines, men resten i C/C++, hvorfor skriver man ikke alt i Assembler så - det er vel hurtigere?
Det er nu også for at level designere (eller gameplay designere) kan arbejde effektivt (uden krav om at de skal være 1337 haXors). Og gøre tilgangen til engine'en nemmere (hvilket kan have betydning hvis du vil sælge din engine).
Den bedste løsning behøver ikke være den optimerede. Optimering kan gå ud over læsbarheden og/eller portability, og så sidder du med tydning af koden næste gang der skal pilles i den e.l. Optimering behøver heller ikke være den elegante tilgang.
Lightning fast eller ultra slim behøver altså ikke altid være den bedste løsning. Man har nogle kravspecifikationer og så overholder man dem. Om man gør det med 10% eller 20% er vel så knap så vigtigt, hvis det betyder væsentlige omkostningsforøgelser?
Det må nødvendigvis være et kompromis. Hvis kritiske operationer skrives i Assembler i engines, men resten i C/C++, hvorfor skriver man ikke alt i Assembler så - det er vel hurtigere?
#48
Ved ikke rigtigt om man kan sige at Java, C# og deslige er nemmere at lære - synes nærmere bare at de er komplicerede "på en anden måde" end f.eks. C++. Det var ligesom i gamle dage, når man skulle lave grafiske programmer -- så skulle man typisk skrive noget assembler der kommunikerede med BIOS'en. Fint nok, da det egentligt var ekstremt simpelt, og da funktionaliteten på et gammeldaws grafikkort var meget begrænset, så kunne man ikke gå helt galt i byen. I dag, hvis man vil have grafik, så bruger man typisk DirectX (hvis man er til den slags)... Nu har man ikke længere brug for at forstå hvordan man kommunikerer direkte med hardwaren, men i stedet skal man vide en masse om objekt-orienteret programmering, klasser, yada-yada.
Det er kompliceret på en mere, hmm, "teoretisk" måde nu om dage, hvorimod det i gamle dage var mere "praktisk".
Kan man ikke sige cirka det samme når man snakker om de gamle sprog kontra de nye?
Synes C++ bærer lidt mere præg af at "man lige skal vide hvor og hvornår man skal svinge en død kat over hovedet", for at man kan få skidtet til at virke. Men det er måske bare mig.
Tja, jeg har efterhånden indset at det er utopisk at tro man kan tillade sig at have dén indstilling, hvis man håber på at kunne tjene penge i den her branche. Men okay det ved du jo også godt :)
Størstedelen af alle PHBs sætter profit over kvalitet, og det kan man selvfølgelig godt forstå. Heldigvis hænger de ting også oftest sammen.
Jeg forstår ikke din kritik af C++. Det tager ikke længere tid at udvikle software med C++, når man kan C++. Java og C# er bare endnu højere abstraktionssprog og er derfor nemmere at lære.
Ved ikke rigtigt om man kan sige at Java, C# og deslige er nemmere at lære - synes nærmere bare at de er komplicerede "på en anden måde" end f.eks. C++. Det var ligesom i gamle dage, når man skulle lave grafiske programmer -- så skulle man typisk skrive noget assembler der kommunikerede med BIOS'en. Fint nok, da det egentligt var ekstremt simpelt, og da funktionaliteten på et gammeldaws grafikkort var meget begrænset, så kunne man ikke gå helt galt i byen. I dag, hvis man vil have grafik, så bruger man typisk DirectX (hvis man er til den slags)... Nu har man ikke længere brug for at forstå hvordan man kommunikerer direkte med hardwaren, men i stedet skal man vide en masse om objekt-orienteret programmering, klasser, yada-yada.
Det er kompliceret på en mere, hmm, "teoretisk" måde nu om dage, hvorimod det i gamle dage var mere "praktisk".
Kan man ikke sige cirka det samme når man snakker om de gamle sprog kontra de nye?
Synes C++ bærer lidt mere præg af at "man lige skal vide hvor og hvornår man skal svinge en død kat over hovedet", for at man kan få skidtet til at virke. Men det er måske bare mig.
Jeg ville ikke kunne arbejde et sted hvor sælgerne sælger et produkt, jeg skal stå til ansvar for, som jeg ikke mener er den bedste løsning.
Tja, jeg har efterhånden indset at det er utopisk at tro man kan tillade sig at have dén indstilling, hvis man håber på at kunne tjene penge i den her branche. Men okay det ved du jo også godt :)
Størstedelen af alle PHBs sætter profit over kvalitet, og det kan man selvfølgelig godt forstå. Heldigvis hænger de ting også oftest sammen.
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
- ⟨
- Nyheder
Gå til bund