Re: [Monotone-devel] Problems building monotone-0.5

[graydon hoare]

Jochen Schaeuble <address@hidden> writes:

> Hi,
> ok I finally got this one working (gcc 2.95 requires an explicit -I for
> the sqlite directory). The next error (errno unknown) was simple to fix
> (#include <errno.h>). But now I get the following error in command.cc.
> Any hints how I can solve this problem? It seems to me that gcc 2.95 and
> gcc 3.x handle some things totally different.

...

> commands.cc:2145: no matching function for call to
> `vector<basic_string<char,string_char_traits<char>,__default_alloc_template<true,0>
> >,allocator<basic_string<char,string_char_traits<char>,__default_alloc_template<true,0>
> >> > >::at (int) const'

oh geez. it looks like you're using a version of the STL which doesn't
have the vector<foo>::at(int) member function. this is the same as
operator[] except that it throws an out_of_range exception if you go
past the array end. I don't think you can solve this directly without
changing STL or changing every instance of .at(i) in our code to [i].

this is sort of an open issue for me. I wish STL let you define error
reporting policy as a template parameter.. the current (inconvenient)
situation results in my lazily having included vector code in monotone
which:

 - explicitly checks boundaries with invariant points, such as 
   I(x < foo.size())
 - uses the .at(x) function
 - uses blind operator[]

the problem with failures on a blind operator[] -- aside from possibly
generating an unsightly SEGV -- is that it doesn't *always* generate a
SEGV. sometimes you can go one or two entries off the end of an array
and nothing traps it. for algorithms where there's some numerical
significance to the random access of the array (xdelta, LCS) this is
no good.

.at(x) improves on this slightly by always generating an exception if
you overflow.  but it shares a problem with the SEGV, which is that it
doesn't report the precise line at which it occurred. the exception is
thrown and the runtime shuts down nicely, but you don't know exactly
which overflow condition happened. you have to go into a
debugger. this is kinda boring, especially since often knowing the
line number and index value vs. size are enough to diagnose the error.

in fact, even the invariant checking isn't quite satisfactory, for two
reasons: it's an extra line of code everywhere which you have to
remember to enter, and when it goes wrong I still don't find out
*which* bad index value was given. what I am considering doing is
adding a definition in sanity.hh along these lines:


template <typename T>
inline T & checked_index(vector<T> & v, 
                         vector<T>::size_type i,
                         char const * vec,
                         char const * index,
                         char const * file,
                         char const * line) { 
  if (i >= v.size())
    throw oops(format("vector out of bounds at %s:%s : "
                      "'%s' size = %d, index '%s' = %d")
               % file % line % vec % v.size() % index % i);
  return v[i];
}

#ifdef DEBUG       
#define idx(v, i) checked_index((v), (i), #v, #i, __FILE__, __LINE__)
#else 
#ifdef HAVE_STL_AT
#define idx(v, i) v.at(i)
#else 
#define idx(v, i) v[i]
#endif
#endif

and then rewriting all explicit vector accesses from v[i] or v.at[i]
to idx(v,i); it's a touch ugly, but it'll give me the feedback I'd
prefer to have, earlier rather than later. comments? is this
completely wrong? is there a cleaner way?

-graydon


(and yes, I'm pretty much convinced I ought to rewrite all the logging
 and printf-y stuff in terms of boost formatters, unless it proves
 unimaginably expensive at runtime. I don't like the char *
 wrangling. I don't actually like having the character '*' show up
 anywhere in my source code if I can avoid it.)