[C++] Deque lancia un out_of_range

[sh4rk_89]

ho un programma che deve acquisire dei dati in tempo reale. C'è una classe che si occupa di gestire il concetto di "array circolare", ad un certo punto lancia un eccezione di tipo out_of_range. Il codice è questo:


T operator[](size_t index) const {
return this->get_(index);
}

T get_(size_t index) const {
return (index < this->container_.size()) ? this->container_[index] : T();
}
la definizione di container è la seguente:
std::deque<T> container_;

Le mie domande sono:

COME DIAVOLO è POSSIBILE che lo faccia se la standard del C++ impone all'operatore [] di non lanciare questo tipo di eccezioni? http://www.cplusplus.com/reference/deque/deque/operator%5B%5D/
COME DIAVOLO è POSSIBILE che lo faccia se prima controllo che la posizione alla quale si voglia accedere sia minore della dimensione del deque?

Ho aperto un debugger ad eccezione avvenuta e ho potuto constatare che, ovviamente, stava cercando di accedere ad una posizione che dovrebbe esistere in memoria.

Useo windows 8.1 e vs2013

Grazie a chiunque sappia aiutarmi!

[tomminno]

Non avendo visto nè l'errore preciso nè tutto il codice, sei sicuro che l'eccezione venga sollevata da this->container_[index] ?

[sh4rk_89]

Non avendo visto nè l'errore preciso nè tutto il codice, sei sicuro che l'eccezione venga sollevata da this->container_[index] ?

L'errore è un eccezione di tipo out_of_range e il codice interessato è davvero solo quello!
comunque sono sicurissimo che venga l'eccezione venga sollevata da this->container_[index] ma credo di aver capito perché:
1- innanzitutto l'MSDN, che avrei dovuto consultare prima di cplusplus.com, dice che visual studio permette a deque di lanciare eccezioni in alcune particolari configurazioni di debug. E vabbò, abbastanza ovvio a questo punto, ma fa piacere trovarlo scritto da qualche parte.
2- c'è una race condition: se un altro thread aggiunge dei dati al vettore la dimensione cambia e tutti gli iteratori attulmente in uso su quel particolare contenitore vengono invalidati, purtroppo mi toccherà mettere qualche mutex.

[Z80Fan]

1- innanzitutto l'MSDN, che avrei dovuto consultare prima di cplusplus.com, dice che visual studio permette a deque di lanciare eccezioni in alcune particolari configurazioni di debug. E vabbò, abbastanza ovvio a questo punto, ma fa piacere trovarlo scritto da qualche parte.

Purtroppo VS è abbastanza strafottente degli standard; più e più volte ho dovuto sistemare codice validissimo (testato su Clang; sto sviluppando del software che compiliamo sia in Windows/VS che in Linux/Clang) che in VS non compilava e/o andava contro quanto lo standard stesso diceva.

[sh4rk_89]

Purtroppo VS è abbastanza strafottente degli standard; più e più volte ho dovuto sistemare codice validissimo (testato su Clang; sto sviluppando del software che compiliamo sia in Windows/VS che in Linux/Clang) che in VS non compilava e/o andava contro quanto lo standard stesso diceva.

Questo caso specifico forse è un po' diverso visto che stiamo parlando di una configurazione di debug e di un comportamento che probabilmente è configurabile (e che quindi può aiutarti a trovare dei bug, come nel mio caso) ma in linea di principio sono totalmente d'accordo.

[tomminno]

Purtroppo VS è abbastanza strafottente degli standard; più e più volte ho dovuto sistemare codice validissimo (testato su Clang; sto sviluppando del software che compiliamo sia in Windows/VS che in Linux/Clang) che in VS non compilava e/o andava contro quanto lo standard stesso diceva.

In realtà questo caso è un check, aggiunto dal compilatore, anti sforamento degli array, ovviamente configurabile.
Se pensi che i più recenti bug di livello mondiale sono dovuti a questo tipo di errore tale controllo del compilatore non mi pare poi una cosa così pessima...

[Z80Fan]

In realtà questo caso è un check, aggiunto dal compilatore, anti sforamento degli array, ovviamente configurabile.

Questo caso ok; io intendevo altri problemi che ho incontrato nell'uso.
Di solito sono problemi a compile time sia di linguaggio che di libreria (C++11 sopratutto, che anche in VS2013 non è completo).