[boost] Re: Invariants Library

From: Dan W. (danw_at_[hidden])
Date: 2004-01-03 11:14:04

Thorsten Ottosen wrote:
> "Dan W." <danw_at_[hidden]> wrote in message
>>If it did it wouldn't matter. The fact is, the contracts must be in the
>>open, or else they aren't contracts. In C++, "In the open" == .hpp
> Dan, that is really your definition. "In the open" to me simply means
> accessible in some form.

No, it's the language definition and tradition. The cpp file is not 
intended to be publically available. Would you want a C++ DBC library to 
compile *only* for Open Source projects?  If your answer is "no", then 
you want the public contracts of a class to be in the header file, where 
they belong.

>>I'm not opposed to producing documentation from source. All I'm saying
>>is that preconditions and postconditions of public functions belong in
>>the header file.
> Maybe. It could be that there are other reasons for demanding a header-only
> policy. Does digital mars does not have that restriction?

To be frank with you, I don't know how Digital Mars handles DBC and for 
the purposes of this discussion I don't care.

>>>If you extract the docs by a tool as the last thing you do, you have the
>>>same guarantee.
>>Sure, I agree. But what's your point?
> that there is on difference between an extended header file and a generated
> docs.
> 
> [snip]
> 

And your point?

>>No. The point is that the header file is what a class advertises about
>>itself, and the cpp file is what a class does not advertise.
> A header file is rarely enough documentation for libraries. It is usually
> enough
> for "good-enough" software.

That's due to the lack of DBC ... ;-)

>>Its
>>products, services and price-list are things it advertises, therefore
>>they go in the header file.
>>The fact that contracts go a long way to document a class, and that
>>their concurrency is guaranteed,
> While this guarantee is certainly good, the most important aspect is that
> the assertions are in the code and not in comments.

Allright!  We agree about something.  But what you don't seem to get is 
that's only a benefit to someone who has *access* to that code.
DBC assertions in my .cpp file are not accessible to you, so what good 
are they to you?  How do you know whether the functions in the class I 
just sold you for $49.99 are any good to you, if I only sold you a 
binary and a header file that contains ne requires or ensures?
And if, technically, I might have just given you a document extracted 
from my cpp file that contains them, is your compiler able to read this 
document to verify contract correctness? Is your debugger able to read 
this extracted document to execute those assertions?
If I were you I would just file a complaint, and insist that I put the 
assertions in the header file, where they properly belong, and get it 
over with.