RE: [boost] bounds checking in array.hpp

From: scleary_at_[hidden]
Date: 2000-12-18 10:36:24

> From: Jesse Jones [mailto:jesjones_at_[hidden]]
> >> From: Jesse Jones [mailto:jejones_at_[hidden]]
> >
> >> <snip>
> >
> >> It's true that most vendors
> >> do a poor job of catching precondition violations, but 
> there's no reason
> >> for boost to go along with this.
> >
> >If they do a "poor job" of catching precondition violations, what is the
> >alternate solution?  Doing a "poor job" of generating efficient code?  
> 
> Yes, in a debug build you'll normally be generating poor code: the 
> optimizer will be disabled (in most of the compilation units) so that the 
> debugger is useable and asserts will be sprinkled throughout 
> the code. 

I didn't make my point clearly.  To avoid ODR violations, either the check
is done or it's not (it can't be based on NDEBUG).  If it is done, then it
does a poor job of generating efficient code; if it's not done, then it does
a poor job of catching precondition violations.  You can't have it both ways
and keep ODR happy, too...

> saying that we cannot use assert because someone *may* define NDEBUG 
> inconsistently sounds like a terrible idea to me. At some point you have 
> to make a trade off. If the vendors would do something as simple as 
> adding asserts to std::string and std::vector to catch range errors I 
> have no doubt that this would quickly save many man years of debugging 
> time. Of course this may cause problems for a few because of the ODR, but 
> I think the balance very much tilts in favor of using asserts.

It happens.  One common problem I've had to deal with more and more recently
is the variety of library builds; on my platform (Borland/Win32), there are
*many* standard libraries:
  dll vs. static
  VCL vs. no-VCL
  single-threaded vs. multi-thread
  exceptions-enabled vs. exceptions-disabled
  debugging vs. release
and if you link to one of these in a DLL and link to another in an EXE that
uses that DLL, you can get problems.  If you're lucky it'll crash on
startup; if not, you can end up with heap corruption (I've had both).

The best solution is to see if we can get the unnamed namespace thing
working.  That way, we save users from shooting themselves in the foot, too.
And no n-tuple versions of Boost.

        -Steve