pointer u VC6 ..................

Imam globalnu promenljivu oblika
A *p;
gde je A neka klasa.
Kasnije radim p = new A[n] i posle punim niz. Na ovom mestu se desava neverovatna stvar : new vrati sasvim ok adresu, ali p ne primi tu vrednost! Dakle ostaje isti, onako kako ga je kompajler inicijalizovao. I ovo je takodje cudno : pre bilo kakve dodele, ima vrednost koja nije neka od standardnih, 0x00000000 ili 0xcccccccc.
Sta se desava?

p.s. ovo sa naslovom teme >=15 karaktera je bull. morao sam opet da pisem poruku i da dodam ove tackice.

Probaj da napravis mali repro case (sto manji deo koda koji demonstrira taj bag), i zakaci ovde sors da vidimo o cemu se radi.

Desilo se i meni to par puta... Ne kazhem da je isti problem (daj da vidimo kod), ali je jedno 'Rebuild All' uvek reshavalo problem. Izgleda da kompajler ponekad sam sebe zbuni u optimizaciji (pogotovo shto je kod tebe globalna promenljiva!)
I josh neshto - ako je taj projekat iole veci, jesi li siguran da se u Debug modu svaki projekat kompajlira takodje u Debug-u? Zvuchi smeshno, ali deshavalo se da poneki zaboravim u Release-u :) I onda debugger poludi i pokazuje gluposti...

Ovo kod mene na VC 7.1 radi sasvim normalno:

Potpis

IOCC

OT: ovo ograničenje za naslove tema od minimum 16 karaktera još nije finalno rešenje ali mislim da već daje rezultate, a moderatori bi trebalo ili da brišu teme koje ovako sadrže tačkice da bi se veštački popunio naslov, ili da ga sami izmene u nešto odgovarajuće. Sve se to radi zato što su naslovni na esu postajali suviše uopšteni, i tu ne mislim samo na one "POMOC", "PROBLEM", i slične, već čak i ovaj tvoj sa pointerom.

To što si izgubio poruku koju si pisao stvarno jeste problem i to će biti rešeno, hvala na sugestiji.

Da, to je to:

Mora da se negde pretripovao usput. Probacu rebuild all.

Sto se tice naslova teme, slazem se da treba uvesti neki red. Ali pazi sad, mogao sam da napisem
"Imam problem sa pokazivacem u VC6" ili
"Pokazivac u VC6 nece da promeni vrednost koju mu je kompajler unapred dodelio, cak ni posle pokusaja dodeljivanja NULL, tj. p=NULL!!!!!!".
Ovo prvo ne govori nista vise od onoga sto sam stavio kao naslov, jer da nemam problema sa pokazivacem, stavio bih naslov
"Nemam problema sa pokazivacem u VC6"
:), mada ne verujem da bi to nekoga ineresovalo. Ovo drugo je naravno predugacko i treba da stoji u samom tekstu poruke, kao sto i stoji. "pointer u vc6" ima 13 karaktera i nedostaje samo 2 da bude ok (ako je najmanji broj 15). Ja bih pre izbacio ono sto si i sam naveo "pomoc", "nemam pojma", "zbunio sam se", previse znakova usklicnika itd...
I naravno, duzina naslova nikako ne garantuje njegovu smislenost.

hm.. slažem se da kvantitet (dužina) naslova ne garantuje kvalitet, ali mislim da u ovom konkretnom primeru nisi u pravu.

ajde realno pogledaj malo ovaj tred iz daleka (recimo sa strane pregleda c/c++ foruma) i pokušaj da samo na osnovu naslova pretpostaviš o čemu se radi u temi.

naravno, ovo je tvoja tema, pa ti znaš o čemu se radi, ali razmisli o nekom drugom ko za mesec dana ima sličan problem, i počne da pretražuje forum.

"pointer u VC6" mu verovatno neće privući pažnju kao npr "pointer u VC6 ne prima vrednost operanda new" zar ne?

a nije ni mnogo dugačko kako ti pretpostavljaš. znači da si samo minut duže razmislio o naslovu (onoliko koliko ti je trebalo da pređeš sistem), dobio bi mnogo na kvalitetu istog.

a i ti bi verovatno smislio još bolji naslov od mene jer je tvoj problem a ne moj...

Potpis

blogče :: unescaped beta
^{» go-paste extenzija
　 » reč dana: backup
　 » bočne koalicije}

Nije dovoljno da objasni stvarnu situaciju, a kada bih dodao ono sto treba zaista bi postalo predugacko. Izmedju sazetog i tacnog i pokusaja blizeg objasnjenja ali nepotpunog, izabrao sam ovo prvo. Istina nisam razmislio ni 2 sekunde za naslov, vec sam napisao ono sto mi se prvo javilo, dakle sazeto.
Bez obzira na to, opet ne mislim da ce duzina teme nekog naterati da razmisli. Nije u pitanju da li sam ja ovoj dao dobar naslov, vec vise to da bi on prosao da sam napisao samo "pointer u vc++ 6.0" sto govori isto a duze je. Tada se ova rasprava ne bi ni vodila, ne zato sto bi to bio dobar naslov, vec zato sto bi prosla od prve i verovatno ne bi ni primetio ogranicenje, pa tako ne bi ni reagovao niti uzrokovao reakcije drugih u tom smislu.

https://www.elitesecurity.org/t27368#188294
https://www.elitesecurity.org/t26715#183867
itd

Da dodam i VC7.1 u listu....

Slichan problem je pocheo da mi se deshava i u VSNet2003.
Izgleda da MS kompajler ima problema sa statickim/globalnim varijablama, narochito kad ih ima dosta i kad je projekat zaista veliki.
Ovog puta nije optimizacija u pitanju (debug build) i ako u par dana radim samo "Build" zbunice se kad tad i globalne promenljive ce imati svakojake vrednosti. Full-rebuild ga nekako dovede u normalu do sledece gluposti za par dana...
Najcudnije je shto su, u pochetku, globalne instance inicijalizovane kako treba, ali kasnije iz chista mira dobiju bezvezne vrednosti, a da ih kod nikad nije ni dirao...
Ne znam da li se ovo josh nekome deshava, ali je zabinjavajuce (narochito ako full-rebuild i uz IncrediBuild u mrezhi traje sat vremena)

Koristim VC6 godinama i VC7 skoro godinu dana i nikad mi se nije desilo nista slicno.
Nema sanse da je u pitanju MS bug. Cini mi se da je bug u tvom programu, koji
pomalo bombarduje memoriju. Pogotovu sto globalne instance dobijaju bezvezne vrednosti.

Ja sam jednom imao sledeci problem:



yooyo

Jugo, o bombardovanju jednostavno nema govora!

Problem SE DESHAVAO, dodushe samo kad radim build za Xbox! Koja je razlika u komapjlerima (ako uopshte postoji, mada mislim da su samo libovi drugaciji...) izmedju PC i Xbox verzije ne bih mogao precizno da kazhem.

Moja greshka je shto sam na brzinu neprecizno opisao shta se zapravo dogadja : nije instanca prebrisana i dobila glupave chlanove, vec je adresa instance promenila vrednost! A radi se o samo jednoj < globalnoj > instanci klase, znaci nije bilo (Klasa * pKlasa), nego (Klasa klasa) !

Usred koda je VC nekako odluchio da ta adresa treba da se promeni, i naravno, sam pocheo da gadja memoriju! Apsolutno je nemoguce da ja promenim tu adresu jer nije pointer u pitanju! Ionako je zbog konzole sve uvijeno u staticke alokacije, tako da sa nekontrolisanim pointerima nemam posla!
Josh chudnije je shto se to nije dogadjalo uzastopno : od 10 startova, 1 zavrshi sa samo-bombardovanjem! A josh chudnije je shto je prestalo da se dogadja naprasno...
Ko ce ga znati shta je tu poshlo po zlu!

Mislim da se Reljam mozda seca mog problema gde MS kompajler uporno odbijao da funkcionise sa jednom globalnom tabelom:

https://www.elitesecurity.org/p120612 - meni bar ovo lici na srodan problem u klasi "zona sumraka" :)

Ja sam bar resenje za svoj problem nasao -> pazljivom inspekcijom je utvrdjeno da je u jednom momentu instaliran Processor Pack za VC++ 6.0 koji zahteva Service Pack N (gde se ne secam koji je broj N) a to nije instalirano - jos je izmedju instaliran BoundsChecker i Intel C++ ... reinstalacijom celog okruzenja je problem naprasno nestao!

Naizgled neprimetno, problemi su sporadicno nastajali samo sa jednim velikim projektom (!!!!) i to samo pri radu sa globalnim varijablama - prava zona sumraka - projekat je tada bio pun globalnih / statickih i sl.. varijabli od kojih je kasnije skroz ociscen, cisto za svaki slucaj :)

Potpis

DigiCortex (ex. SpikeFun) - Cortical Neural Network Simulator:
http://www.digicortex.net/node/1 Videos: http://www.digicortex.net/node/17 Gallery: http://www.digicortex.net/node/25
PowerMonkey - Redyce CPU Power Waste and gain performance! - https://github.com/psyq321/PowerMonkey

Ima tu jos nekoliko gluposti kojie programer moze da napravi... Primer:



Zbog toga sto je test.h 2 puta ukljucen u 2 razlicita cpp-a kreirace se
dve "lokalne" instance someclass. Posto je u test1.cpp pozvana metoda
someclass.Init() instanca iz test2.cpp nije inicijalizovana.

Kada pregledas code iz debugera, u zavisnosti od toga odakle pratis
ponasanje someclass instance, dobijaces razlicite rezultate.

Takodje je bitno da se globalne instance ne oslanjaju medjusobno jedna na drugu.
Nikada se nezna koja ce instanca biti prva kreirana. U stvari, zna se... to odredjuje
redosled linkovanja obj fajlova (tako je barem u MSVC kompajlerima), ali je taj
proces tesko kontrolisati.

yooyo

U pravu si za te slucajeve, samo shto to ovoga puta nije sluchaj :

- Statichka instanca je, s'obzirom na scope, ipak no-no. U ovom sluchaju svi header fajlovi koji deklarishu klase koje ce biti globalne izgledaju otprilike

gde se instanca kreira u .cpp fajlu. Staro dobro pravilo :)

- Sluchaj sa inicijalizacijom globalnih instanci (plus ako ima i dosta singletona) je takav kakav je :( i nema mnogo pomoci sem da se smanji medjuzavisnost klasa.
Ali, opet, u ovom sluchaju to nije bio problem.

Btw,

Evo sad se desila glupost ponovo! VS me ozbiljno izludjuje! Program kreshira na mestu gde nema shanse da padne! Kako? Prosledjuje pogreshne parametre funkciji! Funkcija pozvana sa unisgned int = 18000, a u funkciju ushlo kao 322467682-neshto! Skroz je odlepio!

Lici kao da prosledjeni int nije inicijalizovan.
Cudno... meni se nikada nije desilo nista slicno...

Mozda je calling convention problem? Ili si mozda overclockovao procesor pa
ti masina luduje? Da li ti je mozda multithrading aplikacija, pa nisi vodio racuna
o sinhronizaciji poziva?

Okaci neki code pa da pogledamo.

yooyo

Jugo, kod i ne bih bash mogao da okachim :)

Mada, mislim da si mozhda u pravu shto se hardvera tiche, s'obzirom da SIGURNO nije u pitanju programerska omashka. Moguce je da mahina krece da ludi posle 8-10 sati rada, npr. memorija nije najbolja pa brlja kad se zagreje, sve je moguce.
Mada, ne mogu da se otmem utisku da neshto u lancu buildovanja za Xbox i nije bash kako treba i da se da lako zbuniti...

Btw,
evo da budem dosadan. Nocas (j*bi ga, deadline) su poludele josh dve mahine - game krashira na skroz glupom mestu jer je odjednom "0" (nula) postala true, a na drugom se funkcija jednostavno ne poziva :))) (ovo je smeh od muke!)

...virus...?

Rajko

Virus? I doubt it, mrezha i kompovi u firmi su zashticeniji od belog medveda! U zadnjih 6 meseci nijednog jedinog nije bilo ni izdaleka.

However, da ne davim vishe, pripisacu greshku sledecim faktorima : budjava AMD plocha, losha memorija, losh kuler...
Ostavicu na miru kompajler, barem dok se neko ne javi sa slichnim problemima :)

Pa ja sam se javio sa sličnim problemom :)
"Rešio" sam tako što sam umesto pointera stavio niz, pa kom opanci...
Ali kompajler definitivno šizne sa globalnim pointerima i posle 10¹⁰-og build-a.

... samo što je kod tebe šestica u pitanju, a ta mi je verzija baš u najboljim uspomenama ;)

Neko gore reče da je brzo program očistio od svih statičkih i globalnih varijabli. Naravno, da me neko pogrešno ne razume, to jeste pravi "knjiški" pristup, ali kad nešto sa PC-a što zahteva 256MB samo da se pokrene treba da prebaciš na konzolu koja ima (u ovom slučaju) bednih 64MB (sa sve grafikom i zvukom), mnoga pravila lepog ponašanja više ne važe : što manje brljaš po memoriji to bolje - u prevodu, "new" ili ekvivalente je bolje izbegavati! Ostaju ti statičke i globalne varijable, stegnuti memory-manageri itd.
Mislim da je Microsoft (ako je to uopšte moguće) u svom kompajleru malo "zaboravio" na ovakve "nazadne" slučajeve. Zato bih i voleo da čujem da li je neko imao slična iskustva/probleme.

Btw,
nije ni Borland C++Builder bez putera na glavi! Mada ne kompajler, nego Borlandmm.dll, njihov memory-manager koji jednostavno puca čim ga žestoko opteretiš (mnooogo malih objekata)! Preklapanjem new/delete sa LocalAlloc-om je stanje sredjeno, ali opet bag koji mi je odneo sat vremena!