220 19843 article Path: news.gmane.org!not-for-mail From: "U.Mutlu" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal: "offset" pointers and "offset" references Date: Thu, 13 Aug 2015 17:25:14 +0200 Organization: mutluit.com Lines: 107 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: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1439479536 24434 80.91.229.3 (13 Aug 2015 15:25:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Aug 2015 15:25:36 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCZ6RLW3UIKBBZPNWKXAKGQEHUADDFY@isocpp.org Thu Aug 13 17:25:27 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-la0-f70.google.com ([209.85.215.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZPuNi-00083W-Aa for gclcip-std-proposals@m.gmane.org; Thu, 13 Aug 2015 17:25:26 +0200 Original-Received: by labth1 with SMTP id th1sf18145066lab.2 for ; Thu, 13 Aug 2015 08:25:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:date:organization:lines :message-id:references:mime-version:content-type :content-transfer-encoding:user-agent:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=y71CSNc7Xeg56+h8TehBuH23phruSuEeTx10M+vgYOA=; b=im5mJKRQ6n77ChfrNwF6gv052tWm7qm9VqAF4snD6uwOL9Q+bRw9EkxXjFtbkyIfXV vU5WKSA29YRAS3edGtc1NmKtDQ7XyDUahr3NU3KUUIznB3YZOpiWBW++xyncoYpiof2I xaFjDHtuLmE6dJhDoSmmO9ESEpy3jWpA+oJnQA9Xt8l+bJCozNNAsJC85SOqouvlfZyY PnUe+nKDfJJhq6igSJoqoqLhNSFGWVafKlKXxiSeB4dtx8W3TuGGK2bujIBULf6kApTC pZay1hLlsB3oeCy4lhccqmIr9ZPy X-Gm-Message-State: ALoCoQmYSjO6vHTvwMhGjks2dDHbD2Yc251eE1tE4vxjbhIytSEizoaiXP0BwSihRVm+IRxWrPGt X-Received: by 10.152.45.101 with SMTP id l5mr9645408lam.7.1439479525968; Thu, 13 Aug 2015 08:25:25 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.179.130 with SMTP id dg2ls200565lac.108.gmail; Thu, 13 Aug 2015 08:25:24 -0700 (PDT) X-Received: by 10.112.72.8 with SMTP id z8mr36879628lbu.24.1439479524554; Thu, 13 Aug 2015 08:25:24 -0700 (PDT) Original-Received: from plane.gmane.org (plane.gmane.org. [80.91.229.3]) by mx.google.com with ESMTPS id r1si2835552lar.2.2015.08.13.08.25.24 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 13 Aug 2015 08:25:24 -0700 (PDT) Received-SPF: pass (google.com: domain of gclcip-std-proposals@m.gmane.org designates 80.91.229.3 as permitted sender) client-ip=80.91.229.3; Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZPuNd-0007zB-GT for std-proposals@isocpp.org; Thu, 13 Aug 2015 17:25:21 +0200 Original-Received: from ip4d150b15.dynamic.kabel-deutschland.de ([77.21.11.21]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 13 Aug 2015 17:25:21 +0200 Original-Received: from for-gmane by ip4d150b15.dynamic.kabel-deutschland.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 13 Aug 2015 17:25:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 100 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip4d150b15.dynamic.kabel-deutschland.de User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0 SeaMonkey/2.37a1 In-Reply-To: X-Original-Sender: gclcip-std-proposals@m.gmane.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of gclcip-std-proposals@m.gmane.org designates 80.91.229.3 as permitted sender) smtp.mailfrom=gclcip-std-proposals@m.gmane.org Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:19843 Archived-At: U.Mutlu wrote on 08/13/2015 05:08 PM: > David Rodr=C3=ADguez Ibeas wrote on 08/13/2015 03:31 PM: >> What would be the use case for this feature? Avoiding having to write th= e >> copy-constructor and assignment operator? For what subset of types? >> >> I don't see any good use case off the top of my head. In the example yo= u >> provided, 'p' is not needed at all and the type could do without it >> altogether. > > Think of some more complex types of pointers and references within > the object pointing/referencing locations inside the same object. > > The main benefit would be having pointers and references in STL container > items which point to other local objects within the item. They would alwa= ys > automatically keep their validity. > > Currently, pointers and references in such container items will not funct= ion > properly; one has to reset/set the pointers before first use and before typo: of course not before but "after" was meant. > the container changes its state (adding/inserting/removing/resizing). > And: references are totally lost in such a situation, ie. there is > not even a workaround for plain references. > > The solution to all these problems would bring the proposed offset ptrs a= nd > offset references. > > >> For types that implement a small-object optimization and opt to use a >> pointer to the internal small object when the optimization is in place t= he >> features would not help as the pointer 'p' could be either an offset int= o >> the object or otherwise a pointer to allocated memory outside of the obj= ect. > > It is usually intended for pointing to adresses within the "scope" only, > ie. within the object the internal "this" pointer represents. > >> This seems to be aiming to remove a small burden (having to provide >> copy-constructor/assignment, having to update one more member in the res= t >> of the constructors) in a very small subset of types. > > As shown in the example I create the objects mostly on the stack and > just pass it to the STL containers. This works fine. But if the object > contains pointers or references then these will point/reference wrong > locations when the container changes its mem-buf due to realloc etc.). > >> >> David >> >> On Thu, Aug 13, 2015 at 1:40 PM, U.Mutlu wrote: >> >>> Proposal: "offset" pointers and "offset" references >>> >>> In the example below p shall be an "offset" pointer off the start >>> of its scope, ie. off the "this" ptr: >>> >>> struct TS >>> { >>> const int iId; >>> char buf[4096]; >>> offset char* p; // uses proposed "offset" keyword >>> TS(const int AiId) : iId(AiId), p(buf) {} >>> }; >>> >>> vector v; >>> for (size_t i =3D 0; < N; ++i) >>> v.push_back(TS(i)); >>> >>> By this method, p always stays valid, unlike the current situation >>> with normal ptrs and refs if structs/classes with ptrs and/or refs >>> are used within items for STL containers. >>> >>> For the "offset reference" a similar method would be used, as refs buil= d >>> on ptrs. >>> >>> Internally the compiler would need to store the offset number(s) >>> in the object's virtual part, much like the case with vtab, >>> and update such offset ptrs and offset refs as soon as "this" changes >>> when copying etc., ie. when an object is created via copy-ctor, >>> assignment-op etc. > > > --=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/. .