220 5953 article Path: news.gmane.org!not-for-mail From: Ville Voutilainen Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Properties Syntax Date: Wed, 28 Aug 2013 23:22:04 +0300 Lines: 98 Approved: news@gmane.org Message-ID: 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=001a11c3d73c20a3cf04e507be28 X-Trace: ger.gmane.org 1377721329 4340 80.91.229.3 (28 Aug 2013 20:22:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 Aug 2013 20:22:09 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC5JHI7A7ALRB3VX7GIAKGQEKR5QOHI@isocpp.org Wed Aug 28 22:22:12 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vc0-f199.google.com ([209.85.220.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VEmFj-0002SJ-IB for gclcip-std-proposals@m.gmane.org; Wed, 28 Aug 2013 22:22:07 +0200 Original-Received: by mail-vc0-f199.google.com with SMTP id gf11sf7257262vcb.2 for ; Wed, 28 Aug 2013 13:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from: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=I1gAjnIobMufL4tymy46Lj+rScgzASlTKflT3uxSsNQ=; b=EFJCqp4yNn6+9/i/wV3AOHCDwIPboMIa3ArurPsoUm3a5UMP2rAryfiznus6zGrYFu 7Ks//+msMF39TUSNu8tPZbXTnH9MZpabSXPwZV0ubuzZwyYUlSXC0hPhCkxme87Il3fq fNi58MlFbS/ur39TjjzxSIga48bZ5eTXcETYf3KL7vVeZ7LyLf7aCvOnDjjf//565BOY 4MC6yPtm4amuylX202y0WMI7MLTI9CW/3AIcwSj8vGtfE5KCJ0G2Bwd9N+1zzDz58VPe SkANb6KkOKIT6I2oLZLW6A39yDtCvniho9rWihV+rNNWpXz9kXvVnJ9SXWUNPIyM37AK 1Xqg== X-Received: by 10.236.24.195 with SMTP id x43mr10666205yhx.3.1377721326688; Wed, 28 Aug 2013 13:22:06 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.12.231 with SMTP id b7ls559332qec.68.gmail; Wed, 28 Aug 2013 13:22:05 -0700 (PDT) X-Received: by 10.49.58.229 with SMTP id u5mr4274000qeq.89.1377721325343; Wed, 28 Aug 2013 13:22:05 -0700 (PDT) Original-Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [2607:f8b0:400d:c01::229]) by mx.google.com with ESMTPS id z18si10728qct.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Aug 2013 13:22:04 -0700 (PDT) Received-SPF: pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400d:c01::229 as permitted sender) client-ip=2607:f8b0:400d:c01::229; Original-Received: by mail-qc0-f169.google.com with SMTP id k8so2424100qcq.28 for ; Wed, 28 Aug 2013 13:22:04 -0700 (PDT) X-Received: by 10.224.67.134 with SMTP id r6mr593061qai.24.1377721324182; Wed, 28 Aug 2013 13:22:04 -0700 (PDT) Original-Received: by 10.224.195.8 with HTTP; Wed, 28 Aug 2013 13:22:04 -0700 (PDT) In-Reply-To: X-Original-Sender: ville.voutilainen@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400d:c01::229 as permitted sender) smtp.mail=ville.voutilainen@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) d=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:5953 Archived-At: --001a11c3d73c20a3cf04e507be28 Content-Type: text/plain; charset=ISO-8859-1 On 28 August 2013 22:52, Nick wrote: > I have to disagree with this. > > With Richard's implementation, taking sizeof(property) yields 48 > bytes. > Very likely, it's using std::function which is not the lightest or fastest thing on the planet. > > > 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. > > > Well... I have no trouble making the functions smaller, just by avoiding std::function. The trouble with such solutions is that I would need a combination of an auto member and a maker function (the call to which would be a non-static data member initializer) to make it really palatable. I can store data inside a property, avoiding the "reference to the container". The library approach is not without downsides, but some of them are fixable. At any rate, fixing those downsides would be worth trying before we run head-over-heels towards standardizing property keywords. -- --- 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/. --001a11c3d73c20a3cf04e507be28 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 28 August 2013 22:52, Nick <nicolas.jinchereau@gmail= ..com> wrote:
I have to disagree with this.

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

V= ery likely, it's using std::function which is not the lightest or faste= st thing on the planet.
=A0


<= /div>
The function pointers can be done away with using some very convo= luted template syntax,=A0but the reference t= o the container must still exist, making the minimum possible size of a lib= rary based property 4 bytes, which is still not negligible.


=

Well... I have no trouble maki= ng the functions smaller, just by avoiding std::function. The trouble with = such
solutions is that I would need a combination of an auto member and a maker = function (the call to which would be
a non-static data member initialize= r) to make it really palatable.

I can store data inside a= property, avoiding the "reference to the container".

The library approach is no= t without downsides, but some of them are fixable. At any rate, fixing thos= e downsides
would be worth trying before we run head-over-heels towards = standardizing property keywords.

--
 
---
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>.
--001a11c3d73c20a3cf04e507be28-- .