220 4520 article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: contract programming :: preconditions in STD Date: Fri, 24 May 2013 06:37:09 -0700 (PDT) Lines: 742 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_49_30658112.1369402629855" X-Trace: ger.gmane.org 1369402632 24081 80.91.229.3 (24 May 2013 13:37:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 May 2013 13:37:12 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDT2DGOJ34DBBB627WGAKGQELVQ45GY@isocpp.org Fri May 24 15:37:13 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f198.google.com ([209.85.216.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UfsBE-00066H-Gt for gclcip-std-proposals@m.gmane.org; Fri, 24 May 2013 15:37:12 +0200 Original-Received: by mail-qc0-f198.google.com with SMTP id k14sf5600826qcv.5 for ; Fri, 24 May 2013 06:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-beenthere:date:from:to:message-id:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-google-group-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=ZCpGujYAmJbkrLTFM8VwR2aYbzoWOw98xvF5jYdyXwE=; b=xEbAw1hdWM1U8NVr7pHTre2kMaT+LVmP/Ewr8qnt7p4Uvj+iY3D5Sz399GPXi5+H8v 4RHgHDOFLfZZzwyppptP10VcLh+8ofE5X8PBWmPlTs/Zo7UvEowOZrofXZ5lP+JFUOzz Y8YrcYJwEYXf9WBuBys+fniGPFtIeEhqLtR7+fUdGk06Eov35penrRaWdSU/Y1PN6G3W GrQ1NewuzO3xa9uxl4MGI41mOcRKHiTbviI1rDi4dNvcyAaAlY8GOLPVMPOyfH2+GkfM 4S/mQ1RA64ATDZbIpERhIzxgRqWEThWr1zhbNMVFUAb/oxlwUivu9xzFpTcJ0rP48jYO WjRQ== X-Received: by 10.236.15.34 with SMTP id e22mr7918715yhe.16.1369402631669; Fri, 24 May 2013 06:37:11 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.0.113 with SMTP id 17ls1529056qed.28.gmail; Fri, 24 May 2013 06:37:10 -0700 (PDT) X-Received: by 10.49.1.197 with SMTP id 5mr1675601qeo.24.1369402630231; Fri, 24 May 2013 06:37:10 -0700 (PDT) X-Original-Sender: akrzemi1@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:4520 Archived-At: ------=_Part_49_30658112.1369402629855 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi everyone, While trying to figure out what should the definition of "precondition" be= =20 in C++, I collected a number of examples of potential preconditions, and=20 things that could be confused with preconditions, from the Standard=20 Library. These could serve as a basis for choosing the semantics of=20 preconditions. If you can think of any other kind of expectations on=20 function inputs that could possibly qualify for preconditions, please let= =20 me know. Regards, &rzej UB for performance reasons 21.4.5 (basic_string element access), paragraphs 1 and 3 : reference operator[](size_type pos); Requires: pos <=3D size(). Throws: Nothing. To guarantee the maximum run-time performance we require of the callers=20 that they make sure the precondition holds. Somewhat similar example: 25.4.3.4 (binary_search), paragraph 1: template bool binary_search(ForwardIterator first, ForwardIterator last, const T& value, Compare comp); Requires: The elements e of [first,last) are partitioned with respect to=20 the expressions comp(e, value) and !comp(value, e). Also, for all elements = eof[first, last),=20 comp(e, value) implies !comp(value, e). Here, most of the requirement could be expressed with C++ expressions=20 (using C++14 polymorphic lambdas): is_partitioned(first, last, [&value](auto&& e){ return comp(e, value); }); is_partitioned(first, last, [&value](auto&& e){ return !comp(value, e); }); all_of(first, last, [&value](auto&& e){ return !comp(e, value) || !comp(value, e); // antisymmetry }); However, the runtime complexity of binary_search is O(log(n)) while the=20 complexity of the precondition is O(n).=20 However, there is also one implied precondition that cannot be easily=20 expressed: first and last must form a valid range. That is, there is no=20 expression that can return true for all valid ranges and false for all=20 invalid ranges. This is somewhat similar to checking if a non-null pointer= =20 points to valid memory. =93Logical=94 error with guaranteed error report 21.4.5 (basic_string element access), paragraphs 5 - 6: reference at(size_type pos); Requires: pos < size() Throws: out_of_range if pos >=3D size(). This is accompanied by the controversial requirement from the standard=20 (17.6.4.11): =93Violation of the preconditions specified in a function=92s= =20 Requires: paragraph results in undefined behavior unless the function=92s Throws: paragraph specifies throwing an exception= =20 when the precondition is violated.=94 Here, it is very well defined what happens in case we provide the=20 out-of-range index. This makes the following program well defined: void listChars(string const& s) { int i =3D 0; try { while(true) cout << vec.at(i++); } catch(out_of_range const&) {} } The question is, why call out-of-range a =93precondition=94 if we accept it= as=20 well-defined input? What is the definition of a precondition? What is the= =20 purpose of specifying one? Is it a license to the compiler for rejecting=20 any code where it can prove that a precondition is violated? So should=20 smart compilers be allowed to reject functions like listChars above? Or is= =20 precondition only a hint on usage for other developers? Only an irregular input 20.8.11.2.4 (function invocation), paragraphs 1 and 3: R operator()(ArgTypes... args) const; Effects: INVOKE(f, std::forward(args)..., R), where f is the=20 target object of *this. Throws: bad_function_call if !*this; otherwise, any exception thrown by the= =20 wrapped callable object. 23.2.3 (Sequence containers), paragraph 17: =93The member function at() provides bounds-checked access to container=20 elements. at() throws out_of_range if n >=3D a.size().=94 In either case no precondition is specified, although we can intuitively=20 see that such inputs are =93fishy=94. Thus the following code is perfectly= =20 valid: int process(function f, int i) { try { return f(i); } catch(bad_function_call const&) { return 0; } } --=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/?hl=3Den. ------=_Part_49_30658112.1369402629855 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi everyone,

While trying to figure out what should t= he definition of "precondition" be in C++, I collected a number of examples= of potential preconditions, and things that could be confused with precond= itions, from the Standard Library. These could serve as a basis for choosin= g the semantics of preconditions. If you can think of any other kind of exp= ectations on function inputs that could possibly qualify for preconditions,= please let me know.

Regards,
&rzej


UB for performance reasons

21.4.5 (basic_string element access), paragraphs 1 and 3 :

    reference operator[](size_typ= e pos);

  = ;  Requires: pos <=3D size().

    Throws: Nothing.<= /span>

To guarantee the maximum run-time performance we require of the callers=20 that they make sure the precondition holds. Somewhat similar example:


25.4.3.4 (binary_search), paragraph 1:

template<class ForwardIterator= , class T, class Compare>

bool binary_search(ForwardIterator firs= t, ForwardIterator last,

       =            const T&a= mp; value, Compare comp);

Requires: The elements e of <= span style=3D"font-size:15px;font-family:'Courier New';color:#000000;backgr= ound-color:transparent;font-weight:normal;font-style:normal;font-variant:no= rmal;text-decoration:none;vertical-align:baseline;">[first,last) are partitioned with respect to t= he expressions = comp(e, value) and !comp(value, e). Also, for all elements e of [first, last), comp(e, value) implie= s !comp(value, = e).


Here, most of the requirement could be expressed with C++= expressions (using C++14 polymorphic lambdas):

    is_partitioned(first, last, [&value](a= uto&& e){

return comp(e, value);

})= ;

is_partitioned(first, last, [&value](auto&& e){=

return !comp(value, e);

<= span style=3D"font-size:15px;font-family:'Courier New';color:#000000;backgr= ound-color:transparent;font-weight:normal;font-style:normal;font-variant:no= rmal;text-decoration:none;vertical-align:baseline;">});

all_of(first= , last, [&value](auto&& e){

    return !c= omp(e, value) || !comp(value, e); // antisymmetry

});

However, the runtime complexity of binary_search is O(log(n)) whi= le the complexity of the precondition is O(n).=


However, there is also one implied = precondition that cannot be easily expressed: first and last must form a val= id range. That is, there is no expression that can return true for all valid ranges and false for all invalid ranges. This is somewhat similar to check= ing if a non-null pointer points to valid memory.

=93Logical=94 error with guarantee= d error report

21.= 4.5 (basic_stri= ng element access), par= agraphs 5 - 6:

reference at(size_type pos);

Requires: pos < size()

Throws: out_of_range if = pos >=3D siz= e().


This is accompanied by the controversial requirement from the standard=20 (17.6.4.11): =93Violation of the preconditions specified in a function=92s = Requires: paragraph results in undefined behav= ior

unless the func= tion=92s Throws:= paragraph specifies throwing = an exception when the precondition is violated.=94

Here, it is very well defined what happens in case we provide the=20 out-of-range index. This makes the following program well defined:

void listChars(strin= g const& s)

{

int i =3D 0;

<= span style=3D"font-size:15px;font-family:'Courier New';color:#000000;backgr= ound-color:transparent;font-weight:normal;font-style:normal;font-variant:no= rmal;text-decoration:none;vertical-align:baseline;">try {

while(true) cout << vec.at(i++);

}

catch(out= _of_range const&) {}

}


The question is, why call out-of-range a =93precondition=94 if we accept it as= =20 well-defined input? What is the definition of a precondition? What is=20 the purpose of specifying one? Is it a license to the compiler for=20 rejecting any code where it can prove that a precondition is violated?=20 So should smart compilers be allowed to reject functions like listChars above? Or is precondition only a hint on= usage for other developers?

Only an irregular input

20.8.11.2.4 (function invocation), paragraphs 1 and 3:

    R operator()(ArgTypes... args) const;<= /p>

Effects:= INVOKE(f, std::forward<ArgTypes>= ;(args)..., R), where <= /span>f is the target object of *this.

Throws: = bad_function_call if !*this; otherwise, any exception thrown = by the wrapped callable object.


23.2.3= (Sequence containers), paragraph 17:

=93The member function at() provides bounds-checked access to container elements. at() throws out_of_range if = n >=3D a.size().=94<= /span>


In either case no precondition is specified, although we can intuitively=20 see that such inputs are =93fishy=94. Thus the following code is perfectly= =20 valid:


int p= rocess(function<int(int)> f, int i)

{

try {

<= p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt;ma= rgin-left: 72pt;"> &nb= sp;return f(i);

}

catch(bad_function_call const&) {

    return 0;

}

}

--
 
---
You received this message because you are subscribed to the Google Groups &= quot;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-pro= posals/?hl=3Den.
 
 
------=_Part_49_30658112.1369402629855-- .