Recent changes to tickets

Fix all copyright and licensing info

Lorenzo Caminiti — Fri, 01 Mar 2013 19:08:56 -0000

Proper year ...-2013, remove sourceforce website and use boost website instead, etc

Do not provide separate public header files unless their inclusion is exlusive

Lorenzo Caminiti — Fri, 01 Mar 2013 19:08:02 -0000

check behavior when linking lib with contract disabled

Lorenzo Caminiti — Mon, 21 Jan 2013 18:56:23 -0000

I wanted to ask you about the behavior of Contract++ in the following scenario. I was trying to determine what happens if I link a program compiled with all contract checks disabled against the library compiled with all checks enabled. The code I tried is something like below:

file include.h:
CONTRACT_FUNCTION(

int (diff) ( (int) i, (int) j )
precondition(lessEqual(i, j))

);

file main.cpp:

define CONTRACT_CONFIG_NO_PRECONDITIONS 1

include <contract.hpp>

include "include.h"

int main()
{

auto i = diff(7, 5);

}

file second.cpp:

include <contract.hpp>

include "include.h"

int CONTRACT_FREE_BODY(diff) (int i, int j)
{

return j - i;

}

I found that when I call my function diff() inside main(), the precondition is not checked -- expression not even evaluated -- even though it is compiled with precondition checks enabled. This is a very nice behavior, and a significant improvement over using asserts, because I do not have to recompile the library, when I want to disable the checks. I am just surprised that I didn't find it in the documentation.

Is this an intended feature? N1962 Describes a possible implementation of concept checks that adds no run-time overhead when contract disabled, not requiring at the same time the recompilation of the library. Is it also the case for your library? I know the preconditions are not evaluated in such "mixed configuration" but I cannot determine if some overhead connected to the function call is present.

If this is intended behavior, this feature is remarkable and deserves a honored place in the documentation. The docs do mention disabling the checks, but do not explicitly describe the "mixed mode". I thought that the library worked like normal assert's (If you change the setting you have to recompile the library). Or did I miss it in the docs?

use "static if" syntax for assertion requirements

Lorenzo Caminiti — Tue, 02 Oct 2012 21:41:10 -0000

Following N3329 "static if" proposal, replace assertion requirement syntax:

postcondition(
    back() == value, requires boost::has_eqaul<T>::value
)

with a static if:

postcondition(
    static if(boost::has_equal<T>::value) (
        back() == value
    ) // optional else ( ... )
)

document concurrency in contracts

Lorenzo Caminiti — Mon, 10 Sep 2012 19:01:42 -0000

The docs say that in order to make disabling of nested assertions
thread-safe in multi-threaded programs, the library needs to use a global
lock. Sorry if I am talking nonsense now (I have no intuition of using DbC
in multi-threaded apps), but is it not possible to use thread_local storage
for this purpose? Is it possible that executing an assertion in one thread
would cause the execution of another (nested) assertion in another thread?

I'll think about it. Generally speaking, multi-threading needs to be
handled a level higher than contracts... [Meyer97] also explains how
concurrent programming might fail the contracts (and then he
introduces SCOOP as a solution but Eiffel didn't implement SCOOP until
later). I can provide more information on "contracts and concurrency"
(maybe in a separated email thread) if needed.

Add a small section somewhere explaining the issues with contracts and concurrency (see [Meyer97]).

clarify why contracts are allowed for private and protected members

Lorenzo Caminiti — Mon, 10 Sep 2012 18:59:24 -0000

The documentation says that you can use protected and private members in
contracts because "C++ provides programmers ways around access level
restrictions (e.g., friend and function pointers)". Next, we read that
"only public member functions shall check class invariants. Private and
protected member functions are allowed to brake class invariants because
private and protected member are part of the class implementation and not
of its specification".

This 2nd statement is correct. The 1st statement means that in C++ you
can never prevent people from programming junk like this which will
break the public interface (the same can be done without static):

include <iostream>

class x
{
public: static void pub ( void ) { std::cout << "pub" << std::endl; }
private: static void priv ( void ) { std::cout << "priv" << std::endl;
}

typedef void (*fptr) ( void );
public: static fptr bad ( void ) { return priv; }
};

int main ( void )
{
x::pub();
void (*priv) ( void ) = x::bad();
priv(); // calls a private function :(
return 0;
};

The call to priv via the function pointer is done outside the class
implementation but it won't check the invariants--but if you program
"bad" then you're on your own! That's all I wanted to say with the 1st
statement (which is actually an observation from The C++ Programming
Language, Stroustrup). I can clarify this in the docs.

I feel I have been misunderstood. Let me clarify. I understand how one can
overcame the member access restrictions in C++ with hacks. I do not think
you need to clarify it in the docs. The way I understand the docs is that
you use these hacks as rationale for allowing private and protected members
in contracts.

No. Private and protected members are allowed in contracts because
they can have pre and post even if they never check inv. Public
members are allowed in contract because they have pre, post, and also
check inv.

On a separate note, you cal always call a private or protected member
from a public scope using the access hacks. If you do so beware that
inv will not be checked (as they shouldn't because you are calling a
private or protected member) even if the call is made from a public
scope--you're on your own.

That's what I tried to say in the docs. I'll clarify the docs.

note that variadic macros are not part of C++03 up-front

Lorenzo Caminiti — Mon, 10 Sep 2012 18:57:43 -0000

In the documentation (Introduction) we read that "This library is
implemented for the C++03 <http://en.wikipedia.org/wiki/C%2B%2B> standard
and it does not require C++11 <http://en.wikipedia.org/wiki/C%2B%2B11>." I
think it is a bit imprecise, because many examples in the docs silently
assume that variadic macros, which are not part of C++03, are available. I
believe something like this would be more accurate "This library is
designed to work on C++03 compilers that support variadic macros; no other
C++11 support is necessary. Additionally, if variadic macros are not
supported, this library works in >>strict C++03<< mode with slightly
different syntax."

This is more correct but it's too verbose for the Introduction
section. Also variadic macros were part of C99, etc before C++11. I
might add a footnote to the statement that say "technically variadic
macros are not part of C++03, if your compiler doesn't support
variadic macros see No Variadic Macros section".

add a note that lib used to support non-macro API

Lorenzo Caminiti — Mon, 10 Sep 2012 18:51:29 -0000

Add a note that lib used to support non-macro API which was later abandoned (just mentioning this in the Release Notes section makes it too hidden).

Also let's keep in mind that contracts should be specified at the
declaration site. In any case, this is the best I was able to do
without using macros (rev 0.3.490 of the lib that still supported the
non-macro API):
http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp_0_3_490/doc/html/contract__/without_the_macros.html

Essentially this used function pointers (I guess you could similarly
use functors) to pass to the lib the functions that checked
pre/post/etc so the lib could check. This was abandoned because of the
large amount of boiler-plate code that users have to program,
including repeating the function signature a few times to program the
pre/post/body/etc functions to pass to the lib. Also subcontracting
relied on the user repeating bases classes everywhere making the code
very hard to maintain. Finally, disabling the contract code on
compilation (i.e. removing the pre/post/body/etc functions/functors)
required the user to manually program #ifdef and the all thing got
pretty ugly.

I don't see how C++11 could improve this (also lambdas can't be used in declarations which is were contracts belong).

move static-assertions and ConceptCheck into a check clausule

Lorenzo Caminiti — Mon, 10 Sep 2012 18:36:48 -0000

Removal of the Concepts part.
The use of Boost.ConceptCheck to emulate C++ concepts proposal is in my
opinion erroneous. Boost.Concept.Check is used to assert the actual
parameter satisfy statically the concept conditions, while if I'm not
wrong
the C++ Concepts proposal use the requires clause to state the
conditions
of
a possible instantiations. Using the same grammar with different
semantics
is confusing. In a last resort, if this feature is preserved, the
requires
keyword must be changed by another one.

If that were to be the final decision, I'll remove the interface to
Boost.ConceptCheck or I can use any (alphanumeric) mane rather than
requires (e.g., where).

However, I can use the requires clausule to do multiple things:
1. Check concepts defined using Boost.ConceptCheck (current, I'd leave
it as is).
2. Check static_assert (under consideration, to be moved here from
within pre/post/inv).
3. Check Boost.Generic-like concepts implemented using C++11
expression SFINAE (for future... this will be a lot of work...).
I should be able to support of all those because I can distinguish 2
using the pp (starts with static_assert)

I will really prefer the static_assert goes outside requires, e.g. in a
new
check clause. This clause could also contain the ConceptCheck part. In
this way it is clear that the requires part will disable the
instantiation
if not satisfied, and the check part will report a compile-time error if
not
satisfied.

and I can distinguish between
1 and 2 using the compiler for example using a (hidden) tagging base
class to all concepts defined for 3.

I'm not sure this distinction is possible. For function templates, the
requires part associated to ConceptCheck should be included in the
function
definition, while the one associated to enable_if/SFINAE c++ proposal
concepts emulation should be part of the C++ declaration. For template
classes, ConceptCheck goes to the members part, while Concepts goes to
the
template parameter part.

As you can see the semantics are different, so a specific keyword would
help
to identify the difference.

Can you provide an example of how all of this would ideally look like?
You can also pick a "keyword" other than requires that makes sense to
you and then indicate where to use requires and where to use the other
keyword in the example. Maybe you start from the static_assert example
I gave:

template< typename To, typename From >
requires // new concepts??
Convertible<From, To> // disable this declaration using
SFINAE??
unless // static_assert and Boost.ConceptCheck??
static_assert(sizeof(To) >= sizeof(From), "destination too
small"), // generate compiler-error??
boost::Copyable<From> // generate compiler-error??
To memcopy ( To to, From* from )
precondition {
to; // pointer not null
from; // pointer not null
}
{
// ...
}

I will use check as keyword for the static_assert and ConceptCheck part

template< typename To, typename From >
requires // used with enable_if in the declaration part
is_convertible<From, To>::value
check // included in the function body

assert(sizeof(To) >= sizeof(From), "destination too small")
&& boost::Copyable<From>

To memcopy ( To to, From* from )
precondition {
to; // pointer not null
from; // pointer not null
}
{
// ...
}

You could also use the check

sizeof(To) >= sizeof(From)

in the requires part if you wanted to disable overload resolution when the
condition fails as in

template< typename To, typename From >
requires // used with enable_if in the declaration part
is_convertible<From, To>::value
&& sizeof(To) >= sizeof(From)
check // included in the function body
boost::Copyable<From>

To memcopy ( To to, From* from )
// ...

Note however that the Concept Copyable from ConceptCheck can not be used in
the requires clause (I'm looking for), it is not a bool metafunction (or a
trait). It just compile fail when the parameter doesn't models the concept.

This makes sense to me and, as far as I can tell, it is also in line
with Andrzej suggestion. I'm happy to implement it this way.

CONTRACT_FUNCTION(

template( typename To, typename From )

requires( // used with enable_if in the declaration part

is_convertible<From, To>::value,
is_convertible<To, From>::value

)
check( // included in the function body

static_assert(sizeof(To) >= sizeof(From), "destination too small"),
boost::Copyable<From>

)

(To) memcopy ( (To) to, (From*) from )

precondition(

to; // pointer not null
from; // pointer not null

)

) {

// ...

}

I will implement the check clausule now and the require one later and
only if I'm able to extend the lib to declare and check
Boost.Generic-like concepts.

Just to consider all alternatives, we could also do this:

CONTRACT_FUNCTION(

template( typename To, typename From )

if( // used with enable_if in the declaration part

is_convertible<From, To>::value,
is_convertible<To, From>::value

)
requires( // included in the function body

static_assert(sizeof(To) >= sizeof(From), "destination too small"),
boost::Copyable<From>

)

(To) memcopy ( (To) to, (From*) from )

precondition(

to; // pointer not null
from; // pointer not null

)

) {

// ...

}

Given that the 1st clausule is more like enable-if and the 2nd
clausule states "hard" requirements (in that you get a "hard" compiler
errors when the requirements are not met). But I'm happy with
requires/check and if/requires the same way (and I still haven't read
N3331 which might suggest a syntax vs another...).

The requires clausule will be saved for C++11/enable_if/expression-SFINAE/Boost.Generic-like concepts (no hard errors but removal from overload resolution).

static_assert will not be allowed in pre/post/class-inv/block-inv/loop-var/etc but only in the check clausule.

add an Implementation section

Lorenzo Caminiti — Mon, 10 Sep 2012 18:21:10 -0000

Ideally, the docs will provide an Implementation section that can show some example code of what the macros generate. However, given the large amount of generated code this could be hard to do and especially to maintain (if/when the lib impl changes).