risorse | checked iterators

Checked Iterators

perché STL è lenta in debug?

Introduzione

Lavorando in modalità DEBUG in ambiente Microsoft, può accadere di sperimentare un rallentamento del codice che fa uso della libreria standard. Parte della responsabilità è attribuibile ai checked iterators, un'implementazione in grado di individuare gran parte degli usi inappropriati di iteratori STL nel codice utente.

Checked iterators in VC8/VC9

La libreria standard fornita con i compilatori VC8/VC9 contiene due implementazioni indipendenti volte al controllo del corretto uso degli iteratori; la prima, associata alla macro _SECURE_SCL, è stata sviluppata da Microsoft, mentre la seconda, associata alla macro _HAS_ITERATOR_DEBUGGING, è stata realizzata da Dinkumware, l'azienda incaricata dello sviluppo e del mantenimento della libreria STL di Microsoft.

_SECURE_SCL

Per attivare il controllo secure standard c++ library è necessario porre a 1 la macro _SECURE_SCL; l'uso scorretto di un iteratore STL genera un runtime error che causa la terminazione immediata del programma. Un esaustivo elenco dei controlli effettuati è riportato in[2].

_HAS_ITERATOR_DEBUGGING

L'iterator debugging feature di Dinkumware verifica la validità degli iteratori in uso. Per attivare il controllo, che è disponibile solamente in modalità DEBUG, è necessario porre a 1 la macro _HAS_ITERATOR_DEBUGGING. La dereferenziazione di un iteratore invalido genera il fallimento di un'asserzione, che causa a sua volta la visualizzazione della maschera di scelta Retry/Ignore/Abort.

L'attivazione di questa caratteristica modifica la rappresentazione in memoria dei contenitori e degli iteratori della libreria standard; per tale ragione non si possono linkare assieme moduli compilati con differenti valori di _HAS_ITERATOR_DEBUGGING. Il linker di VC10 riconosce la situazione ed emette un errore, mentre quelli di VC8 e VC9 non effettuano alcuna verifica: la responsabilità di linkare oggetti tra loro compatibili è lasciata al programmatore.

Valori di default

VC8/9ReleaseDebug
_SECURE_SCL11
_HAS_ITERATOR_DEBUGGINGN/A1

Checked iterators in VC10

VC10 unifica i due controlli _SECURE_SCL e _HAS_ITERATOR_DEBUGGING sotto il cappello _ITERATOR_DEBUG_LEVEL, che può assumere uno tra i seguenti valori:

Tipicamente, _ITERATOR_DEBUG_LEVEL è impostato a 0 o 1 in RELEASE, a 2 in DEBUG.

Per ragioni di retro-compatibilià, le macro _SECURE_SCL e _HAS_ITERATOR_DEBUGGING sono ancora disponibili in VC10, con una piccola differenza nei valori di default:

VC10ReleaseDebug
_ITERATOR_DEBUG_LEVEL02
 
_SECURE_SCL01
_HAS_ITERATOR_DEBUGGINGN/A1

Lentezza nel debugger

Se la lentezza si registra esclusivamente quando all'applicativo è collegato un debugger, la causa potrebbe essere l'uso del debug heap[5]:

Running under a Microsoft debugger (windbg, kd, cdb, Visual Studio Debugger) by default forces Windows to use the debug heap instead of the default heap.

L'uso del debug heap è disattivabile impostando la variabile d'ambiente _NO_DEBUG_HEAP=1.

Riferimenti

  1. "_HAS_ITERATOR_DEBUGGING". MSDN. <http://msdn.microsoft.com/en-us/library/aa985939>. Visitato il 21 Maggio 2012.
  2. "_SECURE_SCL". MSDN. <http://msdn.microsoft.com/en-us/library/aa985896>. Visitato il 21 Maggio 2012.
  3. "Checked Iterators". MSDN. <http://msdn.microsoft.com/en-us/library/aa985965>. Visitato il 21 Maggio 2012.
  4. "Debug Iterator Support". MSDN. <http://msdn.microsoft.com/en-us/library/aa985982>. Visitato il 21 Maggio 2012.
  5. "Why the low fragmentation heap (LFH) mechanism may be disabled on some computers that are running Windows Server 2003, Windows XP, or Windows 2000". Microsoft Knowledge Base. <http://support.microsoft.com/kb/929136>. Visitato il 21 Maggio 2012.
  6. Lavavej, S. T. "Advanced STL, 3 of n". Channel 9 Lectures. <http://channel9.msdn.com/Shows/Going+Deep/C9-Lectures-Stephan-T-Lavavej-Advanced-STL-3-of-n>. Visitato il 21 Maggio 2012.

Pagina modificata il 21/05/2012