Topic: get_deleter_type_info
Author: 0xc0deface@gmail.com
Date: Mon, 5 May 2014 18:20:31 -0700 (PDT)
Raw View
------=_Part_1416_25064235.1399339231494
Content-Type: text/plain; charset=UTF-8
On Tuesday, 6 May 2014 01:06:53 UTC+10, Nevin ":-)" Liber wrote:
>
> On 5 May 2014 02:37, Matthew Fletcher <0xc0d...@gmail.com <javascript:>>wrote:
>
>> The use case where I am having problems is with serialisation of
>> shared_ptr.
>>
>
> Just serializing the deleter isn't sufficient; for correctness you also
> need to serialize the allocation method (both the object and the deleter
> may be dependent upon it), which isn't directly stored with the shared_ptr.
>
True. I hadn't considered the allocator as im currently not using one.
>
> Having the type_info object would allow quicker lookups so that the type
>> can be serialised sooner, and would avoid a O(n) search.
>>
>
> You have that many deleters where this will make a difference??
>
No. At the moment we only have a handful of custom deleters. However who
knows how the design may change in the future.
> --
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>> (847)
> 691-1404
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1416_25064235.1399339231494
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, 6 May 2014 01:06:53 UTC+10, Nevin ":-)=
" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">On 5 May 2014 02:37, Matthew Fletcher <span dir=3D"ltr"><<a href=3D"ja=
vascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"OGan9mHQFPwJ" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'jav=
ascript:';return true;">0xc0d...@gmail.com</a>></span> wrote:<br><div><d=
iv class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>The use case where I a=
m having problems is with serialisation of shared_ptr.</div></div></blockqu=
ote>
<div><br></div><div>Just serializing the deleter isn't sufficient; for corr=
ectness you also need to serialize the allocation method (both the object a=
nd the deleter may be dependent upon it), which isn't directly stored with =
the shared_ptr.</div></div></div></div></blockquote><div><br></div><div>Tru=
e. I hadn't considered the allocator as im currently not using one. </=
div><div><br></div><div> </div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote">
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div cl=
ass=3D"gmail_quote"><div>Having the type_info object would allow quicker lo=
okups so that the type can be serialised sooner, and would avoid a O(n) sea=
rch.</div>
</div></div></div></blockquote><div><br></div><div>You have that many delet=
ers where this will make a difference??</div></div></div></div></blockquote=
><div><br></div><div>No. At the moment we only have a handful of custom del=
eters. However who knows how the design may change in the future.</div><div=
> <br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>-- <br> Nevin ":-)" Liber <mailto:<a href=3D"javascr=
ipt:" target=3D"_blank" gdf-obfuscated-mailto=3D"OGan9mHQFPwJ" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascr=
ipt:';return true;">ne...@eviloverlord.com</a><wbr>> (847) 691-140=
4
</div></div>
</blockquote></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_1416_25064235.1399339231494--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 5 May 2014 10:06:53 -0500
Raw View
--001a113467fca6bd7804f8a87dd5
Content-Type: text/plain; charset=UTF-8
On 5 May 2014 02:37, Matthew Fletcher <0xc0deface@gmail.com> wrote:
> The use case where I am having problems is with serialisation of
> shared_ptr.
>
Just serializing the deleter isn't sufficient; for correctness you also
need to serialize the allocation method (both the object and the deleter
may be dependent upon it), which isn't directly stored with the shared_ptr.
Having the type_info object would allow quicker lookups so that the type
> can be serialised sooner, and would avoid a O(n) search.
>
You have that many deleters where this will make a difference??
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
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/.
--001a113467fca6bd7804f8a87dd5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 5 May 2014 02:37, Matthew Fletcher <span dir=3D"ltr">&l=
t;<a href=3D"mailto:0xc0deface@gmail.com" target=3D"_blank">0xc0deface@gmai=
l.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gma=
il_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>The use case where I a=
m having problems is with serialisation of shared_ptr.</div></div></blockqu=
ote>
<div><br></div><div>Just serializing the deleter isn't sufficient; for =
correctness you also need to serialize the allocation method (both the obje=
ct and the deleter may be dependent upon it), which isn't directly stor=
ed with the shared_ptr.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div>Having the type_info objec=
t would allow quicker lookups so that the type can be serialised sooner, an=
d would avoid a O(n) search.</div>
</div></div></div></blockquote><div><br></div><div>You have that many delet=
ers where this will make a difference??</div></div>-- <br>=C2=A0Nevin "=
;:-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com"=
target=3D"_blank">nevin@eviloverlord.com</a>>=C2=A0 (847) 691-1404
</div></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 />
--001a113467fca6bd7804f8a87dd5--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 5 May 2014 12:42:13 -0500
Raw View
--f46d043c7ffe2fab0604f8aaa9a6
Content-Type: text/plain; charset=UTF-8
On 5 May 2014 12:27, Philipp Maximilian Stephani <p.stephani2@gmail.com>wrote:
>
>
> On Mon May 05 2014 at 17:07:35, Nevin Liber <nevin@eviloverlord.com>
> wrote:
>
>> On 5 May 2014 02:37, Matthew Fletcher <0xc0deface@gmail.com> wrote:
>>
>>> The use case where I am having problems is with serialisation of
>>> shared_ptr.
>>>
>>
>> Just serializing the deleter isn't sufficient; for correctness you also
>> need to serialize the allocation method (both the object and the deleter
>> may be dependent upon it), which isn't directly stored with the shared_ptr.
>>
>>
> The allocator is used to deallocate the control block, so I think it needs
> to be stored as well.
>
When a custom deleter is being used (the OP case), the shared_ptr has no
idea where the allocation comes from, because all that is passed to its
constructor is a raw pointer.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
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/.
--f46d043c7ffe2fab0604f8aaa9a6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 5 May 2014 12:27, Philipp Maximilian Stephani <span dir=
=3D"ltr"><<a href=3D"mailto:p.stephani2@gmail.com" target=3D"_blank">p.s=
tephani2@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div=
class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D""><br><br><div>On Mon May 05 2014 at 17:07:3=
5, Nevin Liber <<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_bla=
nk">nevin@eviloverlord.com</a>> wrote:</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
<div dir=3D"ltr">On 5 May 2014 02:37, Matthew Fletcher <span dir=3D"ltr">&l=
t;<a href=3D"mailto:0xc0deface@gmail.com" target=3D"_blank">0xc0deface@gmai=
l.com</a>></span> wrote:<br></div><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>The use case where I am having probl=
ems is with serialisation of shared_ptr.</div>
</div></blockquote>
<div><br></div></div></div></div><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><div dir=3D"ltr"><div>Just serializing the deleter isn't su=
fficient; for correctness you also need to serialize the allocation method =
(both the object and the deleter may be dependent upon it), which isn't=
directly stored with the shared_ptr.</div>
</div></div></div><br></blockquote><div><br></div></div><div>The allocator =
is used to deallocate the control block, so I think it needs to be stored a=
s well.</div></blockquote><div><br></div><div>When a custom deleter is bein=
g used (the OP case), the shared_ptr has no idea where the allocation comes=
from, because all that is passed to its constructor is a raw pointer.</div=
>
</div>-- <br>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=C2=A0 (847) 691-1404
</div></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 />
--f46d043c7ffe2fab0604f8aaa9a6--
.
Author: 0xc0deface@gmail.com
Date: Mon, 5 May 2014 19:14:40 -0700 (PDT)
Raw View
------=_Part_2383_31949344.1399342481108
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, 6 May 2014 11:33:45 UTC+10, Thiago Macieira wrote:
>
> Em seg 05 maio 2014, =C3=A0s 18:20:31, 0xc0d...@gmail.com <javascript:>es=
creveu:=20
> > > Just serializing the deleter isn't sufficient; for correctness you=20
> also=20
> > > need to serialize the allocation method (both the object and the=20
> deleter=20
> > > may be dependent upon it), which isn't directly stored with the=20
> > > shared_ptr.=20
> >=20
> > True. I hadn't considered the allocator as im currently not using one.=
=20
>
> IMHO, that's a major problem here. The allocator is not stored anywhere=
=20
> with=20
> the shared_ptr object. The deleter is the opposite of the allocator and i=
s=20
> probably expected to work in tandem. In other words, when de-serialising=
=20
> the=20
> object, you need to use the right allocator for the right deleter. If you=
=20
> can't do that, you shouldn't use either.=20
>
One of the handiest uses of the deleter i've found is that it allows a=20
convenient way to safely call pure virtual methods on an object before=20
destruction begins.
eg=20
[](Type* a)
{
a->deinitialise(); // pure virtual call
delete a; // use regular delete
}
Or if the destructor of a type is private it allows you to pass it to the=
=20
correct object to delete it
[](Type* a)
{
auto m =3D a->getManager();
if(m)
m->destroy( a );
else
throw /*some exception*/;
}
Both may use default allocation.=20
Or you may be using the shared_ptr for something different entirely that=20
doesn't involve immediately deleting the stored pointer, or maybe queues=20
deletion or pushes into a pool rather than deleting.
[](Type* a)
{
a->queueDelete();
// or...
a->AddToPool();
}
My point is, using a deleter does not, and should not imply custom=20
allocation. shared_ptr simply makes an event happen when the reference=20
count =3D=3D 0. That is usually delete, but does not have to be. The delete=
r=20
encapsulates that event and is the most important object to serialise out.=
=20
--=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=20
> PGP/GPG: 0x6EF45358; fingerprint:=20
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358=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 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_2383_31949344.1399342481108
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Tuesday, 6 May 2014 11:33:45 UTC+10, Thiago Macieir=
a wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em seg 05 maio 2014, =
=C3=A0s 18:20:31, <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"TYX1mtm2oXUJ" onmousedown=3D"this.href=3D'javascript:';return tru=
e;" onclick=3D"this.href=3D'javascript:';return true;">0xc0d...@gmail.com</=
a> escreveu:
<br>> > Just serializing the deleter isn't sufficient; for correctnes=
s you also=20
<br>> > need to serialize the allocation method (both the object and =
the deleter=20
<br>> > may be dependent upon it), which isn't directly stored with t=
he
<br>> > shared_ptr.
<br>>=20
<br>> True. I hadn't considered the allocator as im currently not using =
one.=20
<br>
<br>IMHO, that's a major problem here. The allocator is not stored anywhere=
with=20
<br>the shared_ptr object. The deleter is the opposite of the allocator and=
is=20
<br>probably expected to work in tandem. In other words, when de-serialisin=
g the=20
<br>object, you need to use the right allocator for the right deleter. If y=
ou=20
<br>can't do that, you shouldn't use either.
<br></blockquote><div><br></div><div>One of the handiest uses of the delete=
r i've found is that it allows a convenient way to safely call pure virtual=
methods on an object before destruction begins.</div><div><br></div><div>e=
g </div><div>[](Type* a)</div><div>{</div><div> a->dei=
nitialise(); // pure virtual call</div><div> delete a; // use =
regular delete</div><div>}</div><div><br></div><div>Or if the destructor of=
a type is private it allows you to pass it to the correct object to delete=
it</div><div><br></div><div>[](Type* a)</div><div>{</div><div>  =
; auto m =3D a->getManager();</div><div> if(m)</div><div>&n=
bsp; m->destroy( a );</div><div> else<=
/div><div> throw /*some exception*/;</div><div>}=
</div><div><br></div><div>Both may use default allocation. <br></div><=
div><br></div><div>Or you may be using the shared_ptr for something differe=
nt entirely that doesn't involve immediately deleting the stored pointer, o=
r maybe queues deletion or pushes into a pool rather than deleting.</div><d=
iv><br></div><div>[](Type* a)</div><div>{</div><div> a->que=
ueDelete();<br></div><div> // or...</div><div> a-=
>AddToPool();</div><div>}</div><div><br></div><div>My point is, using a =
deleter does not, and should not imply custom allocation. shared_ptr simply=
makes an event happen when the reference count =3D=3D 0. That is usually d=
elete, but does not have to be. The deleter encapsulates that event and is =
the most important object to serialise out. </div><div><br></div><div>=
<br></div><div><br></div><div><br></div><div><br></div><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%=
3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhq=
Ln_62FW8ag';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNC=
Nanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - thiago (AT) <a href=
=3D"http://kde.org" target=3D"_blank" onmousedown=3D"this.href=3D'http://ww=
w.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQj=
CNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http:=
//www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a>
<br> Software Architect - Intel Open Source Technology Center
<br> PGP/GPG: 0x6EF45358; fingerprint:
<br> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote></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_2383_31949344.1399342481108--
.
Author: Philipp Maximilian Stephani <p.stephani2@gmail.com>
Date: Mon, 05 May 2014 17:27:10 +0000
Raw View
--001a1133f89005627404f8aa71c4
Content-Type: text/plain; charset=UTF-8
On Mon May 05 2014 at 17:07:35, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 5 May 2014 02:37, Matthew Fletcher <0xc0deface@gmail.com> wrote:
>
>> The use case where I am having problems is with serialisation of
>> shared_ptr.
>>
>
> Just serializing the deleter isn't sufficient; for correctness you also
> need to serialize the allocation method (both the object and the deleter
> may be dependent upon it), which isn't directly stored with the shared_ptr.
>
>
The allocator is used to deallocate the control block, so I think it needs
to be stored as well. At least libc++ stores it the same way as the
deleter. Basically the control block could look like:
template<typename T>
struct ControlBlockBase {
virtual const type_info& GetDeleterType() = 0;
virtual const type_info& GetAllocatorType() = 0;
};
template<typename T, typename D, typename A>
struct ControlBlockImpl : ControlBlockBase<T> {
T* object;
D deleter;
A allocator;
const type_info& GetDeleterType() { return typeid(D); }
const type_info& GetAllocatorType() { return typeid(A); }
};
--
---
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/.
--001a1133f89005627404f8aa71c4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br><div>On Mon May 05 2014 at 17:07:35, Nevin Liber <<a href=3D"mai=
lto:nevin@eviloverlord.com">nevin@eviloverlord.com</a>> wrote:</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
<div dir=3D"ltr">On 5 May 2014 02:37, Matthew Fletcher <span dir=3D"ltr">&l=
t;<a href=3D"mailto:0xc0deface@gmail.com" target=3D"_blank">0xc0deface@gmai=
l.com</a>></span> wrote:<br></div><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>The use case where I a=
m having problems is with serialisation of shared_ptr.</div></div></blockqu=
ote>
<div><br></div></div></div></div><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><div dir=3D"ltr"><div>Just serializing the deleter isn't su=
fficient; for correctness you also need to serialize the allocation method =
(both the object and the deleter may be dependent upon it), which isn't=
directly stored with the shared_ptr.</div>
</div></div></div><br></blockquote><div><br></div><div>The allocator is use=
d to deallocate the control block, so I think it needs to be stored as well=
.. At least libc++ stores it the same way as the deleter. Basically the cont=
rol block could look like:</div>
<div><br></div><div>template<typename T></div><div>struct ControlBloc=
kBase {</div><div>=C2=A0 virtual const type_info& GetDeleterType() =3D =
0;</div><div>=C2=A0 virtual const type_info& GetAllocatorType() =3D 0;<=
/div><div>
};</div><div><br></div><div>template<typename T, typename D, typename A&=
gt;</div><div>struct ControlBlockImpl : ControlBlockBase<T> {</div><d=
iv>=C2=A0 T* object;</div><div>=C2=A0 D deleter;</div><div>=C2=A0 A allocat=
or;</div><div>
=C2=A0 const type_info& GetDeleterType() { return typeid(D); }</div><di=
v>=C2=A0 const type_info& GetAllocatorType() { return typeid(A); }</div=
><div>};</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 />
--001a1133f89005627404f8aa71c4--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 05 May 2014 18:33:45 -0700
Raw View
Em seg 05 maio 2014, =E0s 18:20:31, 0xc0deface@gmail.com escreveu:
> > Just serializing the deleter isn't sufficient; for correctness you also=
=20
> > need to serialize the allocation method (both the object and the delete=
r=20
> > may be dependent upon it), which isn't directly stored with the
> > shared_ptr.
>=20
> True. I hadn't considered the allocator as im currently not using one.=20
IMHO, that's a major problem here. The allocator is not stored anywhere wit=
h=20
the shared_ptr object. The deleter is the opposite of the allocator and is=
=20
probably expected to work in tandem. In other words, when de-serialising th=
e=20
object, you need to use the right allocator for the right deleter. If you=
=20
can't do that, you shouldn't use either.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--=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/.
.