🚀 go-pugleaf

Andrew Koenig (ark@research.att.com) wrote:
> In article <AC9FF58C96689D38@sleipner.nts.mh.se> lars.farm@nts.mh.se (Lars Farm) writes:

> > >I'd rather agree with Andy Koenig: "run-time checking is a good thing
> > >if you can afford it."  This would suggest that the only time you turn
> > >checking off is when profiling shows that you have a performance
> > >problem due to run-time checking."

> > Interesting. I got the impression he felt they were a good thing, but would
> > impair performance too much to be required in the general case and I
> > responded accordingly.

> Full run-time checking is exceedingly expensive in C and C++, mostly
> because of C's unconstrained pointers.

Which is a potent reason to require some ability to perform checks in
the newly-designed standard library components.   This would work with
existing compilers at low cost. 

Full run-time checking is very expensive to implement in C and C++, but
one could say "if you use the STL in the right way then you'll get range
checking and pointer checking while using them".

It would further persuade people to move to this same library, 
which is desirable.

So again, I think the specific nature of C++ (few pointer constraints and
thus high cost for full checking) compared to other languages makes it
even more disappointing that it was not addressed by the library
committee. 

One could legitimately say that in, for exmaple Ada and Eiffel, one ought to
leave checking as a compiler-implementation issue, knowing that the language
design makes full checking much easier and that every implementation will
do so to some degree.  Which empirically is indeed the case. 

> -- 
> 				--Andrew Koenig
> 				  ark@research.att.com

cheers
matt
kennel@msr.epm.ornl.gov