dev.gamez.lv

Tankists · Joined: 18 Dec 2006 Posts: 81 Location: Baldone

Lieta, sekojoša. Eksperimentējot ar c++ uzrakstīju nelielu SDL aplikāciju, kur no faila tiek nolasīts tailu tips, un tie izvietoti pa visu ekrānu. Protams radās problēma un cenšos to atrisināt. Logs atveras un aizveras, bet nav ne mazākas nojausmas kur varētu būt kļūda, jo erroru failā(stderr) nekas netiek ierakstīts. Ķeroties pie Code::Blocks debugera cerēju rindiņu pa rindiņai laist kodu, līdz atrodu, kur tieši programma beidz darbību, bet programmu laižot caur Code::Blocks, viņš neatrod direktorijā atrodošos BMP failus un protams stderr tiek ierakstīts, ka failus nevar atvērt. Ko darīt, ka izlabot kodu?

bubu · Posted: Thu Aug 28, 2008 4:03 pm Post subject:

Gan jau ka projekta konfigurācijā tekošā direktorija debugošanai nav uzstādīta tāda, kuru tu gaidi. Atver projekta uzstādījumus un tur atrodi, kur var uzstādīt direktoriju kurā atrasties, kad programma laižās zem debugera.

Tankists · Joined: 18 Dec 2006 Posts: 81 Location: Baldone

ko īsti nozīmē, ja programma atgriež nevis 0, bet 3?

snake5 · Indago dalībnieks Joined: 27 Jun 2007 Posts: 2590

bubu · Posted: Thu Aug 28, 2008 5:41 pm Post subject:

Tankists · Joined: 18 Dec 2006 Posts: 81 Location: Baldone

Sorry par offtopic, bet ir viens jautājums. Kā pareizi vispār veido projektus? Mans stils pagaidām ir viens *.cpp fails kurš satur main() funkciju un klases, funkcijas, globalos mainīgos un konstantes lieku atsevišķos *.h failos un tad tos includoju galvenajā *.cpp failā.
Jautāju, jo ir sanācis tā, ka vienā .h failā man ir klase kura izmanto funkciju no funkciju faila un funkciju failā ir funkcija, kas izmanto klasi.. kā rīkoties šādā sitoācijā? Varbūt ir kāds lasāmais, par to kā pareizi projektu plānot, sadalīt pa failiem utt.?

bubu · Posted: Thu Aug 28, 2008 9:38 pm Post subject:

Dali loģiskas vienības atsevišķos failus. Ir, piemēram, tev klase, kas atbild bildes ielādēšanu - liec klases deklarāciju image.h failā un definīciju image.cpp failā. Ir viena sarežģīta funkcija, kas skaitļot kautko - liec funkcijas deklarāciju mega_calculation.h failā un definīciju mega_calculation.cpp failā.

Nevajag mest vienā failā visas funkcijas, citā visas klases. Jāstrukturizē ir pa loģiskām vienībām - datu lasīšana no faila, attēla apstrāda, spēlētāja objekts utt (katru no tiem savā .cpp/.h failā). Tādējādi būs vieglāk pārredzēt projektu un mainīt kodu.

No globāliem mainīgajiem gan vajag izvairīties kā no uguns. Uguns ir silta un labi noder, ja to māk izmantot, bet visādi citādi no tās var apdedzināties ne pa jokam (arī pat, ja māk izmantot).

Reku kautkāds lasāmais: http://www.gamedev.net/reference/articles/article1798.asp

Storm · Joined: 11 Apr 2006 Posts: 742

Kapeec globaalie mainiigie tik sausmiigi peec tevis teiktaa? Man pimeeram loti noder kaada statiska "global" klase kuraa glabaajaas teiksim references un input menedzeri, grafikas devaisu, elapsed time un veel so to...
_________________
Izraadaas ka dazu dev.gamez.lv lietotaaju absurdaa ignorance meedz eksisteet arii augstaakas paakaapees : http://www.gamedev.net/community/forums/topic.asp?topic_id=411552

bubu · Posted: Thu Aug 28, 2008 10:12 pm Post subject:

Nezinu kā tev, bet man strādājot **pie projektiem ar lielu koda apjomu** globalie mainīgie vienmēr ir čakarējuši. Globālie mainīgie = gan parasti globālā neimspeisa mainīgie, gan statiskas klases, gan arī static mainīgie funkcijās, utt..

Tie ir slikti, jo slēpj programmas stāvokli. Tie padara to izmaināmu no jebkuras vietas, jebkādā veidā. Tādējādi nevar būt drošs par to, kāds šis stāvoklis ir, kad kāds kods izpildās kur citur. Slikums rodās gan šajā nezināšanā, gan arī tur, ka programmas kodā rodas liels coupling's (common coupling) - paliek grūtāk atkalizmantot kodu, nodalīt funkcionalitāti un citas refaktoringa problēmas. Nemaz nerunājot par unit testiem, kuriem globalais stāvoklis ir diezgan traucējošs.

Ne velti pure funkcionālās valodās funkcijas rezultātu ietekmē tikai un vienīgi tās argumentu vērtības. Kodu ir gan viegli pārredzēt, gan saprast. Jo nevajag domāt kā un kas var ietekmēt funkcijas rezultātu izņemot argumentu vērtības, kuras taisies padot. Bet nu lai šo "ļaunumu" saprastu pa īstam, tur ir jāizaug (programminženierijas jomā). Es ļoti labi saprotu, ka to ir grūti saprast. Pats ilgu laiku nesapratu, kas globālajiem mainīgajiem ir vainas. Līdz pašam dzīvē uz savas ādas (lasīt kodā) nācās izjust globālo mainīgo ļaunumu, vairākkārt ;)

Mazās koda programmas, protams, tas nav tik būtiski. Vai arī strādājot pie projekta vienam pašam. Bet strādājot komandā ar citiem developeriem, kad vairs nevari būt drošs kā un kādu kodu cits uzrakstīts, šī problēma ir it sevišķi aktuāla. Ja kolēģis ir stingri nodefinējis interfeisu - tb padod argumentā/konstruktorā x un y, dabūju ārā no funkcijas/metodes z. Ļoti vienkārši. Bet kad jāsāk raizeties par globālo stāvokli, kuru šī funkcija var saturēt vai paļauties... Kā lai es zinu, ka man vajag uzstādīt globālo mainīgo foo::bar = 1, pirms izsaukt funkciju zummdumm(), vai arī kā šī funkcija to ietekmēs, pirms izsaukt nākamo reizi ? (piemērs pārāk abstrakts, neņemt par nopietnu)

Un vēl mazs offtopiciņš - multithreadētā programmā globāls stāvoklis ir ļauns. Reāli tas liedz padarīt kodu multi-thread safe. Jā ir tāds thread-local-storage, bet es to uzskatu par haku un labāk rakstīt korektu kodu ar lokālu stāvokli katram threadam, kuru padot/inicializē kā normālu funkcijas/konstruktora argumentu. Jā, var arī, protams, lokot mutex'us/kritikālās sekcijas - bet tad samazinās jēga no multithreadinga.

Tankists · Joined: 18 Dec 2006 Posts: 81 Location: Baldone

Paldies, šis padoms ļoti noderēs.

Storm · Joined: 11 Apr 2006 Posts: 742

Es jau neizmantoju tos mainiigos lai vinjus mainiitu. Tie ir tikai prieks lasiisanas. Vai tad arii tur kaut kaads ljaunums ir? Kas ir par kaadiem mainiigajiem kas tiek mainiiti - protams, likt kaa globaalu un visi maina ir galiigi garaam. Bet read-only?

P.S sorry par offtopic te, bet varbuut tiesam arii ko noderiigu izspriezam Smile

_________________
Izraadaas ka dazu dev.gamez.lv lietotaaju absurdaa ignorance meedz eksisteet arii augstaakas paakaapees : http://www.gamedev.net/community/forums/topic.asp?topic_id=411552

bubu · Posted: Fri Aug 29, 2008 10:24 am Post subject:

Kādreiz tie mainīgie ta arī mainās (ja nemainās, tad tās ir konstantes, un konstantēm gan nav ne vainas). Viss mans augstāk rakstītais bij par to, ka jo lielāks kods paliek, jo grūtāk ir atcerēties, kas un kam ir tiesības kurus mainīgos mainīt.

Nē nu saproti, ja tev ir kods, kas strādā ar 2 vai 3 globāliem mainīgiem. Tad protams, ka tas strādā. Tas nav slikti. Slikti sāks palikt tad, ja šo mainīgo kļūs vairāk un vairāk. Un, pēc manas pieredzes, ja ir kaut viens globāls mainīgais, tad šķiet, ka ielikt vēl vienu jau nu nav nekas slikts. Un pēc tam vēlvienu, un vēlvienu, utt. Tā tie globāļi sākt augt kā sēnes pēc lietus.

Tankists · Joined: 18 Dec 2006 Posts: 81 Location: Baldone

Tad cik sapratu, globālie mainīgie nav slikti, ja ir ar mēru, jo piemēram SDL surfeisu deklarēšana man ir jāliek kā globāla, lai to varētu izmainīt no jebkuras vietas, pareizi sapratu?

snake5 · Indago dalībnieks Joined: 27 Jun 2007 Posts: 2590

Storm · Joined: 11 Apr 2006 Posts: 742

Tur jau tas saals ar to padosanu, ja man piemeeam ir kamera un kamerai ir updeits, taalaak updeitaa vajag padot - inputu un elapsed time prieks kurstinaasanas, tad veel graphics devaisu kaut kaadam teiksim unproject... un taa visu laiku visam visu kaut ko vajag padot... Rezultaataa kods izskataas vienaarsi stulbi.

taa: