Topic: Why not allow VLA?
Author: Alexander Nikolov <sasho648@mail.bg>
Date: Sat, 14 Mar 2015 17:40:01 -0700 (PDT)
Raw View
------=_Part_2262_1219303546.1426380001819
Content-Type: multipart/alternative;
boundary="----=_Part_2263_1545737948.1426380001819"
------=_Part_2263_1545737948.1426380001819
Content-Type: text/plain; charset=UTF-8
First any rationale for their prohibition?
I can guess it's because implementing such feature on low-level can add big
complexity and perhaps slow-performance at times. On the other hand other
times it can be very beneficial. I think this depends on implementation
details. This is the reason I'm suggesting them - sometimes it's faster to
use the stack rather then the heap.
I also think that using a build-in construct for such a feature is better
then defining standard function or object because it interfere with other
variables on the stack and also function calls.
But I also suggest adding a different way for defining such arrays in order
to warn the programmer that implementation of those can be costly. I think
for this is best to use the keyword 'virtual'. I'm sure that it will make
impression and also it will forbids declaring them without special research.
So an 'VLA' declaration will look something like this (reinvented form of
where shown in this site <http://en.cppreference.com/w/cpp/language/array>):
noptr-declarator *[* constexpr(optional) *]* *virtual*(optional) attr
(optional)
And here are some examples then:
std::size_t szArray; //lvalue, not-constant expression
int arr[szArray] virtual; //VLA of dynamic size 'szArray'
int arr1[szArray]; //error 'szArray' must be constant-expression
I'm still thinking of the type such objects will have though as I don't
think references to incomplete-types are currently defined.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2263_1545737948.1426380001819
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">First any rationale for their prohibition?<div><br></div><=
div>I can guess it's because implementing such feature on low-level can add=
big complexity and perhaps slow-performance at times. On the other hand ot=
her times it can be very beneficial. I think this depends on implementation=
details. This is the reason I'm suggesting them - sometimes it's faster to=
use the stack rather then the heap.</div><div><br></div><div>I also think =
that using a build-in construct for such a feature is better then defining =
standard function or object because it interfere with other variables on th=
e stack and also function calls.</div><div><br></div><div>But I also sugges=
t adding a different way for defining such arrays in order to warn the prog=
rammer that implementation of those can be costly. I think for this is best=
to use the keyword 'virtual'. I'm sure that it will make impression and al=
so it will forbids declaring them without special research.</div><div><br><=
/div><div>So an 'VLA' declaration will look something like this (reinvented=
form of where shown in this <a href=3D"http://en.cppreference.com/w/cpp/la=
nguage/array">site</a>):<br><br><table class=3D"t-sdsc-begin" style=3D"font=
-size: 12.8000001907349px; color: rgb(0, 0, 0); font-family: DejaVuSans, 'D=
ejaVu Sans', arial, sans-serif; line-height: 15.3600006103516px;"><tbody><t=
r class=3D"t-sdsc"><td style=3D"padding-top: 0.5em; padding-bottom: 0.5em; =
padding-left: 1em; font-size: 1em;"><span class=3D"t-spar" style=3D"color: =
rgb(128, 128, 128); font-style: italic; line-height: 1.1em;">noptr-declarat=
or</span> <code style=3D"font-family: DejaVuSansMono, 'DejaVu Sans Mon=
o', courier, monospace !important; background-color: transparent;"><b>[</b>=
</code> <span class=3D"t-spar" style=3D"color: rgb(128, 128, 128); fon=
t-style: italic; line-height: 1.1em;">constexpr</span><span class=3D"t-mark=
" style=3D"color: rgb(0, 128, 0); font-size: 0.8em; line-height: 1.1em;">(o=
ptional)</span> <code style=3D"font-family: DejaVuSansMono, 'DejaVu Sa=
ns Mono', courier, monospace !important; background-color: transparent;"><b=
>]</b></code> <code style=3D"font-size: 12.8000001907349px; line-heigh=
t: 15.3600006103516px; font-family: DejaVuSansMono, 'DejaVu Sans Mono', cou=
rier, monospace !important;"><b>virtual</b></code><span class=3D"t-mark" st=
yle=3D"color: rgb(0, 128, 0); font-size: 0.8em; line-height: 1.1em;">(optio=
nal) </span><span class=3D"t-spar" style=3D"font-size: 1em; color: rgb=
(128, 128, 128); font-style: italic; line-height: 1.1em;">attr</span><span =
class=3D"t-mark" style=3D"color: rgb(0, 128, 0); font-size: 0.8em; line-hei=
ght: 1.1em;">(optional)</span><br></td></tr></tbody></table><br></div><div>=
And here are some examples then:<br><br></div><div class=3D"prettyprint" st=
yle=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; backgro=
und-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"s=
ubprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">st=
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">size_t szArray</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #800;" class=3D"styled-by-prettify">//lvalue, not-constant expressi=
on</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> arr</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">szArray</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: #008;" class=
=3D"styled-by-prettify">virtual</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettif=
y">//VLA of dynamic size 'szArray'</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> arr1</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">[</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">szArray</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
];</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #800;" class=3D"styled-by-prettify">//error 'szArray'=
must be constant-expression</span></div></code></div><div><br></div><div>I=
'm still thinking of the type such objects will have though as I don't thin=
k references to incomplete-types are currently defined.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2263_1545737948.1426380001819--
------=_Part_2262_1219303546.1426380001819--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 15 Mar 2015 10:07:00 +0800
Raw View
--001a113325385f098a05114a30f6
Content-Type: text/plain; charset=UTF-8
On Sunday, March 15, 2015, Alexander Nikolov <sasho648@mail.bg> wrote:
> First any rationale for their prohibition?
>
See the various papers. N3810 is an excellent review, although newer
proposals exist too.
>
> I can guess it's because implementing such feature on low-level can add
> big complexity and perhaps slow-performance at times.
>
This can't be it, since they've been widely implemented for a long time.
The problems are deciding how much of the C99 feature to standardize, and
how to prevent usage from locking users into old-style C arrays which are
widely considered obsolete.
> noptr-declarator *[* constexpr(optional) *]* *virtual*(optional) attr
> (optional)
>
This fails to address either of those problems. Existing code would be
left in the lurch, C compatibility is lost compared to the status quo, and
there's no migration to a more modern style.
--
---
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/.
--001a113325385f098a05114a30f6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Sunday, March 15, 2015, Alexander Nikolov <<a href=3D"mailto:=
sasho648@mail.bg">sasho648@mail.bg</a>> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr">First any rationale for their prohibition?</div><=
/blockquote><div><br></div><div>See the various papers. N3810 is an excelle=
nt review, although newer proposals exist too.</div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>I can guess i=
t's because implementing such feature on low-level can add big complexi=
ty and perhaps slow-performance at times.=C2=A0</div><div></div></div></blo=
ckquote><div><br></div><div>This can't be it, since they've been wi=
dely implemented for a long time. The problems=C2=A0are=C2=A0deciding how m=
uch of the C99 feature to standardize, and how to prevent usage from lockin=
g users into old-style C arrays which are widely considered obsolete.</div>=
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><tabl=
e style=3D"font-size:12.8000001907349px;color:rgb(0,0,0);font-family:DejaVu=
Sans,'DejaVu Sans',arial,sans-serif;line-height:15.3600006103516px"=
><tbody><tr><td style=3D"padding-top:0.5em;padding-bottom:0.5em;padding-lef=
t:1em;font-size:1em"><span style=3D"color:rgb(128,128,128);font-style:itali=
c;line-height:1.1em">noptr-declarator</span>=C2=A0<code style=3D"font-famil=
y:DejaVuSansMono,'DejaVu Sans Mono',courier,monospace!important;bac=
kground-color:transparent"><b>[</b></code>=C2=A0<span style=3D"color:rgb(12=
8,128,128);font-style:italic;line-height:1.1em">constexpr</span><span style=
=3D"color:rgb(0,128,0);font-size:0.8em;line-height:1.1em">(optional)</span>=
=C2=A0<code style=3D"font-family:DejaVuSansMono,'DejaVu Sans Mono',=
courier,monospace!important;background-color:transparent"><b>]</b></code>=
=C2=A0<code style=3D"font-size:12.8000001907349px;line-height:15.3600006103=
516px;font-family:DejaVuSansMono,'DejaVu Sans Mono',courier,monospa=
ce!important"><b>virtual</b></code><span style=3D"color:rgb(0,128,0);font-s=
ize:0.8em;line-height:1.1em">(optional)=C2=A0</span><span style=3D"font-siz=
e:1em;color:rgb(128,128,128);font-style:italic;line-height:1.1em">attr</spa=
n><span style=3D"color:rgb(0,128,0);font-size:0.8em;line-height:1.1em">(opt=
ional)</span></td></tr></tbody></table></div></div></blockquote><div><br></=
div><div>=C2=A0This fails to address=C2=A0either of those problems. Existin=
g code would be left in the lurch, C compatibility is lost compared to the =
status quo, and there's no migration to a more modern style.</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113325385f098a05114a30f6--
.
Author: Douglas Boffey <douglas.boffey@gmail.com>
Date: Sun, 15 Mar 2015 08:22:52 +0000
Raw View
In what way can a VLA be considered virtual, or are you just picking a
keyword out of a hat?
On 3/15/15, David Krauss <potswa@gmail.com> wrote:
> On Sunday, March 15, 2015, Alexander Nikolov <sasho648@mail.bg> wrote:
>
>> First any rationale for their prohibition?
>>
>
> See the various papers. N3810 is an excellent review, although newer
> proposals exist too.
>
>
>>
>> I can guess it's because implementing such feature on low-level can add
>> big complexity and perhaps slow-performance at times.
>>
>
> This can't be it, since they've been widely implemented for a long time.
> The problems are deciding how much of the C99 feature to standardize, and
> how to prevent usage from locking users into old-style C arrays which are
> widely considered obsolete.
>
>
>> noptr-declarator *[* constexpr(optional) *]* *virtual*(optional) attr
>> (optional)
>>
>
> This fails to address either of those problems. Existing code would be
> left in the lurch, C compatibility is lost compared to the status quo, and
> there's no migration to a more modern style.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Alexander Nikolov <sasho648@mail.bg>
Date: Sun, 15 Mar 2015 06:26:51 -0700 (PDT)
Raw View
------=_Part_2871_1050472394.1426426011742
Content-Type: multipart/alternative;
boundary="----=_Part_2872_826463971.1426426011742"
------=_Part_2872_826463971.1426426011742
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 15 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=
=B3., 4:07:03 UTC+2, David Krauss =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:
>
>
>
> On Sunday, March 15, 2015, Alexander Nikolov <sash...@mail.bg=20
> <javascript:>> wrote:
>
>> First any rationale for their prohibition?
>>
>
> See the various papers. N3810 is an excellent review, although newer=20
> proposals exist too.
> =20
>
>>
>> I can guess it's because implementing such feature on low-level can add=
=20
>> big complexity and perhaps slow-performance at times.=20
>>
>
> This can't be it, since they've been widely implemented for a long time.=
=20
> The problems are deciding how much of the C99 feature to standardize, and=
=20
> how to prevent usage from locking users into old-style C arrays which are=
=20
> widely considered obsolete.
> =20
>
>> noptr-declarator *[* constexpr(optional) *]* *virtual*(optional) attr
>> (optional)
>>
>
> This fails to address either of those problems. Existing code would be=
=20
> left in the lurch, C compatibility is lost compared to the status quo, an=
d=20
> there's no migration to a more modern style.
>
Even if a 'modern-style' implementation is used 'C' compatibility will be=
=20
lost too. I don't like those because such construct interfere with function=
=20
stack and thus variables and function calls in it, which are built-int=20
language constructs.
Also I really would like to suppose that 'C++' standard library can be=20
implemented by using language built-in constructs and by using OS API's.=20
Otherwise a big mess occurs - what are the language capacities - they can=
=20
be hardly measured now.
Of-course standard library can provide some abstraction of this construct=
=20
with classes like 'std::array', perhaps named 'std::varray' which will have=
=20
the same capabilities as normal 'std::array' but with the possibility to=20
have dynamic size.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_2872_826463971.1426426011742
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 15 =D0=BC=D0=
=B0=D1=80=D1=82 2015 =D0=B3., 4:07:03 UTC+2, David Krauss =D0=BD=D0=B0=D0=
=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><br>=
On Sunday, March 15, 2015, Alexander Nikolov <<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"z48wu7Hyp0IJ" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">sash...@mail.bg</a>> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr">First any rationale for their prohibitio=
n?</div></blockquote><div><br></div><div>See the various papers. N3810 is a=
n excellent review, although newer proposals exist too.</div><div> </d=
iv><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><br></div><div>I ca=
n guess it's because implementing such feature on low-level can add big com=
plexity and perhaps slow-performance at times. </div><div></div></div>=
</blockquote><div><br></div><div>This can't be it, since they've been widel=
y implemented for a long time. The problems are deciding how much=
of the C99 feature to standardize, and how to prevent usage from locking u=
sers into old-style C arrays which are widely considered obsolete.</div><di=
v> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><table s=
tyle=3D"font-size:12.8000001907349px;color:rgb(0,0,0);font-family:DejaVuSan=
s,'DejaVu Sans',arial,sans-serif;line-height:15.3600006103516px"><tbody><tr=
><td style=3D"padding-top:0.5em;padding-bottom:0.5em;padding-left:1em;font-=
size:1em"><span style=3D"color:rgb(128,128,128);font-style:italic;line-heig=
ht:1.1em">noptr-declarator</span> <code style=3D"font-family:DejaVuSan=
sMono,'DejaVu Sans Mono',courier,monospace!important;background-color:trans=
parent"><b>[</b></code> <span style=3D"color:rgb(128,128,128);font-sty=
le:italic;line-height:1.1em">constexpr</span><span style=3D"color:rgb(0,128=
,0);font-size:0.8em;line-height:1.1em">(<wbr>optional)</span> <code st=
yle=3D"font-family:DejaVuSansMono,'DejaVu Sans Mono',courier,monospace!impo=
rtant;background-color:transparent"><b>]</b></code> <code style=3D"fon=
t-size:12.8000001907349px;line-height:15.3600006103516px;font-family:DejaVu=
SansMono,'DejaVu Sans Mono',courier,monospace!important"><b>virtual</b></co=
de><span style=3D"color:rgb(0,128,0);font-size:0.8em;line-height:1.1em">(op=
tional) </span><span style=3D"font-size:1em;color:rgb(128,128,128);fon=
t-style:italic;line-height:1.1em"><wbr>attr</span><span style=3D"color:rgb(=
0,128,0);font-size:0.8em;line-height:1.1em">(optional)</span></td></tr></tb=
ody></table></div></div></blockquote><div><br></div><div> This fails t=
o address either of those problems. Existing code would be left in the=
lurch, C compatibility is lost compared to the status quo, and there's no =
migration to a more modern style.</div></blockquote><div><br></div><div>Eve=
n if a 'modern-style' implementation is used 'C' compatibility will be lost=
too. I don't like those because such construct interfere with function sta=
ck and thus variables and function calls in it, which are built-int languag=
e constructs.</div><div><br></div><div>Also I really would like to suppose =
that 'C++' standard library can be implemented by using language built-in c=
onstructs and by using OS API's. Otherwise a big mess occurs - what are the=
language capacities - they can be hardly measured now.</div><div><br></div=
><div>Of-course standard library can provide some abstraction of this const=
ruct with classes like 'std::array', perhaps named 'std::varray' which will=
have the same capabilities as normal 'std::array' but with the possib=
ility to have dynamic size.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2872_826463971.1426426011742--
------=_Part_2871_1050472394.1426426011742--
.
Author: Alexander Nikolov <sasho648@mail.bg>
Date: Sun, 15 Mar 2015 06:30:42 -0700 (PDT)
Raw View
------=_Part_2699_794073211.1426426242574
Content-Type: multipart/alternative;
boundary="----=_Part_2700_1525074819.1426426242575"
------=_Part_2700_1525074819.1426426242575
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I just compare it to virtual functions as they require harder=20
implementation also. But the keyword isn't so important then that to have=
=20
one in order to warn the programmer.
=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 15 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=
=B3., 10:22:53 UTC+2, Douglas Boffey =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:
>
> In what way can a VLA be considered virtual, or are you just picking a=20
> keyword out of a hat?=20
>
> On 3/15/15, David Krauss <pot...@gmail.com <javascript:>> wrote:=20
> > On Sunday, March 15, 2015, Alexander Nikolov <sash...@mail.bg=20
> <javascript:>> wrote:=20
> >=20
> >> First any rationale for their prohibition?=20
> >>=20
> >=20
> > See the various papers. N3810 is an excellent review, although newer=20
> > proposals exist too.=20
> >=20
> >=20
> >>=20
> >> I can guess it's because implementing such feature on low-level can ad=
d=20
> >> big complexity and perhaps slow-performance at times.=20
> >>=20
> >=20
> > This can't be it, since they've been widely implemented for a long time=
..=20
> > The problems are deciding how much of the C99 feature to standardize,=
=20
> and=20
> > how to prevent usage from locking users into old-style C arrays which=
=20
> are=20
> > widely considered obsolete.=20
> >=20
> >=20
> >> noptr-declarator *[* constexpr(optional) *]* *virtual*(optional) attr=
=20
> >> (optional)=20
> >>=20
> >=20
> > This fails to address either of those problems. Existing code would be=
=20
> > left in the lurch, C compatibility is lost compared to the status quo,=
=20
> and=20
> > there's no migration to a more modern style.=20
> >=20
> > --=20
> >=20
> > ---=20
> > You received this message because you are subscribed to the Google=20
> Groups=20
> > "ISO C++ Standard - Future Proposals" group.=20
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an=20
> > email to std-proposal...@isocpp.org <javascript:>.=20
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..=20
>
> > Visit this group at=20
> > http://groups.google.com/a/isocpp.org/group/std-proposals/.=20
> >=20
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_2700_1525074819.1426426242575
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I just compare it to virtual functions as they require har=
der implementation also. But the keyword isn't so important then that to ha=
ve one in order to warn the programmer.<br><br>=D0=BD=D0=B5=D0=B4=D0=B5=D0=
=BB=D1=8F, 15 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 10:22:53 UTC+2, Dougla=
s Boffey =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">In what way can a VLA be considered virtual, or are you jus=
t picking a
<br>keyword out of a hat?
<br>
<br>On 3/15/15, David Krauss <<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"6ILmfDlyUa4J" rel=3D"nofollow" onmousedown=3D"this=
..href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;">pot...@gmail.com</a>> wrote:
<br>> On Sunday, March 15, 2015, Alexander Nikolov <<a href=3D"javasc=
ript:" target=3D"_blank" gdf-obfuscated-mailto=3D"6ILmfDlyUa4J" rel=3D"nofo=
llow" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"thi=
s.href=3D'javascript:';return true;">sash...@mail.bg</a>> wrote:
<br>>
<br>>> First any rationale for their prohibition?
<br>>>
<br>>
<br>> See the various papers. N3810 is an excellent review, although new=
er
<br>> proposals exist too.
<br>>
<br>>
<br>>>
<br>>> I can guess it's because implementing such feature on low-leve=
l can add
<br>>> big complexity and perhaps slow-performance at times.
<br>>>
<br>>
<br>> This can't be it, since they've been widely implemented for a long=
time.
<br>> The problems are deciding how much of the C99 feature to standardi=
ze, and
<br>> how to prevent usage from locking users into old-style C arrays wh=
ich are
<br>> widely considered obsolete.
<br>>
<br>>
<br>>> noptr-declarator *[* constexpr(optional) *]* *virtual*(optiona=
l) attr
<br>>> (optional)
<br>>>
<br>>
<br>> This fails to address either of those problems. Existing cod=
e would be
<br>> left in the lurch, C compatibility is lost compared to the status =
quo, and
<br>> there's no migration to a more modern style.
<br>>
<br>> --
<br>>
<br>> ---
<br>> You received this message because you are subscribed to the Google=
Groups
<br>> "ISO C++ Standard - Future Proposals" group.
<br>> To unsubscribe from this group and stop receiving emails from it, =
send an
<br>> email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"6ILmfDlyUa4J" rel=3D"nofollow" onmousedown=3D"this.href=3D'javasc=
ript:';return true;" onclick=3D"this.href=3D'javascript:';return true;">std=
-proposal...@<wbr>isocpp.org</a>.
<br>> To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"6ILmfDlyUa4J" rel=3D"nofollow" onmous=
edown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'ja=
vascript:';return true;">std-pr...@isocpp.org</a>.
<br>> Visit this group at
<br>> <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://=
groups.google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=
=3D"this.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/=
';return true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>p=
roposals/</a>.
<br>>
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2700_1525074819.1426426242575--
------=_Part_2699_794073211.1426426242574--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 15 Mar 2015 21:34:18 +0800
Raw View
--Apple-Mail=_6ED68232-648C-40CB-B3EF-B89FFD8FFFE1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9303=E2=80=9315, at 9:26 PM, Alexander Nikolov <sasho648@ma=
il.bg> wrote:
>=20
> Of-course standard library can provide some abstraction of this construct=
with classes like 'std::array', perhaps named 'std::varray' which will hav=
e the same capabilities as normal 'std::array' but with the possibility to =
have dynamic size.
You=E2=80=99re retracing the steps that lead to the present conundrum. Enca=
psulation is what I meant by =E2=80=9Cmodern style.=E2=80=9D Please review =
the papers, which already explain in detail.
--=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/.
--Apple-Mail=_6ED68232-648C-40CB-B3EF-B89FFD8FFFE1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9303=
=E2=80=9315, at 9:26 PM, Alexander Nikolov <<a href=3D"mailto:sasho648@m=
ail.bg" class=3D"">sasho648@mail.bg</a>> wrote:</div><br class=3D"Apple-=
interchange-newline"><div class=3D""><div dir=3D"ltr" style=3D"font-family:=
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font=
-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto=
; text-align: start; text-indent: 0px; text-transform: none; white-space: n=
ormal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" cl=
ass=3D"">Of-course standard library can provide some abstraction of this co=
nstruct with classes like 'std::array', perhaps named 'std::varray' which w=
ill have the same capabilities as normal 'std::array' but with the pos=
sibility to have dynamic size.</div></div></blockquote><div><br class=3D"">=
</div></div>You=E2=80=99re retracing the steps that lead to the present con=
undrum. Encapsulation is what I meant by =E2=80=9Cmodern style.=E2=80=9D Pl=
ease review the papers, which already explain in detail.</body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_6ED68232-648C-40CB-B3EF-B89FFD8FFFE1--
.
Author: 3dw4rd@verizon.net
Date: Mon, 16 Mar 2015 10:01:10 -0700 (PDT)
Raw View
------=_Part_894_1087609699.1426525270403
Content-Type: multipart/alternative;
boundary="----=_Part_895_75407829.1426525270403"
------=_Part_895_75407829.1426525270403
Content-Type: text/plain; charset=UTF-8
On Saturday, March 14, 2015 at 8:40:01 PM UTC-4, Alexander Nikolov wrote:
>
> First any rationale for their prohibition?
>
It seemed to me that a raw VLA was (rightfully IMO) considered too
low-level on its own. The committee insisted that a library container-like
tool with C++ contiguous container semantics were added. The problem is
that no agreement could be found for the semantics of that container. How
do you deal with a container that grew beyond the allowed stack size? Do
you even know what that is? What about dynarray inside a class object....
Some wanted dynarray to be able to allocate on the heap or be able to move
to the heap in that case. Some wanted the dynarray to be always on the
stack and non-movable.
FWIW I always thought dynarray was backwards. I think you want regular
on-heap containers far more often than you want automatic arrays. I think
a static_array_view or an automatic_array_view that is only used in the
rare occasions that you need to copy to the current stack frame and work
fast. This container would be unmovable. It could be constructed from a
container or a range and could copy it's contents back to the container on
destruction.
I have to admit that if the container size is larger than the maximum
dynaview size then we'd want windowing which copying and reading would slow
things down. But that still might be better than a STL container. Also,
the folks who use automatic duration containers for speed might want the
opportunity to tune sizes and strategies...
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_895_75407829.1426525270403
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, March 14, 2015 at 8:40:01 PM UTC-4, A=
lexander Nikolov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr">First any rationale for their prohibition?<div></div></div></bloc=
kquote><div><br>It seemed to me that a raw VLA was (rightfully IMO) conside=
red too low-level on its own. The committee insisted that a library c=
ontainer-like tool with C++ contiguous container semantics were added. =
; The problem is that no agreement could be found for the semantics of that=
container. How do you deal with a container that grew beyond the all=
owed stack size? Do you even know what that is? What about dyna=
rray inside a class object.... Some wanted dynarray to be able to all=
ocate on the heap or be able to move to the heap in that case. Some w=
anted the dynarray to be always on the stack and non-movable.<br><br>FWIW I=
always thought dynarray was backwards. I think you want regular on-h=
eap containers far more often than you want automatic arrays. I think=
a static_array_view or an automatic_array_view that is only used in the ra=
re occasions that you need to copy to the current stack frame and work fast=
.. This container would be unmovable. It could be constructed fr=
om a container or a range and could copy it's contents back to the containe=
r on destruction.<br>I have to admit that if the container size is larger t=
han the maximum dynaview size then we'd want windowing which copying and re=
ading would slow things down. But that still might be better than a S=
TL container. Also, the folks who use automatic duration containers f=
or speed might want the opportunity to tune sizes and strategies...<br></di=
v></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_895_75407829.1426525270403--
------=_Part_894_1087609699.1426525270403--
.