Verificați dacă indicatorul pentru clasa personalizată nu mai există

Am un obiect construit cu un alt obiect trecut prin referință. Obiectele care sunt transmise constructorului arata astfel:

 HTTPServerResponse::HTTPServerResponse(Poco::Net::HTTPServerResponse &response)

Clasa mea de împachetare ( HTTPServerResponse ) distruge response la un moment dat, dar nu se distruge. De fapt, există mai multe motive (externe) pentru care răspunsul ar putea fi distrus, chiar și în afara clasei mele.

Ceea ce vreau este înainte de a apela alte metode din response pentru a verifica existența acestuia.

Am incercat:

if(!response) {...

Care a produs eroarea C2675: unary '!' : 'Poco :: Net :: HTTPServerResponse' nu definește acest operator sau o conversie la un tip acceptabil operatorului predefinit ; Firește, am încercat, de asemenea:

if(response) {...

Which also failed with error C2451: conditional expression of type 'Poco::Net::HTTPServerResponse' is illegal; No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called

Cum rezolv această problemă?

0
Nu puteți ști dacă un obiect a fost șters/eliberat. Luați în considerare un design mai bun.
adăugat autor Dani, sursa
@Pubby puteți să oferiți un exemplu ca răspuns?
adăugat autor Silviu-Marian, sursa
@ Nici măcar nu verificați referința la memorie sau ceva? Un hasMethod , orice? Ne pare rău, ultimul noob aici.
adăugat autor Silviu-Marian, sursa
Nu puteți apela metode pe un obiect șters (și veți obține un comportament nedefinit dacă încercați), dar dacă este propriul cod care face ștergerea, puteți să setați un semn (sau să setați indicatorul corespunzător la NULL) pentru a indica pentru tine că l-ai șters. Codul dvs. poate verifica starea acelui pavilion/indicator înainte de a încerca să acceseze obiectul. Dacă obiectul poate fi șters fără știrea dvs., aceasta este o problemă reală și va trebui să reproiectați lucrurile pentru ao evita. Administrarea automată a duratei de viață a obiectului cu ajutorul unui partajat_ptr în loc să îl
adăugat autor Jeremy Friesner, sursa
Acest lucru pare a fi un caz de utilizare pentru shared_ptr și weak_ptr .
adăugat autor reima, sursa
Este foarte posibil ca pointerul/referința pe care o aveți să se poată referi la ceva care a fost șters sau la unul nou creat în locul său sau chiar la câini de lângă ușă. Nu aveți nici o modalitate de a ști că un indicator arbitrar este valabil doar cu pointerul.
adăugat autor Deanna, sursa
Utilizați un indicator în schimb?
adăugat autor Pubby, sursa
Cu un pointer el nu va primi NULL dacă obiectul a fost șters. Sunt de acord cu @Dani
adăugat autor Adriano Repetti, sursa

3 răspunsuri

Chiar trebuie să știți dacă obiectul există? Citiți despre modelul Sink Design. Este frecvent folosit în Boost Asio. Dacă utilizați pointeri trebuie să vă amintiți că nu sunt indicatori după ștergere etc ... Încercați cu smart_ptr's.

Pentru mine este greu de imaginat de ce aveți nevoie să verificați dacă indicatorul există încă. Există o problemă de proiectare în codul dvs.

0
adăugat
Fac tot ce pot pentru a rezolva un cadru întrerupt ...
adăugat autor Silviu-Marian, sursa

Am ajuns să țin ocupat întregul fir, împiedicând ștergerea obiectului până când am terminat cu el. E șchiop, știu, dar mi-a salvat toate necazurile de a fi nevoit să-mi dau drumul prin întregul cod.

0
adăugat

You can never know if the reference or pointer you are pointing at is invalid (see Why don't I need to check if references are invalid/null?).

Trebuie doar să fii atent (și clar) despre cine deține referința/indicatorul și cine ar trebui să îl șterge. Pentru a vă ajuta cu proprietatea, puteți folosi std :: unique_ptr sau std :: shared_ptr (în C ++ 0x, utilizați versiuni boost în caz contrar).

0
adăugat
Dacă încerc să îl fac referință într-o instrucțiune try {} catch() {} , puteți explica, de asemenea, de ce cererea mea încă se blochează?
adăugat autor Silviu-Marian, sursa
Nu există o metodă generală/automată pentru a detecta dacă o referință încă indică un obiect valid. Nici timpul de rulare a limbajului, nici tu nu poți face asta. Deci cine ar trebui să arunce excepția pe care încercați să o prindeți?
adăugat autor reima, sursa
Deoarece accesarea unui pointer/referință încurcat este un comportament nedefinit, nimic nu aruncă o excepție. Consultați stackoverflow.com/questions/ 1823721/& hellip;
adăugat autor Julien Lebot, sursa