Hur ska en funktions definition se ut för att ta en pekare till en pekare som argument?
Pekare till pekare
15 svar · 567 visningar · startad av Alpha II
I all välmening så tror jag att Alpha II skulle vinna väldigt mycket på en grundläggande bok i C++.
En bok som kan relommenderas till en nybörjare är: C++ Primer Third Edition av Stanley B. Lippman, Josée Lajoie. Den går igenom grunderna i C++, avancerad C++ och det mesta däremellan, grunderna i programmering allmänt, dessutom hur man programmerar enligt procedurorientering, objektbaserat - vad de nu menar med det - samt OOP. Den kostar nog en del men innehåller också massor! Jag har den själv. Vet inte om den finns på svenska eller endast på engelska.
Engelska böcker är generellt sett betydligt bättre som läroböcker. Själv så rekommenderar jag ändå (min vana trogen):
"C++ Programmering" av S.Prata eller "C++ Direkt" av J.Skansholm.
Tycker att en bra C++ bok ska i första hand belysa OOP, men möjligen upplysa om att det finns imperativa sätt att programmera på.
r: stavfel
Alpha II äger redan C++ programmering av Stephen Prata. Väldigt bra bok. :)
Då kanske han ska börja läsa den också. ;)
Tror att det vore bra om spekulationerna gör halt här, så Alpha II får en chans att svara ;)
Hmm...jaaa ;)
Jo jag har en bok redan (faktiskt 2) men jag har inte haft tiden, tålamodet eller kanske lusten att läsa ut den :l
Ska försöka läsa ut den så snart jag får tid och inte skolan stressar mig så mycket.
F.ö hade jag redan testat med ** tecken men fick en hel del fel då. Det har med directX att göra som jag inte har en aning om hur det fungerar och jag försökte mixtra om en kod så den fungerar (funkar fortfarande inte) och fick tipset om en del saker som jag skulle ändra... som gjorde att jag fick ändå mer fel vid kompileringen :(
Hur trist det än låter så är det faktiskt så att man inte kan lära sig programmera utan att först/samtidigt lära sig ett programmeringsspråk. Det är ungefär som att aspirera på att laga gourmetmiddag med 7 rätter innan man kan koka potatis.
Sedan är det också så att man inte kan enbart läsa sig till varken hur man programmerar eller hur ett språk fungerar. Man måste öva också. Sämsta tänkbara strategi är att läsa in ett språk slarvigt, programmer upp ett komplett program och sedan felsöka i detta komplexa elände. Det är dömt att misslyckas. Även när man är duktig på språket, vet hur det ska fungera och har använt det en del är det jättesvårt att hitta felen om man programmerar upp rubb och stubb på en gång. Vad man bör göra är att dela upp sitt program i småbitar.
I ditt fall: Lyft ut CAsteroid och CSpaceShip i egna filer. Se om du kan kompilera bara dem. När det funkar, försök kompilera själva spelet med de funktioner andra funktioner använder sig av först, resten avkommenterat. Du måste inte ha ett main/WinMain för att kunna kompilera såvida inte din utvecklingsmiljö kräver det förståss. I så fall kan du krita dit en tom funktion som bara returnerar 0; så har du löst det problemet. Ta sen stegvis med mer och mer av koden när du kompilerar. Det är din bästa möjlighet att ringa in var felen är.
Jag håller med asaah.
Ta det lugnt och dela upp problemet i mindre delproblem, det finns inget värre än att sitta med en massa filer och leta efter runtime fel om man inte har hela strukturen klart för sig.. speciellt när man jobbar med pekare och får köra backtrace på adresser - då är det drygt.
PeW skrev:
... det finns inget värre än att sitta med en massa filer och leta efter runtime fel om man inte har hela strukturen klart för sig...
Det skulle i så fall vara att sitta med kompileringsfel för ett komplext program innan man lärt sig tyda dessa felmeddelanden... Då kan man ju inte ens använda debugger och spårutskrifter.
aasah skrev:
dessutom hur man programmerar enligt procedurorientering, objektbaserat - vad de nu menar med det
Jag har sett exempel på program som bygger på vanlig standard-C, där man har använt structer med funktionspekare, vilka har fått peka på funktioner som är intressanta för just dessa structer. Dessutom har man gömt variablerna genom att deklarera dem som "static", så att de är synliga endast i den källkodsfil där de är deklarerade. Har man då varje struct i varsin egen källkodsfil, emulerar man på det viset privata variabler. Det blir någon slags primitiv objektorientering av det, trots att standard-C inte stödjer OOP. Det kanske är något sådant de menar. Känns inte som om det finns någon större anledning att lära sig detta. ;)
Känns inte som om det finns någon större anledning att lära sig detta
Jag har inte bara sett detta utan även implementerat detsamma. Bakgrunden är att vi i skolan fick de grundläggande proggkurserna med OO (i Java och sen även C++), sen imperativt med C och asm.
Vidare har samma "stil" använts i de tillämpade kurserna. Tycker att det är en ganska trevlig stil - komponent influerad C-programmering, även om det ger ett antal rader extra i kod för att ge "enheterna" funktionalitet. Lätt att återanvända kod :)
UlfT skrev:
aasah skrev:
... objektbaserat - vad de nu menar med det
... Känns inte som om det finns någon större anledning att lära sig detta. ;)
Instämmer till 100% med UlfT. Skälet att jag inte vet vad de menar är enkelt - har aldrig öppnat det avsnittet.
Om ni nu är vänner av OOP, torde det inte vara så svårt att inse fördelen med liknande strategi i C:
Dölja, inkapsla och återanvändning av kod.
Det är inte alltid det finns lib för C++ som passar projektet, eller så är det kanske rent av mer straight-forward att bygga hela projektet i C, före C++. Det finns olika vägar att gå, men om man nu är satt att köra i C och inte C++ är strategin inte dum - alls ;)