> -----Original Message-----
> From: Matthew Woehlke [mailto:mw_triad@users.sourceforge.net]
> Sent: Mittwoch, 29. Januar 2014 17:09
> To: std-proposals@isocpp.org
> Subject: [std-proposals] Re: Ideas for C: What could C and systems
> level APIs do for C++ and higher level languages?
>
> On 2014-01-29 09:03, Matthew Fioravante wrote:
> > I'd love to see the C standard adopt a variant the following function
> > in their malloc() API.
> >
> > //Tries to resize p in place to newlen bytes. If successful, returns
> > p, otherwise returns NULL and the memory pointed to by p is
> unmodifed.
> > Returns NULL if p is NULL.
> > void* alloc_expand(void* p, size_t newlen);
> >
> > Why? Because we should be able to take advantage of this memory
> > optimization for contiguous memory layout data structures  such as
> > std::vector and std::string. A dynamic array is the most fundamental
> > data structure in any language. Contiguous memory layout is key for
> > performance on modern hardware.
>
> Given that containers may implement memory growth optimizations (e.g.
> allocate 50% more memory any time growth is needed), I wonder if it
> wouldn't be better to instead have:
>
> size_t alloc_expand(void* p, size_t desired_len, size_t alignment = 0)

There has been a similar proposal in 2006 ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2045.html#Problem%203 ).
It never went anywhere because IIRC nobody believed that the platform vendors would
augment their C lib.




--

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

.

Em qui 20 fev 2014, =E0s 21:45:48, myriachan@gmail.com escreveu:
> On Wednesday, January 29, 2014 6:03:33 AM UTC-8, Matthew Fioravante wrote=
:
> > This post might belong in a C forum, but I wanted to ask. What do you
> > think C could change to make the world better for C++ and/or other
> > languages and technologies?
>=20
> Later versions of C could make something between C99's variable-length
> array craziness and C++'s total lack thereof, so that C++ could adopt it.
> I'm sick and tired of having to use alloca in C++ when it could be a lot
> cleaner, like in the extension that GCC and clang already have (and I can=
't
> use because MSVC doesn't have).
>=20
> Variable-length arrays should just be stack allocations and
> constructor/destructor calls, and nothing more.  None of the weird
> parameter passing stuff that C99 had.  sizeof should just be a compiler
> error rather than be a special runtime-computed case.  I suppose that it
> *could* return the size of Type*, but that would be very error-prone.

VLAs were added to C++14.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 21 February 2014 09:48, Thiago Macieira <thiago@macieira.org> wrote:
> Em qui 20 fev 2014, =E0s 21:45:48, myriachan@gmail.com escreveu:
>> Variable-length arrays should just be stack allocations and
>> constructor/destructor calls, and nothing more.  None of the weird
>> parameter passing stuff that C99 had.  sizeof should just be a compiler
>> error rather than be a special runtime-computed case.  I suppose that it
>> *could* return the size of Type*, but that would be very error-prone.
> VLAs were added to C++14.


Almost, they were detached into an Arrays TS and are not part of the final
C++14 draft.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--20cf301afcc5689ed804f2e5faf6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Not really.

A VLA-like solution will be part of a separate technical specification.

The project will be ISO/IEC TS 19569.

--
J. Daniel

On Fri, Feb 21, 2014 at 8:48 AM, Thiago Macieira <thiago@macieira.org>wrote=
:

> Em qui 20 fev 2014, =E0s 21:45:48, myriachan@gmail.com escreveu:
> > On Wednesday, January 29, 2014 6:03:33 AM UTC-8, Matthew Fioravante
> wrote:
> > > This post might belong in a C forum, but I wanted to ask. What do you
> > > think C could change to make the world better for C++ and/or other
> > > languages and technologies?
> >
> > Later versions of C could make something between C99's variable-length
> > array craziness and C++'s total lack thereof, so that C++ could adopt i=
t.
> > I'm sick and tired of having to use alloca in C++ when it could be a lo=
t
> > cleaner, like in the extension that GCC and clang already have (and I
> can't
> > use because MSVC doesn't have).
> >
> > Variable-length arrays should just be stack allocations and
> > constructor/destructor calls, and nothing more.  None of the weird
> > parameter passing stuff that C99 had.  sizeof should just be a compiler
> > error rather than be a special runtime-computed case.  I suppose that i=
t
> > *could* return the size of Type*, but that would be very error-prone.
>
> VLAs were added to C++14.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">Not really.<div><br></div><div>A VLA-like solution will be=
 part of a separate technical specification.</div><div><br></div><div>The p=
roject will be ISO/IEC TS 19569.</div><div class=3D"gmail_extra"><br clear=
=3D"all">

<div><div dir=3D"ltr">--</div></div><div>J. Daniel</div><br><div class=3D"g=
mail_quote">On Fri, Feb 21, 2014 at 8:48 AM, Thiago Macieira <span dir=3D"l=
tr">&lt;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@mac=
ieira.org</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Em qui 20 fev 2014, =E0s 21:45:48, <a href=
=3D"mailto:myriachan@gmail.com">myriachan@gmail.com</a> escreveu:<br>
<div class=3D"">&gt; On Wednesday, January 29, 2014 6:03:33 AM UTC-8, Matth=
ew Fioravante wrote:<br>
&gt; &gt; This post might belong in a C forum, but I wanted to ask. What do=
 you<br>
&gt; &gt; think C could change to make the world better for C++ and/or othe=
r<br>
&gt; &gt; languages and technologies?<br>
&gt;<br>
&gt; Later versions of C could make something between C99&#39;s variable-le=
ngth<br>
&gt; array craziness and C++&#39;s total lack thereof, so that C++ could ad=
opt it.<br>
&gt; I&#39;m sick and tired of having to use alloca in C++ when it could be=
 a lot<br>
&gt; cleaner, like in the extension that GCC and clang already have (and I =
can&#39;t<br>
&gt; use because MSVC doesn&#39;t have).<br>
&gt;<br>
&gt; Variable-length arrays should just be stack allocations and<br>
&gt; constructor/destructor calls, and nothing more. =A0None of the weird<b=
r>
&gt; parameter passing stuff that C99 had. =A0sizeof should just be a compi=
ler<br>
&gt; error rather than be a special runtime-computed case. =A0I suppose tha=
t it<br>
&gt; *could* return the size of Type*, but that would be very error-prone.<=
br>
<br>
</div>VLAs were added to C++14.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
=A0 =A0Software Architect - Intel Open Source Technology Center<br>
=A0 =A0 =A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=A0 =A0 =A0 E067 918B B660 DBD1 105C =A0966C 33F5 F005 6EF4 5358<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--20cf301afcc5689ed804f2e5faf6--

.

On 02/21/2014 06:45 AM, myriachan@gmail.com wrote:
>=20
> On Wednesday, January 29, 2014 6:03:33 AM UTC-8, Matthew Fioravante wrote=
:
>=20
>     This post might belong in a C forum, but I wanted to ask. What do you=
 think C could change to make the world better for C++ and/or other languag=
es and technologies?
>=20
>=20
> Later versions of C could make something between C99's variable-length ar=
ray craziness and C++'s total lack thereof, so that C++ could adopt it.  I'=
m sick and tired of having to use alloca in C++ when it could be a lot clea=
ner, like in the extension that GCC and clang already have (and I can't use=
 because MSVC doesn't have).
>=20
> Variable-length arrays should just be stack allocations and constructor/d=
estructor calls, and nothing more.  None of the weird parameter passing stu=
ff that C99 had.  sizeof should just be a compiler error rather than be a s=
pecial runtime-computed case.  I suppose that it *could* return the size of=
 Type*, but that would be very error-prone.

This is heading for a separate Technical Specification, whose initial
working draft is available here:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3820.html

(The core language facility was actually uncontroversial, but the
std::dynarray part didn't reach consensus to be put into C++14.)

Jens

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.