Re: [boost] [inspect] exceptions (FW: [Boost-users] no exceptions)

Subject: Re: [boost] [inspect] exceptions (FW: [Boost-users] no exceptions)
From: Vicente BOTET (vicente.botet_at_[hidden])
Date: 2011-03-22 19:27:58

> Message du 22/03/11 23:47
> De : "Robert Kawulak" 
> A : boost_at_[hidden]
> Copie à : 
> Objet : Re: [boost] [inspect] exceptions (FW: [Boost-users] no exceptions)
> 
> > From: Vicente BOTET
> > I guess that the best we can do is to build the lib and the tests with
> > exceptions disabled. No need to update the inspect tool.
> 
> Why bother with building everything in various configurations specifically to solve this problem when there's already a tool created and used regularly to check for such things?

You are right, the compiler will check only some parts of the code.

> > The inspect tool is there to check things that can not be tested in an
> > easy way with the compiler.
> 
> This seems ad-hoc to me. Inspect is there to automatically check for guidelines violations. Whether it is possible to detect the violations manually with a specifically configured compiler is not relevant.

I guess that people will not make any effort to include in the inspection tool things that can be obtained by the compiler, but maybe you will.

> > Take also in account that inspect is not there to check for guidelines, but for
> > rules.
> 
> Apart from the fact that rule and guideline are synonyms in this context, the docs for Boost.Inspect explicitly say about GUIDELINE violations and "common problems". Using throw instead of BOOST_THROW_EXCEPTION or using non-empty exception specifications is a guideline violation. The latter is already mentioned in "Boost Library Requirements and Guidelines"; the former is not, but it ought to be.

Take a look at the thing inspect is managing:

Options:
R -license
R -copyright
R -crlf
? -end
R -link
? -path_name
R -tab
R -ascii
R -apple_macro
R -assert_macro
R -minmax
G -unnamed

Most of them are things that the compiler can nor check and the one the compiler can check are very easy to implement.

Except -unamed that I think is a guideline, the others are rules (I don't know what -end and -path_name checks). BTW, where the checks are documented?

Please, note that I'm not against we add more check to inspect, but note that the value should outweigh the effort. If the test consist simply to check some keywords this seems simple. Is it to check the direct usage of throw, throws, try and catch?

BTW, how many libraries build without exception support now, how many can run their tests? 

Best,
Vicente