220 6063 article Path: news.gmane.org!not-for-mail From: tomaszkam@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Could "dumb" pointer (N3740) be implemented using strong typedef (3741) ? Date: Sun, 1 Sep 2013 01:54:39 -0700 (PDT) Lines: 103 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1280_25332920.1378025679550" X-Trace: ger.gmane.org 1378025679 25465 80.91.229.3 (1 Sep 2013 08:54:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Sep 2013 08:54:39 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDNPVXXG6IGBBUEBRSIQKGQEKWZE6GY@isocpp.org Sun Sep 01 10:54:43 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f200.google.com ([209.85.214.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VG3Qg-0000pS-8H for gclcip-std-proposals@m.gmane.org; Sun, 01 Sep 2013 10:54:42 +0200 Original-Received: by mail-ob0-f200.google.com with SMTP id wd6sf13782292obb.7 for ; Sun, 01 Sep 2013 01:54:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=jv14vGMpoZULGI9b0xuRn+nwi63hdxoSozWiwC7gxCI=; b=uKgiS7PjxCkvNabCDPpuQHWhl7InXvfUmxf9mfyRVvmDi0BmC7HmUbPOR8e0SH/nrO pm70Ikt6HX7Y3Px0lrNzlMGaI0cbQz1hQXnYGO2rEmigDqFkI9JsICfnsyxd/C4S1aKJ qES01tBb1UYVbFpbvAQF8nuZb9YeI7bXh3XDimHWT6+8HwRMAv+SmacEebxBkWY5LGo3 Pc35/HOPxyKbekz4ABtdEIaqSAeUF/oNwKFIFEQOextf0K0KguaTEf11MRCAMDysm4Bs HoJJg6AMyz+ViJS4KM3O0eaa21/AviVsmSIoGa6T2Ax1U3IyjetGbGW4APdWmuGaGGvr Nn/Q== X-Received: by 10.182.148.230 with SMTP id tv6mr3646674obb.42.1378025680551; Sun, 01 Sep 2013 01:54:40 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.34.198 with SMTP id b6ls328790obj.18.gmail; Sun, 01 Sep 2013 01:54:40 -0700 (PDT) X-Received: by 10.182.33.4 with SMTP id n4mr20521obi.9.1378025679995; Sun, 01 Sep 2013 01:54:39 -0700 (PDT) In-Reply-To: X-Original-Sender: tomaszkam@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:6063 Archived-At: ------=_Part_1280_25332920.1378025679550 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable I think it could be done if the current semantics is accepted - merged=20 single-object and array-element representation, but I think that this two= =20 semantics should be spitted off. See:=20 https://groups.google.com/a/isocpp.org/forum/?fromgroups#!topic/std-proposa= ls/1V6Ez7RKrsk W dniu niedziela, 1 wrze=B6nia 2013 10:32:27 UTC+2 u=BFytkownik Klaim - Jo= =EBl=20 Lamotte napisa=B3: > > All is in the subject: > Can an implementation using strong typedefs=20 > http://isocpp.org/files/papers/n3741.pdf > be equivalent to the current dumb pointer specification:=20 > http://isocpp.org/files/papers/n3740.pdf > ? > > That is, something like: > > template< typename T > > using dumb_ptr =3D private T* { // or maybe protected is more correct? > dumb_ptr() { *this =3D nullptr; } // necessary for helping=20 > correctness, but have a minor performance cost > }; > > At first it looks likely but I'm not an expert in the standard wording so= =20 > I might have missed something. > > If I'm correct, then it would be easy to define other kind of pointer=20 > names that just differ in the=20 > documentation -through the name- but are not compatible. It would be=20 > useful for both library > implementers and end-users. > > Joel Lamotte > > --=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_1280_25332920.1378025679550 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable
I think it could be done if the current semantics is accep= ted - merged single-object and array-element representation, but I think th= at this two semantics should be spitted off.
See: https://groups.google.= com/a/isocpp.org/forum/?fromgroups#!topic/std-proposals/1V6Ez7RKrsk

= W dniu niedziela, 1 wrze=B6nia 2013 10:32:27 UTC+2 u=BFytkownik Klaim - Jo= =EBl Lamotte napisa=B3:
All is in the subject:
Can an implementation using strong type= defs http://isocpp.org/files/papers/n3741.pdf
be equivalent to= the current dumb pointer specification: http://isocpp.org/files/pape= rs/n3740.pdf
?

That is, something like:

template< typename T >
using dumb_ptr =3D private T* {    // or maybe protected is= more correct?
      dumb_ptr() { *this =3D nullptr;= }  // necessary for helping correctness, but have a minor performance= cost
};

At first it looks likely but I'm not an expert in the standard wo= rding so I might have missed something.

If I'm correct, then it woul= d be easy to define other kind of pointer names that just differ in the&nbs= p;
documentation -through the name- but are not compatible. It would be useful= for both library
implementers and end-users.

Joel Lamotte

--
 
---
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-proposals/<= /a>.
------=_Part_1280_25332920.1378025679550-- .