Topic: Proposal: "offset" pointers and "offset" references
Author: "U.Mutlu" <for-gmane@mutluit.com>
Date: Thu, 13 Aug 2015 14:40:27 +0200
Raw View
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
S(const int AiId) : iId(AiId), p(buf) {}
};
vector<TS> v;
for (size_t i = 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 build 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.
--
Rgds,
U.Mutlu
--
---
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/.
.
Author: "U.Mutlu" <for-gmane@mutluit.com>
Date: Thu, 13 Aug 2015 14:44:47 +0200
Raw View
<resent due to a minor typo in the struct definition>
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<TS> v;
for (size_t i = 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 build 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.
--
Rgds,
U.Mutlu
--
---
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/.
.
Author: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Thu, 13 Aug 2015 14:31:35 +0100
Raw View
--047d7b6d9baca97b54051d315af5
Content-Type: text/plain; charset=UTF-8
What would be the use case for this feature? Avoiding having to write the
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 you
provided, 'p' is not needed at all and the type could do without it
altogether.
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 the
features would not help as the pointer 'p' could be either an offset into
the object or otherwise a pointer to allocated memory outside of the object.
This seems to be aiming to remove a small burden (having to provide
copy-constructor/assignment, having to update one more member in the rest
of the constructors) in a very small subset of types.
David
On Thu, Aug 13, 2015 at 1:40 PM, U.Mutlu <for-gmane@mutluit.com> 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
> S(const int AiId) : iId(AiId), p(buf) {}
> };
>
> vector<TS> v;
> for (size_t i = 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 build
> 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.
>
> --
> Rgds,
> U.Mutlu
>
>
> --
>
> --- 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/.
>
--
---
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/.
--047d7b6d9baca97b54051d315af5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">What would be the use case for this feature? Avoiding havi=
ng to write the copy-constructor and assignment operator? For what subset o=
f types?<br><br>I don't see any good use case off the top of my head.=
=C2=A0 In the example you provided, 'p' is not needed at all and th=
e type could do without it altogether. =C2=A0<br><br>For types that impleme=
nt a small-object optimization and opt to use a pointer to the internal sma=
ll object when the optimization is in place the features would not help as =
the pointer 'p' could be either an offset into the object or otherw=
ise a pointer to allocated memory outside of the object.<br><br>This seems =
to be aiming to remove a small burden (having to provide copy-constructor/a=
ssignment, having to update one more member in the rest of the constructors=
) in a very small subset of types.<br><br>=C2=A0 =C2=A0 David</div><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Aug 13, 2015 at 1=
:40 PM, U.Mutlu <span dir=3D"ltr"><<a href=3D"mailto:for-gmane@mutluit.c=
om" target=3D"_blank">for-gmane@mutluit.com</a>></span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex">Proposal: "offset" pointers and "of=
fset" references<br>
<br>
In the example below p shall be an "offset" pointer off the start=
<br>
of its scope, ie. off the "this" ptr:<br>
<br>
struct TS<br>
=C2=A0 {<br>
=C2=A0 =C2=A0 const int=C2=A0 =C2=A0 iId;<br>
=C2=A0 =C2=A0 char=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0buf[4096];<br>
=C2=A0 =C2=A0 offset char* p;=C2=A0 =C2=A0 =C2=A0// uses proposed "off=
set" keyword<br>
=C2=A0 =C2=A0 S(const int AiId) : iId(AiId), p(buf) {}<br>
=C2=A0 };<br>
<br>
vector<TS> v;<br>
for (size_t i =3D 0; < N; ++i)<br>
=C2=A0 v.push_back(TS(i));<br>
<br>
By this method, p always stays valid, unlike the current situation<br>
with normal ptrs and refs if structs/classes with ptrs and/or refs<br>
are used within items for STL containers.<br>
<br>
For the "offset reference" a similar method would be used, as ref=
s build on ptrs.<br>
<br>
Internally the compiler would need to store the offset number(s)<br>
in the object's virtual part, much like the case with vtab,<br>
and update such offset ptrs and offset refs as soon as "this" cha=
nges<br>
when copying etc., ie. when an object is created via copy-ctor, assignment-=
op etc.<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
-- <br>
Rgds,<br>
U.Mutlu<br>
<br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b6d9baca97b54051d315af5--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 13 Aug 2015 10:04:39 -0400
Raw View
On 2015-08-13 08:40, 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
> S(const int AiId) : iId(AiId), p(buf) {}
> };
>
> 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.
Um... why? Why not just store *the actual offset*? This requires 'this'
to be given when dereferencing the pointer, but that will often be the
case anyway, and has the *TREMENDOUS* advantage that copying the pointer
*is trivial*. (See especially recent thread(s) on object relocatability!)
p.s. better example use case:
// Can use default copy/move ctors
class Foo
{
Bar bar_private;
public:
Bar const offset& bar = bar_private;
};
--
Matthew
--
---
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/.
.
Author: "U.Mutlu" <for-gmane@mutluit.com>
Date: Thu, 13 Aug 2015 17:08:48 +0200
Raw View
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 the
> 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 you
> 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 always
automatically keep their validity.
Currently, pointers and references in such container items will not functio=
n=20
properly; one has to reset/set the pointers before first use and before
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 and=
=20
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 th=
e
> features would not help as the pointer 'p' could be either an offset into
> the object or otherwise a pointer to allocated memory outside of the obje=
ct.
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 rest
> 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 <for-gmane@mutluit.com> 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<TS> 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 build
>> 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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 13 Aug 2015 23:14:30 +0800
Raw View
--Apple-Mail=_FF30C634-3B94-406E-99FD-DFE779082AF0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9308=E2=80=9313, at 10:04 PM, Matthew Woehlke <mwoehlke.flo=
ss@gmail.com> wrote:
>=20
> Um... why? Why not just store *the actual offset*?=20
Before anyone goes and stores a raw byte offset, consider that PTDMs do it =
safer.
That said, the advantage to the proposal is that no storage is required in =
the class if it=E2=80=99s polymorphic.
A PTDM stored directly in the vtable would be the best of both worlds. Vtab=
le storage was recently proposed here.
--=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=_FF30C634-3B94-406E-99FD-DFE779082AF0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9308=
=E2=80=9313, at 10:04 PM, Matthew Woehlke <<a href=3D"mailto:mwoehlke.fl=
oss@gmail.com" class=3D"">mwoehlke.floss@gmail.com</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><span style=3D"font-fam=
ily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; orphans: =
auto; text-align: start; text-indent: 0px; text-transform: none; white-spac=
e: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;=
float: none; display: inline !important;" class=3D"">Um... why? Why not ju=
st store *the actual offset*?<span class=3D"Apple-converted-space"> </=
span></span></div></blockquote></div><br class=3D""><div class=3D"">Before =
anyone goes and stores a raw byte offset, consider that PTDMs do it safer.<=
/div><div class=3D""><br class=3D""></div><div class=3D"">That said, the ad=
vantage to the proposal is that no storage is required in the class if it=
=E2=80=99s polymorphic.</div><div class=3D""><br class=3D""></div><div clas=
s=3D"">A PTDM stored directly in the vtable would be the best of both world=
s. Vtable storage was recently proposed here.</div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_FF30C634-3B94-406E-99FD-DFE779082AF0--
.
Author: "U.Mutlu" <for-gmane@mutluit.com>
Date: Thu, 13 Aug 2015 17:18:47 +0200
Raw View
Matthew Woehlke wrote on 08/13/2015 04:04 PM:
> On 2015-08-13 08:40, 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) {}
>> };
>>
>> 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.
>
> Um... why? Why not just store *the actual offset*?
Hmm. yes that's an option too.
A pointer, be it an offset ptr or a normal ptr, should have
otherwise the same semantics, IMHO. But OTOH every alternative solution
would be helpful here.
> This requires 'this' to be given when dereferencing the pointer, but that will often be the
> case anyway, and has the *TREMENDOUS* advantage that copying the pointer
> *is trivial*. (See especially recent thread(s) on object relocatability!)
>
> p.s. better example use case:
>
> // Can use default copy/move ctors
> class Foo
> {
> Bar bar_private;
> public:
> Bar const offset& bar = bar_private;
> };
--
---
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/.
.
Author: "U.Mutlu" <for-gmane@mutluit.com>
Date: Thu, 13 Aug 2015 17:25:14 +0200
Raw View
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 <for-gmane@mutluit.com> 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<TS> 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/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 13 Aug 2015 10:06:28 -0700 (PDT)
Raw View
------=_Part_390_1797279254.1439485588479
Content-Type: multipart/alternative;
boundary="----=_Part_391_1394373911.1439485588481"
------=_Part_391_1394373911.1439485588481
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, August 13, 2015 at 11:09:05 AM UTC-4, U.Mutlu wrote:
>
> David Rodr=C3=ADguez Ibeas wrote on 08/13/2015 03:31 PM:=20
> > What would be the use case for this feature? Avoiding having to write=
=20
> the=20
> > copy-constructor and assignment operator? For what subset of types?=20
> >=20
> > I don't see any good use case off the top of my head. In the example=
=20
> you=20
> > provided, 'p' is not needed at all and the type could do without it=20
> > altogether.=20
>
> Think of some more complex types of pointers and references within=20
> the object pointing/referencing locations inside the same object.=20
>
> The main benefit would be having pointers and references in STL container=
=20
> items which point to other local objects within the item. They would=20
> always=20
> automatically keep their validity.=20
>
> Currently, pointers and references in such container items will not=20
> function=20
> properly; one has to reset/set the pointers before first use and before=
=20
> the container changes its state (adding/inserting/removing/resizing).=20
> And: references are totally lost in such a situation, ie. there is=20
> not even a workaround for plain references.=20
>
> The solution to all these problems would bring the proposed offset ptrs=
=20
> and=20
> offset references.=20
>
OK, I want to make sure I understand what you're suggesting. You're=20
suggesting something like this should be possible:
struct Foo
{
vector<int> data;
offset int* offset_ptr;
Foo() : data{4, 5, 2}, offset_ptr{&data[2]} {}
int access() const {return *offset_ptr;}
void realloc() {data.assign({5, 4, 18}); }
};
void main()
{
Foo foo;
std::cout << foo.access() << std::endl;
foo.realloc();
std::cout << foo.access() << std::endl;
}
And you want this program to be guaranteed to return:
2
18
I'm curious as to exactly how this would be possible. `offset_ptr` was=20
initialized with a pointer to a specific memory allocation. If it truly is=
=20
an *offset*, then it needs to know two things: the byte offset to its=20
actual data and the *starting* point.
Once you do `foo.reassign()`, the starting point has (potentially) changed,=
=20
since the vector was reallocated. How exactly could `offset_ptr` possibly=
=20
know that it has changed?
Which means you need to provide the starting point when using offset=20
pointers, much like member pointers. So the code would have to look like=20
this:
struct Foo
{
vector<int> data;
offset int* offset_ptr;
Foo() : data{4, 5, 2}, offset_ptr{2} {}
int access() const {return offset_ptr->(data.data());}
void realloc() {data.assign({5, 4, 18}); }
};
At which point, you may as well just store an integer offset and do the=20
math yourself:
struct Foo
{
vector<int> data;
int offset;
Foo() : data{4, 5, 2}, offset{2} {}
int access() const {return data[2];}
void realloc() {data.assign({5, 4, 18}); }
};
Now, you could try to store two things in the offset pointer: the offset=20
and the std::vector object:
struct Foo
{
vector<int> data;
offset<std::vector<int>> int* offset_ptr;
Foo() : data{4, 5, 2}, offset_ptr{data, 2} {}
int access() const {return *offset_ptr;}
void realloc() {data.assign({5, 4, 18}); }
};
But that doesn't explain how this offset pointer knows that it needs to=20
access `operator[]` in std::vector. Are you going to define some `offset`=
=20
global function that people overload for doing offsets?
This could solve the copy/move problem, but only by the compiler generating=
=20
code to specifically fixing up the pointer/reference to `data` in the=20
destination object. And the compiler doesn't have enough information to=20
know how to do that fixup, since different constructors could initialize=20
the reference with different values. Consider a `Foo` that had two=20
different `std::vector<int>`s in them, and it arbitrarily decides which to=
=20
initialize `offset_ptr` with. The compiler wouldn't be able to statically=
=20
know which was being used.
So no, it can't solve the problem. And even if it could, it would require=
=20
generating code, and thus making the object non-trivially copy/moveable. So=
=20
it doesn't really *solve* the problem.
At the end of the day, I don't see anything here which couldn't be done as=
=20
a user-defined type:
struct Foo
{
vector<int> data;
offset_ptr<std::vector<int>, int> offset_ptr;
Foo() : data{4, 5, 2}, offset_ptr{data, 2} {}
int access() const {return *offset_ptr;}
void realloc() {data.assign({5, 4, 18}); }
};
All you would need is some machinery for `offset_ptr` to know how to apply=
=20
the offset to the typed-pointer it is given. If you need the object to be=
=20
copyable/moveable, then copying/moving it would require some knowledge of=
=20
`this`. But as previously stated, the presence of such an offset pointer=20
would always make the type non-trivial, so you haven't lost anything.
Ultimately, there's nothing you want to do that couldn't be done with a=20
user-defined type. So why make it a language feature? What do you gain,=20
besides some slight ease-of-use?
--=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_391_1394373911.1439485588481
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, August 13, 2015 at 11:09:05 AM UTC-4, U.Mutlu wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">David Rodr=C3=ADguez Ibeas wrote on 08/1=
3/2015 03:31 PM:
<br>> What would be the use case for this feature? Avoiding having to wr=
ite the
<br>> copy-constructor and assignment operator? For what subset of types=
?
<br>>
<br>> I don't see any good use case off the top of my head. =C2=A0In=
the example you
<br>> provided, 'p' is not needed at all and the type could do w=
ithout it
<br>> altogether.
<br>
<br>Think of some more complex types of pointers and references within
<br>the object pointing/referencing locations inside the same object.
<br>
<br>The main benefit would be having pointers and references in STL contain=
er
<br>items which point to other local objects within the item. They would al=
ways
<br>automatically keep their validity.
<br>
<br>Currently, pointers and references in such container items will not fun=
ction=20
<br>properly; one has to reset/set the pointers before first use and before
<br>the container changes its state (adding/inserting/removing/<wbr>resizin=
g).
<br>And: references are totally lost in such a situation, ie. there is
<br>not even a workaround for plain references.
<br>
<br>The solution to all these problems would bring the proposed offset ptrs=
and=20
<br>offset references.
<br></blockquote><div><br>OK, I want to make sure I understand what you'=
;re suggesting. You're suggesting something like this should be possibl=
e:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 25=
0, 250); border-color: rgb(187, 187, 187); border-style: solid; border-widt=
h: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"s=
ubprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">st=
ruct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #606;" class=3D"styled-by-prettify">Foo</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>=C2=A0 vector</span><span style=
=3D"color: #080;" class=3D"styled-by-prettify"><int></span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> data</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>=C2=A0 offset </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> offset_ptr</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #606;" class=3D"s=
tyled-by-prettify">Foo</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> data</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">4</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"=
styled-by-prettify">5</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">2</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">},</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> offset_ptr</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{&</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">data</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">[</span><span style=3D"color: #06=
6;" class=3D"styled-by-prettify">2</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">]}</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> ac=
cess</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">return</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">offset_ptr</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">;}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> reall=
oc</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">data</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">assign</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">({</span><span style=3D"color: #066;" class=3D"styl=
ed-by-prettify">5</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #066;" class=3D"styled-by-prettify">4</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">18</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">});</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> main</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #60=
6;" class=3D"styled-by-prettify">Foo</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>=C2=A0 std</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">cout </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
"><<</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">access</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify"><<</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">endl</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 foo</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">realloc</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>();</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">cout </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify"><<</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">access</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify"><<</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">endl</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></d=
iv></code></div><br>And you want this program to be guaranteed to return:<b=
r><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 2=
50); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1=
px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpr=
ettyprint"><span style=3D"color: #066;" class=3D"styled-by-prettify">2</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #066;" class=3D"styled-by-prettify">18</span></div></code=
></div><br>I'm curious as to exactly how this would be possible. `offse=
t_ptr` was initialized with a pointer to a specific memory allocation. If i=
t truly is an <i>offset</i>, then it needs to know two things: the byte off=
set to its actual data and the <i>starting</i> point.<br><br>Once you do `f=
oo.reassign()`, the starting point has (potentially) changed, since the vec=
tor was reallocated. How exactly could `offset_ptr` possibly know that it h=
as changed?<br><br>Which means you need to provide the starting point when =
using offset pointers, much like member pointers. So the code would have to=
look like this:<br><br><div class=3D"prettyprint" style=3D"background-colo=
r: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: soli=
d; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><=
div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">struct</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">F=
oo</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 vector</span=
><span style=3D"color: #080;" class=3D"styled-by-prettify"><int></spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> data</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 offset </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> offset_ptr</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #606=
;" class=3D"styled-by-prettify">Foo</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
data</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</spa=
n><span style=3D"color: #066;" class=3D"styled-by-prettify">4</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #06=
6;" class=3D"styled-by-prettify">5</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pret=
tify">2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">},<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> offset_ptr=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><s=
pan style=3D"color: #066;" class=3D"styled-by-prettify">2</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">{}</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br><br>=C2=A0 </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> access</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">c=
onst</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> offset_ptr</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">->(</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">data</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">data</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">());}</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> realloc</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">data</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">assign</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">({</span><span style=3D"color: #=
066;" class=3D"styled-by-prettify">5</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pr=
ettify">4</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #066;" class=3D"styled-by-prettify">18</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">});</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span></div></code></div><br>At which point, you may as well=
just store an integer offset and do the math yourself:<br><br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #606;" class=3D"styled-by-prettify">Foo</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>=C2=A0 vector</span><span style=3D"color: #080;" clas=
s=3D"styled-by-prettify"><int></span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> data</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> offset</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Foo=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> data</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">{</span><span style=3D"color: #066;" clas=
s=3D"styled-by-prettify">4</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">5<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">2</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">},</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> offset</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">{</span><span style=3D"color: #066;" class=3D"st=
yled-by-prettify">2</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{}</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=C2=A0 </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> access</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> data</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">[</span><span style=3D"color: #066;" class=3D"styled-by-prettify">2</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">];}</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> realloc</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">data</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">assign</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">({</span><span style=3D"color: #066;" class=3D"styled-by-prettify">5</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">4</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"=
styled-by-prettify">18</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">});</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">};</span></div></co=
de></div><br>Now, you could try to store two things in the offset pointer: =
the offset and the std::vector object:<br><br><div class=3D"prettyprint" st=
yle=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 18=
7); border-style: solid; border-width: 1px; word-wrap: break-word;"><code c=
lass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">struct</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D=
"styled-by-prettify">Foo</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>=C2=A0 vector</span><span style=3D"color: #080;" class=3D"styled-by-pret=
tify"><int></span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> data</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 offset</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
<</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">vector</span><span st=
yle=3D"color: #080;" class=3D"styled-by-prettify"><int></span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> offset_ptr</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>=C2=A0 </span><span style=3D"color: #606;" class=3D"sty=
led-by-prettify">Foo</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> data</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">4</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"=
styled-by-prettify">5</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">2</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">},</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> offset_ptr</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">data</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"s=
tyled-by-prettify">2</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{}</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=C2=A0 <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> access</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify">offset_=
ptr</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;}</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> realloc</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">data</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">assign</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">({</span><span style=3D"color: #066;" class=3D"styled-by-prettif=
y">5</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #066;" class=3D"styled-by-prettify">4</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">18</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">});</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span></div>=
</code></div><br>But that doesn't explain how this offset pointer knows=
that it needs to access `operator[]` in std::vector. Are you going to defi=
ne some `offset` global function that people overload for doing offsets?<br=
><br>This could solve the copy/move problem, but only by the compiler gener=
ating code to specifically fixing up the pointer/reference to `data` in the=
destination object. And the compiler doesn't have enough information t=
o know how to do that fixup, since different constructors could initialize =
the reference with different values. Consider a `Foo` that had two differen=
t `std::vector<int>`s in them, and it arbitrarily decides which to in=
itialize `offset_ptr` with. The compiler wouldn't be able to statically=
know which was being used.<br><br>So no, it can't solve the problem. A=
nd even if it could, it would require generating code, and thus making the =
object non-trivially copy/moveable. So it doesn't really <i>solve</i> t=
he problem.<br><br>At the end of the day, I don't see anything here whi=
ch couldn't be done as a user-defined type:<br><br><div class=3D"pretty=
print" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187=
, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;=
"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"=
color: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;"=
class=3D"styled-by-prettify">Foo</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 vector</span><span style=3D"color: #080;" class=3D"styl=
ed-by-prettify"><int></span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> data</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>=C2=A0 offset_ptr</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify"><</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">vector<=
/span><span style=3D"color: #080;" class=3D"styled-by-prettify"><int>=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> offset_ptr</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #606;" cl=
ass=3D"styled-by-prettify">Foo</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> data<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><sp=
an style=3D"color: #066;" class=3D"styled-by-prettify">4</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" =
class=3D"styled-by-prettify">5</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify=
">2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">},</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> offset_ptr</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">data</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" =
class=3D"styled-by-prettify">2</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">{}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><b=
r>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">i=
nt</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> access<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">offset_ptr</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">voi=
d</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> realloc<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">data</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">assign</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">({</span><span style=3D"color: #066;" class=3D"styled-b=
y-prettify">5</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #066;" class=3D"styled-by-prettify">4</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #06=
6;" class=3D"styled-by-prettify">18</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">});</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></d=
iv></code></div><br>All you would need is some machinery for `offset_ptr` t=
o know how to apply the offset to the typed-pointer it is given. If you nee=
d the object to be copyable/moveable, then copying/moving it would require =
some knowledge of `this`. But as previously stated, the presence of such an=
offset pointer would always make the type non-trivial, so you haven't =
lost anything.<br><br>Ultimately, there's nothing you want to do that c=
ouldn't be done with a user-defined type. So why make it a language fea=
ture? What do you gain, besides some slight ease-of-use?<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_391_1394373911.1439485588481--
------=_Part_390_1797279254.1439485588479--
.
Author: Myriachan <myriachan@gmail.com>
Date: Thu, 13 Aug 2015 11:22:26 -0700 (PDT)
Raw View
------=_Part_140_100231196.1439490146976
Content-Type: multipart/alternative;
boundary="----=_Part_141_1804718146.1439490146976"
------=_Part_141_1804718146.1439490146976
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, August 13, 2015 at 8:14:46 AM UTC-7, David Krauss wrote:
>
>
> On 2015=E2=80=9308=E2=80=9313, at 10:04 PM, Matthew Woehlke <mwoehlk...@g=
mail.com=20
> <javascript:>> wrote:
>
> Um... why? Why not just store *the actual offset*?=20
>
>
> Before anyone goes and stores a raw byte offset, consider that PTDMs do i=
t=20
> safer.
>
>
Data member pointers cannot handle members of members. It's also difficult=
=20
to add support for this feature without either breaking existing code or=20
being syntactically awkward.
Offsets are useful, and I wish the Committee would be more amenable to=20
changing a few definitions so that you could use offsets with=20
non-trivially-copyable types.
I don't like this particular proposal, because it's redundant in several=20
ways. It reminds me of __based in Visual C++.
Melissa
--=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_141_1804718146.1439490146976
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, August 13, 2015 at 8:14:46 AM UTC-7, David Krauss wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word">=
<br><div><blockquote type=3D"cite"><div>On 2015=E2=80=9308=E2=80=9313, at 1=
0:04 PM, Matthew Woehlke <<a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"mJ6imehdAgAJ" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D'javascript:';return true;" onclick=3D"this.href=3D'javascr=
ipt:';return true;">mwoehlk...@gmail.com</a>> wrote:</div><br><div><=
span style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-v=
ariant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;t=
ext-align:start;text-indent:0px;text-transform:none;white-space:normal;word=
-spacing:0px;float:none;display:inline!important">Um... why? Why not just s=
tore *the actual offset*?<span>=C2=A0</span></span></div></blockquote></div=
><br><div>Before anyone goes and stores a raw byte offset, consider that PT=
DMs do it safer.</div><div><br></div></div></blockquote><div><br>Data membe=
r pointers cannot handle members of members.=C2=A0 It's also difficult =
to add support for this feature without either breaking existing code or be=
ing syntactically awkward.<br><br>Offsets are useful, and I wish the Commit=
tee would be more amenable to changing a few definitions so that you could =
use offsets with non-trivially-copyable types.<br></div><br>I don't lik=
e this particular proposal, because it's redundant in several ways.=C2=
=A0 It reminds me of __based in Visual C++.<br><br>Melissa<br>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_141_1804718146.1439490146976--
------=_Part_140_100231196.1439490146976--
.
Author: Larry Evans <cppljevans@suddenlink.net>
Date: Sat, 15 Aug 2015 02:01:20 -0500
Raw View
On 08/13/2015 07:40 AM, 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
> S(const int AiId) : iId(AiId), p(buf) {}
> };
>
> vector<TS> v;
> for (size_t i = 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 build
> 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.
>
If I understand correctly, then the assert in the
following code would *not* fire?
-[--cut here:main--
//include above declaration of struct TS
#include <assert/h>
int main()
{ TS ts;
char*ts_scope=reinterpret_cast<char*>(&ts);
assert(ts.buf-ts_scope == ts.p);
return 0;
}
-]--cut here:main--
But if that's right, then I don't see why there would be any
need to update the offset pointer, p, when ts is copied
or assigned. It's always the same value; hence, wouldn't
it be better to make it a static variable, somehow:
-[--cut here:static offset--
struct TS
{
const int iId;
char buf[4096];
static offset char* p; // uses proposed "offset" keyword
S(const int AiId) : iId(AiId), p(buf) {}
};
-]--cut here:static offset--
?
-regards,
Larry
--
---
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/.
.
Author: John Bytheway <jbytheway@gmail.com>
Date: Sat, 15 Aug 2015 20:03:51 -0400
Raw View
On 2015-08-13 08:40, 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
> S(const int AiId) : iId(AiId), p(buf) {}
> };
>
> vector<TS> v;
> for (size_t i = 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 build
> 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.
I'm not quite sure what you're proposing, but are you aware of Boost's
offset_ptr?
<http://www.boost.org/doc/libs/1_59_0/doc/html/interprocess/offset_ptr.html>
It's designed for pointers between objects stored in interprocess shared
memory, but it technically uses undefined behaviour, and has to be
tweaked sometimes to work around compiler optimizers. It would be nice
to have the means to implement this in a conforming fashion, and it
might solve your use case, and the relocatability use case, too.
John Bytheway
--
---
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/.
.