Topic: Contracts - Non-accessible pre-conditions
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 24 Apr 2015 08:26:19 +0200
Raw View
This is a multi-part message in MIME format.
--------------030302060606080503030108
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi,
we have a standard use case that would need the use of private
conditions. E.g. when we move an string lvalue, the single things that
can be done with is to destroy and assign. To capture this condition we
would need an internal state to reflect this condition.
If pre-conditions can not use non-accessible members, how this
pre-condition can be expressed?
Let me suppose that we allow non-accessible members?
Without contracts, the implementation doesn't need to represent this
internal state, if another function is used the behavior is undefined.
This mean that when adding Contracts, the implementation should need to
do something else when Contract validation is enabled, isn't it?
So the question is, wouldn't we need to standardize a compiler flag to
state that the Contract validation is enabled/disabled?
Otherwise, how a program could be portable and as efficient as possible?
If we don't want that any non-accessible member can be used in a
contract expression, don't we need at least a specific attribute to mean
accessible only on contract expressions?
What am i missing? do we want to take care of this kind of pre-conditions?
Vicente
--
---
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/.
--------------030302060606080503030108
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<font size=3D"+1">Hi,<br>
<br>
we have a standard use case that=C2=A0 would need the use of private
conditions. E.g. when we move an string lvalue, the single things
that can be done with is to destroy and assign. To capture this
condition we would need an internal state to reflect this
condition. <br>
<br>
If pre-conditions can not use non-accessible members, how this
pre-condition can be expressed?<br>
<br>
Let me suppose that we allow non-accessible members? <br>
Without contracts, the implementation doesn't need to represent
this internal state, if another function is used the behavior is
undefined. This mean that when adding Contracts, the
implementation should need to do something else when Contract
validation is enabled, isn't it? <br>
So the question is, wouldn't we need to standardize a compiler
flag to state that the Contract validation is enabled/disabled? <br>
Otherwise, how a program could be portable and as efficient as
possible?<br>
</font><br>
<font size=3D"+1"><font size=3D"+1">If we don't want that any
non-accessible member can be used in a contract expression,
don't we need at least a specific attribute to mean accessible
only on contract expressions?<br>
<br>
</font>What am i missing? do we=C2=A0</font><font size=3D"+1"><font
size=3D"+1"></font>want to take care of this kind of
pre-conditions?<br>
<br>
Vicente<br>
<br>
</font>
</body>
</html>
<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 />
--------------030302060606080503030108--
.
Author: Jonas Persson <l.j.persson@gmail.com>
Date: Fri, 24 Apr 2015 09:13:55 +0200
Raw View
--f46d043be25ea6ea8e0514732338
Content-Type: text/plain; charset=UTF-8
The caller of the function needs to be able to verify that it will not do
an invalid call so it must be accessible. And a broken pre-condition is
equally invalid regardless of wheter contracts are enabled or not, so the
implementation needs to be the same in both cases.
/ Jonas
On Fri, Apr 24, 2015 at 8:26 AM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
> Hi,
>
> we have a standard use case that would need the use of private
> conditions. E.g. when we move an string lvalue, the single things that can
> be done with is to destroy and assign. To capture this condition we would
> need an internal state to reflect this condition.
>
> If pre-conditions can not use non-accessible members, how this
> pre-condition can be expressed?
>
> Let me suppose that we allow non-accessible members?
> Without contracts, the implementation doesn't need to represent this
> internal state, if another function is used the behavior is undefined. This
> mean that when adding Contracts, the implementation should need to do
> something else when Contract validation is enabled, isn't it?
> So the question is, wouldn't we need to standardize a compiler flag to
> state that the Contract validation is enabled/disabled?
> Otherwise, how a program could be portable and as efficient as possible?
>
> If we don't want that any non-accessible member can be used in a contract
> expression, don't we need at least a specific attribute to mean accessible
> only on contract expressions?
>
> What am i missing? do we want to take care of this kind of pre-conditions?
>
> Vicente
>
> --
>
> ---
> 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/.
>
--
---
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/.
--f46d043be25ea6ea8e0514732338
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The caller of the function needs to be able to verify that=
it will not do an invalid call so it must be accessible. And a broken pre-=
condition is equally invalid regardless of wheter contracts are enabled or =
not, so the implementation needs to be the same in both cases.<div><br></di=
v><div>=C2=A0 / Jonas</div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Fri, Apr 24, 2015 at 8:26 AM, Vicente J. Botet Escriba =
<span dir=3D"ltr"><<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D=
"_blank">vicente.botet@wanadoo.fr</a>></span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<font size=3D"+1">Hi,<br>
<br>
we have a standard use case that=C2=A0 would need the use of private
conditions. E.g. when we move an string lvalue, the single things
that can be done with is to destroy and assign. To capture this
condition we would need an internal state to reflect this
condition. <br>
<br>
If pre-conditions can not use non-accessible members, how this
pre-condition can be expressed?<br>
<br>
Let me suppose that we allow non-accessible members? <br>
Without contracts, the implementation doesn't need to represent
this internal state, if another function is used the behavior is
undefined. This mean that when adding Contracts, the
implementation should need to do something else when Contract
validation is enabled, isn't it? <br>
So the question is, wouldn't we need to standardize a compiler
flag to state that the Contract validation is enabled/disabled? <br>
Otherwise, how a program could be portable and as efficient as
possible?<br>
</font><br>
<font size=3D"+1"><font size=3D"+1">If we don't want that any
non-accessible member can be used in a contract expression,
don't we need at least a specific attribute to mean accessible
only on contract expressions?<br>
<br>
</font>What am i missing? do we=C2=A0</font><font size=3D"+1"><font s=
ize=3D"+1"></font>want to take care of this kind of
pre-conditions?<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
Vicente<br>
<br>
</font></span></font><span class=3D"HOEnZb"><font color=3D"#888888">
</font></span></div><span class=3D"HOEnZb"><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>
<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 />
--f46d043be25ea6ea8e0514732338--
.
Author: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Fri, 24 Apr 2015 09:20:40 +0100
Raw View
--001a11c3515263909d051474123d
Content-Type: text/plain; charset=UTF-8
Vicente raises an interesting point, are there any preconditions that might
not be testable/accessible by the client? My experience is that I have hit
this in some cases, with interfaces that require that 'stop' not be called
unless 'start' has previously been called and that at the same time do not
provide an accessor to whether the object had ever been started. But as
Jonas mentions, the feeling when working with those APIs is that they were
not well designed and imposed a burden on the user that has to track
externally whether 'start' was called or not.
I don't have any example of a component that I would consider well designed
and at the same time did not allow the client to determine before hand
whether a given call would be a violation of the contract.
As a side note, is the precondition really that you cannot do anything
other than assignment/destruction on a moved-from string? My believe was
that "valid" meant that you can call any member function with no
preconditions and then any member function for which preconditions are met.
So this would be a perfectly valid program:
std::string src = "String that might or not fit SMO";
std::string dst = std::move(src);
if (!src.empty()) {
std::cout << "First character after move: " << src[1] << '\n';
}
Which again falls within what Jonas mentioned: the caller is able to
determine whether a call to 'operator[]' will be within contract by calling
other member functions that have wide contracts. The precondition on
'operator[]' can be expressed in terms of the publicly available
'src.size()'.
Whether you believe that it is sane or not to try to reuse a string after
being moved this way is a different question, but the contracts for the
different members should not depend on what happened in the past, but the
current state of the object. If the string after being moved is empty you
cannot access the 1st element, how the string became empty is not part of
the contract. If the string is non-empty, it does not matter whether move
was called before, it is not empty and the call is within contract.
If you want to add additional diagnostics specifically for this (using an
object that has been moved-from), you could use an extension similar to
checked iterators for containers. In that extension, the test could either
be internal or the additional state would have to be accessible for the
caller to verify.
David
On Fri, Apr 24, 2015 at 8:13 AM, Jonas Persson <l.j.persson@gmail.com>
wrote:
> The caller of the function needs to be able to verify that it will not do
> an invalid call so it must be accessible. And a broken pre-condition is
> equally invalid regardless of wheter contracts are enabled or not, so the
> implementation needs to be the same in both cases.
>
> / Jonas
>
> On Fri, Apr 24, 2015 at 8:26 AM, Vicente J. Botet Escriba <
> vicente.botet@wanadoo.fr> wrote:
>
>> Hi,
>>
>> we have a standard use case that would need the use of private
>> conditions. E.g. when we move an string lvalue, the single things that can
>> be done with is to destroy and assign. To capture this condition we would
>> need an internal state to reflect this condition.
>>
>> If pre-conditions can not use non-accessible members, how this
>> pre-condition can be expressed?
>>
>> Let me suppose that we allow non-accessible members?
>> Without contracts, the implementation doesn't need to represent this
>> internal state, if another function is used the behavior is undefined. This
>> mean that when adding Contracts, the implementation should need to do
>> something else when Contract validation is enabled, isn't it?
>> So the question is, wouldn't we need to standardize a compiler flag to
>> state that the Contract validation is enabled/disabled?
>> Otherwise, how a program could be portable and as efficient as possible?
>>
>> If we don't want that any non-accessible member can be used in a contract
>> expression, don't we need at least a specific attribute to mean accessible
>> only on contract expressions?
>>
>> What am i missing? do we want to take care of this kind of
>> pre-conditions?
>>
>> Vicente
>>
>> --
>>
>> ---
>> 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/.
>>
>
> --
>
> ---
> 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/.
>
--
---
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/.
--001a11c3515263909d051474123d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Vicente raises an interesting point, are there any precond=
itions that might not be testable/accessible by the client? My experience i=
s that I have hit this in some cases, with interfaces that require that =
9;stop' not be called unless 'start' has previously been called=
and that at the same time do not provide an accessor to whether the object=
had ever been started. But as Jonas mentions, the feeling when working wit=
h those APIs is that they were not well designed and imposed a burden on th=
e user that has to track externally whether 'start' was called or n=
ot.<br><br>I don't have any example of a component that I would conside=
r well designed and at the same time did not allow the client to determine =
before hand whether a given call would be a violation of the contract.<br><=
br>As a side note, is the precondition really that you cannot do anything o=
ther than assignment/destruction on a moved-from string? My believe was tha=
t "valid" meant that you can call any member function with no pre=
conditions and then any member function for which preconditions are met. So=
this would be a perfectly valid program:<br><br>std::string src =3D "=
String that might or not fit SMO";<br>std::string dst =3D std::move(sr=
c);<br>if (!src.empty()) {<br>=C2=A0 =C2=A0 std::cout << "First =
character after move: " << src[1] << '\n';<br>}<br=
><br>Which again falls within what Jonas mentioned: the caller is able to d=
etermine whether a call to 'operator[]' will be within contract by =
calling other member functions that have wide contracts.=C2=A0 The precondi=
tion on 'operator[]' can be expressed in terms of the publicly avai=
lable 'src.size()'.<br><br>Whether you believe that it is sane or n=
ot to try to reuse a string after being moved this way is a different quest=
ion, but the contracts for the different members should not depend on what =
happened in the past, but the current state of the object. If the string af=
ter being moved is empty you cannot access the 1st element, how the string =
became empty is not part of the contract. If the string is non-empty, it do=
es not matter whether move was called before, it is not empty and the call =
is within contract. =C2=A0<br><br>If you want to add additional diagnostics=
specifically for this (using an object that has been moved-from), you coul=
d use an extension similar to checked iterators for containers. In that ext=
ension, the test could either be internal or the additional state would hav=
e to be accessible for the caller to verify.<br><br>=C2=A0 =C2=A0 David</di=
v><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Apr 24,=
2015 at 8:13 AM, Jonas Persson <span dir=3D"ltr"><<a href=3D"mailto:l.j=
..persson@gmail.com" target=3D"_blank">l.j.persson@gmail.com</a>></span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">The caller of the=
function needs to be able to verify that it will not do an invalid call so=
it must be accessible. And a broken pre-condition is equally invalid regar=
dless of wheter contracts are enabled or not, so the implementation needs t=
o be the same in both cases.<span class=3D"HOEnZb"><font color=3D"#888888">=
<div><br></div><div>=C2=A0 / Jonas</div></font></span></div><div class=3D"H=
OEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail=
_quote">On Fri, Apr 24, 2015 at 8:26 AM, Vicente J. Botet Escriba <span dir=
=3D"ltr"><<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">=
vicente.botet@wanadoo.fr</a>></span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<font size=3D"+1">Hi,<br>
<br>
we have a standard use case that=C2=A0 would need the use of private
conditions. E.g. when we move an string lvalue, the single things
that can be done with is to destroy and assign. To capture this
condition we would need an internal state to reflect this
condition. <br>
<br>
If pre-conditions can not use non-accessible members, how this
pre-condition can be expressed?<br>
<br>
Let me suppose that we allow non-accessible members? <br>
Without contracts, the implementation doesn't need to represent
this internal state, if another function is used the behavior is
undefined. This mean that when adding Contracts, the
implementation should need to do something else when Contract
validation is enabled, isn't it? <br>
So the question is, wouldn't we need to standardize a compiler
flag to state that the Contract validation is enabled/disabled? <br>
Otherwise, how a program could be portable and as efficient as
possible?<br>
</font><br>
<font size=3D"+1"><font size=3D"+1">If we don't want that any
non-accessible member can be used in a contract expression,
don't we need at least a specific attribute to mean accessible
only on contract expressions?<br>
<br>
</font>What am i missing? do we=C2=A0</font><font size=3D"+1"><font s=
ize=3D"+1"></font>want to take care of this kind of
pre-conditions?<span><font color=3D"#888888"><br>
<br>
Vicente<br>
<br>
</font></span></font><span><font color=3D"#888888">
</font></span></div><span><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>
<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 />
--001a11c3515263909d051474123d--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 24 Apr 2015 03:36:27 -0700 (PDT)
Raw View
------=_Part_834_1131917411.1429871787036
Content-Type: multipart/alternative;
boundary="----=_Part_835_1725781551.1429871787036"
------=_Part_835_1725781551.1429871787036
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu pi=C4=85tek, 24 kwietnia 2015 08:26:22 UTC+2 u=C5=BCytkownik Vicente=
J. Botet=20
Escriba napisa=C5=82:
>
> Hi,
>
> we have a standard use case that would need the use of private=20
> conditions. E.g. when we move an string lvalue, the single things that ca=
n=20
> be done with is to destroy and assign. To capture this condition we would=
=20
> need an internal state to reflect this condition.=20
>
> If pre-conditions can not use non-accessible members, how this=20
> pre-condition can be expressed?
>
> Let me suppose that we allow non-accessible members?=20
> Without contracts, the implementation doesn't need to represent this=20
> internal state, if another function is used the behavior is undefined. Th=
is=20
> mean that when adding Contracts, the implementation should need to do=20
> something else when Contract validation is enabled, isn't it?=20
> So the question is, wouldn't we need to standardize a compiler flag to=20
> state that the Contract validation is enabled/disabled?=20
> Otherwise, how a program could be portable and as efficient as possible?
>
> If we don't want that any non-accessible member can be used in a contract=
=20
> expression, don't we need at least a specific attribute to mean accessibl=
e=20
> only on contract expressions?
>
> What am i missing? do we want to take care of this kind of pre-conditions=
?
>
> Vicente
>
First, there are some "prerequisites" that we put on the input values that=
=20
are impossible to verify:
void call_f(R* r)
// requires: r points to a valid object of type R (or related) whose=20
life-time is in progress
{
r->f();
}=20
There is no practical way to verify that the memory pointed to by r is a=20
valid object (as opposed to raw memory). So, the preconditions as language=
=20
feature can only express a subset of requirements. Regarding your example=
=20
with strings, the statement that you can only destroy or assign to a=20
moved-from object is incorrect. I recall that during the development of the=
=20
C++11 standard it was often repeated that you can only perform these two=20
operations, but the final outcome is that the moved-from object is in a=20
"valid but unspecified state" (17.6.5.15 [lib.types.movedfrom]). According=
=20
to this interpretation:=20
http://stackoverflow.com/questions/7027523/what-can-i-do-with-a-moved-from-=
object,=20
this means that you can invoke any member function on a moved-from object=
=20
as long as it has "wide contract": on strings this would be size(),=20
empty(), at().
So, I would say that the example with a moved-from string is not a good=20
motivation for allowing private members in specifying a precondition. But=
=20
to address your question, I believe that since the content of the=20
precondition is part of the component's interface, it is required not to=20
use private components. This implies that sometimes we would have to=20
promote some part of the implementation public only for the sake of being=
=20
able to express the precondition (I have encountered some cases like that)=
=20
or accept that some requirements cannot be expressed with a precondition.=
=20
This is needed because sometimes the programmer needs to "manually" check=
=20
if his input satisfies the precondition of the function he is about to=20
call, and this is checked by evaluating the precondition: in this case, the=
=20
precondition needs to be accessible.
Regards,
&rzej=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_835_1725781551.1429871787036
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>W dniu pi=C4=85tek, 24 kwietnia 2015 08:26:22 UTC+=
2 u=C5=BCytkownik Vicente J. Botet Escriba napisa=C5=82:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<font size=3D"+1">Hi,<br>
<br>
we have a standard use case that would need the use of private
conditions. E.g. when we move an string lvalue, the single things
that can be done with is to destroy and assign. To capture this
condition we would need an internal state to reflect this
condition. <br>
<br>
If pre-conditions can not use non-accessible members, how this
pre-condition can be expressed?<br>
<br>
Let me suppose that we allow non-accessible members? <br>
Without contracts, the implementation doesn't need to represent
this internal state, if another function is used the behavior is
undefined. This mean that when adding Contracts, the
implementation should need to do something else when Contract
validation is enabled, isn't it? <br>
So the question is, wouldn't we need to standardize a compiler
flag to state that the Contract validation is enabled/disabled? <br>
Otherwise, how a program could be portable and as efficient as
possible?<br>
</font><br>
<font size=3D"+1"><font size=3D"+1">If we don't want that any
non-accessible member can be used in a contract expression,
don't we need at least a specific attribute to mean accessible
only on contract expressions?<br>
<br>
</font>What am i missing? do we </font><font size=3D"+1"><font s=
ize=3D"+1"></font>want to take care of this kind of
pre-conditions?<br>
<br>
Vicente<br></font></div></blockquote><div><br>First, there are some "=
prerequisites" that we put on the input values that are impossible to verif=
y:<br><br>void call_f(R* r)<br>// requires: r points to a valid object of t=
ype R (or related) whose life-time is in progress<br>{<br> r->f();=
<br>} <br><br>There is no practical way to verify that the memory pointed t=
o by r is a valid object (as opposed to raw memory). So, the preconditions =
as language feature can only express a subset of requirements. Regarding yo=
ur example with strings, the statement that you can only destroy or assign =
to a moved-from object is incorrect. I recall that during the development o=
f the C++11 standard it was often repeated that you can only perform these =
two operations, but the final outcome is that the moved-from object is in a=
"valid but unspecified state" (17.6.5.15 [lib.types.movedfrom]). According=
to this interpretation: <a href=3D"http://stackoverflow.com/questions/7027=
523/what-can-i-do-with-a-moved-from-object">http://stackoverflow.com/questi=
ons/7027523/what-can-i-do-with-a-moved-from-object</a>, this means that you=
can invoke any member function on a moved-from object as long as it has "w=
ide contract": on strings this would be size(), empty(), at().<br><br>So, I=
would say that the example with a moved-from string is not a good motivati=
on for allowing private members in specifying a precondition. But to addres=
s your question, I believe that since the content of the precondition is pa=
rt of the component's interface, it is required not to use private componen=
ts. This implies that sometimes we would have to promote some part of the i=
mplementation public only for the sake of being able to express the precond=
ition (I have encountered some cases like that) or accept that some require=
ments cannot be expressed with a precondition. This is needed because somet=
imes the programmer needs to "manually" check if his input satisfies the pr=
econdition of the function he is about to call, and this is checked by eval=
uating the precondition: in this case, the precondition needs to be accessi=
ble.<br><br>Regards,<br>&rzej <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_835_1725781551.1429871787036--
------=_Part_834_1131917411.1429871787036--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 24 Apr 2015 20:46:47 +0200
Raw View
Le 24/04/15 09:13, Jonas Persson a =C3=A9crit :
> The caller of the function needs to be able to verify that it will not=20
> do an invalid call so it must be accessible.
The user can know if the precondition is satisfied other than using a=20
public function. The context gives also some valid information.
> And a broken pre-condition is equally invalid regardless of wheter=20
> contracts are enabled or not, so the implementation needs to be the=20
> same in both cases.
>
>
You are right. Changing the implementation in order to be able to check=20
a contact seems not natural.
Vicente
--=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: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 24 Apr 2015 20:46:55 +0200
Raw View
Le 24/04/15 10:20, David Rodr=C3=ADguez Ibeas a =C3=A9crit :
> Vicente raises an interesting point, are there any preconditions that=20
> might not be testable/accessible by the client? My experience is that=20
> I have hit this in some cases, with interfaces that require that=20
> 'stop' not be called unless 'start' has previously been called and=20
> that at the same time do not provide an accessor to whether the object=20
> had ever been started. But as Jonas mentions, the feeling when working=20
> with those APIs is that they were not well designed and imposed a=20
> burden on the user that has to track externally whether 'start' was=20
> called or not.
>
> I don't have any example of a component that I would consider well=20
> designed and at the same time did not allow the client to determine=20
> before hand whether a given call would be a violation of the contract.
The standard contains a contextual contract. tsd::mutex::unlock must be=20
called by the same thread that locked it.
>
> As a side note, is the precondition really that you cannot do anything=20
> other than assignment/destruction on a moved-from string?
Yes.
> My believe was that "valid" meant that you can call any member=20
> function with no preconditions and then any member function for which=20
> preconditions are met. So this would be a perfectly valid program:
>
> std::string src =3D "String that might or not fit SMO";
> std::string dst =3D std::move(src);
> if (!src.empty()) {
> std::cout << "First character after move: " << src[1] << '\n';
> }
>
> Which again falls within what Jonas mentioned: the caller is able to=20
> determine whether a call to 'operator[]' will be within contract by=20
> calling other member functions that have wide contracts. The=20
> precondition on 'operator[]' can be expressed in terms of the publicly=20
> available 'src.size()'.
>
There is a long thread about this (see [std-discussion] side effects of=20
moving standard types)
> Whether you believe that it is sane or not to try to reuse a string=20
> after being moved this way is a different question, but the contracts=20
> for the different members should not depend on what happened in the=20
> past, but the current state of the object. If the string after being=20
> moved is empty you cannot access the 1st element, how the string=20
> became empty is not part of the contract. If the string is non-empty,=20
> it does not matter whether move was called before, it is not empty and=20
> the call is within contract.
>
> If you want to add additional diagnostics specifically for this (using=20
> an object that has been moved-from), you could use an extension=20
> similar to checked iterators for containers. In that extension, the=20
> test could either be internal or the additional state would have to be=20
> accessible for the caller to verify.
The particular case of the move operation could be managed by compile=20
time pre/post conditions as suggested by Andrzej. Andzej suggest the use=20
of properties as e.g.
template <typename T>
property bool is_partially_formed (T const&);
T&& move(T& t) [[post: is_partially_formed(t) ]]
X& X::X(const& X x) [[pre: ! is_partially_formed(x) post: !=20
is_partially_formed(*this) ]]
Any other operation than destruction and assignment
R X::f() [[pre: ! is_partially_formed(*this) ]]
X x; // doesn't have property is_partially_formed yet.
X y =3D std::move(x); // x has property is_partially_formed now.
x =3D makeX(); // x doesn't have property is_partially_formed anymore
Vicente
--=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/.
.