------=_Part_406_1392490413.1484009328041
Content-Type: multipart/alternative;
 boundary="----=_Part_407_173409702.1484009328041"

------=_Part_407_173409702.1484009328041
Content-Type: text/plain; charset=UTF-8

string/vector extensions for C interop

I've started this thread so the original thread it came doesn't continue to
get re-directed.
I've taken some comments from that to restart the discussion and re-worked
my example a bit. So:

We seem to have a situation where C is in free-fall decline (at least on
the tiobe index).

But if we can do more to support C programmers moving over to C++ it would
be a win for both camps.
C++ users could use certain performance tuning in this area regardless
because we use C.

To quote r very own mr smith:

"The fact that you can't resize a string or vector without initializing its
elements is a measurable and significant performance problem for some
applications; I have seen people invent their own string type or do truly
horrible things to std::string (directly poking at its internals) to
circumvent that."

So what can we do to stop this?


I have seen a lot of code like this that I'd like to not write/fix/use:

char* do_something_for_c_library()
{
 std::string s;
 s.resize(n+1); // We don't want zero fill here.
// SomeCAPI takes a pointer an a length and returns the actual length it
filled.
 auto len = SomeCAPI(s.data(), n); /* Win32 I'm looking at you. */
 s.resize(len)

 s += "hello";

 char* ptr = malloc(s.length()+1);
 if (!ptr)
  return nullptr;

 strcpy(ptr, s.data());

 return ptr;
}


There are various reasons people use string like this (but vector also).
These are:
1. They just intend to return a string eventually but need data from a C
like API. Fill can be expensive.
2. They need some RAII thing so if there's an exception the destructor will
release the memory.
3. They could use unique_ptr but they want to do some string'y things first.
4. They want string for the small buffer optimization.
5. They sometimes need to return the buffer to C.

It doesn't seem like a big deal, but this is often in performance critical
code. The sizes aren't always trivial.
So why can't we make this easier and more efficient?


To get this discussion started, how about:

char* do_something_for_c_library()
{
 std::string s;

 auto len = SomeCAPI(s.uinitialized_data_at(0, n+1), n);
 s.resize(len);

 s+="hello";
 return s.detach_and_string_terminate(); // And provide basic detach also.
}

s.uinitialized_data_at does this:
Ensures that a range of elements starting at 0 for length n exists.
and if it doesn't it extends it without initialization.
The starting position should exist or it's an error unless it is 0 and the
string is empty.
if it can't allocate or the offset or length is bad the it throws a
std::logic_error(); explaining the problem.


I don't see why we can't provide this same API for vector.
detach_and_string_terminate() could just be enable_if'd only types of
char/wchar_t/unsigned char/char32_t/char16_t.


unintialized_data_at() could just be enabled for these types too for now if
that helps safety.
I think this would:
1. Increase performance as it enables a lot less pointless initializing of
data that will only be overwritten.
2. Increase performance because it enables a lot of less excess allocations
in many cases.
3. Reduce code size because the library is doing the work.
4. Improve safety because the library is doing the safety checking for the
main fail points that users often don't check.
It has to do some checking anyway because it may be re-allocating.
5. Help C programmers and C++ programmers who have to use or enable C api's.

We could provide data_at() too. These can be free functions perhaps.
I would like an API to request allocation of an exact buffer size too but
that doesn't have to be these API's.

The detach api proposal can be separate from the data_at idea.
I don't think this idea needs to wait for some perfect language extensions.

Questions:
Why not basically this?
Do we really need to wait 3 years for ALL of this?
But is providing the minimum to support a minimum of the
uninitialized_data_at routine so hard that we need to wait?
If there's something better. What is it?

Thanks

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/06264fe0-3983-4128-aa91-76b5d128b385%40isocpp.org.

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

<div dir=3D"ltr"><div>string/vector extensions for C interop</div><div><br>=
</div><div>I&#39;ve started this thread so the original thread it came=C2=
=A0doesn&#39;t continue to get=C2=A0re-directed.</div><div>I&#39;ve taken s=
ome comments from that to restart the discussion and re-worked my example a=
 bit. So:</div><div><br>We seem to have a situation where C is in free-fall=
 decline (at least on the tiobe index).</div><p>But if we can do more to su=
pport C programmers moving over to C++ it would be a win for both camps.</p=
><div>C++ users=C2=A0could use certain performance tuning in this area rega=
rdless because we use C.</div><div><br>To quote r very own mr smith:</div><=
p>&quot;The fact that you can&#39;t resize a string or vector without initi=
alizing its elements is a measurable and significant performance problem fo=
r some applications; I have seen people invent their own string type or do =
truly horrible things to std::string (directly poking at its internals) to =
circumvent that.&quot;</p><div><br></div><div>So what can we do to stop thi=
s?</div><p><br>I have seen a lot of code like this that I&#39;d like to not=
 write/fix/use:</p><div><br>char* do_something_for_c_library()<br>{<br>=C2=
=A0std::string s;<br>=C2=A0s.resize(n+1); // We don&#39;t want zero fill he=
re.</div><div>// SomeCAPI takes a pointer an a length and returns the actua=
l length it filled.<br>=C2=A0auto len =3D SomeCAPI(s.data(), n); /* Win32 I=
&#39;m looking at you. */<br>=C2=A0s.resize(len)</div><p>=C2=A0s +=3D &quot=
;hello&quot;;</p><p>=C2=A0char* ptr =3D malloc(s.length()+1);<br>=C2=A0if (=
!ptr)<br>=C2=A0=C2=A0return nullptr;</p><p>=C2=A0strcpy(ptr, s.data());<br>=
</p><p>=C2=A0return ptr;<br>}</p><p><br>There are various reasons people us=
e string like this (but vector also). These are:<br>1. They just intend to =
return a string eventually but need data from a C like API.=C2=A0Fill can b=
e expensive.<br>2. They=C2=A0need some RAII thing so if there&#39;s an exce=
ption the destructor will release the memory.<br>3. They could use unique_p=
tr but they want to do some string&#39;y things first.<br>4. They want stri=
ng for=C2=A0the small buffer optimization.<br>5. They sometimes need to ret=
urn the buffer to C.</p><div><br></div><div>It doesn&#39;t seem like a big =
deal, but this is often in performance critical code. The sizes aren&#39;t =
always trivial.</div><div>So why can&#39;t we make this easier and more eff=
icient?</div><div><br></div><div><br></div><div>To get this discussion star=
ted,=C2=A0how about:</div><div><br></div><p>char* do_something_for_c_librar=
y()<br>{<br>=C2=A0std::string s;</p><p>=C2=A0auto len =3D SomeCAPI(s.uiniti=
alized_data_at(0, n+1), n);<br>=C2=A0s.resize(len);</p><p>=C2=A0s+=3D&quot;=
hello&quot;;<br>=C2=A0return s.detach_and_string_terminate(); // And provid=
e basic detach also.<br>}</p><p>s.uinitialized_data_at does this:<br>Ensure=
s that a range of elements starting at 0 for length n exists.<br>and if it =
doesn&#39;t it extends it without initialization.<br>The starting position =
should exist or it&#39;s an error unless it is 0 and the string is empty.<b=
r>if it can&#39;t allocate or the offset or length is bad the it throws a s=
td::logic_error(); explaining the problem.</p><p><br>I don&#39;t see why we=
 can&#39;t provide this same API for vector.<br>detach_and_string_terminate=
() could just be enable_if&#39;d only types of char/wchar_t/unsigned char/c=
har32_t/char16_t.</p><p><br>unintialized_data_at() could just be enabled fo=
r these types too for now if that helps safety.</p><div>I think this would:=
<br>1. Increase performance as it enables a lot less pointless initializing=
 of data that will only be overwritten.<br>2. Increase performance because =
it enables a lot of less excess allocations in many cases.<br>3. Reduce cod=
e size because the library is doing the work.</div><div>4. Improve safety b=
ecause the library is doing the safety checking for the main fail points th=
at users often don&#39;t check.</div><div>It has to do some checking anyway=
=C2=A0because it may be re-allocating.<br>5. Help C programmers and C++ pro=
grammers who have to use or enable C api&#39;s.</div><div><br></div><div>We=
 could provide data_at() too. These can be free functions perhaps.</div><di=
v>I would like an API to request allocation of an exact buffer size too but=
 that doesn&#39;t have to be these API&#39;s.</div><div><br></div><div>The =
detach api proposal can be separate from the data_at idea.</div><div>I don&=
#39;t think this idea needs to wait for some perfect language extensions.</=
div><div><br></div><div>Questions:</div><div>Why not basically this?</div><=
div>Do we really need to wait 3 years for ALL of this?</div><div><div>But i=
s=C2=A0providing=C2=A0the minimum to support a minimum of the uninitialized=
_data_at=C2=A0routine=C2=A0so hard that we need to wait?</div>If there&#39;=
s something better. What is it?</div><div><br></div><div>Thanks</div><div><=
br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/06264fe0-3983-4128-aa91-76b5d128b385%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/06264fe0-3983-4128-aa91-76b5d128b385=
%40isocpp.org</a>.<br />

------=_Part_407_173409702.1484009328041--

------=_Part_406_1392490413.1484009328041--

.

------=_Part_1322_1747381655.1484012154749
Content-Type: multipart/alternative;
 boundary="----=_Part_1323_478382746.1484012154749"

------=_Part_1323_478382746.1484012154749
Content-Type: text/plain; charset=UTF-8



On Monday, January 9, 2017 at 7:48:48 PM UTC-5, gmis...@gmail.com wrote:
>
> string/vector extensions for C interop
>
> I've started this thread so the original thread it came doesn't continue
> to get re-directed.
> I've taken some comments from that to restart the discussion and re-worked
> my example a bit. So:
>
> We seem to have a situation where C is in free-fall decline (at least on
> the tiobe index).
>
> But if we can do more to support C programmers moving over to C++ it would
> be a win for both camps.
> C++ users could use certain performance tuning in this area regardless
> because we use C.
>
> To quote r very own mr smith:
>
> "The fact that you can't resize a string or vector without initializing
> its elements is a measurable and significant performance problem for some
> applications; I have seen people invent their own string type or do truly
> horrible things to std::string (directly poking at its internals) to
> circumvent that."
>
> So what can we do to stop this?
>
>
> I have seen a lot of code like this that I'd like to not write/fix/use:
>
> char* do_something_for_c_library()
> {
>  std::string s;
>  s.resize(n+1); // We don't want zero fill here.
> // SomeCAPI takes a pointer an a length and returns the actual length it
> filled.
>  auto len = SomeCAPI(s.data(), n); /* Win32 I'm looking at you. */
>  s.resize(len)
>
>  s += "hello";
>
>  char* ptr = malloc(s.length()+1);
>  if (!ptr)
>   return nullptr;
>
>  strcpy(ptr, s.data());
>
>  return ptr;
> }
>
>
> There are various reasons people use string like this (but vector also).
> These are:
> 1. They just intend to return a string eventually but need data from a C
> like API. Fill can be expensive.
> 2. They need some RAII thing so if there's an exception the destructor
> will release the memory.
> 3. They could use unique_ptr but they want to do some string'y things
> first.
> 4. They want string for the small buffer optimization.
> 5. They sometimes need to return the buffer to C.
>
> It doesn't seem like a big deal, but this is often in performance critical
> code. The sizes aren't always trivial.
> So why can't we make this easier and more efficient?
>
>
> To get this discussion started, how about:
>
> char* do_something_for_c_library()
> {
>  std::string s;
>
>  auto len = SomeCAPI(s.uinitialized_data_at(0, n+1), n);
>  s.resize(len);
>
>  s+="hello";
>  return s.detach_and_string_terminate(); // And provide basic detach also.
> }
>
> s.uinitialized_data_at does this:
> Ensures that a range of elements starting at 0 for length n exists.
> and if it doesn't it extends it without initialization.
> The starting position should exist or it's an error unless it is 0 and the
> string is empty.
> if it can't allocate or the offset or length is bad the it throws a
> std::logic_error(); explaining the problem.
>
>
> I don't see why we can't provide this same API for vector.
> detach_and_string_terminate() could just be enable_if'd only types of
> char/wchar_t/unsigned char/char32_t/char16_t.
>
>
> unintialized_data_at() could just be enabled for these types too for now
> if that helps safety.
> I think this would:
> 1. Increase performance as it enables a lot less pointless initializing of
> data that will only be overwritten.
> 2. Increase performance because it enables a lot of less excess
> allocations in many cases.
> 3. Reduce code size because the library is doing the work.
> 4. Improve safety because the library is doing the safety checking for the
> main fail points that users often don't check.
> It has to do some checking anyway because it may be re-allocating.
> 5. Help C programmers and C++ programmers who have to use or enable C
> api's.
>
> We could provide data_at() too. These can be free functions perhaps.
> I would like an API to request allocation of an exact buffer size too but
> that doesn't have to be these API's.
>
> The detach api proposal can be separate from the data_at idea.
> I don't think this idea needs to wait for some perfect language extensions.
>
> Questions:
> Why not basically this?
>

Several reasons.

First, `basic_string` is intended to be able to have small string
optimization (SSO). This means that strings below a certain size are stored
internally rather than allocating memory. Thus, your "detach" function
doesn't "detach" something in all cases.

Second, `basic_string` and `vector` both allocate memory based on provided
allocators. So... how will the user destroy it? They cannot call `delete[]`
on it, since it was not allocated with `new[]`. The only way to destroy
this object us to use the same allocator that was used to allocate it, or a
compatible one. Not only that, the person receiving the pointer has no idea
how many objects are in the array, so unless `T` has a trivial destructor,
you need to know how many items to destroy. And you need to remember to
destroy them in *reverse* order.

Third, your APIs are really bad. Inserting default-initialized objects
shouldn't use radically different APIs from inserting value-initialized
objects. Your API also assumes that `T` is a type which can tolerate being
uninitialized. We shouldn't make APIs that break the C++ object model; we
should make them that actually work with that model.

The goal is this:

T *t = new T[256];
vector<T> tv(256, ...);

Both of these arrays should perform the same amount of initializing of
their respective arrays. If `T` is trivially default constructible, then
both of these will be uninitialized.  If `T` has a non-trivial default
constructor, then it will be called 256 times in both cases. Because by the
rules of C++, that's what `T` requires in order to be a live object.

The goal should *not* be to have `vector/string` emulate
`malloc`/casting/etc. If you want to violate the C++ object model, that's
your business, but we shouldn't have standard library types let you do that.

Do we really need to wait 3 years for ALL of this?
>

Yes. Be glad it's just 3 years.


> But is providing the minimum to support a minimum of the
> uninitialized_data_at routine so hard that we need to wait?
>

You cannot get something into the standard right now just because you
really want it. C++17 was feature-complete *months ago*. The ship has
sailed; it's not coming back into port.

The next ship launches in 3 years. Get ready for it.

If there's something better. What is it?
>

Well, there's what I already suggested.

I also spent a little time thinking about a memory detachment API for
vector, one that would actually recognize things like the fact that
allocators exist ;) Since then, we've had the introduction of `map`/`set`
extract/merge functions, and we see an alternate way to handle transfer of
such objects.

The design of such an API should mirror them, not deal in direct pointers
to something. Also, such a design should include the ability to hand the
system existing memory (and an allocator for deleting it), which can then
be transferred into a `vector`/`string`.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/07f6e085-f75b-41f0-b42d-8a2704dbdb9a%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Monday, January 9, 2017 at 7:48:48 PM UTC-5, gm=
is...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>string/vector extensions for C interop</div><div><br></div><d=
iv>I&#39;ve started this thread so the original thread it came=C2=A0doesn&#=
39;t continue to get=C2=A0re-directed.</div><div>I&#39;ve taken some commen=
ts from that to restart the discussion and re-worked my example a bit. So:<=
/div><div><br>We seem to have a situation where C is in free-fall decline (=
at least on the tiobe index).</div><p>But if we can do more to support C pr=
ogrammers moving over to C++ it would be a win for both camps.</p><div>C++ =
users=C2=A0could use certain performance tuning in this area regardless bec=
ause we use C.</div><div><br>To quote r very own mr smith:</div><p>&quot;Th=
e fact that you can&#39;t resize a string or vector without initializing it=
s elements is a measurable and significant performance problem for some app=
lications; I have seen people invent their own string type or do truly horr=
ible things to std::string (directly poking at its internals) to circumvent=
 that.&quot;</p><div><br></div><div>So what can we do to stop this?</div><p=
><br>I have seen a lot of code like this that I&#39;d like to not write/fix=
/use:</p><div><br>char* do_something_for_c_library()<br>{<br>=C2=A0std::str=
ing s;<br>=C2=A0s.resize(n+1); // We don&#39;t want zero fill here.</div><d=
iv>// SomeCAPI takes a pointer an a length and returns the actual length it=
 filled.<br>=C2=A0auto len =3D SomeCAPI(s.data(), n); /* Win32 I&#39;m look=
ing at you. */<br>=C2=A0s.resize(len)</div><p>=C2=A0s +=3D &quot;hello&quot=
;;</p><p>=C2=A0char* ptr =3D malloc(s.length()+1);<br>=C2=A0if (!ptr)<br>=
=C2=A0=C2=A0return nullptr;</p><p>=C2=A0strcpy(ptr, s.data());<br></p><p>=
=C2=A0return ptr;<br>}</p><p><br>There are various reasons people use strin=
g like this (but vector also). These are:<br>1. They just intend to return =
a string eventually but need data from a C like API.=C2=A0Fill can be expen=
sive.<br>2. They=C2=A0need some RAII thing so if there&#39;s an exception t=
he destructor will release the memory.<br>3. They could use unique_ptr but =
they want to do some string&#39;y things first.<br>4. They want string for=
=C2=A0the small buffer optimization.<br>5. They sometimes need to return th=
e buffer to C.</p><div><br></div><div>It doesn&#39;t seem like a big deal, =
but this is often in performance critical code. The sizes aren&#39;t always=
 trivial.</div><div>So why can&#39;t we make this easier and more efficient=
?</div><div><br></div><div><br></div><div>To get this discussion started,=
=C2=A0how about:</div><div><br></div><p>char* do_something_for_c_library()<=
br>{<br>=C2=A0std::string s;</p><p>=C2=A0auto len =3D SomeCAPI(s.uinitializ=
ed_data_<wbr>at(0, n+1), n);<br>=C2=A0s.resize(len);</p><p>=C2=A0s+=3D&quot=
;hello&quot;;<br>=C2=A0return s.detach_and_string_terminate(<wbr>); // And =
provide basic detach also.<br>}</p><p>s.uinitialized_data_at does this:<br>=
Ensures that a range of elements starting at 0 for length n exists.<br>and =
if it doesn&#39;t it extends it without initialization.<br>The starting pos=
ition should exist or it&#39;s an error unless it is 0 and the string is em=
pty.<br>if it can&#39;t allocate or the offset or length is bad the it thro=
ws a std::logic_error(); explaining the problem.</p><p><br>I don&#39;t see =
why we can&#39;t provide this same API for vector.<br>detach_and_string_ter=
minate() could just be enable_if&#39;d only types of char/wchar_t/unsigned =
char/char32_t/char16_t.</p><p><br>unintialized_data_at() could just be enab=
led for these types too for now if that helps safety.</p><div>I think this =
would:<br>1. Increase performance as it enables a lot less pointless initia=
lizing of data that will only be overwritten.<br>2. Increase performance be=
cause it enables a lot of less excess allocations in many cases.<br>3. Redu=
ce code size because the library is doing the work.</div><div>4. Improve sa=
fety because the library is doing the safety checking for the main fail poi=
nts that users often don&#39;t check.</div><div>It has to do some checking =
anyway=C2=A0because it may be re-allocating.<br>5. Help C programmers and C=
++ programmers who have to use or enable C api&#39;s.</div><div><br></div><=
div>We could provide data_at() too. These can be free functions perhaps.</d=
iv><div>I would like an API to request allocation of an exact buffer size t=
oo but that doesn&#39;t have to be these API&#39;s.</div><div><br></div><di=
v>The detach api proposal can be separate from the data_at idea.</div><div>=
I don&#39;t think this idea needs to wait for some perfect language extensi=
ons.</div><div><br></div><div>Questions:</div><div>Why not basically this?<=
/div></div></blockquote><div><br>Several reasons.<br><br>First, `basic_stri=
ng` is intended to be able to have small string optimization (SSO). This me=
ans that strings below a certain size are stored internally rather than all=
ocating memory. Thus, your &quot;detach&quot; function doesn&#39;t &quot;de=
tach&quot; something in all cases.<br><br>Second, `basic_string` and `vecto=
r` both allocate memory based on provided allocators. So... how will the us=
er destroy it? They cannot call `delete[]` on it, since it was not allocate=
d with `new[]`. The only way to destroy this object us to use the same allo=
cator that was used to allocate it, or a compatible one. Not only that, the=
 person receiving the pointer has no idea how many objects are in the array=
, so unless `T` has a trivial destructor, you need to know how many items t=
o destroy. And you need to remember to destroy them in <i>reverse</i> order=
..<br><br>Third, your APIs are really bad. Inserting default-initialized obj=
ects shouldn&#39;t use radically different APIs from inserting value-initia=
lized objects. Your API also assumes that `T` is a type which can tolerate =
being uninitialized. We shouldn&#39;t make APIs that break the C++ object m=
odel; we should make them that actually work with that model.<br><br>The go=
al is this:<br><br><div style=3D"background-color: rgb(250, 250, 250); bord=
er-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; overf=
low-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by=
-prettify">T </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify">t </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">new</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">[</span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">256</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">];</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>vector</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> tv</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">256</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">...);</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span></div></code></div><br>Both of these arrays s=
hould perform the same amount of initializing of their respective arrays. I=
f `T` is trivially default constructible, then both of these will be uninit=
ialized.=C2=A0 If `T` has a non-trivial default constructor, then it will b=
e called 256 times in both cases. Because by the rules of C++, that&#39;s w=
hat `T` requires in order to be a live object.<br><br>The goal should <i>no=
t</i> be to have `vector/string` emulate `malloc`/casting/etc. If you want =
to violate the C++ object model, that&#39;s your business, but we shouldn&#=
39;t have standard library types let you do that.<br><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Do we really need to=
 wait 3 years for ALL of this?</div></div></blockquote><div><br>Yes. Be gla=
d it&#39;s just 3 years.<br>=C2=A0<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div><div>But is=C2=A0providing=C2=A0the min=
imum to support a minimum of the uninitialized_data_at=C2=A0routine=C2=A0<w=
br>so hard that we need to wait?</div></div></div></blockquote><div><br>You=
 cannot get something into the standard right now just because you really w=
ant it. C++17 was feature-complete <i>months ago</i>. The ship has sailed; =
it&#39;s not coming back into port.<br><br>The next ship launches in 3 year=
s. Get ready for it.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div>If there&#39;s something better. What is it?<br=
></div></div></blockquote><div><br>Well, there&#39;s what I already suggest=
ed.<br><br>I also spent a little time thinking about a memory detachment AP=
I for vector, one that would actually recognize things like the fact that a=
llocators exist ;) Since then, we&#39;ve had the introduction of `map`/`set=
` extract/merge functions, and we see an alternate way to handle transfer o=
f such objects.<br><br>The design of such an API should mirror them, not de=
al in direct pointers to something. Also, such a design should include the =
ability to hand the system existing memory (and an allocator for deleting i=
t), which can then be transferred into a `vector`/`string`.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/07f6e085-f75b-41f0-b42d-8a2704dbdb9a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/07f6e085-f75b-41f0-b42d-8a2704dbdb9a=
%40isocpp.org</a>.<br />

------=_Part_1323_478382746.1484012154749--

------=_Part_1322_1747381655.1484012154749--

.

------=_Part_265_946104966.1484013459305
Content-Type: multipart/alternative;
 boundary="----=_Part_266_1565478909.1484013459305"

------=_Part_266_1565478909.1484013459305
Content-Type: text/plain; charset=UTF-8


>
>
>>
> Several reasons.
>
> First, `basic_string` is intended to be able to have small string
> optimization (SSO). This means that strings below a certain size are stored
> internally rather than allocating memory. Thus, your "detach" function
> doesn't "detach" something in all cases.
>

That's not a reason for doing nothing. That's just a description of how
things are that doesn't forward anything. I don't know why so many replies
are structured like this.

Detach could allocate and copy if it must. If that fails it returns
nullptr. Or uninitialized_data_at can do the allocate copy if directed,
that can fail anyway so that seems the fine place to do that. We can
indicate that in a parameter etc.
There are ways forward here.



> Second, `basic_string` and `vector` both allocate memory based on provided
> allocators. So... how will the user destroy it? They cannot call `delete[]`
> on it, since it was not allocated with `new[]`. The only way to destroy
> this object us to use the same allocator that was used to allocate it, or a
> compatible one. Not only that, the person receiving the pointer has no idea
> how many objects are in the array, so unless `T` has a trivial destructor,
> you need to know how many items to destroy. And you need to remember to
> destroy them in *reverse* order.
>
> Third, your APIs are really bad. Inserting default-initialized objects
> shouldn't use radically different APIs from inserting value-initialized
> objects. Your API also assumes that `T` is a type which can tolerate being
> uninitialized. We shouldn't make APIs that break the C++ object model; we
> should make them that actually work with that model.
>

I said we could enable_if that and that these could be free. You seem to be
ignoring that fact or didn't see it. I don't see a problem with the idea.

And C++ already has plenty of 'get outs' for doing what needs to be done if
it needs to be done. We should make API's that enable us to do what we need
to do. You don't have to call them if you don't need what it offers. So I
don't buy your argument.


> The goal is this:
>
> T *t = new T[256];
> vector<T> tv(256, ...);
>
> Both of these arrays should perform the same amount of initializing of
> their respective arrays. If `T` is trivially default constructible, then
> both of these will be uninitialized.  If `T` has a non-trivial default
> constructor, then it will be called 256 times in both cases. Because by the
> rules of C++, that's what `T` requires in order to be a live object.
>

That's great but why does my suggestion break that or hinder that. So why
do we have to wait for that?
Is there any guarantee we will even get that?


>
> The goal should *not* be to have `vector/string` emulate
> `malloc`/casting/etc. If you want to violate the C++ object model, that's
> your business, but we shouldn't have standard library types let you do that.
>
> Do we really need to wait 3 years for ALL of this?
>>
>
> Yes. Be glad it's just 3 years.
>

I can wait if I must. I was asking if I must, but if so, so be it. But I've
yet to see why this is so hard.


>
>
>> But is providing the minimum to support a minimum of the
>> uninitialized_data_at routine so hard that we need to wait?
>>
>
> You cannot get something into the standard right now just because you
> really want it. C++17 was feature-complete *months ago*. The ship has
> sailed; it's not coming back into port.
>
> The next ship launches in 3 years. Get ready for it.
>

Well I posted this to get ready for it, if not before it. :)


>
> If there's something better. What is it?
>>
>
> Well, there's what I already suggested.
>
> I also spent a little time thinking about a memory detachment API for
> vector, one that would actually recognize things like the fact that
> allocators exist ;) Since then, we've had the introduction of `map`/`set`
> extract/merge functions, and we see an alternate way to handle transfer of
> such objects.
>
> The design of such an API should mirror them, not deal in direct pointers
> to something. Also, such a design should include the ability to hand the
> system existing memory (and an allocator for deleting it), which can then
> be transferred into a `vector`/`string`.
>

I don't see how you can avoid dealing with a pointer when you (I) want to
be able to return a pointer to C here.
But that doesn't preclude options for other situations.

I hope your larger proposal proceeds. I think this part of it can be worked
out independent of that though at least interface wise and especially so in
case the larger proposal doesn't make it through. We need something here
and this is a partner or a fall back.

Thanks

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9d65b478-cfc9-4d38-903f-d83d37b03116%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><blockquote =
class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex=
; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-lef=
t-style: solid;"><div dir=3D"ltr"><div><br></div></div></blockquote><div><b=
r>Several reasons.<br><br>First, `basic_string` is intended to be able to h=
ave small string optimization (SSO). This means that strings below a certai=
n size are stored internally rather than allocating memory. Thus, your &quo=
t;detach&quot; function doesn&#39;t &quot;detach&quot; something in all cas=
es.<br></div></div></blockquote><div><br></div><div>That&#39;s not a reason=
 for doing nothing. That&#39;s just a description of how things are that do=
esn&#39;t forward anything. I don&#39;t know why so many replies are struct=
ured like this.</div><div><br></div><div>Detach could allocate and copy if =
it must. If that fails it returns nullptr. Or=C2=A0uninitialized_data_at ca=
n do the allocate copy if directed, that can fail anyway so that seems the =
fine place to do that. We can indicate that in a parameter etc.</div><div>T=
here are ways forward here.</div><div><br></div><div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex=
; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-lef=
t-style: solid;"><div dir=3D"ltr"><div><br>Second, `basic_string` and `vect=
or` both allocate memory based on provided allocators. So... how will the u=
ser destroy it? They cannot call `delete[]` on it, since it was not allocat=
ed with `new[]`. The only way to destroy this object us to use the same all=
ocator that was used to allocate it, or a compatible one. Not only that, th=
e person receiving the pointer has no idea how many objects are in the arra=
y, so unless `T` has a trivial destructor, you need to know how many items =
to destroy. And you need to remember to destroy them in <i>reverse</i> orde=
r.<br><br>Third, your APIs are really bad. Inserting default-initialized ob=
jects shouldn&#39;t use radically different APIs from inserting value-initi=
alized objects. Your API also assumes that `T` is a type which can tolerate=
 being uninitialized. We shouldn&#39;t make APIs that break the C++ object =
model; we should make them that actually work with that model.<br></div></d=
iv></blockquote><div><br></div><div>I said we could enable_if that and that=
 these could be free. You seem to be ignoring that fact or didn&#39;t=C2=A0=
see it. I don&#39;t see a problem with the idea.</div><div><br></div><div>A=
nd C++ already has plenty of &#39;get outs&#39; for doing what needs to be =
done if it needs to be done. We should make API&#39;s that enable us to do =
what we need to do. You don&#39;t have to call them if you don&#39;t need w=
hat it offers. So I don&#39;t buy your argument.</div><div><br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-lef=
t: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bord=
er-left-style: solid;"><div dir=3D"ltr"><div><br>The goal is this:<br><br><=
div style=3D"border: 1px solid rgb(187, 187, 187); border-image: none; back=
ground-color: rgb(250, 250, 250);"><code><div><span style=3D"color: rgb(0, =
0, 0);">T </span><span style=3D"color: rgb(102, 102, 0);">*</span><span sty=
le=3D"color: rgb(0, 0, 0);">t </span><span style=3D"color: rgb(102, 102, 0)=
;">=3D</span><span style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"co=
lor: rgb(0, 0, 136);">new</span><span style=3D"color: rgb(0, 0, 0);"> T</sp=
an><span style=3D"color: rgb(102, 102, 0);">[</span><span style=3D"color: r=
gb(0, 102, 102);">256</span><span style=3D"color: rgb(102, 102, 0);">];</sp=
an><span style=3D"color: rgb(0, 0, 0);"><br>vector</span><span style=3D"col=
or: rgb(102, 102, 0);">&lt;</span><span style=3D"color: rgb(0, 0, 0);">T</s=
pan><span style=3D"color: rgb(102, 102, 0);">&gt;</span><span style=3D"colo=
r: rgb(0, 0, 0);"> tv</span><span style=3D"color: rgb(102, 102, 0);">(</spa=
n><span style=3D"color: rgb(0, 102, 102);">256</span><span style=3D"color: =
rgb(102, 102, 0);">,</span><span style=3D"color: rgb(0, 0, 0);"> </span><sp=
an style=3D"color: rgb(102, 102, 0);">...);</span><span style=3D"color: rgb=
(0, 0, 0);"><br></span></div></code></div><br>Both of these arrays should p=
erform the same amount of initializing of their respective arrays. If `T` i=
s trivially default constructible, then both of these will be uninitialized=
..=C2=A0 If `T` has a non-trivial default constructor, then it will be calle=
d 256 times in both cases. Because by the rules of C++, that&#39;s what `T`=
 requires in order to be a live object.<br></div></div></blockquote><div><b=
r></div><div>That&#39;s great but why does my suggestion break that=C2=A0or=
 hinder that. So why do we have to wait for that?</div><div>Is there any gu=
arantee we will even get that?</div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-l=
eft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: s=
olid;"><div dir=3D"ltr"><div><br>The goal should <i>not</i> be to have `vec=
tor/string` emulate `malloc`/casting/etc. If you want to violate the C++ ob=
ject model, that&#39;s your business, but we shouldn&#39;t have standard li=
brary types let you do that.<br><br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: =
rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div=
 dir=3D"ltr"><div>Do we really need to wait 3 years for ALL of this?</div><=
/div></blockquote><div><br>Yes. Be glad it&#39;s just 3 years.<br></div></d=
iv></blockquote><div><br></div><div>I can wait if I must. I was asking if I=
 must, but if so, so be it. But I&#39;ve yet to see why this is so hard.</d=
iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px =
0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bo=
rder-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>=C2=
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px=
 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-le=
ft-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><div>But is=
=C2=A0providing=C2=A0the minimum to support a minimum of the uninitialized_=
data_at=C2=A0routine=C2=A0<wbr>so hard that we need to wait?</div></div></d=
iv></blockquote><div><br>You cannot get something into the standard right n=
ow just because you really want it. C++17 was feature-complete <i>months ag=
o</i>. The ship has sailed; it&#39;s not coming back into port.<br><br>The =
next ship launches in 3 years. Get ready for it.<br></div></div></blockquot=
e><div><br></div><div>Well I posted=C2=A0this to get ready for it, if=C2=A0=
not before it.=C2=A0:)</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-colo=
r: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><=
div dir=3D"ltr"><div><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 20=
4, 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr=
"><div>If there&#39;s something better. What is it?<br></div></div></blockq=
uote><div><br>Well, there&#39;s what I already suggested.<br><br>I also spe=
nt a little time thinking about a memory detachment API for vector, one tha=
t would actually recognize things like the fact that allocators exist ;) Si=
nce then, we&#39;ve had the introduction of `map`/`set` extract/merge funct=
ions, and we see an alternate way to handle transfer of such objects.<br><b=
r>The design of such an API should mirror them, not deal in direct pointers=
 to something. Also, such a design should include the ability to hand the s=
ystem existing memory (and an allocator for deleting it), which can then be=
 transferred into a `vector`/`string`.<br></div></div></blockquote><div><br=
></div><div>I don&#39;t see how you can avoid=C2=A0dealing with a pointer w=
hen you (I) want to be able to return a pointer to C here.</div><div>But th=
at doesn&#39;t preclude options for other situations.</div><div><br></div><=
div>I hope your larger proposal proceeds. I think this part of it can be wo=
rked out independent of that though at least interface wise and especially =
so in case the larger proposal doesn&#39;t make it through. We need=C2=A0so=
mething here and this is a partner or a fall back.</div><div><br></div><div=
>Thanks</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9d65b478-cfc9-4d38-903f-d83d37b03116%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9d65b478-cfc9-4d38-903f-d83d37b03116=
%40isocpp.org</a>.<br />

------=_Part_266_1565478909.1484013459305--

------=_Part_265_946104966.1484013459305--

.

--001a1146fba252a7000545b3e278
Content-Type: text/plain; charset=UTF-8

On 9 January 2017 at 17:35, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Monday, January 9, 2017 at 7:48:48 PM UTC-5, gmis...@gmail.com wrote:
>>
>> string/vector extensions for C interop
>>
>> I've started this thread so the original thread it came doesn't continue
>> to get re-directed.
>> I've taken some comments from that to restart the discussion and
>> re-worked my example a bit. So:
>>
>> We seem to have a situation where C is in free-fall decline (at least on
>> the tiobe index).
>>
>> But if we can do more to support C programmers moving over to C++ it
>> would be a win for both camps.
>> C++ users could use certain performance tuning in this area regardless
>> because we use C.
>>
>> To quote r very own mr smith:
>>
>> "The fact that you can't resize a string or vector without initializing
>> its elements is a measurable and significant performance problem for some
>> applications; I have seen people invent their own string type or do truly
>> horrible things to std::string (directly poking at its internals) to
>> circumvent that."
>>
>> So what can we do to stop this?
>>
>>
>> I have seen a lot of code like this that I'd like to not write/fix/use:
>>
>> char* do_something_for_c_library()
>> {
>>  std::string s;
>>  s.resize(n+1); // We don't want zero fill here.
>> // SomeCAPI takes a pointer an a length and returns the actual length it
>> filled.
>>  auto len = SomeCAPI(s.data(), n); /* Win32 I'm looking at you. */
>>  s.resize(len)
>>
>>  s += "hello";
>>
>>  char* ptr = malloc(s.length()+1);
>>  if (!ptr)
>>   return nullptr;
>>
>>  strcpy(ptr, s.data());
>>
>>  return ptr;
>> }
>>
>>
>> There are various reasons people use string like this (but vector also).
>> These are:
>> 1. They just intend to return a string eventually but need data from a C
>> like API. Fill can be expensive.
>> 2. They need some RAII thing so if there's an exception the destructor
>> will release the memory.
>> 3. They could use unique_ptr but they want to do some string'y things
>> first.
>> 4. They want string for the small buffer optimization.
>> 5. They sometimes need to return the buffer to C.
>>
>> It doesn't seem like a big deal, but this is often in performance
>> critical code. The sizes aren't always trivial.
>> So why can't we make this easier and more efficient?
>>
>>
>> To get this discussion started, how about:
>>
>> char* do_something_for_c_library()
>> {
>>  std::string s;
>>
>>  auto len = SomeCAPI(s.uinitialized_data_at(0, n+1), n);
>>  s.resize(len);
>>
>>  s+="hello";
>>  return s.detach_and_string_terminate(); // And provide basic detach
>> also.
>> }
>>
>> s.uinitialized_data_at does this:
>> Ensures that a range of elements starting at 0 for length n exists.
>> and if it doesn't it extends it without initialization.
>> The starting position should exist or it's an error unless it is 0 and
>> the string is empty.
>> if it can't allocate or the offset or length is bad the it throws a
>> std::logic_error(); explaining the problem.
>>
>>
>> I don't see why we can't provide this same API for vector.
>> detach_and_string_terminate() could just be enable_if'd only types of
>> char/wchar_t/unsigned char/char32_t/char16_t.
>>
>>
>> unintialized_data_at() could just be enabled for these types too for now
>> if that helps safety.
>> I think this would:
>> 1. Increase performance as it enables a lot less pointless initializing
>> of data that will only be overwritten.
>> 2. Increase performance because it enables a lot of less excess
>> allocations in many cases.
>> 3. Reduce code size because the library is doing the work.
>> 4. Improve safety because the library is doing the safety checking for
>> the main fail points that users often don't check.
>> It has to do some checking anyway because it may be re-allocating.
>> 5. Help C programmers and C++ programmers who have to use or enable C
>> api's.
>>
>> We could provide data_at() too. These can be free functions perhaps.
>> I would like an API to request allocation of an exact buffer size too but
>> that doesn't have to be these API's.
>>
>> The detach api proposal can be separate from the data_at idea.
>> I don't think this idea needs to wait for some perfect language
>> extensions.
>>
>> Questions:
>> Why not basically this?
>>
>
> Several reasons.
>
> First, `basic_string` is intended to be able to have small string
> optimization (SSO). This means that strings below a certain size are stored
> internally rather than allocating memory. Thus, your "detach" function
> doesn't "detach" something in all cases.
>
> Second, `basic_string` and `vector` both allocate memory based on provided
> allocators. So... how will the user destroy it? They cannot call `delete[]`
> on it, since it was not allocated with `new[]`. The only way to destroy
> this object us to use the same allocator that was used to allocate it, or a
> compatible one. Not only that, the person receiving the pointer has no idea
> how many objects are in the array, so unless `T` has a trivial destructor,
> you need to know how many items to destroy. And you need to remember to
> destroy them in *reverse* order.
>
> Third, your APIs are really bad. Inserting default-initialized objects
> shouldn't use radically different APIs from inserting value-initialized
> objects. Your API also assumes that `T` is a type which can tolerate being
> uninitialized. We shouldn't make APIs that break the C++ object model; we
> should make them that actually work with that model.
>
> The goal is this:
>
> T *t = new T[256];
> vector<T> tv(256, ...);
>
> Both of these arrays should perform the same amount of initializing of
> their respective arrays. If `T` is trivially default constructible, then
> both of these will be uninitialized.  If `T` has a non-trivial default
> constructor, then it will be called 256 times in both cases. Because by the
> rules of C++, that's what `T` requires in order to be a live object.
>

If you only provide that, you have not solved the complete problem.
Sometimes the requirements do include the ability to directly construct a
sequence of T objects in place within a vector, in ways that emplace does
not support.

One (slightly scary) approach would be:
1) permit the user to construct objects in trailing storage of a
vector/string, so long as capacity is large enough, and
2) provide a resize_already_initialized(size_t) member to resize the
container so that those elements are part of its size, without constructing
new Ts over the top of them

Obviously if (1) somehow fails or throws, destroying the elements it
created is its problem, and triggering reallocation during (1) would be bad.

The goal should *not* be to have `vector/string` emulate
> `malloc`/casting/etc. If you want to violate the C++ object model, that's
> your business, but we shouldn't have standard library types let you do that.
>
> Do we really need to wait 3 years for ALL of this?
>>
>
> Yes. Be glad it's just 3 years.
>
>
>> But is providing the minimum to support a minimum of the
>> uninitialized_data_at routine so hard that we need to wait?
>>
>
> You cannot get something into the standard right now just because you
> really want it. C++17 was feature-complete *months ago*. The ship has
> sailed; it's not coming back into port.
>
> The next ship launches in 3 years. Get ready for it.
>
> If there's something better. What is it?
>>
>
> Well, there's what I already suggested.
>
> I also spent a little time thinking about a memory detachment API for
> vector, one that would actually recognize things like the fact that
> allocators exist ;) Since then, we've had the introduction of `map`/`set`
> extract/merge functions, and we see an alternate way to handle transfer of
> such objects.
>
> The design of such an API should mirror them, not deal in direct pointers
> to something. Also, such a design should include the ability to hand the
> system existing memory (and an allocator for deleting it), which can then
> be transferred into a `vector`/`string`.
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/07f6e085-f75b-41f0-
> b42d-8a2704dbdb9a%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/07f6e085-f75b-41f0-b42d-8a2704dbdb9a%40isocpp.org?utm_medium=email&utm_source=footer>
> .

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqm769SZc2grUuWy1AvPc%3DZDz1yyHQKh3KaMDVQi19a8RQ%40mail.gmail.com.

--001a1146fba252a7000545b3e278
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 9=
 January 2017 at 17:35, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto=
:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=
=3D"h5">On Monday, January 9, 2017 at 7:48:48 PM UTC-5, <a href=3D"mailto:g=
mis...@gmail.com" target=3D"_blank">gmis...@gmail.com</a> wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>string/vector extensions=
 for C interop</div><div><br></div><div>I&#39;ve started this thread so the=
 original thread it came=C2=A0doesn&#39;t continue to get=C2=A0re-directed.=
</div><div>I&#39;ve taken some comments from that to restart the discussion=
 and re-worked my example a bit. So:</div><div><br>We seem to have a situat=
ion where C is in free-fall decline (at least on the tiobe index).</div><p>=
But if we can do more to support C programmers moving over to C++ it would =
be a win for both camps.</p><div>C++ users=C2=A0could use certain performan=
ce tuning in this area regardless because we use C.</div><div><br>To quote =
r very own mr smith:</div><p>&quot;The fact that you can&#39;t resize a str=
ing or vector without initializing its elements is a measurable and signifi=
cant performance problem for some applications; I have seen people invent t=
heir own string type or do truly horrible things to std::string (directly p=
oking at its internals) to circumvent that.&quot;</p><div><br></div><div>So=
 what can we do to stop this?</div><p><br>I have seen a lot of code like th=
is that I&#39;d like to not write/fix/use:</p><div><br>char* do_something_f=
or_c_library()<br>{<br>=C2=A0std::string s;<br>=C2=A0s.resize(n+1); // We d=
on&#39;t want zero fill here.</div><div>// SomeCAPI takes a pointer an a le=
ngth and returns the actual length it filled.<br>=C2=A0auto len =3D SomeCAP=
I(s.data(), n); /* Win32 I&#39;m looking at you. */<br>=C2=A0s.resize(len)<=
/div><p>=C2=A0s +=3D &quot;hello&quot;;</p><p>=C2=A0char* ptr =3D malloc(s.=
length()+1);<br>=C2=A0if (!ptr)<br>=C2=A0=C2=A0return nullptr;</p><p>=C2=A0=
strcpy(ptr, s.data());<br></p><p>=C2=A0return ptr;<br>}</p><p><br>There are=
 various reasons people use string like this (but vector also). These are:<=
br>1. They just intend to return a string eventually but need data from a C=
 like API.=C2=A0Fill can be expensive.<br>2. They=C2=A0need some RAII thing=
 so if there&#39;s an exception the destructor will release the memory.<br>=
3. They could use unique_ptr but they want to do some string&#39;y things f=
irst.<br>4. They want string for=C2=A0the small buffer optimization.<br>5. =
They sometimes need to return the buffer to C.</p><div><br></div><div>It do=
esn&#39;t seem like a big deal, but this is often in performance critical c=
ode. The sizes aren&#39;t always trivial.</div><div>So why can&#39;t we mak=
e this easier and more efficient?</div><div><br></div><div><br></div><div>T=
o get this discussion started,=C2=A0how about:</div><div><br></div><p>char*=
 do_something_for_c_library()<br>{<br>=C2=A0std::string s;</p><p>=C2=A0auto=
 len =3D SomeCAPI(s.uinitialized_data_a<wbr>t(0, n+1), n);<br>=C2=A0s.resiz=
e(len);</p><p>=C2=A0s+=3D&quot;hello&quot;;<br>=C2=A0return s.detach_and_st=
ring_terminate(<wbr>); // And provide basic detach also.<br>}</p><p>s.uinit=
ialized_data_at does this:<br>Ensures that a range of elements starting at =
0 for length n exists.<br>and if it doesn&#39;t it extends it without initi=
alization.<br>The starting position should exist or it&#39;s an error unles=
s it is 0 and the string is empty.<br>if it can&#39;t allocate or the offse=
t or length is bad the it throws a std::logic_error(); explaining the probl=
em.</p><p><br>I don&#39;t see why we can&#39;t provide this same API for ve=
ctor.<br>detach_and_string_terminate() could just be enable_if&#39;d only t=
ypes of char/wchar_t/unsigned char/char32_t/char16_t.</p><p><br>unintialize=
d_data_at() could just be enabled for these types too for now if that helps=
 safety.</p><div>I think this would:<br>1. Increase performance as it enabl=
es a lot less pointless initializing of data that will only be overwritten.=
<br>2. Increase performance because it enables a lot of less excess allocat=
ions in many cases.<br>3. Reduce code size because the library is doing the=
 work.</div><div>4. Improve safety because the library is doing the safety =
checking for the main fail points that users often don&#39;t check.</div><d=
iv>It has to do some checking anyway=C2=A0because it may be re-allocating.<=
br>5. Help C programmers and C++ programmers who have to use or enable C ap=
i&#39;s.</div><div><br></div><div>We could provide data_at() too. These can=
 be free functions perhaps.</div><div>I would like an API to request alloca=
tion of an exact buffer size too but that doesn&#39;t have to be these API&=
#39;s.</div><div><br></div><div>The detach api proposal can be separate fro=
m the data_at idea.</div><div>I don&#39;t think this idea needs to wait for=
 some perfect language extensions.</div><div><br></div><div>Questions:</div=
><div>Why not basically this?</div></div></blockquote></div></div><div><br>=
Several reasons.<br><br>First, `basic_string` is intended to be able to hav=
e small string optimization (SSO). This means that strings below a certain =
size are stored internally rather than allocating memory. Thus, your &quot;=
detach&quot; function doesn&#39;t &quot;detach&quot; something in all cases=
..<br><br>Second, `basic_string` and `vector` both allocate memory based on =
provided allocators. So... how will the user destroy it? They cannot call `=
delete[]` on it, since it was not allocated with `new[]`. The only way to d=
estroy this object us to use the same allocator that was used to allocate i=
t, or a compatible one. Not only that, the person receiving the pointer has=
 no idea how many objects are in the array, so unless `T` has a trivial des=
tructor, you need to know how many items to destroy. And you need to rememb=
er to destroy them in <i>reverse</i> order.<br><br>Third, your APIs are rea=
lly bad. Inserting default-initialized objects shouldn&#39;t use radically =
different APIs from inserting value-initialized objects. Your API also assu=
mes that `T` is a type which can tolerate being uninitialized. We shouldn&#=
39;t make APIs that break the C++ object model; we should make them that ac=
tually work with that model.<br><br>The goal is this:<br><br><div style=3D"=
background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-styl=
e:solid;border-width:1px" class=3D"m_-1830414781620457218prettyprint"><code=
 class=3D"m_-1830414781620457218prettyprint"><div class=3D"m_-1830414781620=
457218subprettyprint"><span style=3D"color:#000" class=3D"m_-18304147816204=
57218styled-by-prettify">T </span><span style=3D"color:#660" class=3D"m_-18=
30414781620457218styled-by-prettify">*</span><span style=3D"color:#000" cla=
ss=3D"m_-1830414781620457218styled-by-prettify">t </span><span style=3D"col=
or:#660" class=3D"m_-1830414781620457218styled-by-prettify">=3D</span><span=
 style=3D"color:#000" class=3D"m_-1830414781620457218styled-by-prettify"> <=
/span><span style=3D"color:#008" class=3D"m_-1830414781620457218styled-by-p=
rettify">new</span><span style=3D"color:#000" class=3D"m_-18304147816204572=
18styled-by-prettify"> T</span><span style=3D"color:#660" class=3D"m_-18304=
14781620457218styled-by-prettify">[</span><span style=3D"color:#066" class=
=3D"m_-1830414781620457218styled-by-prettify">256</span><span style=3D"colo=
r:#660" class=3D"m_-1830414781620457218styled-by-prettify">];</span><span s=
tyle=3D"color:#000" class=3D"m_-1830414781620457218styled-by-prettify"><br>=
vector</span><span style=3D"color:#660" class=3D"m_-1830414781620457218styl=
ed-by-prettify">&lt;</span><span style=3D"color:#000" class=3D"m_-183041478=
1620457218styled-by-prettify">T</span><span style=3D"color:#660" class=3D"m=
_-1830414781620457218styled-by-prettify">&gt;</span><span style=3D"color:#0=
00" class=3D"m_-1830414781620457218styled-by-prettify"> tv</span><span styl=
e=3D"color:#660" class=3D"m_-1830414781620457218styled-by-prettify">(</span=
><span style=3D"color:#066" class=3D"m_-1830414781620457218styled-by-pretti=
fy">256</span><span style=3D"color:#660" class=3D"m_-1830414781620457218sty=
led-by-prettify">,</span><span style=3D"color:#000" class=3D"m_-18304147816=
20457218styled-by-prettify"> </span><span style=3D"color:#660" class=3D"m_-=
1830414781620457218styled-by-prettify">...);</span><span style=3D"color:#00=
0" class=3D"m_-1830414781620457218styled-by-prettify"><br></span></div></co=
de></div><br>Both of these arrays should perform the same amount of initial=
izing of their respective arrays. If `T` is trivially default constructible=
, then both of these will be uninitialized.=C2=A0 If `T` has a non-trivial =
default constructor, then it will be called 256 times in both cases. Becaus=
e by the rules of C++, that&#39;s what `T` requires in order to be a live o=
bject.<br></div></div></blockquote><div><br></div><div>If you only provide =
that, you have not solved the complete problem. Sometimes the requirements =
do include the ability to directly construct a sequence of T objects in pla=
ce within a vector, in ways that emplace does not support.</div><div><br></=
div><div>One (slightly scary) approach would be:</div><div>1) permit the us=
er to construct objects in trailing storage of a vector/string, so long as =
capacity is large enough, and</div><div>2) provide a resize_already_initial=
ized(size_t) member to resize the container so that those elements are part=
 of its size, without constructing new Ts over the top of them</div><div><b=
r></div><div>Obviously if (1) somehow fails or throws, destroying the eleme=
nts it created is its problem, and triggering reallocation during (1) would=
 be bad.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div>The goal should <i>not</i> be to have `vector/string` emulate `mallo=
c`/casting/etc. If you want to violate the C++ object model, that&#39;s you=
r business, but we shouldn&#39;t have standard library types let you do tha=
t.<br><br></div><span class=3D""><blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div>Do we really need to wait 3 years for ALL of this?</div=
></div></blockquote></span><div><br>Yes. Be glad it&#39;s just 3 years.<br>=
=C2=A0<br></div><span class=3D""><blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div><div>But is=C2=A0providing=C2=A0the minimum to support =
a minimum of the uninitialized_data_at=C2=A0routine=C2=A0<wbr>so hard that =
we need to wait?</div></div></div></blockquote></span><div><br>You cannot g=
et something into the standard right now just because you really want it. C=
++17 was feature-complete <i>months ago</i>. The ship has sailed; it&#39;s =
not coming back into port.<br><br>The next ship launches in 3 years. Get re=
ady for it.<br><br></div><span class=3D""><blockquote class=3D"gmail_quote"=
 style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div>If there&#39;s something better. What is it?<b=
r></div></div></blockquote></span><div><br>Well, there&#39;s what I already=
 suggested.<br><br>I also spent a little time thinking about a memory detac=
hment API for vector, one that would actually recognize things like the fac=
t that allocators exist ;) Since then, we&#39;ve had the introduction of `m=
ap`/`set` extract/merge functions, and we see an alternate way to handle tr=
ansfer of such objects.<br><br>The design of such an API should mirror them=
, not deal in direct pointers to something. Also, such a design should incl=
ude the ability to hand the system existing memory (and an allocator for de=
leting it), which can then be transferred into a `vector`/`string`.<br></di=
v></div><span class=3D"">

<p></p>

-- <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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/07f6e085-f75b-41f0-b42d-8a2704dbdb9a%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/07f6=
e085-f75b-41f0-<wbr>b42d-8a2704dbdb9a%40isocpp.org</a><wbr>.</blockquote></=
div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqm769SZc2grUuWy1AvPc%3DZDz1yyHQ=
Kh3KaMDVQi19a8RQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqm769SZc2=
grUuWy1AvPc%3DZDz1yyHQKh3KaMDVQi19a8RQ%40mail.gmail.com</a>.<br />

--001a1146fba252a7000545b3e278--

.

------=_Part_1370_658322908.1484019546839
Content-Type: multipart/alternative;
 boundary="----=_Part_1371_760844428.1484019546839"

------=_Part_1371_760844428.1484019546839
Content-Type: text/plain; charset=UTF-8

On Monday, January 9, 2017 at 9:03:03 PM UTC-5, Richard Smith wrote:
>
> On 9 January 2017 at 17:35, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
>
>> Several reasons.
>>
>> First, `basic_string` is intended to be able to have small string
>> optimization (SSO). This means that strings below a certain size are stored
>> internally rather than allocating memory. Thus, your "detach" function
>> doesn't "detach" something in all cases.
>>
>> Second, `basic_string` and `vector` both allocate memory based on
>> provided allocators. So... how will the user destroy it? They cannot call
>> `delete[]` on it, since it was not allocated with `new[]`. The only way to
>> destroy this object us to use the same allocator that was used to allocate
>> it, or a compatible one. Not only that, the person receiving the pointer
>> has no idea how many objects are in the array, so unless `T` has a trivial
>> destructor, you need to know how many items to destroy. And you need to
>> remember to destroy them in *reverse* order.
>>
>> Third, your APIs are really bad. Inserting default-initialized objects
>> shouldn't use radically different APIs from inserting value-initialized
>> objects. Your API also assumes that `T` is a type which can tolerate being
>> uninitialized. We shouldn't make APIs that break the C++ object model; we
>> should make them that actually work with that model.
>>
>> The goal is this:
>>
>> T *t = new T[256];
>> vector<T> tv(256, ...);
>>
>> Both of these arrays should perform the same amount of initializing of
>> their respective arrays. If `T` is trivially default constructible, then
>> both of these will be uninitialized.  If `T` has a non-trivial default
>> constructor, then it will be called 256 times in both cases. Because by the
>> rules of C++, that's what `T` requires in order to be a live object.
>>
>
> If you only provide that, you have not solved the complete problem.
> Sometimes the requirements do include the ability to directly construct a
> sequence of T objects in place within a vector, in ways that emplace does
> not support.
>

That is a problem best solved by allowing `emplace` to construct an object
in ways that it does not currently support.

What in particular was a circumstance you were thinking of?

One (slightly scary) approach would be:
> 1) permit the user to construct objects in trailing storage of a
> vector/string, so long as capacity is large enough, and
> 2) provide a resize_already_initialized(size_t) member to resize the
> container so that those elements are part of its size, without constructing
> new Ts over the top of them
>

> Obviously if (1) somehow fails or throws, destroying the elements it
> created is its problem, and triggering reallocation during (1) would be bad.
>

I'm not sure why we should encourage (1) happening outside of the presence
of (2). Or rather, I don't know why it is *necessary* to do it that way.

Can you give an example? One that is actually legal C++ under the current
object model?

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3ef49ad2-3e73-4d58-872d-fab5f138e22b%40isocpp.org.

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

<div dir=3D"ltr">On Monday, January 9, 2017 at 9:03:03 PM UTC-5, Richard Sm=
ith wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v><div class=3D"gmail_quote">On 9 January 2017 at 17:35, Nicol Bolas <span =
dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"63T5z5zGBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;java=
script:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;ret=
urn true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div>Several reasons.<br><br>First, `basic_strin=
g` is intended to be able to have small string optimization (SSO). This mea=
ns that strings below a certain size are stored internally rather than allo=
cating memory. Thus, your &quot;detach&quot; function doesn&#39;t &quot;det=
ach&quot; something in all cases.<br><br>Second, `basic_string` and `vector=
` both allocate memory based on provided allocators. So... how will the use=
r destroy it? They cannot call `delete[]` on it, since it was not allocated=
 with `new[]`. The only way to destroy this object us to use the same alloc=
ator that was used to allocate it, or a compatible one. Not only that, the =
person receiving the pointer has no idea how many objects are in the array,=
 so unless `T` has a trivial destructor, you need to know how many items to=
 destroy. And you need to remember to destroy them in <i>reverse</i> order.=
<br><br>Third, your APIs are really bad. Inserting default-initialized obje=
cts shouldn&#39;t use radically different APIs from inserting value-initial=
ized objects. Your API also assumes that `T` is a type which can tolerate b=
eing uninitialized. We shouldn&#39;t make APIs that break the C++ object mo=
del; we should make them that actually work with that model.<br><br>The goa=
l is this:<br><br><div style=3D"background-color:rgb(250,250,250);border-co=
lor:rgb(187,187,187);border-style:solid;border-width:1px"><code><div><span =
style=3D"color:#000">T </span><span style=3D"color:#660">*</span><span styl=
e=3D"color:#000">t </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">new</span><span style=3D=
"color:#000"> T</span><span style=3D"color:#660">[</span><span style=3D"col=
or:#066">256</span><span style=3D"color:#660">];</span><span style=3D"color=
:#000"><br>vector</span><span style=3D"color:#660">&lt;</span><span style=
=3D"color:#000">T</span><span style=3D"color:#660">&gt;</span><span style=
=3D"color:#000"> tv</span><span style=3D"color:#660">(</span><span style=3D=
"color:#066">256</span><span style=3D"color:#660">,</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#660">...);</span><span style=3D"col=
or:#000"><br></span></div></code></div><br>Both of these arrays should perf=
orm the same amount of initializing of their respective arrays. If `T` is t=
rivially default constructible, then both of these will be uninitialized.=
=C2=A0 If `T` has a non-trivial default constructor, then it will be called=
 256 times in both cases. Because by the rules of C++, that&#39;s what `T` =
requires in order to be a live object.<br></div></div></blockquote><div><br=
></div><div>If you only provide that, you have not solved the complete prob=
lem. Sometimes the requirements do include the ability to directly construc=
t a sequence of T objects in place within a vector, in ways that emplace do=
es not support.</div></div></div></div></blockquote><div><br>That is a prob=
lem best solved by allowing `emplace` to construct an object in ways that i=
t does not currently support.<br><br>What in particular was a circumstance =
you were thinking of?<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>One (slightly s=
cary) approach would be:</div><div>1) permit the user to construct objects =
in trailing storage of a vector/string, so long as capacity is large enough=
, and</div><div>2) provide a resize_already_initialized(<wbr>size_t) member=
 to resize the container so that those elements are part of its size, witho=
ut constructing new Ts over the top of them</div></div></div></div></blockq=
uote><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; =
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><br></d=
iv></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div><div class=3D"gmail_quote"><div></div><div>Obviously if (1) somehow=
 fails or throws, destroying the elements it created is its problem, and tr=
iggering reallocation during (1) would be bad.</div></div></div></div></blo=
ckquote><div><br>I&#39;m not sure why we should encourage (1) happening out=
side of the presence of (2). Or rather, I don&#39;t know why it is <i>neces=
sary</i> to do it that way.<br><br>Can you give an example? One that is act=
ually legal C++ under the current object model?<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3ef49ad2-3e73-4d58-872d-fab5f138e22b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3ef49ad2-3e73-4d58-872d-fab5f138e22b=
%40isocpp.org</a>.<br />

------=_Part_1371_760844428.1484019546839--

------=_Part_1370_658322908.1484019546839--

.

------=_Part_2835_1022203291.1484021984605
Content-Type: multipart/alternative;
 boundary="----=_Part_2836_873470393.1484021984606"

------=_Part_2836_873470393.1484021984606
Content-Type: text/plain; charset=UTF-8

On Monday, January 9, 2017 at 8:57:39 PM UTC-5, gmis...@gmail.com wrote:
>
>
>>>
>> Several reasons.
>>
>> First, `basic_string` is intended to be able to have small string
>> optimization (SSO). This means that strings below a certain size are stored
>> internally rather than allocating memory. Thus, your "detach" function
>> doesn't "detach" something in all cases.
>>
>
> That's not a reason for doing nothing. That's just a description of how
> things are that doesn't forward anything. I don't know why so many replies
> are structured like this.
>
> Detach could allocate and copy if it must. If that fails it returns
> nullptr. Or uninitialized_data_at can do the allocate copy if directed,
> that can fail anyway so that seems the fine place to do that. We can
> indicate that in a parameter etc.
> There are ways forward here.
>
>
>
>> Second, `basic_string` and `vector` both allocate memory based on
>> provided allocators. So... how will the user destroy it? They cannot call
>> `delete[]` on it, since it was not allocated with `new[]`. The only way to
>> destroy this object us to use the same allocator that was used to allocate
>> it, or a compatible one. Not only that, the person receiving the pointer
>> has no idea how many objects are in the array, so unless `T` has a trivial
>> destructor, you need to know how many items to destroy. And you need to
>> remember to destroy them in *reverse* order.
>>
>> Third, your APIs are really bad. Inserting default-initialized objects
>> shouldn't use radically different APIs from inserting value-initialized
>> objects. Your API also assumes that `T` is a type which can tolerate being
>> uninitialized. We shouldn't make APIs that break the C++ object model; we
>> should make them that actually work with that model.
>>
>
> I said we could enable_if that and that these could be free. You seem to
> be ignoring that fact or didn't see it. I don't see a problem with the idea.
>
> And C++ already has plenty of 'get outs' for doing what needs to be done
> if it needs to be done. We should make API's that enable us to do what we
> need to do. You don't have to call them if you don't need what it offers.
> So I don't buy your argument.
>

C++ has ways to do things that are illegal in some circumstances because
those tools also permit you to do legal things that you would not otherwise
be able to do. I believe that the circumstances where what you're wanting
to do is actually legal C++ code can be done in ways that *don't* require
tools that allow you to *also* do illegal things.

For example, a C API cannot create a non-trivial C++ object (if you want to
get really technical, a C API cannot begin the lifetime of a C++ object *at
all*, but lets pretend that trivial types can be excepted). As such, you
cannot legally hand the memory of a `vector<T>` to a C API to be
initialized *unless* `T` is trivial. Therefore, the ability to default
initialize a `vector<T>` is all you need to avoid the performance penalty,
since default initialization is a no-op.

Your API would look like this:

vector<T> v;
SomeCAPI(v.uinitialized_data_at(0, n), n);

My API would look like this:

vector<T> v(n, std::default_init);
SomeCAPI(v.data(), v.size());

But they would have *the same performance*: a single allocation of a block
of `n` objects, with no initialization of that array.

So why use an API that is oddball and non-standard looking instead of an
API that looks like normal `vector` mechanisms? Your way makes using
"uninitialized" data look special-case, like you're cheating or something.
My way makes it look normal, just like you had done `new T[n]` or whatever.

Because *it is* normal. You're not cheating; every step is 100% legal C++.
You're not pretending that C APIs can begin the lifetime of C++ objects.
You're creating an array of live C++ objects and passing them along to
someone else who will trivially copy into them.

So why do we need an API that looks so alien to how the API currently works?

The goal is this:
>>
>> T *t = new T[256];
>> vector<T> tv(256, ...);
>>
>> Both of these arrays should perform the same amount of initializing of
>> their respective arrays. If `T` is trivially default constructible, then
>> both of these will be uninitialized.  If `T` has a non-trivial default
>> constructor, then it will be called 256 times in both cases. Because by the
>> rules of C++, that's what `T` requires in order to be a live object.
>>
>
> That's great but why does my suggestion break that or hinder that.
>

Because it doesn't look like regular `vector` stuff.

So why do we have to wait for that?
> Is there any guarantee we will even get that?
>

There's no guarantee you'll get yours either.

If there's something better. What is it?
>>>
>>
>> Well, there's what I already suggested.
>>
>> I also spent a little time thinking about a memory detachment API for
>> vector, one that would actually recognize things like the fact that
>> allocators exist ;) Since then, we've had the introduction of `map`/`set`
>> extract/merge functions, and we see an alternate way to handle transfer of
>> such objects.
>>
>> The design of such an API should mirror them, not deal in direct pointers
>> to something. Also, such a design should include the ability to hand the
>> system existing memory (and an allocator for deleting it), which can then
>> be transferred into a `vector`/`string`.
>>
>
> I don't see how you can avoid dealing with a pointer when you (I) want to
> be able to return a pointer to C here.
>

You can want whatever you like, but that doesn't change the fact that it's
simply not possible. Why? Because you're leaking memory. Or worse, breaking
the heap.

`free` cannot be called on memory allocated by `new` or
`allocator::allocate` or whatever other allocator you may have used (unless
that allocator explicitly uses `malloc`, of course). Therefore, the memory
generated by C++ containers cannot be destroyed by C. So either C is going
to try to `free` this memory and corrupt the heap, or the C API is going to
call back into your code in order to free it.

It should also be noted that, at least in my experience, there aren't a lot
of C APIs like this, which genuinely *adopt* memory allocated by external
code. Lua, Cairo, etc, I can't think of one that adopts memory by return
values of a callback. Generally speaking, they copy it from you.

Can you give an example where a return value from a callback is intended by
a C API to be memory which is dynamically allocated in such a way that the
C system can deallocate it?

Generally speaking, when transitioning from one system to another, you will
need to marshal your data: to copy it from your internal data
structures/memory pools into those compatible with the other system. This
is inevitable and natural. And most of the C APIs I know of tend to hold to
that. They'll fill in arrays of memory with data. But they almost never
cross allocations like this, and for more reasons than just playing ball
with C++ APIs. C programmers sometimes need to write their own heap code,
and that means other systems can't deallocate memory they allocate. So in
my experience, C APIs don't frequently adopt memory.

So I question the motivation for this part of your idea.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e987ac25-dd8a-426d-a62e-41a051708b5a%40isocpp.org.

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

<div dir=3D"ltr">On Monday, January 9, 2017 at 8:57:39 PM UTC-5, gmis...@gm=
ail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;paddin=
g-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-=
left-style:solid"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div>=
<br></div></div></blockquote><div><br>Several reasons.<br><br>First, `basic=
_string` is intended to be able to have small string optimization (SSO). Th=
is means that strings below a certain size are stored internally rather tha=
n allocating memory. Thus, your &quot;detach&quot; function doesn&#39;t &qu=
ot;detach&quot; something in all cases.<br></div></div></blockquote><div><b=
r></div><div>That&#39;s not a reason for doing nothing. That&#39;s just a d=
escription of how things are that doesn&#39;t forward anything. I don&#39;t=
 know why so many replies are structured like this.</div><div><br></div><di=
v>Detach could allocate and copy if it must. If that fails it returns nullp=
tr. Or=C2=A0uninitialized_data_at can do the allocate copy if directed, tha=
t can fail anyway so that seems the fine place to do that. We can indicate =
that in a parameter etc.</div><div>There are ways forward here.</div><div><=
br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border=
-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div><br>Second, =
`basic_string` and `vector` both allocate memory based on provided allocato=
rs. So... how will the user destroy it? They cannot call `delete[]` on it, =
since it was not allocated with `new[]`. The only way to destroy this objec=
t us to use the same allocator that was used to allocate it, or a compatibl=
e one. Not only that, the person receiving the pointer has no idea how many=
 objects are in the array, so unless `T` has a trivial destructor, you need=
 to know how many items to destroy. And you need to remember to destroy the=
m in <i>reverse</i> order.<br><br>Third, your APIs are really bad. Insertin=
g default-initialized objects shouldn&#39;t use radically different APIs fr=
om inserting value-initialized objects. Your API also assumes that `T` is a=
 type which can tolerate being uninitialized. We shouldn&#39;t make APIs th=
at break the C++ object model; we should make them that actually work with =
that model.<br></div></div></blockquote><div><br></div><div>I said we could=
 enable_if that and that these could be free. You seem to be ignoring that =
fact or didn&#39;t=C2=A0see it. I don&#39;t see a problem with the idea.</d=
iv><div><br></div><div>And C++ already has plenty of &#39;get outs&#39; for=
 doing what needs to be done if it needs to be done. We should make API&#39=
;s that enable us to do what we need to do. You don&#39;t have to call them=
 if you don&#39;t need what it offers. So I don&#39;t buy your argument.</d=
iv></div></blockquote><div><br>C++ has ways to do things that are illegal i=
n some circumstances because those tools also permit you to do legal things=
 that you would not otherwise be able to do. I believe that the circumstanc=
es where what you&#39;re wanting to do is actually legal C++ code can be do=
ne in ways that <i>don&#39;t</i> require tools that allow you to <i>also</i=
> do illegal things.<br><br>For example, a C API cannot create a non-trivia=
l C++ object (if you want to get really technical, a C API cannot begin the=
 lifetime of a C++ object <i>at all</i>, but lets pretend that trivial type=
s can be excepted). As such, you cannot legally hand the memory of a `vecto=
r&lt;T&gt;` to a C API to be initialized <i>unless</i> `T` is trivial. Ther=
efore, the ability to default initialize a `vector&lt;T&gt;` is all you nee=
d to avoid the performance penalty, since default initialization is a no-op=
..<br><br>Your API would look like this:<br><br><div style=3D"background-col=
or: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: sol=
id; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><c=
ode class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">vector</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> v</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #606;" class=3D"styled-by-prettify">SomeCAPI<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">v</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">uinitialized_data_at</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> n</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">),</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> n</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);<=
/span></div></code></div><br>My API would look like this:<br><br><div style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
 border-style: solid; border-width: 1px; overflow-wrap: break-word;" class=
=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #000;" class=3D"styled-by-prettify">vector</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> v</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">n</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s=
td</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">default_init</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">SomeCAPI</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">v</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">data</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(),</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> v</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">size</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">());</span></div=
></code></div><br>But they would have <i>the same performance</i>: a single=
 allocation of a block of `n` objects, with no initialization of that array=
..<br><br>So why use an API that is oddball and non-standard looking instead=
 of an API that looks like normal `vector` mechanisms? Your way makes using=
 &quot;uninitialized&quot; data look special-case, like you&#39;re cheating=
 or something. My way makes it look normal, just like you had done `new T[n=
]` or whatever.<br><br>Because <i>it is</i> normal. You&#39;re not cheating=
; every step is 100% legal C++. You&#39;re not pretending that C APIs can b=
egin the lifetime of C++ objects. You&#39;re creating an array of live C++ =
objects and passing them along to someone else who will trivially copy into=
 them.<br><br>So why do we need an API that looks so alien to how the API c=
urrently works?<br><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-wi=
dth:1px;border-left-style:solid"><div dir=3D"ltr"><div>The goal is this:<br=
><br><div style=3D"border:1px solid rgb(187,187,187);background-color:rgb(2=
50,250,250)"><code><div><span style=3D"color:rgb(0,0,0)">T </span><span sty=
le=3D"color:rgb(102,102,0)">*</span><span style=3D"color:rgb(0,0,0)">t </sp=
an><span style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(=
0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">new</span><span style=3D=
"color:rgb(0,0,0)"> T</span><span style=3D"color:rgb(102,102,0)">[</span><s=
pan style=3D"color:rgb(0,102,102)">256</span><span style=3D"color:rgb(102,1=
02,0)">];</span><span style=3D"color:rgb(0,0,0)"><br>vector</span><span sty=
le=3D"color:rgb(102,102,0)">&lt;</span><span style=3D"color:rgb(0,0,0)">T</=
span><span style=3D"color:rgb(102,102,0)">&gt;</span><span style=3D"color:r=
gb(0,0,0)"> tv</span><span style=3D"color:rgb(102,102,0)">(</span><span sty=
le=3D"color:rgb(0,102,102)">256</span><span style=3D"color:rgb(102,102,0)">=
,</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(1=
02,102,0)">...);</span><span style=3D"color:rgb(0,0,0)"><br></span></div></=
code></div><br>Both of these arrays should perform the same amount of initi=
alizing of their respective arrays. If `T` is trivially default constructib=
le, then both of these will be uninitialized.=C2=A0 If `T` has a non-trivia=
l default constructor, then it will be called 256 times in both cases. Beca=
use by the rules of C++, that&#39;s what `T` requires in order to be a live=
 object.<br></div></div></blockquote><div><br></div><div>That&#39;s great b=
ut why does my suggestion break that=C2=A0or hinder that.</div></div></bloc=
kquote><div><br>Because it doesn&#39;t look like regular `vector` stuff.<br=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><d=
iv>So why do we have to wait for that?</div><div>Is there any guarantee we =
will even get that?</div></div></blockquote><div><br>There&#39;s no guarant=
ee you&#39;ll get yours either.<br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;paddi=
ng-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border=
-left-style:solid"><div dir=3D"ltr"><div>If there&#39;s something better. W=
hat is it?<br></div></div></blockquote><div><br>Well, there&#39;s what I al=
ready suggested.<br><br>I also spent a little time thinking about a memory =
detachment API for vector, one that would actually recognize things like th=
e fact that allocators exist ;) Since then, we&#39;ve had the introduction =
of `map`/`set` extract/merge functions, and we see an alternate way to hand=
le transfer of such objects.<br><br>The design of such an API should mirror=
 them, not deal in direct pointers to something. Also, such a design should=
 include the ability to hand the system existing memory (and an allocator f=
or deleting it), which can then be transferred into a `vector`/`string`.<br=
></div></div></blockquote><div><br></div><div>I don&#39;t see how you can a=
void=C2=A0dealing with a pointer when you (I) want to be able to return a p=
ointer to C here.</div></div></blockquote><div><br>You can want whatever yo=
u like, but that doesn&#39;t change the fact that it&#39;s simply not possi=
ble. Why? Because you&#39;re leaking memory. Or worse, breaking the heap.<b=
r><br>`free` cannot be called on memory allocated by `new` or `allocator::a=
llocate` or whatever other allocator you may have used (unless that allocat=
or explicitly uses `malloc`, of course). Therefore, the memory generated by=
 C++ containers cannot be destroyed by C. So either C is going to try to `f=
ree` this memory and corrupt the heap, or the C API is going to call back i=
nto your code in order to free it.<br><br>It should also be noted that, at =
least in my experience, there aren&#39;t a lot of C APIs like this, which g=
enuinely <i>adopt</i> memory allocated by external code. Lua, Cairo, etc, I=
 can&#39;t think of one that adopts memory by return values of a callback. =
Generally speaking, they copy it from you.<br><br>Can you give an example w=
here a return value from a callback is intended by a C API to be memory whi=
ch is dynamically allocated in such a way that the C system can deallocate =
it?<br><br>Generally speaking, when transitioning from one system to anothe=
r, you will need to marshal your data: to copy it from your internal data s=
tructures/memory pools into those compatible with the other system. This is=
 inevitable and natural. And most of the C APIs I know of tend to hold to t=
hat. They&#39;ll fill in arrays of memory with data. But they almost never =
cross allocations like this, and for more reasons than just playing ball wi=
th C++ APIs. C programmers sometimes need to write their own heap code, and=
 that means other systems can&#39;t deallocate memory they allocate. So in =
my experience, C APIs don&#39;t frequently adopt memory.<br><br>So I questi=
on the motivation for this part of your idea.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e987ac25-dd8a-426d-a62e-41a051708b5a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e987ac25-dd8a-426d-a62e-41a051708b5a=
%40isocpp.org</a>.<br />

------=_Part_2836_873470393.1484021984606--

------=_Part_2835_1022203291.1484021984605--

.

------=_Part_4561_947098193.1484031449156
Content-Type: multipart/alternative;
 boundary="----=_Part_4562_1542351987.1484031449157"

------=_Part_4562_1542351987.1484031449157
Content-Type: text/plain; charset=UTF-8



On Tuesday, January 10, 2017 at 5:19:44 PM UTC+13, Nicol Bolas wrote:
>
> On Monday, January 9, 2017 at 8:57:39 PM UTC-5, gmis...@gmail.com wrote:
>>
>>
>>>>
>>> Several reasons.
>>>
>>> First, `basic_string` is intended to be able to have small string
>>> optimization (SSO). This means that strings below a certain size are stored
>>> internally rather than allocating memory. Thus, your "detach" function
>>> doesn't "detach" something in all cases.
>>>
>>
>> That's not a reason for doing nothing. That's just a description of how
>> things are that doesn't forward anything. I don't know why so many replies
>> are structured like this.
>>
>> Detach could allocate and copy if it must. If that fails it returns
>> nullptr. Or uninitialized_data_at can do the allocate copy if directed,
>> that can fail anyway so that seems the fine place to do that. We can
>> indicate that in a parameter etc.
>> There are ways forward here.
>>
>>
>>
>>> Second, `basic_string` and `vector` both allocate memory based on
>>> provided allocators. So... how will the user destroy it? They cannot call
>>> `delete[]` on it, since it was not allocated with `new[]`. The only way to
>>> destroy this object us to use the same allocator that was used to allocate
>>> it, or a compatible one. Not only that, the person receiving the pointer
>>> has no idea how many objects are in the array, so unless `T` has a trivial
>>> destructor, you need to know how many items to destroy. And you need to
>>> remember to destroy them in *reverse* order.
>>>
>>> Third, your APIs are really bad. Inserting default-initialized objects
>>> shouldn't use radically different APIs from inserting value-initialized
>>> objects. Your API also assumes that `T` is a type which can tolerate being
>>> uninitialized. We shouldn't make APIs that break the C++ object model; we
>>> should make them that actually work with that model.
>>>
>>
>> I said we could enable_if that and that these could be free. You seem to
>> be ignoring that fact or didn't see it. I don't see a problem with the idea.
>>
>> And C++ already has plenty of 'get outs' for doing what needs to be done
>> if it needs to be done. We should make API's that enable us to do what we
>> need to do. You don't have to call them if you don't need what it offers.
>> So I don't buy your argument.
>>
>
> C++ has ways to do things that are illegal in some circumstances because
> those tools also permit you to do legal things that you would not otherwise
> be able to do. I believe that the circumstances where what you're wanting
> to do is actually legal C++ code can be done in ways that *don't* require
> tools that allow you to *also* do illegal things.
>

Legal and illegal are just points in time. What is today illegal can often
be made legal depending on the will and reasoning.
But something being illegal today in of itself isn't interesting.


>
> For example, a C API cannot create a non-trivial C++ object (if you want
> to get really technical, a C API cannot begin the lifetime of a C++ object *at
> all*, but lets pretend that trivial types can be excepted). As such, you
> cannot legally hand the memory of a `vector<T>` to a C API to be
> initialized *unless* `T` is trivial. Therefore, the ability to default
> initialize a `vector<T>` is all you need to avoid the performance penalty,
> since default initialization is a no-op.
>
> Your API would look like this:
>
> vector<T> v;
> SomeCAPI(v.uinitialized_data_at(0, n), n);
>

yes, I'm not attached to the API, but nor do I have a problem with it. I
just want the ability.


>
> My API would look like this:
>
> vector<T> v(n, std::default_init);
> SomeCAPI(v.data(), v.size());
>
> But they would have *the same performance*: a single allocation of a
> block of `n` objects, with no initialization of that array.
>

I'm fine with your API but it's less flexible than my API unless I miss
understand what yours implies.
And I feel I'm not appreciating what yours implies  Can you extend v
without getting more unwanted initialization with your API?
i.e. Is v.resize(10000) going to do the right thing her and not zero fill
where n in the initial call is say 1 or 0.


>
> So why use an API that is oddball and non-standard looking instead of an
> API that looks like normal `vector` mechanisms? Your way makes using
> "uninitialized" data look special-case, like you're cheating or something.
> My way makes it look normal, just like you had done `new T[n]` or whatever.
>

I don't find my API that oddball but I'm not hung up on my api, I just want
the feature of unintialized allocation.


> Because *it is* normal. You're not cheating; every step is 100% legal
> C++. You're not pretending that C APIs can begin the lifetime of C++
> objects. You're creating an array of live C++ objects and passing them
> along to someone else who will trivially copy into them.
>

I'm not pretending that as far as I know. My API isn't asking C to
begin life here. But I'm sure we'll work out whatever misunderstanding I or
you have here later.


>
> So why do we need an API that looks so alien to how the API currently
> works?
>

I don't need anything alien. I just want something that gives me
unintialized allocation.
When I mooted what I need, you started talking about language changes
as a requirement to progress.
I just said no, as an API should be able to suffice without a language
change. Quite what the API is I'm less fussed.
We need some API with or without language change, I don't care what that is
as long as it works.
I proposed *something* to get the discussion going beyond, 'oh no we can't
progress until there's language change'.


>
> The goal is this:
>>>
>>> T *t = new T[256];
>>> vector<T> tv(256, ...);
>>>
>>> Both of these arrays should perform the same amount of initializing of
>>> their respective arrays. If `T` is trivially default constructible, then
>>> both of these will be uninitialized.  If `T` has a non-trivial default
>>> constructor, then it will be called 256 times in both cases. Because by the
>>> rules of C++, that's what `T` requires in order to be a live object.
>>>
>>
>> That's great but why does my suggestion break that or hinder that.
>>
>
> Because it doesn't look like regular `vector` stuff.
>

This isn't something I agree with. But it's not important to me. I'll
ignore this for now though depending on what you reply to my other
questions.


>
> So why do we have to wait for that?
>> Is there any guarantee we will even get that?
>>
>
> There's no guarantee you'll get yours either.
>

We have more chance of getting something like mine than yours because mine
doesn't require language change.
If we have to wait 3 years for either, I want the best one - but I want
*something* here.
Not an attempt at yours and if it fails, nothing for 6 years. So we're
having the discussion to keep all of this progressing.


>
> If there's something better. What is it?
>>>>
>>>
>>> Well, there's what I already suggested.
>>>
>>> I also spent a little time thinking about a memory detachment API for
>>> vector, one that would actually recognize things like the fact that
>>> allocators exist ;) Since then, we've had the introduction of `map`/`set`
>>> extract/merge functions, and we see an alternate way to handle transfer of
>>> such objects.
>>>
>>> The design of such an API should mirror them, not deal in direct
>>> pointers to something. Also, such a design should include the ability to
>>> hand the system existing memory (and an allocator for deleting it), which
>>> can then be transferred into a `vector`/`string`.
>>>
>>
>> I don't see how you can avoid dealing with a pointer when you (I) want to
>> be able to return a pointer to C here.
>>
>
> You can want whatever you like, but that doesn't change the fact that it's
> simply not possible. Why? Because you're leaking memory. Or worse, breaking
> the heap.
>
> `free` cannot be called on memory allocated by `new` or
> `allocator::allocate` or whatever other allocator you may have used (unless
> that allocator explicitly uses `malloc`, of course). Therefore, the memory
> generated by C++ containers cannot be destroyed by C. So either C is going
> to try to `free` this memory and corrupt the heap, or the C API is going to
> call back into your code in order to free it.
>
> It should also be noted that, at least in my experience, there aren't a
> lot of C APIs like this, which genuinely *adopt* memory allocated by
> external code. Lua, Cairo, etc, I can't think of one that adopts memory by
> return values of a callback. Generally speaking, they copy it from you.
>
> Can you give an example where a return value from a callback is intended
> by a C API to be memory which is dynamically allocated in such a way that
> the C system can deallocate it?
>
> Generally speaking, when transitioning from one system to another, you
> will need to marshal your data: to copy it from your internal data
> structures/memory pools into those compatible with the other system. This
> is inevitable and natural. And most of the C APIs I know of tend to hold to
> that. They'll fill in arrays of memory with data. But they almost never
> cross allocations like this, and for more reasons than just playing ball
> with C++ APIs. C programmers sometimes need to write their own heap code,
> and that means other systems can't deallocate memory they allocate. So in
> my experience, C APIs don't frequently adopt memory.
>

This is because C and C++ don't promise to free each others memory. But
this is something that could potentially be made possible and legal.
Then there would be no leak. If C and C++ are going to be the best
companions possible that's something to consider making legal.
Hopefully this discussion gets people who know the area well talking about
if we can and why we should do this.
But that it is illegal today in of itself means not that much.


>
> So I question the motivation for this part of your idea.
>

You are correct, I see returning pointers to C is the least important part
of my request.
It's a nice to have depending on the problems. That's why I said in my
previous posts that I'm not obsessed about a detach ability for C as much
as I am about the unintialized allocation ability.
It would be nice to pass data of the same type between containers for C++
but it's the uninitialized allocation I'm interested in.
Then C++ interop between containers, then C interop.

But I think if we want C code bases to come to C++ if we could make this
basic interop possible it would seem to be a good thing. it just depends on
what the issues are.

But for C++17, if it was just want unintialized_resize() or data_at or
whatever I'd be happy. We must have this for C++20 I think, I'd ideally
like this function sooner even if non standard to test with.


--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0a229e05-74c9-4950-8e78-b28b8d691b06%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Tuesday, January 10, 2017 at 5:19:44 PM UTC+13,=
 Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">On Monday,=
 January 9, 2017 at 8:57:39 PM UTC-5, <a>gmis...@gmail.com</a> wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-lef=
t: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bord=
er-left-style: solid;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rg=
b(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div d=
ir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0=
..8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left=
-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><br></div></d=
iv></blockquote><div><br>Several reasons.<br><br>First, `basic_string` is i=
ntended to be able to have small string optimization (SSO). This means that=
 strings below a certain size are stored internally rather than allocating =
memory. Thus, your &quot;detach&quot; function doesn&#39;t &quot;detach&quo=
t; something in all cases.<br></div></div></blockquote><div><br></div><div>=
That&#39;s not a reason for doing nothing. That&#39;s just a description of=
 how things are that doesn&#39;t forward anything. I don&#39;t know why so =
many replies are structured like this.</div><div><br></div><div>Detach coul=
d allocate and copy if it must. If that fails it returns nullptr. Or=C2=A0u=
ninitialized_data_at can do the allocate copy if directed, that can fail an=
yway so that seems the fine place to do that. We can indicate that in a par=
ameter etc.</div><div>There are ways forward here.</div><div><br></div><div=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0=
..8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left=
-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><br>Second, `=
basic_string` and `vector` both allocate memory based on provided allocator=
s. So... how will the user destroy it? They cannot call `delete[]` on it, s=
ince it was not allocated with `new[]`. The only way to destroy this object=
 us to use the same allocator that was used to allocate it, or a compatible=
 one. Not only that, the person receiving the pointer has no idea how many =
objects are in the array, so unless `T` has a trivial destructor, you need =
to know how many items to destroy. And you need to remember to destroy them=
 in <i>reverse</i> order.<br><br>Third, your APIs are really bad. Inserting=
 default-initialized objects shouldn&#39;t use radically different APIs fro=
m inserting value-initialized objects. Your API also assumes that `T` is a =
type which can tolerate being uninitialized. We shouldn&#39;t make APIs tha=
t break the C++ object model; we should make them that actually work with t=
hat model.<br></div></div></blockquote><div><br></div><div>I said we could =
enable_if that and that these could be free. You seem to be ignoring that f=
act or didn&#39;t=C2=A0see it. I don&#39;t see a problem with the idea.</di=
v><div><br></div><div>And C++ already has plenty of &#39;get outs&#39; for =
doing what needs to be done if it needs to be done. We should make API&#39;=
s that enable us to do what we need to do. You don&#39;t have to call them =
if you don&#39;t need what it offers. So I don&#39;t buy your argument.</di=
v></div></blockquote><div><br>C++ has ways to do things that are illegal in=
 some circumstances because those tools also permit you to do legal things =
that you would not otherwise be able to do. I believe that the circumstance=
s where what you&#39;re wanting to do is actually legal C++ code can be don=
e in ways that <i>don&#39;t</i> require tools that allow you to <i>also</i>=
 do illegal things.<br></div></div></blockquote><div><br></div><div>Legal a=
nd illegal are just points in time. What is today illegal can often be made=
 legal depending on the will and reasoning.</div><div>But something being i=
llegal today in of itself isn&#39;t interesting.</div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-l=
eft: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bo=
rder-left-style: solid;"><div dir=3D"ltr"><div><br>For example, a C API can=
not create a non-trivial C++ object (if you want to get really technical, a=
 C API cannot begin the lifetime of a C++ object <i>at all</i>, but lets pr=
etend that trivial types can be excepted). As such, you cannot legally hand=
 the memory of a `vector&lt;T&gt;` to a C API to be initialized <i>unless</=
i> `T` is trivial. Therefore, the ability to default initialize a `vector&l=
t;T&gt;` is all you need to avoid the performance penalty, since default in=
itialization is a no-op.<br><br>Your API would look like this:<br><br><div =
style=3D"border: 1px solid rgb(187, 187, 187); border-image: none; backgrou=
nd-color: rgb(250, 250, 250);"><code><div><span style=3D"color: rgb(0, 0, 0=
);">vector</span><span style=3D"color: rgb(102, 102, 0);">&lt;</span><span =
style=3D"color: rgb(0, 0, 0);">T</span><span style=3D"color: rgb(102, 102, =
0);">&gt;</span><span style=3D"color: rgb(0, 0, 0);"> v</span><span style=
=3D"color: rgb(102, 102, 0);">;</span><span style=3D"color: rgb(0, 0, 0);">=
<br></span><span style=3D"color: rgb(102, 0, 102);">SomeCAPI</span><span st=
yle=3D"color: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(0, 0, 0)=
;">v</span><span style=3D"color: rgb(102, 102, 0);">.</span><span style=3D"=
color: rgb(0, 0, 0);">uinitialized_data_<wbr>at</span><span style=3D"color:=
 rgb(102, 102, 0);">(</span><span style=3D"color: rgb(0, 102, 102);">0</spa=
n><span style=3D"color: rgb(102, 102, 0);">,</span><span style=3D"color: rg=
b(0, 0, 0);"> n</span><span style=3D"color: rgb(102, 102, 0);">),</span><sp=
an style=3D"color: rgb(0, 0, 0);"> n</span><span style=3D"color: rgb(102, 1=
02, 0);">);</span></div></code></div></div></div></blockquote><div><br></di=
v><div>yes, I&#39;m not attached to the API, but nor do I have a problem wi=
th it. I just want the ability.</div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-=
left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: =
solid;"><div dir=3D"ltr"><div><br>My API would look like this:<br><br><div =
style=3D"border: 1px solid rgb(187, 187, 187); border-image: none; backgrou=
nd-color: rgb(250, 250, 250);"><code><div><span style=3D"color: rgb(0, 0, 0=
);">vector</span><span style=3D"color: rgb(102, 102, 0);">&lt;</span><span =
style=3D"color: rgb(0, 0, 0);">T</span><span style=3D"color: rgb(102, 102, =
0);">&gt;</span><span style=3D"color: rgb(0, 0, 0);"> v</span><span style=
=3D"color: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(0, 0, 0);">=
n</span><span style=3D"color: rgb(102, 102, 0);">,</span><span style=3D"col=
or: rgb(0, 0, 0);"> std</span><span style=3D"color: rgb(102, 102, 0);">::</=
span><span style=3D"color: rgb(0, 0, 0);">default_init</span><span style=3D=
"color: rgb(102, 102, 0);">);</span><span style=3D"color: rgb(0, 0, 0);"><b=
r></span><span style=3D"color: rgb(102, 0, 102);">SomeCAPI</span><span styl=
e=3D"color: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(0, 0, 0);"=
>v</span><span style=3D"color: rgb(102, 102, 0);">.</span><span style=3D"co=
lor: rgb(0, 0, 0);">data</span><span style=3D"color: rgb(102, 102, 0);">(),=
</span><span style=3D"color: rgb(0, 0, 0);"> v</span><span style=3D"color: =
rgb(102, 102, 0);">.</span><span style=3D"color: rgb(0, 0, 0);">size</span>=
<span style=3D"color: rgb(102, 102, 0);">());</span></div></code></div><br>=
But they would have <i>the same performance</i>: a single allocation of a b=
lock of `n` objects, with no initialization of that array.<br></div></div><=
/blockquote><div><br></div><div>I&#39;m fine with=C2=A0your API=C2=A0but it=
&#39;s less flexible than my=C2=A0API unless I miss understand what=C2=A0yo=
urs implies.</div><div>And I feel I&#39;m not appreciating=C2=A0what yours =
implies=C2=A0 Can you extend v without getting more unwanted initialization=
 with your API?</div><div>i.e. Is v.resize(10000) going to do the right thi=
ng her and not zero fill where n in the initial call is say 1 or 0.</div><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0=
px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-=
left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><br>So wh=
y use an API that is oddball and non-standard looking instead of an API tha=
t looks like normal `vector` mechanisms? Your way makes using &quot;uniniti=
alized&quot; data look special-case, like you&#39;re cheating or something.=
 My way makes it look normal, just like you had done `new T[n]` or whatever=
..<br></div></div></blockquote><div><br></div><div>I don&#39;t find my API t=
hat=C2=A0oddball but I&#39;m not hung up on my api, I just want the feature=
 of unintialized allocation.=C2=A0</div><div><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border=
-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style:=
 solid;"><div dir=3D"ltr"><div><br>Because <i>it is</i> normal. You&#39;re =
not cheating; every step is 100% legal C++. You&#39;re not pretending that =
C APIs can begin the lifetime of C++ objects. You&#39;re creating an array =
of live C++ objects and passing them along to someone else who will trivial=
ly copy into them.<br></div></div></blockquote><div><br></div><div>I&#39;m =
not pretending that as far as I know. My API isn&#39;t asking C to begin=C2=
=A0life here. But I&#39;m sure we&#39;ll work out whatever misunderstanding=
 I or you have here later.</div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-=
color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid=
;"><div dir=3D"ltr"><div><br>So why do we need an API that looks so alien t=
o how the API currently works?<br></div></div></blockquote><div>=C2=A0</div=
><div>I don&#39;t need anything=C2=A0alien. I just want something that give=
s me unintialized allocation.</div><div>When I mooted what I need, you star=
ted talking about language changes as=C2=A0a=C2=A0requirement to progress.<=
/div><div>I just said no, as an API should be able to suffice without a lan=
guage change. Quite what the API is I&#39;m less fussed.</div><div>We need =
some API with or without language change, I don&#39;t care what that is as =
long as it works.</div><div>I proposed *something* to get the discussion go=
ing beyond, &#39;oh no we can&#39;t progress until there&#39;s language cha=
nge&#39;.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 2=
04, 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"lt=
r"><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bord=
er-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1e=
x; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-le=
ft-style: solid;"><div dir=3D"ltr"><div>The goal is this:<br><br><div style=
=3D"border: 1px solid rgb(187, 187, 187); border-image: none; background-co=
lor: rgb(250, 250, 250);"><code><div><span style=3D"color: rgb(0, 0, 0);">T=
 </span><span style=3D"color: rgb(102, 102, 0);">*</span><span style=3D"col=
or: rgb(0, 0, 0);">t </span><span style=3D"color: rgb(102, 102, 0);">=3D</s=
pan><span style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(=
0, 0, 136);">new</span><span style=3D"color: rgb(0, 0, 0);"> T</span><span =
style=3D"color: rgb(102, 102, 0);">[</span><span style=3D"color: rgb(0, 102=
, 102);">256</span><span style=3D"color: rgb(102, 102, 0);">];</span><span =
style=3D"color: rgb(0, 0, 0);"><br>vector</span><span style=3D"color: rgb(1=
02, 102, 0);">&lt;</span><span style=3D"color: rgb(0, 0, 0);">T</span><span=
 style=3D"color: rgb(102, 102, 0);">&gt;</span><span style=3D"color: rgb(0,=
 0, 0);"> tv</span><span style=3D"color: rgb(102, 102, 0);">(</span><span s=
tyle=3D"color: rgb(0, 102, 102);">256</span><span style=3D"color: rgb(102, =
102, 0);">,</span><span style=3D"color: rgb(0, 0, 0);"> </span><span style=
=3D"color: rgb(102, 102, 0);">...);</span><span style=3D"color: rgb(0, 0, 0=
);"><br></span></div></code></div><br>Both of these arrays should perform t=
he same amount of initializing of their respective arrays. If `T` is trivia=
lly default constructible, then both of these will be uninitialized.=C2=A0 =
If `T` has a non-trivial default constructor, then it will be called 256 ti=
mes in both cases. Because by the rules of C++, that&#39;s what `T` require=
s in order to be a live object.<br></div></div></blockquote><div><br></div>=
<div>That&#39;s great but why does my suggestion break that=C2=A0or hinder =
that.</div></div></blockquote><div><br>Because it doesn&#39;t look like reg=
ular `vector` stuff.<br></div></div></blockquote><div><br></div><div>This=
=C2=A0isn&#39;t something I agree with. But it&#39;s not important to me.=
=C2=A0I&#39;ll ignore this for now though depending on what you reply to my=
 other questions.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rg=
b(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div d=
ir=3D"ltr"><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 20=
4); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><di=
v>So why do we have to wait for that?</div><div>Is there any guarantee we w=
ill even get that?</div></div></blockquote><div><br>There&#39;s no guarante=
e you&#39;ll get yours either.<br></div></div></blockquote><div><br></div><=
div>We have more chance of getting something like=C2=A0mine than yours beca=
use mine doesn&#39;t require language change.</div><div>If we have to wait =
3 years for either, I want the best one - but I want *something* here.</div=
><div>Not an attempt at yours and if it fails, nothing for 6 years. So we&#=
39;re having the discussion to keep all of this progressing.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8=
ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-w=
idth: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-le=
ft: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bor=
der-left-style: solid;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" =
style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: r=
gb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div =
dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204);=
 border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>I=
f there&#39;s something better. What is it?<br></div></div></blockquote><di=
v><br>Well, there&#39;s what I already suggested.<br><br>I also spent a lit=
tle time thinking about a memory detachment API for vector, one that would =
actually recognize things like the fact that allocators exist ;) Since then=
, we&#39;ve had the introduction of `map`/`set` extract/merge functions, an=
d we see an alternate way to handle transfer of such objects.<br><br>The de=
sign of such an API should mirror them, not deal in direct pointers to some=
thing. Also, such a design should include the ability to hand the system ex=
isting memory (and an allocator for deleting it), which can then be transfe=
rred into a `vector`/`string`.<br></div></div></blockquote><div><br></div><=
div>I don&#39;t see how you can avoid=C2=A0dealing with a pointer when you =
(I) want to be able to return a pointer to C here.</div></div></blockquote>=
<div><br>You can want whatever you like, but that doesn&#39;t change the fa=
ct that it&#39;s simply not possible. Why? Because you&#39;re leaking memor=
y. Or worse, breaking the heap.<br><br>`free` cannot be called on memory al=
located by `new` or `allocator::allocate` or whatever other allocator you m=
ay have used (unless that allocator explicitly uses `malloc`, of course). T=
herefore, the memory generated by C++ containers cannot be destroyed by C. =
So either C is going to try to `free` this memory and corrupt the heap, or =
the C API is going to call back into your code in order to free it.<br><br>=
It should also be noted that, at least in my experience, there aren&#39;t a=
 lot of C APIs like this, which genuinely <i>adopt</i> memory allocated by =
external code. Lua, Cairo, etc, I can&#39;t think of one that adopts memory=
 by return values of a callback. Generally speaking, they copy it from you.=
<br><br>Can you give an example where a return value from a callback is int=
ended by a C API to be memory which is dynamically allocated in such a way =
that the C system can deallocate it?<br><br>Generally speaking, when transi=
tioning from one system to another, you will need to marshal your data: to =
copy it from your internal data structures/memory pools into those compatib=
le with the other system. This is inevitable and natural. And most of the C=
 APIs I know of tend to hold to that. They&#39;ll fill in arrays of memory =
with data. But they almost never cross allocations like this, and for more =
reasons than just playing ball with C++ APIs. C programmers sometimes need =
to write their own heap code, and that means other systems can&#39;t deallo=
cate memory they allocate. So in my experience, C APIs don&#39;t frequently=
 adopt memory.<br></div></div></blockquote><div><br></div><div>This is beca=
use C and C++ don&#39;t promise to free each others memory. But this is som=
ething that could potentially=C2=A0be made possible and legal.</div><div>Th=
en there would be no leak. If C and C++ are going to be the best companions=
 possible that&#39;s something to consider making legal.</div><div>Hopefull=
y this discussion gets people who know the area well talking about if we ca=
n and why we should do this.</div><div>But that it is illegal today in of i=
tself means not that much.</div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-=
color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid=
;"><div dir=3D"ltr"><div><br>So I question the motivation for this part of =
your idea.<br></div></div></blockquote><div><br></div><div>You are correct,=
 I see returning pointers to C is the least important part of my request.</=
div><div>It&#39;s a nice to have depending on the problems. That&#39;s why =
I said in my previous posts that I&#39;m not obsessed about a detach abilit=
y for C as much as I am about the unintialized allocation ability.</div><di=
v>It would be nice to pass data of the same type between containers for C++=
 but it&#39;s the uninitialized allocation I&#39;m interested in.</div><div=
>Then C++ interop between containers, then C interop.</div><div><br></div><=
div>But I think if we want C code bases to come to C++ if we could make thi=
s basic interop possible it would seem to be a good thing. it just depends =
on what the issues are.</div><div><br></div><div>But for C++17, if it was j=
ust want unintialized_resize() or data_at or whatever I&#39;d be happy. We =
must have this for C++20 I think, I&#39;d ideally like this function sooner=
 even if non standard=C2=A0to test with.</div><div>=C2=A0</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0a229e05-74c9-4950-8e78-b28b8d691b06%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0a229e05-74c9-4950-8e78-b28b8d691b06=
%40isocpp.org</a>.<br />

------=_Part_4562_1542351987.1484031449157--

------=_Part_4561_947098193.1484031449156--

.

--f403045eaca8b60df20545b9e6b6
Content-Type: text/plain; charset=UTF-8

On Tue, Jan 10, 2017 at 6:57 AM, <gmisocpp@gmail.com> wrote:

> But for C++17, if it was just want unintialized_resize() or data_at or
> whatever I'd be happy. We must have this for C++20 I think, I'd ideally
> like this function sooner even if non standard to test with.
>

You must have it? Then start coding it, and publish a write-up of your
successful results.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhGfQ%3DGaQC25K%3DwR%3Dr7d5_L0A6cSqB3Cz4PYJ2%3DEHJMk7w%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Jan 10, 2017 at 6:57 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:gmiso=
cpp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""></span><=
div>But for C++17, if it was just want unintialized_resize() or data_at or =
whatever I&#39;d be happy. We must have this for C++20 I think, I&#39;d ide=
ally like this function sooner even if non standard=C2=A0to test with.</div=
></div></blockquote><div><br></div><div>You must have it? Then start coding=
 it, and publish a write-up of your successful results.<br></div></div><br>=
</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhGfQ%3DGaQC25K%3DwR%3Dr7d5_L0A6=
cSqB3Cz4PYJ2%3DEHJMk7w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhGf=
Q%3DGaQC25K%3DwR%3Dr7d5_L0A6cSqB3Cz4PYJ2%3DEHJMk7w%40mail.gmail.com</a>.<br=
 />

--f403045eaca8b60df20545b9e6b6--

.

--001a1146fba2523c400545ba8dbf
Content-Type: text/plain; charset=UTF-8

On 9 January 2017 at 19:39, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Monday, January 9, 2017 at 9:03:03 PM UTC-5, Richard Smith wrote:
>>
>> On 9 January 2017 at 17:35, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> Several reasons.
>>>
>>> First, `basic_string` is intended to be able to have small string
>>> optimization (SSO). This means that strings below a certain size are stored
>>> internally rather than allocating memory. Thus, your "detach" function
>>> doesn't "detach" something in all cases.
>>>
>>> Second, `basic_string` and `vector` both allocate memory based on
>>> provided allocators. So... how will the user destroy it? They cannot call
>>> `delete[]` on it, since it was not allocated with `new[]`. The only way to
>>> destroy this object us to use the same allocator that was used to allocate
>>> it, or a compatible one. Not only that, the person receiving the pointer
>>> has no idea how many objects are in the array, so unless `T` has a trivial
>>> destructor, you need to know how many items to destroy. And you need to
>>> remember to destroy them in *reverse* order.
>>>
>>> Third, your APIs are really bad. Inserting default-initialized objects
>>> shouldn't use radically different APIs from inserting value-initialized
>>> objects. Your API also assumes that `T` is a type which can tolerate being
>>> uninitialized. We shouldn't make APIs that break the C++ object model; we
>>> should make them that actually work with that model.
>>>
>>> The goal is this:
>>>
>>> T *t = new T[256];
>>> vector<T> tv(256, ...);
>>>
>>> Both of these arrays should perform the same amount of initializing of
>>> their respective arrays. If `T` is trivially default constructible, then
>>> both of these will be uninitialized.  If `T` has a non-trivial default
>>> constructor, then it will be called 256 times in both cases. Because by the
>>> rules of C++, that's what `T` requires in order to be a live object.
>>>
>>
>> If you only provide that, you have not solved the complete problem.
>> Sometimes the requirements do include the ability to directly construct a
>> sequence of T objects in place within a vector, in ways that emplace does
>> not support.
>>
>
> That is a problem best solved by allowing `emplace` to construct an object
> in ways that it does not currently support.
>
> What in particular was a circumstance you were thinking of?
>

Let's say you want to move a sequence of Ts into a vector<T>, applying a
permutation (supplied as a vector<size_t>) as you go, and you can't default
construct Ts. You could do that like this with the proposed functionality:

dest.reserve(src.size());
for (size_t i = 0; i != src.size(); ++i)
  // pointer arithmetic questionable, but that's a pre-existing problem
with vector
  new (dest.data() + perm[i]) T(std::move(src[i]));
dest.resize_already_initialized(src.size());

Due to the random access order of the destination, you can't do this with
emplace.

One (slightly scary) approach would be:
>> 1) permit the user to construct objects in trailing storage of a
>> vector/string, so long as capacity is large enough, and
>> 2) provide a resize_already_initialized(size_t) member to resize the
>> container so that those elements are part of its size, without constructing
>> new Ts over the top of them
>>
>
>> Obviously if (1) somehow fails or throws, destroying the elements it
>> created is its problem, and triggering reallocation during (1) would be bad.
>>
>
> I'm not sure why we should encourage (1) happening outside of the presence
> of (2). Or rather, I don't know why it is *necessary* to do it that way.
>
> Can you give an example? One that is actually legal C++ under the current
> object model?
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/3ef49ad2-3e73-4d58-
> 872d-fab5f138e22b%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3ef49ad2-3e73-4d58-872d-fab5f138e22b%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqkZh8zWj3sdDcPE8%2BgqyJNfZBWd_Aj_1oFLxLfqz3JV7w%40mail.gmail.com.

--001a1146fba2523c400545ba8dbf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 9=
 January 2017 at 19:39, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto=
:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr=
">On Monday, January 9, 2017 at 9:03:03 PM UTC-5, Richard Smith wrote:<span=
 class=3D"gmail-"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div di=
r=3D"ltr"><div><div class=3D"gmail_quote">On 9 January 2017 at 17:35, Nicol=
 Bolas <span dir=3D"ltr">&lt;<a rel=3D"nofollow">jmck...@gmail.com</a>&gt;<=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div>Several reasons.<br><br>First, `basic_string` is intended to =
be able to have small string optimization (SSO). This means that strings be=
low a certain size are stored internally rather than allocating memory. Thu=
s, your &quot;detach&quot; function doesn&#39;t &quot;detach&quot; somethin=
g in all cases.<br><br>Second, `basic_string` and `vector` both allocate me=
mory based on provided allocators. So... how will the user destroy it? They=
 cannot call `delete[]` on it, since it was not allocated with `new[]`. The=
 only way to destroy this object us to use the same allocator that was used=
 to allocate it, or a compatible one. Not only that, the person receiving t=
he pointer has no idea how many objects are in the array, so unless `T` has=
 a trivial destructor, you need to know how many items to destroy. And you =
need to remember to destroy them in <i>reverse</i> order.<br><br>Third, you=
r APIs are really bad. Inserting default-initialized objects shouldn&#39;t =
use radically different APIs from inserting value-initialized objects. Your=
 API also assumes that `T` is a type which can tolerate being uninitialized=
.. We shouldn&#39;t make APIs that break the C++ object model; we should mak=
e them that actually work with that model.<br><br>The goal is this:<br><br>=
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,18=
7);border-style:solid;border-width:1px"><code><div><span style=3D"color:rgb=
(0,0,0)">T </span><span style=3D"color:rgb(102,102,0)">*</span><span style=
=3D"color:rgb(0,0,0)">t </span><span style=3D"color:rgb(102,102,0)">=3D</sp=
an><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,13=
6)">new</span><span style=3D"color:rgb(0,0,0)"> T</span><span style=3D"colo=
r:rgb(102,102,0)">[</span><span style=3D"color:rgb(0,102,102)">256</span><s=
pan style=3D"color:rgb(102,102,0)">];</span><span style=3D"color:rgb(0,0,0)=
"><br>vector</span><span style=3D"color:rgb(102,102,0)">&lt;</span><span st=
yle=3D"color:rgb(0,0,0)">T</span><span style=3D"color:rgb(102,102,0)">&gt;<=
/span><span style=3D"color:rgb(0,0,0)"> tv</span><span style=3D"color:rgb(1=
02,102,0)">(</span><span style=3D"color:rgb(0,102,102)">256</span><span sty=
le=3D"color:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> </spa=
n><span style=3D"color:rgb(102,102,0)">...);</span><span style=3D"color:rgb=
(0,0,0)"><br></span></div></code></div><br>Both of these arrays should perf=
orm the same amount of initializing of their respective arrays. If `T` is t=
rivially default constructible, then both of these will be uninitialized.=
=C2=A0 If `T` has a non-trivial default constructor, then it will be called=
 256 times in both cases. Because by the rules of C++, that&#39;s what `T` =
requires in order to be a live object.<br></div></div></blockquote><div><br=
></div><div>If you only provide that, you have not solved the complete prob=
lem. Sometimes the requirements do include the ability to directly construc=
t a sequence of T objects in place within a vector, in ways that emplace do=
es not support.</div></div></div></div></blockquote></span><div><br>That is=
 a problem best solved by allowing `emplace` to construct an object in ways=
 that it does not currently support.<br><br>What in particular was a circum=
stance you were thinking of?<br></div></div></blockquote><div><br></div><di=
v>Let&#39;s say you want to move a sequence of Ts into a vector&lt;T&gt;, a=
pplying a permutation (supplied as a vector&lt;size_t&gt;) as you go, and y=
ou can&#39;t default construct Ts. You could do that like this with the pro=
posed functionality:</div><div><br></div><div>dest.reserve(src.size());</di=
v><div>for (size_t i =3D 0; i !=3D src.size(); ++i)</div><div>=C2=A0 // poi=
nter arithmetic questionable, but that&#39;s a pre-existing problem with ve=
ctor</div><div>=C2=A0 new (dest.data() + perm[i]) T(std::move(src[i]));</di=
v><div>dest.resize_already_initialized(src.size());<br></div><div><br></div=
><div>Due to the random access order of the destination, you can&#39;t do t=
his with emplace.</div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr"><div></div><span class=3D"gmail-"><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"=
gmail_quote"><div>One (slightly scary) approach would be:</div><div>1) perm=
it the user to construct objects in trailing storage of a vector/string, so=
 long as capacity is large enough, and</div><div>2) provide a resize_alread=
y_initialized(siz<wbr>e_t) member to resize the container so that those ele=
ments are part of its size, without constructing new Ts over the top of the=
m</div></div></div></div></blockquote><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div><br></div></blockquote><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div=
><div>Obviously if (1) somehow fails or throws, destroying the elements it =
created is its problem, and triggering reallocation during (1) would be bad=
..</div></div></div></div></blockquote></span><div><br>I&#39;m not sure why =
we should encourage (1) happening outside of the presence of (2). Or rather=
, I don&#39;t know why it is <i>necessary</i> to do it that way.<br><br>Can=
 you give an example? One that is actually legal C++ under the current obje=
ct model?<br></div></div><span class=3D"gmail-">

<p></p>

-- <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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3ef49ad2-3e73-4d58-872d-fab5f138e22b%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/3ef4=
9ad2-3e73-4d58-<wbr>872d-fab5f138e22b%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqkZh8zWj3sdDcPE8%2BgqyJNfZBWd_A=
j_1oFLxLfqz3JV7w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqkZh8zWj3=
sdDcPE8%2BgqyJNfZBWd_Aj_1oFLxLfqz3JV7w%40mail.gmail.com</a>.<br />

--001a1146fba2523c400545ba8dbf--

.

------=_Part_4689_1753758314.1484048622738
Content-Type: multipart/alternative;
 boundary="----=_Part_4690_736418597.1484048622738"

------=_Part_4690_736418597.1484048622738
Content-Type: text/plain; charset=UTF-8


I don't know why this required a smart butt remark when I'm obviously here
discussing what is required to do that.
But it doesn't happen any easier with you deriding me or the discussion.
Where do you get off in doing that? Do you think that assists?

On Tuesday, January 10, 2017 at 10:13:47 PM UTC+13, D. B. wrote:

> On Tue, Jan 10, 2017 at 6:57 AM, <gmis...@gmail.com <javascript:>> wrote:
>
>> But for C++17, if it was just want unintialized_resize() or data_at or
>> whatever I'd be happy. We must have this for C++20 I think, I'd ideally
>> like this function sooner even if non standard to test with.
>>
>
> You must have it? Then start coding it, and publish a write-up of your
> successful results.
>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/53615ac8-997f-47c4-970b-48cc2e1a258f%40isocpp.org.

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

<div dir=3D"ltr"><div><br></div><div>I don&#39;t know why this required a s=
mart butt remark=C2=A0when=C2=A0I&#39;m obviously here discussing=C2=A0what=
 is=C2=A0required to do that.</div><div>But it doesn&#39;t happen any easie=
r with you deriding me or the discussion. Where do you get off in doing tha=
t? Do you think that assists?<br><br>On Tuesday, January 10, 2017 at 10:13:=
47 PM UTC+13, D. B. wrote:</div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 2=
04, 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"lt=
r"><div><div class=3D"gmail_quote">On Tue, Jan 10, 2017 at 6:57 AM,  <span =
dir=3D"ltr">&lt;<a onmousedown=3D"this.href=3D&#39;javascript:&#39;;return =
true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"j=
avascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"6K3=
I7R3eBQAJ">gmis...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-=
left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: =
solid;"><div dir=3D"ltr"><span></span><div>But for C++17, if it was just wa=
nt unintialized_resize() or data_at or whatever I&#39;d be happy. We must h=
ave this for C++20 I think, I&#39;d ideally like this function sooner even =
if non standard=C2=A0to test with.</div></div></blockquote><div><br></div><=
div>You must have it? Then start coding it, and publish a write-up of your =
successful results.<br></div></div><br></div></div>
</blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/53615ac8-997f-47c4-970b-48cc2e1a258f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/53615ac8-997f-47c4-970b-48cc2e1a258f=
%40isocpp.org</a>.<br />

------=_Part_4690_736418597.1484048622738--

------=_Part_4689_1753758314.1484048622738--

.

--047d7b3a8c2c7ab5be0545bc130c
Content-Type: text/plain; charset=UTF-8

Get down from your high horse. I'm not deriding anything. It was a serious
suggestion. You keep talking about how much "I just want" these things, but
do not appear to have gathered any real evidence of how/whether they would
work. That can be (mis?)read as you wanting others to do it for you,
without having convinced them that it would be feasible or worthwhile, or
that you have begun to lay any real groundwork.

It was also not so much a comment to you specifically, but to anyone who
posts ideas here and then expects that they will just materialise from
nowhere (especially in a version of the language whose draft is already
closed).

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhEp%3Dvs0SyCYdDZxhpj%3DUwvMXQxc9euTVipFhdhC6MJq5A%40mail.gmail.com.

--047d7b3a8c2c7ab5be0545bc130c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Get down from your high horse. I&#39;m not deriding a=
nything. It was a serious suggestion. You keep talking about how much &quot=
;I just want&quot; these things, but do not appear to have gathered any rea=
l evidence of how/whether they would work. That can be (mis?)read as you wa=
nting others to do it for you, without having convinced them that it would =
be feasible or worthwhile, or that you have begun to lay any real groundwor=
k.<br><br></div>It was also not so much a comment to you specifically, but =
to anyone who posts ideas here and then expects that they will just materia=
lise from nowhere (especially in a version of the language whose draft is a=
lready closed).<br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhEp%3Dvs0SyCYdDZxhpj%3DUwvMXQxc=
9euTVipFhdhC6MJq5A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhEp%3Dv=
s0SyCYdDZxhpj%3DUwvMXQxc9euTVipFhdhC6MJq5A%40mail.gmail.com</a>.<br />

--047d7b3a8c2c7ab5be0545bc130c--

.

------=_Part_4924_104925486.1484054641740
Content-Type: multipart/alternative;
 boundary="----=_Part_4925_1635348194.1484054641740"

------=_Part_4925_1635348194.1484054641740
Content-Type: text/plain; charset=UTF-8


It's you that's on your high horse because it's you that is making the
'smart' comments!
You have no idea what I do or don't contribute towards C++ or how I
contribute so I don't see where you get off being so derisory?

And given I do contribute, I'm entitled to express what I think is
important or a must for C++ as anybody else without having to intimately
make any such proposal happen that I wish to comment on. It's ridiculous to
think otherwise. For example, everybody on the planet thinks C++ must have
modules but I can assure you everyone on the planet isn't beavering
away working on it! But they'll sure tell you we must have it! So why
should I be singled out any different? Are you going to now get on reddit
and be derisory to all those folks too?

You seem to have the attitude that because somebody isn't going to make
every effort on a subject that can't make any effort or have any
opinion. That sounds exactly like a high horse to me! So I think it's you
that needs to get off it and stop thinking everyone needs to contribute the
way you do that I don't contribute or have to breath the language because
you do. I don't. And you shouldn't be so assumptive and 'smart'. Because
that isn't.


On Wednesday, January 11, 2017 at 12:49:28 AM UTC+13, D. B. wrote:

> Get down from your high horse. I'm not deriding anything. It was a serious
> suggestion. You keep talking about how much "I just want" these things, but
> do not appear to have gathered any real evidence of how/whether they would
> work. That can be (mis?)read as you wanting others to do it for you,
> without having convinced them that it would be feasible or worthwhile, or
> that you have begun to lay any real groundwork.
>
> It was also not so much a comment to you specifically, but to anyone who
> posts ideas here and then expects that they will just materialise from
> nowhere (especially in a version of the language whose draft is already
> closed).
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5bdb4f35-695b-4941-8323-8289ba540912%40isocpp.org.

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

<div dir=3D"ltr"><div><br></div><div>It&#39;s you that&#39;s on your high h=
orse because it&#39;s you that is making the &#39;smart&#39; comments!</div=
><div>You have no idea what I do or don&#39;t=C2=A0contribute towards C++ o=
r how I contribute=C2=A0so I don&#39;t see where=C2=A0you get off being so=
=C2=A0derisory?</div><div><br></div><div>And given I do contribute, I&#39;m=
 entitled to express what I think=C2=A0is important or a must for C++ as an=
ybody else without=C2=A0having to=C2=A0intimately make=C2=A0any such=C2=A0p=
roposal happen that I wish to comment on. It&#39;s ridiculous to think othe=
rwise.=C2=A0For example, everybody on the planet thinks C++ must have modul=
es but I can assure you=C2=A0everyone on the planet isn&#39;t beavering awa=
y=C2=A0working on it! But they&#39;ll sure tell you we must have it! So why=
 should I be singled out any different? Are you going to now get on reddit =
and be derisory to all those folks too?</div><div><br></div><div>You seem t=
o have the attitude that because somebody isn&#39;t going to make every eff=
ort on a subject that can&#39;t make any effort or have any opinion.=C2=A0T=
hat sounds exactly like a high horse to me! So I think it&#39;s you that ne=
eds to get off=C2=A0it and stop thinking=C2=A0everyone=C2=A0needs to contri=
bute the way you do=C2=A0that I don&#39;t contribute=C2=A0or have to=C2=A0b=
reath the language because you do. I don&#39;t. And you shouldn&#39;t be so=
 assumptive and &#39;smart&#39;. Because that isn&#39;t.</div><div><br></di=
v><div><br>On Wednesday, January 11, 2017 at 12:49:28 AM UTC+13, D. B. wrot=
e:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8e=
x; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-wi=
dth: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>Get down from yo=
ur high horse. I&#39;m not deriding anything. It was a serious suggestion. =
You keep talking about how much &quot;I just want&quot; these things, but d=
o not appear to have gathered any real evidence of how/whether they would w=
ork. That can be (mis?)read as you wanting others to do it for you, without=
 having convinced them that it would be feasible or worthwhile, or that you=
 have begun to lay any real groundwork.<br><br></div>It was also not so muc=
h a comment to you specifically, but to anyone who posts ideas here and the=
n expects that they will just materialise from nowhere (especially in a ver=
sion of the language whose draft is already closed).<br></div>
</blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5bdb4f35-695b-4941-8323-8289ba540912%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5bdb4f35-695b-4941-8323-8289ba540912=
%40isocpp.org</a>.<br />

------=_Part_4925_1635348194.1484054641740--

------=_Part_4924_104925486.1484054641740--

.

------=_Part_5000_1768608180.1484063995766
Content-Type: multipart/alternative;
 boundary="----=_Part_5001_1929372845.1484063995766"

------=_Part_5001_1929372845.1484063995766
Content-Type: text/plain; charset=UTF-8

On Tuesday, January 10, 2017 at 1:57:29 AM UTC-5, gmis...@gmail.com wrote:
>
> On Tuesday, January 10, 2017 at 5:19:44 PM UTC+13, Nicol Bolas wrote:
>>
>> On Monday, January 9, 2017 at 8:57:39 PM UTC-5, gmis...@gmail.com wrote:
>>>
>>>
>>>>>
>>>> Several reasons.
>>>>
>>>> First, `basic_string` is intended to be able to have small string
>>>> optimization (SSO). This means that strings below a certain size are stored
>>>> internally rather than allocating memory. Thus, your "detach" function
>>>> doesn't "detach" something in all cases.
>>>>
>>>
>>> That's not a reason for doing nothing. That's just a description of how
>>> things are that doesn't forward anything. I don't know why so many replies
>>> are structured like this.
>>>
>>> Detach could allocate and copy if it must. If that fails it returns
>>> nullptr. Or uninitialized_data_at can do the allocate copy if directed,
>>> that can fail anyway so that seems the fine place to do that. We can
>>> indicate that in a parameter etc.
>>> There are ways forward here.
>>>
>>>
>>>
>>>> Second, `basic_string` and `vector` both allocate memory based on
>>>> provided allocators. So... how will the user destroy it? They cannot call
>>>> `delete[]` on it, since it was not allocated with `new[]`. The only way to
>>>> destroy this object us to use the same allocator that was used to allocate
>>>> it, or a compatible one. Not only that, the person receiving the pointer
>>>> has no idea how many objects are in the array, so unless `T` has a trivial
>>>> destructor, you need to know how many items to destroy. And you need to
>>>> remember to destroy them in *reverse* order.
>>>>
>>>> Third, your APIs are really bad. Inserting default-initialized objects
>>>> shouldn't use radically different APIs from inserting value-initialized
>>>> objects. Your API also assumes that `T` is a type which can tolerate being
>>>> uninitialized. We shouldn't make APIs that break the C++ object model; we
>>>> should make them that actually work with that model.
>>>>
>>>
>>> I said we could enable_if that and that these could be free. You seem to
>>> be ignoring that fact or didn't see it. I don't see a problem with the idea.
>>>
>>> And C++ already has plenty of 'get outs' for doing what needs to be done
>>> if it needs to be done. We should make API's that enable us to do what we
>>> need to do. You don't have to call them if you don't need what it offers.
>>> So I don't buy your argument.
>>>
>>
>> C++ has ways to do things that are illegal in some circumstances because
>> those tools also permit you to do legal things that you would not otherwise
>> be able to do. I believe that the circumstances where what you're wanting
>> to do is actually legal C++ code can be done in ways that *don't*
>> require tools that allow you to *also* do illegal things.
>>
>
> Legal and illegal are just points in time. What is today illegal can often
> be made legal depending on the will and reasoning.
> But something being illegal today in of itself isn't interesting.
>

.... I'm not sure what that has to do with anything I said. Yes, rules can
be changed. But unless and until you're *actually* proposing to change
those rules, they are what they are.

For example, a C API cannot create a non-trivial C++ object (if you want to
>> get really technical, a C API cannot begin the lifetime of a C++ object *at
>> all*, but lets pretend that trivial types can be excepted). As such, you
>> cannot legally hand the memory of a `vector<T>` to a C API to be
>> initialized *unless* `T` is trivial. Therefore, the ability to default
>> initialize a `vector<T>` is all you need to avoid the performance penalty,
>> since default initialization is a no-op.
>>
>> Your API would look like this:
>>
>> vector<T> v;
>> SomeCAPI(v.uinitialized_data_at(0, n), n);
>>
>
> yes, I'm not attached to the API, but nor do I have a problem with it. I
> just want the ability.
>
>
>>
>> My API would look like this:
>>
>> vector<T> v(n, std::default_init);
>> SomeCAPI(v.data(), v.size());
>>
>> But they would have *the same performance*: a single allocation of a
>> block of `n` objects, with no initialization of that array.
>>
>
> I'm fine with your API but it's less flexible than my API unless I miss
> understand what yours implies.
> And I feel I'm not appreciating what yours implies  Can you extend v
> without getting more unwanted initialization with your API? i.e. Is
> v.resize(10000) going to do the right thing her and not zero fill where n
> in the initial call is say 1 or 0.
>

That would be a backwards-incompatible change, so no.

But `v.resize(10000, std::default_init)` works just fine. As would
`v.insert(v.end(), 10000, std::default_init)` if you want to add 10,000
default-initialized objects to the end. As would `v.insert(v.begin(),
10000, std::default_init)`, if you want to insert 10,000
default-initialized objects at the *beginning*. As would
`v.push_back(std::default_init)`. And so forth.

See how much more flexible and `vector`-like that is?

So why use an API that is oddball and non-standard looking instead of an
>> API that looks like normal `vector` mechanisms? Your way makes using
>> "uninitialized" data look special-case, like you're cheating or something.
>> My way makes it look normal, just like you had done `new T[n]` or whatever.
>>
>
> I don't find my API that oddball but I'm not hung up on my api, I just
> want the feature of unintialized allocation.
>
> Because *it is* normal. You're not cheating; every step is 100% legal
>> C++. You're not pretending that C APIs can begin the lifetime of C++
>> objects. You're creating an array of live C++ objects and passing them
>> along to someone else who will trivially copy into them.
>>
>
> I'm not pretending that as far as I know. My API isn't asking C to
> begin life here. But I'm sure we'll work out whatever misunderstanding I or
> you have here later.
>
>
>> So why do we need an API that looks so alien to how the API currently
>> works?
>>
>
> I don't need anything alien. I just want something that gives me
> unintialized allocation.
>

That's the fundamental difference between our ideas.

I want to allow `vector` to perform default-initialization on its elements.
With my way, the `vector` still contains an array of objects, in accord
with the C++ object model; it's just that these objects may be
uninitialized objects.

You want to allow `vector` to *not construct its elements*.  With your way,
the `vector` no longer contains objects as defined by the C++ object model.

My way is about bringing the equivalent of `new T[n]` into `vector`. Your
way is about bringing *C idioms* (effectively `malloc` + casting) into
`vector`.

That's part of what I mean by "alien". You want to take some other
language's idioms and force them into our objects. I want to take our
language's *current* idioms and make them *fully available* to our objects.

When I mooted what I need, you started talking about language changes
> as a requirement to progress.
>

Strictly speaking, you could implement it as a pure library change, even
with the syntax I outlined. Overload resolution and adding new types will
allow it to work adequately. But if you make it a pure library change, then
other code can't work correctly.

For example, if I want to default-initialize the `T` in an `optional<T>`,
your way doesn't let me do that. Or if I want to default-initialize the `T`
through `make_shared<T>`, it still can't happen. Well, it can't happen
without *further* library changes. And you can keep going on and on and on.
What of user-containers; can they be default-initialized too? Now everybody
has to add changes to *their* libraries just to make this work.

Or you can make a proper language change that just handles these cases.

Now yes, my language solution still needs to have some library changes for
containers to take full advantage of it. But indirect initialization
(`emplace`, `in_place_t` construction, `make/allocate_shared/unique`, etc)
will all work without any library changes.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/69ff356a-11e5-4b3c-aaf2-f056562412d2%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, January 10, 2017 at 1:57:29 AM UTC-5, gmis...@=
gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">On Tuesday, January 10, 2017 at 5:19:44 PM UTC+13, Nicol Bolas wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-le=
ft:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left=
-style:solid"><div dir=3D"ltr">On Monday, January 9, 2017 at 8:57:39 PM UTC=
-5, <a>gmis...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left=
:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-s=
tyle:solid"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);b=
order-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div><br></d=
iv></div></blockquote><div><br>Several reasons.<br><br>First, `basic_string=
` is intended to be able to have small string optimization (SSO). This mean=
s that strings below a certain size are stored internally rather than alloc=
ating memory. Thus, your &quot;detach&quot; function doesn&#39;t &quot;deta=
ch&quot; something in all cases.<br></div></div></blockquote><div><br></div=
><div>That&#39;s not a reason for doing nothing. That&#39;s just a descript=
ion of how things are that doesn&#39;t forward anything. I don&#39;t know w=
hy so many replies are structured like this.</div><div><br></div><div>Detac=
h could allocate and copy if it must. If that fails it returns nullptr. Or=
=C2=A0uninitialized_data_at can do the allocate copy if directed, that can =
fail anyway so that seems the fine place to do that. We can indicate that i=
n a parameter etc.</div><div>There are ways forward here.</div><div><br></d=
iv><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-=
width:1px;border-left-style:solid"><div dir=3D"ltr"><div><br>Second, `basic=
_string` and `vector` both allocate memory based on provided allocators. So=
.... how will the user destroy it? They cannot call `delete[]` on it, since =
it was not allocated with `new[]`. The only way to destroy this object us t=
o use the same allocator that was used to allocate it, or a compatible one.=
 Not only that, the person receiving the pointer has no idea how many objec=
ts are in the array, so unless `T` has a trivial destructor, you need to kn=
ow how many items to destroy. And you need to remember to destroy them in <=
i>reverse</i> order.<br><br>Third, your APIs are really bad. Inserting defa=
ult-initialized objects shouldn&#39;t use radically different APIs from ins=
erting value-initialized objects. Your API also assumes that `T` is a type =
which can tolerate being uninitialized. We shouldn&#39;t make APIs that bre=
ak the C++ object model; we should make them that actually work with that m=
odel.<br></div></div></blockquote><div><br></div><div>I said we could enabl=
e_if that and that these could be free. You seem to be ignoring that fact o=
r didn&#39;t=C2=A0see it. I don&#39;t see a problem with the idea.</div><di=
v><br></div><div>And C++ already has plenty of &#39;get outs&#39; for doing=
 what needs to be done if it needs to be done. We should make API&#39;s tha=
t enable us to do what we need to do. You don&#39;t have to call them if yo=
u don&#39;t need what it offers. So I don&#39;t buy your argument.</div></d=
iv></blockquote><div><br>C++ has ways to do things that are illegal in some=
 circumstances because those tools also permit you to do legal things that =
you would not otherwise be able to do. I believe that the circumstances whe=
re what you&#39;re wanting to do is actually legal C++ code can be done in =
ways that <i>don&#39;t</i> require tools that allow you to <i>also</i> do i=
llegal things.<br></div></div></blockquote><div><br></div><div>Legal and il=
legal are just points in time. What is today illegal can often be made lega=
l depending on the will and reasoning.</div><div>But something being illega=
l today in of itself isn&#39;t interesting.</div></div></blockquote><div><b=
r>... I&#39;m not sure what that has to do with anything I said. Yes, rules=
 can be changed. But unless and until you&#39;re <i>actually</i> proposing =
to change those rules, they are what they are.<br><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-=
left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">=
<div dir=3D"ltr"><div>For example, a C API cannot create a non-trivial C++ =
object (if you want to get really technical, a C API cannot begin the lifet=
ime of a C++ object <i>at all</i>, but lets pretend that trivial types can =
be excepted). As such, you cannot legally hand the memory of a `vector&lt;T=
&gt;` to a C API to be initialized <i>unless</i> `T` is trivial. Therefore,=
 the ability to default initialize a `vector&lt;T&gt;` is all you need to a=
void the performance penalty, since default initialization is a no-op.<br><=
br>Your API would look like this:<br><br><div style=3D"border:1px solid rgb=
(187,187,187);background-color:rgb(250,250,250)"><code><div><span style=3D"=
color:rgb(0,0,0)">vector</span><span style=3D"color:rgb(102,102,0)">&lt;</s=
pan><span style=3D"color:rgb(0,0,0)">T</span><span style=3D"color:rgb(102,1=
02,0)">&gt;</span><span style=3D"color:rgb(0,0,0)"> v</span><span style=3D"=
color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br></span><=
span style=3D"color:rgb(102,0,102)">SomeCAPI</span><span style=3D"color:rgb=
(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">v</span><span style=
=3D"color:rgb(102,102,0)">.</span><span style=3D"color:rgb(0,0,0)">uinitial=
ized_data_<wbr>at</span><span style=3D"color:rgb(102,102,0)">(</span><span =
style=3D"color:rgb(0,102,102)">0</span><span style=3D"color:rgb(102,102,0)"=
>,</span><span style=3D"color:rgb(0,0,0)"> n</span><span style=3D"color:rgb=
(102,102,0)">),</span><span style=3D"color:rgb(0,0,0)"> n</span><span style=
=3D"color:rgb(102,102,0)">);</span></div></code></div></div></div></blockqu=
ote><div><br></div><div>yes, I&#39;m not attached to the API, but nor do I =
have a problem with it. I just want the ability.</div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-lef=
t:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-=
style:solid"><div dir=3D"ltr"><div><br>My API would look like this:<br><br>=
<div style=3D"border:1px solid rgb(187,187,187);background-color:rgb(250,25=
0,250)"><code><div><span style=3D"color:rgb(0,0,0)">vector</span><span styl=
e=3D"color:rgb(102,102,0)">&lt;</span><span style=3D"color:rgb(0,0,0)">T</s=
pan><span style=3D"color:rgb(102,102,0)">&gt;</span><span style=3D"color:rg=
b(0,0,0)"> v</span><span style=3D"color:rgb(102,102,0)">(</span><span style=
=3D"color:rgb(0,0,0)">n</span><span style=3D"color:rgb(102,102,0)">,</span>=
<span style=3D"color:rgb(0,0,0)"> std</span><span style=3D"color:rgb(102,10=
2,0)">::</span><span style=3D"color:rgb(0,0,0)">default_init</span><span st=
yle=3D"color:rgb(102,102,0)">);</span><span style=3D"color:rgb(0,0,0)"><br>=
</span><span style=3D"color:rgb(102,0,102)">SomeCAPI</span><span style=3D"c=
olor:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">v</span><span=
 style=3D"color:rgb(102,102,0)">.</span><span style=3D"color:rgb(0,0,0)">da=
ta</span><span style=3D"color:rgb(102,102,0)">(),</span><span style=3D"colo=
r:rgb(0,0,0)"> v</span><span style=3D"color:rgb(102,102,0)">.</span><span s=
tyle=3D"color:rgb(0,0,0)">size</span><span style=3D"color:rgb(102,102,0)">(=
));</span></div></code></div><br>But they would have <i>the same performanc=
e</i>: a single allocation of a block of `n` objects, with no initializatio=
n of that array.<br></div></div></blockquote><div><br></div><div>I&#39;m fi=
ne with=C2=A0your API=C2=A0but it&#39;s less flexible than my=C2=A0API unle=
ss I miss understand what=C2=A0yours implies.</div><div>And I feel I&#39;m =
not appreciating=C2=A0what yours implies=C2=A0 Can you extend v without get=
ting more unwanted initialization with your API? i.e. Is v.resize(10000) go=
ing to do the right thing her and not zero fill where n in the initial call=
 is say 1 or 0.</div></div></blockquote><div><br>That would be a backwards-=
incompatible change, so no.<br><br>But `v.resize(10000, std::default_init)`=
 works just fine. As would `v.insert(v.end(), 10000, std::default_init)` if=
 you want to add 10,000 default-initialized objects to the end. As would `v=
..insert(v.begin(), 10000, std::default_init)`, if you want to insert 10,000=
 default-initialized objects at the <i>beginning</i>. As would `v.push_back=
(std::default_init)`. And so forth.<br><br>See how much more flexible and `=
vector`-like that is?<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-=
left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div>So why use an=
 API that is oddball and non-standard looking instead of an API that looks =
like normal `vector` mechanisms? Your way makes using &quot;uninitialized&q=
uot; data look special-case, like you&#39;re cheating or something. My way =
makes it look normal, just like you had done `new T[n]` or whatever.<br></d=
iv></div></blockquote><div><br></div><div>I don&#39;t find my API that=C2=
=A0oddball but I&#39;m not hung up on my api, I just want the feature of un=
intialized allocation.=C2=A0</div><div><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-colo=
r:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir=
=3D"ltr"><div>Because <i>it is</i> normal. You&#39;re not cheating; every s=
tep is 100% legal C++. You&#39;re not pretending that C APIs can begin the =
lifetime of C++ objects. You&#39;re creating an array of live C++ objects a=
nd passing them along to someone else who will trivially copy into them.<br=
></div></div></blockquote><div><br></div><div>I&#39;m not pretending that a=
s far as I know. My API isn&#39;t asking C to begin=C2=A0life here. But I&#=
39;m sure we&#39;ll work out whatever misunderstanding I or you have here l=
ater.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bo=
rder-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div>So why d=
o we need an API that looks so alien to how the API currently works?<br></d=
iv></div></blockquote><div>=C2=A0</div><div>I don&#39;t need anything=C2=A0=
alien. I just want something that gives me unintialized allocation.</div></=
div></blockquote><div><br>That&#39;s the fundamental difference between our=
 ideas.<br><br>I want to allow `vector` to perform default-initialization o=
n its elements. With my way, the `vector` still contains an array of object=
s, in accord=20
with the C++ object model; it&#39;s just that these objects may be=20
uninitialized objects.<br><br>You want to allow `vector` to <i>not construc=
t its elements</i>.=C2=A0 With your way, the `vector` no longer contains ob=
jects as defined by the C++ object model.<br><br>My way is about bringing t=
he equivalent of `new T[n]` into `vector`. Your way is about bringing <i>C =
idioms</i> (effectively `malloc` + casting) into `vector`.<br><br>That&#39;=
s part of what I mean by &quot;alien&quot;. You want to take some other lan=
guage&#39;s idioms and force them into our objects. I want to take our lang=
uage&#39;s <i>current</i> idioms and make them <i>fully available</i> to ou=
r objects.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div>When I mooted what I need, you started talking about langua=
ge changes as=C2=A0a=C2=A0requirement to progress.</div></div></blockquote>=
<div><br>Strictly speaking, you could implement it as a pure library change=
, even with the syntax I outlined. Overload resolution and adding new types=
 will allow it to work adequately. But if you make it a pure library change=
, then other code can&#39;t work correctly.<br><br>For example, if I want t=
o default-initialize the `T` in an `optional&lt;T&gt;`, your way doesn&#39;=
t let me do that. Or if I want to default-initialize the `T` through `make_=
shared&lt;T&gt;`, it still can&#39;t happen. Well, it can&#39;t happen with=
out <i>further</i> library changes. And you can keep going on and on and on=
.. What of user-containers; can they be default-initialized too? Now everybo=
dy has to add changes to <i>their</i> libraries just to make this work.<br>=
<br>Or you can make a proper language change that just handles these cases.=
<br><br>Now yes, my language solution still needs to have some library chan=
ges for containers to take full advantage of it. But indirect initializatio=
n (`emplace`, `in_place_t` construction, `make/allocate_shared/unique`, etc=
) will all work without any library changes.</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/69ff356a-11e5-4b3c-aaf2-f056562412d2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/69ff356a-11e5-4b3c-aaf2-f056562412d2=
%40isocpp.org</a>.<br />

------=_Part_5001_1929372845.1484063995766--

------=_Part_5000_1768608180.1484063995766--

.

------=_Part_4937_1013638511.1484064849130
Content-Type: multipart/alternative;
 boundary="----=_Part_4938_519149884.1484064849131"

------=_Part_4938_519149884.1484064849131
Content-Type: text/plain; charset=UTF-8

On Tuesday, January 10, 2017 at 8:24:01 AM UTC-5, gmis...@gmail.com wrote:
>
>
> It's you that's on your high horse because it's you that is making the
> 'smart' comments!
> You have no idea what I do or don't contribute towards C++ or how I
> contribute so I don't see where you get off being so derisory?
>
> And given I do contribute, I'm entitled to express what I think is
> important or a must for C++ as anybody else without having to intimately
> make any such proposal happen that I wish to comment on. It's ridiculous to
> think otherwise.
>

You have the right to express that you feel something is important. That's
fine, and I think D. B. was kinda out of line in trying to upbraid you for
it.

However, you do need to make a distinction between "I believe X is
critical" and "X is critical". You can argue that something is crucial to
C++. But it'd be a lot easier of an argument to make if you have other
people around who agree with you.

When I argue that unified call syntax, or something like it, is a vital
feature for future C++, I can at least point to the disappointment other
people have in the lack of this feature in C++17 as evidence for it. Thus
far, the only evidence you have that this is a critical C++ feature is...
your word.

Now, I do think being able to default-initialize things really is
important. But that doesn't mean we should accept a half-solution (let
alone one that's as laced with C-idioms as yours) when we can get a whole
one.

For example, everybody on the planet thinks C++ must have modules but I can
> assure you everyone on the planet isn't beavering away working on it! But
> they'll sure tell you we must have it! So why should I be singled out any
> different? Are you going to now get on reddit and be derisory to all those
> folks too?
>

There are many differences between modules and your proposal:

1: Modules are a compiler feature. A very, *very* complex one. Implementing
it requires deep knowledge of a complier. Your idea is a pure-library
change. Implementing it requires being a C++ programmer.

2: Modules are actively being implemented by 2 major compiler vendors. Your
idea is actively being implemented by... nobody.

So suggesting that you provide a proof-of-concept implementation is not
unreasonable.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dec40ed1-fd11-47c3-94bb-1a244628e4e4%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, January 10, 2017 at 8:24:01 AM UTC-5, gmis...@=
gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div><br></div><div>It&#39;s you that&#39;s on your high horse because i=
t&#39;s you that is making the &#39;smart&#39; comments!</div><div>You have=
 no idea what I do or don&#39;t=C2=A0contribute towards C++ or how I contri=
bute=C2=A0so I don&#39;t see where=C2=A0you get off being so=C2=A0derisory?=
</div><div><br></div><div>And given I do contribute, I&#39;m entitled to ex=
press what I think=C2=A0is important or a must for C++ as anybody else with=
out=C2=A0having to=C2=A0intimately make=C2=A0any such=C2=A0proposal happen =
that I wish to comment on. It&#39;s ridiculous to think otherwise.</div></d=
iv></blockquote><div><br>You have the right to express that you feel someth=
ing is important. That&#39;s fine, and I think D. B. was kinda out of line =
in trying to upbraid you for it.<br><br>However, you do need to make a dist=
inction between &quot;I believe X is critical&quot; and &quot;X is critical=
&quot;. You can argue that something is crucial to C++. But it&#39;d be a l=
ot easier of an argument to make if you have other people around who agree =
with you.<br><br>When I argue that unified call syntax, or something like i=
t, is a vital feature for future C++, I can at least point to the disappoin=
tment other people have in the lack of this feature in C++17 as evidence fo=
r it. Thus far, the only evidence you have that this is a critical C++ feat=
ure is... your word.<br><br>Now, I do think being able to default-initializ=
e things really is important. But that doesn&#39;t mean we should accept a =
half-solution (let alone one that&#39;s as laced with C-idioms as yours) wh=
en we can get a whole one.<br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div>For example, everybody on the planet thinks=
 C++ must have modules but I can assure you=C2=A0everyone on the planet isn=
&#39;t beavering away=C2=A0working on it! But they&#39;ll sure tell you we =
must have it! So why should I be singled out any different? Are you going t=
o now get on reddit and be derisory to all those folks too?</div></div></bl=
ockquote><div><br>There are many differences between modules and your propo=
sal:<br><br>1: Modules are a compiler feature. A very, <i>very</i> complex =
one. Implementing it requires deep knowledge of a complier. Your idea is a =
pure-library change. Implementing it requires being a C++ programmer.<br><b=
r>2: Modules are actively being implemented by 2 major compiler vendors. Yo=
ur idea is actively being implemented by... nobody.<br><br>So suggesting th=
at you provide a proof-of-concept implementation is not unreasonable.<br></=
div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/dec40ed1-fd11-47c3-94bb-1a244628e4e4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dec40ed1-fd11-47c3-94bb-1a244628e4e4=
%40isocpp.org</a>.<br />

------=_Part_4938_519149884.1484064849131--

------=_Part_4937_1013638511.1484064849130--

.

------=_Part_6048_1713038289.1484128269048
Content-Type: multipart/alternative;
 boundary="----=_Part_6049_426864521.1484128269048"

------=_Part_6049_426864521.1484128269048
Content-Type: text/plain; charset=UTF-8



On Wednesday, January 11, 2017 at 5:14:09 AM UTC+13, Nicol Bolas wrote:
>
> On Tuesday, January 10, 2017 at 8:24:01 AM UTC-5, gmis...@gmail.com wrote:
>>
>>
>> It's you that's on your high horse because it's you that is making the
>> 'smart' comments!
>> You have no idea what I do or don't contribute towards C++ or how I
>> contribute so I don't see where you get off being so derisory?
>>
>> And given I do contribute, I'm entitled to express what I think is
>> important or a must for C++ as anybody else without having to intimately
>> make any such proposal happen that I wish to comment on. It's ridiculous to
>> think otherwise.
>>
>
> You have the right to express that you feel something is important. That's
> fine, and I think D. B. was kinda out of line in trying to upbraid you for
> it.
>
>
Totally. On both accounts.


> However, you do need to make a distinction between "I believe X is
> critical" and "X is critical". You can argue that something is crucial to
> C++. But it'd be a lot easier of an argument to make if you have other
> people around who agree with you.
>

I agree but I'm not some special offender here so why do I need reminding
of this? Maybe you meant to post this to the 'total retardation' guy?

And precisely because there is a one word difference between "we must" and
"I believe we must" is why I think we need to stop reminding people
generally of this every 5 minutes unless their tone is way out of
order. And mine wasn't. It just distracts from the technical issues.

 DB was just doing that just because he's annoyed I haven't presented a
proposal that he feels is a detailed to his requirements. That's the real
issue so lets talk about that. He needs to get over his viewpoint because
he doesn't control how I spend my time.

For the support you mention, I have support for the base of my suggestion:
avoiding excess initialization; you and Richard and your thread you
kindly linked show that support so I'm not sure what support you are
referring to here? Yes we were debating what was best approach for such a
proposal and you informed me of yours but that's the point of this
forum. So I don't see what problem there was here until DB went out of his
way to make a post that was nothing but derisive. So perhaps your reply
should have been to him and not me. But maybe he wouldn't do that if he was
relieved of some ideas so I'll address that.

We really need to weed this forum of the mind set that people must write a
detailed proposal before they can propose or suggest anything on this
forum. Or this will keep happening. Sure we would like detailed proposals,
but that's a wish not a requirement. So if an idea isn't baked, the
reward for that will be it's failure to launch. Let that be enough.
People will propose whatever they are capable/comfortable/or bothered to
propose anyway. People should assist such "proposals" forward where we they
have a mind to and if they don't because they think it's not baked
enough then they should ignore it.

We don't need to be carping at every OP because we feel they haven't done
enough. We don't know their time or ability constraints and being demanding
on them that way is no different to them being demanding on us is it? We
just need to accept ideas the way they come and assist them as far as we
are capable of being productive in that; and then stop. Or else this forum
will read like a moan fest of people on their high horses which it at times
often does. And that's where I think DB crossed over.


>
> When I argue that unified call syntax, or something like it, is a vital
> feature for future C++, I can at least point to the disappointment other
> people have in the lack of this feature in C++17 as evidence for it. Thus
> far, the only evidence you have that this is a critical C++ feature is...
> your word.
>
> Now, I do think being able to default-initialize things really is
> important. But that doesn't mean we should accept a half-solution (let
> alone one that's as laced with C-idioms as yours) when we can get a whole
> one.
>
> For example, everybody on the planet thinks C++ must have modules but I
>> can assure you everyone on the planet isn't beavering away working on it!
>> But they'll sure tell you we must have it! So why should I be singled out
>> any different? Are you going to now get on reddit and be derisory to all
>> those folks too?
>>
>
> There are many differences between modules and your proposal:
>
> 1: Modules are a compiler feature. A very, *very* complex one.
> Implementing it requires deep knowledge of a complier. Your idea is a
> pure-library change. Implementing it requires being a C++ programmer.
>
> 2: Modules are actively being implemented by 2 major compiler vendors.
> Your idea is actively being implemented by... nobody.
>
> So suggesting that you provide a proof-of-concept implementation is not
> unreasonable.
>

This misses the point. There's a time and place for proof of concept. But
demanding proof of concept implementation just so you don't have to think
too hard about it until then shouldn't be the game. Just don't think about
now it if that's how you or anyone (DB) feels, that's cool. I shouldn't
need to go hacking a C and C++ memory allocator to prove it's possible for
the former to be able to able to de-allocate for the latter - at least for
types that don't require destruction - before I can suggest it
might be possible or a good idea to the people who actually write these
things and hear what they have to say.

They have better existing knowledge and access to the tools and the code
bases where they can test these ideas better than I can and they have a
much more vested interest in getting the performance win out of that than
me. Plus if the idea really has merit, they may get paid for it.

So though you say I have a right to my suggestion, that right isn't worth
much if I must have a proof of concept first for my suggestions before I
can make them. I don't accept it needs to be a requirement for discussion.
Yes it's always nice to have though.

Complexity shouldn't be a factor in allowing an opinion either because
complexity is relative to the experience of the people posting and
reading and it leads back to randomly smashing people for incompleteness
again if we get tied up in that. It's impossible to be even handed in its
application anyway.

The recent enum cast proposal is a good example. Will that proposal look at
it's end how it was proposed originally? I doubt it. I suspect it will not
involve std::optional in the final result at all! But it might. My
proposal can easily evolve the same way. So why am I getting flack and not
them? The complexity is even less there depending on how far you go.

And I think the enum cast proposal is a great and has total merit so I've
assisted with that positively too, so that's another reason why we
shouldn't accept derisory attacks because it makes people not want to
bother anywhere. People should just assist with what's presented and
help complete the incomplete if they want to, or stay clear.

We must get this forum to a point where we accept casual proposals or
proposal related comments without insisting investment beyond what the
OP wants to make. If a proposal fails because for lack of implementation so
be it. It's better than arbitrary moaning at an OP so they don't even
engage at all and it fails earlier with less even to take forward by
someone else. We need to change our expectations.

This forum is a "proposals" site and wg21 site is the proposal site. Lets
set expectations to match that reality. We need to let
contributors contribute and just be happy that they are contributing. It
doesn't mean you can't challenge a bad idea or offer a better way, but just
stop moaning something isn't baked enough to your liking. Just help in the
baking which is what community is supposed to be about or stay back. That's
my view. I hope the isocpp site operators will put some wording on the site
to assist this reality being acknowledged so it stops this repetitive cycle.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4f82e0dd-76bb-472f-9bd3-2d63deda0c0c%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Wednesday, January 11, 2017 at 5:14:09 AM UTC+1=
3, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px=
 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); b=
order-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">On Tuesd=
ay, January 10, 2017 at 8:24:01 AM UTC-5, <a>gmis...@gmail.com</a> wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding=
-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; =
border-left-style: solid;"><div dir=3D"ltr"><div><br></div><div>It&#39;s yo=
u that&#39;s on your high horse because it&#39;s you that is making the &#3=
9;smart&#39; comments!</div><div>You have no idea what I do or don&#39;t=C2=
=A0contribute towards C++ or how I contribute=C2=A0so I don&#39;t see where=
=C2=A0you get off being so=C2=A0derisory?</div><div><br></div><div>And give=
n I do contribute, I&#39;m entitled to express what I think=C2=A0is importa=
nt or a must for C++ as anybody else without=C2=A0having to=C2=A0intimately=
 make=C2=A0any such=C2=A0proposal happen that I wish to comment on. It&#39;=
s ridiculous to think otherwise.</div></div></blockquote><div><br>You have =
the right to express that you feel something is important. That&#39;s fine,=
 and I think D. B. was kinda out of line in trying to upbraid you for it.<b=
r><br></div></div></blockquote><div><br></div><div>Totally. On both account=
s.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204=
); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div=
>However, you do need to make a distinction between &quot;I believe X is cr=
itical&quot; and &quot;X is critical&quot;. You can argue that something is=
 crucial to C++. But it&#39;d be a lot easier of an argument to make if you=
 have other people around who agree with you.<br></div></div></blockquote><=
div><br></div><div><div>I agree but I&#39;m not some=C2=A0special offender =
here=C2=A0so why do I need reminding of this?=C2=A0Maybe you meant to post =
this to the &#39;total retardation&#39; guy?</div><div><br></div><div>And p=
recisely because there is a one word difference between &quot;we=C2=A0must&=
quot;=C2=A0and &quot;I believe we must&quot;=C2=A0is why I think we=C2=A0ne=
ed to=C2=A0stop reminding people generally of this=C2=A0every 5 minutes unl=
ess their tone is way out of order.=C2=A0And mine wasn&#39;t. It=C2=A0just=
=C2=A0distracts from the technical issues.</div><div><br></div><div>=C2=A0D=
B=C2=A0was just doing that just because he&#39;s annoyed=C2=A0I haven&#39;t=
 presented=C2=A0a proposal that he feels is a detailed to his requirements.=
 That&#39;s the real issue so lets talk about that.=C2=A0He needs to get ov=
er=C2=A0his viewpoint because he doesn&#39;t control how I spend my time.</=
div><div><br></div><div>For the=C2=A0support you mention, I=C2=A0have suppo=
rt for=C2=A0the base of=C2=A0my suggestion: avoiding excess initialization;=
=C2=A0you and Richard=C2=A0and your thread you kindly=C2=A0linked show=C2=
=A0that=C2=A0support so I&#39;m not sure what support you are referring to =
here?=C2=A0Yes we were debating=C2=A0what was best=C2=A0approach for=C2=A0s=
uch a proposal=C2=A0and you informed me of yours but that&#39;s the point o=
f this forum.=C2=A0So=C2=A0I don&#39;t see what=C2=A0problem=C2=A0there was=
=C2=A0here until DB went out of his way to make a post that was nothing but=
=C2=A0derisive.=C2=A0So perhaps your reply should have been to him and not =
me. But maybe he wouldn&#39;t do that if he was relieved of some ideas so I=
&#39;ll address that.</div></div><div><br></div><div>We really need to weed=
 this forum of the mind set that=C2=A0people=C2=A0must write a detailed pro=
posal before they can propose or=C2=A0suggest=C2=A0anything on this forum. =
Or this will keep happening.=C2=A0Sure we would like detailed proposals, bu=
t that&#39;s a=C2=A0wish not a requirement.=C2=A0So=C2=A0if an idea isn&#39=
;t baked, the reward=C2=A0for that will be it&#39;s failure to launch. Let =
that be enough. People=C2=A0will propose whatever they are=C2=A0capable/com=
fortable/or bothered to propose=C2=A0anyway.=C2=A0People should=C2=A0assist=
 such &quot;proposals&quot; forward where=C2=A0we=C2=A0they have a mind to =
and=C2=A0if=C2=A0they don&#39;t because=C2=A0they think it&#39;s not=C2=A0b=
aked enough=C2=A0then they should ignore it.</div><div><br></div><div>We do=
n&#39;t need to be carping at every OP because we feel they haven&#39;t don=
e enough. We don&#39;t know=C2=A0their time=C2=A0or ability=C2=A0constraint=
s and being demanding on them that way is no different to them being demand=
ing on us is it?=C2=A0We just need to accept ideas the way=C2=A0they come a=
nd assist=C2=A0them as far as we are capable of being productive in that; a=
nd then stop. Or else this forum will read like a moan fest of people on th=
eir high horses which it at times often does. And that&#39;s where I think =
DB crossed over.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb=
(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div di=
r=3D"ltr"><div><br>When I argue that unified call syntax, or something like=
 it, is a vital feature for future C++, I can at least point to the disappo=
intment other people have in the lack of this feature in C++17 as evidence =
for it. Thus far, the only evidence you have that this is a critical C++ fe=
ature is... your word.<br><br>Now, I do think being able to default-initial=
ize things really is important. But that doesn&#39;t mean we should accept =
a half-solution (let alone one that&#39;s as laced with C-idioms as yours) =
when we can get a whole one.<br><br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: =
rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div=
 dir=3D"ltr"><div>For example, everybody on the planet thinks C++ must have=
 modules but I can assure you=C2=A0everyone on the planet isn&#39;t beaveri=
ng away=C2=A0working on it! But they&#39;ll sure tell you we must have it! =
So why should I be singled out any different? Are you going to now get on r=
eddit and be derisory to all those folks too?</div></div></blockquote><div>=
<br>There are many differences between modules and your proposal:<br><br>1:=
 Modules are a compiler feature. A very, <i>very</i> complex one. Implement=
ing it requires deep knowledge of a complier. Your idea is a pure-library c=
hange. Implementing it requires being a C++ programmer.<br><br>2: Modules a=
re actively being implemented by 2 major compiler vendors. Your idea is act=
ively being implemented by... nobody.<br><br>So suggesting that you provide=
 a proof-of-concept implementation is not unreasonable.<br></div></div></bl=
ockquote><div><br></div><div>This=C2=A0misses the point. There&#39;s a time=
 and place for=C2=A0proof of concept.=C2=A0But demanding=C2=A0proof=C2=A0of=
=C2=A0concept implementation=C2=A0just so you don&#39;t=C2=A0have to think =
too hard about it until=C2=A0then=C2=A0shouldn&#39;t be=C2=A0the game. Just=
 don&#39;t think about now it if that&#39;s how you or anyone (DB) feels, t=
hat&#39;s cool.=C2=A0I shouldn&#39;t need to go hacking a C and C++ memory =
allocator to prove it&#39;s possible for the former to be able to able to d=
e-allocate=C2=A0for the=C2=A0latter -=C2=A0at least=C2=A0for types that don=
&#39;t require destruction=C2=A0- before=C2=A0I can suggest it might=C2=A0b=
e=C2=A0possible or=C2=A0a=C2=A0good=C2=A0idea=C2=A0to the=C2=A0people who a=
ctually write these things and=C2=A0hear what they have to say.</div><div><=
br></div><div>They have=C2=A0better existing knowledge and access to the to=
ols and the code bases where=C2=A0they=C2=A0can test these ideas=C2=A0bette=
r than=C2=A0I can and=C2=A0they have a much more vested interest in getting=
=C2=A0the performance win out of that than me. Plus if the idea really has =
merit, they may get paid for it.</div><div><br></div><div>So=C2=A0though=C2=
=A0you=C2=A0say I have a right to my suggestion,=C2=A0that right isn&#39;t =
worth much if I=C2=A0must have=C2=A0a proof of concept=C2=A0first=C2=A0for =
my suggestions before=C2=A0I can make them. I don&#39;t=C2=A0accept it need=
s to be a requirement for discussion. Yes it&#39;s always nice to have thou=
gh.</div><div><br></div><div>Complexity shouldn&#39;t be a factor in allowi=
ng an opinion either=C2=A0because complexity is relative to the experience =
of the people posting and reading=C2=A0and it leads back to randomly smashi=
ng people for incompleteness again if we get tied up in that. It&#39;s impo=
ssible to be=C2=A0even handed in=C2=A0its application=C2=A0anyway.</div><di=
v><br></div><div>The recent enum cast proposal is a good example.=C2=A0Will=
=C2=A0that proposal=C2=A0look at it&#39;s end how=C2=A0it=C2=A0was proposed=
 originally? I doubt it. I suspect it will not involve std::optional=C2=A0i=
n the=C2=A0final result at all! But it might.=C2=A0My proposal=C2=A0can=C2=
=A0easily=C2=A0evolve the=C2=A0same way. So why am I getting flack and not =
them? The complexity is even less there depending on how far you go.</div><=
div><br></div><div>And I think the enum cast proposal is a great=C2=A0and h=
as total merit so I&#39;ve assisted with=C2=A0that positively too, so=C2=A0=
that&#39;s another reason why we shouldn&#39;t=C2=A0accept derisory attacks=
 because it makes=C2=A0people not want to bother anywhere. People should ju=
st assist with what&#39;s presented and help=C2=A0complete the incomplete i=
f they want to, or stay clear.</div><div><br></div><div>We=C2=A0must=C2=A0g=
et this forum to a point where we accept=C2=A0casual proposals or proposal =
related comments without=C2=A0insisting investment beyond what the OP=C2=A0=
wants=C2=A0to make. If a proposal fails because=C2=A0for lack of implementa=
tion=C2=A0so be it.=C2=A0It&#39;s better than=C2=A0arbitrary moaning at an =
OP so they don&#39;t even engage at all and it fails earlier=C2=A0with less=
 even to take forward by someone else. We=C2=A0need to change our expectati=
ons.</div><div><br></div><div>This=C2=A0forum=C2=A0is a &quot;proposals&quo=
t; site and wg21 site is the proposal site.=C2=A0Lets set=C2=A0expectations=
 to match=C2=A0that reality. We need to=C2=A0let contributors=C2=A0contribu=
te and just be happy that they are contributing. It doesn&#39;t mean you ca=
n&#39;t=C2=A0challenge=C2=A0a bad idea or offer a better way, but just stop=
 moaning something isn&#39;t baked enough to your liking. Just help in the =
baking which is what community is supposed to be about or stay back. That&#=
39;s my view. I hope the isocpp site operators will put some wording on the=
 site to assist this reality being acknowledged=C2=A0so it=C2=A0stops this =
repetitive cycle.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4f82e0dd-76bb-472f-9bd3-2d63deda0c0c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4f82e0dd-76bb-472f-9bd3-2d63deda0c0c=
%40isocpp.org</a>.<br />

------=_Part_6049_426864521.1484128269048--

------=_Part_6048_1713038289.1484128269048--

.

On 2017-01-11 04:51, gmisocpp@gmail.com wrote:
> I shouldn't need to go hacking a C and C++ memory allocator to prove
> it's possible for the former to be able to able to de-allocate for
> the latter

Um... good luck with that. Given that, last I knew, it was still
possible to have multiple versions of the C runtime - with incompatible
allocators - participating in a process, I doubt you're going to have
much luck getting them all to play nice by introducing the C++ allocator
to the mix. Never mind that some programs may be using custom allocators.

There's a very good reason why transfer of memory ownership almost
always (at least in code that isn't broken by design) involves also
telling the receiver how to release the memory.

That said, if you want to propose a mechanism that *includes* getting a
pointer to a function that can free your "detached" memory, you might
have better luck...

> So though you say I have a right to my suggestion, that right isn't worth=
=20
> much if I must have a proof of concept first for my suggestions before I=
=20
> can make them. I don't accept it needs to be a requirement for discussion=
..=20
> Yes it's always nice to have though.

I think you might be reading too much into this. You are making a claim.
Others are disbelieving your claim. The point being made is that just
repeating yourself over and over is not persuasive. Otherwise, all we
have, on either side, is opinions, and I am just as welcome to mine as
you are to yours.

Also... *nothing* is stopping you from moving ahead with your proposal
anyway. Maybe the committee will think it's a fabulous idea and move
forward with it anyway. Maybe they'll have the same reaction:
unconvinced without further evidence. Very little=C2=B9 that happens on thi=
s
forum reflects how you *must* proceed. Rather, it serves as an
approximation of how the committee is *likely* to respond to a proposal.
Ignore or abide by that at your own risk.

(=C2=B9 Comments made by committee members are of course not to be set asid=
e
lightly, as they will almost certainly happen in actual committee also.)

> The recent enum cast proposal is a good example [...] why am I
> getting flack and not them?

I would disagree with the claim that Maciej is not getting flack :-).

> People should just assist with what's presented and help complete the
> incomplete if they want to, or stay clear.

Here, I am not sure I agree. There is a cost to dealing with bad
proposals, especially by the time they get to an actual committee
meeting. Allowing a bad proposal to get that far can end up wasting a
lot more time than if it was killed off early.

I also am not convinced that allowing a terrible proposal to make it all
the way to committee isn't doing the *proposer* a disservice, as well.
If I have an idea that is really terrible, I want to know that people
feel that way. At least so I'm prepared for it at committee, but also so
that maybe I'm not wasting time on a proposal that has no chance of success=
..

--=20
Matthew

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/587663E0.9050800%40gmail.com.

.

--001a113cbc0c9d4d260545d9bf15
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 12, 2017 at 5:57 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2017-01-11 04:51, gmisocpp@gmail.com wrote:
> > I shouldn't need to go hacking a C and C++ memory allocator to prove
> > it's possible for the former to be able to able to de-allocate for
> > the latter
>
> Um... good luck with that. Given that, last I knew, it was still
> possible to have multiple versions of the C runtime - with incompatible
> allocators - participating in a process, I doubt you're going to have
> much luck getting them all to play nice by introducing the C++ allocator
> to the mix. Never mind that some programs may be using custom allocators.
>
> There's a very good reason why transfer of memory ownership almost
> always (at least in code that isn't broken by design) involves also
> telling the receiver how to release the memory.
>
> That said, if you want to propose a mechanism that *includes* getting a
> pointer to a function that can free your "detached" memory, you might
> have better luck...
>
> > So though you say I have a right to my suggestion, that right isn't wor=
th
> > much if I must have a proof of concept first for my suggestions before =
I
> > can make them. I don't accept it needs to be a requirement for
> discussion.
> > Yes it's always nice to have though.
>
> I think you might be reading too much into this. You are making a claim.
> Others are disbelieving your claim. The point being made is that just
> repeating yourself over and over is not persuasive. Otherwise, all we
> have, on either side, is opinions, and I am just as welcome to mine as
> you are to yours.
>

Nobody is disbelieving my claim, The emphasis of my posts are about two
things: 1) uninitialized allocation which there is complete agreement
nearly on the need for and 2) how one should be able to present that
proposal/idea without facing derision.

If you are talking about some technical claim where there is disbelief,
you might be focusing on the allocator part, but if you look at my comments
to Nicol, I made it explicitly clear that's not a key aspect of my
proposal.  So there is no disagreement there.

To save you looking, I was saying that C/C++ sharing a de-allocator at
least for pods could be of mutual gain and could be a 'nice to have' thing
that is worthy of consideration by the Committee but I have no hope in hell
of doing that myself. More to the point I should be able to ask those in
the know about that getting unhelpful responses to the question though.

So *now* at the risk of repeating myself...

What I am saying is:
It should be able to "propose" something notionally like I think we need
'uninitialized allocation now' how about this...'

And get back responses like this:
'yes that seems possible but it will be hard because of Y....' (which your
comment said re:allocators) OR
'no because Y seems to be technically un-achievable because of Z'.

Instead of this:
'no it can't be done because we don't allow that today (no further
commentary)'
'no I don't think that's possible, give me a proof of implementation that
shows that it is (no commentary)'
'you're idea is complete. don't come back until you have proof it can be
done.' (especially this)
'you are being demanding go away'

The former set of replies takes us forward (even to a meaningful halt) and
is encouraging.
The latter is utterly pointless.

People will come here to see if their assertions make sense. They don't
want to be told that they can't make these assertions without having to
already know the answer (i.e. have proof of concept already), as if they
were that sure they'd not need to post here at all and they'd just make
contact with wg21 directly.


>
> Also... *nothing* is stopping you from moving ahead with your proposal
> anyway. Maybe the committee will think it's a fabulous idea and move
> forward with it anyway. Maybe they'll have the same reaction:
> unconvinced without further evidence. Very little=C2=B9 that happens on t=
his
> forum reflects how you *must* proceed. Rather, it serves as an
> approximation of how the committee is *likely* to respond to a proposal.
> Ignore or abide by that at your own risk.
>

No, nothing is stopping anybody, but we should we encourage discouragement?


>
> (=C2=B9 Comments made by committee members are of course not to be set as=
ide
> lightly, as they will almost certainly happen in actual committee also.)
>
> > The recent enum cast proposal is a good example [...] why am I
> > getting flack and not them?
>
> I would disagree with the claim that Maciej is not getting flack :-).
>
> > People should just assist with what's presented and help complete the
> > incomplete if they want to, or stay clear.
>
> Here, I am not sure I agree. There is a cost to dealing with bad
> proposals, especially by the time they get to an actual committee
> meeting. Allowing a bad proposal to get that far can end up wasting a
> lot more time than if it was killed off early.
>

Nobody needs waste their time. If someone can't move a "proposal' forward,
say nothing.


> I also am not convinced that allowing a terrible proposal to make it all
> the way to committee isn't doing the *proposer* a disservice, as well.
> If I have an idea that is really terrible, I want to know that people
> feel that way. At least so I'm prepared for it at committee, but also so
> that maybe I'm not wasting time on a proposal that has no chance of
> success.
>


That's fine, I'm not arguing you can't challenge a proposal, I'm trying to
alter how the challenges come so that people aim to focus on the essence of
an idea, incomplete as it maybe, expecting that it will need to grow and
morph a bit, and that's what they are assisting with, not just take
something as it is and rip it up or get derisory each time. Encourage the
essence of the idea.

The essence of my proposal was good: uninitialized allocation. As it turns
out boost has that feature I want already so there's no doubt it's good.
*And we were progressing to that point here until I got derision because
someone was upset about incompleteness.*

*If I'd have gone away and spent ages coming up with what boost already
did, I'd have wasted my time as far as I am concerned.* So we need to let
incomplete proposals roll without unwarranted hassle for that reason too.
This discussion spread awareness and identified what I wanted existed, so
why should I take flack for engaging to discover that.

Now I just hope we get this feature as boost has it. I'd love it to get
into C++17, but I accept it might be too late.


>
> --
> Matthew
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/ofyByk1VorU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/587663E0.9050800%40gmail.com.
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAGxCow05OSSu7vtor%3D%2BEjW%2B6Q4UHXWVaRoAcRHGS0=
Ow7AJzZiA%40mail.gmail.com.

--001a113cbc0c9d4d260545d9bf15
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Jan 12, 2017 at 5:57 AM, Matthew Woehlke <span dir=3D"ltr">&lt;=
<a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.flos=
s@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,20=
4,204);border-left-width:1px;border-left-style:solid"><span>On 2017-01-11 0=
4:51, <a href=3D"mailto:gmisocpp@gmail.com">gmisocpp@gmail.com</a> wrote:<b=
r>
&gt; I shouldn&#39;t need to go hacking a C and C++ memory allocator to pro=
ve<br>
&gt; it&#39;s possible for the former to be able to able to de-allocate for=
<br>
&gt; the latter<br>
<br>
</span>Um... good luck with that. Given that, last I knew, it was still<br>
possible to have multiple versions of the C runtime - with incompatible<br>
allocators - participating in a process, I doubt you&#39;re going to have<b=
r>
much luck getting them all to play nice by introducing the C++ allocator<br=
>
to the mix. Never mind that some programs may be using custom allocators.<b=
r>
<br>
There&#39;s a very good reason why transfer of memory ownership almost<br>
always (at least in code that isn&#39;t broken by design) involves also<br>
telling the receiver how to release the memory.<br>
<br>
That said, if you want to propose a mechanism that *includes* getting a<br>
pointer to a function that can free your &quot;detached&quot; memory, you m=
ight<br>
have better luck...<br>
<span><br>
&gt; So though you say I have a right to my suggestion, that right isn&#39;=
t worth<br>
&gt; much if I must have a proof of concept first for my suggestions before=
 I<br>
&gt; can make them. I don&#39;t accept it needs to be a requirement for dis=
cussion.<br>
&gt; Yes it&#39;s always nice to have though.<br>
<br>
</span>I think you might be reading too much into this. You are making a cl=
aim.<br>
Others are disbelieving your claim. The point being made is that just<br>
repeating yourself over and over is not persuasive. Otherwise, all we<br>
have, on either side, is opinions, and I am just as welcome to mine as<br>
you are to yours.<br></blockquote><div><br></div><div>Nobody is disbelievin=
g my claim, The=C2=A0emphasis of my posts=C2=A0are=C2=A0about two things: 1=
)=C2=A0uninitialized allocation=C2=A0which there is complete agreement near=
ly on the need for and 2) how one=C2=A0should be able=C2=A0to=C2=A0present=
=C2=A0that proposal/idea without=C2=A0facing derision. </div><div><br></div=
><div>If you are talking about some technical claim where there is disbelie=
f, you=C2=A0might be=C2=A0focusing=C2=A0on the=C2=A0allocator part, but if =
you look at my comments to Nicol,=C2=A0I made it explicitly clear that&#39;=
s not=C2=A0a key aspect of my proposal.=C2=A0 So there is no disagreement t=
here.</div><div><br></div><div>To save you looking, I was saying that=C2=A0=
C/C++ sharing a de-allocator=C2=A0at least for=C2=A0pods=C2=A0could be of m=
utual gain and could be a &#39;nice to have&#39; thing that is worthy of co=
nsideration by the Committee but I have no hope in hell of doing that mysel=
f. More to the point I should be able to ask those in the know about that g=
etting unhelpful responses to the question though.<br></div><div><br></div>=
<div>So=C2=A0*now* at the risk of repeating myself...</div><div>=C2=A0</div=
><div>What I am saying is:</div><div>It=C2=A0should be able to=C2=A0&quot;p=
ropose&quot; something=C2=A0notionally like=C2=A0I think we need &#39;unini=
tialized allocation now&#39; how about this...&#39;</div><div><br></div><di=
v>And get back responses like this:</div><div>&#39;yes that seems possible =
but it will be hard because of Y....&#39; (which your comment said re:alloc=
ators)=C2=A0OR</div><div>&#39;no=C2=A0because Y seems to be=C2=A0technicall=
y un-achievable because of Z&#39;.</div><div><br></div><div>Instead of=C2=
=A0this:</div><div>&#39;no it can&#39;t be done because we don&#39;t allow =
that today (no further commentary)&#39;</div><div>&#39;no I don&#39;t think=
 that&#39;s possible, give me a proof of implementation that shows that it =
is (no commentary)&#39;</div><div>&#39;you&#39;re idea is complete. don&#39=
;t come back until you have proof it can be done.&#39; (especially this)</d=
iv><div>&#39;you are being demanding go away&#39;</div><div><br></div><div>=
The former set of replies takes us forward (even to a meaningful halt)=C2=
=A0and is encouraging.</div><div>The latter is utterly pointless.</div><div=
><br></div><div>People will come here to see if their assertions make sense=
.. They don&#39;t want to be told that they can&#39;t make these assertions =
without having to already know the answer (i.e. have proof of concept alrea=
dy), as if they were that sure they&#39;d not need to post here at all and =
they&#39;d just make contact with wg21 directly.<br></div><div>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid">
<br>
Also... *nothing* is stopping you from moving ahead with your proposal<br>
anyway. Maybe the committee will think it&#39;s a fabulous idea and move<br=
>
forward with it anyway. Maybe they&#39;ll have the same reaction:<br>
unconvinced without further evidence. Very little=C2=B9 that happens on thi=
s<br>
forum reflects how you *must* proceed. Rather, it serves as an<br>
approximation of how the committee is *likely* to respond to a proposal.<br=
>
Ignore or abide by that at your own risk.<br></blockquote><div><br></div><d=
iv>No, nothing is stopping anybody, but we=C2=A0should we=C2=A0encourage di=
scouragement?</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid">
<br>
(=C2=B9 Comments made by committee members are of course not to be set asid=
e<br>
lightly, as they will almost certainly happen in actual committee also.)<br=
>
<br>
&gt; The recent enum cast proposal is a good example [...] why am I<br>
<span>&gt; getting flack and not them?<br>
<br>
</span>I would disagree with the claim that Maciej is not getting flack :-)=
..<br>
<span><br>
&gt; People should just assist with what&#39;s presented and help complete =
the<br>
&gt; incomplete if they want to, or stay clear.<br>
<br>
</span>Here, I am not sure I agree. There is a cost to dealing with bad<br>
proposals, especially by the time they get to an actual committee<br>
meeting. Allowing a bad proposal to get that far can end up wasting a<br>
lot more time than if it was killed off early.<br></blockquote><div><br></d=
iv><div><div>Nobody=C2=A0needs=C2=A0waste their time. If someone can&#39;t =
move a &quot;proposal&#39; forward, say nothing.</div></div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid">
<br>
I also am not convinced that allowing a terrible proposal to make it all<br=
>
the way to committee isn&#39;t doing the *proposer* a disservice, as well.<=
br>
If I have an idea that is really terrible, I want to know that people<br>
feel that way. At least so I&#39;m prepared for it at committee, but also s=
o<br>
that maybe I&#39;m not wasting time on a proposal that has no chance of suc=
cess.<br></blockquote><div><br></div><div><br></div><div>That&#39;s fine, I=
&#39;m not arguing you can&#39;t challenge a proposal, I&#39;m trying to al=
ter how the challenges come so that people=C2=A0aim to=C2=A0focus on the es=
sence of an idea,=C2=A0incomplete as it maybe,=C2=A0expecting that it will =
need to=C2=A0grow and morph a bit, and that&#39;s what they are assisting w=
ith,=C2=A0not just=C2=A0take something as it is=C2=A0and=C2=A0rip it up or =
get derisory each time. Encourage the essence of the idea.</div><div><br></=
div><div><div><div>The essence of=C2=A0my proposal was good: uninitialized =
allocation. As it turns out boost has that=C2=A0feature I want already=C2=
=A0so there&#39;s no doubt it&#39;s good. *And we=C2=A0were progressing to =
that point here until=C2=A0I got derision because someone was upset about=
=C2=A0incompleteness.*</div></div><div><br></div><div>*If I&#39;d have gone=
 away and spent ages coming up with what boost already did, I&#39;d have wa=
sted my time as far as I am concerned.* So we need to let incomplete propos=
als roll without unwarranted hassle for that reason too. This discussion sp=
read awareness and identified what I wanted existed,=C2=A0so why should I=
=C2=A0take flack for engaging to discover that.</div><div><br></div><div>No=
w I just hope we get this feature as boost has it. I&#39;d love it to get i=
nto C++17, but I accept it might be too late.<br></div></div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padd=
ing-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;borde=
r-left-style:solid">
<br>
--<br>
Matthew<br>
<span><br>
--<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/ofyByk1VorU/unsubscribe" target=3D"_blan=
k" rel=3D"noreferrer">https://groups.google.com/a/<wbr>isocpp.org/d/topic/s=
td-<wbr>proposals/ofyByk1VorU/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@<wbr>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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/587663E0.9050800%40gmail.com" =
target=3D"_blank" rel=3D"noreferrer">https://groups.google.com/a/<wbr>isocp=
p.org/d/msgid/std-<wbr>proposals/587663E0.9050800%<wbr>40gmail.com</a>.<br>
</blockquote></div><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGxCow05OSSu7vtor%3D%2BEjW%2B6Q4UHXW=
VaRoAcRHGS0Ow7AJzZiA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGxCow05OS=
Su7vtor%3D%2BEjW%2B6Q4UHXWVaRoAcRHGS0Ow7AJzZiA%40mail.gmail.com</a>.<br />

--001a113cbc0c9d4d260545d9bf15--

.

--001a113de47e2ff4430545da161d
Content-Type: text/plain; charset=UTF-8

On Thu, Jan 12, 2017 at 5:57 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2017-01-11 04:51, gmisocpp@gmail.com wrote:
> > I shouldn't need to go hacking a C and C++ memory allocator to prove
> > it's possible for the former to be able to able to de-allocate for
> > the latter
>
> Um... good luck with that.


I should add that so far the enum cast proposal is a model of what I do
want to see.

1. Somebody has the essence of a good idea.
2. Possibly not be best API exactly as proposed, but it's of no concern.
The idea is good.
3. So everyone rallies around and morphs it into something to with a better
API.
4. OP writes it all up and submits a proposal.

No derision, no concern about incompleteness. Complete the incomplete.
Same thing could have happened here. But boost/nicols proposal has what I
want and it revealed that so I'm happy.So this thread can die unless people
want to use it for ironing out anything nicol or boost is proposing that
they don't like.

It might be nice to hear some comments on what the way forward is regarding
boost and C++17/next.
i.e. I assume that hasn't actually been proposed for standardisation yet?
Are they wanting to wait?

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGxCow2XyzLanDk4WOa6hnmZHBnO4Ku5qf8CTgvRM6Bru3u0MQ%40mail.gmail.com.

--001a113de47e2ff4430545da161d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jan 12, 2017 at 5:57 AM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);=
border-left-width:1px;border-left-style:solid"><span>On 2017-01-11 04:51, <=
a href=3D"mailto:gmisocpp@gmail.com">gmisocpp@gmail.com</a> wrote:<br>
&gt; I shouldn&#39;t need to go hacking a C and C++ memory allocator to pro=
ve<br>
&gt; it&#39;s possible for the former to be able to able to de-allocate for=
<br>
&gt; the latter<br>
<br>
</span>Um... good luck with that.</blockquote><div><br></div><div>I should =
add that so far=C2=A0the=C2=A0enum cast proposal is a model of what I do wa=
nt to see.</div><div><br></div><div>1. Somebody has the essence of a good i=
dea.</div><div>2.=C2=A0Possibly not be=C2=A0best=C2=A0API exactly as=C2=A0p=
roposed, but it&#39;s of no concern. The idea is good.</div><div>3. So ever=
yone rallies around and morphs it into something to with a better API.</div=
><div>4. OP writes it all up and submits a proposal.</div><div><br></div><d=
iv>No derision, no concern about incompleteness. Complete the incomplete.</=
div><div>Same thing could have happened here. But=C2=A0boost/nicols proposa=
l has what I want and it revealed that so I&#39;m happy.So this thread can =
die=C2=A0unless=C2=A0people want to use it=C2=A0for ironing out=C2=A0anythi=
ng nicol or=C2=A0boost is proposing that they don&#39;t like.</div><div><br=
></div><div>It might be nice to hear some comments on what the way forward =
is regarding boost and C++17/next.</div><div>i.e. I assume that hasn&#39;t =
actually been proposed for standardisation yet? Are they wanting to wait?<b=
r></div></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGxCow2XyzLanDk4WOa6hnmZHBnO4Ku5qf8C=
TgvRM6Bru3u0MQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGxCow2XyzLanDk4=
WOa6hnmZHBnO4Ku5qf8CTgvRM6Bru3u0MQ%40mail.gmail.com</a>.<br />

--001a113de47e2ff4430545da161d--

.

------=_Part_1252_1610003242.1484181193832
Content-Type: multipart/alternative;
 boundary="----=_Part_1253_1255194688.1484181193833"

------=_Part_1253_1255194688.1484181193833
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, January 11, 2017 at 6:13:30 PM UTC-5, G M wrote:
>
> On Thu, Jan 12, 2017 at 5:57 AM, Matthew Woehlke <mwoehlk...@gmail.com=20
> <javascript:>> wrote:
>
>> On 2017-01-11 04:51, gmis...@gmail.com <javascript:> wrote:
>> > I shouldn't need to go hacking a C and C++ memory allocator to prove
>> > it's possible for the former to be able to able to de-allocate for
>> > the latter
>>
>> Um... good luck with that. Given that, last I knew, it was still
>> possible to have multiple versions of the C runtime - with incompatible
>> allocators - participating in a process, I doubt you're going to have
>> much luck getting them all to play nice by introducing the C++ allocator
>> to the mix. Never mind that some programs may be using custom allocators=
..
>>
>> There's a very good reason why transfer of memory ownership almost
>> always (at least in code that isn't broken by design) involves also
>> telling the receiver how to release the memory.
>>
>> That said, if you want to propose a mechanism that *includes* getting a
>> pointer to a function that can free your "detached" memory, you might
>> have better luck...
>>
>> > So though you say I have a right to my suggestion, that right isn't=20
>> worth
>> > much if I must have a proof of concept first for my suggestions before=
 I
>> > can make them. I don't accept it needs to be a requirement for=20
>> discussion.
>> > Yes it's always nice to have though.
>>
>> I think you might be reading too much into this. You are making a claim.
>> Others are disbelieving your claim. The point being made is that just
>> repeating yourself over and over is not persuasive. Otherwise, all we
>> have, on either side, is opinions, and I am just as welcome to mine as
>> you are to yours.
>>
>
> Nobody is disbelieving my claim, The emphasis of my posts are about two=
=20
> things: 1) uninitialized allocation which there is complete agreement=20
> nearly on the need for
>

But there is disagreement on the need for this. Namely, I disagree.

Note that my idea is very much *not* about "uninitialized allocation"; it=
=20
is about *default initialization*. Those aren't the same thing, and the=20
difference is a matter of what is legal, standard C++ and what is not.

Your proposal is to make C idioms into valid C++. Your proposal is not=20
legal C++; not unless you make changes to the C++ object model. And you=20
have not specified what those changes need to be. Presumably it would be=20
"do whatever it takes to make this code work," which is *not helpful* when=
=20
making a proposal.

My proposal is to make valid C++ idioms accessible through `vector` (and=20
other things).

Essentially, the only things we agree on are the problem domain: avoiding=
=20
value initialization for objects whose contents are going to be overwritten=
..
=20

> Also... *nothing* is stopping you from moving ahead with your proposal
>> anyway. Maybe the committee will think it's a fabulous idea and move
>> forward with it anyway. Maybe they'll have the same reaction:
>> unconvinced without further evidence. Very little=C2=B9 that happens on =
this
>> forum reflects how you *must* proceed. Rather, it serves as an
>> approximation of how the committee is *likely* to respond to a proposal.
>> Ignore or abide by that at your own risk.
>>
>
> No, nothing is stopping anybody, but we should we encourage discouragemen=
t?
>

If it is warranted, then yes. With the exception of what D. B. said, I have=
=20
yet to see any criticism of your idea that is not unwarranted.

On Wednesday, January 11, 2017 at 6:37:42 PM UTC-5, G M wrote:
>
> I should add that so far the enum cast proposal is a model of what I do=
=20
> want to see.
>
> 1. Somebody has the essence of a good idea.
> 2. Possibly not be best API exactly as proposed, but it's of no concern.=
=20
> The idea is good.
> 3. So everyone rallies around and morphs it into something to with a=20
> better API.
> 4. OP writes it all up and submits a proposal.
>

Well, let's point out the differences between that thread and this one.

1: The OP's idea was perfectly functional as originally stated. There were=
=20
no defects of design, only questions of performance and so forth. By=20
contrast, your idea violated the C++ object model and had memory allocation=
=20
concerns. It was not nearly as well conceived as the other thread.

2: When others suggested interface changes, the OP did not respond in a=20
defensive way.

3: At no time did the OP of that thread make the claim that their proposal=
=20
was so important that it *needed* to be stuck into C++17. That waiting 3=20
years or more would be intolerable.

It seems to me that what you get out of this forum is based on what you put=
=20
into it. The more effort you put into your ideas *before* making them, the=
=20
better your reception will be.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ff53dd7a-4ff0-40b5-90e8-59169bc8e4f7%40isocpp.or=
g.

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

<div dir=3D"ltr">On Wednesday, January 11, 2017 at 6:13:30 PM UTC-5, G M wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div=
 class=3D"gmail_quote">On Thu, Jan 12, 2017 at 5:57 AM, Matthew Woehlke <sp=
an dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"DPTkW4VaBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;j=
avascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;=
return true;">mwoehlk...@gmail.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;borde=
r-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid=
"><span>On 2017-01-11 04:51, <a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"DPTkW4VaBgAJ" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;">gmis...@gmail.com</a> wrote:<br>
&gt; I shouldn&#39;t need to go hacking a C and C++ memory allocator to pro=
ve<br>
&gt; it&#39;s possible for the former to be able to able to de-allocate for=
<br>
&gt; the latter<br>
<br>
</span>Um... good luck with that. Given that, last I knew, it was still<br>
possible to have multiple versions of the C runtime - with incompatible<br>
allocators - participating in a process, I doubt you&#39;re going to have<b=
r>
much luck getting them all to play nice by introducing the C++ allocator<br=
>
to the mix. Never mind that some programs may be using custom allocators.<b=
r>
<br>
There&#39;s a very good reason why transfer of memory ownership almost<br>
always (at least in code that isn&#39;t broken by design) involves also<br>
telling the receiver how to release the memory.<br>
<br>
That said, if you want to propose a mechanism that *includes* getting a<br>
pointer to a function that can free your &quot;detached&quot; memory, you m=
ight<br>
have better luck...<br>
<span><br>
&gt; So though you say I have a right to my suggestion, that right isn&#39;=
t worth<br>
&gt; much if I must have a proof of concept first for my suggestions before=
 I<br>
&gt; can make them. I don&#39;t accept it needs to be a requirement for dis=
cussion.<br>
&gt; Yes it&#39;s always nice to have though.<br>
<br>
</span>I think you might be reading too much into this. You are making a cl=
aim.<br>
Others are disbelieving your claim. The point being made is that just<br>
repeating yourself over and over is not persuasive. Otherwise, all we<br>
have, on either side, is opinions, and I am just as welcome to mine as<br>
you are to yours.<br></blockquote><div><br></div><div>Nobody is disbelievin=
g my claim, The=C2=A0emphasis of my posts=C2=A0are=C2=A0about two things: 1=
)=C2=A0uninitialized allocation=C2=A0which there is complete agreement near=
ly on the need for</div></div></div></div></blockquote><div><br>But there i=
s disagreement on the need for this. Namely, I disagree.<br><br>Note that m=
y idea is very much <i>not</i> about &quot;uninitialized allocation&quot;; =
it is about <i>default initialization</i>. Those aren&#39;t the same thing,=
 and the difference is a matter of what is legal, standard C++ and what is =
not.<br><br>Your proposal is to make C idioms into valid C++. Your proposal=
 is not legal C++; not unless you make changes to the C++ object model. And=
 you have not specified what those changes need to be. Presumably it would =
be &quot;do whatever it takes to make this code work,&quot; which is <i>not=
 helpful</i> when making a proposal.<br><br>My proposal is to make valid C+=
+ idioms accessible through `vector` (and other things).<br><br>Essentially=
, the only things we agree on are the problem domain: avoiding value initia=
lization for objects whose contents are going to be overwritten.<br>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><di=
v class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid">

Also... *nothing* is stopping you from moving ahead with your proposal<br>
anyway. Maybe the committee will think it&#39;s a fabulous idea and move<br=
>
forward with it anyway. Maybe they&#39;ll have the same reaction:<br>
unconvinced without further evidence. Very little=C2=B9 that happens on thi=
s<br>
forum reflects how you *must* proceed. Rather, it serves as an<br>
approximation of how the committee is *likely* to respond to a proposal.<br=
>
Ignore or abide by that at your own risk.<br></blockquote><div><br></div><d=
iv>No, nothing is stopping anybody, but we=C2=A0should we=C2=A0encourage di=
scouragement?</div></div></div></div></blockquote><div><br>If it is warrant=
ed, then yes. With the exception of what D. B. said, I have yet to see any =
criticism of your idea that is not unwarranted.<br></div><div><br>On Wednes=
day, January 11, 2017 at 6:37:42 PM UTC-5, G M wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><di=
v>I should add that so far=C2=A0the=C2=A0enum cast proposal is a model of w=
hat I do want to see.</div><div><br></div><div>1. Somebody has the essence =
of a good idea.</div><div>2.=C2=A0Possibly not be=C2=A0best=C2=A0API exactl=
y as=C2=A0proposed, but it&#39;s of no concern. The idea is good.</div><div=
>3. So everyone rallies around and morphs it into something to with a bette=
r API.</div><div>4. OP writes it all up and submits a proposal.</div></div>=
</div></div></blockquote><div><br>Well, let&#39;s point out the differences=
 between that thread and this one.<br><br>1:
 The OP&#39;s idea was perfectly functional as originally stated. There wer=
e
 no defects of design, only questions of performance and so forth. By=20
contrast, your idea violated the C++ object model and had memory=20
allocation concerns. It was not nearly as well conceived as the other=20
thread.<br><br>2: When others suggested interface changes, the OP did not r=
espond in a defensive way.<br><br>3: At no time did the OP of that thread m=
ake the claim that their proposal was so important that it <i>needed</i> to=
 be stuck into C++17. That waiting 3 years or more would be intolerable.<br=
><br>It seems to me that what you get out of this forum is based on what yo=
u put into it. The more effort you put into your ideas <i>before</i> making=
 them, the better your reception will be.<br></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ff53dd7a-4ff0-40b5-90e8-59169bc8e4f7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ff53dd7a-4ff0-40b5-90e8-59169bc8e4f7=
%40isocpp.org</a>.<br />

------=_Part_1253_1255194688.1484181193833--

------=_Part_1252_1610003242.1484181193832--

.

------=_Part_157_293412247.1484196180972
Content-Type: multipart/alternative;
 boundary="----=_Part_158_1819812585.1484196180973"

------=_Part_158_1819812585.1484196180973
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Thursday, January 12, 2017 at 1:33:14 PM UTC+13, Nicol Bolas wrote:
>
> On Wednesday, January 11, 2017 at 6:13:30 PM UTC-5, G M wrote:
>>
>> On Thu, Jan 12, 2017 at 5:57 AM, Matthew Woehlke <mwoehlk...@gmail.com>=
=20
>> wrote:
>>
>>> On 2017-01-11 04:51, gmis...@gmail.com wrote:
>>> > I shouldn't need to go hacking a C and C++ memory allocator to prove
>>> > it's possible for the former to be able to able to de-allocate for
>>> > the latter
>>>
>>> Um... good luck with that. Given that, last I knew, it was still
>>> possible to have multiple versions of the C runtime - with incompatible
>>> allocators - participating in a process, I doubt you're going to have
>>> much luck getting them all to play nice by introducing the C++ allocato=
r
>>> to the mix. Never mind that some programs may be using custom allocator=
s.
>>>
>>> There's a very good reason why transfer of memory ownership almost
>>> always (at least in code that isn't broken by design) involves also
>>> telling the receiver how to release the memory.
>>>
>>> That said, if you want to propose a mechanism that *includes* getting a
>>> pointer to a function that can free your "detached" memory, you might
>>> have better luck...
>>>
>>> > So though you say I have a right to my suggestion, that right isn't=
=20
>>> worth
>>> > much if I must have a proof of concept first for my suggestions befor=
e=20
>>> I
>>> > can make them. I don't accept it needs to be a requirement for=20
>>> discussion.
>>> > Yes it's always nice to have though.
>>>
>>> I think you might be reading too much into this. You are making a claim=
..
>>> Others are disbelieving your claim. The point being made is that just
>>> repeating yourself over and over is not persuasive. Otherwise, all we
>>> have, on either side, is opinions, and I am just as welcome to mine as
>>> you are to yours.
>>>
>>
>> Nobody is disbelieving my claim, The emphasis of my posts are about two=
=20
>> things: 1) uninitialized allocation which there is complete agreement=20
>> nearly on the need for
>>
>
> But there is disagreement on the need for this. Namely, I disagree.
>
> Note that my idea is very much *not* about "uninitialized allocation"; it=
=20
> is about *default initialization*. Those aren't the same thing, and the=
=20
> difference is a matter of what is legal, standard C++ and what is not.
>
> Your proposal is to make C idioms into valid C++. Your proposal is not=20
> legal C++; not unless you make changes to the C++ object model. And you=
=20
> have not specified what those changes need to be. Presumably it would be=
=20
> "do whatever it takes to make this code work," which is *not helpful*=20
> when making a proposal.
>
> My proposal is to make valid C++ idioms accessible through `vector` (and=
=20
> other things).
>
> Essentially, the only things we agree on are the problem domain: avoiding=
=20
> value initialization for objects whose contents are going to be overwritt=
en.
> =20
>
>> Also... *nothing* is stopping you from moving ahead with your proposal
>>> anyway. Maybe the committee will think it's a fabulous idea and move
>>> forward with it anyway. Maybe they'll have the same reaction:
>>> unconvinced without further evidence. Very little=C2=B9 that happens on=
 this
>>> forum reflects how you *must* proceed. Rather, it serves as an
>>> approximation of how the committee is *likely* to respond to a proposal=
..
>>> Ignore or abide by that at your own risk.
>>>
>>
>> No, nothing is stopping anybody, but we should we encourage=20
>> discouragement?
>>
>
> If it is warranted, then yes. With the exception of what D. B. said, I=20
> have yet to see any criticism of your idea that is not unwarranted.
>
> On Wednesday, January 11, 2017 at 6:37:42 PM UTC-5, G M wrote:
>>
>> I should add that so far the enum cast proposal is a model of what I do=
=20
>> want to see.
>>
>> 1. Somebody has the essence of a good idea.
>> 2. Possibly not be best API exactly as proposed, but it's of no concern.=
=20
>> The idea is good.
>> 3. So everyone rallies around and morphs it into something to with a=20
>> better API.
>> 4. OP writes it all up and submits a proposal.
>>
>
> Well, let's point out the differences between that thread and this one.
>
> 1: The OP's idea was perfectly functional as originally stated. There wer=
e=20
> no defects of design, only questions of performance and so forth. By=20
> contrast, your idea violated the C++ object model and had memory allocati=
on=20
> concerns. It was not nearly as well conceived as the other thread.
>
> 2: When others suggested interface changes, the OP did not respond in a=
=20
> defensive way.
>
> 3: At no time did the OP of that thread make the claim that their proposa=
l=20
> was so important that it *needed* to be stuck into C++17. That waiting 3=
=20
> years or more would be intolerable.
>
> It seems to me that what you get out of this forum is based on what you=
=20
> put into it. The more effort you put into your ideas *before* making=20
> them, the better your reception will be.
>

I don't see it that way.

I wasn't "defensive" about changing my interface. I didn't even see the=20
interface as a big deal at this moment. It was acceptance of the=20
functionality that I was gauging. I just presented an API that I felt=20
delivered the functionality I wanted. But then you (or somebody) opened=20
with saying I didn't have support, which I took to mean for=20
the functionality so I was defending that. The functionality IS important.=
=20
You just presented your agreement as non agreement. That was just confusing=
..

Then there was talk about alien interfaces, which is subjective so of=20
course I'm going to defend something against abstract or else I've got=20
nothing. And then you presented an actual an actual API, but it was one=20
method call that was insufficient for what I needed. So of course I'm going=
=20
to defend mine against yours while yours doesn't do what I want! That isn't=
=20
being defensive,

Not least of all because I continued inquiring about if there was more to=
=20
your API then you initially presented. And importantly I continued to=20
be polite about.

If I was defensive I would be neither polite nor inquiring. And once=20
you unfurled the extent of your API and I saw it did what I wanted, I=20
accepted it as a result I'm happy with. You can't ask for more than=20
complete acceptance of an alternative once it's actually presented! I don't=
=20
see anything defensive about that process. That just is the process.

I don't see any problem with that, that's what a discussion is about. It=20
was the derision and the reason behind it that I objected to and I still=20
do. Yours/the boost proposal covers the essence of what I wanted to achieve=
=20
so I don't see there being any disagreement.

If you're supportive to the essence of something, you should sound like it.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a5bc8486-93ef-4bf9-a2a8-a19ca76b10d5%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Thursday, January 12, 2017 at 1:33:14 PM UTC+13=
, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px =
0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bo=
rder-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">On Wednes=
day, January 11, 2017 at 6:13:30 PM UTC-5, G M wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-l=
eft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: s=
olid;"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Thu, Jan 12, 201=
7 at 5:57 AM, Matthew Woehlke <span dir=3D"ltr">&lt;<a rel=3D"nofollow">mwo=
ehlk...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color:=
 rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><sp=
an>On 2017-01-11 04:51, <a rel=3D"nofollow">gmis...@gmail.com</a> wrote:<br=
>
&gt; I shouldn&#39;t need to go hacking a C and C++ memory allocator to pro=
ve<br>
&gt; it&#39;s possible for the former to be able to able to de-allocate for=
<br>
&gt; the latter<br>
<br>
</span>Um... good luck with that. Given that, last I knew, it was still<br>
possible to have multiple versions of the C runtime - with incompatible<br>
allocators - participating in a process, I doubt you&#39;re going to have<b=
r>
much luck getting them all to play nice by introducing the C++ allocator<br=
>
to the mix. Never mind that some programs may be using custom allocators.<b=
r>
<br>
There&#39;s a very good reason why transfer of memory ownership almost<br>
always (at least in code that isn&#39;t broken by design) involves also<br>
telling the receiver how to release the memory.<br>
<br>
That said, if you want to propose a mechanism that *includes* getting a<br>
pointer to a function that can free your &quot;detached&quot; memory, you m=
ight<br>
have better luck...<br>
<span><br>
&gt; So though you say I have a right to my suggestion, that right isn&#39;=
t worth<br>
&gt; much if I must have a proof of concept first for my suggestions before=
 I<br>
&gt; can make them. I don&#39;t accept it needs to be a requirement for dis=
cussion.<br>
&gt; Yes it&#39;s always nice to have though.<br>
<br>
</span>I think you might be reading too much into this. You are making a cl=
aim.<br>
Others are disbelieving your claim. The point being made is that just<br>
repeating yourself over and over is not persuasive. Otherwise, all we<br>
have, on either side, is opinions, and I am just as welcome to mine as<br>
you are to yours.<br></blockquote><div><br></div><div>Nobody is disbelievin=
g my claim, The=C2=A0emphasis of my posts=C2=A0are=C2=A0about two things: 1=
)=C2=A0uninitialized allocation=C2=A0which there is complete agreement near=
ly on the need for</div></div></div></div></blockquote><div><br>But there i=
s disagreement on the need for this. Namely, I disagree.<br><br>Note that m=
y idea is very much <i>not</i> about &quot;uninitialized allocation&quot;; =
it is about <i>default initialization</i>. Those aren&#39;t the same thing,=
 and the difference is a matter of what is legal, standard C++ and what is =
not.<br><br>Your proposal is to make C idioms into valid C++. Your proposal=
 is not legal C++; not unless you make changes to the C++ object model. And=
 you have not specified what those changes need to be. Presumably it would =
be &quot;do whatever it takes to make this code work,&quot; which is <i>not=
 helpful</i> when making a proposal.<br><br>My proposal is to make valid C+=
+ idioms accessible through `vector` (and other things).<br><br>Essentially=
, the only things we agree on are the problem domain: avoiding value initia=
lization for objects whose contents are going to be overwritten.<br>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; =
padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width=
: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><div class=3D"gmail=
_quote"><div></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;">

Also... *nothing* is stopping you from moving ahead with your proposal<br>
anyway. Maybe the committee will think it&#39;s a fabulous idea and move<br=
>
forward with it anyway. Maybe they&#39;ll have the same reaction:<br>
unconvinced without further evidence. Very little=C2=B9 that happens on thi=
s<br>
forum reflects how you *must* proceed. Rather, it serves as an<br>
approximation of how the committee is *likely* to respond to a proposal.<br=
>
Ignore or abide by that at your own risk.<br></blockquote><div><br></div><d=
iv>No, nothing is stopping anybody, but we=C2=A0should we=C2=A0encourage di=
scouragement?</div></div></div></div></blockquote><div><br>If it is warrant=
ed, then yes. With the exception of what D. B. said, I have yet to see any =
criticism of your idea that is not unwarranted.<br></div><div><br>On Wednes=
day, January 11, 2017 at 6:37:42 PM UTC-5, G M wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-l=
eft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: s=
olid;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>I should add t=
hat so far=C2=A0the=C2=A0enum cast proposal is a model of what I do want to=
 see.</div><div><br></div><div>1. Somebody has the essence of a good idea.<=
/div><div>2.=C2=A0Possibly not be=C2=A0best=C2=A0API exactly as=C2=A0propos=
ed, but it&#39;s of no concern. The idea is good.</div><div>3. So everyone =
rallies around and morphs it into something to with a better API.</div><div=
>4. OP writes it all up and submits a proposal.</div></div></div></div></bl=
ockquote><div><br>Well, let&#39;s point out the differences between that th=
read and this one.<br><br>1:
 The OP&#39;s idea was perfectly functional as originally stated. There wer=
e
 no defects of design, only questions of performance and so forth. By=20
contrast, your idea violated the C++ object model and had memory=20
allocation concerns. It was not nearly as well conceived as the other=20
thread.<br><br>2: When others suggested interface changes, the OP did not r=
espond in a defensive way.<br><br>3: At no time did the OP of that thread m=
ake the claim that their proposal was so important that it <i>needed</i> to=
 be stuck into C++17. That waiting 3 years or more would be intolerable.<br=
><br>It seems to me that what you get out of this forum is based on what yo=
u put into it. The more effort you put into your ideas <i>before</i> making=
 them, the better your reception will be.<br></div></div></div></blockquote=
><div><br></div><div>I don&#39;t see it that way.</div><div><br></div><div>=
I wasn&#39;t &quot;defensive&quot; about changing my interface.=C2=A0I=C2=
=A0didn&#39;t even see the interface as a big deal at this moment. It was a=
cceptance of=C2=A0the functionality=C2=A0that I was gauging. I just=C2=A0pr=
esented an=C2=A0API=C2=A0that I felt delivered the functionality=C2=A0I=C2=
=A0wanted. But=C2=A0then you (or somebody) opened with saying I didn&#39;t =
have support, which I=C2=A0took=C2=A0to mean for the=C2=A0functionality=C2=
=A0so I was defending that. The functionality IS important. You just presen=
ted your agreement as non agreement. That was just confusing.</div><div><br=
></div><div>Then there was talk about=C2=A0alien interfaces, which is subje=
ctive so of course I&#39;m going to defend=C2=A0something against abstract =
or else I&#39;ve got nothing.=C2=A0And=C2=A0then=C2=A0you=C2=A0presented=C2=
=A0an=C2=A0actual an actual API, but it was one method call that was insuff=
icient=C2=A0for what I needed. So=C2=A0of course I&#39;m going to defend mi=
ne=C2=A0against yours=C2=A0while yours=C2=A0doesn&#39;t do=C2=A0what I want=
! That isn&#39;t being defensive,</div><div><br></div><div>Not least of all=
 because=C2=A0I continued inquiring about=C2=A0if there was more to your AP=
I then you=C2=A0initially presented. And=C2=A0importantly I continued to be=
=C2=A0polite about.</div><div><br></div><div>If I was defensive I would be =
neither polite nor inquiring. And=C2=A0once you=C2=A0unfurled the extent of=
 your API and I saw=C2=A0it=C2=A0did what I wanted, I accepted it as=C2=A0a=
 result I&#39;m happy with. You can&#39;t=C2=A0ask for more=C2=A0than compl=
ete acceptance of an alternative once it&#39;s actually presented! I don&#3=
9;t see anything defensive about that process. That just is the process.</d=
iv><div><br></div><div>I don&#39;t see any problem with that, that&#39;s wh=
at a discussion is about. It was the derision and the reason behind it that=
 I objected to and I still do. Yours/the boost proposal covers the essence =
of what I wanted to achieve so I don&#39;t see there being any disagreement=
..</div><div><br></div><div>If you&#39;re supportive to the essence of somet=
hing,=C2=A0you should sound like it.</div><div><br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a5bc8486-93ef-4bf9-a2a8-a19ca76b10d5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a5bc8486-93ef-4bf9-a2a8-a19ca76b10d5=
%40isocpp.org</a>.<br />

------=_Part_158_1819812585.1484196180973--

------=_Part_157_293412247.1484196180972--

.