------=_Part_2650_11264633.1358853271143
Content-Type: text/plain; charset=ISO-8859-1

Couldn't find an existing topic, so let me create a new one. Hope that's ok.

I like the idea and have been wondering about this myself.

> Actually a big counter-argument, which I suspect is the cause for this
not being in the c++11 standard in the first place:

> - CON: exact semantics not supported by the C standard, nor in new[]/delete[] operators, making an implementation for std::allocator hard.


Maybe new[] etc should be extended with realloc support too.

Another issue with new[] is that it can't return the actual number of things allocated. Some heaps may actually allocate 8 bytes if you ask for 6. Having a way to take advantage of that (implementation) detail might be a good thing in certain cases.


> The case where an allocation is shrunk, should rarely fail (depending on the implementation ofcourse) since the act of freeing a part of an allocation would yield a portion of free space.


When could it fail?


> Containers implementing shrink_to_fit() will attempt to resize their allocations to the minimum required, by invoking std::allocator_traits<Alloc>::alloc_resize().

Failures will be ignored.


I think ignoring isn't the right word and failures is too broad a term.


> * (p, n_cur) must refer to a previous allocation,

> * or the behaviour is undefined.


> If the combination (p, n_cur) does not reflect an existing allocation, an std::invalid_argument exception will be thrown.


Those two seem contradictoary.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_2650_11264633.1358853271143
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Couldn't find an existing topic, so let me create a new one. Hope that's ok=
..<div><br></div><div>I like the idea and have been wondering about this mys=
elf.</div><div><br></div><div>&gt;&nbsp;<span style=3D"color: rgb(0, 0, 0);=
">Actually a big counter-argument, which I suspect is the cause for this no=
t being in the c++11 standard in the first place:</span></div><pre style=3D=
"color: rgb(0, 0, 0);">&gt; - CON: exact semantics not supported by the C s=
tandard, nor in new[]/delete[] operators, making an implementation for std:=
:allocator hard.</pre><pre style=3D"color: rgb(0, 0, 0);"><br></pre><pre st=
yle=3D"color: rgb(0, 0, 0);">Maybe new[] etc should be extended with reallo=
c support too.</pre><pre style=3D"color: rgb(0, 0, 0);">Another issue with =
new[] is that it can't return the actual number of things allocated. Some h=
eaps may actually allocate 8 bytes if you ask for 6. Having a way to take a=
dvantage of that (implementation) detail might be a good thing in certain c=
ases.</pre><pre style=3D"color: rgb(0, 0, 0);"><br></pre><pre style=3D"colo=
r: rgb(0, 0, 0);">&gt; <span style=3D"font-family: Arial, Helvetica, sans-s=
erif;">The case where an allocation is shrunk, should rarely fail (dependin=
g on the implementation ofcourse) since the act of freeing a part of an all=
ocation would yield a portion of free space.</span></pre><pre style=3D"colo=
r: rgb(0, 0, 0);"><span style=3D"font-family: Arial, Helvetica, sans-serif;=
"><br></span></pre><pre style=3D"color: rgb(0, 0, 0);"><span style=3D"font-=
family: Arial, Helvetica, sans-serif;">When could it fail?</span></pre><pre=
 style=3D"color: rgb(0, 0, 0);"><span style=3D"font-family: Arial, Helvetic=
a, sans-serif;"><br></span></pre><pre style=3D"color: rgb(0, 0, 0);"><span =
style=3D"font-family: Arial, Helvetica, sans-serif;">&gt; </span><span styl=
e=3D"font-family: Arial, Helvetica, sans-serif;">Containers implementing sh=
rink_to_fit() will attempt to resize their allocations to the minimum requi=
red, by invoking std::allocator_traits&lt;Alloc&gt;::alloc_resize().</span>=
</pre><pre style=3D"color: rgb(0, 0, 0);">Failures will be ignored.</pre><p=
re style=3D"color: rgb(0, 0, 0);"><br></pre><pre style=3D"color: rgb(0, 0, =
0);">I think ignoring isn't the right word and failures is too broad a term=
..</pre><pre style=3D"color: rgb(0, 0, 0);"><br></pre><pre style=3D"color: r=
gb(0, 0, 0);"><pre>&gt; * (p, n_cur) must refer to a previous allocation,
</pre><pre><span style=3D"font-family: Arial, Helvetica, sans-serif;">&gt; =
* or the behaviour is undefined.</span></pre><pre><br></pre><pre>&gt; If th=
e combination (p, n_cur) does not reflect an existing allocation, an std::i=
nvalid_argument exception will be thrown.</pre><pre><br></pre><pre>Those tw=
o seem contradictoary.</pre></pre>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2650_11264633.1358853271143--

.

------=_Part_261_27978754.1358900300058
Content-Type: text/plain; charset=ISO-8859-1

realloc() is often important for the best performance. If new and new[]
don't offer this feature, then it's time to add it. I think that UB if not
a correct allocation is fine, but I'd always return NULL if reallocation
could not be achieved. It would be simple enough to do something like

    if (auto newptr = reallocate(alloc, old, size, newsize)) {
        // Valid
    } else {
        // ....
    }


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_261_27978754.1358900300058
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

realloc() is often important for the best performance. If new and new[] don=
't offer this feature, then it's time to add it. I think that UB if not a c=
orrect allocation is fine, but I'd always return NULL if reallocation could=
 not be achieved. It would be simple enough to do something like<div><br></=
div><div style=3D"background-color: rgb(250, 250, 250); border: 1px solid r=
gb(187, 187, 187); word-wrap: break-word;" class=3D"prettyprint"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;=
" class=3D"styled-by-prettify">&nbsp; &nbsp; </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">if</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> newptr </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> reall=
ocate</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">alloc</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> old</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> size</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> newsize</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: #660;" class=3D"styled-by-prettify">{=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp;=
 &nbsp; &nbsp; &nbsp; </span><span style=3D"color: #800;" class=3D"styled-b=
y-prettify">// Valid</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
else</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: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp;=
 &nbsp; </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//=
 ....</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&=
nbsp; &nbsp; </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">}</span></div></code></div><div><br></div><div><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_261_27978754.1358900300058--

.

On Jan 22, 2013, at 6:14 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:

> Couldn't find an existing topic, so let me create a new one. Hope that's ok.
>
> I like the idea and have been wondering about this myself.
>
> > Actually a big counter-argument, which I suspect is the cause for this not being in the c++11 standard in the first place:
> > - CON: exact semantics not supported by the C standard, nor in new[]/delete[] operators, making an implementation for std::allocator hard.
>
> Maybe new[] etc should be extended with realloc support too.
> Another issue with new[] is that it can't return the actual number of things allocated. Some heaps may actually allocate 8 bytes if you ask for 6. Having a way to take advantage of that (implementation) detail might be a good thing in certain cases.
>
> > The case where an allocation is shrunk, should rarely fail (depending on the implementation ofcourse) since the act of freeing a part of an allocation would yield a portion of free space.
>
> When could it fail?
>
> > Containers implementing shrink_to_fit() will attempt to resize their allocations to the minimum required, by invoking std::allocator_traits<Alloc>::alloc_resize().
> Failures will be ignored.
>
> I think ignoring isn't the right word and failures is too broad a term.
>
> > * (p, n_cur) must refer to a previous allocation,
>
> > * or the behaviour is undefined.
>
> > If the combination (p, n_cur) does not reflect an existing allocation, an std::invalid_argument exception will be thrown.
>
> Those two seem contradictoary.

If it helps, here is the history of this topic pre-C++11:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1953.html
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1085.htm
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2045.html

I apologize in advance if I've missed any papers in this area.  These are all I found just doing a quick search.

Howard

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Tue, Jan 22, 2013 at 6:14 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> Couldn't find an existing topic, so let me create a new one. Hope that's ok.

No problem, but as a courtesy to readers it would have been better to
mention the proposal you are discussing, N3495, and provide a link to
it, i.e. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3495.htm

--Beman

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

------=_Part_93_24180585.1358907288962
Content-Type: text/plain; charset=ISO-8859-1

On Tuesday, January 22, 2013 4:18:19 PM UTC-8, DeadMG wrote:
>
> realloc() is often important for the best performance. If new and new[]
> don't offer this feature, then it's time to add it. I think that UB if not
> a correct allocation is fine, but I'd always return NULL if reallocation
> could not be achieved. It would be simple enough to do something like
>
>     if (auto newptr = reallocate(alloc, old, size, newsize)) {
>         // Valid
>     } else {
>         // ....
>     }
>
>
Simple enough to say perhaps. Far more difficult is to implement it.
Especially the idea of reallocating memory that wasn't allocated with
new[]. Remember: new[] is generally implemented as array-size+array, so the
block of allocated memory contains both. Trying to turn something that
wasn't an array into an array is not a good thing.

Also, remember that `new` does more than just allocate memory; it
constructs objects. So you can't just assume that you can copy bits of
memory around and get the "same" objects.

That's why I like the way that the proposal suggests sticking it inside the
allocator, as the allocator handles the dichotomy between allocation and
construction explicitly. Granted, I don't like the idea of reallocation
failure (ie: not being able to expand the allocation memory) being
indicated by throwing std::bad_alloc, as this will happen extremely often
in real applications. Stack rollbacks and such are not cheap, and since
it's a common, expected occurrence, it should not be something that an
exception is thrown over.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_93_24180585.1358907288962
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tuesday, January 22, 2013 4:18:19 PM UTC-8, DeadMG wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">realloc() is often important for the best per=
formance. If new and new[] don't offer this feature, then it's time to add =
it. I think that UB if not a correct allocation is fine, but I'd always ret=
urn NULL if reallocation could not be achieved. It would be simple enough t=
o do something like<div><br></div><div style=3D"background-color:rgb(250,25=
0,250);border:1px solid rgb(187,187,187);word-wrap:break-word"><code><div><=
span style=3D"color:#000">&nbsp; &nbsp; </span><span style=3D"color:#008">i=
f</span><span style=3D"color:#000"> </span><span style=3D"color:#660">(</sp=
an><span style=3D"color:#008">auto</span><span style=3D"color:#000"> newptr=
 </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> re=
allocate</span><span style=3D"color:#660">(</span><span style=3D"color:#000=
">alloc</span><span style=3D"color:#660">,</span><span style=3D"color:#000"=
> old</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> =
size</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> n=
ewsize</span><span style=3D"color:#660">))</span><span style=3D"color:#000"=
> </span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=
&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color:#800">// Valid</spa=
n><span style=3D"color:#000"><br>&nbsp; &nbsp; </span><span style=3D"color:=
#660">}</span><span style=3D"color:#000"> </span><span style=3D"color:#008"=
>else</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{=
</span><span style=3D"color:#000"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><s=
pan style=3D"color:#800">// ....</span><span style=3D"color:#000"><br>&nbsp=
; &nbsp; </span><span style=3D"color:#660">}</span></div></code></div><div>=
</div><div><br></div></blockquote><div><br>Simple enough to say perhaps. Fa=
r more difficult is to implement it. Especially the idea of reallocating me=
mory that wasn't allocated with new[]. Remember: new[] is generally impleme=
nted as array-size+array, so the block of allocated memory contains both. T=
rying to turn something that wasn't an array into an array is not a good th=
ing.<br><br>Also, remember that `new` does more than just allocate memory; =
it constructs objects. So you can't just assume that you can copy bits of m=
emory around and get the "same" objects.<br><br>That's why I like the way t=
hat the proposal suggests sticking it inside the allocator, as the allocato=
r handles the dichotomy between allocation and construction explicitly. Gra=
nted, I don't like the idea of reallocation failure (ie: not being able to =
expand the allocation memory) being indicated by throwing std::bad_alloc, a=
s this will happen extremely often in real applications. Stack rollbacks an=
d such are not cheap, and since it's a common, expected occurrence, it shou=
ld not be something that an exception is thrown over.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_93_24180585.1358907288962--

.

------=_Part_265_19067743.1358908335240
Content-Type: text/plain; charset=ISO-8859-1

Right, but if the reallocation succeeds, you can just add to the array
size, so the fact that the allocated memory includes a size, I think, won't
matter too much. As for copying bits around, perhaps I misread the paper,
but the semantics of a C++-friendly realloc are that it never copies
anything- it only reallocates in place if possible. Else, it fails.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_265_19067743.1358908335240
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Right, but if the reallocation succeeds, you can just add to the array size=
, so the fact that the allocated memory includes a size, I think, won't mat=
ter too much. As for copying bits around, perhaps I misread the paper, but =
the semantics of a C++-friendly realloc are that it never copies anything- =
it only reallocates in place if possible. Else, it fails.

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_265_19067743.1358908335240--

.

One interesting development that I think illustrates the need for
something like what is proposed here, is the vector implementation
provided by Facebook's "folly" C++ library[1]. It achieves better
performance by specifically detecting the jemalloc allocator, and
cooperating with it in ways that would not be possible using only the
standard allocator interfaces.

[1] https://github.com/facebook/folly/blob/master/folly/docs/FBVector.md


--

---
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/?hl=en.



.

------=_Part_1562_21840922.1387178531084
Content-Type: text/plain; charset=ISO-8859-1

Hello,

I'm a member of the SC22WG21 in Japan. I discussed N3495 with other
members. We are interested in this proposal very much. It is a practical
proposal. We will get as good performance as the C. N2045 is more
ambitious, but it was rejected.

I'd like to share some feedback from the members including me.

1. The name idea
   How about resize? It's very simple.

2. Feedback about the interface

We recommend the different interface as follows:

static bool
resize(Alloc& a, pointer p, size_type n_cur, size_type n_new) {
    a.resize(p, n_cur, n_new);
}

This function never replace the pointer p, hence it doesn't need to return
p.

N3495 said that "the fallback definition would be inline and a good
compiler could detect this and optimize the throw/catch away". I tested the
following code using g++ version 4.8.2 and clang++ version 3.3 with
optimize option -O3, -O4, and -O5.

// Pattern 1
int main() {
    try {
        throw std::bad_alloc();
    }
    catch (std::bad_alloc const&) {
        return 0;
    }
    return 0;
}

// Pattern 2
int main() {
    return 0;
}

The compilers output the different code, it seems that try-catch block
isn't removed.

Also we considered about the risks to mis-use. I believe that we can assume
that the points of calling this function are usually in libraries, and the
programmers who develop these kinds of libraries have pretty high skills.
Because of those reasons, we recommend the bool return value interface.

3. Compile time support detection
It seems that N3495 doesn't refer that when the allocator's resize
functionality supporting is detected. It should be detected at compile time
as follows:

template <typename Alloc>
class std::allocator_traits {
template <typename T>
static constexpr auto has_resize() -> decltype( std::declval<T>().resize(
nullptr, 0, 0), bool()) { return true; }
static constexpr bool has_resize(...) { return false; }
template <typename T>
auto resize(T& a, pointer p, size_type n_cur, size_type n_new)
-> typename std::enable_if<std::is_same<Alloc, T>::value &&
has_resize<T>(), bool>::type {
return a.resize(p, n_cur, n_new);
}
bool resize(...) {
return false;
}
};

4. std::allocator::resize

The programming language C currently supports malloc, free, and realloc. To
implement std::allocator::resize, I considered the two ways to do that. One
is adding the resize function to the C stantard library. I think that it is
difficult because there is no incentive to add it for C programmers. The
other is adding resize member function to std::allocators, and the
implementation accesses the internal structure of the C standard library.
The internal structure means something like a freelist, heap structure and
so on. I believe that the latter is more practical approach than former.

5. shrink case failure

This is not a problem. I just would like to add the note about resize
failure case. Even though the new size is smaller than the current size,
resiz1e might fail. Because when the allocator's implementer uses the size
value as a key of the small object chunk, shrink memory size sometimes
crosses the different size chunk. In this case, if resize changes the size
and returns true, the consistency will be broken. When the deallocate
function is called with the size, the size is no longer corresponds to the
chunk that the memory is allocated from. So, the allocator implementer can
return 'false' any case to keep the allocator's consistency.


--

---
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_1562_21840922.1387178531084
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello,</div><div><br></div><div>I'm a member of the S=
C22WG21 in Japan. I discussed N3495 with other members. We are interested i=
n this proposal very much. It is a practical proposal. We will get as&nbsp;=
good performance as the C. N2045 is more ambitious, but it was rejected.</d=
iv><div><br></div><div>I'd like to share some feedback from the members inc=
luding me.</div><div><br></div><div>1. The name idea</div><div>&nbsp; &nbsp=
;How about resize? It's very simple.</div><div><br></div><div>2. Feedback a=
bout the interface</div><div><br></div><div>We recommend the different inte=
rface as follows:</div><div><br></div><div><span id=3D"b9fe6f1e-44b2-4881-8=
388-bdb118046237" ginger_software_uiphraseguid=3D"cb759d9f-8ec6-47b9-867c-d=
9ab5438003f" class=3D"GINGER_SOFTWARE_mark">static</span> <span id=3D"db8b4=
37f-53a5-4c95-9158-1d01dd9d3f49" ginger_software_uiphraseguid=3D"cb759d9f-8=
ec6-47b9-867c-d9ab5438003f" class=3D"GINGER_SOFTWARE_mark">bool</span></div=
><div><span id=3D"b6faafda-0d78-46bf-83f5-03903a5c2917" ginger_software_uip=
hraseguid=3D"a2b9a72a-64c8-4b75-b9e1-04ef49e3205e" class=3D"GINGER_SOFTWARE=
_mark">resize</span><span id=3D"436f31ec-a8cf-4b0f-b346-f95c1d8d9de3" ginge=
r_software_uiphraseguid=3D"a2b9a72a-64c8-4b75-b9e1-04ef49e3205e" class=3D"G=
INGER_SOFTWARE_mark">(</span>Alloc&amp; a, pointer p, size_type n_cur, size=
_type n_new) {</div><div>&nbsp; &nbsp; <span id=3D"3483e634-3fbe-4cbc-830e-=
dace65e54fc7" ginger_software_uiphraseguid=3D"28f5585d-83c2-48f1-9532-0b274=
39cd396" class=3D"GINGER_SOFTWARE_mark">a.</span><span id=3D"b077c72e-4cf7-=
4dcf-ab64-458acee9ac96" ginger_software_uiphraseguid=3D"28f5585d-83c2-48f1-=
9532-0b27439cd396" class=3D"GINGER_SOFTWARE_mark">resize</span><span id=3D"=
01371a7f-23b0-40d4-ac41-57028467cba0" ginger_software_uiphraseguid=3D"28f55=
85d-83c2-48f1-9532-0b27439cd396" class=3D"GINGER_SOFTWARE_mark">(</span>p, =
n_cur, n_new);</div><div>}</div><div><br></div><div>This function <span id=
=3D"0e31a622-9e55-404f-be9f-fd41d63576ef" ginger_software_uiphraseguid=3D"6=
8d926f2-d2f8-4bc5-83bb-451a8f8650ca" class=3D"GINGER_SOFTWARE_mark">never r=
eplace</span> the pointer p, hence it doesn't need to return p.</div><div><=
br></div><div>N3495 said that "the fallback definition would be <span id=3D=
"219823a3-ba03-4500-b4a8-40a1c677db97" ginger_software_uiphraseguid=3D"0028=
bf34-a2da-4d0d-9f5b-5d87dd09a482" class=3D"GINGER_SOFTWARE_mark">inline</sp=
an> and a good compiler could detect this and optimize the throw/catch away=
". I tested the following code using g++ version 4.8.2 and clang++ version =
3.3 with optimize option -O3, -O4, and -O5.</div><div><br></div><div>// Pat=
tern 1</div><div><span id=3D"787af679-02c5-4101-8851-cd16c881fcab" ginger_s=
oftware_uiphraseguid=3D"66689cda-32bc-4543-b989-d9b1dd52a0f0" class=3D"GING=
ER_SOFTWARE_mark">int</span> main<span id=3D"afe6fde8-e7ae-45e4-9914-cc5e2b=
4d4648" ginger_software_uiphraseguid=3D"66689cda-32bc-4543-b989-d9b1dd52a0f=
0" class=3D"GINGER_SOFTWARE_mark">(</span>) {</div><div>&nbsp; &nbsp; <span=
 id=3D"0c7f8ffa-3f14-41ee-bc08-fb04a869a65c" ginger_software_uiphraseguid=
=3D"262c49a7-1377-4bb8-9f00-a348cf75bc1e" class=3D"GINGER_SOFTWARE_mark">tr=
y</span> {</div><div>&nbsp; &nbsp; &nbsp; &nbsp; <span id=3D"d87c43eb-4af6-=
4db3-85be-d97c166c4b3e" ginger_software_uiphraseguid=3D"7cc99d3a-fdd4-4a05-=
8c80-8c566ce91794" class=3D"GINGER_SOFTWARE_mark">throw</span> <span id=3D"=
53b73e63-f5f5-4755-afcf-a8ed0f632500" ginger_software_uiphraseguid=3D"7cc99=
d3a-fdd4-4a05-8c80-8c566ce91794" class=3D"GINGER_SOFTWARE_mark">std</span>:=
<span id=3D"6fcd2292-748d-4895-84e1-a79000e7783f" ginger_software_uiphraseg=
uid=3D"7cc99d3a-fdd4-4a05-8c80-8c566ce91794" class=3D"GINGER_SOFTWARE_mark"=
>:</span>bad_alloc<span id=3D"c61c8b1e-45c8-4f28-a465-6b1898f20b54" ginger_=
software_uiphraseguid=3D"7cc99d3a-fdd4-4a05-8c80-8c566ce91794" class=3D"GIN=
GER_SOFTWARE_mark">(</span>);</div><div>&nbsp; &nbsp; }</div><div>&nbsp; &n=
bsp; <span id=3D"4bfc3f1c-0aa0-4fe1-bc36-65fff5182b09" ginger_software_uiph=
raseguid=3D"913f64f4-0ebf-47de-937b-718e169ca15d" class=3D"GINGER_SOFTWARE_=
mark">catch</span> (<span id=3D"449d9685-74f4-4503-b4d5-6df612897efd" ginge=
r_software_uiphraseguid=3D"913f64f4-0ebf-47de-937b-718e169ca15d" class=3D"G=
INGER_SOFTWARE_mark">std</span>:<span id=3D"a54ca2d1-805b-4243-ae2f-eb97226=
97fb8" ginger_software_uiphraseguid=3D"913f64f4-0ebf-47de-937b-718e169ca15d=
" class=3D"GINGER_SOFTWARE_mark">:</span>bad_alloc const&amp;) {</div><div>=
&nbsp; &nbsp; &nbsp; &nbsp; <span id=3D"a93467ed-77a8-4e71-9be6-307bfd07e17=
e" ginger_software_uiphraseguid=3D"ad5d4d40-8823-497c-9acd-fec978cbf56b" cl=
ass=3D"GINGER_SOFTWARE_mark">return</span> 0;</div><div>&nbsp; &nbsp; }</di=
v><div>&nbsp; &nbsp; <span id=3D"f298c318-c0cc-4dd7-a598-95981ef4f4fb" ging=
er_software_uiphraseguid=3D"69811eef-cc10-4214-854f-e64fae413b2f" class=3D"=
GINGER_SOFTWARE_mark">return</span> 0;</div><div>}</div><div><br></div><div=
>// Pattern 2</div><div><span id=3D"27b45cc2-1c5e-40ed-84b6-078c64c53234" g=
inger_software_uiphraseguid=3D"c165416c-10c0-4be5-9df1-8694f296bcd7" class=
=3D"GINGER_SOFTWARE_mark">int</span> main<span id=3D"c5311ad9-87fa-46bb-8d8=
3-16dfa94d7568" ginger_software_uiphraseguid=3D"c165416c-10c0-4be5-9df1-869=
4f296bcd7" class=3D"GINGER_SOFTWARE_mark">(</span>) {</div><div>&nbsp; &nbs=
p; <span id=3D"49855d6f-c45f-410f-b1a7-deea1a9bcec1" ginger_software_uiphra=
seguid=3D"69795df3-1ab2-4a06-aef2-fa2b89f483a7" class=3D"GINGER_SOFTWARE_ma=
rk">return</span> 0;</div><div>}</div><div><br></div><div>The compilers out=
put the different code, it seems that try-catch block isn't removed.</div><=
div><br></div><div>Also we considered about the risks to <span id=3D"390dd2=
80-8152-4389-b56b-1838311b0ed6" ginger_software_uiphraseguid=3D"ceee9dcb-16=
1d-455b-b013-db885b18b185" class=3D"GINGER_SOFTWARE_mark">mis-use</span>. I=
 believe that we can assume that the points of calling this function are us=
ually in libraries, and the programmers who develop these kinds of librarie=
s have pretty high skills. Because of those reasons, we recommend the <span=
 id=3D"b39e7b36-dcba-4f96-b267-3614516be6bc" ginger_software_uiphraseguid=
=3D"219d0d25-8741-4d30-918c-cd01a6eab48b" class=3D"GINGER_SOFTWARE_mark">bo=
ol</span> return value interface.</div><div><br></div><div>3. Compile time =
support detection</div><div>It seems that N3495 doesn't refer that when the=
 allocator's resize functionality supporting is detected. It should be dete=
cted at compile time as follows:</div><div><br></div><div><span id=3D"a806b=
d90-1091-494f-9c42-4cc534794c37" ginger_software_uiphraseguid=3D"7b114d22-3=
c14-46f5-8583-e1c46603ec6e" class=3D"GINGER_SOFTWARE_mark">template</span> =
&lt;<span id=3D"5fa8d781-0b8f-407c-baba-85465817ab06" ginger_software_uiphr=
aseguid=3D"7b114d22-3c14-46f5-8583-e1c46603ec6e" class=3D"GINGER_SOFTWARE_m=
ark">typename</span> Alloc&gt;</div><div><span id=3D"582da257-3dd3-4ea0-9e0=
a-05803ff368db" ginger_software_uiphraseguid=3D"b9a6731d-7bff-4b01-80ea-6f4=
b613f145a" class=3D"GINGER_SOFTWARE_mark">class</span> <span id=3D"2b5e76e4=
-80dd-416f-b587-0d5241d4c186" ginger_software_uiphraseguid=3D"b9a6731d-7bff=
-4b01-80ea-6f4b613f145a" class=3D"GINGER_SOFTWARE_mark">std</span>:<span id=
=3D"377dd64d-197d-45ae-aeb8-a3cd620e2f2a" ginger_software_uiphraseguid=3D"b=
9a6731d-7bff-4b01-80ea-6f4b613f145a" class=3D"GINGER_SOFTWARE_mark">:</span=
>allocator_traits {</div><div><span class=3D"Apple-tab-span" style=3D"white=
-space:pre"> </span><span id=3D"ecfaf490-65d8-49e7-ad0a-cc23affde2fe" ginge=
r_software_uiphraseguid=3D"aa6bb2a5-05c8-4196-9d21-29486fa8a9fd" class=3D"G=
INGER_SOFTWARE_mark">template</span> &lt;<span id=3D"3d42b57c-c80c-4da2-9bc=
9-e4ca00e7c704" ginger_software_uiphraseguid=3D"aa6bb2a5-05c8-4196-9d21-294=
86fa8a9fd" class=3D"GINGER_SOFTWARE_mark">typename</span> T&gt;</div><div><=
span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span><span id=3D=
"0f5078eb-45e3-42c6-b5ba-d3f6966adf55" ginger_software_uiphraseguid=3D"396d=
6fb5-4500-4fe9-9d7b-ab526f95f16f" class=3D"GINGER_SOFTWARE_mark">static</sp=
an> <span id=3D"e27f7e13-6716-4f46-936f-d986eb8eba92" ginger_software_uiphr=
aseguid=3D"396d6fb5-4500-4fe9-9d7b-ab526f95f16f" class=3D"GINGER_SOFTWARE_m=
ark">constexpr</span> auto has_resize<span id=3D"d083a3ff-5158-494e-a2a8-a5=
ca8dbacf26" ginger_software_uiphraseguid=3D"396d6fb5-4500-4fe9-9d7b-ab526f9=
5f16f" class=3D"GINGER_SOFTWARE_mark">(</span>) -&gt; <span id=3D"f1909178-=
2cfd-47ab-81d9-e7f094786530" ginger_software_uiphraseguid=3D"396d6fb5-4500-=
4fe9-9d7b-ab526f95f16f" class=3D"GINGER_SOFTWARE_mark">decltype</span><span=
 id=3D"20594dae-6b99-4d22-a3a5-6d830b049fdb" ginger_software_uiphraseguid=
=3D"396d6fb5-4500-4fe9-9d7b-ab526f95f16f" class=3D"GINGER_SOFTWARE_mark">(<=
/span> <span id=3D"444b66b3-c4d3-47e2-ae16-73f47d9809c2" ginger_software_ui=
phraseguid=3D"396d6fb5-4500-4fe9-9d7b-ab526f95f16f" class=3D"GINGER_SOFTWAR=
E_mark">std</span>:<span id=3D"0459bdf1-9778-433b-a0e4-76af429c2c01" ginger=
_software_uiphraseguid=3D"396d6fb5-4500-4fe9-9d7b-ab526f95f16f" class=3D"GI=
NGER_SOFTWARE_mark">:</span><span id=3D"ed5da325-0efc-473c-8848-ec40be1eb6c=
3" ginger_software_uiphraseguid=3D"396d6fb5-4500-4fe9-9d7b-ab526f95f16f" cl=
ass=3D"GINGER_SOFTWARE_mark">declval</span>&lt;T&gt;()<span id=3D"b8637cb4-=
5d56-497b-8624-2ebb279a129d" ginger_software_uiphraseguid=3D"396d6fb5-4500-=
4fe9-9d7b-ab526f95f16f" class=3D"GINGER_SOFTWARE_mark">.</span>resize<span =
id=3D"be6eb0c9-ee32-46e9-8797-0091329dc718" ginger_software_uiphraseguid=3D=
"396d6fb5-4500-4fe9-9d7b-ab526f95f16f" class=3D"GINGER_SOFTWARE_mark">(</sp=
an><span id=3D"a2388f6f-2ce3-4abe-a42c-baf22c811c7c" ginger_software_uiphra=
seguid=3D"396d6fb5-4500-4fe9-9d7b-ab526f95f16f" class=3D"GINGER_SOFTWARE_ma=
rk">nullptr</span>, 0, 0), <span id=3D"13071d21-01f4-4dfa-897d-69ef92f4f3d5=
" ginger_software_uiphraseguid=3D"396d6fb5-4500-4fe9-9d7b-ab526f95f16f" cla=
ss=3D"GINGER_SOFTWARE_mark">bool</span><span id=3D"3a1ede44-206b-4f63-9188-=
473cba01bee2" ginger_software_uiphraseguid=3D"396d6fb5-4500-4fe9-9d7b-ab526=
f95f16f" class=3D"GINGER_SOFTWARE_mark">(</span>)) { return true; }</div><d=
iv><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span><span i=
d=3D"b2fc5bd9-0c32-406a-a5f3-356dd928df7d" ginger_software_uiphraseguid=3D"=
d8d4b9a0-ec94-4141-9bee-5965fb3200fd" class=3D"GINGER_SOFTWARE_mark">static=
</span> constexpr bool has_resize<span id=3D"eb58bd48-461e-4e81-948e-49feff=
5f8bd5" ginger_software_uiphraseguid=3D"d8d4b9a0-ec94-4141-9bee-5965fb3200f=
d" class=3D"GINGER_SOFTWARE_mark">(</span>...) { return false; }</div><div>=
<span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span><span id=
=3D"f4d11a88-4cab-44b9-a6f2-2337f60a2709" ginger_software_uiphraseguid=3D"f=
026ee34-3f03-42be-980d-9e021923f222" class=3D"GINGER_SOFTWARE_mark">templat=
e</span> &lt;<span id=3D"ac5bcc30-8507-414f-8e12-37854fd2ef51" ginger_softw=
are_uiphraseguid=3D"f026ee34-3f03-42be-980d-9e021923f222" class=3D"GINGER_S=
OFTWARE_mark">typename</span> T&gt;</div><div><span class=3D"Apple-tab-span=
" style=3D"white-space:pre"> </span><span id=3D"85843b91-4c00-4572-ab29-5da=
b2887fd00" ginger_software_uiphraseguid=3D"950e7cb2-d4b1-4ed0-819a-65938590=
c314" class=3D"GINGER_SOFTWARE_mark">auto</span> resize<span id=3D"44edf156=
-0d58-44cf-bf6f-fbb98f92d68a" ginger_software_uiphraseguid=3D"950e7cb2-d4b1=
-4ed0-819a-65938590c314" class=3D"GINGER_SOFTWARE_mark">(</span>T&amp; a, p=
ointer p, size_type n_cur, size_type n_new)</div><div><span class=3D"Apple-=
tab-span" style=3D"white-space:pre">  </span>-&gt; <span id=3D"613ad837-72d=
a-4013-a6ca-766318a0c6d0" ginger_software_uiphraseguid=3D"bd841b2e-3ac4-477=
e-ad5e-b6cd64f81769" class=3D"GINGER_SOFTWARE_mark">typename</span> <span i=
d=3D"b03a1f35-d23b-4216-a15f-69c5b22c18bf" ginger_software_uiphraseguid=3D"=
bd841b2e-3ac4-477e-ad5e-b6cd64f81769" class=3D"GINGER_SOFTWARE_mark">std</s=
pan>:<span id=3D"a2ba94c0-d58b-40fb-8524-2cdf460b4d2a" ginger_software_uiph=
raseguid=3D"bd841b2e-3ac4-477e-ad5e-b6cd64f81769" class=3D"GINGER_SOFTWARE_=
mark">:</span>enable_if&lt;<span id=3D"bc8570ae-f486-4f71-8dd6-a3458a15835f=
" ginger_software_uiphraseguid=3D"bd841b2e-3ac4-477e-ad5e-b6cd64f81769" cla=
ss=3D"GINGER_SOFTWARE_mark">std</span>:<span id=3D"2d503b14-d680-47f3-a6a1-=
d156cab8f088" ginger_software_uiphraseguid=3D"bd841b2e-3ac4-477e-ad5e-b6cd6=
4f81769" class=3D"GINGER_SOFTWARE_mark">:</span>is_same&lt;Alloc, T&gt;:<sp=
an id=3D"14f6f47b-c721-4bbe-9988-f89bb08e8eba" ginger_software_uiphraseguid=
=3D"bd841b2e-3ac4-477e-ad5e-b6cd64f81769" class=3D"GINGER_SOFTWARE_mark">:<=
/span>value &amp;&amp; has_resize&lt;T&gt;(), <span id=3D"97a107b0-77c6-44a=
5-bdf5-12bd273f83d5" ginger_software_uiphraseguid=3D"bd841b2e-3ac4-477e-ad5=
e-b6cd64f81769" class=3D"GINGER_SOFTWARE_mark">bool</span>&gt;:<span id=3D"=
232d0374-c706-43db-bbf1-0843543c7429" ginger_software_uiphraseguid=3D"bd841=
b2e-3ac4-477e-ad5e-b6cd64f81769" class=3D"GINGER_SOFTWARE_mark">:</span>typ=
e {</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre">  </=
span><span id=3D"978f58af-7e89-4d04-bce1-5be23c015ffc" ginger_software_uiph=
raseguid=3D"ea996122-206e-4565-acb6-14d56749bba8" class=3D"GINGER_SOFTWARE_=
mark">return</span> <span id=3D"fcb373c7-3c24-4a98-89a5-68aa6d6a0008" ginge=
r_software_uiphraseguid=3D"ea996122-206e-4565-acb6-14d56749bba8" class=3D"G=
INGER_SOFTWARE_mark">a.</span>resize<span id=3D"fabc24e7-09b5-42bf-a8c2-9d9=
2a7093832" ginger_software_uiphraseguid=3D"ea996122-206e-4565-acb6-14d56749=
bba8" class=3D"GINGER_SOFTWARE_mark">(</span>p, n_cur, n_new);</div><div><s=
pan class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>}</div><div>=
<span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span><span id=
=3D"8f8d3a44-afe7-4268-91b8-a530922e54b4" ginger_software_uiphraseguid=3D"2=
8bb1180-c57e-4184-8533-1dcfffca6bf0" class=3D"GINGER_SOFTWARE_mark">bool</s=
pan> resize<span id=3D"d5f189c1-3a4e-43ce-a697-56ef053b1812" ginger_softwar=
e_uiphraseguid=3D"28bb1180-c57e-4184-8533-1dcfffca6bf0" class=3D"GINGER_SOF=
TWARE_mark">(</span>...) {</div><div><span class=3D"Apple-tab-span" style=
=3D"white-space:pre">  </span><span id=3D"97b2a984-ec9e-4289-a70d-497452add=
5d1" ginger_software_uiphraseguid=3D"bbfa5ce5-f85b-463f-a8a3-51142fe33f35" =
class=3D"GINGER_SOFTWARE_mark">return</span> false;</div><div><span class=
=3D"Apple-tab-span" style=3D"white-space:pre"> </span>}</div><div>};</div><=
div><br></div><div>4. <span id=3D"51c1bfca-3218-4246-b6cf-d8627ff894d1" gin=
ger_software_uiphraseguid=3D"3968250b-c40c-488a-92f6-a8ab7d819df8" class=3D=
"GINGER_SOFTWARE_mark">std</span>:<span id=3D"9650aee8-f8e1-4ba9-afa0-22451=
42c3d41" ginger_software_uiphraseguid=3D"3968250b-c40c-488a-92f6-a8ab7d819d=
f8" class=3D"GINGER_SOFTWARE_mark">:</span>allocator:<span id=3D"08f3fd8d-d=
f96-4573-bddd-05af8d5cad08" ginger_software_uiphraseguid=3D"3968250b-c40c-4=
88a-92f6-a8ab7d819df8" class=3D"GINGER_SOFTWARE_mark">:</span>resize</div><=
div><br></div><div>The programming language C currently supports <span id=
=3D"ef07a667-a472-4c4f-9b30-5287491350ec" ginger_software_uiphraseguid=3D"e=
75f3931-a519-4afa-bb2d-540e07c1a025" class=3D"GINGER_SOFTWARE_mark">malloc<=
/span>, free, and <span id=3D"6a88f840-e74e-4c11-addf-1a75bfceb2ca" ginger_=
software_uiphraseguid=3D"e75f3931-a519-4afa-bb2d-540e07c1a025" class=3D"GIN=
GER_SOFTWARE_mark">realloc</span>. To implement <span id=3D"87a6f19c-512b-4=
ab8-b410-8e74ab412136" ginger_software_uiphraseguid=3D"4639a1f7-629d-4d8b-b=
53c-adf1a17511b7" class=3D"GINGER_SOFTWARE_mark">std</span>:<span id=3D"7b8=
e3c42-58b7-4198-8c19-86810640dc6e" ginger_software_uiphraseguid=3D"4639a1f7=
-629d-4d8b-b53c-adf1a17511b7" class=3D"GINGER_SOFTWARE_mark">:</span>alloca=
tor:<span id=3D"5bae5409-b3e7-4ea8-93c5-42ea628a1772" ginger_software_uiphr=
aseguid=3D"4639a1f7-629d-4d8b-b53c-adf1a17511b7" class=3D"GINGER_SOFTWARE_m=
ark">:</span>resize, I considered the two ways to do that. One is adding th=
e resize function to the C <span id=3D"e8bf2a84-79fd-49a9-9006-d24e57d2559e=
" ginger_software_uiphraseguid=3D"d4b27a5e-0960-44c1-8861-51ddc2c1d8ab" cla=
ss=3D"GINGER_SOFTWARE_mark">stantard</span> library. I think that it is dif=
ficult because there is no incentive to add it for C programmers. The other=
 is adding resize member function to <span id=3D"2c3c6a51-7f5b-422e-99f8-ec=
2057685d2f" ginger_software_uiphraseguid=3D"adaf33f7-c714-4cbc-9fe0-5c49d5c=
513b5" class=3D"GINGER_SOFTWARE_mark">std</span>:<span id=3D"08de4304-2e4b-=
4136-a90e-c6ea1c1febf8" ginger_software_uiphraseguid=3D"adaf33f7-c714-4cbc-=
9fe0-5c49d5c513b5" class=3D"GINGER_SOFTWARE_mark">:</span>allocators, and t=
he implementation accesses the internal structure of the C standard library=
.. The internal structure means something like a <span id=3D"6b07f016-a63a-4=
b01-9bb5-e9f7852a7ecc" ginger_software_uiphraseguid=3D"43bc2027-527d-4ec1-9=
12f-0e41fa6bdc3c" class=3D"GINGER_SOFTWARE_mark">freelist</span>, heap stru=
cture and so on. I believe that the latter is <span id=3D"77a6a479-dba8-456=
2-8673-da1ce580f830" ginger_software_uiphraseguid=3D"08026a8b-9fdd-494e-ac9=
7-09bbf50e18ff" class=3D"GINGER_SOFTWARE_mark">more practical approach</spa=
n> than former.</div><div><br></div><div>5. <span id=3D"9e4e1416-426a-403f-=
a441-df7075c084fc" ginger_software_uiphraseguid=3D"706860f1-60c3-4505-8dda-=
76bd841fc67a" class=3D"GINGER_SOFTWARE_mark">shrink</span> <span id=3D"7295=
092e-b85f-4318-a49a-47efb64367fe" ginger_software_uiphraseguid=3D"706860f1-=
60c3-4505-8dda-76bd841fc67a" class=3D"GINGER_SOFTWARE_mark">case</span> fai=
lure</div><div><br></div><div>This is not a problem. I just would like to a=
dd the note about resize failure case. Even though the new size is smaller =
than the current size, resiz1e might fail. Because when the allocator's imp=
lementer uses the size value as a key of the small object chunk, shrink mem=
ory size sometimes crosses the different size chunk. In this case, if resiz=
e changes the size and returns true, the consistency will be broken. When t=
he deallocate function is called with the size, the size is no longer corre=
sponds to the chunk that the memory is allocated from. So, the allocator im=
plementer can return 'false' any case to keep the allocator's consistency.<=
/div><div><br></div><div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1562_21840922.1387178531084--

.

On domingo, 15 de dezembro de 2013 23:22:11, Takatoshi Kondo wrote:
>  One
> is adding the resize function to the C stantard library. I think that it is
> difficult because there is no incentive to add it for C programmers.

Of course there is. If we see a benefit, they do too, in similar structures and
circumstances. Just make it more "C friendly"

 void *realloc_inplace(void *ptr, size_t newsize);

It must return ptr or NULL.

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

--

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

.

On 12/16/13 3:22 PM, Takatoshi Kondo wrote:
> static bool
> resize(Alloc& a, pointer p, size_type n_cur, size_type n_new) {
>      a.resize(p, n_cur, n_new);
> }
>
> This function never replace the pointer p, hence it doesn't need to return
> p.
>
> N3495 said that "the fallback definition would be inline and a good
> compiler could detect this and optimize the throw/catch away". I tested the
> following code using g++ version 4.8.2 and clang++ version 3.3 with
> optimize option -O3, -O4, and -O5.

Agreed; I have never seen a compiler optimize even a local throw away.

Since the entire point of resize is to save the cost of making an
unnecessary copy/move, if on some platform it really spends a few
thousand CPU cycles on a throw, then it's very broken.

If there is some risk that the user may not use the Boolean result, it
would be nice for the implementation to detect such and provide a
warning. To provide for this, let the return value be
implementation-specific and contextually convertible to bool. I plan to
propose a facility for must-use values, but this case doesn't require
standardization of details, at least for std::allocator.

> 3. Compile time support detection
> It seems that N3495 doesn't refer that when the allocator's resize
> functionality supporting is detected. It should be detected at compile time
> as follows:

If resize is provided as a free function "std::resize_allocation" rather
than a static member, then an ADL-based function template (called in the
context of "using std::resize_allocation;") can catch unsupported calls
and return (constexpr) false. Furthermore, if the return type
requirement is weakened to contextual conversion to bool,
std::false_type would be a valid return type.

I don't want to muddle the debate with alternatives. But if the user is
working with different allocators, there is little to do with
has_resize() except implement a non-member, SFINAE wrapper function that
calls the member if it exists. We should avoid interfaces that are
useless without such boilerplate.

--

---
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_3321_32825514.1387372093241
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

2013 $BG/ (B12 $B7n (B16 $BF|7nMKF| (B 16 $B;~ (B40 $BJ, (B42 $BIC (B UTC+9 Thiago Macieira:

> On domingo, 15 de dezembro de 2013 23:22:11, Takatoshi Kondo wrote:
> >  One
> > is adding the resize function to the C stantard library. I think that
> it is
> > difficult because there is no incentive to add it for C programmers.
>
> Of course there is.


I should have written that I couldn't find any persuasive reason to add
realloc_inplace to the C standard library rather than there is no
incentive. C++ has a big incentive to add it because C++ need to avoid
shallow copy, but C doesn't. I think that realloc is good enough for C. I'd
like to find the benefit of realloc_inplace for C.

If we see a benefit, they do too, in similar structures and
> circumstances. Just make it more "C friendly"
>
>         void *realloc_inplace(void *ptr, size_t newsize);
>
> It must return ptr or NULL.
>

If we add realloc_inplace on C, I agree to your interface and semantics.
Then the C++ standard library's implementation only depends on the C
standard library's public interface for memory allocation, deallocation,
and resize. I believe that it is a better implementation structure than
direct memory structure manipulation by C++ function.

Takatoshi Kondo

--

---
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_3321_32825514.1387372093241
Content-Type: text/html; charset=ISO-2022-JP
Content-Transfer-Encoding: base64

PGRpdiBkaXI9Imx0ciI+PGRpdj4yMDEzGyRCRy8bKEIxMhskQjduGyhCMTYbJEJGfDduTUtGfBso
QiAxNhskQjt+GyhCNDAbJEJKLBsoQjQyGyRCSUMbKEIgVVRDKzkgVGhpYWdvIE1hY2llaXJhOjxi
cj48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46IDA7
bWFyZ2luLWxlZnQ6IDAuOGV4O2JvcmRlci1sZWZ0OiAxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxl
ZnQ6IDFleDsiPk9uIDxzcGFuIGlkPSJiNmEzMWZlMS0zYTJmLTRiODAtOWFmYS1iMDNkNTQ3OWY5
ODUiIGdpbmdlcl9zb2Z0d2FyZV91aXBocmFzZWd1aWQ9IjJkYjBmNGU3LWI2YmMtNDQ1YS05YjIy
LTE0M2QyN2QyZDcxNCIgY2xhc3M9IkdJTkdFUl9TT0ZUV0FSRV9tYXJrIj5kb21pbmdvPC9zcGFu
PiwgMTUgZGUgPHNwYW4gaWQ9ImM0ZGFhNjM3LTE5ZTctNGQzYy04ZmY4LTdjZDUwMmY1NjRiMiIg
Z2luZ2VyX3NvZnR3YXJlX3VpcGhyYXNlZ3VpZD0iMmRiMGY0ZTctYjZiYy00NDVhLTliMjItMTQz
ZDI3ZDJkNzE0IiBjbGFzcz0iR0lOR0VSX1NPRlRXQVJFX21hcmsiPmRlemVtYnJvPC9zcGFuPiA8
c3BhbiBpZD0iN2ZkNDdkMDQtZjg2NS00YTU0LWIyNTItOTc0YzMzODJmNWZlIiBnaW5nZXJfc29m
dHdhcmVfdWlwaHJhc2VndWlkPSIyZGIwZjRlNy1iNmJjLTQ0NWEtOWIyMi0xNDNkMjdkMmQ3MTQi
IGNsYXNzPSJHSU5HRVJfU09GVFdBUkVfbWFyayI+ZGU8L3NwYW4+IDIwMTMgMjM6MjI6MTEsIFRh
a2F0b3NoaSBLb25kbyB3cm90ZToNCjxicj4mZ3Q7ICZuYnNwO09uZSANCjxicj4mZ3Q7IDxzcGFu
IGlkPSJkYjdiYzBmMi00MzlhLTRhOGYtOTZhOS0wMmVhNmM1YWQyOGEiIGdpbmdlcl9zb2Z0d2Fy
ZV91aXBocmFzZWd1aWQ9ImZmNmQ3M2FjLWM2NGQtNGI1Ny1hNDk5LWVhNDI1NDYzOTMzYyIgY2xh
c3M9IkdJTkdFUl9TT0ZUV0FSRV9tYXJrIj5pczwvc3Bhbj4gYWRkaW5nIHRoZSByZXNpemUgZnVu
Y3Rpb24gdG8gdGhlIEMgPHNwYW4gaWQ9ImNlMTNhOTM4LTM1ZjMtNGZkZC1iNDY4LWUxZDExMGEz
YTAxMSIgZ2luZ2VyX3NvZnR3YXJlX3VpcGhyYXNlZ3VpZD0iZmY2ZDczYWMtYzY0ZC00YjU3LWE0
OTktZWE0MjU0NjM5MzNjIiBjbGFzcz0iR0lOR0VSX1NPRlRXQVJFX21hcmsiPnN0YW50YXJkPC9z
cGFuPiBsaWJyYXJ5LiBJIHRoaW5rIHRoYXQgaXQgaXMgDQo8YnI+Jmd0OyA8c3BhbiBpZD0iYjZh
ZDk2Y2YtNDJlNC00NzhhLWI5YTYtOTVlMzdhNGZjNWZmIiBnaW5nZXJfc29mdHdhcmVfdWlwaHJh
c2VndWlkPSJiMTczODkzNy1jZDgwLTRhZjMtOWE5Zi1hZTA1ZTZmZjdiNGMiIGNsYXNzPSJHSU5H
RVJfU09GVFdBUkVfbWFyayI+ZGlmZmljdWx0PC9zcGFuPiBiZWNhdXNlIHRoZXJlIGlzIG5vIGlu
Y2VudGl2ZSB0byBhZGQgaXQgZm9yIEMgcHJvZ3JhbW1lcnMuDQo8YnI+DQo8YnI+T2YgY291cnNl
IHRoZXJlIGlzLiA8L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5JIHNob3VsZCBoYXZl
IHdyaXR0ZW4gdGhhdCBJIGNvdWxkbid0IGZpbmQgYW55IHBlcnN1YXNpdmUgcmVhc29uIHRvIGFk
ZCByZWFsbG9jX2lucGxhY2UgdG8gdGhlIEMgc3RhbmRhcmQgbGlicmFyeSByYXRoZXIgdGhhbiB0
aGVyZSBpcyBubyBpbmNlbnRpdmUuIEMrKyBoYXMgYSBiaWcgaW5jZW50aXZlIHRvIGFkZCBpdCBi
ZWNhdXNlIEMrKyBuZWVkIHRvIGF2b2lkIHNoYWxsb3cgY29weSwgYnV0IEMgZG9lc24ndC4gSSB0
aGluayB0aGF0IDxzcGFuIGlkPSI3M2EyNTVlYi1hMzA2LTRjMGYtYmQwMS01ZjE1ZTEwZmFkZTgi
IGdpbmdlcl9zb2Z0d2FyZV91aXBocmFzZWd1aWQ9IjE0MWJkZjU3LWMxMTUtNDQ3Ni1iZTcxLTM0
NTZhY2E1NGEyOSIgY2xhc3M9IkdJTkdFUl9TT0ZUV0FSRV9tYXJrIj5yZWFsbG9jPC9zcGFuPiZu
YnNwO2lzIGdvb2QgZW5vdWdoIGZvciBDLiBJJ2QgbGlrZSB0byBmaW5kIHRoZSBiZW5lZml0IG9m
IHJlYWxsb2NfaW5wbGFjZSBmb3IgQy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48YmxvY2txdW90ZSBj
bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46IDA7bWFyZ2luLWxlZnQ6IDAuOGV4O2Jv
cmRlci1sZWZ0OiAxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6IDFleDsiPklmIHdlIHNlZSBh
IGJlbmVmaXQsIHRoZXkgZG8gdG9vLCBpbiBzaW1pbGFyIHN0cnVjdHVyZXMgYW5kIA0KPGJyPjxz
cGFuIGlkPSI4ZWI5NGIxMy0wYjlhLTQxMDctYWUwNC0wNmViNWY0ODc5MjYiIGdpbmdlcl9zb2Z0
d2FyZV91aXBocmFzZWd1aWQ9ImJhZDE3YjllLTNiZmEtNGY0NC04OTYzLTFkZWJlZjRlYzhkYyIg
Y2xhc3M9IkdJTkdFUl9TT0ZUV0FSRV9tYXJrIj5jaXJjdW1zdGFuY2VzPC9zcGFuPi4gSnVzdCBt
YWtlIGl0IG1vcmUgIkMgZnJpZW5kbHkiDQo8YnI+DQo8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gaWQ9IjQ2NjI5YzEwLTY3ZmQtNDJhYi05
OWE0LTA1NTEwYjVhMzg5MyIgZ2luZ2VyX3NvZnR3YXJlX3VpcGhyYXNlZ3VpZD0iNjg2YmUxZDct
MThiZS00ZjEyLWE5ZWQtZjYxYzY5NjBmZjM3IiBjbGFzcz0iR0lOR0VSX1NPRlRXQVJFX21hcmsi
PnZvaWQ8L3NwYW4+ICpyZWFsbG9jX2lucGxhY2U8c3BhbiBpZD0iOGI4ODU4NWEtNzVhOS00MDM0
LTg4NjMtOTZiNTdkODIyNjc3IiBnaW5nZXJfc29mdHdhcmVfdWlwaHJhc2VndWlkPSI2ODZiZTFk
Ny0xOGJlLTRmMTItYTllZC1mNjFjNjk2MGZmMzciIGNsYXNzPSJHSU5HRVJfU09GVFdBUkVfbWFy
ayI+KDwvc3Bhbj52b2lkICpwdHIsIHNpemVfdCBuZXdzaXplKTsNCjxicj4NCjxicj5JdCBtdXN0
IHJldHVybiA8c3BhbiBpZD0iZTZkZjRjODgtYTg3My00Nzk4LWIxNTYtNTU2ODhkYzEyYjY3IiBn
aW5nZXJfc29mdHdhcmVfdWlwaHJhc2VndWlkPSJjNzRkYzk3NS1kZDI4LTQ1NWUtODYzMi05MTY4
YTZhMGMyNjMiIGNsYXNzPSJHSU5HRVJfU09GVFdBUkVfbWFyayI+cHRyPC9zcGFuPiBvciBOVUxM
Lg0KPGJyPjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2PklmIHdlIGFkZCByZWFsbG9j
X2lucGxhY2Ugb24gQywgSSBhZ3JlZSB0byB5b3VyIGludGVyZmFjZSBhbmQgc2VtYW50aWNzLiBU
aGVuIHRoZSBDKysgc3RhbmRhcmQgbGlicmFyeSdzIGltcGxlbWVudGF0aW9uIG9ubHkgZGVwZW5k
cyBvbiB0aGUgQyBzdGFuZGFyZCBsaWJyYXJ5J3MgcHVibGljIGludGVyZmFjZSBmb3IgbWVtb3J5
IGFsbG9jYXRpb24sIGRlYWxsb2NhdGlvbiwgYW5kIHJlc2l6ZS4gSSBiZWxpZXZlJm5ic3A7dGhh
dCBpdCBpcyBhIGJldHRlciBpbXBsZW1lbnRhdGlvbiBzdHJ1Y3R1cmUgdGhhbiBkaXJlY3QgbWVt
b3J5IHN0cnVjdHVyZSBtYW5pcHVsYXRpb24gYnkgQysrIGZ1bmN0aW9uLjwvZGl2PjxkaXY+PGJy
PjwvZGl2PjxkaXY+PHNwYW4gaWQ9IjcwZGE3OWFlLTdjZDUtNGViNy1iOGZkLWRmYWZjODgyNzU1
MyIgZ2luZ2VyX3NvZnR3YXJlX3VpcGhyYXNlZ3VpZD0iNGQyZTUyOWItMGYwYS00NTNhLWI5NmEt
ZmE0YzEzNGQ2YTk5IiBjbGFzcz0iR0lOR0VSX1NPRlRXQVJFX21hcmsiPlRha2F0b3NoaTwvc3Bh
bj4mbmJzcDtLb25kbzxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rpdj4NCg0KPHA+PC9wPg0K
DQotLSA8YnIgLz4NCiZuYnNwOzxiciAvPg0KLS0tIDxiciAvPg0KWW91IHJlY2VpdmVkIHRoaXMg
bWVzc2FnZSBiZWNhdXNlIHlvdSBhcmUgc3Vic2NyaWJlZCB0byB0aGUgR29vZ2xlIEdyb3VwcyAm
cXVvdDtJU08gQysrIFN0YW5kYXJkIC0gRnV0dXJlIFByb3Bvc2FscyZxdW90OyBncm91cC48YnIg
Lz4NClRvIHVuc3Vic2NyaWJlIGZyb20gdGhpcyBncm91cCBhbmQgc3RvcCByZWNlaXZpbmcgZW1h
aWxzIGZyb20gaXQsIHNlbmQgYW4gZW1haWwgdG8gc3RkLXByb3Bvc2Fscyt1bnN1YnNjcmliZUBp
c29jcHAub3JnLjxiciAvPg0KVG8gcG9zdCB0byB0aGlzIGdyb3VwLCBzZW5kIGVtYWlsIHRvIHN0
ZC1wcm9wb3NhbHNAaXNvY3BwLm9yZy48YnIgLz4NClZpc2l0IHRoaXMgZ3JvdXAgYXQgPGEgaHJl
Zj0iaHR0cDovL2dyb3Vwcy5nb29nbGUuY29tL2EvaXNvY3BwLm9yZy9ncm91cC9zdGQtcHJvcG9z
YWxzLyI+aHR0cDovL2dyb3Vwcy5nb29nbGUuY29tL2EvaXNvY3BwLm9yZy9ncm91cC9zdGQtcHJv
cG9zYWxzLzwvYT4uPGJyIC8+DQo=
------=_Part_3321_32825514.1387372093241--

.

--nextPart1997290.umWibakhIF
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On quarta-feira, 18 de dezembro de 2013 05:08:13, Takatoshi Kondo wrote:
> I should have written that I couldn't find any persuasive reason to add
> realloc_inplace to the C standard library rather than there is no
> incentive. C++ has a big incentive to add it because C++ need to avoid
> shallow copy, but C doesn't. I think that realloc is good enough for C. I'd
> like to find the benefit of realloc_inplace for C.

I'm saying that the same requirements that you have found for C++ apply to C
too.

In any case, even if you can't convince WG14 to add to the library, please
define the interface in the C++ standard as extern "C" and basically force it
as a C API, like the atomics were done.

By the way, we might want to add an argument for alignment.

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

--nextPart1997290.umWibakhIF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iD8DBQBSsbpUM/XwBW70U1gRAsqrAJ9BQYJxZiRhjOafGKOgkjakp70chACgpao2
ATTnxr+YUNm6UNq38gbCtaE=
=rsQn
-----END PGP SIGNATURE-----

--nextPart1997290.umWibakhIF--


.

------=_Part_121_10547857.1387406743182
Content-Type: text/plain; charset=ISO-8859-1

Apart from the realloc_inplace functionality I think it would be beneficial
to be able to ask to what maximum size a certain memory block can be
reallocated without move. The idea is to be able to minimize the number of
moves using this additional info. To be able to do the realloc_inplace this
information would of course be needed inside the malloc implementation
anyway.

Being able to ask for the size after a new[] would also be very useful of
course, but I think there are some issues with this.

Den onsdagen den 18:e december 2013 kl. 16:07:57 UTC+1 skrev Thiago
Macieira:
>
> On quarta-feira, 18 de dezembro de 2013 05:08:13, Takatoshi Kondo wrote:
> > I should have written that I couldn't find any persuasive reason to add
> > realloc_inplace to the C standard library rather than there is no
> > incentive. C++ has a big incentive to add it because C++ need to avoid
> > shallow copy, but C doesn't. I think that realloc is good enough for C.
> I'd
> > like to find the benefit of realloc_inplace for C.
>
> I'm saying that the same requirements that you have found for C++ apply to
> C
> too.
>
> In any case, even if you can't convince WG14 to add to the library, please
> define the interface in the C++ standard as extern "C" and basically force
> it
> as a C API, like the atomics were done.
>
> By the way, we might want to add an argument for alignment.
>
> --
> 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
>

--

---
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_121_10547857.1387406743182
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Apart from the realloc_inplace functionality I think it wo=
uld be beneficial to be able to ask to what maximum size a certain memory b=
lock can be reallocated without move. The idea is to be able to minimize th=
e number of moves using this additional info. To be able to do the realloc_=
inplace this information would of course be needed inside the malloc implem=
entation anyway.<div><br></div><div>Being able to ask for the size after a =
new[] would also be very useful of course, but I think there are some issue=
s with this.<br><br>Den onsdagen den 18:e december 2013 kl. 16:07:57 UTC+1 =
skrev Thiago Macieira:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On quart=
a-feira, 18 de dezembro de 2013 05:08:13, Takatoshi Kondo wrote:
<br>&gt; I should have written that I couldn't find any persuasive reason t=
o add=20
<br>&gt; realloc_inplace to the C standard library rather than there is no=
=20
<br>&gt; incentive. C++ has a big incentive to add it because C++ need to a=
void=20
<br>&gt; shallow copy, but C doesn't. I think that realloc is good enough f=
or C. I'd=20
<br>&gt; like to find the benefit of realloc_inplace for C.
<br>
<br>I'm saying that the same requirements that you have found for C++ apply=
 to C=20
<br>too.
<br>
<br>In any case, even if you can't convince WG14 to add to the library, ple=
ase=20
<br>define the interface in the C++ standard as extern "C" and basically fo=
rce it=20
<br>as a C API, like the atomics were done.
<br>
<br>By the way, we might want to add an argument for alignment.
<br>
<br>--=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>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br></blockquote></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_121_10547857.1387406743182--

.

On quarta-feira, 18 de dezembro de 2013 14:45:43, Bengt Gustafsson wrote:
> Apart from the realloc_inplace functionality I think it would be beneficial
> to be able to ask to what maximum size a certain memory block can be
> reallocated without move. The idea is to be able to minimize the number of
> moves using this additional info. To be able to do the realloc_inplace this
> information would of course be needed inside the malloc implementation
> anyway.

I'm not sure of the usefulness of that.... Do you mean a global parameter? I
think most malloc / realloc / realloc_inplace implementations will only be
able to not move depending on what else is allocated around, so this will be
dependent on the buffer in question.

Moreover, it is also time-dependent. Since memory is a pooled resource between
threads, the result of such a call is invalid after the function has returned.
It's possible that the number has grown if another thread has freed data
adjacent to this block, but it's also possible that it has shrunk if malloc in
another thread serviced the request by returning adjacent memory. This is very
possible if you're trying to realloc a buffer that was originally allocated in
another thread.

> Being able to ask for the size after a new[] would also be very useful of
> course, but I think there are some issues with this.

You can't realloc_inplace for new[]. If you want to realloc, you must use
malloc(). Especially since the array new[] must save the size of the array in
the buffer, the pointer that you got is most likely not the pointer that it got
from malloc().

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

--

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

.

--001a11c301fc13abd404edd7ad29
Content-Type: text/plain; charset=ISO-8859-1

It seems like a better place to provide this kind of thing would be on an
STL allocator interface. If an allocator supports inplace expansion, they
could declare that they do so in the interface, and callers could inspect
this and do the right thing at compile time. (It would be implementation
defined whether std::allocator supported such a thing) This neatly avoids
the problem described here:

>You can't realloc_inplace for new[]. If you want to realloc, you must use
>malloc(). Especially since the array new[] must save the size of the array
in
>the buffer, the pointer that you got is most likely not the pointer that
it got
>from malloc().

and encourages use of the more extensible allocator mechanism.

Would a valid implementation of realloc_inplace be:

    void* realloc_inplace(void*) { return nullptr; }

if a given allocator didn't support doing anything special for growth?
(e.g. Windows' Low Fragmentation Heap explicitly does not support in place
reallocations; changing an allocation size changes the bucket to which it
belongs)

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Wed, Dec 18, 2013 at 3:31 PM, Thiago Macieira <thiago@macieira.org>wrote:

> On quarta-feira, 18 de dezembro de 2013 14:45:43, Bengt Gustafsson wrote:
> > Apart from the realloc_inplace functionality I think it would be
> beneficial
> > to be able to ask to what maximum size a certain memory block can be
> > reallocated without move. The idea is to be able to minimize the number
> of
> > moves using this additional info. To be able to do the realloc_inplace
> this
> > information would of course be needed inside the malloc implementation
> > anyway.
>
> I'm not sure of the usefulness of that.... Do you mean a global parameter?
> I
> think most malloc / realloc / realloc_inplace implementations will only be
> able to not move depending on what else is allocated around, so this will
> be
> dependent on the buffer in question.
>
> Moreover, it is also time-dependent. Since memory is a pooled resource
> between
> threads, the result of such a call is invalid after the function has
> returned.
> It's possible that the number has grown if another thread has freed data
> adjacent to this block, but it's also possible that it has shrunk if
> malloc in
> another thread serviced the request by returning adjacent memory. This is
> very
> possible if you're trying to realloc a buffer that was originally
> allocated in
> another thread.
>
> > Being able to ask for the size after a new[] would also be very useful of
> > course, but I think there are some issues with this.
>
> You can't realloc_inplace for new[]. If you want to realloc, you must use
> malloc(). Especially since the array new[] must save the size of the array
> in
> the buffer, the pointer that you got is most likely not the pointer that
> it got
> from malloc().
>
> --
> 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
>
> --
>
> ---
> 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/.

--001a11c301fc13abd404edd7ad29
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>It seems like a better place to provide this kind of =
thing would be on an STL allocator interface. If an allocator supports inpl=
ace expansion, they could declare that they do so in the interface, and cal=
lers could inspect this and do the right thing at compile time. (It would b=
e implementation defined whether std::allocator supported such a thing) Thi=
s neatly avoids the problem described here:</div>

<div><br></div><div>&gt;You can&#39;t realloc_inplace for new[]. If you wan=
t to realloc, you must use</div><div>&gt;malloc(). Especially since the arr=
ay new[] must save the size of the array in</div><div>&gt;the buffer, the p=
ointer that you got is most likely not the pointer that it got</div>

<div>&gt;from malloc().</div><div><br></div><div>and encourages use of the =
more extensible allocator mechanism.</div><div><br></div><div>Would a valid=
 implementation of realloc_inplace be:</div><div><br></div><div>=A0=A0=A0 v=
oid* realloc_inplace(void*) { return nullptr; }</div>

<div><br></div><div>if a given allocator didn&#39;t support doing anything =
special for growth? (e.g. Windows&#39; Low Fragmentation Heap explicitly do=
es not support in place reallocations; changing an allocation size changes =
the bucket to which it belongs)</div>

</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
 target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Wed, Dec 18, 2013 at 3:31 PM, Thiago =
Macieira <span dir=3D"ltr">&lt;<a href=3D"mailto:thiago@macieira.org" targe=
t=3D"_blank">thiago@macieira.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

On quarta-feira, 18 de dezembro de 2013 14:45:43, Bengt Gustafsson wrote:<b=
r>
&gt; Apart from the realloc_inplace functionality I think it would be benef=
icial<br>
&gt; to be able to ask to what maximum size a certain memory block can be<b=
r>
&gt; reallocated without move. The idea is to be able to minimize the numbe=
r of<br>
&gt; moves using this additional info. To be able to do the realloc_inplace=
 this<br>
&gt; information would of course be needed inside the malloc implementation=
<br>
&gt; anyway.<br>
<br>
I&#39;m not sure of the usefulness of that.... Do you mean a global paramet=
er? I<br>
think most malloc / realloc / realloc_inplace implementations will only be<=
br>
able to not move depending on what else is allocated around, so this will b=
e<br>
dependent on the buffer in question.<br>
<br>
Moreover, it is also time-dependent. Since memory is a pooled resource betw=
een<br>
threads, the result of such a call is invalid after the function has return=
ed.<br>
It&#39;s possible that the number has grown if another thread has freed dat=
a<br>
adjacent to this block, but it&#39;s also possible that it has shrunk if ma=
lloc in<br>
another thread serviced the request by returning adjacent memory. This is v=
ery<br>
possible if you&#39;re trying to realloc a buffer that was originally alloc=
ated in<br>
another thread.<br>
<br>
&gt; Being able to ask for the size after a new[] would also be very useful=
 of<br>
&gt; course, but I think there are some issues with this.<br>
<br>
You can&#39;t realloc_inplace for new[]. If you want to realloc, you must u=
se<br>
malloc(). Especially since the array new[] must save the size of the array =
in<br>
the buffer, the pointer that you got is most likely not the pointer that it=
 got<br>
from malloc().<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
=A0 =A0Software Architect - Intel Open Source Technology Center<br>
=A0 =A0 =A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=A0 =A0 =A0 E067 918B B660 DBD1 105C =A0966C 33F5 F005 6EF4 5358<br>
<br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--001a11c301fc13abd404edd7ad29--

.

On quarta-feira, 18 de dezembro de 2013 15:47:24, Billy O'Neal wrote:
> It seems like a better place to provide this kind of thing would be on an
> STL allocator interface. If an allocator supports inplace expansion, they
> could declare that they do so in the interface, and callers could inspect
> this and do the right thing at compile time. (It would be implementation
> defined whether std::allocator supported such a thing) This neatly avoids
> the problem described here:

I still think we may want it in non-allocator contexts. The most basic
implementation of this is going to be coupled with malloc(), which is why I
think this should start in a C library function.

Whether we provide this option in an allocator in the C++ Standard Library or
even if it should exist in the default allocator, I'll leave that to other
people.

> >You can't realloc_inplace for new[]. If you want to realloc, you must use
> >malloc(). Especially since the array new[] must save the size of the array
> >in
> >the buffer, the pointer that you got is most likely not the pointer that
> >it got
> >from malloc().
>
> and encourages use of the more extensible allocator mechanism.

Right. You can't use it for new or new[], but you may be able to use in an
allocator. (I'd hope, I don't even know std::allocator API)

> Would a valid implementation of realloc_inplace be:
>
>     void* realloc_inplace(void*) { return nullptr; }
>
> if a given allocator didn't support doing anything special for growth?

Yes. For any system where the C library does not provide the support, that's
what it would need to be.

> (e.g. Windows' Low Fragmentation Heap explicitly does not support in place
> reallocations; changing an allocation size changes the bucket to which it
> belongs)

Right, I've seen many allocators like that. But it might still work depending
on where your original allocation ended up. If you allocated 1200 bytes and
was given a block of the 2048-byte bucket, you can still increase in size
without triggering a reallocation. The same goes for shrinking.

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

--

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

.

Hi Takatoshi Kondo,

I'm sorry for not writing back earlier.  I have neglected my personal
e-mail quite a bit and am only now in a position to catch up.

I added comments inline and would love to hear back if you're still
interested. :)

I will draft up an update on the proposal over the weekend.


On 16/12/13 07:22, Takatoshi Kondo wrote:
> I'm a member of the SC22WG21 in Japan. I discussed N3495 with other
> members. We are interested in this proposal very much.  It is a practical
> proposal. We will get as good performance as the C. N2045 is more
> ambitious, but it was rejected.
>
> I'd like to share some feedback from the members including me.
>
> 1. The name idea
>     How about resize? It's very simple.

Yes.

> 2. Feedback about the interface
>
> We recommend the different interface as follows:
>
> static bool
> resize(Alloc& a, pointer p, size_type n_cur, size_type n_new) {
> a.resize(p, n_cur, n_new);
> }
>
> This function never replace the pointer p, hence it doesn't need to
> return p.

I'm much in favour of that, it makes the code simpler.

> N3495 said that "the fallback definition would be inline and a good
> compiler could detect this and optimize the throw/catch away". I tested
> the following code using g++ version 4.8.2 and clang++ version 3.3 with
> optimize option -O3, -O4, and -O5.
>
> // Pattern 1
> int main() {
> try {
> throw std::bad_alloc();
>      }
> catch (std::bad_alloc const&) {
> return 0;
>      }
> return 0;
> }
>
> // Pattern 2
> int main() {
> return 0;
> }
>
> The compilers output the different code, it seems that try-catch block
> isn't removed.

Hmm, indeed.

I'm a bit torn about how to handle std::bad_alloc.  On the one hand, the
bool interface does not require an allocator implementation to throw
this exception (since the same is communicated through the return type).
On the other hand, an allocator implementation may have an easier time
communicating failure through a throw, rather than a return.  I wouldn't
want the generated code to have a try-catch if it doesn't need it.
Perhaps the resize() function should have be noexcept, if the underlying
implementation is noexcept?

> Also we considered about the risks to mis-use. I believe that we can
> assume that the points of calling this function are usually in
> libraries, and the programmers who develop these kinds of libraries have
> pretty high skills. Because of those reasons, we recommend the bool
> return value interface.

That's fair enough.

> 3. Compile time support detection
> It seems that N3495 doesn't refer that when the allocator's resize
> functionality supporting is detected. It should be detected at compile
> time as follows:
>
> template <typename Alloc>
> class std::allocator_traits {
> template <typename T>
> static constexpr auto has_resize() -> decltype(
> std::declval<T>().resize(nullptr, 0, 0), bool()) { return true; }
> static constexpr bool has_resize(...) { return false; }
> template <typename T>
> auto resize(T& a, pointer p, size_type n_cur, size_type n_new)
> -> typename std::enable_if<std::is_same<Alloc, T>::value &&
> has_resize<T>(), bool>::type {
> return a.resize(p, n_cur, n_new);
> }
> bool resize(...) {
> return false;
> }
> };

Yes.

> 4. std::allocator::resize
>
> The programming language C currently supports malloc, free, and realloc.
> To implement std::allocator::resize, I considered the two ways to do
> that. One is adding the resize function to the C stantard library. I
> think that it is difficult because there is no incentive to add it for C
> programmers. The other is adding resize member function to
> std::allocators, and the implementation accesses the internal structure
> of the C standard library. The internal structure means something like a
> freelist, heap structure and so on. I believe that the latter is more
> practical approach than former.

A third option is to make std::allocator::resize optional, I suppose.
std::allocator_traits::resize is still required to function as described.

Adding a resize member function that access internal malloc structures
is dangerous because:
- std::allocator may be implemented in terms of operator new/delete,
which are allowed to be overriden at link time,
- operator new/delete may be implemented in terms of malloc/free, which
are allowed to be overriden at link time as well.

I think a better approach would be, to require that if an implementation
implements std::allocator::resize, they'll have to provide an
implementation for the allocate() and deallocate() as well.  Thus
maintaining backward compatibility with c++11 and earlier.

> 5. shrink case failure
>
> This is not a problem. I just would like to add the note about resize
> failure case. Even though the new size is smaller than the current size,
> resiz1e might fail. Because when the allocator's implementer uses the
> size value as a key of the small object chunk, shrink memory size
> sometimes crosses the different size chunk. In this case, if resize
> changes the size and returns true, the consistency will be broken. When
> the deallocate function is called with the size, the size is no longer
> corresponds to the chunk that the memory is allocated from. So, the
> allocator implementer can return 'false' any case to keep the
> allocator's consistency.

Yes.

--
Ariane

--

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

.

Do not forget that one important use-case if for std::vector. I
believe it would be important to be able to get back less than
allocated.
So something like

size_t std::resize(void* p,size_t new_size);
// resizes the area pointed to by p. Returns the size of the new area
which for an expansion might be smaller than the area requested.

Also, perhaps an implementation such as:

size_t std::resize(void*,size_t) { return 0; }

should be allowed. Certainly this allows an easy migration path for
code that will have to run on a platform where a 'real' resize is not
implemented yet.

/Peter

On 2/28/14, Ariane van der Steldt <ariane@stack.nl> wrote:
> Hi Takatoshi Kondo,
>
> I'm sorry for not writing back earlier.  I have neglected my personal
> e-mail quite a bit and am only now in a position to catch up.
>
> I added comments inline and would love to hear back if you're still
> interested. :)
>
> I will draft up an update on the proposal over the weekend.
>
>
> On 16/12/13 07:22, Takatoshi Kondo wrote:
>> I'm a member of the SC22WG21 in Japan. I discussed N3495 with other
>> members. We are interested in this proposal very much.  It is a practical
>> proposal. We will get as good performance as the C. N2045 is more
>> ambitious, but it was rejected.
>>
>> I'd like to share some feedback from the members including me.
>>
>> 1. The name idea
>>     How about resize? It's very simple.
>
> Yes.
>
>> 2. Feedback about the interface
>>
>> We recommend the different interface as follows:
>>
>> static bool
>> resize(Alloc& a, pointer p, size_type n_cur, size_type n_new) {
>> a.resize(p, n_cur, n_new);
>> }
>>
>> This function never replace the pointer p, hence it doesn't need to
>> return p.
>
> I'm much in favour of that, it makes the code simpler.
>
>> N3495 said that "the fallback definition would be inline and a good
>> compiler could detect this and optimize the throw/catch away". I tested
>> the following code using g++ version 4.8.2 and clang++ version 3.3 with
>> optimize option -O3, -O4, and -O5.
>>
>> // Pattern 1
>> int main() {
>> try {
>> throw std::bad_alloc();
>>      }
>> catch (std::bad_alloc const&) {
>> return 0;
>>      }
>> return 0;
>> }
>>
>> // Pattern 2
>> int main() {
>> return 0;
>> }
>>
>> The compilers output the different code, it seems that try-catch block
>> isn't removed.
>
> Hmm, indeed.
>
> I'm a bit torn about how to handle std::bad_alloc.  On the one hand, the
> bool interface does not require an allocator implementation to throw
> this exception (since the same is communicated through the return type).
> On the other hand, an allocator implementation may have an easier time
> communicating failure through a throw, rather than a return.  I wouldn't
> want the generated code to have a try-catch if it doesn't need it.
> Perhaps the resize() function should have be noexcept, if the underlying
> implementation is noexcept?
>
>> Also we considered about the risks to mis-use. I believe that we can
>> assume that the points of calling this function are usually in
>> libraries, and the programmers who develop these kinds of libraries have
>> pretty high skills. Because of those reasons, we recommend the bool
>> return value interface.
>
> That's fair enough.
>
>> 3. Compile time support detection
>> It seems that N3495 doesn't refer that when the allocator's resize
>> functionality supporting is detected. It should be detected at compile
>> time as follows:
>>
>> template <typename Alloc>
>> class std::allocator_traits {
>> template <typename T>
>> static constexpr auto has_resize() -> decltype(
>> std::declval<T>().resize(nullptr, 0, 0), bool()) { return true; }
>> static constexpr bool has_resize(...) { return false; }
>> template <typename T>
>> auto resize(T& a, pointer p, size_type n_cur, size_type n_new)
>> -> typename std::enable_if<std::is_same<Alloc, T>::value &&
>> has_resize<T>(), bool>::type {
>> return a.resize(p, n_cur, n_new);
>> }
>> bool resize(...) {
>> return false;
>> }
>> };
>
> Yes.
>
>> 4. std::allocator::resize
>>
>> The programming language C currently supports malloc, free, and realloc.
>> To implement std::allocator::resize, I considered the two ways to do
>> that. One is adding the resize function to the C stantard library. I
>> think that it is difficult because there is no incentive to add it for C
>> programmers. The other is adding resize member function to
>> std::allocators, and the implementation accesses the internal structure
>> of the C standard library. The internal structure means something like a
>> freelist, heap structure and so on. I believe that the latter is more
>> practical approach than former.
>
> A third option is to make std::allocator::resize optional, I suppose.
> std::allocator_traits::resize is still required to function as described.
>
> Adding a resize member function that access internal malloc structures
> is dangerous because:
> - std::allocator may be implemented in terms of operator new/delete,
> which are allowed to be overriden at link time,
> - operator new/delete may be implemented in terms of malloc/free, which
> are allowed to be overriden at link time as well.
>
> I think a better approach would be, to require that if an implementation
> implements std::allocator::resize, they'll have to provide an
> implementation for the allocate() and deallocate() as well.  Thus
> maintaining backward compatibility with c++11 and earlier.
>
>> 5. shrink case failure
>>
>> This is not a problem. I just would like to add the note about resize
>> failure case. Even though the new size is smaller than the current size,
>> resiz1e might fail. Because when the allocator's implementer uses the
>> size value as a key of the small object chunk, shrink memory size
>> sometimes crosses the different size chunk. In this case, if resize
>> changes the size and returns true, the consistency will be broken. When
>> the deallocate function is called with the size, the size is no longer
>> corresponds to the chunk that the memory is allocated from. So, the
>> allocator implementer can return 'false' any case to keep the
>> allocator's consistency.
>
> Yes.
>
> --
> Ariane
>
> --
>
> ---
> 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/.

.