------=_Part_179_8334730.1397690004711
Content-Type: text/plain; charset=UTF-8

Hi all,
I propose a simple extended realloc, let's say realloc_ext as an extension
to the standard C library:

/*
 * ptr - pointer to reallocate
 * size - requested (new) size
 * skip_free - flag to tell whether or not to skip free
 */
void *realloc_ext( void *ptr, size_t size, int skip_free );

It's only purpose would be to control whether or not to free the old
pointer in the case that reallocation failed.
The reasoning behind this is that it would enable implementations of
important stl containers (i.e. std::vector)
to do in-place reallocation if possible. In such cases, memory
fragmentation and expensive copying could be avoided.
If this is a duplicate of another request (or if something similar already
exists and I'm not aware of it), I apologize.

Best regards

Martin Sedlak

--

---
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_179_8334730.1397690004711
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all,<div>I propose a simple extended realloc, let's say=
 realloc_ext as an extension to the standard C library:<br></div><div><br><=
/div><div>/*</div><div>&nbsp;* ptr - pointer to reallocate</div><div>&nbsp;=
* size - requested (new) size</div><div>&nbsp;* skip_free - flag to tell wh=
ether or not to skip free</div><div>&nbsp;*/<br></div><div>void *realloc_ex=
t( void *ptr, size_t size, int skip_free );</div><div><br></div><div>It's o=
nly purpose would be to control whether or not to free the old pointer in t=
he case that reallocation failed.</div><div>The reasoning behind this is th=
at it would enable implementations of important stl containers (i.e. std::v=
ector)</div><div>to do in-place reallocation if possible. In such cases, me=
mory fragmentation and expensive copying could be avoided.</div><div>If thi=
s is a duplicate of another request (or if something similar already exists=
 and I'm not aware of it), I apologize.</div><div><br></div><div>Best regar=
ds</div><div><br></div><div>Martin Sedlak</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&quot; 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_179_8334730.1397690004711--

.

This is a multi-part message in MIME format.

------=_NextPart_000_0085_01CF5A1F.36223050
Content-Type: text/plain; charset=UTF-8

There has been a similar proposal back in 2006 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2045.html#Problem%203)

It goes a bit further in allowing to request a minimum needed, and a prefered size and allow realloc to resize the memory approproately.



The main problem with those proposals seems to be that it would need support of the C-committee and all C-library vendors, which is difficult to achieve,

and it seems not clear if the performance win is big enough to warrant this cost.



best regards



Fabio Fracassi



From: Martin Sedlak [mailto:k_mar@seznam.cz]
Sent: Thursday, April 17, 2014 1:13 AM
To: std-proposals@isocpp.org
Subject: [std-proposals] extended realloc



Hi all,

I propose a simple extended realloc, let's say realloc_ext as an extension to the standard C library:



/*

 * ptr - pointer to reallocate

 * size - requested (new) size

 * skip_free - flag to tell whether or not to skip free

 */

void *realloc_ext( void *ptr, size_t size, int skip_free );



It's only purpose would be to control whether or not to free the old pointer in the case that reallocation failed.

The reasoning behind this is that it would enable implementations of important stl containers (i.e. std::vector)

to do in-place reallocation if possible. In such cases, memory fragmentation and expensive copying could be avoided.

If this is a duplicate of another request (or if something similar already exists and I'm not aware of it), I apologize.



Best regards



Martin Sedlak

--

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

------=_NextPart_000_0085_01CF5A1F.36223050
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Dutf-8"><meta name=3DGenerator content=3D"Microsoft=
 Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
 {font-family:"Cambria Math";
 panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
 {font-family:Calibri;
 panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
 {font-family:Tahoma;
 panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
 {margin:0cm;
 margin-bottom:.0001pt;
 font-size:12.0pt;
 font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
 {mso-style-priority:99;
 color:blue;
 text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
 {mso-style-priority:99;
 color:purple;
 text-decoration:underline;}
p
 {mso-style-priority:99;
 mso-margin-top-alt:auto;
 margin-right:0cm;
 mso-margin-bottom-alt:auto;
 margin-left:0cm;
 font-size:12.0pt;
 font-family:"Times New Roman","serif";}
span.EmailStyle18
 {mso-style-type:personal-reply;
 font-family:"Tahoma","sans-serif";
 color:#1F497D;}
..MsoChpDefault
 {mso-style-type:export-only;}
@page WordSection1
 {size:612.0pt 792.0pt;
 margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
 {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DDE link=3Dblue vlink=
=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'fon=
t-size:10.0pt;font-family:"Tahoma","sans-serif";color:#1F497D'>There has be=
en a similar proposal back in 2006 (<a href=3D"http://www.open-std.org/jtc1=
/sc22/wg21/docs/papers/2006/n2045.html#Problem%203">http://www.open-std.org=
/jtc1/sc22/wg21/docs/papers/2006/n2045.html#Problem%203</a>)<o:p></o:p></sp=
an></p><p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Ta=
homa","sans-serif";color:#1F497D'>It goes a bit further in allowing to requ=
est a minimum needed, and a prefered size and allow realloc to resize the m=
emory approproately.<o:p></o:p></span></p><p class=3DMsoNormal><span style=
=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:#1F497D'><o:p>=
&nbsp;</o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:10.0pt=
;font-family:"Tahoma","sans-serif";color:#1F497D'>The main problem with tho=
se proposals seems to be that it would need support of the C-committee and =
all C-library vendors, which is difficult to achieve, <o:p></o:p></span></p=
><p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Tahoma",=
"sans-serif";color:#1F497D'>and it seems not clear if the performance win i=
s big enough to warrant this cost.<o:p></o:p></span></p><p class=3DMsoNorma=
l><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:#=
1F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span style=3D'fon=
t-size:10.0pt;font-family:"Tahoma","sans-serif";color:#1F497D'>best regards=
<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:10.0pt;=
font-family:"Tahoma","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></=
p><p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Tahoma"=
,"sans-serif";color:#1F497D'>Fabio Fracassi<o:p></o:p></span></p><p class=
=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-ser=
if";color:#1F497D'><o:p>&nbsp;</o:p></span></p><div style=3D'border:none;bo=
rder-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style=3D'bo=
rder:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p clas=
s=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"=
Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-size=
:10.0pt;font-family:"Tahoma","sans-serif"'> Martin Sedlak [mailto:k_mar@sez=
nam.cz] <br><b>Sent:</b> Thursday, April 17, 2014 1:13 AM<br><b>To:</b> std=
-proposals@isocpp.org<br><b>Subject:</b> [std-proposals] extended realloc<o=
:p></o:p></span></p></div></div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><=
div><p class=3DMsoNormal>Hi all,<o:p></o:p></p><div><p class=3DMsoNormal>I =
propose a simple extended realloc, let's say realloc_ext as an extension to=
 the standard C library:<o:p></o:p></p></div><div><p class=3DMsoNormal><o:p=
>&nbsp;</o:p></p></div><div><p class=3DMsoNormal>/*<o:p></o:p></p></div><di=
v><p class=3DMsoNormal>&nbsp;* ptr - pointer to reallocate<o:p></o:p></p></=
div><div><p class=3DMsoNormal>&nbsp;* size - requested (new) size<o:p></o:p=
></p></div><div><p class=3DMsoNormal>&nbsp;* skip_free - flag to tell wheth=
er or not to skip free<o:p></o:p></p></div><div><p class=3DMsoNormal>&nbsp;=
*/<o:p></o:p></p></div><div><p class=3DMsoNormal>void *realloc_ext( void *p=
tr, size_t size, int skip_free );<o:p></o:p></p></div><div><p class=3DMsoNo=
rmal><o:p>&nbsp;</o:p></p></div><div><p class=3DMsoNormal>It's only purpose=
 would be to control whether or not to free the old pointer in the case tha=
t reallocation failed.<o:p></o:p></p></div><div><p class=3DMsoNormal>The re=
asoning behind this is that it would enable implementations of important st=
l containers (i.e. std::vector)<o:p></o:p></p></div><div><p class=3DMsoNorm=
al>to do in-place reallocation if possible. In such cases, memory fragmenta=
tion and expensive copying could be avoided.<o:p></o:p></p></div><div><p cl=
ass=3DMsoNormal>If this is a duplicate of another request (or if something =
similar already exists and I'm not aware of it), I apologize.<o:p></o:p></p=
></div><div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=
=3DMsoNormal>Best regards<o:p></o:p></p></div><div><p class=3DMsoNormal><o:=
p>&nbsp;</o:p></p></div><div><p class=3DMsoNormal>Martin Sedlak<o:p></o:p><=
/p></div></div><p class=3DMsoNormal>-- <br><br>--- <br>You received this me=
ssage because you are subscribed to the Google Groups &quot;ISO C++ Standar=
d - Future Proposals&quot; group.<br>To unsubscribe from this group and sto=
p receiving emails from it, send an email to <a href=3D"mailto:std-proposal=
s+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>To p=
ost 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://gr=
oups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com=
/a/isocpp.org/group/std-proposals/</a>.<o:p></o:p></p></div></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&quot; 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 />

------=_NextPart_000_0085_01CF5A1F.36223050--


.

El 17/04/2014 9:27, Fabio Fracassi wrote:
> There has been a similar proposal back in 2006
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2045.html#Problem%203)
>
> It goes a bit further in allowing to request a minimum needed, and a
> prefered size and allow realloc to resize the memory approproately.
>
> The main problem with those proposals seems to be that it would need
> support of the C-committee and all C-library vendors, which is difficult
> to achieve,
>
> and it seems not clear if the performance win is big enough to warrant
> this cost.

A modified version of the proposal has been implemented in
Boost.Container and it will ship in Boost 1.56 (it's in both master and
develop branches). A new allocator type has been developed that can
offer realloc-like capabilities. If anyone want to measure performance
wins in its plaform there are some benchmarks in the Boost.Container
"bench" subfolder.

Best,

Ion

--

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

.

> From: Ion Gazta=C3=B1aga [mailto:igaztanaga@gmail.com]
> El 17/04/2014 9:27, Fabio Fracassi wrote:
> > and it seems not clear if the performance win is big enough to
> warrant
> > this cost.
>=20
> A modified version of the proposal has been implemented in
> Boost.Container and it will ship in Boost 1.56 (it's in both master and
> develop branches). A new allocator type has been developed that can
> offer realloc-like capabilities.=20

+1
Do you have to have support form the runtime, or can you work around this i=
ssue?
are you going to submit a Paper on this?

best regards

Fabio






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

.

El 17/04/2014 11:14, Fabio Fracassi wrote:
>
>> From: Ion Gazta=C3=B1aga [mailto:igaztanaga@gmail.com]
>> El 17/04/2014 9:27, Fabio Fracassi wrote:
>>> and it seems not clear if the performance win is big enough to
>> warrant
>>> this cost.
>>
>> A modified version of the proposal has been implemented in
>> Boost.Container and it will ship in Boost 1.56 (it's in both master and
>> develop branches). A new allocator type has been developed that can
>> offer realloc-like capabilities.
>
> +1
> Do you have to have support form the runtime, or can you work around this=
 issue?
> are you going to submit a Paper on this?

The latest version of DLMalloc (2.8.6) has been extended to implement=20
all needed functions. That code is wrapped in a Boost.Container DLL. It=20
should work on all Windows and Unixes.

Obviously is not a replacement for an optimized multithreaded allocator,=20
but at least in my tests, reallocation is quite effective, even in the=20
presence of move semantics. Burst allocation is also quite effective in=20
node containers when inserting ranges. The idea of making it part of=20
Boost is to obtain user reports and improvements.

I don't have a plan to submit a paper (yet). The interface is quite=20
complicated and the committee does not seem interested in this type of=20
extensions. The idea is to have a working implementation so that we can=20
measure real improvements in our programs. If the performance is good=20
enough, we could have another proposal backed by existing practice.

I would like to use also system allocators, at least to implement part=20
of the proposal, but that would require some kind of runtime support.=20
Another idea is to try to convince C memory allocator writers=20
(nedmalloc, jemalloc,tcmalloc) to implement some extensions, this could=20
be tried once we've established we appropriate C interface.

Now it's time to try and measure. I'd be glad to receive any feedback=20
from the community in this mailing list or in any Boost mailing lists.

Best,

Ion

--=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_898_11912190.1397749445156
Content-Type: text/plain; charset=UTF-8

After some thinking, I figured out that my proposal is useless.
Standard realloc will do (objects holding pointers will be copied by
realloc anyway, I can't think of a case where it would break).
Plus standard realloc has one important advantage over what I proposed:
it can do reallocation by moving overlapping region if previous block is
free and combined with the one to be reallocated fits the new size.
So I take my proposal back. Still, it should be possible to reduce
fragmentation of vector by using realloc in some cases.
In fact my primary concern was fragmentation, not performance.
My apologies :)

Best regards

Martin

--

---
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_898_11912190.1397749445156
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">After some thinking, I figured out that my proposal is use=
less.<div>Standard realloc will do (objects holding pointers will be copied=
 by realloc anyway, I can't think of a case where it would break).</div><di=
v>Plus standard realloc has one important advantage over what I proposed:</=
div><div>it can do reallocation by moving overlapping region if previous bl=
ock is free and combined with the one to be reallocated fits the new size.<=
/div><div>So I take my proposal back. Still, it should be possible to reduc=
e fragmentation of vector by using realloc in some cases.</div><div>In fact=
 my primary concern was fragmentation, not performance.</div><div>My apolog=
ies :)</div><div><br></div><div>Best regards</div><div><br></div><div>Marti=
n</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&quot; 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_898_11912190.1397749445156--

.

------=_Part_465_9833808.1397751966337
Content-Type: text/plain; charset=UTF-8

On the second thought C realloc won't work if move/copy is non-trivial (but
in that case storing pointers in the container instead would be the right
thing to do).
Plus overlapping reallocation is still possible but requires the caller to
detect the overlap and not call free in that case.
I think I went too deep in low-level thinking...
Thanks for your replies.

Best regards

Martin

--

---
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_465_9833808.1397751966337
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On the second thought C realloc won't work if move/copy is=
 non-trivial (but in that case storing pointers in the container instead wo=
uld be the right thing to do).<div>Plus overlapping reallocation is still p=
ossible but requires the caller to detect the overlap and not call free in =
that case.</div><div>I think I went too deep in low-level thinking...</div>=
<div>Thanks for your replies.</div><div><br></div><div>Best regards</div><d=
iv><br></div><div>Martin</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&quot; 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_465_9833808.1397751966337--

.

Em qui 17 abr 2014, =E0s 09:26:06, Martin Sedlak escreveu:
> On the second thought C realloc won't work if move/copy is non-trivial (b=
ut
> in that case storing pointers in the container instead would be the right
> thing to do).
> Plus overlapping reallocation is still possible but requires the caller t=
o
> detect the overlap and not call free in that case.
> I think I went too deep in low-level thinking...

What we need in containers is "realloc by extending if you can", which mean=
s=20
non-trivial contained objects will stay in place.

What has occurred to me when you posted your proposal is that the next thin=
g=20
that any container will do after getting a "failed to extend" return code i=
s=20
allocate a new memory block. So a realloc function that extends if possible=
,=20
allocating a brand new block if not, would also be welcome.

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

.

El 17/04/2014 18:56, Thiago Macieira escribi=F3:
> Em qui 17 abr 2014, =E0s 09:26:06, Martin Sedlak escreveu:
>> On the second thought C realloc won't work if move/copy is non-trivial (=
but
>> in that case storing pointers in the container instead would be the righ=
t
>> thing to do).
>> Plus overlapping reallocation is still possible but requires the caller =
to
>> detect the overlap and not call free in that case.
>> I think I went too deep in low-level thinking...
>
> What we need in containers is "realloc by extending if you can", which me=
ans
> non-trivial contained objects will stay in place.
>
> What has occurred to me when you posted your proposal is that the next th=
ing
> that any container will do after getting a "failed to extend" return code=
 is
> allocate a new memory block. So a realloc function that extends if possib=
le,
> allocating a brand new block if not, would also be welcome.

N2045 covered this case and also proposed atomically checking for=20
extensions and allocate on failure. The steps are:

-> Check if memory can be expanded forward. Usually this means (e.g.=20
vector) that stored objects won't be copied or moved after expansion.

-> Otherwise, check if memory can be expanded backwards + forward. This=20
obtains a memory region that will have the stored objects in the middle=20
of the region. This lowers fragmentation and usually it's faster because=20
several allocators can check in O(1) if the previous and next blocks are=20
free.

-> Otherwise, allocate a new block.

Once memory has been expanded/allocated, the user copies/moves elements=20
if needed and in case a new buffer was allocated, frees the old buffer.

The downside of the forward+backwards expansion is that you can lose=20
strong safety guarantees in some vector operations.

Best,

Ion

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

.