220 11735 article Path: news.gmane.org!not-for-mail From: "J. Daniel Garcia" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Value constraints (or contract programming in C++) Date: Wed, 9 Jul 2014 17:56:20 +0200 Lines: 194 Approved: news@gmane.org Message-ID: References: <6da50966-e3d3-441d-8474-614a51b035df@isocpp.org> <3D5B2169-72D6-473E-87DF-32D6D159A455@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=90e6ba212347369e8804fdc4c2b1 X-Trace: ger.gmane.org 1404921437 25396 80.91.229.3 (9 Jul 2014 15:57:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Jul 2014 15:57:17 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCFIPGWXVYIRBTOM6WOQKGQEE46OC2Q@isocpp.org Wed Jul 09 17:57:06 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vc0-f198.google.com ([209.85.220.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X4uEw-0005KV-Jf for gclcip-std-proposals@m.gmane.org; Wed, 09 Jul 2014 17:57:02 +0200 Original-Received: by mail-vc0-f198.google.com with SMTP id hy10sf24934206vcb.9 for ; Wed, 09 Jul 2014 08:57:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=zuiByfAt7vhbF30OumeMGuI5zljXcVSsbnQMNf05suo=; b=HWEcnhchTjDUbzGqV3/b7z2Ny8UtWOPT7p+npubH1W5uJaTpFO1vc6iL0ySpolEb2a qSRWphgD/Wv87yMM2uil0g4HlE1xJrQaOzSzwU+9SgHJqoQ0rvw/NLVz29JYPZgiThE2 KjkWP3hYFVUa4HMb+H0FbbryPqnzDhv0sTD3Gpu7L9WlOR/0qS16LfFqkEBLc9FZokN/ Tji/fsNCK0cFFzFFzUkjD4l2LesbYZYn38boZjEONK6S7c4gV1ZmhdXcEgxmjlE/6P/k HIWLWxUjnvUoYhMsUBEQ26maqsmDxM7HK5JwQGi4cB17LLuzayJmrUSHtUB/dt4+zPj4 WNOA== X-Gm-Message-State: ALoCoQk3k+4248f/HFIdQdkya5gJhfBBULAUY5SpV3KoO+q4sXUq7l0u0T+cdaL3C6ujXsb8AqhW X-Received: by 10.58.186.50 with SMTP id fh18mr20784309vec.34.1404921421846; Wed, 09 Jul 2014 08:57:01 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.254.161 with SMTP id aj1ls994021igd.36.canary; Wed, 09 Jul 2014 08:57:00 -0700 (PDT) X-Received: by 10.42.107.68 with SMTP id c4mr48807296icp.60.1404921420869; Wed, 09 Jul 2014 08:57:00 -0700 (PDT) Original-Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [2607:f8b0:4001:c05::22e]) by mx.google.com with ESMTPS id hg12si72104449icb.17.2014.07.09.08.57.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Jul 2014 08:57:00 -0700 (PDT) Received-SPF: pass (google.com: domain of josedaniel.garcia.uc3m@gmail.com designates 2607:f8b0:4001:c05::22e as permitted sender) client-ip=2607:f8b0:4001:c05::22e; Original-Received: by mail-ig0-f174.google.com with SMTP id c1so2026150igq.13 for ; Wed, 09 Jul 2014 08:57:00 -0700 (PDT) X-Received: by 10.42.139.4 with SMTP id e4mr17455308icu.73.1404921420617; Wed, 09 Jul 2014 08:57:00 -0700 (PDT) Original-Sender: josedaniel.garcia.uc3m@gmail.com Original-Received: by 10.64.227.41 with HTTP; Wed, 9 Jul 2014 08:56:20 -0700 (PDT) In-Reply-To: X-Original-Sender: josedaniel.garcia@uc3m.es X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of josedaniel.garcia.uc3m@gmail.com designates 2607:f8b0:4001:c05::22e as permitted sender) smtp.mail=josedaniel.garcia.uc3m@gmail.com; dkim=pass header.i=@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:11735 Archived-At: --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 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 > wrote: > >> >> On Wed, Jul 9, 2014 at 3:45 PM, David Krauss wrote: >> >>> >>> On 2014=E2=80=9307=E2=80=9309, at 9:09 PM, Klaim - Jo=C3=ABl Lamotte >>> 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
Understood. This is something I did not think about.
<= br>
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 co= ncept of library in the language.

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=C2=A0detected=C2=A0contract fai= lure, assuming that the contract checking is actually running.
Something close to set_terminate() but as I was saying there would be a &qu= ot;need" to have one per "library".

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
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 K= rauss <potswa@gmail.com> wrote:

On 2014=E2=80=9307=E2=80=9309, at 9:09 PM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.com&= gt; 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 paper= s:
> 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.
> 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 ea= rly to explore now).

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?

If we are t= alking about a decision taken at runtime, then yes it's totally differe= nt.=C2=A0


<= /div>

--

---
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/gro= up/std-proposals/.

--

---
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-proposa= ls+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/<= /a>.
--90e6ba212347369e8804fdc4c2b1-- .