mboost-dp1
unknown
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).
Jeg undskylder hermed at jeg glemte level designerene. Muligheden for scripting har ikke noget med værdien af enginen til videresalg at gøre. Den pågældende køber har også udviklere.
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
Nu er det åbenbart gået mere hen i en debat om optimering, men fair nok. Læsbarheden af kildekoden bliver ikke ringere medmindre man ikke bruger det redskab man har i kommentarer. Normalt sælger man heller ikke hele kildekoden til sin engine, men en lukket form med interfaces og der skal derfor ikke kigges på den optimering du har lavet. Overdreven optimering kan skade portabiliteten, men så har man nok roddet sig ud i noget man skulle lade compileren ordne.
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 er så der du tænker som forretningsmand og jeg tænker som hacker.
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?
Der er en rigtig god grund til at vælge Assembler til tidskrævende opgaver (CPU tid), men som du sarkastisk nok prøver at få frem tager det for lang tid i mandetimer at skrive en hel engine. Det tager ikke længere tid at udvikle noget i C++ end det gør at udvikle det i Java eller C#, man får bare et bedre produkt.
#42 det kræver så at c/c++ prøgramøren har adgang til tilstråkkeligt gode biblioteker og stort ikke implemetere noget selv.
Det er specielt i forbindele med tekst manipulitation at jeg har set påstanden om at perl er hurtigere end C, fordi den c kode der inde i perl fortolkeren er så meget foran hvad der ligger i standard biblitekerne.
Det er specielt i forbindele med tekst manipulitation at jeg har set påstanden om at perl er hurtigere end C, fordi den c kode der inde i perl fortolkeren er så meget foran hvad der ligger i standard biblitekerne.
*host*www.boost.org*host*
Inden Java og .NET fans skriger op om biblioteker, så findes der et HAV af den slags..
Som det er sagt, så er Java og C# endnu et abstraktions lag, fuldstændig som assembler er det på maskinkode, C (og lignende)på assember, Java og C# på C(og lignende). C++ er som sagt "C med klasser", og så en hel del mere selvfølgelig...hehe.
Ingen af de enkelte sprog er bedre end andre, medmindre man sammenligner enkelte opgaver løst i hvert sprog (hvilket ikke giver mening...). Sammenligner man sprogenes evne til at løse en bred vifte af opgaver (alså over mange parametre), så vil de hver især have styrker og svagheder. Man skal jo også indberegne udviklingstid, ansattes ekspertiser, kundens krav og generel drift (ment som, man skal jo ikke optimere 5 sekunder væk på en operation, der forekommer én gang hver tiende år, hvis det tager en måned..).
Og så lige en ting:
#46
Disclaimer: Jeg udvikler ikke i C/C++, jeg har bedre ting at bruge min tid på ;)
Fair nok, jeg udvikler i hvad opgaven nu kræver...
Inden Java og .NET fans skriger op om biblioteker, så findes der et HAV af den slags..
Som det er sagt, så er Java og C# endnu et abstraktions lag, fuldstændig som assembler er det på maskinkode, C (og lignende)på assember, Java og C# på C(og lignende). C++ er som sagt "C med klasser", og så en hel del mere selvfølgelig...hehe.
Ingen af de enkelte sprog er bedre end andre, medmindre man sammenligner enkelte opgaver løst i hvert sprog (hvilket ikke giver mening...). Sammenligner man sprogenes evne til at løse en bred vifte af opgaver (alså over mange parametre), så vil de hver især have styrker og svagheder. Man skal jo også indberegne udviklingstid, ansattes ekspertiser, kundens krav og generel drift (ment som, man skal jo ikke optimere 5 sekunder væk på en operation, der forekommer én gang hver tiende år, hvis det tager en måned..).
Og så lige en ting:
#46
Disclaimer: Jeg udvikler ikke i C/C++, jeg har bedre ting at bruge min tid på ;)
Fair nok, jeg udvikler i hvad opgaven nu kræver...
#57
Jeg har en påstand, hvis du kan kode C# kan du også kode C++, hvis du er bange for selv at skulle holde styr på hukommelse så lad være med at bruge pointere, så er 80% af dine hukommelses issue i C++ væk. Derudover så brug GUI libraries der selv holder styr på sine underklasser, så er du stortset hele vejen.
Man kan stortset ignorere hukommelsesstyring i C++ hvis man vælger sine værktøjer med forsigtighed, når det så er sagt, så smider man også en stor del af fleksibiliteten væk, men det må man så leve med.
Jeg koder C++ og C# i fritiden og bruger Java i forbindelse med min uddannelse, så jeg prøver at holde mig godt med. Et andet sprog jeg synes man skal holde øje med og som jeg til en vis grad leger med, er python, det er et herligt sprog, syntaxet er lidt sjovt, men det har nogle fantastisk lækre datatyper.
Jeg har en påstand, hvis du kan kode C# kan du også kode C++, hvis du er bange for selv at skulle holde styr på hukommelse så lad være med at bruge pointere, så er 80% af dine hukommelses issue i C++ væk. Derudover så brug GUI libraries der selv holder styr på sine underklasser, så er du stortset hele vejen.
Man kan stortset ignorere hukommelsesstyring i C++ hvis man vælger sine værktøjer med forsigtighed, når det så er sagt, så smider man også en stor del af fleksibiliteten væk, men det må man så leve med.
Jeg koder C++ og C# i fritiden og bruger Java i forbindelse med min uddannelse, så jeg prøver at holde mig godt med. Et andet sprog jeg synes man skal holde øje med og som jeg til en vis grad leger med, er python, det er et herligt sprog, syntaxet er lidt sjovt, men det har nogle fantastisk lækre datatyper.
#59
Python er lidt underligt, man skal lige vende sig til at indrykning faktisk har en betydning. Men den måde sproget fungerer på synes jeg er lækker, og passer godt til hvis man bare skal implementere noget hurtigt for at teste et eller andet.
Python er lidt underligt, man skal lige vende sig til at indrykning faktisk har en betydning. Men den måde sproget fungerer på synes jeg er lækker, og passer godt til hvis man bare skal implementere noget hurtigt for at teste et eller andet.
#58 Jeg er enig, bare fordi man KAN skyde sig i foden med C++ behøver jo ikke, at dette ej kan undgås.
Når det så er sagt; jeg arbejder med J2EE til hverdag og det er jo noget kedeligere (mindre tilfredsstillende) end f.eks. at skrive noget i C++ og rent faktisk konstatere, at ens algoritme fungerer og husker at frigøre alle pointere på heapen. Det er noget intuiativt i mennesket tror jeg, ønsket om at forbedre og optimere mest muligt. Desværre er min boss mere over i lejren "kan det compile? Så virker det som det skal!".
Når det så er sagt; jeg arbejder med J2EE til hverdag og det er jo noget kedeligere (mindre tilfredsstillende) end f.eks. at skrive noget i C++ og rent faktisk konstatere, at ens algoritme fungerer og husker at frigøre alle pointere på heapen. Det er noget intuiativt i mennesket tror jeg, ønsket om at forbedre og optimere mest muligt. Desværre er min boss mere over i lejren "kan det compile? Så virker det som det skal!".
En forklaring på hans citat:
http://www.research.att.com/~bs/bs_faq.html#really...
Iøvrigt en ret god FAQ.
http://www.research.att.com/~bs/bs_faq.html#really...
Did you really say that?
"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off." Yes, I said something like that. What people tend to miss, is that what I said there about C++ is to a varying extent true for all powerful languages. As you protect people from simple dangers, they get themselves into new and less obvious problems. Someone who avoids the simple problems may simply be heading for a not-so-simple one. One problem with very supporting and protective environments is that the hard problems may be discovered too late or be too hard to remedy once discovered. Also, a rare problem is harder to find than a frequent one because you don't suspect it.
"Within C++, there is a much smaller and cleaner language struggling to get out." Yes, that quote can be found on page 207 of The Design and Evolution of C++. And no, that smaller and cleaner language is not Java or C#. The quote occurs in a section entitled "Beyond Files and Syntax". I was pointing out that the C++ semantics is much cleaner than its syntax. I was thinking of programming styles, libraries and programming environments that emphasized the cleaner and more effective practices over archaic uses focussed on the low-level aspects of C.
"I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone" I said that after a frustrating attempt to use a "feature-rich" telephone sometime around 1990. I'm sure the sentiment wasn't original, and probably not even the overall phrasing; someone must have thought of that before me.
"There are only two kinds of languages: the ones people complain about and the ones nobody uses". Again, I very much doubt that the sentiment is original. Of course, all "there are only two" quotes have to be taken with a grain o salt.
"Proof by analogy is fraud". Page 692 of TC++PL. A good analogy is an excellent way of illustrating an idea, but far too often such analogies are not accompanied by solid reasoning, data, etc.
Iøvrigt en ret god FAQ.
Do you own C++?
No. If anyone "owns C++," it must be the ISO. AT&T gave the rights to the C++ manual that I wrote to the ISO. The ISO C++ Standard is copyrighted by ISO.
Compiler vendors do not pay royalties to me or to AT&T for C++, and ISO standards are specifications intended for royalty-free use by everyone (once they have paid the ISO or a national standard committee for their copy of the standard). The individual compilers are owned by their respective vendors/suppliers.
"But someone from SCO claimed that they own C++"; is that not so? It's complete rubbish. I saw that interview. The SCO guy clearly had no clue what C++ was, referreing to it as "the C++ languages". At most, SCO may own a 15-year old and seriously outdated version of Cfront - my original C++ compiler. I was careful not to patent or trademark anything to do with C++. That's one reason we write plain "C++" and not "C++(tm)". The C++ standard is unencumbered of patents - the committee carefully checked that also.
Om mange år vil der komme sprog som erstatter dem vi har idag .. :) Hvis man jo vil udvikle det helt store skal man starte med at tage C++, men om nogle år kan c# meget mere, og det er nemmere at skifte fra C++ til c# end c# til C++!
C++ -> C#
C++ -> Java
C# -> Java
Java -> C#
er nemme
C# -> C++
Java -> C++
er svære
C++ -> C#
C++ -> Java
C# -> Java
Java -> C#
er nemme
C# -> C++
Java -> C++
er svære
#64
Hvad er du? En eller anden wanna-be IT version af Nostradamus?
----------
Folk sidder og blærer sig med at de kan lægge én til en variabel. Ja det er sgu pragtfuldt *klappe klappe*. Gør dem helt bestemt istand til at bedømme et sprog der har mere end 25 år på bagen.
Til dem der siger at C++ syntaksen er svær... har I overvejet at læse at skrive alle eksemplerne i de billige hæfter forlag fra Globe I har købt? Kodesyntaksen i C++ er EKSTREMT mere ren og logisk bygget op end "herligt-beskyttede-pointerfri-uha-da-da" C# og Java syntax.
C er over 35 år gammelt, C++ var godt på vej i 1980. Begge sprog er uundværlige idag.
Utroligt at folk sammenligner C# med C++ når Visual C++.NET ville være mere nærlæggende.
Hvis jeg skulle ansætte en programmør ville jeg kræve meget meget mere end han blot kunne knalde et par controls på en WINDOWSFORM.
C# er stadigvæk i babystadiet. Syntax er en billig kopi af C++ og det .NET Framework er forfærdeligt.
Dem der er såkaldte kendere af programmeringssprog må hjertens gerne poste et par links til spændende projekter de har lavet. Men hvis det eneste der er kommet ud af det, er en lille prut af en box hvis tekstindhold kan gemmes i en fil så hold venligst mund.
Bjarne Stroustrup, Befiehl - Wir Folgen!
Hvad er du? En eller anden wanna-be IT version af Nostradamus?
----------
Folk sidder og blærer sig med at de kan lægge én til en variabel. Ja det er sgu pragtfuldt *klappe klappe*. Gør dem helt bestemt istand til at bedømme et sprog der har mere end 25 år på bagen.
Til dem der siger at C++ syntaksen er svær... har I overvejet at læse at skrive alle eksemplerne i de billige hæfter forlag fra Globe I har købt? Kodesyntaksen i C++ er EKSTREMT mere ren og logisk bygget op end "herligt-beskyttede-pointerfri-uha-da-da" C# og Java syntax.
C er over 35 år gammelt, C++ var godt på vej i 1980. Begge sprog er uundværlige idag.
Utroligt at folk sammenligner C# med C++ når Visual C++.NET ville være mere nærlæggende.
Hvis jeg skulle ansætte en programmør ville jeg kræve meget meget mere end han blot kunne knalde et par controls på en WINDOWSFORM.
C# er stadigvæk i babystadiet. Syntax er en billig kopi af C++ og det .NET Framework er forfærdeligt.
Dem der er såkaldte kendere af programmeringssprog må hjertens gerne poste et par links til spændende projekter de har lavet. Men hvis det eneste der er kommet ud af det, er en lille prut af en box hvis tekstindhold kan gemmes i en fil så hold venligst mund.
Bjarne Stroustrup, Befiehl - Wir Folgen!
Hold da op, d'herrer -- en særdeles interessant diskussion, må jeg sige. :)
Jeg vil blot indskyde, at C ikke retfærdigt kan kaldes et højniveausprog i dagens termer.
Dette citat beskriver, hvordan jeg anskuer C's niveau. Taget fra Wikipedia.
Jeg vil blot indskyde, at C ikke retfærdigt kan kaldes et højniveausprog i dagens termer.
Dette citat beskriver, hvordan jeg anskuer C's niveau. Taget fra Wikipedia.
C is a relatively minimalist programming language that operates close to the hardware, and is more similar to assembly language than most other programming languages. Indeed, C is sometimes referred to as "portable assembly," reflecting its important difference from assembly languages: C code can be compiled for and run on almost any machine, more than any other language in existence, while assembly languages run on at most a few very specific models of machines. C is typically called a low level or medium level language, indicating how closely it operates with the hardware.
#65:
"Kodesyntaksen i C++ er EKSTREMT mere ren og logisk bygget op end "herligt-beskyttede-pointerfri-uha-da-da" C# og Java syntax."
I stedet for du bare bralrer løs uden at have belæg for det, så vil jeg gerne vide HVORFOR du synes at kodesyntaksen i C++ er mere ren og logisk bygget op.. ?
Apropos knalde controls på en windows form.. er det ikke det man har gjort med Visual Studio, C++ Builder i årevis? :p
"Kodesyntaksen i C++ er EKSTREMT mere ren og logisk bygget op end "herligt-beskyttede-pointerfri-uha-da-da" C# og Java syntax."
I stedet for du bare bralrer løs uden at have belæg for det, så vil jeg gerne vide HVORFOR du synes at kodesyntaksen i C++ er mere ren og logisk bygget op.. ?
Apropos knalde controls på en windows form.. er det ikke det man har gjort med Visual Studio, C++ Builder i årevis? :p
#68:
Det skyldes jo sikkert at nogle af Java-folkene (Sun) tænkte - "hey! C++ er et godt sprog, men vi har nogle ting, vi mener der kan forbedres" .. Udover dette så er udviklere jo - efter min mening svære at overbevise om at nye sprog er bedre - eller i hvertfald mere effektive, se bare på #65, der ikke har noget som helst til overfor .NET eksempelvis..Selvom jeg mener at skulle han skifte til enten C++.NET eller C#, så bliver hans hverdag fantastisk meget nemmere (lyder som en Microsoft-repræsentant lige nu .. det er jeg ikke.. er bare begejstret)
Så hvis de laver sprog som ligger sig op ad eksisterende sprog så er succes'en garanteret. Microsoft har valgt samme strategi og det er der jo nok en grund til. Jeg er sikker på at C# nok skal vinde popularitet efterhånden som sproget modnes.. det har jo ikke mere end 3-4 år på bagen, hvilket ikke er meget, hvis man sammenligner med C++.
Det skyldes jo sikkert at nogle af Java-folkene (Sun) tænkte - "hey! C++ er et godt sprog, men vi har nogle ting, vi mener der kan forbedres" .. Udover dette så er udviklere jo - efter min mening svære at overbevise om at nye sprog er bedre - eller i hvertfald mere effektive, se bare på #65, der ikke har noget som helst til overfor .NET eksempelvis..Selvom jeg mener at skulle han skifte til enten C++.NET eller C#, så bliver hans hverdag fantastisk meget nemmere (lyder som en Microsoft-repræsentant lige nu .. det er jeg ikke.. er bare begejstret)
Så hvis de laver sprog som ligger sig op ad eksisterende sprog så er succes'en garanteret. Microsoft har valgt samme strategi og det er der jo nok en grund til. Jeg er sikker på at C# nok skal vinde popularitet efterhånden som sproget modnes.. det har jo ikke mere end 3-4 år på bagen, hvilket ikke er meget, hvis man sammenligner med C++.
Dem der er såkaldte kendere af programmeringssprog må hjertens gerne poste et par links til spændende projekter de har lavet. Men hvis det eneste der er kommet ud af det, er en lille prut af en box hvis tekstindhold kan gemmes i en fil så hold venligst mund.
Nu kan jeg af gode grunde ikke lægge .NET software ud jeg har skrevet for mit firma, men hvis jeg kunne ville jeg også kun kunne lægge sløv business software ud som webservice klienter og andre kedelige sager.
Hvad jeg derimod kan linke til, er et af mine egne projekter som ganske enkelt ikke kan skrives i C# uden at programmet blev umådeligt langsomt. Det er C++/MFC jeg bruger hvis der skal laves noget seriøst.
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