Topic: Value constraints (or contract programming in C++)
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 4 Jul 2014 07:52:03 -0700 (PDT)
Raw View
------=_Part_80_32937670.1404485523485
Content-Type: multipart/alternative;
boundary="----=_Part_81_2415517.1404485523486"
------=_Part_81_2415517.1404485523486
Content-Type: text/plain; charset=UTF-8
Hi,
I wanted to share here my reflections about how C++ could support contract
programming (things like preconditions). One alternative to the
"traditional" design-by-contract is considered.
I share the html document on GitHub, so there is an inconvenience involved:
you have to see it in raw form, download and then reopen in the browser.
Here's the link:
https://github.com/akrzemi1/contract/blob/master/contract.html
I also enclose it for convenience. I would be grateful for any comments.
Regards,
&rzej
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_81_2415517.1404485523486
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<br>I wanted to share here my reflections about how C++=
could support contract programming (things like preconditions). One altern=
ative to the "traditional" design-by-contract is considered. <br><br>I shar=
e the html document on GitHub, so there is an inconvenience involved: you h=
ave to see it in raw form, download and then reopen in the browser. Here's =
the link:<br><br>https://github.com/akrzemi1/contract/blob/master/contract.=
html<br><br>I also enclose it for convenience. I would be grateful for any =
comments.<br><br>Regards,<br>&rzej<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_81_2415517.1404485523486--
------=_Part_80_32937670.1404485523485
Content-Type: text/html; charset=UTF-8; name=contract.html
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename=contract.html
X-Attachment-Id: 464541be-b443-41f5-89bd-e95ead9383bf
Content-ID: <464541be-b443-41f5-89bd-e95ead9383bf>
<html>
<head>
<title>Value constraints</title>
</head>
<body>
<p>Author: Andrzej Krzemieński</p>
<h1>Value constraints</h1>
<p>In this paper we want to analyse how a support for contract programming-=
like features could be supported in C++. We use a different term "value sem=
antics" to stress that we do not necessarily want to copy solutions that ot=
her imperative programming languages adapt. we want to change a focus from =
how broken contracts are responded to in run-time, to how contract violatio=
ns can be detected at compile-time. This is a high-level overview of the pr=
oblem, and we are not even covering the things like sub-contracting or othe=
r interactions with OO features.</p>
<h1>What do we need?</h1>
<p>
The 'features' we describe here can be collectively called <em>value constr=
aints.</em>
We want to use them to express in the language that certain combinations of=
values of certain objects=20
at certain times are invalid and are intended (and expected) never to occur=
..</p>
<h2>Specify function's domain</h2>
<p>The problem goes back to mathematics. Certain functions are well defined
only for a subset of values of the input type. for instance a square root
over real numbers is not defined for negative numbers.=20
What does it mean for a function in a programming language like C++=20
that it is not defined? Currently there are two approaches. One is to detec=
t=20
the value of the parameter(s) that the function should not be prepared for=
=20
and execute a different logic: returning a special value, throwing an excep=
tion, etc.=20
Using our example with a square root, a corresponding function <code>sqrt()=
</code>
could be defined as follows:</p>
<pre>double sqrt(double x)
{
if (x >=3D 0.0) {
//<em> do proper algorithm</em>
}
else {
return numeric_limits<double>::signaling_NaN();
// <em>or throw an exception</em>
}
}
</pre>
<p>What it effectively does is to change the function's domain. Now the fun=
ctions do not restrict its domain anymore.
It is well defined for every value of an input type, and does other things =
than only the "proper algorithm".=20
This has an unintended consequence: our function can be used for detecting =
negative numbers:
</p>
<pre>double is_negative(double x)
{
return isnan(sqrt(x));
}
</pre>
<p>Another way of approaching the function domain problem is to informally =
'announce' that the function is not
defined for certain values of input types and implement it with the assumpt=
ion that the undesired values
are never passed to the function:</p>
<pre>
double sqrt(double x)
// requires: x >=3D 0.0
{
// proper algorithm:
double y =3D 1.0;
double prev_y;
=20
do {
prev_y =3D y;
y =3D (y + x / y) * 0.5;
}
while (!closeEnough(y, prev_y));
=20
return y;
}
</pre>
<p>This uses Newton's Iteration algorithm. The loop will terminate when val=
ues <code>y</code> and <code>prev_y</code> become close enough. They will o=
nly do that when <code>x</code> is non-negative. Supplying a negative value=
will make the loop run forever and hang the program. Even a clever analyse=
r is unlikely to detect from the function body that passing a negative inpu=
t to this function is something wrong. But everything is fine as long as no=
negative number is passed in. 'Announcing' that the function is not prepar=
ed for just any input is informal: it is either written in the comment, or =
in paper or html documentation, or only spread by word, or assumed to be ob=
vious. This risks an unintended negative program behaviour, like a halt, or=
a UB. However, it is often preferred because of performance and inability =
to come up with a reasonable fall-back action. Consider <code>std::vector::=
operator[]</code>, it does not check the bounds for performance reasons. If=
it was used in the following code:</p>
<pre>
for (int i =3D 0; i !=3D vec.size(); ++i) {
if (i > 0) cout << ", ";
cout << vec[i];
}
</pre>
<p>The condition in the loop already checks if the index is within bounds. =
If <code>operator[]</code> was also checking the same condition inside, we =
would be wasting time on doing redundant checks. Also, for some functions i=
t is not possible to think of any fall-back action. For instance <code>std:=
:vector::swap</code> must not throw exceptions and returns <code>void</code=
>, yet, it is not well defined when two vectors' allocators do not compare =
equal.</p>
<p>Not checking for argument being within domain and delegating the check t=
o the callers is desirable, especially that the caller is in a better posit=
ion in verifying if the domain of the function. Consider:</p>
<pre>return sqrt(abs(x));</pre>
<p>The caller can be sure that no negative value is passed to function <cod=
e>sqrt()</code> even though no check is performed at all. Function domain d=
efined this way is a <em>contract</em> between function author and function=
callers. The author defines the domain and assumes he will not get values =
from outside the domain. The caller guarantees that she will not pass value=
s outside the domain. Out of all contracts described here, this one is the =
most likely to be broken, because it is the only one where the person respo=
nsible for guaranteeing is different than the person declaring the contract=
.. The user may not be aware that a function has requirements on the values =
of parameters, or may misunderstand what the requirement is. Therefore this=
contract requires the most serious attention and support in the language.<=
/p>
<p>What we need is the ability to declare the function's domain along with =
the function, so that it is visible to the callers and to the automated too=
ls. How the tools can handle this is a secondary issue, but the behaviour c=
an be: (1) automated documentation generation, (2) additional warnings from=
static analysers, (3) additional instrumentation injected by compilers, (4=
) compiler optimizations based on domain declarations.</p>
<h2>Specify function's co-domain</h2>
<p>In the above example with function <code>abs()</code> a hypothetical too=
l could detect that expression <code>sqrt(abs(x))</code> is always fine onl=
y if it knew that the co-domain of <code>abs</code> is equal (or smaller) t=
han the domain of <code>sqrt</code>. We need to be able to constrain the al=
lowed function output in order for automated tools to be able to verify if =
other functions' domain requirements are satisfied. </p>
<p>In this case a function author specifies the contract and (likely) the s=
ame author guarantees it. Function's user can rely on the guarantee. It is =
much less likely that this contract is broken, because it is the same perso=
n that declares and later ensures the obligation. And conversely, if the au=
thor makes an error in the function, he is equally likely to make an error =
in specifying the contract.</p>
<h2>Block-level assertions</h2>
<p>This type of value constraint is quite familiar to many C++ user, as it =
is implemented with macro <code>assert</code> and some similar tools in man=
y libraries. If we think of it as a contract, this time a function author d=
efines it, he ensures that it holds, and he is the benefactor of the contra=
ct: he guarantees something to himself, namely that certain state of a bloc=
k-local variable or set of variables shall never occur at the point of the =
assertion. At the same time the function author guarantees something that h=
e can be held accountable for, and relies on the guarantee expressed with t=
he assertion.</p>
<h2>Class-level assertions</h2>
<p>A similar constraint on variables is often required for (non-static) dat=
a members of objects of a given class. Consider the following example:</p>
<pre>class WeighedAverage
{
double wgt1_ =3D 0.5;
double wgt2_ =3D 0.5;
public:
double average(double val1, double val2) const;=20
<em>// ensures: answer is between val1 and val2</em>
{ return wgt1_ * val1 + wgt2_ * val2; }
void set_1st_weight(double w1);=20
<em>// requires: w1 between 0.0 and 1.0</em>
{ wgt1_ =3D w1; wgt2_ =3D 1.0 - w1; }
<em>// always true: wgt1_ between 0.0 and 1.0</em>
<em>// always true: wgt2_ between 0.0 and 1.0</em>
<em>// always true: wgt1_ + wgt2_ =3D=3D 1.0</em>
};
</pre>
<p>Note the three comments at the bottom. They are something that could be =
expressed with macro <code>assert</code>, except that <code>assert</code> i=
s an expression and cannot be put at the class scope. Note also that member=
s <code>wgt1_</code> and <code>wgt2_</code> are private. So, we are not dec=
laring anything to the outside world. Word "always" needs to be more formal=
.. It applies to any object of this class whose life time has begun and have=
not yet ended, except that member functions can temporarily compromise it =
provided that they restore it upon exit (either via exception or a normal r=
eturn). Also, in case of thread or context switching, if a function decides=
to temporarily break such class-scope assertion, it must guard this action=
with a lock or equivalent, so that other threads do not see an object with=
a broken contract.</p>
<p>Class-level assertions (or class invariants) could be use as a criterion=
for good abstractions, much like axioms in concepts. If you cannot specify=
an invariant, it might be an indication that the design/abstraction may be=
poor or this should not have been made a class.</p>
<h2>Specify equivalent expressions</h2>
<p>Often library interfaces offer more than one way of doing the same thing=
.. For instance, checking if a container contains at least one element can b=
e checked in two ways: <code>cont.empty()</code> and <code>cont.size() !=3D=
0</code>. The latter is more general and could be used to check for emptin=
ess, but there are occasions where the former can perform faster. This just=
ifies the existence of the two forms. However, the job of matching one func=
tion's domain with other function's co-domain would be severely impeded if =
either specified the contract with a different (albeit equivalent) expressi=
on. consider:</p>
<pre>template <typename T>
class vector
{
void resize (size_t s); <em>// ensures: this->size() =3D=3D s</em>
const T& front() const; <em>// requires: !this->empty()</em>
};
vec.resize(1);
return vec.front(); <em>// safe?</em>
</pre>
<p>Can we match what <code>resize</code> guarantees with what <code>front</=
code> expects? The two expressions are different. It would be much easier i=
f we were able to explicitly declare that for any container expressions <co=
de>cont.empty()</code> and <code>cont.size() !=3D 0</code> are equivalent. =
This is somewhat similar to class-level assertions, but the declaration app=
lies to more than one class, now we are only interested in the public inter=
faces, and we can express equivalence between expressions that have side ef=
fects. for instance, we can specify that <code>cont.clear()</code> is equiv=
alent to <code>cont.resize(0)</code>. Out of all "constraints" described in=
this section, this is the only one where term "value constraint" is inadeq=
uate. This is a constraint on the semantics of expressions.</p>
<h2>Loop variants</h2>
<p>This is somewhat similar to an assertion. It can help convince oneself t=
hat a non-trivial loop will ultimately terminate. Sometimes it is not easil=
y seen, because there is no loop counter. We may for instance inspect eleme=
nts in the collection by skipping some elements, increasing or shrinking, t=
he collection. A loop variant is an expression that evaluates to an integra=
l non-negative number. It is expected that in each loop iteration evaluatin=
g this expression renders a number smaller than in the previous iteration. =
It is also expected that when the value renders zero, the loop terminates.<=
/p>
<p>A framework for supporting value constraints need not address all the ab=
ove needs. We believe that only supporting the declaration of function doma=
in is a big help in itself. Note that while assertions loop variants need t=
o work with expressions, the features for specifying function domain and co=
-domain need not necessarily use expressions. We address this in detail in =
the later sections.</p>
<h1>What use can be made of value constraints?</h1>
<p>Value constraints exist, even though there is no language support for th=
em in the language. We have seen in the above examples that comments were u=
sed to convey the information. In this section we list the benefits obtaine=
d form standardizing or formalizing value constraints this way or the other=
..</p>
<p>In order for an automated tool to understand the constraint, we have to =
provide a special-purpose syntax. Some tools expect that it is put inside s=
ource code comments. For instance <a href=3D"#ACSL">[ACSL]</a> uses the fol=
lowing notation: </p>
<pre><em>/*@ requires x >=3D 0;
ensures \result >=3D 0;=20
*/</em>
double sqrt(double x);</pre>
<p>But for structured comments like the above, C++ has an alternative: [[at=
tributes]]. Attributes are akin to comments because they cannot affect the =
semantics of the program. On the other hand they can be used as hints for o=
ptimizations, warnings and any kind of program analysis. If the expectation=
of value constraints is to affect the program behaviour, attributes will n=
ot do, and a special language feature would need to be devised.</p>=20
<p>An ideal — and unrealistic — support for value constraints i=
s for compiler to check any possible flow in the program and signal a compi=
ler error whenever a breach of the constraint is going to happen. Because t=
his is not doable, the we aim at the support that is not entirely satisfact=
ory, but believed to be better than none.</p>
<h2>Improved documentation</h2>
<p>One of the obvious uses of formalized value constraints is the automated=
generation of documentation. Even if developers do not use any tool for ge=
nerating documentation, there is still a gain. When a developer sees the de=
claration of the function she is going to use, she can immediately see the =
value constraints along. If they are a language feature, developers are mor=
e encouraged to use them (even though comments would do). Since this does n=
ot affect program semantics [[attributes]] are sufficient.</p>
<h2>Static analysis</h2>
<p>Value constraints could enable static analysers to detect a potential br=
each of value constraints and issue warnings. Again, using value constraint=
s this way does not affect program semantics, so [[attributes]] would do.</=
p>
<h2>Constraint-based compiler optimizations</h2>
<p>In that case, compiler is able to arbitrarily change the behaviour of th=
e program in case where a value constraint has been violated. So, adding a =
value constraint may change the meaning of the program. In this case attrib=
utes will not suffice, and we need a language extension for specifying valu=
e constraints.</p>
<h2>Auto-generation of runtime checks</h2>
<p>This is what Eiffel provides and what <a href=3D"#N1962">[N1962]</a> pro=
poses. Value constraints need to be C++ expressions. An implementation can =
(optionally) inject, at well defined places, a code that evaluates at run-t=
ime expressions representing value constraints. If any (boolean) expression=
evaluates to <code>false</code>, a certain action (like calling <code>std:=
:terminate</code>) is performed. The insertion of additional logic requires=
that value constraints are introduced as a language feature. In fact even =
more language and library features is required to control when and how the =
run-time checks are performed and responded to.</p>
<h1>Run-time evaluation of value constraints</h1>
<p>In this section we focus on one possible approach: treating value constr=
aints as expressions and evaluating them at run-time.</p>
<h2>Side effects of the expressions</h2>
<p>Using expressions with side effects in value constraints is generally di=
scouraged, but sometimes it might be difficult to spot that we have a side =
effect. For the purpose of this discussion we also consider run-time overhe=
ad, and especially the run-time complexity as a side effect. To minimize th=
e possibility of invoking a function with a side effect <a href=3D"#N1962">=
[N1962]</a> proposes that only <code>const</code>-qualified member function=
s are allowed; but even these can modify non-member variables, and it is no=
t only member functions that may need to be used to express value constrain=
ts. Ideally, we would like to use only <em>pure</em> (referentially transpa=
rent) expressions, but C++ as of today does not offer the possibility of de=
tecting if an expression is pure. Although the definition of relaxed <code>=
constexpr</code> functions makes a step towards pure functions.</p>
<p>A practical question to be answered, given the syntax from <a href=3D"#N=
1962">[N1962]</a>, is if the following to be a legal code for detecting if =
run-time value constraint checks are enabled?</p>
<pre>
int preconditions_on =3D false;
void test() precondition{ preconditions_on =3D true; }
{
cout << "preconditions are on: " << preconditions_on;
}
</pre>
<p>And similarly, is the following a reliable way of checking if a number i=
s negative?</p>
<pre>double sqrt(double x) precondition { x >=3D 0.0; };
double is_negative(double x)
{
set_precondition_broken_handler(&throw_exception);
try { sqrt(x) };
catch (exception const&) { return true; }
return false;
}
</pre>
<h2>Value constraints in overloaded functions</h2>
<p>Consider the following declaration:</p>
<pre>
template <typename IIT> <em>// requires: InputIterator<IIT></em=
>
void displayFirstSecondNext(IIT beg, IIT end);
<em>// requires: std::distance(beg, end) >=3D2</em>
</pre>
<p>Is function template <code>std::distance</code> referentially transparen=
t? The answer is: it is not templates that can or cannot be pure but functi=
ons. Some functions instantiated from this template will be pure, others wi=
ll not — it depends what iterator type the template will be instantia=
ted with. Consider <code>InputIterator</code>. In the worst case (of <code>=
std::istream_iterator</code>) incrementing the iterator invalidates other i=
terators referring to the same stream. This is a tricky behaviour: by chang=
ing our internal copies of objects (iterators), we alter (invalidate) other=
, external objects. Function <code>std::distance</code> does increment iter=
ators. If our precondition was to be evaluated, this might cause a UB in th=
e program.</p>
<p>Thus, we have an expression; it is pure and natural to use for some inst=
antiations, and has severe side effects for other instantiations. If we wan=
t it to be evaluated only in certain instantiations, another feature needs =
to be provided. For instance, we will need to specialize a template only to=
be able to specify a different precondition, or add an annotation that thi=
s precondition should not be evaluated if certain compile-time predicate ev=
aluates to <code>true</code>. clearly, on global switch (similar to <code>N=
DEBUG</code>) saying "disable/enable all value constraint evaluations" will=
not be enough.</p>
<h2>Inadvertent increase in run-time complexity</h2>
<p>There are other reasons for having a more fine grained control of which =
checks should be enabled. Consider a binary search algorithm. Its runtime c=
omplexity is O(log <var>n</var>). It has an obvious precondition that the r=
ange we search through is sorted. Performing the sorted check has complexit=
y O(<var>n</var>). Thus by evaluating the precondition, we change the algor=
ithms complexity. This might be unacceptable, even for some debug/testing b=
uilds. Runtime complexity is a sort of side effect of an algorithm, and it =
can be silently added to the function, especially when following a good pra=
ctise a developer adds an obvious precondition, which would be his primary =
task, and forgets the secondary task of specifying (using some contract-spe=
cific sub-language) the conditions under which this precondition shall be e=
valuated.</p>
<h2>Run-time response to a broken contract</h2>
<p><a href=3D"#N1962">[N1962]</a> proposes that the action taken upon viola=
ting a value constraint should be configurable by the programmer. While we =
agree this should be configurable, we object to the way of achieving this b=
y <code>std::set_terminate</code>-like registering function. <code>std::set=
_terminate</code> can be called multiple times from multiple places: differ=
ent, possibly dynamically-loaded/shared libraries. This makes sense for <co=
de>std::terminate</code>. Every part of the system may acquire a <em>critic=
al</em> resource: one that has to be released even if "exception handling m=
ust be abandoned for less subtle error handling techniques". In that case t=
he component also needs to register an additional clean-up function. In cas=
e of broken contract situation, we do not need or want that. We believe onl=
y the person that assembles the final program from the components and libra=
ries, should be empowered to to decide how broken contracts are handled. On=
ly him does have the knowledge if this is a test or a retail build; if the =
slow-down of some run-time checks can be afforded. Libraries do not know th=
at: they do not know in what environment they will be used.</p>
<p>Additionally, the <code>std::set_terminate</code> mechanism has a certai=
n flow. Unless you apply some syntactic contortions, you cannot set the han=
dler for functions executed before <code>main()</code>.</p>
<p>We are not aware of any mechanism currently available in C++ that would =
facilitate our needs. But since function <code>main</code> has the property=
of being required to be defined only once across the executable program, a=
solution we are leaning towards is to apply some special annotation around=
function <code>main</code> that would indicate what the user's preference =
is on the handling of broken contracts.</p>
<h1>Assisting static analysis</h1>
<p>Automated tools already perform static analysis, even without any suppor=
t from the programmer. However, additional hints from developers could enab=
le even further analysis, or enable vendors to add analysis in compilers at=
lower expense. In the example like the following, a compiler can fairly ea=
sily detect that a potential UB is at hand:</p>
<pre>int* produce()
{
if (cond) return &global;
else return nullptr;
}
void consume(int* p)
{
use(*p);
}
consume(produce());
</pre>
<p>But even here, certain problems occur. What if the two functions are com=
piled separately; e.g., if <code>produce</code> is part of a separate third=
party library? Even if compiler performs a per-file analysis, it may not h=
ave sufficient resources (RAM) to perform a global link-time analysis. Even=
if the analysis is successful and detects a potential UB, it doesn't tell =
us who of the three: author of <code>produce</code>, author of <code>consum=
e</code> or the guy who assembles them, is responsible for the situation an=
d should fix the problem. This is somewhat similar to the situation we face=
today with template instantiation error messages. Compiler sees that there=
is a syntax/type error, it can give you the entire context, but it cannot =
tell at which level of instantiation process the source of the problem lays=
..</p>
<p>Also, as shown in the example with <code>sqrt</code> it is sometimes not=
possible to tell from only observing the reads from a variable what the fu=
nction's requirement is. In the case of <code>sqrt</code> it is not the UB =
that we want to avoid but an infinite recursion.</p>
<p>Another reason where assisting the static analysis may prove useful is w=
hen there is more than one way to express a given condition. Consider the f=
ollowing code:</p>
<pre>
class Vector
{
const T& front() const; <em>// requires: !this->empty()</em>
<em>// ...</em>
};
void test(Vector & vec)
{
if (vec.size() !=3D 0)
use(vec.front());
}
</pre>
<p>You know that <code>vec.size() !=3D 0</code> and <code>!vec.empty()</cod=
e> mean the same thing, but compiler may not, especially if it cannot look =
inside the definitions of member functions (because they are compiled separ=
ately).</p>
<h2>How long does a condition hold?</h2>
<p>We illustrate the issue in question with the following two examples.</p>
<pre>
Iter test(Iter b, Iter e, Value_type<Iter> v)
{
std::sort(b, e);
fun();
std::binary_search(b, e, v); // requires: is_sorted(b, e)
}
</pre>
<p>Assuming that a static analyser can somehow figure out that <code>sort</=
code> leaves elements in the state that satisfies the condition <code>is_so=
rted</code>, can it be sure that the condition still holds when <code>fun</=
code> is finished? After all <code>fun</code> could be manipulating iterato=
rs that alias <code>b</code> and <code>e</code>. Apparently, static analysi=
s cannot give us a 100% bug-free guarantee. It can only helps detect certai=
n bugs.</p>
<p>Second, it is obvious that a certain condition does not last forever. Ho=
w is the analyser supposed to know when a given condition ceases to hold? O=
ne easy answer would be to say that when a non-<code>const</code> operation=
is called on the object all conditions it might have satisfied are now co=
nsidered not satisfied. But this would break even simple use cases:</p>
<pre>void test(std::vector<int> & vec)
auto b =3D vec.begin(); <em>// non-const: invalidates all conditions</em>
auto e =3D vec.end(); <em>// non-const: invalidates all conditions</em>
std::sort(b, e); <em>// requires: valid_range(b, e)</em>
</pre>
<p>Even if the analyser knows that <code>vec.begin()</code> and <code>vec.e=
nd()</code> form a valid range, they are a non-<code>const</code> operation=
s and invalidate any assumptions about their value/state. Any language feat=
ure for assisting static analysis must provide a way of specifying which op=
erations invalidate which conditions. But this is likely to make the specif=
ications very complicated, and discourage everybody from using the feature.=
</p>
<h1>"Properties": a hypothetical language feature</h1>
<p>In this section we describe a language feature that would enable definin=
g value constraints in a somewhat different way than the "imperative" appro=
ach described in <a href=3D"#N1962">[N1962]</a>. We call it <em>properties<=
/em>, which have been described in <a href=3D"#N3351">[N3351]</a>. A proper=
ty is a new kind of "entity" in the language: it is neither an object, nor =
a function, it is just something else. It is introduced by an invented keyw=
ord "<code>property</code>":</p>
<pre>template <typename T>
property bool is_non_empty (std::vector<T>);
</pre>
<p>A property is something that an object, or a group of objects can acquir=
e at a certain point in time, and then loose at a different point in time. =
There is no function-body associated with the property: it only has a name.=
A property can be used in specifying pre- and postconditions:</p>
<pre>
template <typename T>
class vector
{
void push_back (T const&); // post: is_non_empty(*this);
const T& back() const; // pre: is_non_empty(*this);
};
vector<int> v; // doesn't have property is_non_empty yet.
v.push_back(1); // acquires property is_non_empty
int i =3D back(); // required property is present
v.pop_back(); // looses property is_non_empty
</pre>
<p>How do we know when a property is lost? In the most simple case we could=
say that every mutating (non-const) function called upon our object discar=
ds all its properties. But this would imply that in our case even calling <=
code>back()</code> discards the property, so a more complex way of specifyi=
ng how the properties are preserved may be required.</p>
<p>So, what do we buy using properties rather than considering any boolean =
expression such a property? First, properties are pure: they have no side e=
ffects. Second, we can express value constraints that are not expressible w=
ith expressions:</p>
<pre>
template <typename Iter>
property bool valid_range(Iter begin, Iter end);
template <typename T>
class vector
{
// invariant: valid_range(this->begin(), this->end());
};
template <typename Iter>
void sort(Iter begin, Iter end) // pre: valid_range(this->begin(), this-=
>end());
</pre>
<p>We do not propose to add such properties to the language. We just want t=
o show a different perspective on value constraints. <a href=3D"#N1962">[N1=
962]</a> also offers this perspective, but we fear that the focus on broken=
contract handlers and the order of evaluation of different value constrain=
ts, might have obfuscated this idea. A similar effect (as having properties=
) could be achieved by annotating some value constraints (which use normal =
expressions) that they must never be evaluated. </p>
<h1>Interactions with other C++ features</h1>
<h2>When should precondition hold?</h2>
<p>A common answer to this question is "after function parameters have been=
initialized, before its first instruction is executed." While it looks goo=
d in typical simple examples, consider the following case:</p>
<pre>void fun(Tool * const tool, int const i)
// requires: tool !=3D nullptr
// requires: tool->value() >=3D 0;
{
line_1: int j =3D transform(i);=20
line_2: int k =3D process(tool->value());
}
</pre>
<p>A precondition constrains the state of a remote object of type <code>Too=
l</code>, its state can change asynchronously. Suppose we can evaluate the =
precondition upon entering the function. We determine that it is satisfied.=
We successfully execute instruction <code>line_1</code>, we will now proce=
ed to instruction <code>line_2</code>. It is only now that we really need t=
he precondition to hold, but by now the state of the remote object referred=
to by pointer <code>tool</code> might have already changed (perhaps functi=
on <code>transform</code> modified it)</code>. While the precondition held =
upon entry, the same condition caused a UB later on. Even if one argues tha=
t function must not break the precondition itself, one should still conside=
r the possibility that while executing <code>line_1</code> another thread m=
ay concurrently update the object referred to by <code>tool</code>. So, sho=
uld precondition hold for the entire duration of its function? Or is it a b=
ad idea to express a constrain on remote objects that we do not obtain by v=
alue? We do not have a ready answer for this question, but the question is =
very important, because this kind of interface is used in STL algorithms: t=
hey obtain and return iterators, which are handles to remote parts likely a=
liased and accessible by other threads.</p>
<h2><code>constexpr</code> functions and literal types</h2>
<p><code>constexpr</code> functions can be evaluated at run-time or at comp=
ile-time. Ideally, a compile-time evaluation of such function should result=
in compile-time error when its precondition or postcondition is broken. Th=
is is possible if expressions in preconditions and postconditions are core =
constant expressions. It appears reasonable to require that <code>constexpr=
</code> functions have only <code>constexpr</code> value constraints.</p>
<p>A similar question needs to be answered for literal types and invariants=
.. For literal types it is required that they have at least one non-copy/mov=
e <code>constexpr</code> constructor. This constructor can be used to creat=
e a compile-time constant, whose invariant is expected to hold. This may re=
quire that the invariant should also be <code>constexpr</code>, as otherwis=
e it is impossible to verify it at compile time. On the other hand, the int=
erface of user-defined literal types can be divided into compile-time (<cod=
e>constexpr</code>) and run-time part. The effects of the other one may alt=
er other parts of the program state that may only be invariant-verified wit=
h run-time expressions. More, some constructors are <code>constexpr</code> =
even for non-literal classes: their purpose is to guarantee the static init=
ialization of global objects. It is not clear if this should affect the <co=
de>constexpr</code> requirement on the class invariant.</p>
<h2>When should invariant hold?</h2>
<p>When is class invariant supposed to hold? Objects are manipulated via cl=
ass's public interface. Public functions often need to compromise the invar=
iant, but they always put the invariant back when they finish -- even via a=
n exception. This means that as long as no function from the object's publi=
c interface is being invoked on it, or any of its subobjects manipulated, t=
he object's invariant should hold.</p>=20
<p>This is different from the common notion that invariants should hold bef=
ore entering any public function or destructor and after leaving any public=
member function or constructor. For instance, inside a public function you=
can invoke other public functions and around these nested calls you do not=
expect the invariant to hold.</p>
<h2>Composing invariants</h2>
<p>Given some class <code>D</code>, apart from its "direct" invariant, we e=
xpect that invariants of <code>D</code>'s bases classes and <code>D</code>'=
s data members also hold. This can be implicit, you do not have to make rec=
ursive definitions yourself, similarly like you do not have to specify in t=
he destructor which subobject's destructors need to be called. But this doe=
s not cover all cases. Consider class <code>optional</code> (similar to Boo=
st.Optional), it can be implemented as follows:
<pre>
template <typename T>
class optional
{
bool is_initiailzed_ =3D false;
std::aligned_storage_t<sizeof(t), alignof(T)> storage_;
T* storage() { return *static_cast<T*>(&storage_); }
public:
explicit operator bool() const { return is_initialized_; }
T& operator*() {=20
assert (is_initiailzed_);
return *storage();=20
}
optional(const T& v) {
new (storage()) T(v);=20
is_initiailzed_ =3D true;
}
~optional() {=20
if (is_initiailzed_)
storage()->T::~T();
}=20
}; =20
</pre>
<p>
Obviously, we store (sometimes) an object of type <code>T</code> inside, bu=
t it is neither a base class nor a member sub-object. Yet, if it is there (=
if optional object contains a value), we want its invariant to hold, and co=
mpiler may not be able to deduce it. We might need to express a "conditiona=
l" invariant:</p>
<pre>// invariant: !is_initialized_ || invariant(*storage());</pre>
<p>Similarly, a vector of <code>T</code>s (<code>std::vector<T></code=
>) can be thought of as being composed of the <code>T</code>s it contains. =
This is reflected in how its equality comparison is defined and how const-n=
ess is propagated. A value of the container is composed of the values of it=
s elements. In a similar manner, we would like to be able to express invari=
ants on composed types, i.e., the vector's invariant holds iff some vector-=
specific conditions are satisfied and all vector elements' invariants hold.=
We are not quite sure, if this needs to be specified explicitly, or is it =
not enough for the machine to observe that if there is some nested T access=
ible from the vector, its invariant must hold. But will the machine know th=
at the result of <code>vec.back()</code> should have its invariant hold? af=
ter all, calling <code>back()</code> is not always allowed, and may render =
a UB.</p>
<p>Another open question is if we should check invariants of member subobje=
cts if they are references (and therefore do not pertain to the master obje=
ct=E2=80=99s value).</p>
<h2>Function's public interface</h2>
<p>For the purpose of specifying the semantics of value constrains, we may =
need to redefine the concept of class's public interface. Consider the foll=
owing definition:</p>
<pre>class Account
{
public:
void modify(Param p);
friend void swap(Account& a1, Account& a2);
private:
// ...
};
</pre>
<p>Function <code>swap</code>, although it is not a public member function,=
clearly is part of <code>Account</code>'s public interface. I.e., we allow=
that it temporarily breaks the invariant of objects <code>a1</code> and <c=
ode>a2</code>. The technique with defining operator-like free functions as =
friends is not just a trick. In fact it is sometimes recommended for operat=
ors like <code>operator=3D=3D</code> when the two arguments are to be treat=
ed symmetrically.</p>
<h2>Protected members</h2>
<p>Can protected member functions be called in pre- and post-conditions? In=
public functions, this makes no sense: the user of the class may not have =
access to protected functions; and it is expected that the user in order to=
verify if a precondition holds should be able to evaluate the condition he=
rself.</p>
<p>On the other hand, protected functions may also need to specify their pr=
econditions as they constitute an interface for deriving classes (which can=
also be considered users), and for them calling other protected members ap=
pears reasonable.</p>
<p>Similarly, it is possible that class's protected interface may assume an=
invariant that is narrower than the class's public interface's invariant. =
Protected members may require less of the program state than the public mem=
bers, but they still may require something. Not suer if this use case is wo=
rth complicating the language.</p>
<h1>Constraining STL</h1>
<p>As a usefulness test, any proposed value constraint framework should be =
checked if it is able to express value constraints in STL. We consider some=
selected examples. We do not insist that a proposed framework should be ab=
le to handle them, but consider it rather a test of expressive power. The g=
oal is to help determine where we want to stop in expressing the semantics =
in the language.</p>=20
<h2>Case 1: a valid range</h2>
<p>This is probably the most difficult one to handle. Nearly any algorithm =
on STL ranges requires that <code>end</code> is reachable from <code>begin<=
/code>. It cannot be validated by executing any expression. This is why it =
is required as a precondition: the caller may have better means of ensuring=
that this requirement is satisfied. For instance, it is obvious that <code=
>c.begin()</code> and <code>c.end()</code> called on any STL container form=
a valid range. Is a value constraints framework capable of expressing that=
the values of <code>c.begin()</code> and <code>c.end()</code> satisfy the =
requirements of, say, <code>std::for_each</code>?</p>
<h2>Case 2: sub-ranges</h2>
Similarly, in the call <code>m =3D std::find_if(b, e, p)</code>, assuming t=
hat <code>b</code> and <code>e</code> form a valid range, can it be verifie=
d or even expressed that <code>b</code> and <code>m</code> as well as <code=
>m</code> and <code>e</code> form valid ranges and that these combinations =
should satisfy the requirement of subsequent STL algorithms about valid ran=
ges?
<h2>Case 3: sorting</h2>
<p>Consider functions <code>sort</code> and <code>binary_search</code> from=
the Standard Library (we consider only the overloads with the predicate). =
The former guarantees that it leaves the range sorted with respect to the g=
iven predicate. The later requires that the range is <em>partitioned</em> w=
ith respect to the given predicate and the given element. Being partitioned=
is something less than being sorted. for instance range {3, 1, 2, 5, 9, 8,=
7} is partitioned with respect to element 5 and <code>operator<</code> =
but is not sorted.<p>
<h2>Solution with properties and axioms</h2>
Below we show how the above task can be solved with sophisticated features =
like properties (described above) and axioms (similar to those described in=
<a href=3D"#N2887">[N2887]</a>).
<h3>Case 1</h3>
<pre>template <typename I>
property bool is_valid_range(I b, I e);
template <typename T>
axiom vec_range(std::vector<T> v)
{
is_valid_range(v.begin(), v.end());
}
template <typename Iter>
void sort(Iter b, Iter e)
precondition{ is_valid_range(b, e); };
=20
vector<int> v =3D {/*...*/};
sort(v.begin(), v.end());
</pre>=20
<h3>Case 2</h3>
<pre>template<typename I, typename V>
I find(I b, I e, V v)
precondition{ is_valid_range(b, e); }
postcondition(f) {
is_valid_range(b, f);
is_valid_range(f, e);
// ... more
};
vecotr<int> v =3D {/*...*/};
auto i =3D find(v.begin(), v.end(), 7); // axiom vec_range
auto j =3D find(i, v.end(), 7); // postcondition of find
</pre>
<h3>Case 3</h3>
<pre>template <typename It, typename T, typename Comp>
bool is_partitioned_for_element(It b, It e, T v, Comp c)
{
return is_partitioned(b, e, [&v](auto&& e) {return cmp(e, v);=
})
&& is_partitioned(b, e, [&v](auto&& e) {return !c=
mp(v, e);})
&& all_of(b, e, [&v](auto&& e) {return !cmp(e, v)=
|| !cmp(v, e);});
}
template <typename It, typename T, typename Comp>
axiom sorted_is_partitioned(It b, It e, T v, Comp cmp)
{
is_sorted(b, e, p) =3D> is_partitioned_for_element(b, e, v, cmp);
}
template <typename Iter, typename Comp>
void sort(Iter b, Iter e, Comp cmp)
postcondition{ is_sorted(b, e, cmp) };
template <typename It, typename T, typename Comp>
bool binary_search(It b, It e, T v, Comp cmp)
precondition{ is_partitioned_for_element(b, e, v, cmp) };
</pre>
<p>Again, we do not propose to standardize the above, but we show that prec=
onditions in STL algorithms are expressible with a sufficiently complex fa=
cility.</p>
=20
<h1>What do we need to standardize?</h1>
<p>The language feature of value constraints can be divided into two main p=
arts. (1) What value constraints we define and how, (2) how do we handle ru=
n-time response to a broken value constraint.</p>
<h2>Defining value constraints</h2>
<p>At this point it is too early to decide on the details, but one thing ap=
pears fairly uncontroversial. Value constraints support needs two accommoda=
te two fairly opposite requirements: (1) no run-time overhead in cases like=
(<code>operator[]</code> for vectors), (2) guaranteed (in certain situati=
ons) evaluation of the predicates (where performance requirement is not cri=
tical).</p>
<p>This calls for the following semantics. If a piece of code that "relies"=
on a value constraint is executed, and its corresponding value constraint =
would return false <em>if it were evaluated</em> (but no evaluation is requ=
ired), the behaviour of the program is undefined. Any value constraint "in =
its proper moment" may be evaluated once or not evaluated -- it is <em>unsp=
ecified</em>. </p>
<h2>Run-time response</h2>
<p>One option is not to standardize what should happen when we detect at ru=
n-time a broken value constraint (whether to throw or terminate or abort or=
ignore), and let the vendors decide how they want to handle these cases. W=
ith this approach a minimum conforming implementation only needs to syntax-=
and type-check the declarations.</p>
<p>It may be useful to standardize a set of [[attributes]] for giving hints=
on what conditions to evaluate value constraints, e.g., "evaluate only if =
<code>T</code> satisfies some requirements", or "this constraint has comple=
xity O(N), evaluate it only when O(N) and bigger complexities are enabled",=
or "never evaluate this".</p>
<h1>Acknowledgements</h1>
<p>Lots of content in this paper is inspired by work in <a href=3D"#N1962">=
[N1962]</a>, <a href=3D"#N2887">[N2887]</a> and <a href=3D"#N3351">[N3351]<=
/a>.</p>
<p>Gabriel Dos Reis suggested the "STL test" for a precondition framework.<=
/p>
<h1>References</h1>
<ul>
<li><a name=3D"ACSL">[ACSL]</a> Patrick Baudin, Pascal Cuoq, Jean-Christoph=
e Filliâtre, Claude Marché, Benjamin Monate, Yannick Moy, Virg=
ile Prevosto, "ACSL: ANSI/ISO C Specification Language" (<a href=3D"http://=
frama-c.com/download/acsl_1.4.pdf">http://frama-c.com/download/acsl_1.4.pdf=
</a>),</li>
<li><a name=3D"N1962">[N1962]</a> Lawrence Crowl, Thorsten Ottosen, "Propos=
al to add Contract Programming to C++ (revision 4)" (<a href=3D"http://www.=
open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1962.html">http://www.open-st=
d.org/jtc1/sc22/wg21/docs/papers/2006/n1962.html</a>),</li>
<li><a name=3D"N2887">[N2887]</a> Gabriel Dos Reis, Bjarne Stroustrup, Alis=
dair Meredith, "Axioms: Semantics Aspects of C++ Concepts" (<a href=3D"http=
://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2887.pdf">http://www.o=
pen-std.org/jtc1/sc22/wg21/docs/papers/2009/n2887.pdf</a>),</li>
<li><a name=3D"N3351">[N3351]</a> Bjarne Stroustrup, Andrew Sutton et al., =
"A Concept Design for the STL" (<a href=3D"http://www.open-std.org/jtc1/sc2=
2/wg21/docs/papers/2012/n3351.pdf">http://www.open-std.org/jtc1/sc22/wg21/d=
ocs/papers/2012/n3351.pdf</a>).</li>
</ul>
</body>
</html>
------=_Part_80_32937670.1404485523485--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 4 Jul 2014 18:01:13 +0300
Raw View
On 4 July 2014 17:52, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com> wrote:
> Hi,
> I wanted to share here my reflections about how C++ could support contrac=
t
> programming (things like preconditions). One alternative to the
> "traditional" design-by-contract is considered.
>
> I share the html document on GitHub, so there is an inconvenience involve=
d:
> you have to see it in raw form, download and then reopen in the browser.
> Here's the link:
>
> https://github.com/akrzemi1/contract/blob/master/contract.html
Tip:
http://htmlpreview.github.io/?https://github.com/akrzemi1/contract/blob/mas=
ter/contract.html
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Fri, 4 Jul 2014 17:02:43 +0200
Raw View
On Fri, Jul 04, 2014 at 07:52:03AM -0700, Andrzej Krzemie??ski wrote:
> Hi,
> I wanted to share here my reflections about how C++ could support contract
> programming (things like preconditions). One alternative to the
> "traditional" design-by-contract is considered.
>
> I share the html document on GitHub, so there is an inconvenience involved:
> you have to see it in raw form, download and then reopen in the browser.
> Here's the link:
>
> https://github.com/akrzemi1/contract/blob/master/contract.html
I have not read this paper throughly but I have two big questions:
How does this relate to N3997?
Why do you stuff properties in this paper instead of in a separate proposal?
/MF
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Fri, 4 Jul 2014 17:11:19 +0200
Raw View
--047d7b4724f8a048c304fd5f89ce
Content-Type: text/plain; charset=UTF-8
On Fri, Jul 4, 2014 at 5:02 PM, Magnus Fromreide <magfr@lysator.liu.se>
wrote:
> How does this relate to N3997?
> Why do you stuff properties in this paper instead of in a separate
> proposal?
>
Note that the Rapperswil minutes[1] says:
Straw poll, LWG Motion 8, Move we adopt N4075 Centralized
Defensive-Programming Support for Narrow Contracts for a future C++ Library
Fundamentals TS
[... discussions & concerns ...]
LWG Motion 8 straw poll results were
In favor: 9 Opposed: 38 Abstain: 12
The motion was removed from the formal motions page.
N4075 is not publicly published yet apparently but it seems obvious that
it's directly related to N3997.
[1] https://isocpp.org/files/papers/N4053.html
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7b4724f8a048c304fd5f89ce
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Fri, Jul 4, 2014 at 5:02 PM, Magnus Fromreide <span dir=3D"ltr"><<a h=
ref=3D"mailto:magfr@lysator.liu.se" target=3D"_blank">magfr@lysator.liu.se<=
/a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div id=3D":2vw" class=3D"" style=3D"overflow:hidden">How =
does this relate to N3997?<br>
Why do you stuff properties in this paper instead of in a separate proposal=
?</div></blockquote></div><br>Note that the Rapperswil minutes[1] says:</di=
v><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><div clas=
s=3D"gmail_extra">
=C2=A0 =C2=A0 Straw poll, LWG Motion 8, Move we adopt N4075 Centralized Def=
ensive-Programming Support for Narrow Contracts for a future C++ Library Fu=
ndamentals TS</div><div class=3D"gmail_extra">=C2=A0 =C2=A0 [... discussion=
s & concerns ...]</div>
<div class=3D"gmail_extra">=C2=A0 =C2=A0 LWG Motion 8 straw poll results we=
re</div><div class=3D"gmail_extra">=C2=A0 =C2=A0 In favor: 9 Opposed: 38 Ab=
stain: 12</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ext=
ra">=C2=A0 =C2=A0 The motion was removed from the formal motions page.</div=
>
</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">N4075=
is not publicly published yet apparently but it seems obvious that it'=
s directly related to N3997.<br></div><div class=3D"gmail_extra"><br></div>=
<div class=3D"gmail_extra">
<br></div><div class=3D"gmail_extra">[1] <a href=3D"https://isocpp.org/file=
s/papers/N4053.html">https://isocpp.org/files/papers/N4053.html</a><br></di=
v><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div=
></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b4724f8a048c304fd5f89ce--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Sat, 5 Jul 2014 07:29:44 -0700 (PDT)
Raw View
------=_Part_1639_8251235.1404570584159
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu pi=C4=85tek, 4 lipca 2014 17:02:46 UTC+2 u=C5=BCytkownik Magnus From=
reide=20
napisa=C5=82:
>
> On Fri, Jul 04, 2014 at 07:52:03AM -0700, Andrzej Krzemie??ski wrote:=20
> > Hi,=20
> > I wanted to share here my reflections about how C++ could support=20
> contract=20
> > programming (things like preconditions). One alternative to the=20
> > "traditional" design-by-contract is considered.=20
> >=20
> > I share the html document on GitHub, so there is an inconvenience=20
> involved:=20
> > you have to see it in raw form, download and then reopen in the browser=
..=20
> > Here's the link:=20
> >=20
> > https://github.com/akrzemi1/contract/blob/master/contract.html=20
>
> I have not read this paper throughly but I have two big questions:=20
>
> How does this relate to N3997?=20
> Why do you stuff properties in this paper instead of in a separate=20
> proposal?=20
>
My paper is not really a proposal. I tried to state certain criteria that a=
=20
contract programming framework should address. I am not proposing the=20
addition of preconditions, axioms and properties. I am just showing how=20
they relate to other approaches to contract programming, and trying to show=
=20
that it is possible to meet the stated criteria.=20
How does my paper relate to N3997? I state certain design goals and N3997=
=20
does not meet them. N3997 proposes a more "imperative" approach. A=20
precondition declaration means that something must be executed under=20
certain configuration. I tried to promote a different philosophy:=20
preconditions are more for static analysis. Also, in N3997pre- and post-=20
conditions are not part of function's declaration, but something in the=20
function body -- invisible to the users. I disagree with this. I believe=20
that preconditions are part of functions interface.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1639_8251235.1404570584159
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>W dniu pi=C4=85tek, 4 lipca 2014 17:02:46 UTC+2 u=
=C5=BCytkownik Magnus Fromreide napisa=C5=82:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;">On Fri, Jul 04, 2014 at 07:52:03AM -0700, Andrzej Krzemie??s=
ki wrote:
<br>> Hi,
<br>> I wanted to share here my reflections about how C++ could support =
contract=20
<br>> programming (things like preconditions). One alternative to the=20
<br>> "traditional" design-by-contract is considered.=20
<br>>=20
<br>> I share the html document on GitHub, so there is an inconvenience =
involved:=20
<br>> you have to see it in raw form, download and then reopen in the br=
owser.=20
<br>> Here's the link:
<br>>=20
<br>> <a href=3D"https://github.com/akrzemi1/contract/blob/master/contra=
ct.html" target=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.c=
om/url?q\75https%3A%2F%2Fgithub.com%2Fakrzemi1%2Fcontract%2Fblob%2Fmaster%2=
Fcontract.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHiEbEG56eA0aJru-IMVfA1A15=
-QA';return true;" onclick=3D"this.href=3D'https://www.google.com/url?q\75h=
ttps%3A%2F%2Fgithub.com%2Fakrzemi1%2Fcontract%2Fblob%2Fmaster%2Fcontract.ht=
ml\46sa\75D\46sntz\0751\46usg\75AFQjCNHiEbEG56eA0aJru-IMVfA1A15-QA';return =
true;">https://github.com/akrzemi1/<wbr>contract/blob/master/contract.<wbr>=
html</a>
<br>
<br>I have not read this paper throughly but I have two big questions:
<br>
<br>How does this relate to N3997?
<br>Why do you stuff properties in this paper instead of in a separate prop=
osal?
<br></blockquote><div><br>My paper is not really a proposal. I tried to sta=
te certain criteria that a contract programming framework should address. I=
am not proposing the addition of preconditions, axioms and properties. I a=
m just showing how they relate to other approaches to contract programming,=
and trying to show that it is possible to meet the stated criteria. <br><b=
r>How does my paper relate to N3997? I state certain design goals and N3997=
does not meet them. N3997 proposes a more "imperative" approach. A precond=
ition declaration means that something must be executed under certain confi=
guration. I tried to promote a different philosophy: preconditions are more=
for static analysis. Also, in N3997pre- and post- conditions are not part =
of function's declaration, but something in the function body -- invisible =
to the users. I disagree with this. I believe that preconditions are part o=
f functions interface.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1639_8251235.1404570584159--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Sat, 5 Jul 2014 07:31:06 -0700 (PDT)
Raw View
------=_Part_1705_8372016.1404570666934
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu pi=C4=85tek, 4 lipca 2014 17:01:15 UTC+2 u=C5=BCytkownik Ville Vouti=
lainen=20
napisa=C5=82:
>
> On 4 July 2014 17:52, Andrzej Krzemie=C5=84ski <akrz...@gmail.com <javasc=
ript:>>=20
> wrote:=20
> > Hi,=20
> > I wanted to share here my reflections about how C++ could support=20
> contract=20
> > programming (things like preconditions). One alternative to the=20
> > "traditional" design-by-contract is considered.=20
> >=20
> > I share the html document on GitHub, so there is an inconvenience=20
> involved:=20
> > you have to see it in raw form, download and then reopen in the browser=
..=20
> > Here's the link:=20
> >=20
> > https://github.com/akrzemi1/contract/blob/master/contract.html=20
>
> Tip:=20
>
> http://htmlpreview.github.io/?https://github.com/akrzemi1/contract/blob/m=
aster/contract.html=20
>
Thank you. I missed such a tool for a long while.=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1705_8372016.1404570666934
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>W dniu pi=C4=85tek, 4 lipca 2014 17:01:15 UTC+2 u=
=C5=BCytkownik Ville Voutilainen napisa=C5=82:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">On 4 July 2014 17:52, Andrzej Krzemie=C5=84ski <<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"GQU3VZiDYo0J" o=
nmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">akrz...@gmail.com</a>> wrote:
<br>> Hi,
<br>> I wanted to share here my reflections about how C++ could support =
contract
<br>> programming (things like preconditions). One alternative to the
<br>> "traditional" design-by-contract is considered.
<br>>
<br>> I share the html document on GitHub, so there is an inconvenience =
involved:
<br>> you have to see it in raw form, download and then reopen in the br=
owser.
<br>> Here's the link:
<br>>
<br>> <a href=3D"https://github.com/akrzemi1/contract/blob/master/contra=
ct.html" target=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.c=
om/url?q\75https%3A%2F%2Fgithub.com%2Fakrzemi1%2Fcontract%2Fblob%2Fmaster%2=
Fcontract.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHiEbEG56eA0aJru-IMVfA1A15=
-QA';return true;" onclick=3D"this.href=3D'https://www.google.com/url?q\75h=
ttps%3A%2F%2Fgithub.com%2Fakrzemi1%2Fcontract%2Fblob%2Fmaster%2Fcontract.ht=
ml\46sa\75D\46sntz\0751\46usg\75AFQjCNHiEbEG56eA0aJru-IMVfA1A15-QA';return =
true;">https://github.com/akrzemi1/<wbr>contract/blob/master/contract.<wbr>=
html</a>
<br>
<br>Tip:
<br><a href=3D"http://htmlpreview.github.io/?https://github.com/akrzemi1/co=
ntract/blob/master/contract.html" target=3D"_blank" onmousedown=3D"this.hre=
f=3D'http://www.google.com/url?q\75http%3A%2F%2Fhtmlpreview.github.io%2F%3F=
https%3A%2F%2Fgithub.com%2Fakrzemi1%2Fcontract%2Fblob%2Fmaster%2Fcontract.h=
tml\46sa\75D\46sntz\0751\46usg\75AFQjCNHBmDQIhe5kCYyrKrgVbEL0d9lQXA';return=
true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2F=
htmlpreview.github.io%2F%3Fhttps%3A%2F%2Fgithub.com%2Fakrzemi1%2Fcontract%2=
Fblob%2Fmaster%2Fcontract.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHBmDQIhe5=
kCYyrKrgVbEL0d9lQXA';return true;">http://htmlpreview.github.io/?<wbr>https=
://github.com/akrzemi1/<wbr>contract/blob/master/contract.<wbr>html</a>
<br></blockquote><div><br>Thank you. I missed such a tool for a long while.=
<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1705_8372016.1404570666934--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Tue, 8 Jul 2014 01:07:37 +0200
Raw View
--089e0122efac87e5d004fda28a49
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
This paper have just been posted on isocpp.org:
https://isocpp.org/files/papers/N4110.pdf
It looks a lot like your paper (but I didn't read it completely yet).
On Sat, Jul 5, 2014 at 4:31 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.co=
m>
wrote:
>
>
> W dniu pi=C4=85tek, 4 lipca 2014 17:01:15 UTC+2 u=C5=BCytkownik Ville Vou=
tilainen
> napisa=C5=82:
>
>> On 4 July 2014 17:52, Andrzej Krzemie=C5=84ski <akrz...@gmail.com> wrote=
:
>> > Hi,
>> > I wanted to share here my reflections about how C++ could support
>> contract
>> > programming (things like preconditions). One alternative to the
>> > "traditional" design-by-contract is considered.
>> >
>> > I share the html document on GitHub, so there is an inconvenience
>> involved:
>> > you have to see it in raw form, download and then reopen in the
>> browser.
>> > Here's the link:
>> >
>> > https://github.com/akrzemi1/contract/blob/master/contract.html
>>
>> Tip:
>> http://htmlpreview.github.io/?https://github.com/akrzemi1/
>> contract/blob/master/contract.html
>>
>
> Thank you. I missed such a tool for a long while.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--089e0122efac87e5d004fda28a49
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This paper have just been posted on <a href=3D"http://isoc=
pp.org">isocpp.org</a>:=C2=A0<a href=3D"https://isocpp.org/files/papers/N41=
10.pdf">https://isocpp.org/files/papers/N4110.pdf</a><br><br>It looks a lot=
like your paper (but I didn't read it completely yet).</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat, Jul 5=
, 2014 at 4:31 PM, Andrzej Krzemie=C5=84ski <span dir=3D"ltr"><<a href=
=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@gmail.com</a>>=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>W dniu pi=C4=85tek,=
4 lipca 2014 17:01:15 UTC+2 u=C5=BCytkownik Ville Voutilainen napisa=C5=82=
:<div class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
On 4 July 2014 17:52, Andrzej Krzemie=C5=84ski <<a>akrz...@gmail.com</a>=
> wrote:
<br>> Hi,
<br>> I wanted to share here my reflections about how C++ could support =
contract
<br>> programming (things like preconditions). One alternative to the
<br>> "traditional" design-by-contract is considered.
<br>>
<br>> I share the html document on GitHub, so there is an inconvenience =
involved:
<br>> you have to see it in raw form, download and then reopen in the br=
owser.
<br>> Here's the link:
<br>>
<br>> <a href=3D"https://github.com/akrzemi1/contract/blob/master/contra=
ct.html" target=3D"_blank">https://github.com/akrzemi1/<u></u>contract/blob=
/master/contract.<u></u>html</a>
<br>
<br>Tip:
<br><a href=3D"http://htmlpreview.github.io/?https://github.com/akrzemi1/co=
ntract/blob/master/contract.html" target=3D"_blank">http://htmlpreview.gith=
ub.io/?<u></u>https://github.com/akrzemi1/<u></u>contract/blob/master/contr=
act.<u></u>html</a>
<br></blockquote></div><div><br>Thank you. I missed such a tool for a long =
while. <br></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e0122efac87e5d004fda28a49--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Tue, 8 Jul 2014 18:55:48 +0200
Raw View
--047d7b2e4802a23a0704fdb1762a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Andrzej, one thing I've been wondering while reading your paper (and N4110,
I'm in the middle right now)
is: should contracts have a role in overload resolution and if yes how?
I know it's early to get into specifics but maybe your paper could at least
mention the question?
=E2=80=8B
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--047d7b2e4802a23a0704fdb1762a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Andrzej, one thing I've been wondering while reading y=
our paper (and N4110, I'm in the middle right now)<div>is: should contr=
acts have a role in overload resolution and if yes how?</div><div>I know it=
's early to get into specifics but maybe your paper could at least ment=
ion the question?</div>
<div><br></div>=E2=80=8B</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b2e4802a23a0704fdb1762a--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Tue, 8 Jul 2014 19:05:05 +0200
Raw View
--001a1134cd04da56bd04fdb19769
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Another question: if I understand correctly, the contracts should be part
of the signature of functions?
If so, does it means that you have to write the contract too when you
forward-declare a free function?
If so, does it means that you would be able to check ONLY arguments and
return value for free functions?
On Tue, Jul 8, 2014 at 6:55 PM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.co=
m>
wrote:
> Andrzej, one thing I've been wondering while reading your paper (and
> N4110, I'm in the middle right now)
> is: should contracts have a role in overload resolution and if yes how?
> I know it's early to get into specifics but maybe your paper could at
> least mention the question?
>
> =E2=80=8B
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a1134cd04da56bd04fdb19769
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Another question: if I understand correctly, the contracts=
should be part of the signature of functions?<div>If so, does it means tha=
t you have to write the contract too when you forward-declare a free functi=
on?=C2=A0</div>
<div>If so, does it means that you would be able to check ONLY arguments an=
d return value for free functions?</div></div><div class=3D"gmail_extra"><b=
r><br><div class=3D"gmail_quote">On Tue, Jul 8, 2014 at 6:55 PM, Klaim - Jo=
=C3=ABl Lamotte <span dir=3D"ltr"><<a href=3D"mailto:mjklaim@gmail.com" =
target=3D"_blank">mjklaim@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Andrzej, one thing I've=
been wondering while reading your paper (and N4110, I'm in the middle =
right now)<div>
is: should contracts have a role in overload resolution and if yes how?</di=
v><div>I know it's early to get into specifics but maybe your paper cou=
ld at least mention the question?</div>
<div><br></div>=E2=80=8B</div>
</blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1134cd04da56bd04fdb19769--
.
Author: "J. Daniel Garcia" <josedaniel.garcia@uc3m.es>
Date: Tue, 8 Jul 2014 22:12:03 +0200
Raw View
--20cf301cc0c8dff3b004fdb43681
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Overloading is a compile-time feature.
Let's consider the following:
void f(int x) expects(x=3D0) {
handle_zero(x);
}
void f(int x) expects(x!=3D0) {
handle_non_zero(x)
}
void g() {
int x =3D some_function();
f(x);
}
Overloading on preconditions would mean that preconditions can be evaluated
at compile-time and this not the case. So, overloading on preconditions
does not seem feasible.
Please, also note that N4110 leaves compile-time preconditions as
out-of-scope and points out that they could be handled better as part of a
future extension of conecepts TS.
--
J. Daniel
On Tue, Jul 8, 2014 at 6:55 PM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.co=
m>
wrote:
> Andrzej, one thing I've been wondering while reading your paper (and
> N4110, I'm in the middle right now)
> is: should contracts have a role in overload resolution and if yes how?
> I know it's early to get into specifics but maybe your paper could at
> least mention the question?
>
> =E2=80=8B
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--20cf301cc0c8dff3b004fdb43681
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Overloading is a compile-time feature.<div><br></div><div>=
Let's consider the following:</div><div><br></div><div>void f(int x) ex=
pects(x=3D0) {</div><div>=C2=A0 handle_zero(x);</div><div>}</div><div>void =
f(int x) expects(x!=3D0) {</div>
<div>=C2=A0 handle_non_zero(x)</div><div>}</div><div><br></div><div>void g(=
) {</div><div>=C2=A0 int x =3D some_function();</div><div>=C2=A0 f(x);</div=
><div>}</div><div><br></div><div>Overloading on preconditions would mean th=
at preconditions can be evaluated at compile-time and this not the case. So=
, overloading on preconditions does not seem feasible.</div>
<div><br></div><div>Please, also note that N4110 leaves compile-time precon=
ditions as out-of-scope and points out that they could be handled better as=
part of a future extension of conecepts TS.</div><div>--</div><div>=C2=A0 =
J. Daniel</div>
<div><br></div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=
=3D"ltr"><br></div></div><div class=3D"gmail_quote">On Tue, Jul 8, 2014 at =
6:55 PM, Klaim - Jo=C3=ABl Lamotte <span dir=3D"ltr"><<a href=3D"mailto:=
mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.com</a>></span> wrote=
:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Andrzej, one thing I've=
been wondering while reading your paper (and N4110, I'm in the middle =
right now)<div>
is: should contracts have a role in overload resolution and if yes how?</di=
v><div>I know it's early to get into specifics but maybe your paper cou=
ld at least mention the question?</div>
<div><br></div>=E2=80=8B</div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--20cf301cc0c8dff3b004fdb43681--
.
Author: "J. Daniel Garcia" <josedaniel.garcia@uc3m.es>
Date: Tue, 8 Jul 2014 22:17:21 +0200
Raw View
--20cf301cc0c8dd8d0304fdb4495d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
There are pros and cons on adding contracts to the type of a function.
N4110 does not take a clear position on this issue.
In any case a function contract is part of its interface specification.
However, take note that global state is also accessible from contract
checks.
On Tue, Jul 8, 2014 at 7:05 PM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.co=
m>
wrote:
> Another question: if I understand correctly, the contracts should be part
> of the signature of functions?
> If so, does it means that you have to write the contract too when you
> forward-declare a free function?
> If so, does it means that you would be able to check ONLY arguments and
> return value for free functions?
>
>
> On Tue, Jul 8, 2014 at 6:55 PM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.=
com>
> wrote:
>
>> Andrzej, one thing I've been wondering while reading your paper (and
>> N4110, I'm in the middle right now)
>> is: should contracts have a role in overload resolution and if yes how?
>> I know it's early to get into specifics but maybe your paper could at
>> least mention the question?
>>
>> =E2=80=8B
>>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--20cf301cc0c8dd8d0304fdb4495d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">There are pros and cons on adding contracts to the type of=
a function. N4110 does not take a clear position on this issue.<div><br></=
div><div>In any case a function contract is part of its interface specifica=
tion. However, take note that global state is also accessible from contract=
checks.<br>
<div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><br></di=
v></div><div class=3D"gmail_quote">On Tue, Jul 8, 2014 at 7:05 PM, Klaim - =
Jo=C3=ABl Lamotte <span dir=3D"ltr"><<a href=3D"mailto:mjklaim@gmail.com=
" target=3D"_blank">mjklaim@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Another question: if I unde=
rstand correctly, the contracts should be part of the signature of function=
s?<div>
If so, does it means that you have to write the contract too when you forwa=
rd-declare a free function?=C2=A0</div>
<div>If so, does it means that you would be able to check ONLY arguments an=
d return value for free functions?</div></div><div class=3D"HOEnZb"><div cl=
ass=3D"h5"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On=
Tue, Jul 8, 2014 at 6:55 PM, Klaim - Jo=C3=ABl Lamotte <span dir=3D"ltr">&=
lt;<a href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.com=
</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Andrzej, one thing I've=
been wondering while reading your paper (and N4110, I'm in the middle =
right now)<div>
is: should contracts have a role in overload resolution and if yes how?</di=
v><div>I know it's early to get into specifics but maybe your paper cou=
ld at least mention the question?</div>
<div><br></div>=E2=80=8B</div>
</blockquote></div><br></div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--20cf301cc0c8dd8d0304fdb4495d--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Wed, 9 Jul 2014 01:37:23 +0200
Raw View
--001a11c1f7e2d5bef604fdb712cc
Content-Type: text/plain; charset=UTF-8
On Tue, Jul 8, 2014 at 10:12 PM, J. Daniel Garcia <josedaniel.garcia@uc3m.es
> wrote:
> Overloading on preconditions would mean that preconditions can be
> evaluated at compile-time and this not the case. So, overloading on
> preconditions does not seem feasible.
Indeed, I forgot it was all at run-time. Thanks for the clarification.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c1f7e2d5bef604fdb712cc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Jul 8, 2014 at 10:12 PM, J. Daniel Garcia <span dir=3D"ltr"><<a =
href=3D"mailto:josedaniel.garcia@uc3m.es" target=3D"_blank">josedaniel.garc=
ia@uc3m.es</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Overloading on preconditions would mean that=
preconditions can be evaluated at compile-time and this not the case. So, =
overloading on preconditions does not seem feasible.</blockquote>
</div><br>Indeed, I forgot it was all at run-time. Thanks for the clarifica=
tion.</div><div class=3D"gmail_extra"><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c1f7e2d5bef604fdb712cc--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Wed, 9 Jul 2014 01:38:57 +0200
Raw View
--001a11c20afa6bad3404fdb71814
Content-Type: text/plain; charset=UTF-8
On Tue, Jul 8, 2014 at 10:17 PM, J. Daniel Garcia <josedaniel.garcia@uc3m.es
> wrote:
> However, take note that global state is also accessible from contract
> checks.
I note that it would also prevent types using the pimpl idiom to use
contracts checking on internal data too.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c20afa6bad3404fdb71814
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Jul 8, 2014 at 10:17 PM, J. Daniel Garcia <span dir=3D"ltr"><<a =
href=3D"mailto:josedaniel.garcia@uc3m.es" target=3D"_blank">josedaniel.garc=
ia@uc3m.es</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">However, take note that global state is also=
accessible from contract checks.</blockquote></div><br>I note that it woul=
d also prevent types using the pimpl idiom to use contracts checking on int=
ernal data too.</div>
<div class=3D"gmail_extra"><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c20afa6bad3404fdb71814--
.
Author: "J. Daniel Garcia" <josedaniel.garcia@uc3m.es>
Date: Wed, 9 Jul 2014 09:04:58 +0200
Raw View
--047d7b10cfedea871c04fdbd5581
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I am not quite sure of that assertion. Note that contracts may include
evaluation of boolean free functions and member functions.
Could you provide an example of why we are preventing this?
On Wed, Jul 9, 2014 at 1:38 AM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.co=
m>
wrote:
>
> On Tue, Jul 8, 2014 at 10:17 PM, J. Daniel Garcia <
> josedaniel.garcia@uc3m.es> wrote:
>
>> However, take note that global state is also accessible from contract
>> checks.
>
>
> I note that it would also prevent types using the pimpl idiom to use
> contracts checking on internal data too.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--047d7b10cfedea871c04fdbd5581
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">I am not quite sure of that ass=
ertion. Note that contracts may include evaluation of boolean free function=
s and member functions.</div><div class=3D"gmail_extra"><br></div><div clas=
s=3D"gmail_extra">
Could you provide an example of why we are preventing this?</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On Wed, Jul 9, 2014 at 1:38 AM, Klaim - Jo=C3=ABl Lamotte <span d=
ir=3D"ltr"><<a href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjkla=
im@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D""><br><div class=3D"gmail_quote">On Tue, Jul 8, 2014 at 10:17=
PM, J. Daniel Garcia <span dir=3D"ltr"><<a href=3D"mailto:josedaniel.ga=
rcia@uc3m.es" target=3D"_blank">josedaniel.garcia@uc3m.es</a>></span> wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">However, take note that global state is also=
accessible from contract checks.</blockquote></div><br></div>I note that i=
t would also prevent types using the pimpl idiom to use contracts checking =
on internal data too.</div>
<div class=3D"gmail_extra"><br></div></div><div class=3D"HOEnZb"><div class=
=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b10cfedea871c04fdbd5581--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Wed, 9 Jul 2014 10:15:41 +0200
Raw View
--047d7b2e480263c5b004fdbe50ea
Content-Type: text/plain; charset=UTF-8
On Wed, Jul 9, 2014 at 9:04 AM, J. Daniel Garcia <josedaniel.garcia@uc3m.es>
wrote:
> I am not quite sure of that assertion. Note that contracts may include
> evaluation of boolean free functions and member functions.
>
> Could you provide an example of why we are preventing this?
>
It seems that you are right, using private member functions seems to solve
the issue.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7b2e480263c5b004fdbe50ea
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, Jul 9, 2014 at 9:04 AM, J. Daniel Garcia <span dir=3D"ltr"><<a h=
ref=3D"mailto:josedaniel.garcia@uc3m.es" target=3D"_blank">josedaniel.garci=
a@uc3m.es</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"gmail_extra">I am not quite su=
re of that assertion. Note that contracts may include evaluation of boolean=
free functions and member functions.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">
Could you provide an example of why we are preventing this?</div><div class=
=3D"yj6qo ajU"><div id=3D":21l" class=3D"ajR" tabindex=3D"0"><img class=3D"=
ajT" src=3D"//ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif"></div><=
/div></blockquote>
</div><br>It seems that you are right, using private member functions seems=
to solve the issue.</div><div class=3D"gmail_extra"><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b2e480263c5b004fdbe50ea--
.
Author: Andrzej Krzemienski <akrzemi1@gmail.com>
Date: Wed, 9 Jul 2014 10:24:19 +0200
Raw View
--f46d043c80724f859804fdbe6f22
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
2014-07-08 19:05 GMT+02:00 Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.com>:
> Another question: if I understand correctly, the contracts should be part
> of the signature of functions?
>
Yes but; one of the options is that they are declared as attributes, I am
not sure if it counts as part of function's signature.
> If so, does it means that you have to write the contract too when you
> forward-declare a free function?
>
Typically you would declare a function in a header file and define it in a
cpp file. In that case you would want to put contract declarations in a
header file, when you forward declare a function.
> If so, does it means that you would be able to check ONLY arguments and
> return value for free functions?
>
For member functions too, I guess. They are like other functions. Sometimes
you declare and define them in one go, but you can still put a contract
declaration in there.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--f46d043c80724f859804fdbe6f22
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">2014-07-08 19:05 GMT+02:00 Klaim - Jo=C3=ABl Lamotte <span dir=3D"l=
tr"><<a href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmai=
l.com</a>></span>:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Another question: if I unde=
rstand correctly, the contracts should be part of the signature of function=
s?</div>
</blockquote><div><br></div><div>Yes but; one of the options is that they a=
re declared as attributes, I am not sure if it counts as part of function&#=
39;s signature.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>If so, does it means that you have to write the contr=
act too when you forward-declare a free function?=C2=A0</div></div></blockq=
uote><div><br></div><div>Typically you would declare a function in a header=
file and define it in a cpp file. In that case you would want to put contr=
act declarations in a header file, when you forward declare a function.<br>
=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">
<div>If so, does it means that you would be able to check ONLY arguments an=
d return value for free functions?</div></div></blockquote><div><br></div><=
div>For member functions too, I guess. They are like other functions. Somet=
imes you declare and define them in one go, but you can still put a contrac=
t declaration in there.<br>
</div><div><br>=C2=A0</div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--f46d043c80724f859804fdbe6f22--
.
Author: "J. Daniel Garcia" <josedaniel.garcia@uc3m.es>
Date: Wed, 9 Jul 2014 10:32:34 +0200
Raw View
--20cf301cc0c82c08e804fdbe8f7d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Jul 9, 2014 at 10:24 AM, Andrzej Krzemienski <akrzemi1@gmail.com>
wrote:
>
>
>
> 2014-07-08 19:05 GMT+02:00 Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.com>:
>
> Another question: if I understand correctly, the contracts should be part
>> of the signature of functions?
>>
>
> Yes but; one of the options is that they are declared as attributes, I am
> not sure if it counts as part of function's signature.
>
Attributes are quite arguable here. Attributes should not have semantic
effects. However a contract violation checking MAY have semantic effects
>
>
>> If so, does it means that you have to write the contract too when you
>> forward-declare a free function?
>>
>
> Typically you would declare a function in a header file and define it in =
a
> cpp file. In that case you would want to put contract declarations in a
> header file, when you forward declare a function.
>
You will want to put the contract in the declaration as it is part of the
function interface.
One question here is if all declarations corresponding to the same functio
need to have the same contract. i.e should the following be valid code?
int f(int x);
int f(int x)
expects(x>0);
int f(int x)
expects(x>0)
ensures(x>0).
int f(int x) {
return x*2;
}
>
>
>> If so, does it means that you would be able to check ONLY arguments and
>> return value for free functions?
>>
>
> For member functions too, I guess. They are like other functions.
> Sometimes you declare and define them in one go, but you can still put a
> contract declaration in there.
>
Sure. You should be able to do so. However as I said previously global
state (including thread_locals) should be accessible there.
>
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--20cf301cc0c82c08e804fdbe8f7d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Jul 9, 2014 at 10:24 AM, Andrzej Krzemienski <span dir=3D"ltr"><<a h=
ref=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@gmail.com</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote">2014-07-08 19:05 GMT+02:00 Klaim - J=
o=C3=ABl Lamotte <span dir=3D"ltr"><<a href=3D"mailto:mjklaim@gmail.com"=
target=3D"_blank">mjklaim@gmail.com</a>></span>:<div class=3D"">
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Another question: if I unde=
rstand correctly, the contracts should be part of the signature of function=
s?</div>
</blockquote><div><br></div></div><div>Yes but; one of the options is that =
they are declared as attributes, I am not sure if it counts as part of func=
tion's signature.<br></div></div></div></div></blockquote><div><br>
</div><div>Attributes are quite arguable here. Attributes should not have s=
emantic effects. However a contract violation checking MAY have semantic ef=
fects</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>=C2=A0<br></div><div class=3D""><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>If so, does it means that you have to write the contr=
act too when you forward-declare a free function?=C2=A0</div></div></blockq=
uote><div><br></div></div><div>Typically you would declare a function in a =
header file and define it in a cpp file. In that case you would want to put=
contract declarations in a header file, when you forward declare a functio=
n.<br>
</div></div></div></div></blockquote><div><br></div><div>You will want to p=
ut the contract in the declaration as it is part of the function interface.=
</div><div><br></div><div>One question here is if all declarations correspo=
nding to the same functio need to have the same contract. i.e should the fo=
llowing be valid code?</div>
<div><br></div><div>int f(int x);</div><div><br></div><div>int f(int x)</di=
v><div>=C2=A0 expects(x>0);</div><div><br></div><div>int f(int x)=C2=A0<=
/div><div>=C2=A0 expects(x>0)=C2=A0</div><div>=C2=A0 ensures(x>0).</d=
iv><div><br></div><div>
int f(int x) {</div><div>=C2=A0 return x*2;</div><div>}</div><div><br></div=
><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><div class=3D"gmail_extra">
<div class=3D"gmail_quote"><div>
=C2=A0<br></div><div class=3D""><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr">
<div>If so, does it means that you would be able to check ONLY arguments an=
d return value for free functions?</div></div></blockquote><div><br></div><=
/div><div>For member functions too, I guess. They are like other functions.=
Sometimes you declare and define them in one go, but you can still put a c=
ontract declaration in there.<br>
</div></div></div></div></blockquote><div><br></div><div>Sure. You should b=
e able to do so. However as I said previously global state (including threa=
d_locals) should be accessible there.</div><div><br></div><div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>
</div><div><br>=C2=A0</div></div><br></div></div><div class=3D"HOEnZb"><div=
class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--20cf301cc0c82c08e804fdbe8f7d--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Wed, 9 Jul 2014 01:59:44 -0700 (PDT)
Raw View
------=_Part_89_2745534.1404896384615
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
J. Daniel, I have just learned about your paper. I am about to read it. I=
=20
am glad that the subject is being pursued.
W dniu =C5=9Broda, 9 lipca 2014 10:33:15 UTC+2 u=C5=BCytkownik J. Daniel Ga=
rcia=20
napisa=C5=82:
>
> On Wed, Jul 9, 2014 at 10:24 AM, Andrzej Krzemienski <akrz...@gmail.com=
=20
> <javascript:>> wrote:
>
>>
>>
>>
>> 2014-07-08 19:05 GMT+02:00 Klaim - Jo=C3=ABl Lamotte <mjk...@gmail.com=
=20
>> <javascript:>>:
>>
>> Another question: if I understand correctly, the contracts should be par=
t=20
>>> of the signature of functions?
>>>
>>
>> Yes but; one of the options is that they are declared as attributes, I a=
m=20
>> not sure if it counts as part of function's signature.
>>
>
> Attributes are quite arguable here. Attributes should not have semantic=
=20
> effects. However a contract violation checking MAY have semantic effects
>
I agree that using attributes implies no semantic effects. I am convinced=
=20
that the semantics of evaluating preconditions before functions and=20
postconditions after functions is not the only (and not even the most=20
important) use of pre- and post- condition declarations. As an alternative,=
=20
they can be used for static analysis and the generation of warning=20
messages, and code optimizations.
My ideal is that we first decide what semantics we expect of these=20
correctness declarations: (1) run-time (call precondition before function)=
=20
or (2) compile-time (compiler warnings). My choice isn't that obvious in=20
favour of evaluating preconditions at run-time. Once we decide on this, we=
=20
can decide on how we want to represent the correctness declarations. If we=
=20
decide on (2), [[attributes]] come as a natural choice.=20
=20
> =20
>
>> =20
>>
>>> If so, does it means that you have to write the contract too when you=
=20
>>> forward-declare a free function?=20
>>>
>>
>> Typically you would declare a function in a header file and define it in=
=20
>> a cpp file. In that case you would want to put contract declarations in =
a=20
>> header file, when you forward declare a function.
>>
>
> You will want to put the contract in the declaration as it is part of the=
=20
> function interface.
>
> One question here is if all declarations corresponding to the same functi=
o=20
> need to have the same contract. i.e should the following be valid code?
>
> int f(int x);
>
> int f(int x)
> expects(x>0);
>
> int f(int x)=20
> expects(x>0)=20
> ensures(x>0).
>
> int f(int x) {
> return x*2;
> }
>
>
a similar problem was already solved for default function argument=20
declarations, auto type deduction for functions, inline, so we can just=20
copy from the existing solutions. At this point I guess it is of little=20
priority. I agree that correctness declarations are part of function=20
declaration (regardless of whether they affect function signature or=20
overload resolution mechanism or not.)
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_89_2745534.1404896384615
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>J. Daniel, I have just learned about your paper. I am =
about to read it. I am glad that the subject is being pursued.<br><br>W dni=
u =C5=9Broda, 9 lipca 2014 10:33:15 UTC+2 u=C5=BCytkownik J. Daniel Garcia =
napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote">On Wed, Jul 9, 2014 at 10:24 AM, Andrzej Kr=
zemienski <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"EtCEF3GuGB8J" onmousedown=3D"this.href=3D'javascrip=
t:';return true;" onclick=3D"this.href=3D'javascript:';return true;">akrz..=
..@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div><br><br><div class=
=3D"gmail_quote">2014-07-08 19:05 GMT+02:00 Klaim - Jo=C3=ABl Lamotte <span=
dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"EtCEF3GuGB8J" onmousedown=3D"this.href=3D'javascript:';return true=
;" onclick=3D"this.href=3D'javascript:';return true;">mjk...@gmail.com</a>&=
gt;</span>:<div>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Another question: if I unde=
rstand correctly, the contracts should be part of the signature of function=
s?</div>
</blockquote><div><br></div></div><div>Yes but; one of the options is that =
they are declared as attributes, I am not sure if it counts as part of func=
tion's signature.<br></div></div></div></div></blockquote><div><br>
</div><div>Attributes are quite arguable here. Attributes should not have s=
emantic effects. However a contract violation checking MAY have semantic ef=
fects</div></div></div></div></blockquote><div><br>I agree that using attri=
butes implies no semantic effects. I am convinced that the semantics of eva=
luating preconditions before functions and postconditions after functions i=
s not the only (and not even the most important) use of pre- and post- cond=
ition declarations. As an alternative, they can be used for static analysis=
and the generation of warning messages, and code optimizations.<br><br>My =
ideal is that we first decide what semantics we expect of these corre=
ctness declarations: (1) run-time (call precondition before function) or (2=
) compile-time (compiler warnings). My choice isn't that obvious in favour =
of evaluating preconditions at run-time. Once we decide on this, we can dec=
ide on how we want to represent the correctness declarations. If we decide =
on (2), [[attributes]] come as a natural choice. <br> <br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"=
gmail_quote"><div> </div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div> <br></div><div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>If so, does it means that you have to write the contr=
act too when you forward-declare a free function? </div></div></blockq=
uote><div><br></div></div><div>Typically you would declare a function in a =
header file and define it in a cpp file. In that case you would want to put=
contract declarations in a header file, when you forward declare a functio=
n.<br>
</div></div></div></div></blockquote><div><br></div><div>You will want to p=
ut the contract in the declaration as it is part of the function interface.=
</div><div><br></div><div>One question here is if all declarations correspo=
nding to the same functio need to have the same contract. i.e should the fo=
llowing be valid code?</div>
<div><br></div><div>int f(int x);</div><div><br></div><div>int f(int x)</di=
v><div> expects(x>0);</div><div><br></div><div>int f(int x) <=
/div><div> expects(x>0) </div><div> ensures(x>0).</d=
iv><div><br></div><div>
int f(int x) {</div><div> return x*2;</div><div>}</div><div><br></div=
></div></div></div></blockquote><div><br>a similar problem was already solv=
ed for default function argument declarations, auto type deduction for func=
tions, inline, so we can just copy from the existing solutions. At this poi=
nt I guess it is of little priority. I agree that correctness declarations =
are part of function declaration (regardless of whether they affect functio=
n signature or overload resolution mechanism or not.)<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_89_2745534.1404896384615--
.
Author: "J. Daniel Garcia" <josedaniel.garcia@uc3m.es>
Date: Wed, 9 Jul 2014 11:19:13 +0200
Raw View
--90e6ba21234706e39b04fdbf36eb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Jul 9, 2014 at 10:59 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om>
wrote:
>
> J. Daniel, I have just learned about your paper. I am about to read it. I
> am glad that the subject is being pursued.
>
> W dniu =C5=9Broda, 9 lipca 2014 10:33:15 UTC+2 u=C5=BCytkownik J. Daniel =
Garcia
> napisa=C5=82:
>>
>> On Wed, Jul 9, 2014 at 10:24 AM, Andrzej Krzemienski <akrz...@gmail.com>
>> wrote:
>>
>>>
>>>
>>>
>>> 2014-07-08 19:05 GMT+02:00 Klaim - Jo=C3=ABl Lamotte <mjk...@gmail.com>=
:
>>>
>>> Another question: if I understand correctly, the contracts should be
>>>> part of the signature of functions?
>>>>
>>>
>>> Yes but; one of the options is that they are declared as attributes, I
>>> am not sure if it counts as part of function's signature.
>>>
>>
>> Attributes are quite arguable here. Attributes should not have semantic
>> effects. However a contract violation checking MAY have semantic effects
>>
>
> I agree that using attributes implies no semantic effects. I am convinced
> that the semantics of evaluating preconditions before functions and
> postconditions after functions is not the only (and not even the most
> important) use of pre- and post- condition declarations. As an alternativ=
e,
> they can be used for static analysis and the generation of warning
> messages, and code optimizations.
>
Yes. This are important uses. However, non of them seem a reason to favour
attributes.
>
> My ideal is that we first decide what semantics we expect of these
> correctness declarations: (1) run-time (call precondition before function=
)
> or (2) compile-time (compiler warnings). My choice isn't that obvious in
> favour of evaluating preconditions at run-time. Once we decide on this, w=
e
> can decide on how we want to represent the correctness declarations. If w=
e
> decide on (2), [[attributes]] come as a natural choice.
>
Yes. Representation is secondary.
In general, it is unlikely that every assert may be checked at
compile-time. Thus, I feel inclined towards run-time checking. However, the
compiler should be free of removing checks for those cases where it can be
prooved that the assertion never fails.
>
>
>>
>>
>>>
>>>
>>>> If so, does it means that you have to write the contract too when you
>>>> forward-declare a free function?
>>>>
>>>
>>> Typically you would declare a function in a header file and define it i=
n
>>> a cpp file. In that case you would want to put contract declarations in=
a
>>> header file, when you forward declare a function.
>>>
>>
>> You will want to put the contract in the declaration as it is part of th=
e
>> function interface.
>>
>> One question here is if all declarations corresponding to the same
>> functio need to have the same contract. i.e should the following be vali=
d
>> code?
>>
>> int f(int x);
>>
>> int f(int x)
>> expects(x>0);
>>
>> int f(int x)
>> expects(x>0)
>> ensures(x>0).
>>
>> int f(int x) {
>> return x*2;
>> }
>>
>>
> a similar problem was already solved for default function argument
> declarations, auto type deduction for functions, inline, so we can just
> copy from the existing solutions. At this point I guess it is of little
> priority. I agree that correctness declarations are part of function
> declaration (regardless of whether they affect function signature or
> overload resolution mechanism or not.)
>
Agreed!
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--90e6ba21234706e39b04fdbf36eb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, Jul 9, 2014 at 10:59 AM, Andrzej Krzemie=C5=84ski <span dir=3D"ltr"=
><<a href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@gmail=
..com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>J. Daniel, I have just =
learned about your paper. I am about to read it. I am glad that the subject=
is being pursued.<br>
<br>W dniu =C5=9Broda, 9 lipca 2014 10:33:15 UTC+2 u=C5=BCytkownik J. Danie=
l Garcia napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote">
On Wed, Jul 9, 2014 at 10:24 AM, Andrzej Krzemienski <span dir=3D"ltr"><=
<a>akrz...@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div><br><br><div class=
=3D"gmail_quote">2014-07-08 19:05 GMT+02:00 Klaim - Jo=C3=ABl Lamotte <span=
dir=3D"ltr"><<a>mjk...@gmail.com</a>></span>:<div class=3D"">
<div>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Another question: if I unde=
rstand correctly, the contracts should be part of the signature of function=
s?</div>
</blockquote><div><br></div></div><div>Yes but; one of the options is that =
they are declared as attributes, I am not sure if it counts as part of func=
tion's signature.<br></div></div></div></div></div></blockquote><div cl=
ass=3D"">
<div><br>
</div><div>Attributes are quite arguable here. Attributes should not have s=
emantic effects. However a contract violation checking MAY have semantic ef=
fects</div></div></div></div></div></blockquote><div><br>I agree that using=
attributes implies no semantic effects. I am convinced that the semantics =
of evaluating preconditions before functions and postconditions after funct=
ions is not the only (and not even the most important) use of pre- and post=
- condition declarations. As an alternative, they can be used for static an=
alysis and the generation of warning messages, and code optimizations.<br>
</div></div></blockquote><div><br></div><div>Yes. This are important uses. =
However, non of them seem a reason to favour attributes.</div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><br>My ideal is that we first decide what semantics w=
e expect of=C2=A0 these correctness declarations: (1) run-time (call precon=
dition before function) or (2) compile-time (compiler warnings). My choice =
isn't that obvious in favour of evaluating preconditions at run-time. O=
nce we decide on this, we can decide on how we want to represent the correc=
tness declarations. If we decide on (2), [[attributes]] come as a natural c=
hoice. <br>
</div></div></blockquote><div><br></div><div>Yes. Representation is seconda=
ry.</div><div><br></div><div>In general, it is unlikely that every assert m=
ay be checked at compile-time. Thus, I feel inclined towards run-time check=
ing. However, the compiler should be free of removing checks for those case=
s where it can be prooved that the assertion never fails.</div>
<div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr"><div>=C2=A0<br></div><div class=3D""><blockquote class=3D"gmail_quote"=
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>=C2=A0<br></div><div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>If so, does it means that you have to write the contr=
act too when you forward-declare a free function?=C2=A0</div></div></blockq=
uote><div><br></div></div><div>Typically you would declare a function in a =
header file and define it in a cpp file. In that case you would want to put=
contract declarations in a header file, when you forward declare a functio=
n.<br>
</div></div></div></div></blockquote><div><br></div><div>You will want to p=
ut the contract in the declaration as it is part of the function interface.=
</div><div><br></div><div>One question here is if all declarations correspo=
nding to the same functio need to have the same contract. i.e should the fo=
llowing be valid code?</div>
<div><br></div><div>int f(int x);</div><div><br></div><div>int f(int x)</di=
v><div>=C2=A0 expects(x>0);</div><div><br></div><div>int f(int x)=C2=A0<=
/div><div>=C2=A0 expects(x>0)=C2=A0</div><div>=C2=A0 ensures(x>0).</d=
iv><div><br></div><div>
int f(int x) {</div><div>=C2=A0 return x*2;</div><div>}</div><div><br></div=
></div></div></div></blockquote></div><div><br>a similar problem was alread=
y solved for default function argument declarations, auto type deduction fo=
r functions, inline, so we can just copy from the existing solutions. At th=
is point I guess it is of little priority. I agree that correctness declara=
tions are part of function declaration (regardless of whether they affect f=
unction signature or overload resolution mechanism or not.)<br>
</div></div></blockquote><div><br></div><div>Agreed!=C2=A0</div><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div></div></div><div class=3D"HOEnZb"=
><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--90e6ba21234706e39b04fdbf36eb--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Wed, 9 Jul 2014 15:09:42 +0200
Raw View
--001a11c20afaeb62d904fdc26bcd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Another=E2=80=8B point was raised few months ago on Boost mailing list, rel=
ative to
the Centralized error checking feature from the related papers:
its often more useful to the user to be able to specify/change error
handling (or not) behaviour for a specific library (or several) rather than
for the whole application.
I have no specific suggestion of how this could be made possible but I
think it's an interesting point to maybe
explore in future papers related to yours (but I guess it's too early to
explore now).
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c20afaeb62d904fdc26bcd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Another=E2=80=8B point was raised few months ago on Boost =
mailing list, relative to the Centralized error checking feature from the r=
elated papers:<div>its often more useful to the user to be able to specify/=
change error handling (or not) behaviour for a specific library (or several=
) rather than for the whole application.</div>
<div>I have no specific suggestion of how this could be made possible but I=
think it's an interesting point to maybe=C2=A0</div><div>explore in fu=
ture papers related to yours (but I guess it's too early to explore now=
).</div>
<div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c20afaeb62d904fdc26bcd--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 9 Jul 2014 21:45:54 +0800
Raw View
On 2014=E2=80=9307=E2=80=9309, at 9:09 PM, Klaim - Jo=C3=ABl Lamotte <mjkla=
im@gmail.com> wrote:
> Another=E2=80=8B point was raised few months ago on Boost mailing list, r=
elative to the Centralized error checking feature from the related papers:
> its often more useful to the user to be able to specify/change error hand=
ling (or not) behaviour for a specific library (or several) rather than for=
the whole application.
> I have no specific suggestion of how this could be made possible but I th=
ink it's an interesting point to maybe=20
> explore in future papers related to yours (but I guess it's too early to =
explore now).
Is there anything to do differently than NDEBUG applied to linked libraries=
, and whatever equivalent library-specific flags that might control debuggi=
ng in inline functions?
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: "J. Daniel Garcia" <josedaniel.garcia@uc3m.es>
Date: Wed, 9 Jul 2014 16:45:02 +0200
Raw View
--20cf303ddd6038c54404fdc3c3bc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I N4110 that the decision of whether checks are performed or not is a
decision from the caller.
Prof. J. Daniel Garcia
Associate Professor - Profesor Titular de Universidad
Computer Architecture Group
University Carlos III of Madrid
Avenida Gregorio Peces-Barba Mart=C3=ADnez, 22
28270 Colmenarejo, Madrid. Spain
Tel: +34 918561316
Fax: +34 91 856 1270
e-mail: josedaniel.garcia@uc3m.es
Web: http://www.arcos.inf.uc3m.es/~jdaniel
Linked-In: http://es.linkedin.com/in/jdanielgarcia
Twitter: http://www.twitter.com/jdgarciauc3m
On Wed, Jul 9, 2014 at 3:45 PM, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9307=E2=80=9309, at 9:09 PM, Klaim - Jo=C3=ABl Lamotte <mjk=
laim@gmail.com> wrote:
>
> > Another=E2=80=8B point was raised few months ago on Boost mailing list,=
relative
> to the Centralized error checking feature from the related papers:
> > its often more useful to the user to be able to specify/change error
> handling (or not) behaviour for a specific library (or several) rather th=
an
> for the whole application.
> > I have no specific suggestion of how this could be made possible but I
> think it's an interesting point to maybe
> > explore in future papers related to yours (but I guess it's too early t=
o
> explore now).
>
> Is there anything to do differently than NDEBUG applied to linked
> libraries, and whatever equivalent library-specific flags that might
> control debugging in inline functions?
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--20cf303ddd6038c54404fdc3c3bc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I N4110 that the decision of whether checks are performed =
or not is a decision from the caller.</div><div class=3D"gmail_extra"><br c=
lear=3D"all"><div><div dir=3D"ltr">Prof. J. Daniel Garcia<br>Associate Prof=
essor - Profesor Titular de Universidad<br>
Computer Architecture Group<br>University Carlos III of Madrid<br>Avenida G=
regorio Peces-Barba Mart=C3=ADnez, 22<br>28270 Colmenarejo, Madrid. Spain<b=
r>Tel: +34 918561316<br>Fax: +34 91 856 1270<br>e-mail: <a href=3D"mailto:j=
osedaniel.garcia@uc3m.es" target=3D"_blank">josedaniel.garcia@uc3m.es</a><b=
r>
Web: <a href=3D"http://www.arcos.inf.uc3m.es/~jdaniel" target=3D"_blank">ht=
tp://www.arcos.inf.uc3m.es/~jdaniel</a><br>=C2=A0<br>Linked-In: <a href=3D"=
http://es.linkedin.com/in/jdanielgarcia" target=3D"_blank">http://es.linked=
in.com/in/jdanielgarcia</a><br>
Twitter:=C2=A0<a href=3D"http://www.twitter.com/jdgarciauc3m" target=3D"_bl=
ank">http://www.twitter.com/jdgarciauc3m</a></div></div>
<br><br><div class=3D"gmail_quote">On Wed, Jul 9, 2014 at 3:45 PM, David Kr=
auss <span dir=3D"ltr"><<a href=3D"mailto:potswa@gmail.com" target=3D"_b=
lank">potswa@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
<div class=3D""><br>
On 2014=E2=80=9307=E2=80=9309, at 9:09 PM, Klaim - Jo=C3=ABl Lamotte <<a=
href=3D"mailto:mjklaim@gmail.com">mjklaim@gmail.com</a>> wrote:<br>
<br>
> Another=E2=80=8B point was raised few months ago on Boost mailing list=
, relative to the Centralized error checking feature from the related paper=
s:<br>
> its often more useful to the user to be able to specify/change error h=
andling (or not) behaviour for a specific library (or several) rather than =
for the whole application.<br>
> I have no specific suggestion of how this could be made possible but I=
think it's an interesting point to maybe<br>
> explore in future papers related to yours (but I guess it's too ea=
rly to explore now).<br>
<br>
</div>Is there anything to do differently than NDEBUG applied to linked lib=
raries, and whatever equivalent library-specific flags that might control d=
ebugging in inline functions?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--20cf303ddd6038c54404fdc3c3bc--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Wed, 9 Jul 2014 17:17:19 +0200
Raw View
--001a11c2f1124c5a7604fdc434f5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Jul 9, 2014 at 3:45 PM, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9307=E2=80=9309, at 9:09 PM, Klaim - Jo=C3=ABl Lamotte <mjk=
laim@gmail.com> wrote:
>
> > Another=E2=80=8B point was raised few months ago on Boost mailing list,=
relative
> to the Centralized error checking feature from the related papers:
> > its often more useful to the user to be able to specify/change error
> handling (or not) behaviour for a specific library (or several) rather th=
an
> for the whole application.
> > I have no specific suggestion of how this could be made possible but I
> think it's an interesting point to maybe
> > explore in future papers related to yours (but I guess it's too early t=
o
> explore now).
>
> Is there anything to do differently than NDEBUG applied to linked
> libraries, and whatever equivalent library-specific flags that might
> control debugging in inline functions?
If we are talking about a decision taken at runtime, then yes it's totally
different.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c2f1124c5a7604fdc434f5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, Jul 9, 2014 at 3:45 PM, David Krauss <span dir=3D"ltr"><<a href=
=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>></sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb adM"><div class=3D"h5">=
<br>
On 2014=E2=80=9307=E2=80=9309, at 9:09 PM, Klaim - Jo=C3=ABl Lamotte <<a=
href=3D"mailto:mjklaim@gmail.com">mjklaim@gmail.com</a>> wrote:<br>
<br>
> Another=E2=80=8B point was raised few months ago on Boost mailing list=
, relative to the Centralized error checking feature from the related paper=
s:<br>
> its often more useful to the user to be able to specify/change error h=
andling (or not) behaviour for a specific library (or several) rather than =
for the whole application.<br>
> I have no specific suggestion of how this could be made possible but I=
think it's an interesting point to maybe<br>
> explore in future papers related to yours (but I guess it's too ea=
rly to explore now).<br>
<br>
</div></div>Is there anything to do differently than NDEBUG applied to link=
ed libraries, and whatever equivalent library-specific flags that might con=
trol debugging in inline functions?</blockquote></div><br>If we are talking=
about a decision taken at runtime, then yes it's totally different.=C2=
=A0</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><=
/div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c2f1124c5a7604fdc434f5--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Wed, 9 Jul 2014 17:21:47 +0200
Raw View
--089e01227f0448f69904fdc44430
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
To clarify, I'm talking only about the decision of how to handle
a detected contract failure, assuming that the contract checking is
actually running.
Something close to set_terminate() but as I was saying there would be a
"need" to have one per "library".
Something close to NDEBUG would be for compile/link-time choice that is
generating, or not, the contract checking code, which is more obvious to
imagine from current
classic assertion macro implementations.
On Wed, Jul 9, 2014 at 5:17 PM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.co=
m>
wrote:
>
> On Wed, Jul 9, 2014 at 3:45 PM, David Krauss <potswa@gmail.com> wrote:
>
>>
>> On 2014=E2=80=9307=E2=80=9309, at 9:09 PM, Klaim - Jo=C3=ABl Lamotte <mj=
klaim@gmail.com>
>> wrote:
>>
>> > Another=E2=80=8B point was raised few months ago on Boost mailing list=
,
>> relative to the Centralized error checking feature from the related pape=
rs:
>> > its often more useful to the user to be able to specify/change error
>> handling (or not) behaviour for a specific library (or several) rather t=
han
>> for the whole application.
>> > I have no specific suggestion of how this could be made possible but I
>> think it's an interesting point to maybe
>> > explore in future papers related to yours (but I guess it's too early
>> to explore now).
>>
>> Is there anything to do differently than NDEBUG applied to linked
>> libraries, and whatever equivalent library-specific flags that might
>> control debugging in inline functions?
>
>
> If we are talking about a decision taken at runtime, then yes it's totall=
y
> different.
>
>
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--089e01227f0448f69904fdc44430
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">To clarify, I'm talking only about the decision of how=
to handle a=C2=A0detected=C2=A0contract failure, assuming that the contrac=
t checking is actually running.<div>Something close to set_terminate() but =
as I was saying there would be a "need" to have one per "lib=
rary".</div>
<div><br></div><div>Something close to NDEBUG would be for compile/link-tim=
e choice that is generating, or not, the contract checking code, which is m=
ore obvious to imagine from current=C2=A0</div><div>classic assertion macro=
implementations.</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed,=
Jul 9, 2014 at 5:17 PM, Klaim - Jo=C3=ABl Lamotte <span dir=3D"ltr"><<a=
href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.com</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote"><div class=3D"">On Wed, Jul 9, 2014 at 3:45 =
PM, David Krauss <span dir=3D"ltr"><<a href=3D"mailto:potswa@gmail.com" =
target=3D"_blank">potswa@gmail.com</a>></span> wrote:<br>
</div><div class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br>
On 2014=E2=80=9307=E2=80=9309, at 9:09 PM, Klaim - Jo=C3=ABl Lamotte <<a=
href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.com</a>&=
gt; wrote:<br>
<br>
> Another=E2=80=8B point was raised few months ago on Boost mailing list=
, relative to the Centralized error checking feature from the related paper=
s:<br>
> its often more useful to the user to be able to specify/change error h=
andling (or not) behaviour for a specific library (or several) rather than =
for the whole application.<br>
> I have no specific suggestion of how this could be made possible but I=
think it's an interesting point to maybe<br>
> explore in future papers related to yours (but I guess it's too ea=
rly to explore now).<br>
<br>
</div></div>Is there anything to do differently than NDEBUG applied to link=
ed libraries, and whatever equivalent library-specific flags that might con=
trol debugging in inline functions?</blockquote></div></div><br>If we are t=
alking about a decision taken at runtime, then yes it's totally differe=
nt.=C2=A0</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><=
/div>
</blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e01227f0448f69904fdc44430--
.
Author: "J. Daniel Garcia" <josedaniel.garcia@uc3m.es>
Date: Wed, 9 Jul 2014 17:56:20 +0200
Raw View
--90e6ba212347369e8804fdc4c2b1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Understood. This is something I did not think about.
Is there such an existing practice in any other language?
Some compelling example of its usefulness?
The problem I see is that we do not have the concept of library in the
language.
On Wed, Jul 9, 2014 at 5:21 PM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.co=
m>
wrote:
> To clarify, I'm talking only about the decision of how to handle
> a detected contract failure, assuming that the contract checking is
> actually running.
> Something close to set_terminate() but as I was saying there would be a
> "need" to have one per "library".
>
> Something close to NDEBUG would be for compile/link-time choice that is
> generating, or not, the contract checking code, which is more obvious to
> imagine from current
> classic assertion macro implementations.
>
>
> On Wed, Jul 9, 2014 at 5:17 PM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.=
com>
> wrote:
>
>>
>> On Wed, Jul 9, 2014 at 3:45 PM, David Krauss <potswa@gmail.com> wrote:
>>
>>>
>>> On 2014=E2=80=9307=E2=80=9309, at 9:09 PM, Klaim - Jo=C3=ABl Lamotte <m=
jklaim@gmail.com>
>>> wrote:
>>>
>>> > Another=E2=80=8B point was raised few months ago on Boost mailing lis=
t,
>>> relative to the Centralized error checking feature from the related pap=
ers:
>>> > its often more useful to the user to be able to specify/change error
>>> handling (or not) behaviour for a specific library (or several) rather =
than
>>> for the whole application.
>>> > I have no specific suggestion of how this could be made possible but =
I
>>> think it's an interesting point to maybe
>>> > explore in future papers related to yours (but I guess it's too early
>>> to explore now).
>>>
>>> Is there anything to do differently than NDEBUG applied to linked
>>> libraries, and whatever equivalent library-specific flags that might
>>> control debugging in inline functions?
>>
>>
>> If we are talking about a decision taken at runtime, then yes it's
>> totally different.
>>
>>
>>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--90e6ba212347369e8804fdc4c2b1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Understood. This is something I did not think about.<div><=
br></div><div>Is there such an existing practice in any other language?</di=
v><div><br></div><div>Some compelling example of its usefulness?</div><div =
class=3D"gmail_extra">
<br clear=3D"all"><div><div>The problem I see is that we do not have the co=
ncept of library in the language.</div></div><br><div class=3D"gmail_quote"=
>On Wed, Jul 9, 2014 at 5:21 PM, Klaim - Jo=C3=ABl Lamotte <span dir=3D"ltr=
"><<a href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.=
com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">To clarify, I'm talking=
only about the decision of how to handle a=C2=A0detected=C2=A0contract fai=
lure, assuming that the contract checking is actually running.<div>
Something close to set_terminate() but as I was saying there would be a &qu=
ot;need" to have one per "library".</div>
<div><br></div><div>Something close to NDEBUG would be for compile/link-tim=
e choice that is generating, or not, the contract checking code, which is m=
ore obvious to imagine from current=C2=A0</div><div>classic assertion macro=
implementations.</div>
</div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><b=
r><br><div class=3D"gmail_quote">On Wed, Jul 9, 2014 at 5:17 PM, Klaim - Jo=
=C3=ABl Lamotte <span dir=3D"ltr"><<a href=3D"mailto:mjklaim@gmail.com" =
target=3D"_blank">mjklaim@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote"><div>On Wed, Jul 9, 2014 at 3:45 PM, David K=
rauss <span dir=3D"ltr"><<a href=3D"mailto:potswa@gmail.com" target=3D"_=
blank">potswa@gmail.com</a>></span> wrote:<br>
</div><div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div><div><br>
On 2014=E2=80=9307=E2=80=9309, at 9:09 PM, Klaim - Jo=C3=ABl Lamotte <<a=
href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.com</a>&=
gt; wrote:<br>
<br>
> Another=E2=80=8B point was raised few months ago on Boost mailing list=
, relative to the Centralized error checking feature from the related paper=
s:<br>
> its often more useful to the user to be able to specify/change error h=
andling (or not) behaviour for a specific library (or several) rather than =
for the whole application.<br>
> I have no specific suggestion of how this could be made possible but I=
think it's an interesting point to maybe<br>
> explore in future papers related to yours (but I guess it's too ea=
rly to explore now).<br>
<br>
</div></div>Is there anything to do differently than NDEBUG applied to link=
ed libraries, and whatever equivalent library-specific flags that might con=
trol debugging in inline functions?</blockquote></div></div><br>If we are t=
alking about a decision taken at runtime, then yes it's totally differe=
nt.=C2=A0</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><=
/div>
</blockquote></div><br></div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--90e6ba212347369e8804fdc4c2b1--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Wed, 9 Jul 2014 18:33:41 +0200
Raw View
--047d7b33981364a42a04fdc545de
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Jul 9, 2014 at 5:56 PM, J. Daniel Garcia <josedaniel.garcia@uc3m.es=
>
wrote:
> Understood. This is something I did not think about.
>
>
I did not either until someone (I don't remember who) criticized the
centralized proposal by pointing the lack of such facility.
> Is there such an existing practice in any other language?
> Some compelling example of its usefulness?
>
>
In my experience I have several times hit similar need (but not exactly the
same) when working on applications which are big,
therefore splitted in a lot of small libraries plus several dependencies.
In these cases, if you have an obscure bug (as in you can't guess the
source yet, might come from dependencies)
which happen in a way that makes it occur less often when in full debug
mode (for example if the performance
have an impact on it's occurence, typical in soft-real-time simulations),
then it's very useful to be able to activate the assertions (or other
"debug" info) only for one or two libraries,
but have no impact on the rest.
I even hit this need in one of my (big) personal project, and didn't solve
this yet.
But most of the time the need then is more on the assertion generation than
on the choice of contract failure handling.
The choice behaviour when the assertion fails depends a lot on if you
actually want to have part of your libraries
released to the user or not. If you do, then I can see the choice between
logging and ignoring, throwing an exception and just calling terminate()
would become useful.
I do have worked on applications as I just described (big, lot of libs)
which did have a runtime choice of logging behaviour, which seems similar
but still different.
The main reason for having this was the compilation time being awful and
debugging at the client was made possible (by activating all the logs).
I don't have a concrete case at the moment where contract failure handling
have to be different depending on the library,
but I can see how that might be useful for servers (being able to either
log and ignore or just call terminate when there is a
failure in a dependency which have contract check activated).
I'll report if I find a compelling case.
>
> The problem I see is that we do not have the concept of library in the
> language.
>
>
Yes, the only things I can think about would be a namespace-wide way to
specify it (but that would make namespaces become more than they are now)
or a module-wide way (but we can't rely on modules at the moment).
Or have a way to associate contracts with some kind of identifiers, to
allow that identifier to be used in the failure handling facilities.
I'd say that as long as there is a way to extend the contract failure
handling facilities to make it possible later to have one per "library",
there is no point to propose something now for this (and I dont' have
strong arguments for) but having it in mind for later might
be useful. That's why I mentioned it.
> On Wed, Jul 9, 2014 at 5:21 PM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.=
com>
> wrote:
>
>> To clarify, I'm talking only about the decision of how to handle
>> a detected contract failure, assuming that the contract checking is
>> actually running.
>> Something close to set_terminate() but as I was saying there would be a
>> "need" to have one per "library".
>>
>> Something close to NDEBUG would be for compile/link-time choice that is
>> generating, or not, the contract checking code, which is more obvious to
>> imagine from current
>> classic assertion macro implementations.
>>
>>
>> On Wed, Jul 9, 2014 at 5:17 PM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail=
..com>
>> wrote:
>>
>>>
>>> On Wed, Jul 9, 2014 at 3:45 PM, David Krauss <potswa@gmail.com> wrote:
>>>
>>>>
>>>> On 2014=E2=80=9307=E2=80=9309, at 9:09 PM, Klaim - Jo=C3=ABl Lamotte <=
mjklaim@gmail.com>
>>>> wrote:
>>>>
>>>> > Another=E2=80=8B point was raised few months ago on Boost mailing li=
st,
>>>> relative to the Centralized error checking feature from the related pa=
pers:
>>>> > its often more useful to the user to be able to specify/change error
>>>> handling (or not) behaviour for a specific library (or several) rather=
than
>>>> for the whole application.
>>>> > I have no specific suggestion of how this could be made possible but
>>>> I think it's an interesting point to maybe
>>>> > explore in future papers related to yours (but I guess it's too earl=
y
>>>> to explore now).
>>>>
>>>> Is there anything to do differently than NDEBUG applied to linked
>>>> libraries, and whatever equivalent library-specific flags that might
>>>> control debugging in inline functions?
>>>
>>>
>>> If we are talking about a decision taken at runtime, then yes it's
>>> totally different.
>>>
>>>
>>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--047d7b33981364a42a04fdc545de
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Jul 9, 2014 at 5:56 PM, J. Daniel Garcia <span dir=3D"ltr">=
<<a href=3D"mailto:josedaniel.garcia@uc3m.es" target=3D"_blank">josedani=
el.garcia@uc3m.es</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">Understood. This is something I did not t=
hink about.<div>
<br></div></div></blockquote><div><br></div><div>I did not either until som=
eone (I don't remember who) criticized the centralized proposal by poin=
ting the lack of such facility.</div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir=3D"ltr"><div></div><div>Is there such an existing practice in any =
other language?</div><div><div>Some compelling example of its usefulness?</=
div></div><div><br></div></div></blockquote><div><br></div><div>In my exper=
ience I have several times hit similar need=C2=A0(but not exactly the same)=
=C2=A0when working on applications which are big,</div>
<div>therefore splitted in a lot of small libraries plus several dependenci=
es.=C2=A0</div><div>In these cases, if you have an obscure bug (as in you c=
an't guess the source yet, might come from dependencies)</div><div>=C2=
=A0which happen in a way that makes it occur less often when in full debug =
mode (for example if the performance</div>
<div>have an impact on it's occurence, typical in soft-real-time simula=
tions),=C2=A0</div><div>then it's very useful to be able to activate th=
e assertions (or other "debug" info) only for one or two librarie=
s,=C2=A0</div>
<div>but have no impact on the rest.</div><div>I even hit this need in one =
of my (big) personal project, and didn't solve this yet.</div><div>But =
most of the time the need then is more on the assertion generation than on =
the choice of contract failure handling.</div>
<div>The choice behaviour when the assertion fails depends a lot on if you =
actually want to have part of your libraries</div><div>released to the user=
or not. If you do, then I can see the choice between logging and ignoring,=
throwing an exception and just calling terminate()=C2=A0</div>
<div>would become useful.</div><div><br></div><div>I do have worked on appl=
ications as I just described (big, lot of libs) which did have a runtime ch=
oice of logging behaviour, which seems similar but still different.</div>
<div>The main reason for having this was the compilation time being awful a=
nd debugging at the client was made possible (by activating all the logs).<=
/div><div><br></div><div>I don't have a concrete case at the moment whe=
re contract failure handling have to be different depending on the library,=
</div>
<div>but I can see how that might be useful for servers (being able to eith=
er log and ignore or just call terminate when there is a</div><div>failure =
in a dependency which have contract check activated).</div><div>I'll re=
port if I find a compelling case.</div>
<div><br></div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>=
</div><div>
<br></div><div class=3D"gmail_extra"><div><div>The problem I see is that we=
do not have the concept of library in the language.</div></div><br></div><=
/div></blockquote><div><br></div><div>Yes, the only things I can think abou=
t would be a namespace-wide way to specify it (but that would make namespac=
es become more than they are now)</div>
<div>or a module-wide way (but we can't rely on modules at the moment).=
</div><div>Or have a way to associate contracts with some kind of identifie=
rs, to allow that identifier to be used in the failure handling facilities.=
</div>
<div><br></div><div>I'd say that as long as there is a way to extend th=
e contract failure handling facilities to make it possible later to have on=
e per "library",=C2=A0</div><div>there is no point to propose som=
ething now for this (and I dont' have strong arguments for) but having =
it in mind for later might=C2=A0</div>
<div>be useful. That's why I mentioned it.</div><div><br></div><div><br=
></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><div class=3D"h5">On Wed, Jul 9, 2014 at 5:21 PM, Klaim - Jo=C3=ABl Lamott=
e <span dir=3D"ltr"><<a href=3D"mailto:mjklaim@gmail.com" target=3D"_bla=
nk">mjklaim@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><div><div class=3D"h5"><div dir=3D"ltr">To cla=
rify, I'm talking only about the decision of how to handle a=C2=A0detec=
ted=C2=A0contract failure, assuming that the contract checking is actually =
running.<div>
Something close to set_terminate() but as I was saying there would be a &qu=
ot;need" to have one per "library".</div>
<div><br></div><div>Something close to NDEBUG would be for compile/link-tim=
e choice that is generating, or not, the contract checking code, which is m=
ore obvious to imagine from current=C2=A0</div><div>classic assertion macro=
implementations.</div>
</div></div></div><div><div><div><div class=3D"h5"><div class=3D"gmail_extr=
a"><br><br><div class=3D"gmail_quote">On Wed, Jul 9, 2014 at 5:17 PM, Klaim=
- Jo=C3=ABl Lamotte <span dir=3D"ltr"><<a href=3D"mailto:mjklaim@gmail.=
com" target=3D"_blank">mjklaim@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">
<div>On Wed, Jul 9, 2014 at 3:45 PM, David Krauss <span dir=3D"ltr"><<a =
href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>>=
</span> wrote:<br>
</div><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-st=
yle:solid;padding-left:1ex"><div><div><br>
On 2014=E2=80=9307=E2=80=9309, at 9:09 PM, Klaim - Jo=C3=ABl Lamotte <<a=
href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.com</a>&=
gt; wrote:<br>
<br>
> Another=E2=80=8B point was raised few months ago on Boost mailing list=
, relative to the Centralized error checking feature from the related paper=
s:<br>
> its often more useful to the user to be able to specify/change error h=
andling (or not) behaviour for a specific library (or several) rather than =
for the whole application.<br>
> I have no specific suggestion of how this could be made possible but I=
think it's an interesting point to maybe<br>
> explore in future papers related to yours (but I guess it's too ea=
rly to explore now).<br>
<br>
</div></div>Is there anything to do differently than NDEBUG applied to link=
ed libraries, and whatever equivalent library-specific flags that might con=
trol debugging in inline functions?</blockquote></div></div><br>If we are t=
alking about a decision taken at runtime, then yes it's totally differe=
nt.=C2=A0</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><=
/div>
</blockquote></div><br></div>
<p></p></div></div><span class=3D""><font color=3D"#888888">
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></div></div></blockquote></div><span class=3D""><font color=
=3D"#888888"><br></font></span></div></div><span class=3D""><font color=3D"=
#888888">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b33981364a42a04fdc545de--
.
Author: Felipe Magno de Almeida <felipe.m.almeida@gmail.com>
Date: Wed, 9 Jul 2014 14:39:21 -0300
Raw View
On Sat, Jul 5, 2014 at 11:29 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
>
Hello Andrzej,
[snip]
> How does my paper relate to N3997? I state certain design goals and N3997
> does not meet them. N3997 proposes a more "imperative" approach. A
> precondition declaration means that something must be executed under cert=
ain
> configuration. I tried to promote a different philosophy: preconditions a=
re
> more for static analysis. Also, in N3997pre- and post- conditions are not
> part of function's declaration, but something in the function body --
> invisible to the users. I disagree with this. I believe that precondition=
s
> are part of functions interface.
I like your approach to pre/pos condition declarations. I do think this sho=
uld
be a tool that enables the construction of tools to help the user trust the
correctness of its application and not just a tool for catching errors (we
already have assert for that). This implies that the language must be
expressive enough to deal with abstracted properties which can't be
defined with mathematics alone, like saying the color is red for example
(if I'm defining a color class or concept).
I'm not so sure about the definition of a property as an entity like that
though, and how about calling it a predicate instead too?
> --
Regards,
--=20
Felipe Magno de Almeida
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Andrzej Krzemienski <akrzemi1@gmail.com>
Date: Wed, 9 Jul 2014 22:26:04 +0200
Raw View
--001a11c383ac7c6abf04fdc884ec
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
2014-07-09 19:39 GMT+02:00 Felipe Magno de Almeida <
felipe.m.almeida@gmail.com>:
> On Sat, Jul 5, 2014 at 11:29 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail=
..com>
> wrote:
> >
>
> Hello Andrzej,
>
> [snip]
>
> > How does my paper relate to N3997? I state certain design goals and N39=
97
> > does not meet them. N3997 proposes a more "imperative" approach. A
> > precondition declaration means that something must be executed under
> certain
> > configuration. I tried to promote a different philosophy: preconditions
> are
> > more for static analysis. Also, in N3997pre- and post- conditions are n=
ot
> > part of function's declaration, but something in the function body --
> > invisible to the users. I disagree with this. I believe that
> preconditions
> > are part of functions interface.
>
> I like your approach to pre/pos condition declarations. I do think this
> should
> be a tool that enables the construction of tools to help the user trust t=
he
> correctness of its application and not just a tool for catching errors (w=
e
> already have assert for that). This implies that the language must be
> expressive enough to deal with abstracted properties which can't be
> defined with mathematics alone, like saying the color is red for example
> (if I'm defining a color class or concept).
>
> I'm not so sure about the definition of a property as an entity like that
> though, and how about calling it a predicate instead too?
>
I do not insist on having the properties like this in the language. I do
not insist on a particular name. Too soon for that. I am trying to stress
that just evaluating predicates at given points in time is not the only
approach to enforcing correctness, and not necessarily the best one. Some
predicates just must never be evaluated, even though they express clearly
the precondition of the function. The paper gives such examples.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c383ac7c6abf04fdc884ec
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">2014-07-09 19:39 GMT+02:00 Felipe Magno de Almeida <span dir=3D"ltr=
"><<a href=3D"mailto:felipe.m.almeida@gmail.com" target=3D"_blank">felip=
e.m.almeida@gmail.com</a>></span>:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Sat, Jul 5, 2014 at 11:29 AM, Andrzej Krz=
emie=C5=84ski <<a href=3D"mailto:akrzemi1@gmail.com">akrzemi1@gmail.com<=
/a>> wrote:<br>
><br>
<br>
Hello Andrzej,<br>
<br>
[snip]<br>
<div class=3D""><br>
> How does my paper relate to N3997? I state certain design goals and N3=
997<br>
> does not meet them. N3997 proposes a more "imperative" appro=
ach. A<br>
> precondition declaration means that something must be executed under c=
ertain<br>
> configuration. I tried to promote a different philosophy: precondition=
s are<br>
> more for static analysis. Also, in N3997pre- and post- conditions are =
not<br>
> part of function's declaration, but something in the function body=
--<br>
> invisible to the users. I disagree with this. I believe that precondit=
ions<br>
> are part of functions interface.<br>
<br>
</div>I like your approach to pre/pos condition declarations. I do think th=
is should<br>
be a tool that enables the construction of tools to help the user trust the=
<br>
correctness of its application and not just a tool for catching errors (we<=
br>
already have assert for that). This implies that the language must be<br>
expressive enough to deal with abstracted properties which can't be<br>
defined with mathematics alone, like saying the color is red for example<br=
>
(if I'm defining a color class or concept).<br>
<br>
I'm not so sure about the definition of a property as an entity like th=
at<br>
though, and how about calling it a predicate instead too?<br></blockquote><=
div><br></div><div>I do not insist on having the properties=C2=A0 like this=
in the language. I do not insist on a particular name. Too soon for that. =
I am trying to stress that just evaluating predicates at given points in ti=
me is not the only approach to enforcing correctness, and not necessarily t=
he best one. Some predicates just must never be evaluated, even though they=
express clearly the precondition of the function. The paper gives such exa=
mples. <br>
</div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c383ac7c6abf04fdc884ec--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Thu, 10 Jul 2014 05:32:16 -0700 (PDT)
Raw View
------=_Part_27_18375580.1404995536552
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu wtorek, 8 lipca 2014 01:07:38 UTC+2 u=C5=BCytkownik Klaim - Jo=C3=AB=
l Lamotte=20
napisa=C5=82:
>
> This paper have just been posted on isocpp.org:=20
> https://isocpp.org/files/papers/N4110.pdf
>
> It looks a lot like your paper (but I didn't read it completely yet).
>
Not quite. Like mine, it also sees the necessity of declaring things like=
=20
preconditions, postconditions and invariants, however there is a notable=20
difference in what should be done with these declarations. In try to=20
discuss the benefits and issues of different approaches. N4110 just=20
explores one: evaluating them at run-time and installing handlers.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_27_18375580.1404995536552
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>W dniu wtorek, 8 lipca 2014 01:07:38 UTC+2 u=C5=BC=
ytkownik Klaim - Jo=C3=ABl Lamotte napisa=C5=82:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr">This paper have just been posted on <a h=
ref=3D"http://isocpp.org" target=3D"_blank" onmousedown=3D"this.href=3D'htt=
p://www.google.com/url?q\75http%3A%2F%2Fisocpp.org\46sa\75D\46sntz\0751\46u=
sg\75AFQjCNHaIcX84r8AUHgx9Q4pR00LZ1llsQ';return true;" onclick=3D"this.href=
=3D'http://www.google.com/url?q\75http%3A%2F%2Fisocpp.org\46sa\75D\46sntz\0=
751\46usg\75AFQjCNHaIcX84r8AUHgx9Q4pR00LZ1llsQ';return true;">isocpp.org</a=
>: <a href=3D"https://isocpp.org/files/papers/N4110.pdf" target=3D"_bl=
ank" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F=
%2Fisocpp.org%2Ffiles%2Fpapers%2FN4110.pdf\46sa\75D\46sntz\0751\46usg\75AFQ=
jCNF_-5W4GA0J1PQm8XAMRJgNUcZFcw';return true;" onclick=3D"this.href=3D'http=
s://www.google.com/url?q\75https%3A%2F%2Fisocpp.org%2Ffiles%2Fpapers%2FN411=
0.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNF_-5W4GA0J1PQm8XAMRJgNUcZFcw';retu=
rn true;">https://isocpp.<wbr>org/files/papers/N4110.pdf</a><br><br>It look=
s a lot like your paper (but I didn't read it completely yet).</div></block=
quote><div><br>Not quite. Like mine, it also sees the necessity of declarin=
g things like preconditions, postconditions and invariants, however there i=
s a notable difference in what should be done with these declarations. In t=
ry to discuss the benefits and issues of different approaches. N4110 just e=
xplores one: evaluating them at run-time and installing handlers.<br></div>=
</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_27_18375580.1404995536552--
.