Funksjon som lager initialer av et navn ?

[Dead_Rabbit]

Flott at det funker!

[kjetil7]

@kjetil7

Har forsøkt å teste ut boost-varianten din kjetil, men får følgende feilmelding:

fatal error C1083: Cannot open include file: 'boost/algorithm/string.hpp': No such file or directory

 

Hmm.. Noen forslag?

 

Eksemplet mitt var bare ment som en illustrasjon på hvor enkelt det kan gjøres med Boost-biblioteket. Du må laste ned Boost (www.boost.org) før du kan kompilere koden. Men jeg tror du slipper å bygge Boost for å kjøre eksemplet mitt.

 

Hvis du ikke kjenner til Boost vil jeg anbefale deg å ta en titt på det. Det har masse snacks som kan forenkle en C++ -programmerers hverdag. De delene jeg har hatt mest nytte av er smartpekerne, parserbiblioteket (Spirit), type traits og strengalgoritmene som jeg brukte i eksemplet.

 

Hvis du jobber med strenger bør du uansett ha tilgang til et bibliotek med utvidet strengfunksjonalitet siden standardbiblioteket ikke alltid strekker til.

[GeirGrusom]

dessuten suger stl, særlig std::string

Jeg misliker sterkt den overdrevne bruken av templates, bare for at de som skriver compileren skal få en enkel jobb.

 

Grunnen til at jeg sjeldent bruker templates, er pga. at compileren får ofte panikk når jeg bruker det i __declspec(dllimport) funksjoner (av en eller annen grunn alltid når jeg har en template (f.eks. stack) i en private eller protected deklarering)

[teflonpanne]

det er tydelig at du ikke vet åssen du bruker stl eller std::string da. for hvis du kunne det så hadde du kunnet skrevet kode 10 ganger så fort og bruke 10 ganger mindre kodelinjer enn "vanilla c++". men du bruker assembler også da, så det er kanskje noe der..

"Jeg misliker sterkt den overdrevne bruken av templates, bare for at de som skriver compileren skal få en enkel jobb."

vet du hvor vanskelig det er å implementere templates i en c++-kompilator? det er først nå at kompilatorene har en nogenlunde grei støtte for templates. det er der for å gjøre det lettere for programmeren. hvis du setter deg ned å ser på hvordan hele stl er designet, er det utrolig effektivt og genialt iforhold til hvor low-level c++ er. templates var egentlig bare beregnet for generisk programmering, men man fant ut at templates egentlig er et turingkomplett compile-time språk ved en "feil". derfor kan man nå til en viss grad gjøre metaprogrammering (koden blir kjørt compile-time) og funksjonell programmering. stl og boost har mange ferdige biblioteker som fjerner noe av styggheten til c++-templates.

 

hva er det som suger med stl? hadde det ikke vært for stl kunne man like gjerne brukt C. stl/templates gjør at c++ klarer å balansere akkurat mellom low-level og high-level på en måte ingen andre språk klarer, og det er også derfor det er så populært. men nå som prosessorkraft ikke spiller så stor rolle lenger blir behovet for c++ mindre og mindre og man kan like gjerne bruke lisp som har alt alle andre språk har, og enda litt til

Endret 23. november 2005 av teflonpanne

[GeirGrusom]

Jeg tror ikke det jeg hører...

men nå som prosessorkraft ikke spiller så stor rolle lenger blir behovet for c++ mindre og mindre og man kan like gjerne bruke lisp som har alt alle andre språk har, og enda litt til

 

Skriver du C++ kode fordi det er enkelt? kanskje du skal prøve C# eller Java istedet?

derfor skriver jeg assembly rutiner, og egen string klasse: folk betaler for en prosessor, og da skal de få alt den er verdt, det gjør du ikke hvis du bruker stl, gir blaffen i dangling referances, eller skriver programmer i Java, Visual Basic eller C#

 

C/C++ var i utgangspunktet laget for å være brukelig til alt, og effektivt.

Derfor skrives alle krevende programmer i C++ og Assembly, f.eks. Quake, mye assembly, ren C kode

 

Siden John Carmack har samme syn på saken som meg, så gjetter jeg at det er mye asm i Doom3 også.

 

CAD programmer må skrives i C++

Renderen i 3D Studio MAX er for det meste skrevet i Assembly, hvordan vet jeg det? fordi det stod i Whats New in 5.0 "Rewritten the renderer in assembly" hvorfor? fordi common lisp, python, java etc. IKKE er effektivt.

pluss at prosessor spesifikke kall, som SSE2 ikke er tilgjenegelig der.

[GenericName]

...

Endret 12. januar 2011 av Token

[GeirGrusom]

tja tjo nja

 

et eksempel:

 

return 0 blir for maskinen seende slik ut:

 

xor eax, eax

 

men det kan skrives slik også:

 

mov eax, 0

 

som er en tyngre måte å gjøre det på, men like mange linjer med kode.

Poenget er at det er mange måter å gjøre ting på, og noen synes jeg er tåpelig fordi jeg skriver assembly rutiner for å tune programmet så godt som mulig, og da er mitt svar: hvorfor i helvete bruker du C++ hvis du ikke bryr deg om hvor mye CPU programmet ditt bruker? C# er mye enklere å lage GUI programmer i, Visual Basic 6.0 gir deg tilogmed en native .exe fil

Husk at en C++ compiler er et program, i høyeste grad et AI program, den prøver å finne den beste løsningen på et problem på grunnlag av et visst spekter med løsninger, og vil sjeldent ligge på linje med det et menneske kan klare, den oversetter linje for linje, noe som er veldig synlig hvis du ser på koden den spytter ut.

 

f.eks.

 

float cos(float)

 

ville jeg, hvis jeg hadde skrevet en effektiv compiler laget slik:

 

cos PROC

fcos

ret

cos ENDP

 

men det gjøres ikke slik, for compileren må holde seg til standarder, og standarden sier at variablen ligger på stacken, og må leses derfra først.

 

Jeg synes ikke stl har de beste løsningene på alle problemene, jeg misliker sterkt bruken av << og >> i stream, grunnet at de blir brukt til noe helt annet i andre sammenhenger, og kan være forvirrende.

 

fordelen en template har, er at kun den koden du bruker blir kompiler, og lagt inn i programmet, men det får du uansett hvis du enten skriver en funksjon kun i en .h fil, eller deklarerer en funksjon som inline.

 

stl er flott for enkle programmer, som ikke er CPU krevende.

selvom stream er kritikkverdig fra mitt synspunkt.

 

Det som irriterer meg, er at mange beskytter ting på grunnlag av at de ikke har vært borti noe annet (Java tilhengere f.eks. )

 

Men nok off-topic. jeg skal holde kjeft nå

folk liker ikke at jeg basher standarder eller folks generelle holding til ting, bare tenk litt igjennom, noen pekte meg til en side som forklarte hvor flott Java var i forhold til andre språk, og at det i enkelte tilfeller var raskere en C++ (som er pisspreik fra ende til annen av opplagte grunner) hvor alt var basert på hva forfatteren syntes, bare fordi noen på internett synes stl er bra, betyr ikke at det er det.

[teflonpanne]

altså, du må få deg en reality check. for det første er dagens kompilatorer så gode til å skrive assembler, at mange ganger vil din assemblerkode være dårligere enn den kompilatoren din skriver. og kan du ta og benchmarke stl mot c++ uten stl og assembler? kan være morsomt å se hvor mye forskjell det blir. jeg tipper det er snakk om millisekunder, som ikke betyr en dritt irl. har du noen gang testet stl mot ikke-stl? har du testet assemblerkoden din mot vanlig c++ og fått differanser som er mer enn et par millisekunder? du må gjerne programmere assembler for min del, og det er godt mulig du sparer et par millisekunder her og der, men har det virkelig noe å si? tror du de som måtte bruke spillet ditt bryr seg eller merker noe i det hele tatt til det?

 

du kan forresten lese litt her: http://theory.stanford.edu/~amitp/rants/c++-vs-c/

 

Conclusions

 

I can't claim that C++ is always faster than C. However, I do claim that C++ templates offer a way to provide library routines that offer the traditional advantages of library routines (ease of use, flexibility) yet still are able to provide speed close to hand-written code. This combination is generally unavailable to programmers using C (or Pascal, or Basic, or Java, or ...). When I programmed in C, I always had to choose between library routines and hand-written code. In C++, I choose (STL) library routines whenever possible. I usually get better (faster and more flexible) code than I would have written myself, and it takes less effort to get it. It's refreshing to finally be able to use library routines without expecting any performance penalties.

Endret 24. november 2005 av teflonpanne

[kjetil7]

GeirGrusom:

 

Stream-delen av standardbiblioteket er ikke en del av STL. Ikke std::string heller for den saks skyld. Jeg deler mange av dine synspunkter rundt iostream-delen av C++ og innrømmer glatt at jeg ofte bruker de gamle C-rutinene istedenfor.

 

Men jeg kan ikke si meg enig i de andre karakteristikkene du gir av STL. Å blande inn assembly her mener jeg blir litt skivebom fordi assembly blir sjelden eller aldri brukt til å skrive kode som skal erstatte STL-kode. Hva har en 3D-renderer med STL å gjøre? Ikke si at du bruker assembly til å lagre, manipulere og hente objekter i en container?

 

Assembly blir hovedsaklig brukt til å knuse tall, heftige tallalgoritmer og embedded systems. C/C++ styrer gjerne logikken, mens assembly-koden blir brukt til å de små kodebitene som er spesielt kritiske. Og av personlig og andre profilerte utvikleres erfaring er det en svært liten del av et program som er kritisk for ytelsen. Spesielt på typen applikasjonene du nevner.

 

STL og for den saks skyld hele standardbiblioteket er en helt annen verden enn assembly og kan ikke sammenlignes fordi de brukes til totalt forskjellige ting.

 

At du ikke liker templates er din fulle rett. Men jeg må kunne si at du går glipp av kanskje C++ sin største styrke. Templates er etter min mening noe av det som gjør C++ så spesielt. Det lar deg skrive svært effektiv kode på en enkel måte. I tillegg får du generell kode som egner seg meget bra til gjenbruk.

 

Utviklingen går framover og koden vi skriver blir enklere for hvert år. Hvis du ønsker å skrive assembly-kode for alt mulig rart, og for så enkle ting som strengbehandling og containere er jeg redd for du ikke vil være veldig konkurransedyktig i et marked som stadig tar i bruk flere høynivå-verktøy.

[teflonpanne]

gameplay > fps http://www.franz.com/success/customer_apps...aughtydog.lhtml

Endret 25. november 2005 av teflonpanne

[Dead_Rabbit]

std::string er da i STL det? std::string er jo bare en typedef basic_string<char>, så.

[GeirGrusom]

altså, du må få deg en reality check. for det første er dagens kompilatorer så gode til å skrive assembler, at mange ganger vil din assemblerkode være dårligere enn den kompilatoren din skriver. og kan du ta og benchmarke stl mot c++ uten stl og assembler? kan være morsomt å se hvor mye forskjell det blir. jeg tipper det er snakk om millisekunder, som ikke betyr en dritt irl. har du noen gang testet stl mot ikke-stl? har du testet assemblerkoden din mot vanlig c++ og fått differanser som er mer enn et par millisekunder? du må gjerne programmere assembler for min del, og det er godt mulig du sparer et par millisekunder her og der, men har det virkelig noe å si? tror du de som måtte bruke spillet ditt bryr seg eller merker noe i det hele tatt til det?

 

du kan forresten lese litt her: http://theory.stanford.edu/~amitp/rants/c++-vs-c/

 

Conclusions

 

I can't claim that C++ is always faster than C. However, I do claim that C++ templates offer a way to provide library routines that offer the traditional advantages of library routines (ease of use, flexibility) yet still are able to provide speed close to hand-written code. This combination is generally unavailable to programmers using C (or Pascal, or Basic, or Java, or ...). When I programmed in C, I always had to choose between library routines and hand-written code. In C++, I choose (STL) library routines whenever possible. I usually get better (faster and more flexible) code than I would have written myself, and it takes less effort to get it. It's refreshing to finally be able to use library routines without expecting any performance penalties.

5201179[/snapback]

 

 

Dette er tøv fra ende til annen; en C++ compiler er en ROBOT, den kan ikke skrive like bra kode av flere årsaker, dette burde du vite, kikk på det Visual C++ skriver ut av assembly, og sammenlign det med det du ville skrevet, ditt er MYE mer effektivt.

Velg Options->C/C++->Output Files->Assembly Listing velg Assembly With Source Code

 

så ser du tydelig at compileren jobber linje til linje, å få til noe annet er ekstremt vanskelig, hvis ikke umilig å få til riktig med en transistorprosessor.

 

Tror du folk kjøper en dual core AMD for at programmererne skal få en enklere jobb?

tror ikke det nei. jo raksere prosessorene blir, jo mer kan vi få til, mer kompleks fysikk, flere shaders samtidig, større teksturer etc.

 

Se på Medal Of Honor 2, det er så skit-dårlig programmert at jeg skammer meg over å vite om spillet, hvorfor? fordi de har jobber akkurat som det du snakker om.

Mens de før bruke Quake3 engine, bruker de nå sin egen, og den er ikke bra, den bruker garnny 3D, og sikkert MYE scripting, som python e.l.

Jeg sier egentlig ingenting imot Granny 3D, har aldri brukt det, men jeg peker på det at de har laget sin egen engine, hvor 3D grafikken allerede er laget for dem, men likevel går spillet rævva.

 

Bruken av templates:

Hva er templates til? for at en skal slippe å skrive samme koden om, og om, og om igjen med forskjellige overloads og datatyper, og faktisk implementere ting på en måte som ikke ville vært mulig ellers. det er ikke det jeg klager på, det er det at stl biblioteket har skrevet ting med templates som er strengt att unødvendig, som kanskje gir deg inline funksjoner der du helst ville ungått det?

dessuten å kalle kildekoden uoversiktelig er en underdrivelse.

[teflonpanne]

STL er standard template library som ble utviklet av alexander stepanov uavhengig av c++-standarden, men mye av STL ble lagt med til standarden, akkurat som mye av boost kommer til å være med i den neste c++-standarden. std::string var ikke med i STL.

 

og lykke til geirgrusom, lær deg litt om ting før du uttaler deg om dem