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

[Jochen Schaeuble]

Hi,
I would prefer this way. This would enable me to build monotone. I can
help you replacing all [] and .at's.

Greets,
  Jochen

On Wed, Oct 01, 2003 at 03:16:57PM -0400, graydon hoare wrote:
> 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.)
>