220 5956 <82e8d6bc-c6a3-441d-8079-d385cd4f1238@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nick Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Properties Syntax Date: Wed, 28 Aug 2013 15:30:18 -0700 (PDT) Lines: 510 Approved: news@gmane.org Message-ID: <82e8d6bc-c6a3-441d-8079-d385cd4f1238@isocpp.org> References: <5e23a0e9-2bd9-4f62-aa83-47bea8144eae@isocpp.org> <1377717206.3009.5.camel@sara> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_819_7158214.1377729018440" X-Trace: ger.gmane.org 1377729018 22564 80.91.229.3 (28 Aug 2013 22:30:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 Aug 2013 22:30:18 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC42HSUOVYGBB67T7GIAKGQEFF6VVQA@isocpp.org Thu Aug 29 00:30:21 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f199.google.com ([209.85.214.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VEoFo-0007J8-I8 for gclcip-std-proposals@m.gmane.org; Thu, 29 Aug 2013 00:30:21 +0200 Original-Received: by mail-ob0-f199.google.com with SMTP id dn14sf25669451obc.6 for ; Wed, 28 Aug 2013 15:30:19 -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=tnjxbtQ8ZSoU/H27TObwds2tAnZDkxqfTbzRfBWqXUU=; b=y+dFJl9ZM62pVUPEOsxiE8HXBMstZwZ99b+w7XhQSqRtijasdSvTwSpmiexrw25HSo 3siXMyPDna9xe3ykmZre8tWaB8G2BI2zSWcgEKND1f13dXfEyhEW7mk9wUPLEEOcLcfw zTuY9xWccAYmNq2muQHzwOIIBHDwIkHpmccJM6SaI0U3vjZUhkWDaO3VO6U+le/veyYV b329JNP5Zf5U5Fum0lkkK0Up7gPckqODciJ+AqNg2Sz4Y2Cv5c7wp2DWF+CinerEo8HL sL7xODbTYe3RoqN/5qOt1rCrt0BboFdjdBrqU/6gc5bicJSHhZdCcKuTLbsANLLpWpWp co/w== X-Received: by 10.182.148.230 with SMTP id tv6mr22626obb.42.1377729019411; Wed, 28 Aug 2013 15:30:19 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.12.231 with SMTP id b7ls608673qec.68.gmail; Wed, 28 Aug 2013 15:30:18 -0700 (PDT) X-Received: by 10.49.94.39 with SMTP id cz7mr7472qeb.26.1377729018955; Wed, 28 Aug 2013 15:30:18 -0700 (PDT) In-Reply-To: X-Original-Sender: nicolas.jinchereau@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:5956 Archived-At: ------=_Part_819_7158214.1377729018440 Content-Type: text/plain; charset=ISO-8859-1 On Wednesday, 28 August 2013 17:24:44 UTC-4, Richard Smith wrote: > On Wed, Aug 28, 2013 at 12:52 PM, Nick > > wrote: > >> I have to disagree with this. >> >> With Richard's implementation, taking sizeof(property) yields 48 >> bytes. >> >> So if you had an object with 10 properties, you would have a half a >> kilobyte of extra data per instance. >> >> The function pointers can be done away with using some very convoluted >> template syntax, but the reference to the container must still exist, >> making the minimum possible size of a library based property 4 bytes, which >> is still not negligible. >> > > Yes, the code I presented is not ideal, in a number of ways. The storage > overhead is one. Another is that "a.number = b.number" does not compile, > and classes containing such properties become non-copyable ("a.number = > b.number;" would need to do different things depending on whether it > happens in the surrounding class's copy-assignment operator). > > But... if we can find a set of language changes that suffice to make a > library implementation of properties work better, we are likely to improve > the language as a whole rather than adding a single point feature. > There are several more problems with library properties beside the storage overhead. Let's consider that we used the following template implementation, which still takes 4 bytes per property: template struct property { C *object; property(C *object) : object(object){} operator T() { return (object->*get)(); } template property &operator=(U &&u) { (object->*set)(std:: forward(u)); return *this; } } 1) But consider using it on a Point: struct Point { float x, y; Point(float x = 0, float y = 0) : x(x), y(y){} }; How would you provide access to the members of Point with library properties? struct Test { property point; }; Test test; cout << test.point.x << endl; Currently, the only option available is to override T* operator->() const T* property::operator->() { return &(object->*get)(); } but unless C::get() returns a reference, which it very likely won't, then this code will be returning a reference to a temporary. This may not cause problems, since that temporary is read only, but may will fail to compile or generate warnings on some compilers. 2) No function overloading could be done for the setter. 3) specific functionality of the property's type would be hidden: Consider if Point had operator+=() Point& operator+=(const Point &p) { x += p.x; y += p.y; return *this; } The following code would not compile: test.point += Point(5, 6); Whereas, with a real property, the get and set methods of the property could be called to retrieve and store the value. Now, a partial solution may be to include commonly used operators inside the property class: template property &operator+=(U &&u) { T tmp = (object->*get)(); tmp += u; (object->*set)(std::forward(tmp)); return *this; } And since this is a template, I'm pretty sure(vs2012 and mingw tested) it should be ignored for classes that don't have an operator+= unless you actually try to use it, but that doesn't fix the problem that you still have to include every operator manually into your property class. If you started to use a class that had a ToString() method, now you would need to incorporate that into your property too, and the list would go on endlessly. 4) Finally if something like offsetof() was standardized to work on non-POD types, there would be a way to get rid of that last 4 bytes per property, but currently, it is not. And I say "something like" because assuming that offsetof() did work, it would still require macros to get the job done. A real piece of builtin compiler magic would still be needed to get a pointer to the enclosing instance of an object. Now, this is just the begining, but I'm sure I could go on for a few more hours at least. -- --- 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_819_7158214.1377729018440 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wednesday, 28 August 2= 013 17:24:44 UTC-4, Richard Smith wrote:
On Wed, Aug 28, 2013 at 12:52 PM, Ni= ck <nicolas.j...@gmail.com> wrote:=
I have to disagree with this.

With Richard's implementation, taking sizeof(property<= int>) yields 48 bytes.

So if you had an object = with 10 properties, you would have a half a kilobyte of extra data per inst= ance.

The function pointers can be done away with using some = very convoluted template syntax, but th= e reference to the container must still exist, making the minimum possible = size of a library based property 4 bytes, which is still not negligible.

Yes, the code I presented is not ide= al, in a number of ways. The storage overhead is one. Another is that "a.nu= mber =3D b.number" does not compile, and classes containing such properties= become non-copyable ("a.number =3D b.number;" would need to do different t= hings depending on whether it happens in the surrounding class's copy-assig= nment operator).

But... if we can find a set of language changes that su= ffice to make a library implementation of properties work better, we are li= kely to improve the language as a whole rather than adding a single point f= eature.
 


There are several more problems with library propertie= s beside the storage overhead.

Let's consider that= we used the following template implementation, which still takes 4 bytes p= er property:

template= <typename T, class C, T(C::*get)(), void(C= ::*set)(T)>
struct property {
    C *object;
    property(C *ob= ject) : object(object){}

    operator T() { return (object->*get)(); }=
 =   te= mplate<= typename U> property &operator=3D(U &&u) { = (object->*set)(std::forward<U>(= u)); return *this; }
}

1) But consider= using it on a Point:

struct Point
<= span style=3D"color: #660;" class=3D"styled-by-prettify">{
    float x,= y;
  &n= bsp; Point= (float x =3D 0, float y <= /span>=3D<= span style=3D"color: #000;" class=3D"styled-by-prettify"> 0) : x(x), y(y){}
};

How would you provide access to the members of Point with library proper= ties?

struct Test {
    property<Point, ...>= point;
};

Test test;
cout << test.point.x << endl;

Currently, the only option available is to over= ride T* operator->()

const T= * property::operator->() { return &(= object->= ;*get)(); }
<= br>but unless C::get() returns a reference, which it very likely won't, the= n this code will be returning a reference to a temporary. This may not caus= e problems, since that temporary is read only, but may will fail to compile= or generate warnings on some compilers.

2) <= span style=3D"font-size: 13px;">No function overloading could be done for t= he setter.

3) specific functionality of the p= roperty's type would be hidden:

Consider if P= oint had operator+=3D()
<= br>
Poi= nt& operator+=3D(const Point &p) { x +=3D p.x; y += =3D p.y; return *this; }
=

The following code would not compile:

test.point +=3D Point(5,= 6);

Whe= reas, with a real property, the get and set methods of the property could b= e called to retrieve and store the value.

No= w, a partial solution may be to include commonly used operators inside the = property class:

templ= ate<typename U>
property &operator+=3D(U &&u) {    T tmp =3D (object= ->*get)();
    tmp +=3D u;
    (object->*set)(std::forward<U>(= tmp= ));
&nbs= p;   return *this;
}
<= br>
And since this is a template, I'm pretty sure(vs2012 an= d mingw tested) it should be ignored for classes that don't have an operato= r+=3D unless you actually try to use it, but that doesn't fix the problem t= hat you still have to include every operator manually into your property cl= ass.

If you started to use a class that had a ToSt= ring() method, now you would need to incorporate that into your property to= o, and the list would go on endlessly.

4) Finally if something like offsetof() was stan= dardized to work on non-POD types, there would be a way to get rid of that = last 4 bytes per property, but currently, it is not. And I say "something l= ike" because assuming that offsetof() did work, it would still require macr= os to get the job done. A real piece of builtin compiler magic would still = be needed to get a pointer to the enclosing instance of an object.


Now, this is just the begining, but = I'm sure I could go on for a few more hours at least.

<= /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/group/std-proposals/<= /a>.
------=_Part_819_7158214.1377729018440-- .