dev.gamez.lv

[programmer]

Problēma tāda, ka palaižot programmu iekš Visual Studio 2003 Debug vai Release modē, tā darbojas pilnīgi perfekti, taču, kad palaižu debug vai release exi bez debuggera, tad debug exe darbojas "uz pusi" kā vajadzētu, taču release exe galīgi nedod tos rezultātus, kādus vajag.
Ar Visual Studio 2005 Express notiek tieši tas pats.
Googlē uzmeklēju vienu postu microsoft forumā ar tādu pašu problēmu, taču tur netika atbildēts.

[bubu]

Ko nozīmē "darbojas uz pusi kā vajadzētu"?
Un kā izpaužas "galīga rezultātu nedošana kādus vajag"?
Īsti nesaprotu - tad ar debugeri vai bez debugera nestrādā? Jo studijas IDĒ programmu var laist gan zem debugera (F5) vai arī bez debugera (Ctrl+F5) gan debug, gan release modēs.

Lūdzu cilvēki saprotiet taču, ka nav neviens te gaišreģis. Nevaram uzminēt jūsu problēmas.

[programmer]

Es domāju, ka diezgan skaidri pateicu, ka ar attach'otu debuggeri strādā, bet bez debuggera (ctrl+F5) nestrādā.
Es neminēju, kas tieši nedarbojas, jo domāju, ka tas neko neizteiks - iespējams, ka kļūdos. Es neceru, ka kāds no jums ir gaišreģis, bet es cerēju, ka kāds no jums kādreiz būs saskāries ar šo problēmu. Šī nav tāda "parasta" problēma, kad es varu pateikt, ko gribu panākt, bet nezinu kā. Pamatā programma strādā perfekti, kā es to biju iecerējis.
Taisu savam spēles dzinim GUI. Salieku testam dažus logus, pogas, čekboxus utt., lai paskatītos vai viss iet kā nākas. Ar debuugeri viss ir štokos (parādās "root" logs, uz tā vēl divi logi un visi elementi, kam jābūt uz šiem logiem).

Tagad ir trīs varianti kā viss darbojas BEZ debuggera:

* Palaižot Debug exi ar dubultklikšķi uz exes, parādās tikai "root" logs ar visiem uz tā esošajiem elementiem, izņemot pārējos divus logus, kas ir šī loga "bērni".

* Palaižot Debug exi ar Ctrl+F5 (iekš VS), parādās tikai "root" logs ar uz tā esošajiem elementiem un vēlviens logs, bet uz šī loga ir tikai viens no 7 elemetiem, kam būtu jāatrodas uz šī loga. Otrs logs neparādās.

* Ar Release exi abos variantos (dubultklikšķis uz exes; Ctrl+F5 iekš VS) neparādās pilnīgi nekas no GUI.

Nav ne jausmas, kas ir pie vainas. Varbūt kautkas saistīts ar atmiņu? Debugeris noteikti tās lietas ar atmiņu kārto savādāk, lai varētu visu izsekot. Nevaru spriest par to, ko nezinu.

[bubu]

Kā notiek to dažu logu/pogu/čekbokšu salikšana testam? Kas tā par GUI sistēmu un uz kā bāzēta? Vai gadījumā nelādē failu ar relatīvu ceļu? Tad ņem vērā, ka tekošā direktorija taisot dubultklikšķi uz exe's ir exe's direktorija, bet laižot no studijas - projekta faila (.vcproj) direktorija. Šo kļūdu vari pārbaudīt pārbaudot atgrieztās vērtības no failu atvēršanas funkcijām, tb vai tās ir valīdas. Tekošo direktoriju laižot no IDE's var nomainīt projekta propertijos zem Debugging sadaļas.

Jā, par valīdumu runājot - vai pārbaudi visu funkciju darbības rezultātu? Vai tās nostrādā un neatgriež kļūdainu rezultātu (tipa FALSE vai tml)? Izstrādes stadijā ļoti ieteicams to darīt, jo tas palīdz atrast lielumlielo vairumu kļūdu. Vēlāk, ja to vajag ātrdarbības dēļ, var pārbaudes atslēgt, kad esi pārliecinājies, ka tas strādā kā gribēji.

Neko citu kā kārtīgi izdebugot savu kodu ieteikt nemācēšu.

Ar debug modes atmiņu tam visam ir tikai sakars tādā gadījumā, ja pats nepareizi kautkā atmiņu aiztiec un raksti vērtības tur, kur nevajag. Bet tādā gadījumā diez vai kautkam vispār vajadzētu strādāt, visdrīzāk tad viss vienkārši krašotu, nevis "gandrīz" strādātu.

[programmer]

Logu/pogu/čekbokšu salikšana testam notiek veidojot jaunas šo klašu instances. GUI sistēma bāzēta uz scene-graph struktūras. Katram elementam sava klase, kas manto vienu bāzes klasi. Nekas jauns - domāju, ka gandrīz visas GUI sistēmas darbojas līdzīgi.

Ar problēmu par relatīvo faila ceļu biju saskāries jau agrāk un vairāk tādas kļūdas cenšos nepieļaut, taču šis nav tas gadījums. Nekādus failus gui sistēma pašlaik vēl neielādē, izņemot fontus, kas ielādējas pareizi (esmu pārliecināts).

Cenšos pārbaudīt visus funkciju darbības rezultātus, taču tos es pats nedabūju zināt Laikam vajadzēja pierakstīt vienu rindiņu katrā vietā, lai izvada konsolē rezultātu. Tas būs jāizdara.

Atmiņu es pats uz dullo neaiztieku, tātad šī problēma atkrīt.

Taču es vēl aizvien nesaprotu, kāpēc, debugerī un ārpus tā, programma darbojas savādāk? Un vēl tas, ka Ctrl+F5 un palaišana no exes dod citādus rezultātus.

EDIT: Tikko atklāju ceturto variantu. Kad palaižu Debug exi caur command-promt, tad notiek tas pats, kas ar Release exi - neparādās nekas no gui.
Kāda starpība palaižot exi ar dubultklikšķi vai caur command-promt?

[programmer]

Atnāca rīts, melnie mākoņi izklīda un manam skatam pavērās divi ne-inicializēti mainīgie, to starpā arī m_Visible, kas nosaka vai elements būs redzams.
Tagad arī skaidrs kāpēc dažādās modēs bija dažādi rezultāti. Dažreiz atmiņā bija palicis TRUE, citreiz - FALSE.

Vai ir kāda iespēja, ka debugeris visus mainīgos inicializē pats, jeb tā ir vienkārši sakritība?

[bubu]

Debug modē kompilēta exe (vienalga kā tu to palaid) visus neinicializetos lokālos mainīgos inicializē ar 0xcccccccc vērtību. Vismaz 2005 studija. Vecākās studijā iespējams vērtība ir nedaudz cita, bet tā ir kautkāda konstante.

Globālie mainīgie laikam satur vērtību kāda vien tā pagadās atmiņā. Uz to nevar paļauties.

[elvman]

[bubu]

em.. nesapratu. Gribi debug modē atslēgt to? Vai nav vienkārši nedod debug modē kompilētu exe citiem?

Šī "fīča" taču ir ļoti noderīga, kad vajag kodu debugot. Jo tad debugerī var ļoti vienkārši redzēt, kādi mainīgie ir neinicializēti. Nez, man ar šo fīču nekad nav bijušas nekādas problēmas. Tieši otrādi, ar tās palīdzību daudzus citus bugus tieši esmu izlabojis :) Debug modes būtība jau ir būt par debug modi - veikt papildus pārbaudes un čekus. Ja jau visas pārbaudes atslēgsi - dabūsi vienkārši neoptimizētu release modi... Cita atšķirība starp release un debug modēm nav - daži settingi tikai (debug mode = release mode - optimizācija + papildus pārbaudes).

Padomā, kas notiks, kad atslēgi šo fīču - ieejot funkcijā pieņemsim, ka stekā atradās pointeris uz sen izdzēstu objektu, bet tā atmiņa vēl nav pārrakstīta. Un tu esi nodefinējis lokālo mainīgo, kuram kompilators piešķir atmiņas vietu tieši tajā pašā steka vietā. Programma visdrīzāk krašos, jo aiztiks sabojātus datus. Bet debugerī tu nevarēsi saprast neko, jo tas uzrādīs sakarīgas vērtības - uz to atbrīvto, bet vēl neizmainīto atmiņas vietu. Tb debugeris uzrādīs, ka lokālais neinicializētais mainīgais ir itkā inicializēts.

To vajag pieņemt to sev kā par likumu - mainīgos vienmēr inicializēt! It īpaši lokālos, jo pirms tam stekā var sazin kas atrasties.

[elvman]

Piekrītu, šī "fīča" ir noderīga, kad tu programmu debug'o, bet ja es programmu palaižu bez debug'ošanas, viņš dara tieši tā pat. Es nevaru atļauties tērēt laiku katrai programma buildot gan Release, gan Debug versiju, tāpēc arī prasu, vai viņu, kad vajag, var atslēgt.
_________________
long time; /* know C */

[bubu]

Un buildot vēlreiz, kad gribi programmu bez šīs fīčas, tu gribi? :) Kur atsķirība uzbuildot release modē projektu?

Sproti, ka tas nav nekās boolean flags. Tā inicializēšana ar 0xccc... ir iekompilēta mašīnkodā - katru reizi kad koda vadība nonāk funkcijas sākumā, tā vietā, lai tikai atbrīvotu vietu stekā - atņemtu no steka pointera reģistra konstanti - tiek izdarīta šī atņemšana un tā visa vieta tiek aizpildīta ar to maģisko konstanti. Tas ir papildus kods. Kura protams release modē, nav jo tas padara visu programmu nedaudz lēnāku.

"Atslēgt" to var tikai pārkompilējot kodu.

[elvman]

Nē, nē, tu nesaproti. Kad palaižu savu Debug programmu no Visual C++ ar Shift+F5 (bez debug'ošanas), viņš inicializē visus mainīgos ar šo vērtību (0xcccccc), bet, kad palaižu programmu no explorera visi mainīgie tiek pagrābti no atmiņas uz dullo (tā kā strādātu normāla programma), tātad tas ir kaukāds fīčers iebūvēts iekš VC++, kas liek visiem mainīgajiem inicializēties ar šo mainīgo. Tas prasa laiku atrast programmu un laist viņu no explorera vai arī buildot Release versiju, tāpēc man būtu ērtāk, ka viņš programmu palaiž kautkādā "normal mode", nevis tā, kā viņš to dara tagad. Domāju, ka to vajadzētu varēt atslēgt.
_________________
long time; /* know C */

[bubu]

Nē, tā nav tiesa.
Reku, uztaisīju mazu main.cpp failu:

[elvman]

Hmm. Pats izstestējos tā un šitā, un tiešām, šī "fīčera" nav. Ar aprakstu biju nedaudz kļūdijies, bija nedaudz savādāk. UNDU kodēju uz VC++ 2005 Express un bija tā, ka klašu lokālie vairabļi (pointeri) debug versijā palaižot no VC++ vienmēr bija 0, tāpēc izdarot šo darbību nekad neradās kļūdas: