220 15083 article Path: news.gmane.org!not-for-mail From: Jonathan Coe Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Reinitializing immutable objects Date: Mon, 15 Dec 2014 21:49:09 +0000 Lines: 189 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-C6A4A5A4-11B5-4E4E-8D56-4B92AB8D0170 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1418680164 681 80.91.229.3 (15 Dec 2014 21:49:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 15 Dec 2014 21:49:24 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBC2JVFPBRAHBBWFOXWSAKGQETRKLXPQ@isocpp.org Mon Dec 15 22:49:13 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ee0-f69.google.com ([74.125.83.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Y0dVx-0004yD-KN for gclcip-std-proposals@m.gmane.org; Mon, 15 Dec 2014 22:49:13 +0100 Original-Received: by mail-ee0-f69.google.com with SMTP id d49sf8135655eek.8 for ; Mon, 15 Dec 2014 13:49:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :mime-version:subject:message-id:date:references:in-reply-to: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; bh=ojViMkaDSUJ9nJf3rkDo9G7vMA5OIgqU+1NQRFUK9ug=; b=G/03/D4OTqGwUp5gnUnZP8/eUQEKq2jYTSDYygwD5nKT2ICtjE7DZY/m97DW15x4Ev k0CD3BncAmLMoX92IPu8is4JguKNF5uRT/pKJcgYIz8cNijaSZHu38bHUzBE+vtwhj9G YJ0deksYUKDKR1eJ7t3Ef5l6R5Lpqueu+42rIFUgQi6cRLWUmMisZIBGDOpqHlWGYkSA J+VpJykRZYoolF/rzRuK1ySYB1rk6lf8R1OJCbzNJT0IVl8pOqbURf43GdLuEcIphFL6 pxzCUO5Q9+fFry/Zm96HQYLlfobDa5hU3EQg6l8E9hMwNe+9RDU0YFbMVleBantnNMF6 Qzaw== X-Gm-Message-State: ALoCoQkpEOI7nu33DXBj3vXHPx4twTWGwcIlvvqkVbSiJYqO4F1Uyr0u6UhT11egFtHVz/GPq3mv X-Received: by 10.180.7.226 with SMTP id m2mr2452025wia.5.1418680153200; Mon, 15 Dec 2014 13:49:13 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.93.130 with SMTP id cu2ls22065wib.43.gmail; Mon, 15 Dec 2014 13:49:12 -0800 (PST) X-Received: by 10.180.228.37 with SMTP id sf5mr35255637wic.35.1418680151997; Mon, 15 Dec 2014 13:49:11 -0800 (PST) Original-Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com. [2a00:1450:400c:c05::231]) by mx.google.com with ESMTPS id g15si18693997wiw.78.2014.12.15.13.49.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Dec 2014 13:49:11 -0800 (PST) Received-SPF: pass (google.com: domain of jonathanbcoe@gmail.com designates 2a00:1450:400c:c05::231 as permitted sender) client-ip=2a00:1450:400c:c05::231; Original-Received: by mail-wi0-f177.google.com with SMTP id l15so10533948wiw.16 for ; Mon, 15 Dec 2014 13:49:11 -0800 (PST) X-Received: by 10.180.98.197 with SMTP id ek5mr35249083wib.35.1418680151518; Mon, 15 Dec 2014 13:49:11 -0800 (PST) Original-Received: from [10.2.82.24] (dab-ntm1-h-28-7.dab.02.net. [82.132.230.182]) by mx.google.com with ESMTPSA id u18sm8387912wjq.42.2014.12.15.13.49.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Dec 2014 13:49:10 -0800 (PST) In-Reply-To: X-Mailer: iPhone Mail (12B440) X-Original-Sender: jonathanbcoe@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of jonathanbcoe@gmail.com designates 2a00:1450:400c:c05::231 as permitted sender) smtp.mail=jonathanbcoe@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:15083 Archived-At: --Apple-Mail-C6A4A5A4-11B5-4E4E-8D56-4B92AB8D0170 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would worry that references to the supposedly immutable object would be l= ogically invalidated. > On 15 Dec 2014, at 19:50, tl wrote: >=20 > You sometimes want to have classes with variables that cannot be changed = after the object has been created. For example: >=20 > class point_cloud { > private: > point* const buffer_; > const std::size_t buffer_size_; > const std::string original_name_; >=20 > public: > explicit point_cloud(point_cloud_reader&); > ~point_cloud(); >=20 > ... > }; >=20 > Here the buffer is allocated only once on construction, and all of its va= riables cannot be changed afterwards. However it is still possible to chang= e the contents of the buffer. Imposing such restrictions on a class can oft= en simplify coding, since you don't have to define semantics for assignment= , or handling side effects of changing properties of an object that are als= o defined at construction. >=20 > For example a class representing a camera in 3D space might contain both = a projection matrix and its inverse. It would have to be recalculated each = time the camera's parameters are changed. But it would also have been possi= ble to just create a new camera instance with new parameters. So the class = could be left immutable, avoiding overcomplicating the code without much ga= in in functionality. >=20 > The only problem is that immutable objects cannot implement an assignment= operator=3D, since this is meant to change the object, and not create a ne= w one in-place. To reuse the same variable, a possible workaround currently= is to use call destructor and then use placement new: >=20 > immutable obj(1, 2); > obj.f(); > //obj =3D immutable(2, 3); not possible, instead: > obj.~ immutable(); > new(&obj) immutable(2, 3); > obj.f(); >=20 > Eigen actually recommends this for its Map class: http://eigen.tuxfamily.= org/dox/group__TutorialMapClass.html. >=20 > My idea would be to introduce reinitialization of objects as a language f= eature or into the STL library. std::optional currently expect the object t= o be assignable if an engaged optional is reassigned a new value. If it is = not engaged however, it constructs a new object as above. Maybe introduce a= class: >=20 > std::reusable obj(1, 2); > obj->f(); > obj.replace(1, 2); > obj->f(); >=20 > Or maybe an alternative operator to the assignment operator that destruct= s the object and creates a new one in-place. > --=20 >=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= 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-propo= sals/. --=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/. --Apple-Mail-C6A4A5A4-11B5-4E4E-8D56-4B92AB8D0170 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would worry that references to t= he supposedly immutable object would be logically invalidated.


<= /div>

On 15 Dec 2014, at 19:50, tl <timlenertz@gmail.com> wrote:

You sometimes want to have classes with v= ariables that cannot be changed after the object has been created. For exam= ple:

class point_c= loud {
private:
    point* con= st buffer_;
  &= nbsp; const std::size_t buffer_size_;
    const std::string original_name_;

public:
    explicit point_cloud(point_cloud_reader&am= p;);
    ~= point_cloud();

<= /font>
    ...
};
Here the buffer is allocated only once on construction, and al= l of its variables cannot be changed afterwards. However it is still possib= le to change the contents of the buffer. Imposing such restrictions on a cl= ass can often simplify coding, since you don't have to define semantics for= assignment, or handling side effects of changing properties of an object t= hat are also defined at construction.

For example = a class representing a camera in 3D space might contain both a projection m= atrix and its inverse. It would have to be recalculated each time the camer= a's parameters are changed. But it would also have been possible to just cr= eate a new camera instance with new parameters. So the class could be left = immutable, avoiding overcomplicating the code without much gain in function= ality.

The only problem is that immutable objects = cannot implement an assignment operator=3D, since this is meant to change t= he object, and not create a new one in-place. To reuse the same variable, a= possible workaround currently is to use call destructor and then use place= ment new:

im= mutable obj(1, 2);
o= bj.f();
//obj =3D im= mutable(2, 3);   not possible, instead:
obj.~ immutable();
new(&obj) immutable(2, 3);
obj.f();

Eigen actually recommends this for its Map class: http://eigen.tuxfamily.org/= dox/group__TutorialMapClass.html.

My idea woul= d be to introduce reinitialization of objects as a language feature or into= the STL library. std::optional currently expect the object to be assignable if= an engaged optional is reassigned a new value. If it is not engaged howeve= r, it constructs a new object as above. Maybe introduce a class:
=
std::reusable<immut= able> obj(1, 2);
= obj->f();
obj.rep= lace(1, 2);
obj->= f();

Or maybe an alternative operator to the assignment operator that des= tructs the object and creates a new one in-place.

--

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

--

---
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>.
--Apple-Mail-C6A4A5A4-11B5-4E4E-8D56-4B92AB8D0170-- .