#1 MSVC stack overflow in std::map::operator[]

[octon lippy]

if I try to build and run the
test harness without my hack, I get a stack overflow on
the first line that the library is accessed:

#if DO_DBG
dbg::out(dbg::tracing) << DBG_HERE << "\n";
#endif

What seems to be happening is the following:

1. dbg::out is called with src == 0 - the implementation of
this function indexes into source_map with an empty string.

2. Indexing into source_map actually invokes
source_map_type::operator[], which delegates to the member
_map's operator[].

3. operator[] for the map implementation with MSVC looks
like:

\_Tref operator\[\]\(const key\_type& \_Kv\)
    \{iterator \_P = insert\(value\_type\(\_Kv, \_Ty\(\)\)\).first;
    return \(\(\*\_P\).second\); \}

Note the second argument to the value_type constuctor -
source_info gets default constructed.

4. The default consructor of source_info indexes
into source_map with dbg::default_source.

5. This is the same as step 2 so we get into an
infinite recursive
call & stack overflow.

I imagine this behaviour is specific to the implementation
details of the std::map - i.e. whether operator[] lookup
necessarily involves default constructing a instance of the
mapped value. I am using MSVC6 sp5 with the bundled library
implementation. A couple of my colleagues who tried it also
saw this behaviour.

The workaround was to reimplement
source_map_type::operator[] as:

    \{ 
      map\_type::iterator it = \_map.find\(key\);
      return \(it == \_map.end\(\)\) ? \_map\[key\] : it->second; 
    \}