Vector andando fuori dai limiti senza dare errori

Ho un std::vector . Controllo la sua dimensione che è 6 ma quando provo ad accedere a vec[6] per verificare se darà errore, non ottengo alcun errore ma un certo numero. Non dovrebbe dare un errore?

modifica: qualcosa come:

 struct Element { std::vector face; }; int main() { Element elm; .... // insert 6 elements into elm.face std::cout << elm.face.size() << std::endl; // answer is 6 std::cout << elm.face[6] << std::endl; // answer is some number } 

I vettori STL eseguono il controllo dei limiti quando viene chiamata la funzione membro .at() , ma non eseguono alcun controllo sull’operatore [] .

Quando non ci sono limiti, l’operatore [] produce risultati non definiti.

Come affermato nella risposta di kgraney, questo è un comportamento indefinito. Tuttavia, la maggior parte delle librerie c ++ ha alcune possibilità di abortire o sollevare un’eccezione in questi casi. Solitamente controllato impostando o distriggersndo specifiche macro del compilatore.

Ho fatto una panoramica della documentazione pertinente:

gnu libstdc ++

  • Modalità debug : informazioni generali sul debug di libstdc ++
  • _GLIBCXX_DEBUG
  • _GLIBCXX_CONCEPT_CHECKS , con -fconcepts – abilita i concetti c ++

clang libcxx

  • _LIBCPP_DEBUG_LEVEL = 1

Incremento

  • BOOST_DISABLE_ASSERTS – disabilita gli asserimenti nella libreria boost.

Microsoft

  • Iteratori controllati
  • _ITERATOR_DEBUG_LEVEL – imposta il livello di debug di iteratore
  • Funzioni di sicurezza nel CRT
  • _CRT_SECURE_NO_WARNINGS: disabilita gli avvisi di deprecazione
  • _SCL_SECURE_NO_WARNINGS – meno sicuro (secondo microsoft), ma più conforms allo standard:

  • _SECURE_SCL – vecchio metodo di impostazione del livello di debug di iteratore

  • _HAS_ITERATOR_DEBUGGING – macro deprecata

Nota che gnu e clang disabilitano i controlli di default, mentre microsoft li ha abilitati di default. Se non si è a conoscenza di ciò, il codice potrebbe essere notevolmente più lento in modalità di debug su un sistema Microsoft.

È un comportamento indefinito. Un comportamento indefinito non significa necessariamente che riceverai un errore: potresti , ma potresti avere qualche risultato che non ha molto senso.

Le strutture dati sono indicizzate a partire da 0, quindi se stai accedendo a vec [6], questo sarà fuori dai limiti. Probabilmente non ricevi un errore a causa di un problema di memoria; potrebbe esserci qualcosa dal codice precedente che hai eseguito, o qualche errore simile. Si prega di inviare il codice.