Hello Jurko, "Jurko Gospodnetic" <jurko.gospodnetic@docte.hr> schrieb im Newsbeitrag news:<g9neff$v6f$1@ger.gmane.org>...

First some collected background information related to Microsoft's checked & debugging iterator support to get a clearer image of what we

are modeling. And could someone please collect a similar summary for other compilers/libraries?

Now the design summaries in order of preference. Note that the list is a 'work in progress' and the ordering and the 'importance' are

Below you can find a excerpt of the stlports user config file. I do not use the stlport so maybe someone else can give more profound info. based

on my own personal choices and current understanding of all the feedback received so far. Feel free to holler if you do not agree with them and

I'll update as needed.

Currently, I favor design B.

-------- Design B -------- Improved version of the originally suggested 'Design A' allowing for debugging iterators and making the features msvc toolset specific, although the exact implementation described here is based on the msvc compiler documentation:

Feature: <checked-iterators> 'on' --> _SECURE_SCL=1 'off' (default) --> _SECURE_SCL=0

Name mangling: <checked-iterators> adds 'c' to library name if enabled (assuming it's applicable).

Feature: <debugging-iterators> 'on' --> _HAS_ITERATOR_DEBUGGING defined 'off' (default) --> _HAS_ITERATOR_DEBUGGING not defined

<runtime-debugging>off & <debugging-iterators>on are incompatible.

Name mangling: <debugging-iterators> adds 'e' to library name if enabled (assuming it's applicable).

* We really need to mangle library names to make it clear which libraries have checked/debugging iterators enabled and which do not, at for those compiled with MSVC, as these options produce binary incompatible libraries. This can be done by either adding new tag letters for these features...

Yes

* All this will affects only code compiled using MSVC compiler versions 8.0 & above. It may also affect other non-MSVC toolsets as we

get more information on them.

Stlport gives also additional support for checking. Greetings, Johannes P.S.: Excerpt from the STLport user-config.h file responsible for configuration of the library. I did take all entries which might be relevant in the context. /* * Set _STLP_DEBUG to turn the "Debug Mode" on. * That gets you checked iterators/ranges in the manner * of "Safe STL". Very useful for debugging. Thread-safe. * Please do not forget to link proper STLport library flavor * (e.g libstlportstlg.so or libstlportstlg.a) when you set this flag * in STLport iostreams mode, namespace customization guaranty that you * link to the right library. */ #define _STLP_DEBUG 1 /* * You can also choose the debug level: * STLport debug level: Default value * Check only what the STLport implementation consider as invalid. * It also change the iterator invalidation schema. * Standard debug level: Check for all operations the standard consider as "undefined behavior" * even if STlport implement it correctly. It also invalidates iterators * more often. */ #define _STLP_DEBUG_LEVEL _STLP_STLPORT_DBG_LEVEL #define _STLP_DEBUG_LEVEL _STLP_STANDARD_DBG_LEVEL /* When an inconsistency is detected by the 'safe STL' the program will abort. * If you prefer an exception define the following macro. The thrown exception * will be the Standard runtime_error exception. */ #define _STLP_DEBUG_MODE_THROWS /* * Use this option to catch uninitialized members in your classes. * When it is set, construct() and destroy() fill the class storage * with _STLP_SHRED_BYTE (see below). * Note : _STLP_DEBUG and _STLP_DEBUG_ALLOC don't set this option automatically. */ #define _STLP_DEBUG_UNINITIALIZED 1 #define _STLP_DEBUG_ALLOC 1 /* * Uncomment and provide a definition for the byte with which raw memory * will be filled if _STLP_DEBUG_ALLOC or _STLP_DEBUG_UNINITIALIZED is defined. * Choose a value which is likely to cause a noticeable problem if dereferenced * or otherwise abused. A good value may already be defined for your platform. */ #define _STLP_SHRED_BYTE 0xA3 ____________ Virus checked by G DATA AntiVirusKit Version: AVK 19.305 from 04.09.2008 Virus news: www.antiviruslab.com