Topic: Thumbs Up for No Graphics
Author: mihailnajdenov@gmail.com
Date: Fri, 1 Jun 2018 05:00:48 -0700 (PDT)
Raw View
------=_Part_9962_1464043341.1527854448902
Content-Type: multipart/alternative;
boundary="----=_Part_9963_515287120.1527854448902"
------=_Part_9963_515287120.1527854448902
Content-Type: text/plain; charset="UTF-8"
Hello, I recently stumbled into p1062R0 (Diet Graphics)
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html>
I wholeheartedly agree, the Committee should not pursue *any* from of
"Graphics Programing".
Here is why:
- *Impossible* to keep up-to date with modern trends - *both* hardware,
algorithms and APIs to address the hardware change all the time.
- *Impossible *to look (or perform) nearly the same on all platforms or
implementations.
- *Impossible* to be complete and useful for the real world - useful
graphics programming framework is way bigger the standard library itself!
- *Impossible* to keep up to date in terms of user requests - new
primitives, strokes, colors, brushes, filters, helper functions,
customization points, etc etc etc etc etc
- *Heavy* *burden* on the implementations.
- *Limited use *as a percent of c++ community in comparison to many other
features and libraries, including higher level ones like filesystem
- *Will open the floodgates* for *Proposals Related To Graphics* *and* *Proposals
Which Build On Top Of Graphics, *which the Committee (and the community)
will waste time considering, probably without even having the expertise for
that!
--
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/7915a73c-e305-4bce-bf6e-28f20a7faccb%40isocpp.org.
------=_Part_9963_515287120.1527854448902
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hello, I recently stumbled into=C2=A0<a href=3D"http:=
//www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html">p1062R0 (D=
iet Graphics)</a></div><div><br></div><div>I wholeheartedly agree, the Comm=
ittee should not pursue <i>any</i> from of "Graphics Programing".=
</div><div><br></div><div>Here is why:</div><div>=C2=A0- <b>Impossible</b> =
to keep up-to date with modern trends - <i>both</i> hardware, algorithms an=
d APIs to address the hardware change all the time.</div><div><span style=
=3D"display: inline !important; float: none; background-color: transparent;=
color: rgb(34, 34, 34); font-family: "Arial","Helvetica&quo=
t;,sans-serif; font-size: 13px; font-style: normal; font-variant: normal; f=
ont-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text=
-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-str=
oke-width: 0px; white-space: normal; word-spacing: 0px;">=C2=A0- </span><b =
style=3D"background-attachment: scroll; background-clip: border-box; backgr=
ound-color: transparent; background-image: none; background-origin: padding=
-box; background-position-x: 0%; background-position-y: 0%; background-repe=
at: repeat; background-size: auto; border-bottom-color: rgb(34, 34, 34); bo=
rder-bottom-style: none; border-bottom-width: 0px; border-image-outset: 0; =
border-image-repeat: stretch; border-image-slice: 100%; border-image-source=
: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); border-l=
eft-style: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34=
); border-right-style: none; border-right-width: 0px; border-top-color: rgb=
(34, 34, 34); border-top-style: none; border-top-width: 0px; color: rgb(34,=
34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&qu=
ot;,sans-serif; font-size: 13px; font-style: normal; font-variant: normal; =
font-weight: 700; height: auto; letter-spacing: normal; margin-bottom: 0px;=
margin-left: 0px; margin-right: 0px; margin-top: 0px; min-width: 0px; orph=
ans: 2; overflow: visible; overflow-x: visible; overflow-y: visible; paddin=
g-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; tex=
t-align: left; text-decoration: none; text-indent: 0px; text-transform: non=
e; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"=
>Impossible </b><span style=3D"display: inline !important; float: none; bac=
kground-color: transparent; color: rgb(34, 34, 34); font-family: "Aria=
l","Helvetica",sans-serif; font-size: 13px; font-style: norm=
al; font-variant: normal; font-weight: 400; letter-spacing: normal; orphans=
: 2; text-align: left; text-decoration: none; text-indent: 0px; text-transf=
orm: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacin=
g: 0px;">to look (or perform) nearly the same on all platforms or <span sty=
le=3D"display: inline !important; float: none; background-color: transparen=
t; color: rgb(34, 34, 34); font-family: "Arial","Helvetica&q=
uot;,sans-serif; font-size: 13px; font-style: normal; font-variant: normal;=
font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; te=
xt-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-s=
troke-width: 0px; white-space: normal; word-spacing: 0px;">implementations<=
/span>.</span><span style=3D"display: inline !important; float: none; backg=
round-color: transparent; color: rgb(34, 34, 34); font-family: "Arial&=
quot;,"Helvetica",sans-serif; font-size: 13px; font-style: normal=
; font-variant: normal; font-weight: 400; letter-spacing: normal; orphans: =
2; text-align: left; text-decoration: none; text-indent: 0px; text-transfor=
m: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing:=
0px;">=C2=A0</span><br></div><div>=C2=A0- <b>Impossible</b> to be complete=
and useful for the real world - useful graphics programming framework is w=
ay bigger the standard library itself!</div><div>=C2=A0- <b>Impossible</b> =
to keep up to date in terms of user requests - new primitives, strokes, col=
ors, brushes, filters, helper functions, customization points, etc etc etc =
etc etc</div><div><span style=3D"display: inline !important; float: none; b=
ackground-color: transparent; color: rgb(34, 34, 34); font-family: "Ar=
ial","Helvetica",sans-serif; font-size: 13px; font-style: no=
rmal; font-variant: normal; font-weight: 400; letter-spacing: normal; orpha=
ns: 2; text-align: left; text-decoration: none; text-indent: 0px; text-tran=
sform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spac=
ing: 0px;">=C2=A0- </span><b style=3D"background-attachment: scroll; backgr=
ound-clip: border-box; background-color: transparent; background-image: non=
e; background-origin: padding-box; background-position-x: 0%; background-po=
sition-y: 0%; background-repeat: repeat; background-size: auto; border-bott=
om-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: =
0px; border-image-outset: 0; border-image-repeat: stretch; border-image-sli=
ce: 100%; border-image-source: none; border-image-width: 1; border-left-col=
or: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; borde=
r-right-color: rgb(34, 34, 34); border-right-style: none; border-right-widt=
h: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-t=
op-width: 0px; color: rgb(34, 34, 34); font-family: &quot;Arial&quo=
t;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: n=
ormal; font-variant: normal; font-weight: 700; height: auto; letter-spacing=
: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-t=
op: 0px; min-width: 0px; orphans: 2; overflow: visible; overflow-x: visible=
; overflow-y: visible; padding-bottom: 0px; padding-left: 0px; padding-righ=
t: 0px; padding-top: 0px; text-align: left; text-decoration: none; text-ind=
ent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space=
: normal; word-spacing: 0px;">Heavy</b><span style=3D"display: inline !impo=
rtant; float: none; background-color: transparent; color: rgb(34, 34, 34); =
font-family: "Arial","Helvetica",sans-serif; font-size:=
13px; font-style: normal; font-variant: normal; font-weight: 400; letter-s=
pacing: normal; orphans: 2; text-align: left; text-decoration: none; text-i=
ndent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-spa=
ce: normal; word-spacing: 0px;"> <b>burden</b> on the implementations.=C2=
=A0</span><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br><=
/div><div>=C2=A0- <b>Limited use </b>as a percent of c++ community in compa=
rison to many other features and libraries, including higher level ones lik=
e filesystem=C2=A0</div><div>=C2=A0- <b>Will open the floodgates</b> for <i=
>Proposals Related To Graphics</i> <b>and</b> <i>Proposals Which Build On T=
op Of Graphics, </i>which the Committee (and the community) will waste time=
considering, probably without even having the expertise for that!</div><di=
v>=C2=A0</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" 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/7915a73c-e305-4bce-bf6e-28f20a7faccb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7915a73c-e305-4bce-bf6e-28f20a7faccb=
%40isocpp.org</a>.<br />
------=_Part_9963_515287120.1527854448902--
------=_Part_9962_1464043341.1527854448902--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Fri, 1 Jun 2018 16:15:23 +0200
Raw View
--000000000000b3bbb2056d9537f8
Content-Type: text/plain; charset="UTF-8"
> I wholeheartedly agree, the Committee should not pursue *any* from of
"Graphics Programing".
While I agree that a Noddy-style 2d line-drawing library is of no use to
anyone, I strongly feel that there should be a standardised 3d graphics,
sound and human interface library, and damn the difficulties. I'm not
arguing that every compiler vendor ships a fully functioning library, but
if they do there should be a standard so that vendors can report levels of
compliance.
At the moment, collecting together all the bits and pieces to build a
cross-platform graphics engine is just too much work. In the end you give
up the will to continue and switch to an inferior language with better
support.
In my view this is a shame.
On Fri, 1 Jun 2018 at 14:00, <mihailnajdenov@gmail.com> wrote:
> Hello, I recently stumbled into p1062R0 (Diet Graphics)
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html>
>
> I wholeheartedly agree, the Committee should not pursue *any* from of
> "Graphics Programing".
>
> Here is why:
> - *Impossible* to keep up-to date with modern trends - *both* hardware,
> algorithms and APIs to address the hardware change all the time.
> - *Impossible *to look (or perform) nearly the same on all platforms or
> implementations.
> - *Impossible* to be complete and useful for the real world - useful
> graphics programming framework is way bigger the standard library itself!
> - *Impossible* to keep up to date in terms of user requests - new
> primitives, strokes, colors, brushes, filters, helper functions,
> customization points, etc etc etc etc etc
> - *Heavy* *burden* on the implementations.
> - *Limited use *as a percent of c++ community in comparison to many
> other features and libraries, including higher level ones like filesystem
> - *Will open the floodgates* for *Proposals Related To Graphics* *and* *Proposals
> Which Build On Top Of Graphics, *which the Committee (and the community)
> will waste time considering, probably without even having the expertise for
> that!
>
>
> --
> 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/7915a73c-e305-4bce-bf6e-28f20a7faccb%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7915a73c-e305-4bce-bf6e-28f20a7faccb%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/CALvx3hZ0Ouf4OgeeaeVjYvVP3n61AWBn3f6%3DH2-3A2hMPxGzVg%40mail.gmail.com.
--000000000000b3bbb2056d9537f8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"color:rgb(34,34,34);font-family:s=
ans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;fo=
nt-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:sta=
rt;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;=
background-color:rgb(255,255,255);text-decoration-style:initial;text-decora=
tion-color:initial;float:none;display:inline">I wholeheartedly agree, the C=
ommittee should not pursue<span>=C2=A0</span></span><i style=3D"color:rgb(3=
4,34,34);font-family:sans-serif;font-size:13px;font-variant-ligatures:norma=
l;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align=
:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:=
0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-de=
coration-color:initial">any</i><span style=3D"color:rgb(34,34,34);font-fami=
ly:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:norma=
l;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align=
:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:=
0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-de=
coration-color:initial;float:none;display:inline"><span>=C2=A0</span>from o=
f "Graphics Programing".</span><div><span style=3D"color:rgb(34,3=
4,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-=
ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:no=
rmal;text-align:start;text-indent:0px;text-transform:none;white-space:norma=
l;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:=
initial;text-decoration-color:initial;float:none;display:inline"><br></span=
></div><div><span style=3D"color:rgb(34,34,34);font-family:sans-serif;font-=
size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps=
:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:=
0px;text-transform:none;white-space:normal;word-spacing:0px;background-colo=
r:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:init=
ial;float:none;display:inline">While I agree that a Noddy-style 2d line-dra=
wing library is of no use to anyone, I strongly feel that there should be a=
standardised 3d graphics, sound and human interface library, and damn the =
difficulties. I'm not arguing that every compiler vendor ships a fully =
functioning library, but if they do there should be a standard so that vend=
ors can report levels of compliance.</span></div><div><span style=3D"color:=
rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-=
variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-sp=
acing:normal;text-align:start;text-indent:0px;text-transform:none;white-spa=
ce:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoratio=
n-style:initial;text-decoration-color:initial;float:none;display:inline"><b=
r></span></div><div>At the moment, collecting together all the bits and pie=
ces to build a cross-platform graphics engine is just too much work. In the=
end you give up the will to continue and switch to an inferior language wi=
th better support.<br></div><div><span style=3D"color:rgb(34,34,34);font-fa=
mily:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:nor=
mal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-ali=
gn:start;text-indent:0px;text-transform:none;white-space:normal;word-spacin=
g:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-=
decoration-color:initial;float:none;display:inline"><br></span></div><div><=
span style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;fon=
t-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-=
weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-tran=
sform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255=
,255);text-decoration-style:initial;text-decoration-color:initial;float:non=
e;display:inline">In my view this is a shame.</span></div><div><span style=
=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:no=
rmal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400=
;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none=
;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text=
-decoration-style:initial;text-decoration-color:initial;float:none;display:=
inline"><br></span></div></div><br><div class=3D"gmail_quote"><div dir=3D"l=
tr">On Fri, 1 Jun 2018 at 14:00, <<a href=3D"mailto:mihailnajdenov@gmail=
..com">mihailnajdenov@gmail.com</a>> wrote:<br></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>Hello, I recently stumbled into=C2=A0<a hr=
ef=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html"=
target=3D"_blank">p1062R0 (Diet Graphics)</a></div><div><br></div><div>I w=
holeheartedly agree, the Committee should not pursue <i>any</i> from of &qu=
ot;Graphics Programing".</div><div><br></div><div>Here is why:</div><d=
iv>=C2=A0- <b>Impossible</b> to keep up-to date with modern trends - <i>bot=
h</i> hardware, algorithms and APIs to address the hardware change all the =
time.</div><div><span style=3D"display:inline!important;float:none;backgrou=
nd-color:transparent;color:rgb(34,34,34);font-family:"Arial",&quo=
t;Helvetica",sans-serif;font-size:13px;font-style:normal;font-variant:=
normal;font-weight:400;letter-spacing:normal;text-align:left;text-decoratio=
n:none;text-indent:0px;text-transform:none;white-space:normal;word-spacing:=
0px">=C2=A0- </span><b>Impossible </b><span style=3D"display:inline!importa=
nt;float:none;background-color:transparent;color:rgb(34,34,34);font-family:=
"Arial","Helvetica",sans-serif;font-size:13px;font-styl=
e:normal;font-variant:normal;font-weight:400;letter-spacing:normal;text-ali=
gn:left;text-decoration:none;text-indent:0px;text-transform:none;white-spac=
e:normal;word-spacing:0px">to look (or perform) nearly the same on all plat=
forms or <span style=3D"display:inline!important;float:none;background-colo=
r:transparent;color:rgb(34,34,34);font-family:"Arial","Helve=
tica",sans-serif;font-size:13px;font-style:normal;font-variant:normal;=
font-weight:400;letter-spacing:normal;text-align:left;text-decoration:none;=
text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">im=
plementations</span>.</span><span style=3D"display:inline!important;float:n=
one;background-color:transparent;color:rgb(34,34,34);font-family:"Aria=
l","Helvetica",sans-serif;font-size:13px;font-style:normal;f=
ont-variant:normal;font-weight:400;letter-spacing:normal;text-align:left;te=
xt-decoration:none;text-indent:0px;text-transform:none;white-space:normal;w=
ord-spacing:0px">=C2=A0</span><br></div><div>=C2=A0- <b>Impossible</b> to b=
e complete and useful for the real world - useful graphics programming fram=
ework is way bigger the standard library itself!</div><div>=C2=A0- <b>Impos=
sible</b> to keep up to date in terms of user requests - new primitives, st=
rokes, colors, brushes, filters, helper functions, customization points, et=
c etc etc etc etc</div><div><span style=3D"display:inline!important;float:n=
one;background-color:transparent;color:rgb(34,34,34);font-family:"Aria=
l","Helvetica",sans-serif;font-size:13px;font-style:normal;f=
ont-variant:normal;font-weight:400;letter-spacing:normal;text-align:left;te=
xt-decoration:none;text-indent:0px;text-transform:none;white-space:normal;w=
ord-spacing:0px">=C2=A0- </span><b>Heavy</b><span style=3D"display:inline!i=
mportant;float:none;background-color:transparent;color:rgb(34,34,34);font-f=
amily:"Arial","Helvetica",sans-serif;font-size:13px;fon=
t-style:normal;font-variant:normal;font-weight:400;letter-spacing:normal;te=
xt-align:left;text-decoration:none;text-indent:0px;text-transform:none;whit=
e-space:normal;word-spacing:0px"> <b>burden</b> on the implementations.=C2=
=A0</span><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br><=
/div><div>=C2=A0- <b>Limited use </b>as a percent of c++ community in compa=
rison to many other features and libraries, including higher level ones lik=
e filesystem=C2=A0</div><div>=C2=A0- <b>Will open the floodgates</b> for <i=
>Proposals Related To Graphics</i> <b>and</b> <i>Proposals Which Build On T=
op Of Graphics, </i>which the Committee (and the community) will waste time=
considering, probably without even having the expertise for that!</div><di=
v>=C2=A0</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" 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@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7915a73c-e305-4bce-bf6e-28f20a7faccb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7915a73c-e305-=
4bce-bf6e-28f20a7faccb%40isocpp.org</a>.<br>
</blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ0Ouf4OgeeaeVjYvVP3n61AWBn3f6%=
3DH2-3A2hMPxGzVg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ0Ouf4Og=
eeaeVjYvVP3n61AWBn3f6%3DH2-3A2hMPxGzVg%40mail.gmail.com</a>.<br />
--000000000000b3bbb2056d9537f8--
.
Author: Corentin <corentin.jabot@gmail.com>
Date: Fri, 1 Jun 2018 16:29:36 +0200
Raw View
--00000000000088532c056d956a91
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> At the moment, collecting together all the bits and pieces to build a
cross-platform graphics engine is just too much work. In the end you give
up the will to continue and switch to an inferior language with better
support.
I think most people would agree with that observation.
But what we need is a better way to collecting bits and pieces, not to put
the whole world in the standard to make up for insufficient tooling !
Le ven. 1 juin 2018 =C3=A0 16:15, Richard Hodges <hodges.r@gmail.com> a =C3=
=A9crit :
> > I wholeheartedly agree, the Committee should not pursue *any* from of
> "Graphics Programing".
>
> While I agree that a Noddy-style 2d line-drawing library is of no use to
> anyone, I strongly feel that there should be a standardised 3d graphics,
> sound and human interface library, and damn the difficulties. I'm not
> arguing that every compiler vendor ships a fully functioning library, but
> if they do there should be a standard so that vendors can report levels o=
f
> compliance.
>
> At the moment, collecting together all the bits and pieces to build a
> cross-platform graphics engine is just too much work. In the end you give
> up the will to continue and switch to an inferior language with better
> support.
>
> In my view this is a shame.
>
>
> On Fri, 1 Jun 2018 at 14:00, <mihailnajdenov@gmail.com> wrote:
>
>> Hello, I recently stumbled into p1062R0 (Diet Graphics)
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html>
>>
>> I wholeheartedly agree, the Committee should not pursue *any* from of
>> "Graphics Programing".
>>
>> Here is why:
>> - *Impossible* to keep up-to date with modern trends - *both* hardware,
>> algorithms and APIs to address the hardware change all the time.
>> - *Impossible *to look (or perform) nearly the same on all platforms or
>> implementations.
>> - *Impossible* to be complete and useful for the real world - useful
>> graphics programming framework is way bigger the standard library itself=
!
>> - *Impossible* to keep up to date in terms of user requests - new
>> primitives, strokes, colors, brushes, filters, helper functions,
>> customization points, etc etc etc etc etc
>> - *Heavy* *burden* on the implementations.
>> - *Limited use *as a percent of c++ community in comparison to many
>> other features and libraries, including higher level ones like filesyste=
m
>> - *Will open the floodgates* for *Proposals Related To Graphics* *and* =
*Proposals
>> Which Build On Top Of Graphics, *which the Committee (and the community)
>> will waste time considering, probably without even having the expertise =
for
>> that!
>>
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/7915a73c-e3=
05-4bce-bf6e-28f20a7faccb%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7915a73c-e=
305-4bce-bf6e-28f20a7faccb%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
> --
> 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/CALvx3hZ0Ouf=
4OgeeaeVjYvVP3n61AWBn3f6%3DH2-3A2hMPxGzVg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ0Ou=
f4OgeeaeVjYvVP3n61AWBn3f6%3DH2-3A2hMPxGzVg%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>
--=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/CA%2BOm%2BSjxfeHSdw%3DDPJGFBJFJtH1NgQ19tH%3DWY5K=
qKCKkzs-fPg%40mail.gmail.com.
--00000000000088532c056d956a91
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"color:rgb(33,33,33)">At the momen=
t, collecting together all the bits and pieces to build a cross-platform gr=
aphics engine is just too much work. In the end you give up the will to con=
tinue and switch to an inferior language with better support.</span><div><b=
r></div><div>I think most people would agree with that observation.=C2=A0</=
div><div>But what we need is a better way to collecting bits and pieces, no=
t to put the whole world in the standard to make up for insufficient toolin=
g !</div><div><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">Le=
=C2=A0ven. 1 juin 2018 =C3=A0=C2=A016:15, Richard Hodges <<a href=3D"mai=
lto:hodges.r@gmail.com">hodges.r@gmail.com</a>> a =C3=A9crit=C2=A0:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">>=C2=A0<span style=
=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:no=
rmal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400=
;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none=
;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text=
-decoration-style:initial;text-decoration-color:initial;float:none;display:=
inline">I wholeheartedly agree, the Committee should not pursue<span>=C2=A0=
</span></span><i style=3D"color:rgb(34,34,34);font-family:sans-serif;font-s=
ize:13px;font-variant-ligatures:normal;font-variant-caps:normal;font-weight=
:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:=
none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);=
text-decoration-style:initial;text-decoration-color:initial">any</i><span s=
tyle=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-styl=
e:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight=
:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:=
none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);=
text-decoration-style:initial;text-decoration-color:initial;float:none;disp=
lay:inline"><span>=C2=A0</span>from of "Graphics Programing".</sp=
an><div><span style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size=
:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:nor=
mal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;=
text-transform:none;white-space:normal;word-spacing:0px;background-color:rg=
b(255,255,255);text-decoration-style:initial;text-decoration-color:initial;=
float:none;display:inline"><br></span></div></div><div dir=3D"ltr"><div><sp=
an style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-=
style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-we=
ight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transf=
orm:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,2=
55);text-decoration-style:initial;text-decoration-color:initial;float:none;=
display:inline">While I agree that a Noddy-style 2d line-drawing library is=
of no use to anyone, I strongly feel that there should be a standardised 3=
d graphics, sound and human interface library, and damn the difficulties. I=
'm not arguing that every compiler vendor ships a fully functioning lib=
rary, but if they do there should be a standard so that vendors can report =
levels of compliance.</span></div><div><span style=3D"color:rgb(34,34,34);f=
ont-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatur=
es:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;te=
xt-align:start;text-indent:0px;text-transform:none;white-space:normal;word-=
spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial=
;text-decoration-color:initial;float:none;display:inline"><br></span></div>=
<div>At the moment, collecting together all the bits and pieces to build a =
cross-platform graphics engine is just too much work. In the end you give u=
p the will to continue and switch to an inferior language with better suppo=
rt.<br></div><div><span style=3D"color:rgb(34,34,34);font-family:sans-serif=
;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-varian=
t-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-i=
ndent:0px;text-transform:none;white-space:normal;word-spacing:0px;backgroun=
d-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-colo=
r:initial;float:none;display:inline"><br></span></div><div><span style=3D"c=
olor:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;=
font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;lett=
er-spacing:normal;text-align:start;text-indent:0px;text-transform:none;whit=
e-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-deco=
ration-style:initial;text-decoration-color:initial;float:none;display:inlin=
e">In my view this is a shame.</span></div><div><span style=3D"color:rgb(34=
,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-varian=
t-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:=
normal;text-align:start;text-indent:0px;text-transform:none;white-space:nor=
mal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-styl=
e:initial;text-decoration-color:initial;float:none;display:inline"><br></sp=
an></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, 1 Ju=
n 2018 at 14:00, <<a href=3D"mailto:mihailnajdenov@gmail.com" target=3D"=
_blank">mihailnajdenov@gmail.com</a>> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div>Hello, I recently stumbled into=C2=A0<a=
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.ht=
ml" target=3D"_blank">p1062R0 (Diet Graphics)</a></div><div><br></div><div>=
I wholeheartedly agree, the Committee should not pursue <i>any</i> from of =
"Graphics Programing".</div><div><br></div><div>Here is why:</div=
><div>=C2=A0- <b>Impossible</b> to keep up-to date with modern trends - <i>=
both</i> hardware, algorithms and APIs to address the hardware change all t=
he time.</div><div><span style=3D"display:inline!important;float:none;backg=
round-color:transparent;color:rgb(34,34,34);font-family:"Arial",&=
quot;Helvetica",sans-serif;font-size:13px;font-style:normal;font-varia=
nt:normal;font-weight:400;letter-spacing:normal;text-align:left;text-decora=
tion:none;text-indent:0px;text-transform:none;white-space:normal;word-spaci=
ng:0px">=C2=A0- </span><b>Impossible </b><span style=3D"display:inline!impo=
rtant;float:none;background-color:transparent;color:rgb(34,34,34);font-fami=
ly:"Arial","Helvetica",sans-serif;font-size:13px;font-s=
tyle:normal;font-variant:normal;font-weight:400;letter-spacing:normal;text-=
align:left;text-decoration:none;text-indent:0px;text-transform:none;white-s=
pace:normal;word-spacing:0px">to look (or perform) nearly the same on all p=
latforms or <span style=3D"display:inline!important;float:none;background-c=
olor:transparent;color:rgb(34,34,34);font-family:"Arial","He=
lvetica",sans-serif;font-size:13px;font-style:normal;font-variant:norm=
al;font-weight:400;letter-spacing:normal;text-align:left;text-decoration:no=
ne;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"=
>implementations</span>.</span><span style=3D"display:inline!important;floa=
t:none;background-color:transparent;color:rgb(34,34,34);font-family:"A=
rial","Helvetica",sans-serif;font-size:13px;font-style:norma=
l;font-variant:normal;font-weight:400;letter-spacing:normal;text-align:left=
;text-decoration:none;text-indent:0px;text-transform:none;white-space:norma=
l;word-spacing:0px">=C2=A0</span><br></div><div>=C2=A0- <b>Impossible</b> t=
o be complete and useful for the real world - useful graphics programming f=
ramework is way bigger the standard library itself!</div><div>=C2=A0- <b>Im=
possible</b> to keep up to date in terms of user requests - new primitives,=
strokes, colors, brushes, filters, helper functions, customization points,=
etc etc etc etc etc</div><div><span style=3D"display:inline!important;floa=
t:none;background-color:transparent;color:rgb(34,34,34);font-family:"A=
rial","Helvetica",sans-serif;font-size:13px;font-style:norma=
l;font-variant:normal;font-weight:400;letter-spacing:normal;text-align:left=
;text-decoration:none;text-indent:0px;text-transform:none;white-space:norma=
l;word-spacing:0px">=C2=A0- </span><b>Heavy</b><span style=3D"display:inlin=
e!important;float:none;background-color:transparent;color:rgb(34,34,34);fon=
t-family:"Arial","Helvetica",sans-serif;font-size:13px;=
font-style:normal;font-variant:normal;font-weight:400;letter-spacing:normal=
;text-align:left;text-decoration:none;text-indent:0px;text-transform:none;w=
hite-space:normal;word-spacing:0px"> <b>burden</b> on the implementations.=
=C2=A0</span><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><b=
r></div><div>=C2=A0- <b>Limited use </b>as a percent of c++ community in co=
mparison to many other features and libraries, including higher level ones =
like filesystem=C2=A0</div><div>=C2=A0- <b>Will open the floodgates</b> for=
<i>Proposals Related To Graphics</i> <b>and</b> <i>Proposals Which Build O=
n Top Of Graphics, </i>which the Committee (and the community) will waste t=
ime considering, probably without even having the expertise for that!</div>=
<div>=C2=A0</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" 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@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7915a73c-e305-4bce-bf6e-28f20a7faccb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7915a73c-e305-=
4bce-bf6e-28f20a7faccb%40isocpp.org</a>.<br>
</blockquote></div>
<p></p>
-- <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" target=3D"_=
blank">std-proposals+unsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ0Ouf4OgeeaeVjYvVP3n61AWBn3f6%=
3DH2-3A2hMPxGzVg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CALvx3hZ0Ouf4OgeeaeVjYvVP3n61AWBn3f6%3DH2-3A2hMPxGzVg%40mail.gmail.c=
om</a>.<br>
</blockquote></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2BSjxfeHSdw%3DDPJGFBJFJtH1NgQ=
19tH%3DWY5KqKCKkzs-fPg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2=
BSjxfeHSdw%3DDPJGFBJFJtH1NgQ19tH%3DWY5KqKCKkzs-fPg%40mail.gmail.com</a>.<br=
/>
--00000000000088532c056d956a91--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Fri, 1 Jun 2018 15:32:50 +0100
Raw View
--0000000000000be226056d957632
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> But what we need is a better way to collecting bits and pieces, not to
put the whole world in the standard to make up for insufficient tooling !
A standard way, even?
On Fri, 1 Jun 2018 at 15:29, Corentin <corentin.jabot@gmail.com> wrote:
> > At the moment, collecting together all the bits and pieces to build a
> cross-platform graphics engine is just too much work. In the end you give
> up the will to continue and switch to an inferior language with better
> support.
>
> I think most people would agree with that observation.
> But what we need is a better way to collecting bits and pieces, not to pu=
t
> the whole world in the standard to make up for insufficient tooling !
>
>
> Le ven. 1 juin 2018 =C3=A0 16:15, Richard Hodges <hodges.r@gmail.com> a =
=C3=A9crit :
>
>> > I wholeheartedly agree, the Committee should not pursue *any* from of
>> "Graphics Programing".
>>
>> While I agree that a Noddy-style 2d line-drawing library is of no use to
>> anyone, I strongly feel that there should be a standardised 3d graphics,
>> sound and human interface library, and damn the difficulties. I'm not
>> arguing that every compiler vendor ships a fully functioning library, bu=
t
>> if they do there should be a standard so that vendors can report levels =
of
>> compliance.
>>
>> At the moment, collecting together all the bits and pieces to build a
>> cross-platform graphics engine is just too much work. In the end you giv=
e
>> up the will to continue and switch to an inferior language with better
>> support.
>>
>> In my view this is a shame.
>>
>>
>> On Fri, 1 Jun 2018 at 14:00, <mihailnajdenov@gmail.com> wrote:
>>
>>> Hello, I recently stumbled into p1062R0 (Diet Graphics)
>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html>
>>>
>>> I wholeheartedly agree, the Committee should not pursue *any* from of
>>> "Graphics Programing".
>>>
>>> Here is why:
>>> - *Impossible* to keep up-to date with modern trends - *both*
>>> hardware, algorithms and APIs to address the hardware change all the ti=
me.
>>> - *Impossible *to look (or perform) nearly the same on all platforms
>>> or implementations.
>>> - *Impossible* to be complete and useful for the real world - useful
>>> graphics programming framework is way bigger the standard library itsel=
f!
>>> - *Impossible* to keep up to date in terms of user requests - new
>>> primitives, strokes, colors, brushes, filters, helper functions,
>>> customization points, etc etc etc etc etc
>>> - *Heavy* *burden* on the implementations.
>>> - *Limited use *as a percent of c++ community in comparison to many
>>> other features and libraries, including higher level ones like filesyst=
em
>>> - *Will open the floodgates* for *Proposals Related To Graphics* *and*=
*Proposals
>>> Which Build On Top Of Graphics, *which the Committee (and the
>>> community) will waste time considering, probably without even having th=
e
>>> expertise for that!
>>>
>>>
>>> --
>>> 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/7915a73c-e=
305-4bce-bf6e-28f20a7faccb%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7915a73c-=
e305-4bce-bf6e-28f20a7faccb%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/CALvx3hZ0Ou=
f4OgeeaeVjYvVP3n61AWBn3f6%3DH2-3A2hMPxGzVg%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ0O=
uf4OgeeaeVjYvVP3n61AWBn3f6%3DH2-3A2hMPxGzVg%40mail.gmail.com?utm_medium=3De=
mail&utm_source=3Dfooter>
>> .
>>
> --
> 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/CA%2BOm%2BSj=
xfeHSdw%3DDPJGFBJFJtH1NgQ19tH%3DWY5KqKCKkzs-fPg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2BS=
jxfeHSdw%3DDPJGFBJFJtH1NgQ19tH%3DWY5KqKCKkzs-fPg%40mail.gmail.com?utm_mediu=
m=3Demail&utm_source=3Dfooter>
> .
>
--=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/CALvx3hbeANpuC-O%3DEWxH206KG%3DWDrFwCiruoxc_02rf=
DooZcNg%40mail.gmail.com.
--0000000000000be226056d957632
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"color:rgb(34,34,34);font-family:s=
ans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;fo=
nt-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:sta=
rt;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;=
background-color:rgb(255,255,255);text-decoration-style:initial;text-decora=
tion-color:initial;float:none;display:inline">But what we need is a better =
way to collecting bits and pieces, not to put the whole world in the standa=
rd to make up for insufficient tooling !</span><div><span style=3D"color:rg=
b(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-va=
riant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spac=
ing:normal;text-align:start;text-indent:0px;text-transform:none;white-space=
:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-=
style:initial;text-decoration-color:initial;float:none;display:inline"><br>=
</span></div><div>A standard way, even?</div><div><br></div></div><br><div =
class=3D"gmail_quote"><div dir=3D"ltr">On Fri, 1 Jun 2018 at 15:29, Corenti=
n <<a href=3D"mailto:corentin.jabot@gmail.com">corentin.jabot@gmail.com<=
/a>> wrote:<br></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">>=
;=C2=A0<span style=3D"color:rgb(33,33,33)">At the moment, collecting togeth=
er all the bits and pieces to build a cross-platform graphics engine is jus=
t too much work. In the end you give up the will to continue and switch to =
an inferior language with better support.</span><div><br></div><div>I think=
most people would agree with that observation.=C2=A0</div><div>But what we=
need is a better way to collecting bits and pieces, not to put the whole w=
orld in the standard to make up for insufficient tooling !</div><div><br></=
div><br><div class=3D"gmail_quote"><div dir=3D"ltr">Le=C2=A0ven. 1 juin 201=
8 =C3=A0=C2=A016:15, Richard Hodges <<a href=3D"mailto:hodges.r@gmail.co=
m" target=3D"_blank">hodges.r@gmail.com</a>> a =C3=A9crit=C2=A0:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">>=C2=A0<span style=3D"=
color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal=
;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;let=
ter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;whi=
te-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-dec=
oration-style:initial;text-decoration-color:initial;float:none;display:inli=
ne">I wholeheartedly agree, the Committee should not pursue<span>=C2=A0</sp=
an></span><i style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:=
13px;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400=
;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none=
;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text=
-decoration-style:initial;text-decoration-color:initial">any</i><span style=
=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:no=
rmal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400=
;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none=
;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text=
-decoration-style:initial;text-decoration-color:initial;float:none;display:=
inline"><span>=C2=A0</span>from of "Graphics Programing".</span><=
div><span style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13p=
x;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;=
font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text=
-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(25=
5,255,255);text-decoration-style:initial;text-decoration-color:initial;floa=
t:none;display:inline"><br></span></div></div><div dir=3D"ltr"><div><span s=
tyle=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-styl=
e:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight=
:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:=
none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);=
text-decoration-style:initial;text-decoration-color:initial;float:none;disp=
lay:inline">While I agree that a Noddy-style 2d line-drawing library is of =
no use to anyone, I strongly feel that there should be a standardised 3d gr=
aphics, sound and human interface library, and damn the difficulties. I'=
;m not arguing that every compiler vendor ships a fully functioning library=
, but if they do there should be a standard so that vendors can report leve=
ls of compliance.</span></div><div><span style=3D"color:rgb(34,34,34);font-=
family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:n=
ormal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-a=
lign:start;text-indent:0px;text-transform:none;white-space:normal;word-spac=
ing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;tex=
t-decoration-color:initial;float:none;display:inline"><br></span></div><div=
>At the moment, collecting together all the bits and pieces to build a cros=
s-platform graphics engine is just too much work. In the end you give up th=
e will to continue and switch to an inferior language with better support.<=
br></div><div><span style=3D"color:rgb(34,34,34);font-family:sans-serif;fon=
t-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-ca=
ps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-inden=
t:0px;text-transform:none;white-space:normal;word-spacing:0px;background-co=
lor:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:in=
itial;float:none;display:inline"><br></span></div><div><span style=3D"color=
:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font=
-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-s=
pacing:normal;text-align:start;text-indent:0px;text-transform:none;white-sp=
ace:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decorati=
on-style:initial;text-decoration-color:initial;float:none;display:inline">I=
n my view this is a shame.</span></div><div><span style=3D"color:rgb(34,34,=
34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-li=
gatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:norm=
al;text-align:start;text-indent:0px;text-transform:none;white-space:normal;=
word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:in=
itial;text-decoration-color:initial;float:none;display:inline"><br></span><=
/div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, 1 Jun 20=
18 at 14:00, <<a href=3D"mailto:mihailnajdenov@gmail.com" target=3D"_bla=
nk">mihailnajdenov@gmail.com</a>> wrote:<br></div><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"><div>Hello, I recently stumbled into=C2=A0<a href=
=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html" t=
arget=3D"_blank">p1062R0 (Diet Graphics)</a></div><div><br></div><div>I who=
leheartedly agree, the Committee should not pursue <i>any</i> from of "=
;Graphics Programing".</div><div><br></div><div>Here is why:</div><div=
>=C2=A0- <b>Impossible</b> to keep up-to date with modern trends - <i>both<=
/i> hardware, algorithms and APIs to address the hardware change all the ti=
me.</div><div><span style=3D"display:inline!important;float:none;background=
-color:transparent;color:rgb(34,34,34);font-family:"Arial","=
Helvetica",sans-serif;font-size:13px;font-style:normal;font-variant:no=
rmal;font-weight:400;letter-spacing:normal;text-align:left;text-decoration:=
none;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0p=
x">=C2=A0- </span><b>Impossible </b><span style=3D"display:inline!important=
;float:none;background-color:transparent;color:rgb(34,34,34);font-family:&q=
uot;Arial","Helvetica",sans-serif;font-size:13px;font-style:=
normal;font-variant:normal;font-weight:400;letter-spacing:normal;text-align=
:left;text-decoration:none;text-indent:0px;text-transform:none;white-space:=
normal;word-spacing:0px">to look (or perform) nearly the same on all platfo=
rms or <span style=3D"display:inline!important;float:none;background-color:=
transparent;color:rgb(34,34,34);font-family:"Arial","Helveti=
ca",sans-serif;font-size:13px;font-style:normal;font-variant:normal;fo=
nt-weight:400;letter-spacing:normal;text-align:left;text-decoration:none;te=
xt-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">impl=
ementations</span>.</span><span style=3D"display:inline!important;float:non=
e;background-color:transparent;color:rgb(34,34,34);font-family:"Arial&=
quot;,"Helvetica",sans-serif;font-size:13px;font-style:normal;fon=
t-variant:normal;font-weight:400;letter-spacing:normal;text-align:left;text=
-decoration:none;text-indent:0px;text-transform:none;white-space:normal;wor=
d-spacing:0px">=C2=A0</span><br></div><div>=C2=A0- <b>Impossible</b> to be =
complete and useful for the real world - useful graphics programming framew=
ork is way bigger the standard library itself!</div><div>=C2=A0- <b>Impossi=
ble</b> to keep up to date in terms of user requests - new primitives, stro=
kes, colors, brushes, filters, helper functions, customization points, etc =
etc etc etc etc</div><div><span style=3D"display:inline!important;float:non=
e;background-color:transparent;color:rgb(34,34,34);font-family:"Arial&=
quot;,"Helvetica",sans-serif;font-size:13px;font-style:normal;fon=
t-variant:normal;font-weight:400;letter-spacing:normal;text-align:left;text=
-decoration:none;text-indent:0px;text-transform:none;white-space:normal;wor=
d-spacing:0px">=C2=A0- </span><b>Heavy</b><span style=3D"display:inline!imp=
ortant;float:none;background-color:transparent;color:rgb(34,34,34);font-fam=
ily:"Arial","Helvetica",sans-serif;font-size:13px;font-=
style:normal;font-variant:normal;font-weight:400;letter-spacing:normal;text=
-align:left;text-decoration:none;text-indent:0px;text-transform:none;white-=
space:normal;word-spacing:0px"> <b>burden</b> on the implementations.=C2=A0=
</span><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br></di=
v><div>=C2=A0- <b>Limited use </b>as a percent of c++ community in comparis=
on to many other features and libraries, including higher level ones like f=
ilesystem=C2=A0</div><div>=C2=A0- <b>Will open the floodgates</b> for <i>Pr=
oposals Related To Graphics</i> <b>and</b> <i>Proposals Which Build On Top =
Of Graphics, </i>which the Committee (and the community) will waste time co=
nsidering, probably without even having the expertise for that!</div><div>=
=C2=A0</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" 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@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7915a73c-e305-4bce-bf6e-28f20a7faccb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7915a73c-e305-=
4bce-bf6e-28f20a7faccb%40isocpp.org</a>.<br>
</blockquote></div>
<p></p>
-- <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" target=3D"_=
blank">std-proposals+unsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ0Ouf4OgeeaeVjYvVP3n61AWBn3f6%=
3DH2-3A2hMPxGzVg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CALvx3hZ0Ouf4OgeeaeVjYvVP3n61AWBn3f6%3DH2-3A2hMPxGzVg%40mail.gmail.c=
om</a>.<br>
</blockquote></div></div>
<p></p>
-- <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" target=3D"_=
blank">std-proposals+unsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2BSjxfeHSdw%3DDPJGFBJFJtH1NgQ=
19tH%3DWY5KqKCKkzs-fPg%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid=
/std-proposals/CA%2BOm%2BSjxfeHSdw%3DDPJGFBJFJtH1NgQ19tH%3DWY5KqKCKkzs-fPg%=
40mail.gmail.com</a>.<br>
</blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hbeANpuC-O%3DEWxH206KG%3DWDrFwC=
iruoxc_02rfDooZcNg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hbeANpu=
C-O%3DEWxH206KG%3DWDrFwCiruoxc_02rfDooZcNg%40mail.gmail.com</a>.<br />
--0000000000000be226056d957632--
.
Author: Dejan Milosavljevic <dmilos@gmail.com>
Date: Fri, 1 Jun 2018 16:38:47 +0200
Raw View
--000000000000b5c751056d958a99
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Take look at next thread:
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/aEdZvQS1Soc/8TpS=
RdhSAQAJ
Everything what apply to GUI is same for Graphics.
On Fri, Jun 1, 2018 at 4:29 PM, Corentin <corentin.jabot@gmail.com> wrote:
> > At the moment, collecting together all the bits and pieces to build a
> cross-platform graphics engine is just too much work. In the end you give
> up the will to continue and switch to an inferior language with better
> support.
>
> I think most people would agree with that observation.
> But what we need is a better way to collecting bits and pieces, not to pu=
t
> the whole world in the standard to make up for insufficient tooling !
>
>
> Le ven. 1 juin 2018 =C3=A0 16:15, Richard Hodges <hodges.r@gmail.com> a =
=C3=A9crit :
>
>> > I wholeheartedly agree, the Committee should not pursue *any* from of
>> "Graphics Programing".
>>
>> While I agree that a Noddy-style 2d line-drawing library is of no use to
>> anyone, I strongly feel that there should be a standardised 3d graphics,
>> sound and human interface library, and damn the difficulties. I'm not
>> arguing that every compiler vendor ships a fully functioning library, bu=
t
>> if they do there should be a standard so that vendors can report levels =
of
>> compliance.
>>
>> At the moment, collecting together all the bits and pieces to build a
>> cross-platform graphics engine is just too much work. In the end you giv=
e
>> up the will to continue and switch to an inferior language with better
>> support.
>>
>> In my view this is a shame.
>>
>>
>> On Fri, 1 Jun 2018 at 14:00, <mihailnajdenov@gmail.com> wrote:
>>
>>> Hello, I recently stumbled into p1062R0 (Diet Graphics)
>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html>
>>>
>>> I wholeheartedly agree, the Committee should not pursue *any* from of
>>> "Graphics Programing".
>>>
>>> Here is why:
>>> - *Impossible* to keep up-to date with modern trends - *both*
>>> hardware, algorithms and APIs to address the hardware change all the ti=
me.
>>> - *Impossible *to look (or perform) nearly the same on all platforms
>>> or implementations.
>>> - *Impossible* to be complete and useful for the real world - useful
>>> graphics programming framework is way bigger the standard library itsel=
f!
>>> - *Impossible* to keep up to date in terms of user requests - new
>>> primitives, strokes, colors, brushes, filters, helper functions,
>>> customization points, etc etc etc etc etc
>>> - *Heavy* *burden* on the implementations.
>>> - *Limited use *as a percent of c++ community in comparison to many
>>> other features and libraries, including higher level ones like filesyst=
em
>>> - *Will open the floodgates* for *Proposals Related To Graphics* *and*=
*Proposals
>>> Which Build On Top Of Graphics, *which the Committee (and the
>>> community) will waste time considering, probably without even having th=
e
>>> expertise for that!
>>>
>>>
>>> --
>>> 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/7915a73c-e305-4bce-
>>> bf6e-28f20a7faccb%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7915a73c-=
e305-4bce-bf6e-28f20a7faccb%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/CALvx3hZ0Ouf4OgeeaeVjYvVP3n61A
>> WBn3f6%3DH2-3A2hMPxGzVg%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ0O=
uf4OgeeaeVjYvVP3n61AWBn3f6%3DH2-3A2hMPxGzVg%40mail.gmail.com?utm_medium=3De=
mail&utm_source=3Dfooter>
>> .
>>
> --
> 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/CA%2BOm%2BSjxfeHSdw%
> 3DDPJGFBJFJtH1NgQ19tH%3DWY5KqKCKkzs-fPg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2BS=
jxfeHSdw%3DDPJGFBJFJtH1NgQ19tH%3DWY5KqKCKkzs-fPg%40mail.gmail.com?utm_mediu=
m=3Demail&utm_source=3Dfooter>
> .
>
--=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/CAEfefmz9U8RXHkOD2U06vbAoQZJFa7kgg_yc56Z2GxHep-M=
mCQ%40mail.gmail.com.
--000000000000b5c751056d958a99
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Take look at next thread:</div><div>=C2=A0<a href=3D"=
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/aEdZvQS1Soc/8TpS=
RdhSAQAJ">https://groups.google.com/a/isocpp.org/d/msg/std-proposals/aEdZvQ=
S1Soc/8TpSRdhSAQAJ</a></div><div><br></div><div>Everything what apply to GU=
I is same for Graphics.=C2=A0<br><br></div><div><br></div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Jun 1, 2018 at 4:29=
PM, Corentin <span dir=3D"ltr"><<a href=3D"mailto:corentin.jabot@gmail.=
com" target=3D"_blank">corentin.jabot@gmail.com</a>></span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>>=C2=A0<span style=
=3D"color:rgb(33,33,33)">At the moment, collecting together all the bits an=
d pieces to build a cross-platform graphics engine is just too much work. I=
n the end you give up the will to continue and switch to an inferior langua=
ge with better support.</span><div><br></div></span><div>I think most peopl=
e would agree with that observation.=C2=A0</div><div>But what we need is a =
better way to collecting bits and pieces, not to put the whole world in the=
standard to make up for insufficient tooling !</div><div><div class=3D"h5"=
><div><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">Le=C2=A0ven=
.. 1 juin 2018 =C3=A0=C2=A016:15, Richard Hodges <<a href=3D"mailto:hodge=
s.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a>> a =C3=A9crit=C2=
=A0:<br></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">>=C2=A0<sp=
an style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-=
style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-we=
ight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transf=
orm:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,2=
55);text-decoration-style:initial;text-decoration-color:initial;float:none;=
display:inline">I wholeheartedly agree, the Committee should not pursue<spa=
n>=C2=A0</span></span><i style=3D"color:rgb(34,34,34);font-family:sans-seri=
f;font-size:13px;font-variant-ligatures:normal;font-variant-caps:normal;fon=
t-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-tr=
ansform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,2=
55,255);text-decoration-style:initial;text-decoration-color:initial">any</i=
><span style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;f=
ont-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;fon=
t-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-tr=
ansform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,2=
55,255);text-decoration-style:initial;text-decoration-color:initial;float:n=
one;display:inline"><span>=C2=A0</span>from of "Graphics Programing&qu=
ot;.</span><div><span style=3D"color:rgb(34,34,34);font-family:sans-serif;f=
ont-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-=
caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-ind=
ent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-=
color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:=
initial;float:none;display:inline"><br></span></div></div><div dir=3D"ltr">=
<div><span style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13=
px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal=
;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;tex=
t-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(2=
55,255,255);text-decoration-style:initial;text-decoration-color:initial;flo=
at:none;display:inline">While I agree that a Noddy-style 2d line-drawing li=
brary is of no use to anyone, I strongly feel that there should be a standa=
rdised 3d graphics, sound and human interface library, and damn the difficu=
lties. I'm not arguing that every compiler vendor ships a fully functio=
ning library, but if they do there should be a standard so that vendors can=
report levels of compliance.</span></div><div><span style=3D"color:rgb(34,=
34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant=
-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:n=
ormal;text-align:start;text-indent:0px;text-transform:none;white-space:norm=
al;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style=
:initial;text-decoration-color:initial;float:none;display:inline"><br></spa=
n></div><div>At the moment, collecting together all the bits and pieces to =
build a cross-platform graphics engine is just too much work. In the end yo=
u give up the will to continue and switch to an inferior language with bett=
er support.<br></div><div><span style=3D"color:rgb(34,34,34);font-family:sa=
ns-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;fon=
t-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:star=
t;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;b=
ackground-color:rgb(255,255,255);text-decoration-style:initial;text-decorat=
ion-color:initial;float:none;display:inline"><br></span></div><div><span st=
yle=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style=
:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:=
400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:n=
one;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);t=
ext-decoration-style:initial;text-decoration-color:initial;float:none;displ=
ay:inline">In my view this is a shame.</span></div><div><span style=3D"colo=
r:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;fon=
t-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-=
spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-s=
pace:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decorat=
ion-style:initial;text-decoration-color:initial;float:none;display:inline">=
<br></span></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On F=
ri, 1 Jun 2018 at 14:00, <<a href=3D"mailto:mihailnajdenov@gmail.com" ta=
rget=3D"_blank">mihailnajdenov@gmail.com</a>> wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><div>Hello, I recently stumbled into=
=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1=
062r0.html" target=3D"_blank">p1062R0 (Diet Graphics)</a></div><div><br></d=
iv><div>I wholeheartedly agree, the Committee should not pursue <i>any</i> =
from of "Graphics Programing".</div><div><br></div><div>Here is w=
hy:</div><div>=C2=A0- <b>Impossible</b> to keep up-to date with modern tren=
ds - <i>both</i> hardware, algorithms and APIs to address the hardware chan=
ge all the time.</div><div><span style=3D"display:inline!important;float:no=
ne;background-color:transparent;color:rgb(34,34,34);font-family:"Arial=
","Helvetica",sans-serif;font-size:13px;font-style:normal;fo=
nt-variant:normal;font-weight:400;letter-spacing:normal;text-align:left;tex=
t-decoration:none;text-indent:0px;text-transform:none;white-space:normal;wo=
rd-spacing:0px">=C2=A0- </span><b>Impossible </b><span style=3D"display:inl=
ine!important;float:none;background-color:transparent;color:rgb(34,34,34);f=
ont-family:"Arial","Helvetica",sans-serif;font-size:13p=
x;font-style:normal;font-variant:normal;font-weight:400;letter-spacing:norm=
al;text-align:left;text-decoration:none;text-indent:0px;text-transform:none=
;white-space:normal;word-spacing:0px">to look (or perform) nearly the same =
on all platforms or <span style=3D"display:inline!important;float:none;back=
ground-color:transparent;color:rgb(34,34,34);font-family:"Arial",=
"Helvetica",sans-serif;font-size:13px;font-style:normal;font-vari=
ant:normal;font-weight:400;letter-spacing:normal;text-align:left;text-decor=
ation:none;text-indent:0px;text-transform:none;white-space:normal;word-spac=
ing:0px">implementations</span>.</span><span style=3D"display:inline!import=
ant;float:none;background-color:transparent;color:rgb(34,34,34);font-family=
:"Arial","Helvetica",sans-serif;font-size:13px;font-sty=
le:normal;font-variant:normal;font-weight:400;letter-spacing:normal;text-al=
ign:left;text-decoration:none;text-indent:0px;text-transform:none;white-spa=
ce:normal;word-spacing:0px">=C2=A0</span><br></div><div>=C2=A0- <b>Impossib=
le</b> to be complete and useful for the real world - useful graphics progr=
amming framework is way bigger the standard library itself!</div><div>=C2=
=A0- <b>Impossible</b> to keep up to date in terms of user requests - new p=
rimitives, strokes, colors, brushes, filters, helper functions, customizati=
on points, etc etc etc etc etc</div><div><span style=3D"display:inline!impo=
rtant;float:none;background-color:transparent;color:rgb(34,34,34);font-fami=
ly:"Arial","Helvetica",sans-serif;font-size:13px;font-s=
tyle:normal;font-variant:normal;font-weight:400;letter-spacing:normal;text-=
align:left;text-decoration:none;text-indent:0px;text-transform:none;white-s=
pace:normal;word-spacing:0px">=C2=A0- </span><b>Heavy</b><span style=3D"dis=
play:inline!important;float:none;background-color:transparent;color:rgb(34,=
34,34);font-family:"Arial","Helvetica",sans-serif;font-=
size:13px;font-style:normal;font-variant:normal;font-weight:400;letter-spac=
ing:normal;text-align:left;text-decoration:none;text-indent:0px;text-transf=
orm:none;white-space:normal;word-spacing:0px"> <b>burden</b> on the impleme=
ntations.=C2=A0</span><b></b><i></i><u></u><sub></sub><sup></sup><strike></=
strike><br></div><div>=C2=A0- <b>Limited use </b>as a percent of c++ commun=
ity in comparison to many other features and libraries, including higher le=
vel ones like filesystem=C2=A0</div><div>=C2=A0- <b>Will open the floodgate=
s</b> for <i>Proposals Related To Graphics</i> <b>and</b> <i>Proposals Whic=
h Build On Top Of Graphics, </i>which the Committee (and the community) wil=
l waste time considering, probably without even having the expertise for th=
at!</div><div>=C2=A0</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" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7915a73c-e305-4bce-bf6e-28f20a7faccb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/7915=
a73c-e305-4bce-<wbr>bf6e-28f20a7faccb%40isocpp.org</a><wbr>.<br>
</blockquote></div>
<p></p>
-- <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" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ0Ouf4OgeeaeVjYvVP3n61AWBn3f6%=
3DH2-3A2hMPxGzVg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/<wbr>CALvx3hZ0Ouf4OgeeaeVjYvVP3n61A<wbr>WBn3f6%3DH2-3A2hMP=
xGzVg%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div></div></div></div><div><div class=3D"h5">
<p></p>
-- <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" 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></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2BSjxfeHSdw%3DDPJGFBJFJtH1NgQ=
19tH%3DWY5KqKCKkzs-fPg%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/=
msgid/std-<wbr>proposals/CA%2BOm%2BSjxfeHSdw%<wbr>3DDPJGFBJFJtH1NgQ19tH%<wb=
r>3DWY5KqKCKkzs-fPg%40mail.<wbr>gmail.com</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEfefmz9U8RXHkOD2U06vbAoQZJFa7kgg_yc=
56Z2GxHep-MmCQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmz9U8RXHkOD=
2U06vbAoQZJFa7kgg_yc56Z2GxHep-MmCQ%40mail.gmail.com</a>.<br />
--000000000000b5c751056d958a99--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Fri, 1 Jun 2018 15:52:12 +0100
Raw View
--000000000000487351056d95bbfb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Fri, 1 Jun 2018 at 15:38, Dejan Milosavljevic <dmilos@gmail.com> wrote:
> Take look at next thread:
>
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/aEdZvQS1Soc/8T=
pSRdhSAQAJ
>
> Everything what apply to GUI is same for Graphics.
>
And yet OpenGL is a (very successful) standard thing...
>
>
>
> On Fri, Jun 1, 2018 at 4:29 PM, Corentin <corentin.jabot@gmail.com> wrote=
:
>
>> > At the moment, collecting together all the bits and pieces to build a
>> cross-platform graphics engine is just too much work. In the end you giv=
e
>> up the will to continue and switch to an inferior language with better
>> support.
>>
>> I think most people would agree with that observation.
>> But what we need is a better way to collecting bits and pieces, not to
>> put the whole world in the standard to make up for insufficient tooling =
!
>>
>>
>> Le ven. 1 juin 2018 =C3=A0 16:15, Richard Hodges <hodges.r@gmail.com> a
>> =C3=A9crit :
>>
>>> > I wholeheartedly agree, the Committee should not pursue *any* from of
>>> "Graphics Programing".
>>>
>>> While I agree that a Noddy-style 2d line-drawing library is of no use t=
o
>>> anyone, I strongly feel that there should be a standardised 3d graphics=
,
>>> sound and human interface library, and damn the difficulties. I'm not
>>> arguing that every compiler vendor ships a fully functioning library, b=
ut
>>> if they do there should be a standard so that vendors can report levels=
of
>>> compliance.
>>>
>>> At the moment, collecting together all the bits and pieces to build a
>>> cross-platform graphics engine is just too much work. In the end you gi=
ve
>>> up the will to continue and switch to an inferior language with better
>>> support.
>>>
>>> In my view this is a shame.
>>>
>>>
>>> On Fri, 1 Jun 2018 at 14:00, <mihailnajdenov@gmail.com> wrote:
>>>
>>>> Hello, I recently stumbled into p1062R0 (Diet Graphics)
>>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html>
>>>>
>>>> I wholeheartedly agree, the Committee should not pursue *any* from of
>>>> "Graphics Programing".
>>>>
>>>> Here is why:
>>>> - *Impossible* to keep up-to date with modern trends - *both*
>>>> hardware, algorithms and APIs to address the hardware change all the t=
ime.
>>>> - *Impossible *to look (or perform) nearly the same on all platforms
>>>> or implementations.
>>>> - *Impossible* to be complete and useful for the real world - useful
>>>> graphics programming framework is way bigger the standard library itse=
lf!
>>>> - *Impossible* to keep up to date in terms of user requests - new
>>>> primitives, strokes, colors, brushes, filters, helper functions,
>>>> customization points, etc etc etc etc etc
>>>> - *Heavy* *burden* on the implementations.
>>>> - *Limited use *as a percent of c++ community in comparison to many
>>>> other features and libraries, including higher level ones like filesys=
tem
>>>> - *Will open the floodgates* for *Proposals Related To Graphics* *and=
* *Proposals
>>>> Which Build On Top Of Graphics, *which the Committee (and the
>>>> community) will waste time considering, probably without even having t=
he
>>>> expertise for that!
>>>>
>>>>
>>>> --
>>>> 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/7915a73c-=
e305-4bce-bf6e-28f20a7faccb%40isocpp.org
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7915a73c=
-e305-4bce-bf6e-28f20a7faccb%40isocpp.org?utm_medium=3Demail&utm_source=3Df=
ooter>
>>>> .
>>>>
>>> --
>>> 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/CALvx3hZ0O=
uf4OgeeaeVjYvVP3n61AWBn3f6%3DH2-3A2hMPxGzVg%40mail.gmail.com
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ0=
Ouf4OgeeaeVjYvVP3n61AWBn3f6%3DH2-3A2hMPxGzVg%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/CA%2BOm%2BS=
jxfeHSdw%3DDPJGFBJFJtH1NgQ19tH%3DWY5KqKCKkzs-fPg%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2B=
SjxfeHSdw%3DDPJGFBJFJtH1NgQ19tH%3DWY5KqKCKkzs-fPg%40mail.gmail.com?utm_medi=
um=3Demail&utm_source=3Dfooter>
>> .
>>
>
> --
> 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/CAEfefmz9U8R=
XHkOD2U06vbAoQZJFa7kgg_yc56Z2GxHep-MmCQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmz9U8=
RXHkOD2U06vbAoQZJFa7kgg_yc56Z2GxHep-MmCQ%40mail.gmail.com?utm_medium=3Demai=
l&utm_source=3Dfooter>
> .
>
--=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/CALvx3ha9NLb6AS%2BwcZ4oiKBK3LhSfROk%2BK%2BTEucmL=
ckY9Q-JVA%40mail.gmail.com.
--000000000000487351056d95bbfb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri=
, 1 Jun 2018 at 15:38, Dejan Milosavljevic <<a href=3D"mailto:dmilos@gma=
il.com">dmilos@gmail.com</a>> wrote:<br></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>Take look at next thread:</div><div>=C2=A0<a hre=
f=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/aEdZvQS1Soc=
/8TpSRdhSAQAJ" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/m=
sg/std-proposals/aEdZvQS1Soc/8TpSRdhSAQAJ</a></div><div><br></div><div>Ever=
ything what apply to GUI is same for Graphics.=C2=A0<br></div></div></block=
quote><div><br></div><div>And yet OpenGL is a (very successful) standard th=
ing...</div><div>=C2=A0</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><br></div><div><br></div></div><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">On Fri, Jun 1, 2018 at 4:29 PM, Corentin <span dir=3D"=
ltr"><<a href=3D"mailto:corentin.jabot@gmail.com" target=3D"_blank">core=
ntin.jabot@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><span>>=C2=A0<span style=3D"color:rgb(33,33,33)">At t=
he moment, collecting together all the bits and pieces to build a cross-pla=
tform graphics engine is just too much work. In the end you give up the wil=
l to continue and switch to an inferior language with better support.</span=
><div><br></div></span><div>I think most people would agree with that obser=
vation.=C2=A0</div><div>But what we need is a better way to collecting bits=
and pieces, not to put the whole world in the standard to make up for insu=
fficient tooling !</div><div><div class=3D"m_2875691077859021142h5"><div><b=
r></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">Le=C2=A0ven. 1 juin=
2018 =C3=A0=C2=A016:15, Richard Hodges <<a href=3D"mailto:hodges.r@gmai=
l.com" target=3D"_blank">hodges.r@gmail.com</a>> a =C3=A9crit=C2=A0:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">>=C2=A0<span style=
=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:no=
rmal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400=
;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none=
;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text=
-decoration-style:initial;text-decoration-color:initial;float:none;display:=
inline">I wholeheartedly agree, the Committee should not pursue<span>=C2=A0=
</span></span><i style=3D"color:rgb(34,34,34);font-family:sans-serif;font-s=
ize:13px;font-variant-ligatures:normal;font-variant-caps:normal;font-weight=
:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:=
none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);=
text-decoration-style:initial;text-decoration-color:initial">any</i><span s=
tyle=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-styl=
e:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight=
:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:=
none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);=
text-decoration-style:initial;text-decoration-color:initial;float:none;disp=
lay:inline"><span>=C2=A0</span>from of "Graphics Programing".</sp=
an><div><span style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size=
:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:nor=
mal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;=
text-transform:none;white-space:normal;word-spacing:0px;background-color:rg=
b(255,255,255);text-decoration-style:initial;text-decoration-color:initial;=
float:none;display:inline"><br></span></div></div><div dir=3D"ltr"><div><sp=
an style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-=
style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-we=
ight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transf=
orm:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,2=
55);text-decoration-style:initial;text-decoration-color:initial;float:none;=
display:inline">While I agree that a Noddy-style 2d line-drawing library is=
of no use to anyone, I strongly feel that there should be a standardised 3=
d graphics, sound and human interface library, and damn the difficulties. I=
'm not arguing that every compiler vendor ships a fully functioning lib=
rary, but if they do there should be a standard so that vendors can report =
levels of compliance.</span></div><div><span style=3D"color:rgb(34,34,34);f=
ont-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatur=
es:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;te=
xt-align:start;text-indent:0px;text-transform:none;white-space:normal;word-=
spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial=
;text-decoration-color:initial;float:none;display:inline"><br></span></div>=
<div>At the moment, collecting together all the bits and pieces to build a =
cross-platform graphics engine is just too much work. In the end you give u=
p the will to continue and switch to an inferior language with better suppo=
rt.<br></div><div><span style=3D"color:rgb(34,34,34);font-family:sans-serif=
;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-varian=
t-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-i=
ndent:0px;text-transform:none;white-space:normal;word-spacing:0px;backgroun=
d-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-colo=
r:initial;float:none;display:inline"><br></span></div><div><span style=3D"c=
olor:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;=
font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;lett=
er-spacing:normal;text-align:start;text-indent:0px;text-transform:none;whit=
e-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-deco=
ration-style:initial;text-decoration-color:initial;float:none;display:inlin=
e">In my view this is a shame.</span></div><div><span style=3D"color:rgb(34=
,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-varian=
t-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:=
normal;text-align:start;text-indent:0px;text-transform:none;white-space:nor=
mal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-styl=
e:initial;text-decoration-color:initial;float:none;display:inline"><br></sp=
an></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, 1 Ju=
n 2018 at 14:00, <<a href=3D"mailto:mihailnajdenov@gmail.com" target=3D"=
_blank">mihailnajdenov@gmail.com</a>> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div>Hello, I recently stumbled into=C2=A0<a=
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.ht=
ml" target=3D"_blank">p1062R0 (Diet Graphics)</a></div><div><br></div><div>=
I wholeheartedly agree, the Committee should not pursue <i>any</i> from of =
"Graphics Programing".</div><div><br></div><div>Here is why:</div=
><div>=C2=A0- <b>Impossible</b> to keep up-to date with modern trends - <i>=
both</i> hardware, algorithms and APIs to address the hardware change all t=
he time.</div><div><span style=3D"display:inline!important;float:none;backg=
round-color:transparent;color:rgb(34,34,34);font-family:"Arial",&=
quot;Helvetica",sans-serif;font-size:13px;font-style:normal;font-varia=
nt:normal;font-weight:400;letter-spacing:normal;text-align:left;text-decora=
tion:none;text-indent:0px;text-transform:none;white-space:normal;word-spaci=
ng:0px">=C2=A0- </span><b>Impossible </b><span style=3D"display:inline!impo=
rtant;float:none;background-color:transparent;color:rgb(34,34,34);font-fami=
ly:"Arial","Helvetica",sans-serif;font-size:13px;font-s=
tyle:normal;font-variant:normal;font-weight:400;letter-spacing:normal;text-=
align:left;text-decoration:none;text-indent:0px;text-transform:none;white-s=
pace:normal;word-spacing:0px">to look (or perform) nearly the same on all p=
latforms or <span style=3D"display:inline!important;float:none;background-c=
olor:transparent;color:rgb(34,34,34);font-family:"Arial","He=
lvetica",sans-serif;font-size:13px;font-style:normal;font-variant:norm=
al;font-weight:400;letter-spacing:normal;text-align:left;text-decoration:no=
ne;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"=
>implementations</span>.</span><span style=3D"display:inline!important;floa=
t:none;background-color:transparent;color:rgb(34,34,34);font-family:"A=
rial","Helvetica",sans-serif;font-size:13px;font-style:norma=
l;font-variant:normal;font-weight:400;letter-spacing:normal;text-align:left=
;text-decoration:none;text-indent:0px;text-transform:none;white-space:norma=
l;word-spacing:0px">=C2=A0</span><br></div><div>=C2=A0- <b>Impossible</b> t=
o be complete and useful for the real world - useful graphics programming f=
ramework is way bigger the standard library itself!</div><div>=C2=A0- <b>Im=
possible</b> to keep up to date in terms of user requests - new primitives,=
strokes, colors, brushes, filters, helper functions, customization points,=
etc etc etc etc etc</div><div><span style=3D"display:inline!important;floa=
t:none;background-color:transparent;color:rgb(34,34,34);font-family:"A=
rial","Helvetica",sans-serif;font-size:13px;font-style:norma=
l;font-variant:normal;font-weight:400;letter-spacing:normal;text-align:left=
;text-decoration:none;text-indent:0px;text-transform:none;white-space:norma=
l;word-spacing:0px">=C2=A0- </span><b>Heavy</b><span style=3D"display:inlin=
e!important;float:none;background-color:transparent;color:rgb(34,34,34);fon=
t-family:"Arial","Helvetica",sans-serif;font-size:13px;=
font-style:normal;font-variant:normal;font-weight:400;letter-spacing:normal=
;text-align:left;text-decoration:none;text-indent:0px;text-transform:none;w=
hite-space:normal;word-spacing:0px"> <b>burden</b> on the implementations.=
=C2=A0</span><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><b=
r></div><div>=C2=A0- <b>Limited use </b>as a percent of c++ community in co=
mparison to many other features and libraries, including higher level ones =
like filesystem=C2=A0</div><div>=C2=A0- <b>Will open the floodgates</b> for=
<i>Proposals Related To Graphics</i> <b>and</b> <i>Proposals Which Build O=
n Top Of Graphics, </i>which the Committee (and the community) will waste t=
ime considering, probably without even having the expertise for that!</div>=
<div>=C2=A0</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" 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@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7915a73c-e305-4bce-bf6e-28f20a7faccb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7915a73c-e305-=
4bce-bf6e-28f20a7faccb%40isocpp.org</a>.<br>
</blockquote></div>
<p></p>
-- <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" target=3D"_=
blank">std-proposals+unsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ0Ouf4OgeeaeVjYvVP3n61AWBn3f6%=
3DH2-3A2hMPxGzVg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CALvx3hZ0Ouf4OgeeaeVjYvVP3n61AWBn3f6%3DH2-3A2hMPxGzVg%40mail.gmail.c=
om</a>.<br>
</blockquote></div></div></div></div><div><div class=3D"m_28756910778590211=
42h5">
<p></p>
-- <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" target=3D"_=
blank">std-proposals+unsubscribe@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></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2BSjxfeHSdw%3DDPJGFBJFJtH1NgQ=
19tH%3DWY5KqKCKkzs-fPg%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid=
/std-proposals/CA%2BOm%2BSjxfeHSdw%3DDPJGFBJFJtH1NgQ19tH%3DWY5KqKCKkzs-fPg%=
40mail.gmail.com</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <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" target=3D"_=
blank">std-proposals+unsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEfefmz9U8RXHkOD2U06vbAoQZJFa7kgg_yc=
56Z2GxHep-MmCQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CAEfefmz9U8RXHkOD2U06vbAoQZJFa7kgg_yc56Z2GxHep-MmCQ%40mail.gmail.com</=
a>.<br>
</blockquote></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3ha9NLb6AS%2BwcZ4oiKBK3LhSfROk%2=
BK%2BTEucmLckY9Q-JVA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3ha9NL=
b6AS%2BwcZ4oiKBK3LhSfROk%2BK%2BTEucmLckY9Q-JVA%40mail.gmail.com</a>.<br />
--000000000000487351056d95bbfb--
.
Author: Rene Rivera <grafikrobot@gmail.com>
Date: Fri, 1 Jun 2018 09:57:33 -0500
Raw View
--000000000000cc04c3056d95cd2b
Content-Type: text/plain; charset="UTF-8"
On Fri, Jun 1, 2018 at 9:38 AM, Dejan Milosavljevic <dmilos@gmail.com>
wrote:
> Take look at next thread:
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/aEdZvQS1Soc/
> 8TpSRdhSAQAJ
>
> Everything what apply to GUI is same for Graphics.
>
Correct.. And the same conclusion applies.
--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
--
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/CAHEh_GikxSi-H7Y1oX8fOz%2Bq2iHuDxT2S4FVBsQvTUO3HEDtuw%40mail.gmail.com.
--000000000000cc04c3056d95cd2b
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 F=
ri, Jun 1, 2018 at 9:38 AM, Dejan Milosavljevic <span dir=3D"ltr"><<a hr=
ef=3D"mailto:dmilos@gmail.com" target=3D"_blank">dmilos@gmail.com</a>></=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Take l=
ook at next thread:</div><div>=C2=A0<a href=3D"https://groups.google.com/a/=
isocpp.org/d/msg/std-proposals/aEdZvQS1Soc/8TpSRdhSAQAJ" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msg/std-<wbr>proposals/aEdZvQ=
S1Soc/<wbr>8TpSRdhSAQAJ</a></div><div><br></div><div>Everything what apply =
to GUI is same for Graphics.=C2=A0<br></div></div></blockquote><div><br></d=
iv><div>Correct.. And the same conclusion applies.</div></div><div><br></di=
v>-- <br><div class=3D"gmail_signature" data-smartmail=3D"gmail_signature">=
<div dir=3D"ltr"><div><div dir=3D"ltr">-- Rene Rivera<br>-- Grafik - Don=
9;t Assume Anything<br>-- Robot Dreams -=C2=A0<a href=3D"http://robot-dream=
s.net/" target=3D"_blank">http://robot-dreams.net</a><br><br></div></div></=
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" 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/CAHEh_GikxSi-H7Y1oX8fOz%2Bq2iHuDxT2S4=
FVBsQvTUO3HEDtuw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_GikxSi-H7=
Y1oX8fOz%2Bq2iHuDxT2S4FVBsQvTUO3HEDtuw%40mail.gmail.com</a>.<br />
--000000000000cc04c3056d95cd2b--
.
Author: Rene Rivera <grafikrobot@gmail.com>
Date: Fri, 1 Jun 2018 09:58:50 -0500
Raw View
--00000000000068d966056d95d24c
Content-Type: text/plain; charset="UTF-8"
On Fri, Jun 1, 2018 at 9:52 AM, Richard Hodges <hodges.r@gmail.com> wrote:
>
>
> On Fri, 1 Jun 2018 at 15:38, Dejan Milosavljevic <dmilos@gmail.com> wrote:
>
>> Take look at next thread:
>> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/aEdZvQS1Soc/
>> 8TpSRdhSAQAJ
>>
>> Everything what apply to GUI is same for Graphics.
>>
>
> And yet OpenGL is a (very successful) standard thing...
>
With at least three competing "standards". So I guess it's not so standard.
--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
--
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/CAHEh_GghBeFQGCv2WqWct1bkfC_F8NrGTGxxAif4DBsvo%3DRqFw%40mail.gmail.com.
--00000000000068d966056d95d24c
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 F=
ri, Jun 1, 2018 at 9:52 AM, Richard Hodges <span dir=3D"ltr"><<a href=3D=
"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a>></s=
pan> 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"><br><br><div=
class=3D"gmail_quote"><span class=3D""><div dir=3D"ltr">On Fri, 1 Jun 2018=
at 15:38, Dejan Milosavljevic <<a href=3D"mailto:dmilos@gmail.com" targ=
et=3D"_blank">dmilos@gmail.com</a>> wrote:<br></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>Take look at next thread:</div><div>=C2=A0=
<a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/aEdZv=
QS1Soc/8TpSRdhSAQAJ" target=3D"_blank">https://groups.google.com/a/<wbr>iso=
cpp.org/d/msg/std-<wbr>proposals/aEdZvQS1Soc/<wbr>8TpSRdhSAQAJ</a></div><di=
v><br></div><div>Everything what apply to GUI is same for Graphics.=C2=A0<b=
r></div></div></blockquote><div><br></div></span><div>And yet OpenGL is a (=
very successful) standard thing...</div></div></div></blockquote><div><br><=
/div><div>With at least three competing "standards". So I guess i=
t's not so standard.</div></div><div><br></div>-- <br><div class=3D"gma=
il_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div=
dir=3D"ltr">-- Rene Rivera<br>-- Grafik - Don't Assume Anything<br>-- =
Robot Dreams -=C2=A0<a href=3D"http://robot-dreams.net/" target=3D"_blank">=
http://robot-dreams.net</a><br><br></div></div></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" 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/CAHEh_GghBeFQGCv2WqWct1bkfC_F8NrGTGxx=
Aif4DBsvo%3DRqFw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_GghBeFQGC=
v2WqWct1bkfC_F8NrGTGxxAif4DBsvo%3DRqFw%40mail.gmail.com</a>.<br />
--00000000000068d966056d95d24c--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 1 Jun 2018 08:06:11 -0700 (PDT)
Raw View
------=_Part_10768_109537121.1527865571398
Content-Type: multipart/alternative;
boundary="----=_Part_10769_575308706.1527865571399"
------=_Part_10769_575308706.1527865571399
Content-Type: text/plain; charset="UTF-8"
On Friday, June 1, 2018 at 10:33:03 AM UTC-4, Richard Hodges wrote:
>
> > But what we need is a better way to collecting bits and pieces, not to
> put the whole world in the standard to make up for insufficient tooling !
>
> A standard way, even?
>
If by "standard" you mean "supported in all environments", yes. If by
"standard" you mean "defined in the ISO C++ standard", then no.
While the C++ standard can certainly take tooling into account, and even
make suggestions, it can't *define* how tools work the way it defines how
the object model and so forth work.
--
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/77f5ed53-0673-4382-b579-5d08794c3805%40isocpp.org.
------=_Part_10769_575308706.1527865571399
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, June 1, 2018 at 10:33:03 AM UTC-4, Richard Hodg=
es 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">>=
=C2=A0<span style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:1=
3px;font-style:normal;font-weight:400;letter-spacing:normal;text-align:star=
t;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;b=
ackground-color:rgb(255,255,255);float:none;display:inline">But what we nee=
d is a better way to collecting bits and pieces, not to put the whole world=
in the standard to make up for insufficient tooling !</span><div><span sty=
le=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:=
normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0=
px;text-transform:none;white-space:normal;word-spacing:0px;background-color=
:rgb(255,255,255);float:none;display:inline"><br></span></div><div>A standa=
rd way, even?</div></div></blockquote><div><br></div><div>If by "stand=
ard" you mean "supported in all environments", yes. If by &q=
uot;standard" you mean "defined in the ISO C++ standard", th=
en no.</div><div><br></div><div>While the C++ standard can certainly take t=
ooling into account, and even make suggestions, it can't <i>define</i> =
how tools work the way it defines how the object model and so forth work.</=
div><br></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/77f5ed53-0673-4382-b579-5d08794c3805%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/77f5ed53-0673-4382-b579-5d08794c3805=
%40isocpp.org</a>.<br />
------=_Part_10769_575308706.1527865571399--
------=_Part_10768_109537121.1527865571398--
.
Author: Robert Ramey <ramey@rrsd.com>
Date: Fri, 1 Jun 2018 09:31:53 -0700
Raw View
On 6/1/18 7:32 AM, Richard Hodges wrote:
> > But what we need is a better way to collecting bits and pieces, not
> to put the whole world in the standard to make up for insufficient tooling !
>
> A standard way, even?
Actually this is most valuable insight.
The standard works well for the language and certain core libraries such
as those required to create a common facade for the local operating system.
But it doesn't work well when trying to design library components by
committee. These components are too complex, too large, and the
environment is too dynamic to be done within the standards process.
People do create these components outside of the standards process:
Boost, CGal, Eigen and many, many, many others. And of course there is
GitHub. But these are not standardized - so what is the problem.
The problem is that they are not standardized. That is they are
a) of uneven quality
b) often not documented
c) evolve "too fast"
d) fail to present a single widely accepted interface. That is there
are often competing, different, but similar libraries which are meant to
address the same problem.
f) developers of libraries are not sufficiently funded to invest the
effort required to address the shortcomings above.
e) including packages of different versions from differing sources
creates difficulties in management of larger applications.
Assuming the above is an accurate description of the current and past
situation, what should be done.
I've got some ideas - but I'll leave that for a later post.
Robert Ramey
--
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/pers9n%248ih%241%40blaine.gmane.org.
.
Author: Rene Rivera <grafikrobot@gmail.com>
Date: Fri, 1 Jun 2018 12:28:28 -0500
Raw View
--000000000000879f22056d97e95e
Content-Type: text/plain; charset="UTF-8"
On Fri, Jun 1, 2018 at 10:06 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> While the C++ standard can certainly take tooling into account, and even
> make suggestions, it can't *define* how tools work the way it defines how
> the object model and so forth work.
>
Why "can't [it] define how tools work"? After all it already defines that
there is a source to executable transformation tool.
--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
--
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/CAHEh_Gje7bTjm-syUtcWP4kg3bxrbrARB6d4%2BcdqGp%3DVWffvpA%40mail.gmail.com.
--000000000000879f22056d97e95e
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 F=
ri, Jun 1, 2018 at 10:06 AM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></s=
pan> 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>While t=
he C++ standard can certainly take tooling into account, and even make sugg=
estions, it can't <i>define</i> how tools work the way it defines how t=
he object model and so forth work.</div></div></blockquote><div><br></div><=
div>Why "can't [it] define how tools work"? After all it alre=
ady defines that there is a source to executable transformation tool.</div>=
<div><br></div></div><div><br></div>-- <br><div class=3D"gmail_signature" d=
ata-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr">--=
Rene Rivera<br>-- Grafik - Don't Assume Anything<br>-- Robot Dreams -=
=C2=A0<a href=3D"http://robot-dreams.net/" target=3D"_blank">http://robot-d=
reams.net</a><br><br></div></div></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" 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/CAHEh_Gje7bTjm-syUtcWP4kg3bxrbrARB6d4=
%2BcdqGp%3DVWffvpA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_Gje7bTj=
m-syUtcWP4kg3bxrbrARB6d4%2BcdqGp%3DVWffvpA%40mail.gmail.com</a>.<br />
--000000000000879f22056d97e95e--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 1 Jun 2018 11:46:33 -0700 (PDT)
Raw View
------=_Part_12105_383779787.1527878793944
Content-Type: multipart/alternative;
boundary="----=_Part_12106_864313174.1527878793945"
------=_Part_12106_864313174.1527878793945
Content-Type: text/plain; charset="UTF-8"
On Friday, June 1, 2018 at 1:28:30 PM UTC-4, Rene Rivera wrote:
>
> On Fri, Jun 1, 2018 at 10:06 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> While the C++ standard can certainly take tooling into account, and even
>> make suggestions, it can't *define* how tools work the way it defines
>> how the object model and so forth work.
>>
>
> Why "can't [it] define how tools work"? After all it already defines that
> there is a source to executable transformation tool.
>
No, it does not. Nowhere does the standard talk about an "executable". It
describes the behavior of an implementation, which *could be* an
interpreter for all the standard cares.
Now, the committee could produce some kind of technical report about how to
go about making build systems compatible with each other or some such (and
if it leads to unification, I'm all for it). But this would not be part of
the C++ standard itself.
--
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/5e4d757d-b3ef-4ac6-b2d2-4802ce2fbef0%40isocpp.org.
------=_Part_12106_864313174.1527878793945
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, June 1, 2018 at 1:28:30 PM UTC-4, Rene Rivera w=
rote:<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">On Fri, Jun 1, 2018 at 10:06 AM, Nicol Bolas <span =
dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"sfY4S8ENAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';ret=
urn true;">jmck...@gmail.com</a>></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>While the C++ standard can certainly take t=
ooling into account, and even make suggestions, it can't <i>define</i> =
how tools work the way it defines how the object model and so forth work.</=
div></div></blockquote><div><br></div><div>Why "can't [it] define =
how tools work"? After all it already defines that there is a source t=
o executable transformation tool.</div></div></div></div></blockquote><div>=
<br></div><div>No, it does not. Nowhere does the standard talk about an &qu=
ot;executable". It describes the behavior of an implementation, which =
<i>could be</i> an interpreter for all the standard cares.</div><div><br></=
div><div>Now, the committee could produce some kind of technical report abo=
ut how to go about making build systems compatible with each other or some =
such (and if it leads to unification, I'm all for it). But this would n=
ot be part of the C++ standard itself.<br></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5e4d757d-b3ef-4ac6-b2d2-4802ce2fbef0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5e4d757d-b3ef-4ac6-b2d2-4802ce2fbef0=
%40isocpp.org</a>.<br />
------=_Part_12106_864313174.1527878793945--
------=_Part_12105_383779787.1527878793944--
.
Author: Rene Rivera <grafikrobot@gmail.com>
Date: Fri, 1 Jun 2018 14:08:00 -0500
Raw View
--000000000000808c8a056d994d38
Content-Type: text/plain; charset="UTF-8"
On Fri, Jun 1, 2018 at 1:46 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Friday, June 1, 2018 at 1:28:30 PM UTC-4, Rene Rivera wrote:
>>
>> On Fri, Jun 1, 2018 at 10:06 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> While the C++ standard can certainly take tooling into account, and even
>>> make suggestions, it can't *define* how tools work the way it defines
>>> how the object model and so forth work.
>>>
>>
>> Why "can't [it] define how tools work"? After all it already defines that
>> there is a source to executable transformation tool.
>>
>
> No, it does not. Nowhere does the standard talk about an "executable". It
> describes the behavior of an implementation, which *could be* an
> interpreter for all the standard cares.
>
Okay... But it does talk about linking TUs into a program. Which
practically has a limited set of meanings.
> Now, the committee could produce some kind of technical report about how
> to go about making build systems compatible with each other or some such
> (and if it leads to unification, I'm all for it). But this would not be
> part of the C++ standard itself.
>
Right.. But, again, why can't the standard specify behavior of tools? What
prevents such a specification from being adopted, assuming someone proposes
it?
--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
--
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/CAHEh_Gg46a5wbbE_q0vre9FNicAZZB_Mq5aFVMhmQAK6yWK1yw%40mail.gmail.com.
--000000000000808c8a056d994d38
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 F=
ri, Jun 1, 2018 at 1:46 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></sp=
an> 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">On Friday, Ju=
ne 1, 2018 at 1:28:30 PM UTC-4, Rene Rivera wrote:<span class=3D""><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_q=
uote">On Fri, Jun 1, 2018 at 10:06 AM, Nicol Bolas <span dir=3D"ltr"><<a=
rel=3D"nofollow">jmck...@gmail.com</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>While the C++ standard can certainly=
take tooling into account, and even make suggestions, it can't <i>defi=
ne</i> how tools work the way it defines how the object model and so forth =
work.</div></div></blockquote><div><br></div><div>Why "can't [it] =
define how tools work"? After all it already defines that there is a s=
ource to executable transformation tool.</div></div></div></div></blockquot=
e><div><br></div></span><div>No, it does not. Nowhere does the standard tal=
k about an "executable". It describes the behavior of an implemen=
tation, which <i>could be</i> an interpreter for all the standard cares.</d=
iv></div></blockquote><div><br></div><div>Okay... But it does talk about li=
nking TUs into a program. Which practically has a limited set of meanings.<=
/div><div>=C2=A0</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>=
Now, the committee could produce some kind of technical report about how to=
go about making build systems compatible with each other or some such (and=
if it leads to unification, I'm all for it). But this would not be par=
t of the C++ standard itself.<br></div></div></blockquote><div><br></div><d=
iv>Right.. But, again, why can't the standard specify behavior of tools=
? What prevents such a specification from being adopted, assuming someone p=
roposes it?</div><div><br></div></div>-- <br><div class=3D"gmail_signature"=
data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr">=
-- Rene Rivera<br>-- Grafik - Don't Assume Anything<br>-- Robot Dreams =
-=C2=A0<a href=3D"http://robot-dreams.net/" target=3D"_blank">http://robot-=
dreams.net</a><br><br></div></div></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" 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/CAHEh_Gg46a5wbbE_q0vre9FNicAZZB_Mq5aF=
VMhmQAK6yWK1yw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_Gg46a5wbbE_=
q0vre9FNicAZZB_Mq5aFVMhmQAK6yWK1yw%40mail.gmail.com</a>.<br />
--000000000000808c8a056d994d38--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Fri, 1 Jun 2018 15:43:52 -0400
Raw View
--000000000000687cc1056d99ce3b
Content-Type: text/plain; charset="UTF-8"
On Fri, Jun 1, 2018 at 12:32 PM Robert Ramey <ramey@rrsd.com> wrote:
> The problem is that they are not standardized.
>
The standardization of [filesystem] contributes 46 pages to the C++
Standard,
incorporates POSIX by reference, and is full of "for POSIX it does this and
for
Windows it does that" statements along with other waffling. (For example,
the
specification of absolute(const path&p) in [fs.op.absolute] contains this:
*Implementations are strongly encouraged to ... not consider !exists(p) an
error.*)
I submit that standardizing file system operation in the C++ Standard hasn't
really standardized much, since the underlying system dependencies are still
showing through and have to be accounted for, and has added complexity and
length to a standard that is already too complex and too long. Adding
graphics
would be a hundred times worse.
Programming language standards should define the programming language.
Functionality not required by the core language should be standardized
separately, if people are moved to do it.
--
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/CAHSYqdYkh1BJe3UHVP_8AtdEspvBBKNK9E2or%2BdFLH83ajgyuA%40mail.gmail.com.
--000000000000687cc1056d99ce3b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Jun 1,=
2018 at 12:32 PM Robert Ramey <<a href=3D"mailto:ramey@rrsd.com" target=
=3D"_blank">ramey@rrsd.com</a>> wrote:</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">
The problem is that they are not standardized.<br></blockquote><div><br>The=
standardization of [filesystem] contributes 46 pages to the C++ Standard,<=
br>incorporates POSIX by reference, and is full of "for POSIX it does =
this and for<br>Windows it does that" statements along with other waff=
ling.=C2=A0 (For example, the<br>specification of=C2=A0<font face=3D"monosp=
ace, monospace">absolute(const path&p)</font>=C2=A0in [fs.op.absolute] =
contains this:<br><i>Implementations are strongly encouraged to ... not con=
sider <font face=3D"monospace, monospace">!exists(p)</font> an error.</i>)<=
br><br>I submit that standardizing file system operation in the C++ Standar=
d hasn't<br>really standardized much, since the underlying system depen=
dencies are still<br>showing through and have to be accounted for, and has =
added complexity and<br>length to a standard that is already too complex an=
d too long.=C2=A0 Adding graphics<br>would be a hundred times worse.<br><br=
>Programming language standards should define the programming language.<br>=
Functionality not required by the core language should be standardized<br>s=
eparately, if people are moved to do it.</div></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYkh1BJe3UHVP_8AtdEspvBBKNK9E2o=
r%2BdFLH83ajgyuA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYkh1BJe3=
UHVP_8AtdEspvBBKNK9E2or%2BdFLH83ajgyuA%40mail.gmail.com</a>.<br />
--000000000000687cc1056d99ce3b--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 1 Jun 2018 13:15:53 -0700 (PDT)
Raw View
------=_Part_12606_164433557.1527884153270
Content-Type: multipart/alternative;
boundary="----=_Part_12607_1684145751.1527884153271"
------=_Part_12607_1684145751.1527884153271
Content-Type: text/plain; charset="UTF-8"
On Friday, June 1, 2018 at 3:44:06 PM UTC-4, Hyman Rosen wrote:
>
> On Fri, Jun 1, 2018 at 12:32 PM Robert Ramey <ra...@rrsd.com <javascript:>>
> wrote:
>
>> The problem is that they are not standardized.
>>
>
> The standardization of [filesystem] contributes 46 pages to the C++
> Standard,
> incorporates POSIX by reference, and is full of "for POSIX it does this
> and for
> Windows it does that" statements along with other waffling.
>
Not one *normative* statement in the standard has any of this "waffling".
Any platform-specific information are in [notes], and therefore are not
required parts of the actual specification.
(For example, the
> specification of absolute(const path&p) in [fs.op.absolute] contains this:
> *Implementations are strongly encouraged to ... not consider !exists(p) an
> error.*)
>
> I submit that standardizing file system operation in the C++ Standard
> hasn't
> really standardized much, since the underlying system dependencies are
> still
> showing through and have to be accounted for, and has added complexity and
> length to a standard that is already too complex and too long.
>
If you can write cross-platform code without a single `#ifdef WINDOWS` or
whatever, then the standard is doing its job. The existence of
implementation-dependent aspects of the standard does not mean that you
cannot write your code such that it works on all platforms.
Consider the statement on `absolute`. All you need to do is handle errors
that happen, to write your code as if you can't call it on a file that
doesn't exist. It's not a problem.
Adding graphics
> would be a hundred times worse.
>
> Programming language standards should define the programming language.
>
By that logic, we shouldn't have file APIs, streams, containers, atomics,
threads, or anything of that nature. Those aren't the "programming
language", so there's no need for any part of the standard library outside
of the language support library.
And what good would that have accomplished? How would that make C++ a
better programming environment?
Functionality not required by the core language should be standardized
> separately, if people are moved to do it.
>
--
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/2035f76f-5775-44c1-b9cc-e9249d9b8142%40isocpp.org.
------=_Part_12607_1684145751.1527884153271
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, June 1, 2018 at 3:44:06 PM UTC-4, Hyman Rosen w=
rote:<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 cla=
ss=3D"gmail_quote"><div dir=3D"ltr">On Fri, Jun 1, 2018 at 12:32 PM Robert =
Ramey <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"yUpnnycVAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascri=
pt:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;">ra...@rrsd.com</a>> wrote:</div><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">
The problem is that they are not standardized.<br></blockquote><div><br>The=
standardization of [filesystem] contributes 46 pages to the C++ Standard,<=
br>incorporates POSIX by reference, and is full of "for POSIX it does =
this and for<br>Windows it does that" statements along with other waff=
ling.</div></div></div></blockquote><div><br></div><div>Not one <i>normativ=
e</i> statement in the standard has any of this "waffling". Any p=
latform-specific information are in [notes], and therefore are not required=
parts of the actual specification.</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div class=3D"gmail_quote"><di=
v>(For example, the<br>specification of=C2=A0<font face=3D"monospace, monos=
pace">absolute(const path&p)</font>=C2=A0in [fs.op.absolute] contains t=
his:<br><i>Implementations are strongly encouraged to ... not consider <fon=
t face=3D"monospace, monospace">!exists(p)</font> an error.</i>)<br><br>I s=
ubmit that standardizing file system operation in the C++ Standard hasn'=
;t<br>really standardized much, since the underlying system dependencies ar=
e still<br>showing through and have to be accounted for, and has added comp=
lexity and<br>length to a standard that is already too complex and too long=
..</div></div></div></blockquote><div><br></div><div>If you can write cross-=
platform code without a single `#ifdef WINDOWS` or whatever, then the stand=
ard is doing its job. The existence of implementation-dependent aspects of =
the standard does not mean that you cannot write your code such that it wor=
ks on all platforms.</div><div><br></div><div>Consider the statement on `ab=
solute`. All you need to do is handle errors that happen, to write your cod=
e as if you can't call it on a file that doesn't exist. It's no=
t a problem.<br></div><div><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>Adding graphics<br>=
would be a hundred times worse.<br><br>Programming language standards shoul=
d define the programming language.<br></div></div></div></blockquote><div><=
br></div><div>By that logic, we shouldn't have file APIs, streams, cont=
ainers, atomics, threads, or anything of that nature. Those aren't the =
"programming language", so there's no need for any part of th=
e standard library outside of the language support library.</div><div><br><=
/div><div>And what good would that have accomplished? How would that make C=
++ a better programming environment?<br></div><div><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div class=3D"gmail_quote">=
<div>Functionality not required by the core language should be standardized=
<br>separately, if people are moved to do it. <br></div></div></div></block=
quote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2035f76f-5775-44c1-b9cc-e9249d9b8142%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2035f76f-5775-44c1-b9cc-e9249d9b8142=
%40isocpp.org</a>.<br />
------=_Part_12607_1684145751.1527884153271--
------=_Part_12606_164433557.1527884153270--
.
Author: Dilip Ranganathan <misc.usage@gmail.com>
Date: Fri, 1 Jun 2018 16:51:41 -0400
Raw View
--0000000000004bac08056d9ac05a
Content-Type: text/plain; charset="UTF-8"
On Fri, Jun 1, 2018 at 4:15 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Friday, June 1, 2018 at 3:44:06 PM UTC-4, Hyman Rosen wrote:
>>
>>
>>> Adding graphics
>>
> would be a hundred times worse.
>>
>> Programming language standards should define the programming language.
>>
>
> By that logic, we shouldn't have file APIs, streams, containers, atomics,
> threads, or anything of that nature. Those aren't the "programming
> language", so there's no need for any part of the standard library outside
> of the language support library.
>
And what good would that have accomplished? How would that make C++ a
better programming environment?
I think you were too quick with that one. He wrote this in the very next
line:
>> *Functionality not required by the core language should be standardized*
>> *separately*, if people are moved to do it.
--
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/CALEPxfuC%2BAVhdHdiGzFhj85AE-L_Ai_0837tGYCtxr4cMVEetA%40mail.gmail.com.
--0000000000004bac08056d9ac05a
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 F=
ri, Jun 1, 2018 at 4:15 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></sp=
an> 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">On Friday, Ju=
ne 1, 2018 at 3:44:06 PM UTC-4, Hyman Rosen wrote:<span class=3D""><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><br></blockquote><div>Ad=
ding graphics<br></div></div></div></blockquote></span><span class=3D""><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_q=
uote"><div>would be a hundred times worse.<br><br>Programming language stan=
dards should define the programming language.<br></div></div></div></blockq=
uote><div><br></div></span><div>By that logic, we shouldn't have file A=
PIs, streams, containers, atomics, threads, or anything of that nature. Tho=
se aren't the "programming language", so there's no need =
for any part of the standard library outside of the language support librar=
y.</div></div></blockquote><div>=C2=A0 =C2=A0And what good would that have =
accomplished? How would that make C++ a better programming environment?<br>=
<br>I think you were too quick with that one. He wrote this in the very nex=
t line:</div><div><br></div><div>>>=C2=A0
<b style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:smal=
l;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;=
letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;=
white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-=
decoration-style:initial;text-decoration-color:initial"><u>Functionality no=
t required by the core language should be standardized</u></b></div><div><s=
pan style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:sma=
ll;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal=
;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none=
;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text=
-decoration-style:initial;text-decoration-color:initial">>>=C2=A0=C2=
=A0<b style=3D"text-decoration-line:underline">separately</b></span><span s=
tyle=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;fo=
nt-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font=
-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-tra=
nsform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,25=
5,255);text-decoration-style:initial;text-decoration-color:initial;float:no=
ne;display:inline">, if people are moved to do it.<span>=C2=A0</span></span=
>
<br><br></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" 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/CALEPxfuC%2BAVhdHdiGzFhj85AE-L_Ai_083=
7tGYCtxr4cMVEetA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALEPxfuC%2BAVh=
dHdiGzFhj85AE-L_Ai_0837tGYCtxr4cMVEetA%40mail.gmail.com</a>.<br />
--0000000000004bac08056d9ac05a--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 1 Jun 2018 14:15:24 -0700 (PDT)
Raw View
------=_Part_12828_1449723883.1527887725139
Content-Type: multipart/alternative;
boundary="----=_Part_12829_484506786.1527887725140"
------=_Part_12829_484506786.1527887725140
Content-Type: text/plain; charset="UTF-8"
On Friday, June 1, 2018 at 4:51:44 PM UTC-4, Dilip R wrote:
>
> On Fri, Jun 1, 2018 at 4:15 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Friday, June 1, 2018 at 3:44:06 PM UTC-4, Hyman Rosen wrote:
>>>
>>>
>>>> Adding graphics
>>>
>> would be a hundred times worse.
>>>
>>> Programming language standards should define the programming language.
>>>
>>
>> By that logic, we shouldn't have file APIs, streams, containers, atomics,
>> threads, or anything of that nature. Those aren't the "programming
>> language", so there's no need for any part of the standard library outside
>> of the language support library.
>>
> And what good would that have accomplished? How would that make C++ a
> better programming environment?
>
> I think you were too quick with that one. He wrote this in the very next
> line:
>
> >> *Functionality not required by the core language should be
> standardized*
> >> *separately*, if people are moved to do it.
>
>
I still fail to see how that makes C++ a better programming environment.
It's bad enough that we have compiler and standard library implementations
separately declaring "C++17 conformance". We really don't need the C++
language and standard library *standards* advancing at different rates.
Consider the spaceship operator. Adjusting the standard library to properly
take advantage of it is kind of important. Having that be a part of the
same standard release as the operator itself is equally important for
making the feature useful. What good is default generation of comparison
operators if some of your most commonly used types don't use it because
their standard hasn't been updated yet? If I can't even stick an
`optional<T>` in a type and have `operator<=> = default` work, how useful
will that feature be?
Indeed, if you look at the worst, most painful, or generally unpleasant
language features of C++ since C++11, more likely than not, the ones on
that list are the ones that are least used by the standard library.
"Uniform initialization" isn't used by `std::allocator::construct`,
`make_shared`, or similar features. Why? Because it's too broken to be used
in general in template contexts.
C++ needs to eat its own dogfood. The standard library is a way to do that.
Having the standard library directly linked to the language is a positive
thing for the language and for programmers working within that language.
--
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/8b16c598-0574-4590-bc7e-01d5429c652a%40isocpp.org.
------=_Part_12829_484506786.1527887725140
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, June 1, 2018 at 4:51:44 PM UTC-4, Dilip=
R 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=
><div class=3D"gmail_quote">On Fri, Jun 1, 2018 at 4:15 PM, Nicol Bolas <sp=
an dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"7NqjUNgYAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'j=
avascript:';return true;" onclick=3D"this.href=3D'javascript:';=
return true;">jmck...@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">On Friday, June 1, 2018 at 3:44:06 PM UTC-4,=
Hyman Rosen wrote:<span><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 class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><br></blockquote><div>Adding graphics<br></div></div></div></blo=
ckquote></span><span><blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div class=3D"gmail_quote"><div>would be a hundred times worse.<br><br>P=
rogramming language standards should define the programming language.<br></=
div></div></div></blockquote><div><br></div></span><div>By that logic, we s=
houldn't have file APIs, streams, containers, atomics, threads, or anyt=
hing of that nature. Those aren't the "programming language",=
so there's no need for any part of the standard library outside of the=
language support library.</div></div></blockquote><div>=C2=A0 =C2=A0And wh=
at good would that have accomplished? How would that make C++ a better prog=
ramming environment?<br><br>I think you were too quick with that one. He wr=
ote this in the very next line:</div><div><br></div><div>>>=C2=A0
<b style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:smal=
l;font-style:normal;letter-spacing:normal;text-align:start;text-indent:0px;=
text-transform:none;white-space:normal;word-spacing:0px;background-color:rg=
b(255,255,255)"><u>Functionality not required by the core language should b=
e standardized</u></b></div><div><span style=3D"color:rgb(34,34,34);font-fa=
mily:arial,sans-serif;font-size:small;font-style:normal;letter-spacing:norm=
al;text-align:start;text-indent:0px;text-transform:none;white-space:normal;=
word-spacing:0px;background-color:rgb(255,255,255)">>>=C2=A0=C2=A0<b>=
separately</b></span><span style=3D"color:rgb(34,34,34);font-family:arial,s=
ans-serif;font-size:small;font-style:normal;font-weight:400;letter-spacing:=
normal;text-align:start;text-indent:0px;text-transform:none;white-space:nor=
mal;word-spacing:0px;background-color:rgb(255,255,255);float:none;display:i=
nline">, if people are moved to do it.<span>=C2=A0</span></span>
<br><br></div></div></div></div></blockquote><div><br></div><div>I still fa=
il to see how that makes C++ a better programming environment.</div><div><b=
r></div><div>It's bad enough that we have compiler and standard library=
implementations separately declaring "C++17 conformance". We rea=
lly don't need the C++ language and standard library <i>standards</i> a=
dvancing at different rates.</div><div><br></div><div>Consider the spaceshi=
p operator. Adjusting the standard library to properly take advantage of it=
is kind of important. Having that be a part of the same standard release a=
s the operator itself is equally important for making the feature useful. W=
hat good is default generation of comparison operators if some of your most=
commonly used types don't use it because their standard hasn't bee=
n updated yet? If I can't even stick an `optional<T>` in a type a=
nd have `operator<=3D> =3D default` work, how useful will that featur=
e be?<br></div><div><br></div><div>Indeed, if you look at the worst, most p=
ainful, or generally unpleasant language features of C++ since C++11, more =
likely than not, the ones on that list are the ones that are least used by =
the standard library. "Uniform initialization" isn't used by =
`std::allocator::construct`, `make_shared`, or similar features. Why? Becau=
se it's too broken to be used in general in template contexts.<br></div=
><div><br></div><div>C++ needs to eat its own dogfood. The standard library=
is a way to do that. Having the standard library directly linked to the la=
nguage is a positive thing for the language and for programmers working wit=
hin that language.<br></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8b16c598-0574-4590-bc7e-01d5429c652a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8b16c598-0574-4590-bc7e-01d5429c652a=
%40isocpp.org</a>.<br />
------=_Part_12829_484506786.1527887725140--
------=_Part_12828_1449723883.1527887725139--
.
Author: mihailnajdenov@gmail.com
Date: Fri, 1 Jun 2018 14:16:23 -0700 (PDT)
Raw View
------=_Part_13065_608498145.1527887783665
Content-Type: multipart/alternative;
boundary="----=_Part_13066_1887728245.1527887783666"
------=_Part_13066_1887728245.1527887783666
Content-Type: text/plain; charset="UTF-8"
On Friday, June 1, 2018 at 11:15:53 PM UTC+3, Nicol Bolas wrote:
>
> On Friday, June 1, 2018 at 3:44:06 PM UTC-4, Hyman Rosen wrote:
>>
>> On Fri, Jun 1, 2018 at 12:32 PM Robert Ramey <ra...@rrsd.com> wrote:
>>
>>> The problem is that they are not standardized.
>>>
>>
>> The standardization of [filesystem] contributes 46 pages to the C++
>> Standard,
>> incorporates POSIX by reference, and is full of "for POSIX it does this
>> and for
>> Windows it does that" statements along with other waffling.
>>
>
> Not one *normative* statement in the standard has any of this "waffling".
> Any platform-specific information are in [notes], and therefore are not
> required parts of the actual specification.
>
> (For example, the
>> specification of absolute(const path&p) in [fs.op.absolute] contains
>> this:
>> *Implementations are strongly encouraged to ... not consider !exists(p)
>> an error.*)
>>
>> I submit that standardizing file system operation in the C++ Standard
>> hasn't
>> really standardized much, since the underlying system dependencies are
>> still
>> showing through and have to be accounted for, and has added complexity and
>> length to a standard that is already too complex and too long.
>>
>
> If you can write cross-platform code without a single `#ifdef WINDOWS` or
> whatever, then the standard is doing its job. The existence of
> implementation-dependent aspects of the standard does not mean that you
> cannot write your code such that it works on all platforms.
>
> Consider the statement on `absolute`. All you need to do is handle errors
> that happen, to write your code as if you can't call it on a file that
> doesn't exist. It's not a problem.
>
> Adding graphics
>> would be a hundred times worse.
>>
>> Programming language standards should define the programming language.
>>
>
> By that logic, we shouldn't have file APIs, streams, containers, atomics,
> threads, or anything of that nature. Those aren't the "programming
> language", so there's no need for any part of the standard library outside
> of the language support library.
>
> And what good would that have accomplished? How would that make C++ a
> better programming environment?
>
I guess it is the ratio of uses vs diversity vs dynamic of the task that is
to be in a library.
Uses must be high, diversity (alternative interpretations of what it is,
different attack vectors, different priorities) low and dynamic (rate of
change) also low
All the things you mentioned fit the criteria ok, well or very well - Many
people use them, there are no grotesque alternative views of they are,
quite low dynamic (new "inventions" of these come rarely)
At higher level libraries things start to lose on these properties.
FS is good example.
It is saved by the fact the use is high (anyone will want to save a file or
list folders contents), but the diversity is also moderate-high (many
different attack vectors), dynamic is moderate-to-high as well (for
instance mac switched to urls around the time the FS got adopted)
As a result FS falls back to a decades old API and if you use the native
APIs you will have order of magnate better, as in
modern/professional/feature rich, file IO. This is true for all major
platforms.
Still, as said FS is fine, because of the high potential use and the fact
not anyone needs feature rich IO.
Things much, much worse for Graphics in any of three criteria and this time
around, in contrast to FS, falling back to "some basic principals" risks
making it useless outside prototyping and teaching.
>
> Functionality not required by the core language should be standardized
>> separately, if people are moved to do it.
>>
>
--
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/31d6c89e-cbc9-4b25-b9e2-c2f2a98bef0f%40isocpp.org.
------=_Part_13066_1887728245.1527887783666
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, June 1, 2018 at 11:15:53 PM UTC+3, Nico=
l Bolas 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"=
>On Friday, June 1, 2018 at 3:44:06 PM UTC-4, Hyman Rosen 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 class=3D"gmail_quote"><d=
iv dir=3D"ltr">On Fri, Jun 1, 2018 at 12:32 PM Robert Ramey <<a rel=3D"n=
ofollow">ra...@rrsd.com</a>> wrote:</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">
The problem is that they are not standardized.<br></blockquote><div><br>The=
standardization of [filesystem] contributes 46 pages to the C++ Standard,<=
br>incorporates POSIX by reference, and is full of "for POSIX it does =
this and for<br>Windows it does that" statements along with other waff=
ling.</div></div></div></blockquote><div><br></div><div>Not one <i>normativ=
e</i> statement in the standard has any of this "waffling". Any p=
latform-specific information are in [notes], and therefore are not required=
parts of the actual specification.</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>(Fo=
r example, the<br>specification of=C2=A0<font face=3D"monospace, monospace"=
>absolute(const path&p)</font>=C2=A0in [fs.op.absolute] contains this:<=
br><i>Implementations are strongly encouraged to ... not consider <font fac=
e=3D"monospace, monospace">!exists(p)</font> an error.</i>)<br><br>I submit=
that standardizing file system operation in the C++ Standard hasn't<br=
>really standardized much, since the underlying system dependencies are sti=
ll<br>showing through and have to be accounted for, and has added complexit=
y and<br>length to a standard that is already too complex and too long.</di=
v></div></div></blockquote><div><br></div><div>If you can write cross-platf=
orm code without a single `#ifdef WINDOWS` or whatever, then the standard i=
s doing its job. The existence of implementation-dependent aspects of the s=
tandard does not mean that you cannot write your code such that it works on=
all platforms.</div><div><br></div><div>Consider the statement on `absolut=
e`. All you need to do is handle errors that happen, to write your code as =
if you can't call it on a file that doesn't exist. It's not a p=
roblem.<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div class=3D"gmail_quote"><div>Adding graphics<br>would be a=
hundred times worse.<br><br>Programming language standards should define t=
he programming language.<br></div></div></div></blockquote><div><br></div><=
div>By that logic, we shouldn't have file APIs, streams, containers, at=
omics, threads, or anything of that nature. Those aren't the "prog=
ramming language", so there's no need for any part of the standard=
library outside of the language support library.</div><div><br></div><div>=
And what good would that have accomplished? How would that make C++ a bette=
r programming environment?<br></div></div></blockquote><div><br></div><div>=
<br></div><div><div style=3D"background-color: transparent; border-bottom-c=
olor: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px;=
border-image-outset: 0; border-image-repeat: stretch; border-image-slice: =
100%; border-image-source: none; border-image-width: 1; border-left-color: =
rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; border-ri=
ght-color: rgb(34, 34, 34); border-right-style: none; border-right-width: 0=
px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-top-w=
idth: 0px; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&=
amp;quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: norma=
l; font-variant: normal; font-weight: 400; letter-spacing: normal; margin-b=
ottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: =
2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top:=
0px; text-align: left; text-decoration: none; text-indent: 0px; text-trans=
form: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spaci=
ng: 0px;">I guess it is the ratio of uses vs diversity vs dynamic of the ta=
sk that is to be in a library.=C2=A0</div><div style=3D"background-color: t=
ransparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none=
; border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: st=
retch; border-image-slice: 100%; border-image-source: none; border-image-wi=
dth: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; border=
-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: =
none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-to=
p-style: none; border-top-width: 0px; color: rgb(34, 34, 34); font-family: =
&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-si=
ze: 13px; font-style: normal; font-variant: normal; font-weight: 400; lette=
r-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px;=
margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; paddi=
ng-right: 0px; padding-top: 0px; text-align: left; text-decoration: none; t=
ext-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; whit=
e-space: normal; word-spacing: 0px;"><br></div><div style=3D"background-col=
or: transparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style:=
none; border-bottom-width: 0px; border-image-outset: 0; border-image-repea=
t: stretch; border-image-slice: 100%; border-image-source: none; border-ima=
ge-width: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; b=
order-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-st=
yle: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); bord=
er-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34); font-fam=
ily: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; fo=
nt-size: 13px; font-style: normal; font-variant: normal; font-weight: 400; =
letter-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right:=
0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; =
padding-right: 0px; padding-top: 0px; text-align: left; text-decoration: no=
ne; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px;=
white-space: normal; word-spacing: 0px;">Uses must be high, diversity (alt=
ernative interpretations of what it is, different attack vectors, different=
priorities) low and dynamic (rate of change) also low</div><div style=3D"b=
ackground-color: transparent; border-bottom-color: rgb(34, 34, 34); border-=
bottom-style: none; border-bottom-width: 0px; border-image-outset: 0; borde=
r-image-repeat: stretch; border-image-slice: 100%; border-image-source: non=
e; border-image-width: 1; border-left-color: rgb(34, 34, 34); border-left-s=
tyle: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34); bo=
rder-right-style: none; border-right-width: 0px; border-top-color: rgb(34, =
34, 34); border-top-style: none; border-top-width: 0px; color: rgb(34, 34, =
34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,s=
ans-serif; font-size: 13px; font-style: normal; font-variant: normal; font-=
weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px; =
margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; paddin=
g-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; text-d=
ecoration: none; text-indent: 0px; text-transform: none; -webkit-text-strok=
e-width: 0px; white-space: normal; word-spacing: 0px;"><br style=3D"backgro=
und-attachment: scroll; background-clip: border-box; background-color: tran=
sparent; background-image: none; background-origin: padding-box; background=
-position-x: 0%; background-position-y: 0%; background-repeat: repeat; back=
ground-size: auto; border-bottom-color: rgb(34, 34, 34); border-bottom-styl=
e: none; border-bottom-width: 0px; border-image-outset: 0; border-image-rep=
eat: stretch; border-image-slice: 100%; border-image-source: none; border-i=
mage-width: 1; border-left-color: rgb(34, 34, 34); border-left-style: none;=
border-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-=
style: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); bo=
rder-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34); font-f=
amily: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; =
font-size: 13px; height: auto; margin-bottom: 0px; margin-left: 0px; margin=
-right: 0px; margin-top: 0px; min-width: 0px; overflow: visible; overflow-x=
: visible; overflow-y: visible; padding-bottom: 0px; padding-left: 0px; pad=
ding-right: 0px; padding-top: 0px;"></div><div style=3D"background-color: t=
ransparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none=
; border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: st=
retch; border-image-slice: 100%; border-image-source: none; border-image-wi=
dth: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; border=
-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: =
none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-to=
p-style: none; border-top-width: 0px; color: rgb(34, 34, 34); font-family: =
&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-si=
ze: 13px; font-style: normal; font-variant: normal; font-weight: 400; lette=
r-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px;=
margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; paddi=
ng-right: 0px; padding-top: 0px; text-align: left; text-decoration: none; t=
ext-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; whit=
e-space: normal; word-spacing: 0px;">All the things you mentioned fit the c=
riteria ok, well or very well - Many people use them, there are no grotesqu=
e alternative views of they are, quite low dynamic (new "inventions&qu=
ot; of these come rarely)</div><div style=3D"background-color: transparent;=
border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bo=
ttom-width: 0px; border-image-outset: 0; border-image-repeat: stretch; bord=
er-image-slice: 100%; border-image-source: none; border-image-width: 1; bor=
der-left-color: rgb(34, 34, 34); border-left-style: none; border-left-width=
: 0px; border-right-color: rgb(34, 34, 34); border-right-style: none; borde=
r-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: no=
ne; border-top-width: 0px; color: rgb(34, 34, 34); font-family: &quot;A=
rial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; f=
ont-style: normal; font-variant: normal; font-weight: 400; letter-spacing: =
normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top=
: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right: 0=
px; padding-top: 0px; text-align: left; text-decoration: none; text-indent:=
0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: no=
rmal; word-spacing: 0px;">=C2=A0</div><div style=3D"background-color: trans=
parent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; bo=
rder-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stretc=
h; border-image-slice: 100%; border-image-source: none; border-image-width:=
1; border-left-color: rgb(34, 34, 34); border-left-style: none; border-lef=
t-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: none=
; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-st=
yle: none; border-top-width: 0px; color: rgb(34, 34, 34); font-family: &=
;quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: =
13px; font-style: normal; font-variant: normal; font-weight: 400; letter-sp=
acing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; mar=
gin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-r=
ight: 0px; padding-top: 0px; text-align: left; text-decoration: none; text-=
indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-sp=
ace: normal; word-spacing: 0px;">At higher level libraries things start to =
lose on these properties.=C2=A0</div><div style=3D"background-color: transp=
arent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; bor=
der-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stretch=
; border-image-slice: 100%; border-image-source: none; border-image-width: =
1; border-left-color: rgb(34, 34, 34); border-left-style: none; border-left=
-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: none;=
border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-sty=
le: none; border-top-width: 0px; color: rgb(34, 34, 34); font-family: &=
quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 1=
3px; font-style: normal; font-variant: normal; font-weight: 400; letter-spa=
cing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; marg=
in-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-ri=
ght: 0px; padding-top: 0px; text-align: left; text-decoration: none; text-i=
ndent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-spa=
ce: normal; word-spacing: 0px;"><br></div><div style=3D"background-color: t=
ransparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none=
; border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: st=
retch; border-image-slice: 100%; border-image-source: none; border-image-wi=
dth: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; border=
-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: =
none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-to=
p-style: none; border-top-width: 0px; color: rgb(34, 34, 34); font-family: =
&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-si=
ze: 13px; font-style: normal; font-variant: normal; font-weight: 400; lette=
r-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px;=
margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; paddi=
ng-right: 0px; padding-top: 0px; text-align: left; text-decoration: none; t=
ext-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; whit=
e-space: normal; word-spacing: 0px;">FS is good example.=C2=A0</div><div st=
yle=3D"background-color: transparent; border-bottom-color: rgb(34, 34, 34);=
border-bottom-style: none; border-bottom-width: 0px; border-image-outset: =
0; border-image-repeat: stretch; border-image-slice: 100%; border-image-sou=
rce: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); borde=
r-left-style: none; border-left-width: 0px; border-right-color: rgb(34, 34,=
34); border-right-style: none; border-right-width: 0px; border-top-color: =
rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; color: rgb(=
34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&=
;quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: norma=
l; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-lef=
t: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px=
; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left=
; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-te=
xt-stroke-width: 0px; white-space: normal; word-spacing: 0px;">It is saved =
by the fact the use is high (anyone will want to save a file or list folder=
s contents), but the diversity is also moderate-high (many different attack=
vectors), <span style=3D"background-color: transparent; border-bottom-colo=
r: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; bo=
rder-image-outset: 0; border-image-repeat: stretch; border-image-slice: 100=
%; border-image-source: none; border-image-width: 1; border-left-color: rgb=
(34, 34, 34); border-left-style: none; border-left-width: 0px; border-right=
-color: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px;=
border-top-color: rgb(34, 34, 34); border-top-style: none; border-top-widt=
h: 0px; color: rgb(34, 34, 34); display: inline; float: none; font-family: =
&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-si=
ze: 13px; font-style: normal; font-variant: normal; font-weight: 400; lette=
r-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px;=
margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; paddi=
ng-right: 0px; padding-top: 0px; text-align: left; text-decoration: none; t=
ext-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; whit=
e-space: normal; word-spacing: 0px;">dynamic </span>is moderate-to-high as =
well (for instance mac switched to urls around the time the FS got adopted)=
</div><div style=3D"background-color: transparent; border-bottom-color: rgb=
(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-i=
mage-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; bor=
der-image-source: none; border-image-width: 1; border-left-color: rgb(34, 3=
4, 34); border-left-style: none; border-left-width: 0px; border-right-color=
: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; borde=
r-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px=
; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;=
Helvetica&quot;,sans-serif; font-size: 13px; font-style: normal; font-v=
ariant: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0p=
x; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; paddin=
g-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; tex=
t-align: left; text-decoration: none; text-indent: 0px; text-transform: non=
e; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"=
><br style=3D"background-attachment: scroll; background-clip: border-box; b=
ackground-color: transparent; background-image: none; background-origin: pa=
dding-box; background-position-x: 0%; background-position-y: 0%; background=
-repeat: repeat; background-size: auto; border-bottom-color: rgb(34, 34, 34=
); border-bottom-style: none; border-bottom-width: 0px; border-image-outset=
: 0; border-image-repeat: stretch; border-image-slice: 100%; border-image-s=
ource: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); bor=
der-left-style: none; border-left-width: 0px; border-right-color: rgb(34, 3=
4, 34); border-right-style: none; border-right-width: 0px; border-top-color=
: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; color: rg=
b(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&a=
mp;quot;,sans-serif; font-size: 13px; height: auto; margin-bottom: 0px; mar=
gin-left: 0px; margin-right: 0px; margin-top: 0px; min-width: 0px; overflow=
: visible; overflow-x: visible; overflow-y: visible; padding-bottom: 0px; p=
adding-left: 0px; padding-right: 0px; padding-top: 0px;"></div><div style=
=3D"background-color: transparent; border-bottom-color: rgb(34, 34, 34); bo=
rder-bottom-style: none; border-bottom-width: 0px; border-image-outset: 0; =
border-image-repeat: stretch; border-image-slice: 100%; border-image-source=
: none; border-image-width: 1; border-left-color: rgb(34, 34, 34); border-l=
eft-style: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34=
); border-right-style: none; border-right-width: 0px; border-top-color: rgb=
(34, 34, 34); border-top-style: none; border-top-width: 0px; color: rgb(34,=
34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&qu=
ot;,sans-serif; font-size: 13px; font-style: normal; font-variant: normal; =
font-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-left: =
0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; p=
adding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; t=
ext-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-=
stroke-width: 0px; white-space: normal; word-spacing: 0px;">As a result FS =
falls back to a decades old API and if you use the native APIs you will hav=
e order of magnate better, as in modern/professional/feature rich, file IO.=
This is true for all major platforms.=C2=A0</div><div style=3D"background-=
color: transparent; border-bottom-color: rgb(34, 34, 34); border-bottom-sty=
le: none; border-bottom-width: 0px; border-image-outset: 0; border-image-re=
peat: stretch; border-image-slice: 100%; border-image-source: none; border-=
image-width: 1; border-left-color: rgb(34, 34, 34); border-left-style: none=
; border-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right=
-style: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); b=
order-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34); font-=
family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;=
font-size: 13px; font-style: normal; font-variant: normal; font-weight: 40=
0; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-rig=
ht: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0p=
x; padding-right: 0px; padding-top: 0px; text-align: left; text-decoration:=
none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0=
px; white-space: normal; word-spacing: 0px;">Still, as said FS is fine, bec=
ause of the high potential use and the fact not anyone needs <span style=3D=
"display: inline !important; float: none; background-color: transparent; co=
lor: rgb(34, 34, 34); font-family: "Arial","Helvetica",=
sans-serif; font-size: 13px; font-style: normal; font-variant: normal; font=
-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-de=
coration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke=
-width: 0px; white-space: normal; word-spacing: 0px;">feature rich </span>I=
O.</div><div style=3D"background-color: transparent; border-bottom-color: r=
gb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border=
-image-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; b=
order-image-source: none; border-image-width: 1; border-left-color: rgb(34,=
34, 34); border-left-style: none; border-left-width: 0px; border-right-col=
or: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; bor=
der-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0=
px; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quo=
t;Helvetica&quot;,sans-serif; font-size: 13px; font-style: normal; font=
-variant: normal; font-weight: 400; letter-spacing: normal; margin-bottom: =
0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padd=
ing-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; t=
ext-align: left; text-decoration: none; text-indent: 0px; text-transform: n=
one; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px=
;"><br></div><div style=3D"background-color: transparent; border-bottom-col=
or: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; b=
order-image-outset: 0; border-image-repeat: stretch; border-image-slice: 10=
0%; border-image-source: none; border-image-width: 1; border-left-color: rg=
b(34, 34, 34); border-left-style: none; border-left-width: 0px; border-righ=
t-color: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px=
; border-top-color: rgb(34, 34, 34); border-top-style: none; border-top-wid=
th: 0px; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&am=
p;quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: normal;=
font-variant: normal; font-weight: 400; letter-spacing: normal; margin-bot=
tom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2;=
padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0=
px; text-align: left; text-decoration: none; text-indent: 0px; text-transfo=
rm: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing=
: 0px;">Things much, much worse for Graphics in any of three criteria and t=
his time around, in contrast to FS, falling back to "some basic princi=
pals" risks making it useless outside prototyping and teaching.<br></d=
iv>=C2=A0</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><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div class=3D"gmail_quote"><div>Functionality not required by the=
core language should be standardized<br>separately, if people are moved to=
do it. <br></div></div></div></blockquote></div></blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/31d6c89e-cbc9-4b25-b9e2-c2f2a98bef0f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/31d6c89e-cbc9-4b25-b9e2-c2f2a98bef0f=
%40isocpp.org</a>.<br />
------=_Part_13066_1887728245.1527887783666--
------=_Part_13065_608498145.1527887783665--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 01 Jun 2018 18:36:27 -0700
Raw View
On Friday, 1 June 2018 12:08:00 PDT Rene Rivera wrote:
> Right.. But, again, why can't the standard specify behavior of tools? What
> prevents such a specification from being adopted, assuming someone proposes
> it?
Try and we'll see.
What tools are you talking about anyway?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/1743822.X6ygPEYEuq%40tjmaciei-mobl1.
.
Author: Rene Rivera <grafikrobot@gmail.com>
Date: Fri, 1 Jun 2018 21:00:52 -0500
Raw View
--00000000000008490e056d9f1232
Content-Type: text/plain; charset="UTF-8"
On Fri, Jun 1, 2018 at 8:36 PM, Thiago Macieira <thiago@macieira.org> wrote:
> On Friday, 1 June 2018 12:08:00 PDT Rene Rivera wrote:
> > Right.. But, again, why can't the standard specify behavior of tools?
> What
> > prevents such a specification from being adopted, assuming someone
> proposes
> > it?
>
> Try and we'll see.
>
I am going to try (I actually started on such a try last Fall). But I was
really curious as to why people think it's not possible. So as to try and
avoid roadblocks.
What tools are you talking about anyway?
>
The compiler of course. As it's the first step in being able to define
common aspects for build systems and package managers.
--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
--
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/CAHEh_GjqfQeTGVM0dkULGYNzMyOzXDf3aJJdLR6qgvj0peQLOg%40mail.gmail.com.
--00000000000008490e056d9f1232
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 F=
ri, Jun 1, 2018 at 8:36 PM, Thiago Macieira <span dir=3D"ltr"><<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Frid=
ay, 1 June 2018 12:08:00 PDT Rene Rivera wrote:<br>
> Right.. But, again, why can't the standard specify behavior of too=
ls? What<br>
> prevents such a specification from being adopted, assuming someone pro=
poses<br>
> it?<br>
<br>
</span>Try and we'll see.<br></blockquote><div><br></div><div>I am goin=
g to try (I actually started on such a try last Fall). But I was really cur=
ious as to why people think it's not possible. So as to try and avoid r=
oadblocks.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What tools are you talking about anyway?<br></blockquote><div><br></div><di=
v>The compiler of course. As it's the first step in being able to defin=
e common aspects for build systems and package managers.</div></div><div><b=
r></div>-- <br><div class=3D"gmail_signature" data-smartmail=3D"gmail_signa=
ture"><div dir=3D"ltr"><div><div dir=3D"ltr">-- Rene Rivera<br>-- Grafik - =
Don't Assume Anything<br>-- Robot Dreams -=C2=A0<a href=3D"http://robot=
-dreams.net/" target=3D"_blank">http://robot-dreams.net</a><br><br></div></=
div></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" 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/CAHEh_GjqfQeTGVM0dkULGYNzMyOzXDf3aJJd=
LR6qgvj0peQLOg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_GjqfQeTGVM0=
dkULGYNzMyOzXDf3aJJdLR6qgvj0peQLOg%40mail.gmail.com</a>.<br />
--00000000000008490e056d9f1232--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Sat, 2 Jun 2018 03:17:41 +0100
Raw View
--000000000000ce9b50056d9f4eee
Content-Type: text/plain; charset="UTF-8"
Related: https://xkcd.com/927/
Personally, I don't think the resources are worth the outcome. I look
forward to seeing the results of any efforts towards a proposal, though, in
the hope that it will change my mind.
--
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/CAC%2B0CCPJqbCNgSt%2Bz9ctBC3HknBecU5kBsfszgVjdbJzFrN3%2Bw%40mail.gmail.com.
--000000000000ce9b50056d9f4eee
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div dir=3D"auto">Related:=C2=A0<a href=3D"https://xkcd.c=
om/927/">https://xkcd.com/927/</a><br></div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">Personally, I don't think the resources are worth the ou=
tcome. I look forward to seeing the results of any efforts towards a propos=
al, though, in the hope that it will change my mind.</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPJqbCNgSt%2Bz9ctBC3HknBecU5k=
BsfszgVjdbJzFrN3%2Bw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPJ=
qbCNgSt%2Bz9ctBC3HknBecU5kBsfszgVjdbJzFrN3%2Bw%40mail.gmail.com</a>.<br />
--000000000000ce9b50056d9f4eee--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 01 Jun 2018 20:15:19 -0700
Raw View
On Friday, 1 June 2018 19:00:52 PDT Rene Rivera wrote:
> The compiler of course. As it's the first step in being able to define
> common aspects for build systems and package managers.
Compilers are actually mostly compatible with each other. This goes back to
the early days of "cc", the C compiler that came with Unix. Since almost every
single compiler invented is meant to be a drop-in replacement to an earlier
compiler, almost all of them behave the same way in the core functionality.
Except for MSVC (and ICC on Windows and Clang-cl), which in turn are meant to
be compatible with the older C compilers on DOS, which used options slightly
differently because of limitations of that system. And still they are mostly
compatible with their Unix counterparts, except for one gratuitous change:
naming the object files .obj, instead of .o.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/8539420.4ZEJzz54VO%40tjmaciei-mobl1.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 1 Jun 2018 22:02:09 -0700 (PDT)
Raw View
------=_Part_15491_1108242966.1527915729471
Content-Type: multipart/alternative;
boundary="----=_Part_15492_160257740.1527915729471"
------=_Part_15492_160257740.1527915729471
Content-Type: text/plain; charset="UTF-8"
On Friday, June 1, 2018 at 10:00:54 PM UTC-4, Rene Rivera wrote:
>
> On Fri, Jun 1, 2018 at 8:36 PM, Thiago Macieira <thi...@macieira.org
> <javascript:>> wrote:
>
>> On Friday, 1 June 2018 12:08:00 PDT Rene Rivera wrote:
>> > Right.. But, again, why can't the standard specify behavior of tools?
>> What
>> > prevents such a specification from being adopted, assuming someone
>> proposes
>> > it?
>>
>> Try and we'll see.
>>
>
> I am going to try (I actually started on such a try last Fall). But I was
> really curious as to why people think it's not possible. So as to try and
> avoid roadblocks.
>
The kind of tool you need to make it easy to download and build a random
C++ application is some form of build system. A *platform independent*
build system. That requires dealing with a lot of things that the C++
language standard doesn't even come close to.
Basically, think of the analogy like this. The works of Shakespeare, no
matter how interesting or wonderful they may be, are not appropriate for
inclusion in a *dictionary* or a book on grammar. These are two
different-yet-related things that exist in two different-yet-related
domains.
The same goes for the C++ language and a build system. Yes, we would love
to have a platform-independent build system. But that's not part of the
language, because that's not what the language is for.
What tools are you talking about anyway?
>>
>
> The compiler of course. As it's the first step in being able to define
> common aspects for build systems and package managers.
>
Where does the standard mandate the presence of a "compiler"? There is
merely the "implementation". Non-normative language may occasionally refer
to a "compiler", but as far as the normative standard is concerned, there
are just "implementations".
Nothing is said about the implementation, save for the fact that it
implements the standard as described.
--
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/9bad3834-d0d7-4642-ad8c-b44e0c9b3ce9%40isocpp.org.
------=_Part_15492_160257740.1527915729471
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, June 1, 2018 at 10:00:54 PM UTC-4, Rene Rivera =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><d=
iv class=3D"gmail_quote">On Fri, Jun 1, 2018 at 8:36 PM, Thiago Macieira <s=
pan dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"Q5NFeLcpAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
javascript:';return true;" onclick=3D"this.href=3D'javascript:'=
;return true;">thi...@macieira.org</a>></span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><span>On Friday, 1 June 2018 12:08:00 PDT Rene Rivera wrote=
:<br>
> Right.. But, again, why can't the standard specify behavior of too=
ls? What<br>
> prevents such a specification from being adopted, assuming someone pro=
poses<br>
> it?<br>
<br>
</span>Try and we'll see.<br></blockquote><div><br></div><div>I am goin=
g to try (I actually started on such a try last Fall). But I was really cur=
ious as to why people think it's not possible. So as to try and avoid r=
oadblocks.</div></div></div></div></blockquote><div><br></div><div><div>The=
kind of tool you need to make it easy to download and build a random C++ a=
pplication is some form of build system. A <i>platform independent</i> buil=
d system. That requires dealing with a lot of things that the C++ language =
standard doesn't even come close to.</div><div><br></div><div>Basically=
,
think of the analogy like this. The works of Shakespeare, no matter how
interesting or wonderful they may be, are not appropriate for inclusion
in a <i>dictionary</i> or a book on grammar. These are two different-yet-r=
elated things that exist in two different-yet-related domains.<br></div><di=
v><br></div>The
same goes for the C++ language and a build system. Yes, we would love=20
to have a platform-independent build system. But that's not part of the=
=20
language, because that's not what the language is for.</div><div> <br><=
/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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What tools are you talking about anyway?<br></blockquote><div><br></div><di=
v>The compiler of course. As it's the first step in being able to defin=
e common aspects for build systems and package managers.</div></div></div><=
/div></blockquote><div><br></div><div>Where does the standard mandate the p=
resence of a "compiler"? There is merely the "implementation=
". Non-normative language may occasionally refer to a "compiler&q=
uot;, but as far as the normative standard is concerned, there are just &qu=
ot;implementations".</div><div><br></div><div>Nothing is said about th=
e implementation, save for the fact that it implements the standard as desc=
ribed.<br></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9bad3834-d0d7-4642-ad8c-b44e0c9b3ce9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9bad3834-d0d7-4642-ad8c-b44e0c9b3ce9=
%40isocpp.org</a>.<br />
------=_Part_15492_160257740.1527915729471--
------=_Part_15491_1108242966.1527915729471--
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Sat, 2 Jun 2018 08:55:43 +0200
Raw View
On Fri, Jun 01, 2018 at 09:31:53AM -0700, Robert Ramey wrote:
> On 6/1/18 7:32 AM, Richard Hodges wrote:
> > > But what we need is a better way to collecting bits and pieces, not
> > to put the whole world in the standard to make up for insufficient
> > tooling !
> >
> > A standard way, even?
>
> Actually this is most valuable insight.
>
> The standard works well for the language and certain core libraries such as
> those required to create a common facade for the local operating system.
>
> But it doesn't work well when trying to design library components by
> committee. These components are too complex, too large, and the environment
> is too dynamic to be done within the standards process. People do create
> these components outside of the standards process: Boost, CGal, Eigen and
> many, many, many others. And of course there is GitHub. But these are not
> standardized - so what is the problem.
>
> The problem is that they are not standardized. That is they are
>
> a) of uneven quality
> b) often not documented
> c) evolve "too fast"
> d) fail to present a single widely accepted interface. That is there are
> often competing, different, but similar libraries which are meant to address
> the same problem.
> f) developers of libraries are not sufficiently funded to invest the effort
> required to address the shortcomings above.
> e) including packages of different versions from differing sources creates
> difficulties in management of larger applications.
>
> Assuming the above is an accurate description of the current and past
> situation, what should be done.
I think you missed one bullet:
g) evolve "too slow"
Both c) and g) can be true at the same time if there is more than one user of
the library.
/MF
--
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/20180602065543.GA5176%40noemi.bahnhof.se.
.
Author: Rene Rivera <grafikrobot@gmail.com>
Date: Sat, 2 Jun 2018 08:42:22 -0500
Raw View
--000000000000c972e2056da8dedf
Content-Type: text/plain; charset="UTF-8"
On Sat, Jun 2, 2018 at 12:02 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Friday, June 1, 2018 at 10:00:54 PM UTC-4, Rene Rivera wrote:
>>
>> On Fri, Jun 1, 2018 at 8:36 PM, Thiago Macieira <thi...@macieira.org>
>> wrote:
>>
>>> On Friday, 1 June 2018 12:08:00 PDT Rene Rivera wrote:
>>> > Right.. But, again, why can't the standard specify behavior of tools?
>>> What
>>> > prevents such a specification from being adopted, assuming someone
>>> proposes
>>> > it?
>>>
>>> Try and we'll see.
>>>
>>
>> I am going to try (I actually started on such a try last Fall). But I was
>> really curious as to why people think it's not possible. So as to try and
>> avoid roadblocks.
>>
>
> The kind of tool you need to make it easy to download and build a random
> C++ application is some form of build system. A *platform independent*
> build system. That requires dealing with a lot of things that the C++
> language standard doesn't even come close to.
>
Yes, aware.. I wrote, and maintain, one of those.
Basically, think of the analogy like this. The works of Shakespeare, no
> matter how interesting or wonderful they may be, are not appropriate for
> inclusion in a *dictionary* or a book on grammar. These are two
> different-yet-related things that exist in two different-yet-related
> domains.
>
Interesting analogy.
The same goes for the C++ language and a build system. Yes, we would love
> to have a platform-independent build system. But that's not part of the
> language, because that's not what the language is for.
>
I don't disagree.
> What tools are you talking about anyway?
>>>
>>
>> The compiler of course. As it's the first step in being able to define
>> common aspects for build systems and package managers.
>>
>
> Where does the standard mandate the presence of a "compiler"? There is
> merely the "implementation". Non-normative language may occasionally refer
> to a "compiler", but as far as the normative standard is concerned, there
> are just "implementations".
>
> Nothing is said about the implementation, save for the fact that it
> implements the standard as described.
>
Are you saying that the reason we can't define X is because X is undefined?
--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
--
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/CAHEh_GgjA8jg7Orqn%3D830D5gaK0n5vJMroRbQXkuyFWP3k85OQ%40mail.gmail.com.
--000000000000c972e2056da8dedf
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 S=
at, Jun 2, 2018 at 12:02 AM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></s=
pan> 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">On Friday, J=
une 1, 2018 at 10:00:54 PM UTC-4, Rene Rivera wrote:<span class=3D""><block=
quote 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 Fri, Jun 1, 2018 at 8:36 PM, Thiago Macieira <span dir=3D"ltr">&=
lt;<a rel=3D"nofollow">thi...@macieira.org</a>></span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><span>On Friday, 1 June 2018 12:08:00 PDT Rene Rive=
ra wrote:<br>
> Right.. But, again, why can't the standard specify behavior of too=
ls? What<br>
> prevents such a specification from being adopted, assuming someone pro=
poses<br>
> it?<br>
<br>
</span>Try and we'll see.<br></blockquote><div><br></div><div>I am goin=
g to try (I actually started on such a try last Fall). But I was really cur=
ious as to why people think it's not possible. So as to try and avoid r=
oadblocks.</div></div></div></div></blockquote><div><br></div></span><div><=
div>The kind of tool you need to make it easy to download and build a rando=
m C++ application is some form of build system. A <i>platform independent</=
i> build system. That requires dealing with a lot of things that the C++ la=
nguage standard doesn't even come close to.</div></div></div></blockquo=
te><div><br></div><div>Yes, aware.. I wrote, and maintain, one of those.</d=
iv><div><br></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><div=
>Basically,
think of the analogy like this. The works of Shakespeare, no matter how
interesting or wonderful they may be, are not appropriate for inclusion
in a <i>dictionary</i> or a book on grammar. These are two different-yet-r=
elated things that exist in two different-yet-related domains.<br></div></d=
iv></div></blockquote><div><br></div><div>Interesting analogy.=C2=A0</div><=
div><br></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>The
same goes for the C++ language and a build system. Yes, we would love=20
to have a platform-independent build system. But that's not part of the=
=20
language, because that's not what the language is for.</div></div></blo=
ckquote><div><br></div><div>I don't disagree.</div><div>=C2=A0</div><bl=
ockquote 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""><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"=
><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
What tools are you talking about anyway?<br></blockquote><div><br></div><di=
v>The compiler of course. As it's the first step in being able to defin=
e common aspects for build systems and package managers.</div></div></div><=
/div></blockquote><div><br></div></span><div>Where does the standard mandat=
e the presence of a "compiler"? There is merely the "impleme=
ntation". Non-normative language may occasionally refer to a "com=
piler", but as far as the normative standard is concerned, there are j=
ust "implementations".</div><div><br></div><div>Nothing is said a=
bout the implementation, save for the fact that it implements the standard =
as described.<br></div></div></blockquote><div><br></div><div>Are you sayin=
g that the reason we can't define X is because X is undefined?</div><di=
v><br></div></div><div><br></div>-- <br><div class=3D"gmail_signature" data=
-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr">-- Re=
ne Rivera<br>-- Grafik - Don't Assume Anything<br>-- Robot Dreams -=C2=
=A0<a href=3D"http://robot-dreams.net/" target=3D"_blank">http://robot-drea=
ms.net</a><br><br></div></div></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" 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/CAHEh_GgjA8jg7Orqn%3D830D5gaK0n5vJMro=
RbQXkuyFWP3k85OQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_GgjA8jg7O=
rqn%3D830D5gaK0n5vJMroRbQXkuyFWP3k85OQ%40mail.gmail.com</a>.<br />
--000000000000c972e2056da8dedf--
.
Author: Robert Ramey <ramey@rrsd.com>
Date: Sat, 2 Jun 2018 11:09:46 -0700
Raw View
On 6/1/18 11:55 PM, Magnus Fromreide wrote:
> On Fri, Jun 01, 2018 at 09:31:53AM -0700, Robert Ramey wrote:
>> On 6/1/18 7:32 AM, Richard Hodges wrote:
>>> > But what we need is a better way to collecting bits and pieces, not
>>> to put the whole world in the standard to make up for insufficient
>>> tooling !
>>>
>>> A standard way, even?
>>
>> Actually this is most valuable insight.
>>
>> The standard works well for the language and certain core libraries such as
>> those required to create a common facade for the local operating system.
>>
>> But it doesn't work well when trying to design library components by
>> committee. These components are too complex, too large, and the environment
>> is too dynamic to be done within the standards process. People do create
>> these components outside of the standards process: Boost, CGal, Eigen and
>> many, many, many others. And of course there is GitHub. But these are not
>> standardized - so what is the problem.
>>
>> The problem is that they are not standardized. That is they are
>>
>> a) of uneven quality
>> b) often not documented
>> c) evolve "too fast"
>> d) fail to present a single widely accepted interface. That is there are
>> often competing, different, but similar libraries which are meant to address
>> the same problem.
>> f) developers of libraries are not sufficiently funded to invest the effort
>> required to address the shortcomings above.
>> e) including packages of different versions from differing sources creates
>> difficulties in management of larger applications.
>>
>> Assuming the above is an accurate description of the current and past
>> situation, what should be done.
>
> I think you missed one bullet:
>
> g) evolve "too slow"
>
> Both c) and g) can be true at the same time if there is more than one user of
> the library.
>
> /MF
Right.
Some historical perspective. I got my hands on the the source code to a
C compiler in 1980 for a Z80 microprocessor. I saw the merit of the
language right away as I was working with COBOL at the time. I had a
Data General 16 bit processor - high performance machine for it's time.
I crafted a backend for the DG. It came with what would be considered
today a very primitive standard library. I only had to tweak a few
functions written in assembler (fopen, ...) and then use the same
compiler to re-compile the standard library. That was it.
Hundreds of others did the same thing. C was available on a very wide
variety of machines of various architectures.
Today, this is not possible. Aside that the language is too large and
complex, libraries are now provided by the same supplier as the compiler
itself, they end up coupled. So porting the standard library to another
architecture seems like a big job.
Soooo ... I suggest
a) separating the standard library as a separate component with it's own
committee etc. Coordination between the standard library committee and
language would be limited to cases where some new library function
requires compiler support.
b) making the "standard library" much smaller. Limit it to basic
functions such as API to interface with operating environment. Things
like mutex, file io etc.
c) leave "application" level components to the open source market place.
d) Encourage standards for library development. These are things that
everyone agrees we should be doing but almost most no one does.
Documentation, consistent naming, test suite. reviews etc.
Documentation is kind of interesting. The standard actually has a
section named "17.4 Method of Description" which basically supports
documentation similar to the original STL documents. See
http://www.rrsd.com/software_development/stl/index.htm. Interestingly,
almost no one follows or attempts to enforce these "informative"
prescription. Changing this might be considered.
e) Reconsidering the model for compensation of library authors.
Currently there is no such model. If library authors could be paid for
their work it some proportion to it's utility, it might permit us to
raise expectations for independently created "standard libraries"
There might be several ideas for the form such compensation might take:
Some sort of royalty would be great - but perhaps hard to enforce.
There might be an anual prize - The Falco prize (named after my friend
vinnie falco) of significant sum ($100,000). For the best new open
source C++ library. This would sucker in a lot of us to create better
quality libraries.
Perhaps there are other ideas. But just working harder using the
current structure and method is not going to improve things.
Robert Ramey
--
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/peumd9%241mt%241%40blaine.gmane.org.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 2 Jun 2018 11:35:23 -0700 (PDT)
Raw View
------=_Part_19117_1369966717.1527964524002
Content-Type: multipart/alternative;
boundary="----=_Part_19118_534292831.1527964524003"
------=_Part_19118_534292831.1527964524003
Content-Type: text/plain; charset="UTF-8"
On Saturday, June 2, 2018 at 2:10:04 PM UTC-4, Robert Ramey wrote:
>
> On 6/1/18 11:55 PM, Magnus Fromreide wrote:
> > On Fri, Jun 01, 2018 at 09:31:53AM -0700, Robert Ramey wrote:
> >> On 6/1/18 7:32 AM, Richard Hodges wrote:
> >>> > But what we need is a better way to collecting bits and pieces,
> not
> >>> to put the whole world in the standard to make up for insufficient
> >>> tooling !
> >>>
> >>> A standard way, even?
> >>
> >> Actually this is most valuable insight.
> >>
> >> The standard works well for the language and certain core libraries
> such as
> >> those required to create a common facade for the local operating
> system.
> >>
> >> But it doesn't work well when trying to design library components by
> >> committee. These components are too complex, too large, and the
> environment
> >> is too dynamic to be done within the standards process. People do
> create
> >> these components outside of the standards process: Boost, CGal, Eigen
> and
> >> many, many, many others. And of course there is GitHub. But these are
> not
> >> standardized - so what is the problem.
> >>
> >> The problem is that they are not standardized. That is they are
> >>
> >> a) of uneven quality
> >> b) often not documented
> >> c) evolve "too fast"
> >> d) fail to present a single widely accepted interface. That is there
> are
> >> often competing, different, but similar libraries which are meant to
> address
> >> the same problem.
> >> f) developers of libraries are not sufficiently funded to invest the
> effort
> >> required to address the shortcomings above.
> >> e) including packages of different versions from differing sources
> creates
> >> difficulties in management of larger applications.
> >>
> >> Assuming the above is an accurate description of the current and past
> >> situation, what should be done.
> >
> > I think you missed one bullet:
> >
> > g) evolve "too slow"
> >
> > Both c) and g) can be true at the same time if there is more than one
> user of
> > the library.
> >
> > /MF
>
> Right.
>
> Some historical perspective. I got my hands on the the source code to a
> C compiler in 1980 for a Z80 microprocessor. I saw the merit of the
> language right away as I was working with COBOL at the time. I had a
> Data General 16 bit processor - high performance machine for it's time.
> I crafted a backend for the DG. It came with what would be considered
> today a very primitive standard library. I only had to tweak a few
> functions written in assembler (fopen, ...) and then use the same
> compiler to re-compile the standard library. That was it.
>
> Hundreds of others did the same thing. C was available on a very wide
> variety of machines of various architectures.
>
> Today, this is not possible. Aside that the language is too large and
> complex, libraries are now provided by the same supplier as the compiler
> itself, they end up coupled. So porting the standard library to another
> architecture seems like a big job.
>
> Soooo ... I suggest
>
> a) separating the standard library as a separate component with it's own
> committee etc. Coordination between the standard library committee and
> language would be limited to cases where some new library function
> requires compiler support.
>
> b) making the "standard library" much smaller. Limit it to basic
> functions such as API to interface with operating environment. Things
> like mutex, file io etc.
>
> c) leave "application" level components to the open source market place.
>
> d) Encourage standards for library development. These are things that
> everyone agrees we should be doing but almost most no one does.
> Documentation, consistent naming, test suite. reviews etc.
> Documentation is kind of interesting. The standard actually has a
> section named "17.4 Method of Description" which basically supports
> documentation similar to the original STL documents. See
> http://www.rrsd.com/software_development/stl/index.htm. Interestingly,
> almost no one follows or attempts to enforce these "informative"
> prescription. Changing this might be considered.
>
> e) Reconsidering the model for compensation of library authors.
> Currently there is no such model. If library authors could be paid for
> their work it some proportion to it's utility, it might permit us to
> raise expectations for independently created "standard libraries"
> There might be several ideas for the form such compensation might take:
> Some sort of royalty would be great - but perhaps hard to enforce.
> There might be an anual prize - The Falco prize (named after my friend
> vinnie falco) of significant sum ($100,000). For the best new open
> source C++ library. This would sucker in a lot of us to create better
> quality libraries.
>
> Perhaps there are other ideas. But just working harder using the
> current structure and method is not going to improve things.
>
But this isn't going to improve things either.
Dissociating the standard library from the language doesn't improve the
quality of the standard library. In such a system, the library lag behind
language features even moreso than it currently does. That's not improving
things for anyone.
What good would move support in C++11 have been if no standard library
components used it? What good would "uniform initialization" have been
without containers using it? What good are forwarding references and
variadic templates without `emplace` and the like? And so on.
As for "standards for library development", this idea suggests that the ISO
C++ committee has more power than it actually does. It can no more enforce
"standards for library development" than it can make Microsoft respect that
`class` and `struct` are not supposed to be syntactically different. And
without any genuine enforcement, such a "standard" is worthless.
People use libraries because they're useful, not because they follow some
"standard for development".
Furthermore, that ignores the fact that the community has already fractured
with regard to "standards for library development". You're *not* going to
make Qt rename all of its types to fit some other naming convention; it
isn't gonna happen.
The ISO committee also has no power (or money) to award prizes or such
things.
At the end of the day, the C++ ISO committee is simply not the organization
you should be looking to with regard to fixing all of C++'s problems.
Expecting them to do things other than produce language/library standards
is just unreasonable.
What C++ needs is a cross-platform build system that's easy to use (which
knocks CMake out of contention), has some way of easily installing
libraries, and possibly has a centralized repository that anyone can
register a project to use. That is not something that the ISO C++ committee
can accomplish. Some *members* of that committee might be able to help. But
that's simply not their job.
Again, it's like expecting Webster to start publishing the complete works
of Shakespeare. It's simply not their department.
--
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/27acf1a3-02ec-4da0-b8bd-a7b553313799%40isocpp.org.
------=_Part_19118_534292831.1527964524003
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, June 2, 2018 at 2:10:04 PM UTC-4, Robert Rame=
y wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 6/1/18 11:55 PM, Ma=
gnus Fromreide wrote:
<br>> On Fri, Jun 01, 2018 at 09:31:53AM -0700, Robert Ramey wrote:
<br>>> On 6/1/18 7:32 AM, Richard Hodges wrote:
<br>>>> =C2=A0 > But what we need is a better way to collecting=
bits and pieces, not
<br>>>> to put the whole world in the standard to make up for insu=
fficient
<br>>>> tooling !
<br>>>>
<br>>>> A standard way, even?
<br>>>
<br>>> Actually this is most valuable insight.
<br>>>
<br>>> The standard works well for the language and certain core libr=
aries such as
<br>>> those required to create a common facade for the local operati=
ng system.
<br>>>
<br>>> But it doesn't work well when trying to design library com=
ponents by
<br>>> committee. =C2=A0These components are too complex, too large, =
and the environment
<br>>> is too dynamic to be done within the standards process. People=
do create
<br>>> these components outside of the standards process: Boost, CGal=
, Eigen and
<br>>> many, many, many others. And of course there is GitHub. But th=
ese are not
<br>>> standardized - so what is the problem.
<br>>>
<br>>> The problem is that they are not standardized. =C2=A0That is t=
hey are
<br>>>
<br>>> a) of uneven quality
<br>>> b) often not documented
<br>>> c) evolve "too fast"
<br>>> d) fail to present a single widely accepted interface. =C2=A0T=
hat is there are
<br>>> often competing, different, but similar libraries which are me=
ant to address
<br>>> the same problem.
<br>>> f) developers of libraries are not sufficiently funded to inve=
st the effort
<br>>> required to address the shortcomings above.
<br>>> e) including packages of different versions from differing sou=
rces creates
<br>>> difficulties in management of larger applications.
<br>>>
<br>>> Assuming the above is an accurate description of the current a=
nd past
<br>>> situation, what should be done.
<br>>=20
<br>> I think you missed one bullet:
<br>>=20
<br>> g) evolve "too slow"
<br>>=20
<br>> Both c) and g) can be true at the same time if there is more than =
one user of
<br>> the library.
<br>>=20
<br>> /MF
<br>
<br>Right.
<br>
<br>Some historical perspective. =C2=A0I got my hands on the the source cod=
e to a=20
<br>C compiler in 1980 for a Z80 microprocessor. =C2=A0I saw the merit of t=
he=20
<br>language right away as I was working with COBOL at the time. =C2=A0I ha=
d a=20
<br>Data General 16 bit processor - high performance machine for it's t=
ime.=20
<br>I crafted a backend for the DG. =C2=A0It came with what would be consid=
ered=20
<br>today a very primitive standard library. =C2=A0I only had to tweak a fe=
w=20
<br>functions written in assembler (fopen, ...) and then use the same=20
<br>compiler to re-compile the standard library. =C2=A0That was it.
<br>
<br>Hundreds of others did the same thing. =C2=A0C was available on a very =
wide=20
<br>variety of machines of various architectures.
<br>
<br>Today, this is not possible. =C2=A0Aside that the language is too large=
and=20
<br>complex, libraries are now provided by the same supplier as the compile=
r=20
<br>itself, they end up coupled. =C2=A0So porting the standard library to a=
nother=20
<br>architecture seems like a big job.
<br>
<br>Soooo ... I suggest
<br>
<br>a) separating the standard library as a separate component with it'=
s own=20
<br>committee etc. =C2=A0Coordination between the standard library committe=
e and=20
<br>language would be limited to cases where some new library function=20
<br>requires compiler support.
<br>
<br>b) making the "standard library" much smaller. =C2=A0Limit it=
to basic=20
<br>functions such as API to interface with operating environment. =C2=A0Th=
ings=20
<br>like mutex, file io etc.
<br>
<br>c) leave "application" level components to the open source ma=
rket place.
<br>
<br>d) Encourage standards for library development. =C2=A0These are things =
that=20
<br>everyone agrees we should be doing but almost most no one does.=20
<br>Documentation, consistent naming, test suite. reviews etc.=20
<br>Documentation is kind of interesting. The standard actually has a=20
<br>section named "17.4 Method of Description" =C2=A0which basica=
lly supports=20
<br>documentation similar to the original STL documents. =C2=A0See
<br><a href=3D"http://www.rrsd.com/software_development/stl/index.htm" targ=
et=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.g=
oogle.com/url?q\x3dhttp%3A%2F%2Fwww.rrsd.com%2Fsoftware_development%2Fstl%2=
Findex.htm\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGbHJJbSYhmVIAUUFB42b7BE8=
eERg';return true;" onclick=3D"this.href=3D'http://www.google.com/u=
rl?q\x3dhttp%3A%2F%2Fwww.rrsd.com%2Fsoftware_development%2Fstl%2Findex.htm\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGbHJJbSYhmVIAUUFB42b7BE8eERg';r=
eturn true;">http://www.rrsd.com/software_<wbr>development/stl/index.htm</a=
>. =C2=A0Interestingly,=20
<br>almost no one follows or attempts to enforce these "informative&qu=
ot;=20
<br>prescription. =C2=A0Changing this might be considered.
<br>
<br>e) Reconsidering the model for compensation of library authors.=20
<br>Currently there is no such model. =C2=A0If library authors could be pai=
d for=20
<br>their work it some proportion to it's utility, it might permit us t=
o=20
<br>raise expectations for independently created "standard libraries&q=
uot;
<br>There might be several ideas for the form such compensation might take:=
=20
<br>Some sort of royalty would be great - but perhaps hard to enforce.=20
<br>There might be an anual prize - The Falco prize (named after my friend=
=20
<br>vinnie falco) of significant sum ($100,000). =C2=A0For the best new ope=
n=20
<br>source C++ library. =C2=A0This would sucker in a lot of us to create be=
tter=20
<br>quality libraries.
<br>
<br>Perhaps there are other ideas. =C2=A0But just working harder using the=
=20
<br>current structure and method is not going to improve things.
<br></blockquote><div><br></div><div>But this isn't going to improve th=
ings either.</div><div><br></div><div>Dissociating the standard library fro=
m the language doesn't improve the quality of the standard library. In =
such a system, the library lag behind language features even moreso than it=
currently does. That's not improving things for anyone.</div><div><br>=
</div><div>What good would move support in C++11 have been if no standard l=
ibrary components used it? What good would "uniform initialization&quo=
t; have been without containers using it? What good are forwarding referenc=
es and variadic templates without `emplace` and the like? And so on.</div><=
div><br></div><div>As for "standards for library development", th=
is idea suggests that the ISO C++ committee has more power than it actually=
does. It can no more enforce "standards for library development"=
than it can make Microsoft respect that `class` and `struct` are not suppo=
sed to be syntactically different. And without any genuine enforcement, suc=
h a "standard" is worthless.</div><div><br></div><div>People use =
libraries because they're useful, not because they follow some "st=
andard for development".<br></div><div><br></div><div>Furthermore, tha=
t ignores the fact that the community has already fractured with regard to =
"standards for library development". You're <i>not</i> going =
to make Qt rename all of its types to fit some other naming convention; it =
isn't gonna happen.<br></div><div><br></div><div>The ISO committee also=
has no power (or money) to award prizes or such things.</div><div><br></di=
v><div>At the end of the day, the C++ ISO committee is simply not the organ=
ization you should be looking to with regard to fixing all of C++'s pro=
blems. Expecting them to do things other than produce language/library stan=
dards is just unreasonable.</div><div><br></div><div>What C++ needs is a cr=
oss-platform build system that's easy to use (which knocks CMake out of=
contention), has some way of easily installing libraries, and possibly has=
a centralized repository that anyone can register a project to use. That i=
s not something that the ISO C++ committee can accomplish. Some <i>members<=
/i> of that committee might be able to help. But that's simply not thei=
r job.</div><div><br></div><div>Again, it's like expecting Webster to s=
tart publishing the complete works of Shakespeare. It's simply not thei=
r department.<br></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/27acf1a3-02ec-4da0-b8bd-a7b553313799%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/27acf1a3-02ec-4da0-b8bd-a7b553313799=
%40isocpp.org</a>.<br />
------=_Part_19118_534292831.1527964524003--
------=_Part_19117_1369966717.1527964524002--
.
Author: Robert Ramey <ramey@rrsd.com>
Date: Sat, 2 Jun 2018 12:59:31 -0700
Raw View
On 6/2/18 11:35 AM, Nicol Bolas wrote:
> But this isn't going to improve things either.
speculative
>
> Dissociating the standard library from the language doesn't improve the
> quality of the standard library.
speculative.
> In such a system, the library lag
> behind language features even more so than it currently does.
I don't believe this. Many if not most of the standard library
components appeared other places first. Most of boost, type traits,
STL, etc. Very little of the standard library was created by the
standards committee.
When the standards committee gets involved - it hobbles progress.
Ranges, Networking. Very complex components. They been available for
years, while the standards committee versions won't be available for
years to com.
> That's not improving things for anyone.
> What good would move support in C++11 have been if no standard library
> components used it?
> What good would "uniform initialization" have been
> without containers using it?
> What good are forwarding references and
> variadic templates without `emplace` and the like? And so on.
If move support exists, only a short time will pass before library
writers take advantage of it. same for the other features.
> As for "standards for library development", this idea suggests that the
> ISO C++ committee has more power than it actually does. It can no more
> enforce "standards for library development" than it can make Microsoft
> respect that `class` and `struct` are not supposed to be syntactically
> different. And without any genuine enforcement, such a "standard" is
> worthless.
Of course I'm aware of this. ButI've never meant to suggest that this
be "enforced". This is why I included other mechanisms to achieve
improvements of higher standards.
> People use libraries because they're useful, not because they follow
> some "standard for development".
This is my point exactly. Useful libraries have no need to part of some
C++ standard library. Today we have many libraries that are widely
used and are not part of the standard. Eigen, Boost, multiple
serialization libraries, ASIO networking, CGal and many, many, many
more. Being part of the standard wouldn't make these libraries better
and not being part of the standard has not hindered their success.
> Furthermore, that ignores the fact that the community has already
> fractured with regard to "standards for library development". You're
> /not/ going to make Qt rename all of its types to fit some other naming
> convention; it isn't gonna happen.
I'm not suggesting that it happen. When I refer to "standards for
library development" I'm not referring to specifics such as naming (OK -
I said naming - I'll take that back). I'm really referring to a higher
expectation of what constitutes a quality library. I could see some
sort of document similar to the Guidelines Support Library which
provides an expectation of what quality work should look like.
> The ISO committee also has no power (or money) to award prizes or such
> things.
I wouldn't envision the ISO committee doing this. I'm trying to reduce
their workload. I doesn't really matter who does it.
> At the end of the day, the C++ ISO committee is simply not the
> organization you should be looking to with regard to fixing all of C++'s
> problems.
LOL - Right. I'm suggesting that the committee shrink it's area of
responsibility to those things that only such a committee can actually do.
Expecting them to do things other than produce
> language/library standards is just unreasonable.
I'm suggesting that they do less - much less. I'm expecting them to
produce language standards. I'm expecting them to retire form the
library standards business.
> What C++ needs is a cross-platform build system that's easy to use
> (which knocks CMake out of contention), has some way of easily
> installing libraries, and possibly has a centralized repository that
> anyone can register a project to use. That is not something that the ISO
> C++ committee can accomplish. Some /members/ of that committee might be
> able to help. But that's simply not their job.
Agreed. The committee would not be a good vehicle for such an effort -
even if it had the time
> Again, it's like expecting Webster to start publishing the complete
> works of Shakespeare. It's simply not their department.
So we're in agreement.
My proposal is for the committee to reduce it's scope. I'm not sure how
this came across as a proposal to increase that same scope. Sorry if my
proposal wasn't clear.
Robert Ramey
--
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/peusr0%24ipd%241%40blaine.gmane.org.
.
Author: mihailnajdenov@gmail.com
Date: Sat, 2 Jun 2018 13:33:47 -0700 (PDT)
Raw View
------=_Part_6100_1085077975.1527971627554
Content-Type: multipart/alternative;
boundary="----=_Part_6101_1342597120.1527971627555"
------=_Part_6101_1342597120.1527971627555
Content-Type: text/plain; charset="UTF-8"
Robert Ramey, where do you consider is the line b/w library and language
for C++, considering it takes great pride it does most of the stuff as
library?
Also, if the committee develops a library as well (or evaluates one for
standardization), isn't that a good eat-your-own-dog-food for the language
it develops?
Lastly, for C++ 20 and 23, what are the projects You think should be
dropped for good?
--
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/fcd58187-fbcd-4ea8-a99e-626dabb2292c%40isocpp.org.
------=_Part_6101_1342597120.1527971627555
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><span style=3D"display: inline !important; float: non=
e; background-color: transparent; color: rgb(34, 34, 34); font-family: &quo=
t;Arial","Helvetica",sans-serif; font-size: 13px; font-style=
: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; o=
rphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-=
transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-=
spacing: 0px;">Robert Ramey, where do you consider is the line b/w library =
and language for C++, considering it takes great pride it does most of the =
stuff as library?=C2=A0</span></div><div><span style=3D"display: inline !im=
portant; float: none; background-color: transparent; color: rgb(34, 34, 34)=
; font-family: "Arial","Helvetica",sans-serif; font-siz=
e: 13px; font-style: normal; font-variant: normal; font-weight: 400; letter=
-spacing: normal; orphans: 2; text-align: left; text-decoration: none; text=
-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-s=
pace: normal; word-spacing: 0px;"><br></span></div><div><span style=3D"disp=
lay: inline !important; float: none; background-color: transparent; color: =
rgb(34, 34, 34); font-family: "Arial","Helvetica",sans-=
serif; font-size: 13px; font-style: normal; font-variant: normal; font-weig=
ht: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decorat=
ion: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-widt=
h: 0px; white-space: normal; word-spacing: 0px;">Also, if the committee dev=
elops a library as well (or evaluates one for standardization), isn't t=
hat a good eat-your-own-dog-food for the language it develops?</span></div>=
<div><br></div><div>Lastly, for C++ 20 and 23, what are the projects You th=
ink should be dropped for good?=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" 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/fcd58187-fbcd-4ea8-a99e-626dabb2292c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fcd58187-fbcd-4ea8-a99e-626dabb2292c=
%40isocpp.org</a>.<br />
------=_Part_6101_1342597120.1527971627555--
------=_Part_6100_1085077975.1527971627554--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 2 Jun 2018 14:07:25 -0700 (PDT)
Raw View
------=_Part_19821_1699878773.1527973645461
Content-Type: multipart/alternative;
boundary="----=_Part_19822_1804732719.1527973645462"
------=_Part_19822_1804732719.1527973645462
Content-Type: text/plain; charset="UTF-8"
On Saturday, June 2, 2018 at 3:59:41 PM UTC-4, Robert Ramey wrote:
>
> On 6/2/18 11:35 AM, Nicol Bolas wrote:
>
> > But this isn't going to improve things either.
>
> speculative
>
No moreso than yours. I back my speculation up with a detailed explanation
of why it won't help.
> >
> > Dissociating the standard library from the language doesn't improve the
> > quality of the standard library.
>
> speculative.
>
> > In such a system, the library lag
> > behind language features even more so than it currently does.
>
> I don't believe this. Many if not most of the standard library
> components appeared other places first. Most of boost, type traits,
> STL, etc. Very little of the standard library was created by the
> standards committee.
>
What does that have to do with anything I was talking about?
STL's `vector` type didn't have move support because move support *didn't
exist* when STL was created. It didn't have `emplace` because forwarding
references and variadic templates *didn't exist* back then. And so forth.
That is the kind of lagging behind I'm talking about. C++11 brought about
those language features, and C++11 simultaneously added those features to
the standard library components that could use them. That's good.
Separating the language from the library will make it difficult for that to
happen. That's bad.
> When the standards committee gets involved - it hobbles progress.
> Ranges, Networking. Very complex components. They been available for
> years, while the standards committee versions won't be available for
> years to com.
>
You can use that argument for pretty much any big feature, language or
library. I mean, before C++11 came out, GCC has a nearly-complete
implementation of the large Concepts proposal. But the committee decided
not to move forward with it, so progress was hobbled for a good 7 years or
so.
The same goes for many other things C++ features. If we just let compilers
independently create their own separate language features, then C++ would
advance much more quickly.
And it would advance in incompatible ways. Standardization of the language
creates standardization of implementations. The same is true of the
standard library.
Now, you might say that that's not a valid comparison. After all, you can
just download and use a library, while switching compilers is hard. And you
can't use one compiler for some code and another for others, while you can
download two libraries that don't know about each other.
But that's only true if the library doesn't depend on the platform. When it
does (as many useful libraries do), well, now you're at the mercy of the
maker of the library to ensure that it works on your platforms of interest.
A problem with dropping things from the standard is that it creates a lack
of interoperability. Take the entire STL iterator mechanism. I can write
new algorithms that work within the iterator model, and someone else can
write new containers that provide iterators within that model. Because
we're both coding against the same standard model, their containers can
work with my algorithms. That's good.
Take `optional<T>`. Because it's available to everyone, it becomes a lingua
franca type that everyone can use. You can stick it in an interface and not
feel like you're making someone else use something they'd rather not use.
Something similar can be said for `string_view`. That's good too.
Having standard solutions to certain library problems is useful and
important. And that cannot be achieved by using arbitrary external
libraries.
Take the STL iterator model. It is baked into the language, thanks to
range-based `for`. You couldn't do that with a library external model. And
you might have multiple competing iterator models. Some might look like STL
iterators, some might look like Java's "iterator", etc. And they'd be
incompatible.
And while one model might be better in some situations than another, the
fact is picking *some answer* is better than "let the community sort it
out". Because the C++ community has proven that they are really terrible at
that.
> That's not improving things for anyone.
>
> > What good would move support in C++11 have been if no standard library
> > components used it?
>
> > What good would "uniform initialization" have been
> > without containers using it?
>
> > What good are forwarding references and
> > variadic templates without `emplace` and the like? And so on.
>
> If move support exists, only a short time will pass before library
> writers take advantage of it. same for the other features.
>
Maybe. Maybe not.
Tell me: how long did it take `boost::shared_ptr` to get move support? What
about `boost::optional`? Or `boost::any`? And those are the ones I know off
the top of my head. Even now in 2017, is move support ubiquitous throughout
Boost? Even in the libraries that aren't well maintained?
Boost has `boost::string_view`. Are there alternate versions of APIs that
take `boost::string_view` that take C++17 `std::string_view` too? When will
those appear?
And what about when a language feature strongly encourages a library
redesign? Consider `boost::variant`. Move support is a game changer for
`variant` assignment, as it reduces the circumstances when a `variant`
might need to allocate memory to avoid thrown exceptions. At that point,
the decision to allow memory allocation *at all* starts becoming
questionable.
So no, it takes more than "a short time" for such changes to appear.
>
> > As for "standards for library development", this idea suggests that the
> > ISO C++ committee has more power than it actually does. It can no more
> > enforce "standards for library development" than it can make Microsoft
> > respect that `class` and `struct` are not supposed to be syntactically
> > different. And without any genuine enforcement, such a "standard" is
> > worthless.
>
> Of course I'm aware of this. ButI've never meant to suggest that this
> be "enforced". This is why I included other mechanisms to achieve
> improvements of higher standards.
>
> > People use libraries because they're useful, not because they follow
> > some "standard for development".
>
> This is my point exactly. Useful libraries have no need to part of some
> C++ standard library. Today we have many libraries that are widely
> used and are not part of the standard. Eigen, Boost, multiple
> serialization libraries, ASIO networking, CGal and many, many, many
> more. Being part of the standard wouldn't make these libraries better
> and not being part of the standard has not hindered their success.
>
Being part of the standard would make them *part of the standard* and thus
reliable for all C++ users. That matters in part because of the difficulty
of just using someone else's library, but also because of interoperability.
Let's say there is some library A. And it has a signal callback mechanism,
which takes functions that take an `A::any` type as parameters. Now, let's
say that there is some library B, which has functions you'd like to use
with A's signaling mechanism. The problem is that B's API takes `B::any`,
which is a distinct type.
And since we're talking about an "any" type, you can't create some kind of
one-size-fits-all glue between the two. Your glue code has to know what
type the signaled function expects, so that it can cross the two.
This is a problem only because A and B implemented two types that do the
same thing. If they'd just used `std::any`, this wouldn't be a problem. But
if you had your way, there would be no `std::any`, so you'd have two
Balkanized libraries that only work with themselves and code written
specifically against them.
The thing is, we both agree that there are domains the committee should not
be exploring. It's simply a matter of where that line gets drawn. To you,
that line should be "OS features" and that's it. To me, my concern is
primarily about having platform neutrality and general code inter-operation.
--
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/a78b9ce4-bc39-4ae5-bac5-76b789ca95a2%40isocpp.org.
------=_Part_19822_1804732719.1527973645462
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, June 2, 2018 at 3:59:41 PM UTC-4, Robert Rame=
y wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 6/2/18 11:35 AM, Ni=
col Bolas wrote:
<br>
<br>> But this isn't going to improve things either.
<br>
<br>speculative
<br></blockquote><div><br></div><div>No moreso than yours. I back my specul=
ation up with a detailed explanation of why it won't help.<br></div><di=
v><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>>=20
<br>> Dissociating the standard library from the language doesn't im=
prove the=20
<br>> quality of the standard library.
<br>
<br>speculative.
<br>
<br>> In such a system, the library lag=20
<br>> behind language features even more so than it currently does.=20
<br>
<br>I don't believe this. =C2=A0Many if not most of the standard librar=
y=20
<br>components appeared other places first. =C2=A0Most of boost, type trait=
s,=20
<br>STL, etc. =C2=A0Very little of the standard library was created by the=
=20
<br>standards committee.<br></blockquote><div><br></div><div>What does that=
have to do with anything I was talking about?</div><div><br></div><div>STL=
's `vector` type didn't have move support because move support <i>d=
idn't exist</i> when STL was created. It didn't have `emplace` beca=
use forwarding references and variadic templates <i>didn't exist</i> ba=
ck then. And so forth.</div><div><br></div><div>That is the kind of lagging=
behind I'm talking about. C++11 brought about those language features,=
and C++11 simultaneously added those features to the standard library comp=
onents that could use them. That's good.</div><div><br></div><div>Separ=
ating the language from the library will make it difficult for that to happ=
en. That's bad.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">
When the standards committee gets involved - it hobbles progress.=20
<br>Ranges, Networking. =C2=A0Very complex components. They been available =
for=20
<br>years, while the standards committee versions won't be available fo=
r=20
<br>years to com.<br></blockquote><div><br></div><div>You can use that argu=
ment for pretty much any big feature, language or library. I mean, before C=
++11 came out, GCC has a nearly-complete implementation of the large Concep=
ts proposal. But the committee decided not to move forward with it, so prog=
ress was hobbled for a good 7 years or so.<br></div><div><br></div><div>The=
same goes for many other things C++ features. If we just let compilers ind=
ependently create their own separate language features, then C++ would adva=
nce much more quickly.</div><div><br></div><div>And it would advance in inc=
ompatible ways. Standardization of the language creates standardization of =
implementations. The same is true of the standard library.</div><div><br></=
div><div>Now, you might say that that's not a valid comparison. After a=
ll, you can just download and use a library, while switching compilers is h=
ard. And you can't use one compiler for some code and another for other=
s, while you can download two libraries that don't know about each othe=
r.</div><div><br></div><div>But that's only true if the library doesn&#=
39;t depend on the platform. When it does (as many useful libraries do), we=
ll, now you're at the mercy of the maker of the library to ensure that =
it works on your platforms of interest.<br></div><div><br></div><div>A prob=
lem with dropping things from the standard is that it creates a lack of int=
eroperability. Take the entire STL iterator mechanism. I can write new algo=
rithms that work within the iterator model, and someone else can write new =
containers that provide iterators within that model. Because we're both=
coding against the same standard model, their containers can work with my =
algorithms. That's good.</div><div><br></div><div>Take `optional<T&g=
t;`. Because it's available to everyone, it becomes a lingua franca typ=
e that everyone can use. You can stick it in an interface and not feel like=
you're making someone else use something they'd rather not use. So=
mething similar can be said for `string_view`. That's good too.</div><d=
iv><br></div><div>Having standard solutions to certain library problems is =
useful and important. And that cannot be achieved by using arbitrary extern=
al libraries.</div><div><br></div><div>Take the STL iterator model. It is b=
aked into the language, thanks to range-based `for`. You couldn't do th=
at with a library external model. And you might have multiple competing ite=
rator models. Some might look like STL iterators, some might look like Java=
's "iterator", etc. And they'd be incompatible.</div><div=
><br></div><div>And while one model might be better in some situations than=
another, the fact is picking <i>some answer</i> is better than "let t=
he community sort it out". Because the C++ community has proven that t=
hey are really terrible at that.<br></div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">
> That's not improving things for anyone.
<br>
<br>> What good would move support in C++11 have been if no standard lib=
rary=20
<br>> components used it?
<br>
<br>> What good would "uniform initialization" have been=20
<br>> without containers using it?=20
<br>
<br>> What good are forwarding references and=20
<br>> variadic templates without `emplace` and the like? And so on.
<br>
<br>If move support exists, only a short time will pass before library=20
<br>writers take advantage of it. same for the other features.<br></blockqu=
ote><div><br></div><div>Maybe. Maybe not.</div><div><br></div><div>Tell me:=
how long did it take `boost::shared_ptr` to get move support? What about `=
boost::optional`? Or `boost::any`? And those are the ones I know off the to=
p of my head. Even now in 2017, is move support ubiquitous throughout Boost=
? Even in the libraries that aren't well maintained?</div><div><br></di=
v><div>Boost has `boost::string_view`. Are there alternate versions of APIs=
that take `boost::string_view` that take C++17 `std::string_view` too? Whe=
n will those appear?<br></div><div><br></div><div>And what about when a lan=
guage feature strongly encourages a library redesign? Consider `boost::vari=
ant`. Move support is a game changer for `variant` assignment, as it reduce=
s the circumstances when a `variant` might need to allocate memory to avoid=
thrown exceptions. At that point, the decision to allow memory allocation =
<i>at all</i> starts becoming questionable.</div><div><br></div><div>So no,=
it takes more than "a short time" for such changes to appear.<br=
></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>> As for "standards for library development", this idea su=
ggests that the=20
<br>> ISO C++ committee has more power than it actually does. It can no =
more=20
<br>> enforce "standards for library development" than it can =
make Microsoft=20
<br>> respect that `class` and `struct` are not supposed to be syntactic=
ally=20
<br>> different. And without any genuine enforcement, such a "stand=
ard" is=20
<br>> worthless.
<br>
<br>Of course I'm aware of this. =C2=A0ButI've never meant to sugge=
st that this=20
<br>be "enforced". =C2=A0This is why I included other mechanisms =
to achieve=20
<br>improvements of higher standards.
<br>
<br>> People use libraries because they're useful, not because they =
follow=20
<br>> some "standard for development".
<br>
<br>This is my point exactly. =C2=A0Useful libraries have no need to part o=
f some=20
<br>C++ standard library. =C2=A0 Today we have many libraries that are wide=
ly=20
<br>used and are not part of the standard. =C2=A0Eigen, Boost, multiple=20
<br>serialization libraries, ASIO networking, CGal and many, many, many=20
<br>more. =C2=A0Being part of the standard wouldn't make these librarie=
s better=20
<br>and not being part of the standard has not hindered their success.<br><=
/blockquote><div><br></div><div>Being part of the standard would make them =
<i>part of the standard</i> and thus reliable for all C++ users. That matte=
rs in part because of the difficulty of just using someone else's libra=
ry, but also because of interoperability.</div><div><br></div><div>Let'=
s say there is some library A. And it has a signal callback mechanism, whic=
h takes functions that take an `A::any` type as parameters. Now, let's =
say that there is some library B, which has functions you'd like to use=
with A's signaling mechanism. The problem is that B's API takes `B=
::any`, which is a distinct type.</div><div><br></div><div>And since we'=
;re talking about an "any" type, you can't create some kind o=
f one-size-fits-all glue between the two. Your glue code has to know what t=
ype the signaled function expects, so that it can cross the two.</div><div>=
<br></div><div>This is a problem only because A and B implemented two types=
that do the same thing. If they'd just used `std::any`, this wouldn=
9;t be a problem. But if you had your way, there would be no `std::any`, so=
you'd have two Balkanized libraries that only work with themselves and=
code written specifically against them.</div><div><br></div><div>The thing=
is, we both agree that there are domains the committee should not be explo=
ring. It's simply a matter of where that line gets drawn. To you, that =
line should be "OS features" and that's it. To me, my concern=
is primarily about having platform neutrality and general code inter-opera=
tion.</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a78b9ce4-bc39-4ae5-bac5-76b789ca95a2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a78b9ce4-bc39-4ae5-bac5-76b789ca95a2=
%40isocpp.org</a>.<br />
------=_Part_19822_1804732719.1527973645462--
------=_Part_19821_1699878773.1527973645461--
.
Author: Robert Ramey <ramey@rrsd.com>
Date: Sat, 2 Jun 2018 15:45:01 -0700
Raw View
On 6/2/18 1:33 PM, mihailnajdenov@gmail.com wrote:
> Lastly, for C++ 20 and 23, what are the projects You think should be
> dropped for good?
This paper lists most/all of the topics to be considered at the next
standards meeting. There are 43.
All those not marked with * I would consider as library proposals
outside my view of the proper scope for the committee.
Of the remaining 3, I would consider 2 within the scope of the committee.
Of course opinions can and will differ.
Robert Ramey
--
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/pev6ha%24ugl%241%40blaine.gmane.org.
.
Author: Robert Ramey <ramey@rrsd.com>
Date: Sat, 2 Jun 2018 16:46:10 -0700
Raw View
On 6/2/18 2:07 PM, Nicol Bolas wrote:
> > In such a system, the library lag
> > behind language features even more so than it currently does.
>=20
> I don't believe this. =C2=A0Many if not most of the standard library
> components appeared other places first. =C2=A0Most of boost, type tra=
its,
> STL, etc. =C2=A0Very little of the standard library was created by th=
e
> standards committee.
>=20
>=20
> What does that have to do with anything I was talking about?
You suggested that library lags behind language features. I don't this=20
is very true. In fact, I'm of the believe that library components come=20
first and motivate enhancements to the language itself. For example,=20
functions objects where found to be very useful but syntactically=20
cumbersome. This motivated addition of lambdas to the language.
> STL's `vector` type didn't have move support because move support=20
> /didn't exist/ when STL was created. It didn't have `emplace` because=20
> forwarding references and variadic templates /didn't exist/ back then.=20
> And so forth.
Right. It was only apparent that these facilities were useful when=20
these libraries were fairly widely used. The language standard follows=20
code and practice. For the committee to be spending too much time trying=20
to speculatively anticipate the future is not an effective usage of=20
resources.
> That is the kind of lagging behind I'm talking about. C++11 brought=20
> about those language features, and C++11 simultaneously added those=20
> features to the standard library components that could use them. That's=
=20
> good.
Those features are/were added to all libraries and user code - not just=20
those designed by the committee.
> Separating the language from the library will make it difficult for that=
=20
> to happen. That's bad.
No it won't
>=20
> When the standards committee gets involved - it hobbles progress.
> Ranges, Networking. =C2=A0Very complex components. They been availabl=
e for
> years, while the standards committee versions won't be available for
> years to com.
>=20
>=20
> You can use that argument for pretty much any big feature, language or=20
> library.=20
LOL - of course I can, and I do - because it's a good argument.
> I mean, before C++11 came out, GCC has a nearly-complete=20
> implementation of the large Concepts proposal. But the committee decided=
=20
> not to move forward with it, so progress was hobbled for a good 7 years=
=20
> or so.
Great example.
As you point out, the idea of concepts is an example where design by=20
committee has worked out well.
Most if not all the benefits of the future concepts implementation can=20
and have been implemented as libraries. The Boost Concept Library=20
(2004) was somewhat crude but effective. The Tick library ( proposed to=20
boost but not accepted) includes a quite complete and effective=20
implementation based on C++11. But neither of these libraries are widely=20
used in spite of a large amount of evangelism at conferences. Of the=20
very few libraries which actually have documentation, only a few=20
actually use concepts in their designs - much less enforce them in their=20
code. In spite of all this, the C++ community has spent huge amounts of=20
effort promoting and designing this feature as part of the language.
Much better would have be to just let libraries implementing concepts=20
develop. If they become successful and it becomes apparent that a=20
change in the language would make them better, the the language can be=20
enhanced to better support them. This is similar to your example for=20
vector where vector was invented, found wide usage, and motivate some=20
enhancements in the language (move).
> The same goes for many other things C++ features. If we just let=20
> compilers independently create their own separate language features,=20
> then C++ would advance much more quickly.
I have not proposed this.
but compiler vendors have proposed their own incompatible=20
features/extensions. The committee cannot and does not prohibit this.
> And it would advance in incompatible ways. Standardization of the=20
> language creates standardization of implementations. The same is true of=
=20
> the standard library.
under my proposal the standard library would be smaller. But all=20
implementations would be compatible.
> But that's only true if the library doesn't depend on the platform.=20
I've proposed limiting library standardization to those things which are=20
platform dependent such as i/o (fopen, etc.) to facility the writing of=20
portable code.
> A problem with dropping things from the standard is that it creates a=20
> lack of interoperability. Take the entire STL iterator mechanism. I can=
=20
> write new algorithms that work within the iterator model, and someone=20
> else can write new containers that provide iterators within that model.=
=20
> Because we're both coding against the same standard model, their=20
> containers can work with my algorithms. That's good.
Right. In my world standard components would still exist. Someone=20
would make them and they would become "effectively" standard in that=20
many people come to depend upon them. ASIO, Eigan are good examples. So=20
"standard components" will always exist. But this doesn't mean that the=20
ISO C++ standards committee has to be responsible for designing all of=20
them. I argue that it doesn't have to spend time on this, that it's not=20
a good use of their time, and it doesn't result in the most effective=20
designs.
>=20
> Take `optional<T>`. Because it's available to everyone, it becomes a=20
> lingua franca type that everyone can use. You can stick it in an=20
> interface and not feel like you're making someone else use something=20
> they'd rather not use. Something similar can be said for `string_view`.=
=20
> That's good too.
Boost::Optional has existed for many years and has wide use. Spending=20
c++ committee resources to (re)design it added nothing to C++.
> Having standard solutions to certain library problems is useful and=20
> important.=20
I don't think it's necessary
And that cannot be achieved by using arbitrary external libraries.
The trickiest functions: networking, linear algebra, gui, serialization,=20
are all currently handled by non-iso libraries. I don't see the value=20
of the C++ committee trying to contribute to that.
> Take the STL iterator model. It is baked into the language,=20
it's baked into the STL library
> thanks to range-based `for`.=20
Hmmm I'm not seeing that. But maybe you're right. Before I had=20
range-based 'for', I used BOOST_FOREACH for the same effect. I'm not=20
totally convinced that it had to "baked into the language". If so, it=20
raises questions about the design of the feature.
> You couldn't do that with a library external model.=20
> And you might have multiple competing iterator models. Some might look=20
> like STL iterators, some might look like Java's "iterator", etc. And=20
> they'd be incompatible.
Could be. But I doubt it. The most successful libraries become dominant=20
and tend to drive out alternatives... Until some compelling better=20
alternative comes along. This is a general principle which shows in=20
evolution, capitalism, art, politics and other fields which are not=20
overly centralized.
> And while one model might be better in some situations than another, the=
=20
> fact is picking /some answer/ is better than "let the community sort it=
=20
> out". Because the C++ community has proven that they are really terrible=
=20
> at that.
Hmmm - Did you write that or did I. I don't remember.
> If move support exists, only a short time will pass before library
> writers take advantage of it. same for the other features.
>=20
> Maybe. Maybe not.
>=20
> Tell me: how long did it take `boost::shared_ptr` to get move support?=20
> What about `boost::optional`? Or `boost::any`? And those are the ones I=
=20
> know off the top of my head. Even now in 2017, is move support=20
> ubiquitous throughout Boost? Even in the libraries that aren't well=20
> maintained?
To be honest I don't know. I certainly haven't heard anyone complain.
But the real answer is that if there exist superior components to the=20
boost ones, the boost ones will be driven out when that becomes apparent.
>=20
> And what about when a language feature strongly encourages a library=20
> redesign? Consider `boost::variant`. Move support is a game changer for=
=20
> `variant` assignment, as it reduces the circumstances when a `variant`=20
> might need to allocate memory to avoid thrown exceptions. At that point,=
=20
> the decision to allow memory allocation /at all/ starts becoming=20
> questionable.
another interesting example. I know there has been a lot of dispute=20
about the various ways variant can / should be implemented. This is=20
chiefly due to the implementation of the assign operation in the=20
presence of multi-threading, exceptions, etc. I'm guessing that=20
different situations will call for different implementations and type=20
requirements. So trying to standardize this so that everyone or most=20
people are satisfied is not great idea. (FWIW - I suggested just=20
deleting the assignment as it works well for my use cases - Response was=20
underwhelming)
>=20
> So no, it takes more than "a short time" for such changes to appear.
>=20
>=20
> > As for "standards for library development", this idea suggests
> that the
> > ISO C++ committee has more power than it actually does. It can no
> more
> > enforce "standards for library development" than it can make
> Microsoft
> > respect that `class` and `struct` are not supposed to be
> syntactically
> > different. And without any genuine enforcement, such a "standard" =
is
> > worthless.
>=20
> Of course I'm aware of this. =C2=A0ButI've never meant to suggest tha=
t this
> be "enforced". =C2=A0This is why I included other mechanisms to achie=
ve
> improvements of higher standards.
>=20
> > People use libraries because they're useful, not because they foll=
ow
> > some "standard for development".
>=20
> This is my point exactly. =C2=A0Useful libraries have no need to part=
of
> some
> C++ standard library. =C2=A0 Today we have many libraries that are wi=
dely
> used and are not part of the standard. =C2=A0Eigen, Boost, multiple
> serialization libraries, ASIO networking, CGal and many, many, many
> more. =C2=A0Being part of the standard wouldn't make these libraries =
better
> and not being part of the standard has not hindered their success.
>=20
>=20
> Being part of the standard would make them /part of the standard/ and=20
> thus reliable for all C++ users.=20
"standardization" and reliability are separate issues.
> That matters in part because of the=20
> difficulty of just using someone else's library,=20
"standard libraries" are not guarenteed to be easy to use. and many are not=
..
but also because of
> interoperability.
I'm not sure what interoperability means in this context. I doubt it's=20
relevent anyway.
> This is a problem only because A and B implemented two types that do the=
=20
> same thing. If they'd just used `std::any`, this wouldn't be a problem.=
=20
> But if you had your way, there would be no `std::any`, so you'd have two=
=20
> Balkanized libraries that only work with themselves and code written=20
> specifically against them.
Right. This is the essence of the argument for the current system. I=20
don't dispute that the argument has merit. But I don't think that this=20
is the only consideration. The current system also has a lot of=20
problems which are widely noted. Something is going to have to change.=20
My view is that the only thing that will make a difference will be to=20
narrow the scope of what the committee has to deal with. I think a lot=20
of people would agree with this. At least until it has to be decide=20
what should be eliminated from that scope.
> The thing is, we both agree that there are domains the committee should=
=20
> not be exploring. It's simply a matter of where that line gets drawn. To=
=20
> you, that line should be "OS features" and that's it. To me, my concern=
=20
> is primarily about having platform neutrality and general code=20
> inter-operation.
Hmmm ... I don't see much difference between what I mean when I say OS=20
features and you say "platform neutrality".
Robert Ramey
--=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/peva40%242lh%241%40blaine.gmane.org.
.
Author: olafvdspek@gmail.com
Date: Mon, 4 Jun 2018 02:46:11 -0700 (PDT)
Raw View
------=_Part_6825_883002522.1528105571650
Content-Type: multipart/alternative;
boundary="----=_Part_6826_169303886.1528105571650"
------=_Part_6826_169303886.1528105571650
Content-Type: text/plain; charset="UTF-8"
Op zondag 3 juni 2018 01:46:22 UTC+2 schreef Robert Ramey:
>
> > But that's only true if the library doesn't depend on the platform.
>
> I've proposed limiting library standardization to those things which are
> platform dependent such as i/o (fopen, etc.) to facility the writing of
> portable code.
>
> Right. In my world standard components would still exist. Someone
> would make them and they would become "effectively" standard in that
> many people come to depend upon them. ASIO, Eigan are good examples. So
> "standard components" will always exist. But this doesn't mean that the
> ISO C++ standards committee has to be responsible for designing all of
> them. I argue that it doesn't have to spend time on this, that it's not
> a good use of their time, and it doesn't result in the most effective
> designs.
>
Why should file IO be part of std but network IO should not be?
--
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/409ad7b3-d0ed-47c6-a378-4d4d2490a9b6%40isocpp.org.
------=_Part_6826_169303886.1528105571650
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Op zondag 3 juni 2018 01:46:22 UTC+2 schreef Rober=
t Ramey:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> But that's on=
ly true if the library doesn't depend on the platform.=20
<br>
<br>I've proposed limiting library standardization to those things whic=
h are=20
<br>platform dependent such as i/o (fopen, etc.) to facility the writing of=
=20
<br>portable code.
<br>
<br>Right. =C2=A0In my world standard components would still exist. =C2=A0S=
omeone=20
<br>would make them and they would become "effectively" standard =
in that=20
<br>many people come to depend upon them. =C2=A0ASIO, Eigan are good exampl=
es. So=20
<br>"standard components" will always exist. =C2=A0But this doesn=
't mean that the=20
<br>ISO C++ standards committee has to be responsible for designing all of=
=20
<br>them. =C2=A0I argue that it doesn't have to spend time on this, tha=
t it's not=20
<br>a good use of their time, and it doesn't result in the most effecti=
ve=20
<br>designs.
<br></blockquote><div><br></div><div>Why should file IO be part of std but =
network IO should not be?</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" 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/409ad7b3-d0ed-47c6-a378-4d4d2490a9b6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/409ad7b3-d0ed-47c6-a378-4d4d2490a9b6=
%40isocpp.org</a>.<br />
------=_Part_6826_169303886.1528105571650--
------=_Part_6825_883002522.1528105571650--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Mon, 4 Jun 2018 11:58:47 +0200
Raw View
--Apple-Mail=_4E979C1F-0300-4545-956F-6F12518FD48E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
> On 4 Jun 2018, at 11:46, olafvdspek@gmail.com wrote:
>=20
>=20
>=20
> Op zondag 3 juni 2018 01:46:22 UTC+2 schreef Robert Ramey:
> > But that's only true if the library doesn't depend on the platform.=20
>=20
> I've proposed limiting library standardization to those things which are=
=20
> platform dependent such as i/o (fopen, etc.) to facility the writing of=
=20
> portable code.=20
>=20
> Right. In my world standard components would still exist. Someone=20
> would make them and they would become "effectively" standard in that=20
> many people come to depend upon them. ASIO, Eigan are good examples. So=
=20
> "standard components" will always exist. But this doesn't mean that the=
=20
> ISO C++ standards committee has to be responsible for designing all of=20
> them. I argue that it doesn't have to spend time on this, that it's not=
=20
> a good use of their time, and it doesn't result in the most effective=20
> designs.=20
>=20
> Why should file IO be part of std but network IO should not be?
And if we have standard file and network, why not standard visual display, =
standard human interaction, standard audio? We could argue that not every c=
omputer has audio. But we can also argue that not every computer system has=
file io.
A long time ago, I used to write video gambling machines on a variety of pr=
oprietary hardware. In my world, everything had video, sound, buttons, seri=
al comms and nothing had files or consoles.
It didn=E2=80=99t stop me using a subset of standard C.
If I were to do similar work again, I don=E2=80=99t see why I should not be=
able to write portable code for the games and just provide compatibility l=
ayers in the c++ library when porting to different hardware.
Standards make everything easier.=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=
email to std-proposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubs=
cribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org <mailto:std=
-proposals@isocpp.org>.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/409ad7b3-d0ed-47c6-a378-4d4d2490a9b6%40isocpp.=
org <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/409ad7b3-=
d0ed-47c6-a378-4d4d2490a9b6%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>.
--=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/09748AC4-8CC1-4045-B4A5-45A9973A4774%40gmail.com=
..
--Apple-Mail=_4E979C1F-0300-4545-956F-6F12518FD48E
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 4 Jun 2018, at 11=
:46, <a href=3D"mailto:olafvdspek@gmail.com" class=3D"">olafvdspek@gmail.co=
m</a> wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><=
div dir=3D"ltr" class=3D""><br class=3D""><br class=3D"">Op zondag 3 juni 2=
018 01:46:22 UTC+2 schreef Robert Ramey:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;">> But that's only true if the library doesn't depend on the pl=
atform.=20
<br class=3D"">
<br class=3D"">I've proposed limiting library standardization to those thin=
gs which are=20
<br class=3D"">platform dependent such as i/o (fopen, etc.) to facility the=
writing of=20
<br class=3D"">portable code.
<br class=3D"">
<br class=3D"">Right. In my world standard components would still exi=
st. Someone=20
<br class=3D"">would make them and they would become "effectively" standard=
in that=20
<br class=3D"">many people come to depend upon them. ASIO, Eigan are =
good examples. So=20
<br class=3D"">"standard components" will always exist. But this does=
n't mean that the=20
<br class=3D"">ISO C++ standards committee has to be responsible for design=
ing all of=20
<br class=3D"">them. I argue that it doesn't have to spend time on th=
is, that it's not=20
<br class=3D"">a good use of their time, and it doesn't result in the most =
effective=20
<br class=3D"">designs.
<br class=3D""></blockquote><div class=3D""><br class=3D""></div><div class=
=3D"">Why should file IO be part of std but network IO should not be?</div>=
</div></div></blockquote><div><br class=3D""></div><div>And if we have stan=
dard file and network, why not standard visual display, standard human inte=
raction, standard audio? We could argue that not every computer has audio. =
But we can also argue that not every computer system has file io.</div><div=
><br class=3D""></div><div>A long time ago, I used to write video gambling =
machines on a variety of proprietary hardware. In my world, everything had =
video, sound, buttons, serial comms and nothing had files or consoles.</div=
><div><br class=3D""></div><div>It didn=E2=80=99t stop me using a subset of=
standard C.</div><div><br class=3D""></div><div>If I were to do similar wo=
rk again, I don=E2=80=99t see why I should not be able to write portable co=
de for the games and just provide compatibility layers in the c++ library w=
hen porting to different hardware.</div><div><br class=3D""></div><div>Stan=
dards make everything easier. </div><div><br class=3D""></div><div><br=
class=3D""></div><div><br class=3D""></div><blockquote type=3D"cite" class=
=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D""><br class=
=3D""></div></div><div class=3D""><br class=3D"webkit-block-placeholder"></=
div>
-- <br class=3D"">
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br class=3D"">
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" class=3D"">=
std-proposals+unsubscribe@isocpp.org</a>.<br class=3D"">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"">std-proposals@isocpp.org</a>.<br class=3D"">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/409ad7b3-d0ed-47c6-a378-4d4d2490a9b6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" class=3D"">https:/=
/groups.google.com/a/isocpp.org/d/msgid/std-proposals/409ad7b3-d0ed-47c6-a3=
78-4d4d2490a9b6%40isocpp.org</a>.<br class=3D"">
</div></blockquote></div><br class=3D""></body></html>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/09748AC4-8CC1-4045-B4A5-45A9973A4774%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/09748AC4-8CC1-4045-B4A5-45A9973A4774%=
40gmail.com</a>.<br />
--Apple-Mail=_4E979C1F-0300-4545-956F-6F12518FD48E--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Mon, 4 Jun 2018 10:28:39 -0400
Raw View
--0000000000009caedf056dd1c02c
Content-Type: text/plain; charset="UTF-8"
On Mon, Jun 4, 2018 at 5:58 AM Richard Hodges <hodges.r@gmail.com> wrote:
> Why should file IO be part of std but network IO should not be?
>
> And if we have standard file and network, why not standard visual display,
> standard human interaction, standard audio?
>
Exactly. You have just demonstrated why files should not be part of the
Standard.
I'm joking here, but just a little bit. Part of the attraction of C++ was
the possibility
of replacing the printf format-string paradigm with overloaded type-safe
I/O, and
it was necessary to provide those facilities as part of making the language
attractive.
By the time standardization rolled around, it would have been unthinkable
to not
include I/O via operator<<. Files came along with that just as they did in
C.
But that should not translate into making every library part of the C++
Standard.
Remember that C practice always said that I/O was not part of the language,
but was implemented by libraries. Now we have spherical Bessel functions as
part of the language standard.
--
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/CAHSYqdZb0N_x3dx3p%2Bcp2jaRA1JG9rOA9v0sYfvQCvOQABgv%3Dg%40mail.gmail.com.
--0000000000009caedf056dd1c02c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Jun 4,=
2018 at 5:58 AM Richard Hodges <<a href=3D"mailto:hodges.r@gmail.com" t=
arget=3D"_blank">hodges.r@gmail.com</a>> wrote:</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div style=3D"word-wrap:break-word"><div><blockquote type=3D"=
cite"><div><div dir=3D"ltr"><div>Why should file IO be part of std but netw=
ork IO should not be?</div></div></div></blockquote><div>And if we have sta=
ndard file and network, why not standard visual display, standard human int=
eraction, standard audio?</div></div></div></blockquote><div><br>Exactly.=
=C2=A0 You have just demonstrated why files should not be part of the Stand=
ard.</div><div><br>I'm joking here, but just a little bit.=C2=A0 Part o=
f the attraction of C++ was the possibility<br>of replacing the <font face=
=3D"monospace, monospace">printf</font> format-string paradigm with overloa=
ded type-safe I/O, and<br>it was necessary to provide those facilities as p=
art of making the language attractive.<br>By the time standardization rolle=
d around, it would have been unthinkable to not<br>include I/O via <font fa=
ce=3D"monospace, monospace">operator<<</font>.=C2=A0 Files came along=
with that just as they did in C.<br><br>But that should not translate into=
making every library part of the C++ Standard.<br>Remember that C practice=
always said that I/O was not part of the language,<br>but was implemented =
by libraries.=C2=A0 Now we have spherical Bessel functions as<br>part of th=
e language standard.</div></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZb0N_x3dx3p%2Bcp2jaRA1JG9rOA9v=
0sYfvQCvOQABgv%3Dg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZb0N_x=
3dx3p%2Bcp2jaRA1JG9rOA9v0sYfvQCvOQABgv%3Dg%40mail.gmail.com</a>.<br />
--0000000000009caedf056dd1c02c--
.
Author: Robert Ramey <ramey@rrsd.com>
Date: Mon, 4 Jun 2018 07:47:09 -0700
Raw View
On 6/4/18 2:46 AM, olafvdspek@gmail.com wrote:
> Why should file IO be part of std but network IO should not be?
Certainly a good point.
We've had fopen, fread, etc... since the beginning of C which I think is
a good idea. It presents a unified facade over the file system. I can
easily imagine a posix style facade being part of the standard. (I
suspect that it defacto is) But I question the inclusion of much larger
application oriented components. In this case we would be talking about
file system (45 pages of standardese) and ASIO networking which really
presents an elaborate applications oriented interface. By the same
token I could imagine including some set of 29 drawing primitives while
stopping short a set of widgets, dialog boxes etc.
So it's not easy to decide where to draw the line. If we assign extreme
"right" to bare metal and extreme "left" to full blown applications, I
would say that of late, things have moved too far to the left.
I would like to see the standardization stop at the point where there
are enough primitive facilities so that fancier ones built on them can
be reliably compiled. So this would not mean NO libraries in the
standard. I think the original C libraries got it about right. Enough
to make you're application libraries and applications portable - but no
more than that.
Robert Ramey
--
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/pf3j99%242b6%241%40blaine.gmane.org.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 4 Jun 2018 08:59:14 -0700 (PDT)
Raw View
------=_Part_18564_441128094.1528127955032
Content-Type: multipart/alternative;
boundary="----=_Part_18565_40513494.1528127955033"
------=_Part_18565_40513494.1528127955033
Content-Type: text/plain; charset="UTF-8"
On Saturday, June 2, 2018 at 7:46:22 PM UTC-4, Robert Ramey wrote:
>
> On 6/2/18 2:07 PM, Nicol Bolas wrote:
> > > In such a system, the library lag
> > > behind language features even more so than it currently does.
> >
> > I don't believe this. Many if not most of the standard library
> > components appeared other places first. Most of boost, type traits,
> > STL, etc. Very little of the standard library was created by the
> > standards committee.
> >
> >
> > What does that have to do with anything I was talking about?
>
> You suggested that library lags behind language features. I don't this
> is very true.
The source of a library feature has nothing to do with whether it lags
behind improvements in the language. Again, when did `boost` types get
access to C++11 features, compared to when standard library types getting
access to them?
I bet the standard library got them first. And even then, there were
several C++11 features that didn't get spread into the library; UDLs being
the most obvious. It took until C++14 for those to show up.
Splitting the standard library off to be handled by "the community" would
only multiply such cases, not reduce them. Do you want to wait until 2023
before you can use `operator<=>` with `optional`?
> The same goes for many other things C++ features. If we just let
> > compilers independently create their own separate language features,
> > then C++ would advance much more quickly.
>
> I have not proposed this.
>
You've proposed it at the *library level*. My point is that your argument
is just as valid for the language level. Or rather, it would cause the same
problems to the library as it would to the language. So if you don't like
it in the language, you shouldn't like it in the library.
> > A problem with dropping things from the standard is that it creates a
> > lack of interoperability. Take the entire STL iterator mechanism. I can
> > write new algorithms that work within the iterator model, and someone
> > else can write new containers that provide iterators within that model.
> > Because we're both coding against the same standard model, their
> > containers can work with my algorithms. That's good.
>
> Right. In my world standard components would still exist. Someone
> would make them and they would become "effectively" standard in that
> many people come to depend upon them. ASIO, Eigan are good examples.
Since when did ASIO and Eigan become "'effectively' standard"? And to whom?
For some users, GLM is "standard" for vector math stuff, not Eigan. And I
bet there's a lot more C++ networking code out there that *doesn't* use
ASIO than which does.
Your view of things simply does not match how actual C++ users are
presently working. There are no "'effectively' standard" C++ libraries.
Anywhere. Not Boost, not Qt, none of them.
So
> "standard components" will always exist. But this doesn't mean that the
> ISO C++ standards committee has to be responsible for designing all of
> them. I argue that it doesn't have to spend time on this, that it's not
> a good use of their time, and it doesn't result in the most effective
> designs.
>
> >
> > Take `optional<T>`. Because it's available to everyone, it becomes a
> > lingua franca type that everyone can use. You can stick it in an
> > interface and not feel like you're making someone else use something
> > they'd rather not use. Something similar can be said for `string_view`.
> > That's good too.
>
> Boost::Optional has existed for many years and has wide use. Spending
> c++ committee resources to (re)design it added nothing to C++.
>
It only has "wide use" with programs that use Boost. That's not all, or
even most, C++ programs. Putting it in the standard gives it *real* "wide
use".
> > Having standard solutions to certain library problems is useful and
> > important.
>
> I don't think it's necessary
>
> And that cannot be achieved by using arbitrary external libraries.
>
> The trickiest functions: networking, linear algebra, gui, serialization,
> are all currently handled by non-iso libraries. I don't see the value
> of the C++ committee trying to contribute to that.
>
And (for the most part) I agree. It's when you start saying containers or
iterators shouldn't exist, that algorithms and `optional` shouldn't exist
that we run into conflict.
Culling out everything that doesn't directly talk to the OS culls out too
much genuinely useful stuff, things where there is a distinct advantage to
everyone using the same tool. An advantage you can't get without putting it
in the standard library.
> Take the STL iterator model. It is baked into the language,
>
> it's baked into the STL library
>
> > thanks to range-based `for`.
>
> Hmmm I'm not seeing that. But maybe you're right. Before I had
> range-based 'for', I used BOOST_FOREACH for the same effect. I'm not
> totally convinced that it had to "baked into the language". If so, it
> raises questions about the design of the feature.
>
Nobody said that it "had to" be anything. But the language is better off
with it begin a legitimate language construct rather than some macro hack.
And that language construct needed an iterator model to work. The library
already had a good, proven iterator model, so the language simply
incorporated it.
> You couldn't do that with a library external model.
> > And you might have multiple competing iterator models. Some might look
> > like STL iterators, some might look like Java's "iterator", etc. And
> > they'd be incompatible.
>
> Could be. But I doubt it. The most successful libraries become dominant
> and tend to drive out alternatives... Until some compelling better
> alternative comes along. This is a general principle which shows in
> evolution, capitalism, art, politics and other fields which are not
> overly centralized.
>
"Evolution, capitalism, art, politics and other fields which are not overly
centralized" all prove to us that you eventually wind up with *multiple
competing* standards, with no one standard winning out in the end. Windows,
MacOS, and dozens of flavors of Linux all exist, despite doing the same
basic thing. Qt and Gnome still exist, despite doing the same thing, with
no sign that either is going to "win" over the other. I can keep going, but
my point is clear: your model ends up with lots of competing, incompatible
things that all do the same basic thing, not a single standard.
This is why ISO standards *exist* at all. C++ is not well served by having
5 competing, incompatible iterator models, with their own cloisters of
users who swear up and down that theirs is the best. We only need one.
Think about how much code *hasn't* been written simply because C++98 said
"this is how iterators work". Think about all the people who grumble and
gripe about some aspect of the STL iterator model, but they still use it.
Why?
Because *it's standard*. If you want to use `std::sort`, you have to use
the STL iterator model.
Without it being standard, those people would have just rolled their own.
Because that's what C++ programmers do when they encounter such problems.
It doesn't matter if there's a big library out there that is 95% of what
they want. If any aspect of its design annoys them even slightly, they'll
roll their own in a heartbeat.
> And while one model might be better in some situations than another, the
> > fact is picking /some answer/ is better than "let the community sort it
> > out". Because the C++ community has proven that they are really terrible
> > at that.
>
> Hmmm - Did you write that or did I. I don't remember.
>
> > If move support exists, only a short time will pass before library
> > writers take advantage of it. same for the other features.
> >
> > Maybe. Maybe not.
> >
> > Tell me: how long did it take `boost::shared_ptr` to get move support?
> > What about `boost::optional`? Or `boost::any`? And those are the ones I
> > know off the top of my head. Even now in 2017, is move support
> > ubiquitous throughout Boost? Even in the libraries that aren't well
> > maintained?
>
> To be honest I don't know. I certainly haven't heard anyone complain.
> But the real answer is that if there exist superior components to the
> boost ones, the boost ones will be driven out when that becomes apparent.
>
OK, let's take your `boost::optional` example. Earlier, you claimed
"Boost::Optional has existed for many years and has wide use." Let's
pretend that we lived in a world where that was actually true.
So, let's imagine we're in a pre-move world, where `boost::optional` use
really has become ubiquitous. It's a basic vocabulary type, and lots of
code has been written against it. But then, the language changes; move
support is added to the language. But for whatever reason,
`boost::optional` doesn't get it for several years. In the meantime,
someone else comes along with their own `optional` type that provides move
support. But it has a different interface because making new interfaces is
what C++ programmers do for fun.
So... what happens to all of that "lots of code" that was written against
`boost::optional`? Is everyone going to switch to the new type with its new
interface? Odds are good they will not. Some will, many won't.
Thus leading to bifurcation of the community, all because someone didn't
update a basic vocabulary type to conform to the possibilities of the new
standard fast enough.
>
> > And what about when a language feature strongly encourages a library
> > redesign? Consider `boost::variant`. Move support is a game changer for
> > `variant` assignment, as it reduces the circumstances when a `variant`
> > might need to allocate memory to avoid thrown exceptions. At that point,
> > the decision to allow memory allocation /at all/ starts becoming
> > questionable.
>
> another interesting example. I know there has been a lot of dispute
> about the various ways variant can / should be implemented. This is
> chiefly due to the implementation of the assign operation in the
> presence of multi-threading, exceptions, etc. I'm guessing that
> different situations will call for different implementations and type
> requirements. So trying to standardize this so that everyone or most
> people are satisfied is not great idea. (FWIW - I suggested just
> deleting the assignment as it works well for my use cases - Response was
> underwhelming)
>
You're missing the forest for the trees here. My point is that new language
features can prompt people to completely redesign types with different
tradeoffs based on those features.
>
> > So no, it takes more than "a short time" for such changes to appear.
> >
> >
> > > As for "standards for library development", this idea suggests
> > that the
> > > ISO C++ committee has more power than it actually does. It can no
> > more
> > > enforce "standards for library development" than it can make
> > Microsoft
> > > respect that `class` and `struct` are not supposed to be
> > syntactically
> > > different. And without any genuine enforcement, such a "standard"
> is
> > > worthless.
> >
> > Of course I'm aware of this. ButI've never meant to suggest that
> this
> > be "enforced". This is why I included other mechanisms to achieve
> > improvements of higher standards.
> >
> > > People use libraries because they're useful, not because they
> follow
> > > some "standard for development".
> >
> > This is my point exactly. Useful libraries have no need to part of
> > some
> > C++ standard library. Today we have many libraries that are widely
> > used and are not part of the standard. Eigen, Boost, multiple
> > serialization libraries, ASIO networking, CGal and many, many, many
> > more. Being part of the standard wouldn't make these libraries
> better
> > and not being part of the standard has not hindered their success.
> >
> >
> > Being part of the standard would make them /part of the standard/ and
> > thus reliable for all C++ users.
>
> "standardization" and reliability are separate issues.
>
When I said "reliable", I meant that you can rely on having it available.
Things which are standard are reliable. You may be able to get reliability
without standardization, but in the C++ world, that only goes so far. The
standard library provides *maximum* reliability in C++; that's kind of the
point of the standard library.
If you want to reduce the scope of the standard library, you must *first*
make it possible for third-party libraries to be as accessible as standard
ones. Or close to it.
I'm saying that what you're doing is out of order. There's a river you want
to cross, and you want to destroy its bridge. You need to cross the river
*before* you destroy the bridge; doing it backwards doesn't end well.
> That matters in part because of the
> > difficulty of just using someone else's library,
>
> "standard libraries" are not guarenteed to be easy to use. and many are
> not.
>
Using a library requires installing it first. The standard library comes
with your compiler. Therefore, it is more difficult to use someone else's
library than the standard one.
but also because of
> > interoperability.
>
> I'm not sure what interoperability means in this context. I doubt it's
> relevent anyway.
>
If your API has a function that takes an `int`, I can use it because the
standard defines `int` as a type. Because of that, I'm likely to use `int`
rather than some other integer type provided by some other library.
Similarly, third-party APIs are likely to use `int` instead of rolling
their own. And because of that, I can take a third-party API that returns
`int`s and pass the result directly to your function. And vice-versa.
If your API has a function that takes `boost::optional`, I can't use it
unless I also use `boost::optional`. If there's a third-party API that
returns some other `optional`-like type, I can't pass that to your library
directly.
That's a failure of interoperability. I get interop with `int`, but not
with `boost::optional`. This is why standardizing vocabulary types is
important.
> This is a problem only because A and B implemented two types that do the
> > same thing. If they'd just used `std::any`, this wouldn't be a problem.
> > But if you had your way, there would be no `std::any`, so you'd have two
> > Balkanized libraries that only work with themselves and code written
> > specifically against them.
>
> Right. This is the essence of the argument for the current system. I
> don't dispute that the argument has merit. But I don't think that this
> is the only consideration. The current system also has a lot of
> problems which are widely noted. Something is going to have to change.
> My view is that the only thing that will make a difference will be to
> narrow the scope of what the committee has to deal with. I think a lot
> of people would agree with this. At least until it has to be decide
> what should be eliminated from that scope.
>
Here's the thing though. The committee is already divided between CWG/EWG
(which considers language features) and LWG/LEWG (which considers library
features). The two groups do communicate, where one has need of the other.
But they are separate.
Reducing the amount of stuff LWG deals with will in no way lower the amount
of stuff CWG deals with. So it's not going to get you language features any
faster. The graphics TS was not dismissed because it would slow down
progress on language features; it was dismissed because it would slow down
progress on *library* features.
> The thing is, we both agree that there are domains the committee should
> > not be exploring. It's simply a matter of where that line gets drawn. To
> > you, that line should be "OS features" and that's it. To me, my concern
> > is primarily about having platform neutrality and general code
> > inter-operation.
>
> Hmmm ... I don't see much difference between what I mean when I say OS
> features and you say "platform neutrality".
>
Read the part after the "and". Vocabulary types (optional, any, etc) and
common programming idioms (iterators, arrays, linked-lists, etc) are vital
aspects to any decent standard library.
I don't believe it is useful to draw some definitive, immutable line as to
where things ought to be between the standard library and 3rd parties. That
doesn't mean everything ought to be permissible. But a hard-and-fast rule
for standard libraries hurts more than it helps.
It's better to have general principles, which can be applied to specific
cases, but always with a view towards serving the genuine needs of C++
programmers.
--
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/d1d4fe21-d833-4d59-98b1-1c04a5646003%40isocpp.org.
------=_Part_18565_40513494.1528127955033
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, June 2, 2018 at 7:46:22 PM UTC-4, Robert Rame=
y wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 6/2/18 2:07 PM, Nic=
ol Bolas wrote:
<br>
> =C2=A0 =C2=A0 =C2=A0> In such a system, the library lag
<br>> =C2=A0 =C2=A0 =C2=A0> behind language features even more so tha=
n it currently does.
<br>>=20
<br>> =C2=A0 =C2=A0 I don't believe this. =C2=A0Many if not most of =
the standard library
<br>> =C2=A0 =C2=A0 components appeared other places first. =C2=A0Most o=
f boost, type traits,
<br>> =C2=A0 =C2=A0 STL, etc. =C2=A0Very little of the standard library =
was created by the
<br>> =C2=A0 =C2=A0 standards committee.
<br>>=20
<br>>=20
<br>> What does that have to do with anything I was talking about?
<br>
<br>You suggested that library lags behind language features. I don't t=
his=20
<br>is very true.</blockquote><div><br></div><div>The source of a library f=
eature has nothing to do with whether it lags behind improvements in the la=
nguage. Again, when did `boost` types get access to C++11 features, compare=
d to when standard library types getting access to them?</div><div><br></di=
v><div>I bet the standard library got them first. And even then, there were=
several C++11 features that didn't get spread into the library; UDLs b=
eing the most obvious. It took until C++14 for those to show up.</div><div>=
<br></div><div>Splitting the standard library off to be handled by "th=
e community"=20
would only multiply such cases, not reduce them. Do you want to wait=20
until 2023 before you can use `operator<=3D>` with `optional`?</div><=
div></div><div></div><br><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
> The same goes for many other things C++ features. If we just let=20
<br>> compilers independently create their own separate language feature=
s,=20
<br>> then C++ would advance much more quickly.
<br>
<br>I have not proposed this.<br></blockquote><div><br></div><div>You'v=
e proposed it at the <i>library level</i>. My point is that your argument i=
s just as valid for the language level. Or rather, it would cause the same =
problems to the library as it would to the language. So if you don't li=
ke it in the language, you shouldn't like it in the library.<br></div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
> A problem with dropping things from the standard is that it creates a=
=20
<br>> lack of interoperability. Take the entire STL iterator mechanism. =
I can=20
<br>> write new algorithms that work within the iterator model, and some=
one=20
<br>> else can write new containers that provide iterators within that m=
odel.=20
<br>> Because we're both coding against the same standard model, the=
ir=20
<br>> containers can work with my algorithms. That's good.
<br>
<br>Right. =C2=A0In my world standard components would still exist. =C2=A0S=
omeone=20
<br>would make them and they would become "effectively" standard =
in that=20
<br>many people come to depend upon them. =C2=A0ASIO, Eigan are good exampl=
es.</blockquote><div><br></div><div>Since when did ASIO and Eigan become &q=
uot;'effectively' standard"? And to whom? For some users, GLM =
is "standard" for vector math stuff, not Eigan. And I bet there&#=
39;s a lot more C++ networking code out there that <i>doesn't</i> use A=
SIO than which does.<br></div><div><br></div><div>Your view of things simpl=
y does not match how actual C++ users are presently working. There are no &=
quot;'effectively' standard" C++ libraries. Anywhere. Not Boos=
t, not Qt, none of them.</div><div><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;"> So=20
<br>"standard components" will always exist. =C2=A0But this doesn=
't mean that the=20
<br>ISO C++ standards committee has to be responsible for designing all of=
=20
<br>them. =C2=A0I argue that it doesn't have to spend time on this, tha=
t it's not=20
<br>a good use of their time, and it doesn't result in the most effecti=
ve=20
<br>designs.
<br>
<br>>=20
<br>> Take `optional<T>`. Because it's available to everyone, =
it becomes a=20
<br>> lingua franca type that everyone can use. You can stick it in an=
=20
<br>> interface and not feel like you're making someone else use som=
ething=20
<br>> they'd rather not use. Something similar can be said for `stri=
ng_view`.=20
<br>> That's good too.
<br>
<br>Boost::Optional has existed for many years and has wide use.=C2=A0 Spen=
ding=20
<br>c++ committee resources to (re)design it added nothing to C++.
<br></blockquote><div><br></div><div>It only has "wide use" with =
programs that use Boost. That's not all, or even most, C++ programs. Pu=
tting it in the standard gives it <i>real</i> "wide use".<br></di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
> Having standard solutions to certain library problems is useful and=20
<br>> important.=20
<br>
<br>I don't think it's necessary
<br>
<br>And that cannot be achieved by using arbitrary external libraries.
<br>
<br>The trickiest functions: networking, linear algebra, gui, serialization=
,=20
<br>are all currently handled by non-iso libraries. =C2=A0I don't see t=
he value=20
<br>of the C++ committee trying to contribute to that.<br></blockquote><div=
><br></div><div>And (for the most part) I agree. It's when you start sa=
ying containers or iterators shouldn't exist, that algorithms and `opti=
onal` shouldn't exist that we run into conflict.</div><div><br></div><d=
iv>Culling out everything that doesn't directly talk to the OS culls ou=
t too much genuinely useful stuff, things where there is a distinct advanta=
ge to everyone using the same tool. An advantage you can't get without =
putting it in the standard library.<br></div><div><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">
> Take the STL iterator model. It is baked into the language,=20
<br>
<br>it's baked into the STL library
<br>
<br>> thanks to range-based `for`.=20
<br>
<br>Hmmm I'm not seeing that.=C2=A0 But maybe you're right. =C2=A0B=
efore I had=20
<br>range-based 'for', I used BOOST_FOREACH for the same effect. =
=C2=A0I'm not=20
<br>totally convinced that it had to "baked into the language". =
=C2=A0If so, it=20
<br>raises questions about the design of the feature.<br></blockquote><div>=
<br></div><div>Nobody said that it "had to" be anything. But the =
language is better off with it begin a legitimate language construct rather=
than some macro hack. And that language construct needed an iterator model=
to work. The library already had a good, proven iterator model, so the lan=
guage simply incorporated it.</div><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;">
> You couldn't do that with a library external model.=20
<br>> And you might have multiple competing iterator models. Some might =
look=20
<br>> like STL iterators, some might look like Java's "iterator=
", etc. And=20
<br>> they'd be incompatible.
<br>
<br>Could be. =C2=A0But I doubt it. The most successful libraries become do=
minant=20
<br>and tend to drive out alternatives... Until some compelling better=20
<br>alternative comes along. =C2=A0This is a general principle which shows =
in=20
<br>evolution, capitalism, art, politics and other fields which are not=20
<br>overly centralized.<br></blockquote><div><br></div><div>"Evolution=
, capitalism, art, politics and other fields which are not=20
overly centralized" all prove to us that you eventually wind up with <=
i>multiple competing</i> standards, with no one standard winning out in the=
end. Windows, MacOS, and dozens of flavors of Linux all exist, despite doi=
ng the same basic thing. Qt and Gnome still exist, despite doing the same t=
hing, with no sign that either is going to "win" over the other. =
I can keep going, but my point is clear: your model ends up with lots of co=
mpeting, incompatible things that all do the same basic thing, not a single=
standard.<br></div><div><br></div><div></div><div>This is why ISO standard=
s <i>exist</i> at all. C++ is not well served by having 5 competing, incomp=
atible iterator models, with their own cloisters of users who swear up and =
down that theirs is the best. We only need one.</div><div><br></div><div>Th=
ink about how much code <i>hasn't</i> been written simply because C++98=
said "this is how iterators work". Think about all the people wh=
o grumble and gripe about some aspect of the STL iterator model, but they s=
till use it. Why?</div><div><br></div><div>Because <i>it's standard</i>=
.. If you want to use `std::sort`, you have to use the STL iterator model.</=
div><div><br></div><div>Without it being standard, those people would have =
just rolled their own. Because that's what C++ programmers do when they=
encounter such problems. It doesn't matter if there's a big librar=
y out there that is 95% of what they want. If any aspect of its design anno=
ys them even slightly, they'll roll their own in a heartbeat.<br></div>=
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
> And while one model might be better in some situations than another, t=
he=20
<br>> fact is picking /some answer/ is better than "let the communi=
ty sort it=20
<br>> out". Because the C++ community has proven that they are real=
ly terrible=20
<br>> at that.
<br>
<br>Hmmm - Did you write that or did I. =C2=A0I don't remember.
<br>
<br>> =C2=A0 =C2=A0 If move support exists, only a short time will pass =
before library
<br>> =C2=A0 =C2=A0 writers take advantage of it. same for the other fea=
tures.
<br>>=20
<br>> Maybe. Maybe not.
<br>>=20
<br>> Tell me: how long did it take `boost::shared_ptr` to get move supp=
ort?=20
<br>> What about `boost::optional`? Or `boost::any`? And those are the o=
nes I=20
<br>> know off the top of my head. Even now in 2017, is move support=20
<br>> ubiquitous throughout Boost? Even in the libraries that aren't=
well=20
<br>> maintained?
<br>
<br>To be honest I don't know. =C2=A0I certainly haven't heard anyo=
ne complain.
<br>But the real answer is that if there exist superior components to the=
=20
<br>boost ones, the boost ones will be driven out when that becomes apparen=
t.
<br></blockquote><div><br></div><div>OK, let's take your `boost::option=
al` example. Earlier, you claimed "Boost::Optional has existed for man=
y years and has wide use." Let's pretend that we lived in a world =
where that was actually true.</div><div><br></div><div>So, let's imagin=
e we're in a pre-move world, where `boost::optional` use really has bec=
ome ubiquitous. It's a basic vocabulary type, and lots of code has been=
written against it. But then, the language changes; move support is added =
to the language. But for whatever reason, `boost::optional` doesn't get=
it for several years. In the meantime, someone else comes along with their=
own `optional` type that provides move support. But it has a different int=
erface because making new interfaces is what C++ programmers do for fun.<br=
></div><div><br></div><div>So... what happens to all of that "lots of =
code" that was written against `boost::optional`? Is everyone going to=
switch to the new type with its new interface? Odds are good they will not=
.. Some will, many won't.</div><div><br></div><div>Thus leading to bifur=
cation of the community, all because someone didn't update a basic voca=
bulary type to conform to the possibilities of the new standard fast enough=
..<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">>=
=20
<br>> And what about when a language feature strongly encourages a libra=
ry=20
<br>> redesign? Consider `boost::variant`. Move support is a game change=
r for=20
<br>> `variant` assignment, as it reduces the circumstances when a `vari=
ant`=20
<br>> might need to allocate memory to avoid thrown exceptions. At that =
point,=20
<br>> the decision to allow memory allocation /at all/ starts becoming=
=20
<br>> questionable.
<br>
<br>another interesting example. =C2=A0I know there has been a lot of dispu=
te=20
<br>about the various ways variant can / should be implemented. =C2=A0This =
is=20
<br>chiefly due to the implementation of the assign operation in the=20
<br>presence of multi-threading, exceptions, etc. =C2=A0I'm guessing th=
at=20
<br>different situations will call for different implementations and type=
=20
<br>requirements. =C2=A0So trying to standardize this so that everyone or m=
ost=20
<br>people are satisfied is not great idea. =C2=A0(FWIW - I suggested just=
=20
<br>deleting the assignment as it works well for my use cases - Response wa=
s=20
<br>underwhelming)<br></blockquote><div><br></div><div>You're missing t=
he forest for the trees here. My point is that new language features can pr=
ompt people to completely redesign types with different tradeoffs based on =
those features.<br></div><div><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;">
>=20
<br>> So no, it takes more than "a short time" for such change=
s to appear.
<br>>=20
<br>>=20
<br>> =C2=A0 =C2=A0 =C2=A0> As for "standards for library develo=
pment", this idea suggests
<br>> =C2=A0 =C2=A0 that the
<br>> =C2=A0 =C2=A0 =C2=A0> ISO C++ committee has more power than it =
actually does. It can no
<br>> =C2=A0 =C2=A0 more
<br>> =C2=A0 =C2=A0 =C2=A0> enforce "standards for library devel=
opment" than it can make
<br>> =C2=A0 =C2=A0 Microsoft
<br>> =C2=A0 =C2=A0 =C2=A0> respect that `class` and `struct` are not=
supposed to be
<br>> =C2=A0 =C2=A0 syntactically
<br>> =C2=A0 =C2=A0 =C2=A0> different. And without any genuine enforc=
ement, such a "standard" is
<br>> =C2=A0 =C2=A0 =C2=A0> worthless.
<br>>=20
<br>> =C2=A0 =C2=A0 Of course I'm aware of this. =C2=A0ButI've n=
ever meant to suggest that this
<br>> =C2=A0 =C2=A0 be "enforced". =C2=A0This is why I include=
d other mechanisms to achieve
<br>> =C2=A0 =C2=A0 improvements of higher standards.
<br>>=20
<br>> =C2=A0 =C2=A0 =C2=A0> People use libraries because they're =
useful, not because they follow
<br>> =C2=A0 =C2=A0 =C2=A0> some "standard for development"=
..
<br>>=20
<br>> =C2=A0 =C2=A0 This is my point exactly. =C2=A0Useful libraries hav=
e no need to part of
<br>> =C2=A0 =C2=A0 some
<br>> =C2=A0 =C2=A0 C++ standard library. =C2=A0 Today we have many libr=
aries that are widely
<br>> =C2=A0 =C2=A0 used and are not part of the standard. =C2=A0Eigen, =
Boost, multiple
<br>> =C2=A0 =C2=A0 serialization libraries, ASIO networking, CGal and m=
any, many, many
<br>> =C2=A0 =C2=A0 more. =C2=A0Being part of the standard wouldn't =
make these libraries better
<br>> =C2=A0 =C2=A0 and not being part of the standard has not hindered =
their success.
<br>>=20
<br>>=20
<br>> Being part of the standard would make them /part of the standard/ =
and=20
<br>> thus reliable for all C++ users.=20
<br>
<br>"standardization" and reliability are separate issues.<br></b=
lockquote><div><br></div><div>When I said "reliable", I meant tha=
t you can rely on having it available.<br></div><div><br></div><div>Things =
which are standard are reliable. You may be able to get reliability without=
standardization, but in the C++ world, that only goes so far. The standard=
library provides <i>maximum</i> reliability in C++; that's kind of the=
point of the standard library.<br></div><div><br></div><div>If you want to=
reduce the scope of the standard library, you must <i>first</i> make it po=
ssible for third-party libraries to be as accessible as standard ones. Or c=
lose to it.</div><div><br></div><div>I'm saying that what you're do=
ing is out of order. There's a river you want to cross, and you want to=
destroy its bridge. You need to cross the river <i>before</i> you destroy =
the bridge; doing it backwards doesn't end well.<br></div><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">
> That matters in part because of the=20
<br>> difficulty of just using someone else's library,=20
<br>
<br>"standard libraries" are not guarenteed to be easy to use. an=
d many are not.<br></blockquote><div><br></div><div>Using a library require=
s installing it first. The standard library comes with your compiler. There=
fore, it is more difficult to use someone else's library than the stand=
ard one.<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;">
but also because of
<br>> interoperability.
<br>
<br>I'm not sure what interoperability means in this context. =C2=A0I d=
oubt it's=20
<br>relevent anyway.<br></blockquote><div><br></div><div>If your API has a =
function that takes an `int`, I can use it because the standard defines `in=
t` as a type. Because of that, I'm likely to use `int` rather than some=
other integer type provided by some other library. Similarly, third-party =
APIs are likely to use `int` instead of rolling their own. And because of t=
hat, I can take a third-party API that returns `int`s and pass the result d=
irectly to your function. And vice-versa.<br></div><div><br></div><div> If =
your API has a function that takes `boost::optional`, I can't use it un=
less I also use `boost::optional`. If there's a third-party API that re=
turns some other `optional`-like type, I can't pass that to your librar=
y directly.</div><div><br></div><div>That's a failure of interoperabili=
ty. I get interop with `int`, but not with `boost::optional`. This is why s=
tandardizing vocabulary types is important.<br></div><div><br></div><div></=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">
> This is a problem only because A and B implemented two types that do t=
he=20
<br>> same thing. If they'd just used `std::any`, this wouldn't =
be a problem.=20
<br>> But if you had your way, there would be no `std::any`, so you'=
d have two=20
<br>> Balkanized libraries that only work with themselves and code writt=
en=20
<br>> specifically against them.
<br>
<br>Right. =C2=A0This is the essence of the argument for the current system=
.. =C2=A0I=20
<br>don't dispute that the argument has merit. =C2=A0But I don't th=
ink that this=20
<br>is the only consideration. =C2=A0The current system also has a lot of=
=20
<br>problems which are widely noted. =C2=A0Something is going to have to ch=
ange.=20
<br>My view is that the only thing that will make a difference will be to=
=20
<br>narrow the scope of what the committee has to deal with. =C2=A0I think =
a lot=20
<br>of people would agree with this. =C2=A0At least until it has to be deci=
de=20
<br>what should be eliminated from that scope.<br></blockquote><div><br></d=
iv><div>Here's the thing though. The committee is already divided betwe=
en CWG/EWG (which considers language features) and LWG/LEWG (which consider=
s library features). The two groups do communicate, where one has need of t=
he other. But they are separate.</div><div><br></div><div>Reducing the amou=
nt of stuff LWG deals with will in no way lower the amount of stuff CWG dea=
ls with. So it's not going to get you language features any faster. The=
graphics TS was not dismissed because it would slow down progress on langu=
age features; it was dismissed because it would slow down progress on <i>li=
brary</i> features.<br></div><div><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;">
> The thing is, we both agree that there are domains the committee shoul=
d=20
<br>> not be exploring. It's simply a matter of where that line gets=
drawn. To=20
<br>> you, that line should be "OS features" and that's it=
.. To me, my concern=20
<br>> is primarily about having platform neutrality and general code=20
<br>> inter-operation.
<br>
<br>Hmmm ... I don't see much difference between what I mean when I say=
OS=20
<br>features and you say "platform neutrality".
<br></blockquote><div><br></div><div>Read the part after the "and"=
;. Vocabulary types (optional, any, etc) and common programming idioms (ite=
rators, arrays, linked-lists, etc) are vital aspects to any decent standard=
library.</div><div><br></div><div>I don't believe it is useful to draw=
some definitive, immutable line as to where things ought to be between the=
standard library and 3rd parties. That doesn't mean everything ought t=
o be permissible. But a hard-and-fast rule for standard libraries hurts mor=
e than it helps.</div><div><br></div><div>It's better to have general p=
rinciples, which can be applied to specific cases, but always with a view t=
owards serving the genuine needs of C++ programmers.<br></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d1d4fe21-d833-4d59-98b1-1c04a5646003%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d1d4fe21-d833-4d59-98b1-1c04a5646003=
%40isocpp.org</a>.<br />
------=_Part_18565_40513494.1528127955033--
------=_Part_18564_441128094.1528127955032--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 4 Jun 2018 16:05:26 -0400
Raw View
On 2018-06-04 05:58, Richard Hodges wrote:
> On 4 Jun 2018, at 11:46, olafvdspek@gmail.com wrote:
>> Why should file IO be part of std but network IO should not be?
>
> And if we have standard file and network, why not standard visual
> display, standard human interaction, standard audio?
There is, indeed, a fine line to walk here. However, I think we've seen
some good guidelines. Things should be in the standard library iff:
- They are widely used.
- There is strong agreement on how to do them.
- They are not subject to rapid change.
Networking, in general, clearly does not fit this model. There are many
ways (synchronous, callback-based, ASIO, other asynchronous approaches)
to implement network communication.
That said, if we had good tools for dealing with all of these different
methods, it *might* make sense to have high level network API's in the
standard. In any case, I think it could make sense to have *low* level
API's standardized, i.e. basic socket operations (create a socket, read
from a socket)...
File *system* mostly passes these tests, although file *I/O* doesn't...
and indeed, many people *don't* use the standard library for file I/O.
Similarly, I think there is room for some *low* level API's in the area
of audio and input handling, but I would argue that there are too many
competing high level approaches to warrant trying to create One True
API. This is even more true for graphics, where even low level things
can vary widely in approach.
--
Matthew
--
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/2be240b2-44e1-c755-e20a-6f50d668a2d3%40gmail.com.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 4 Jun 2018 16:05:32 -0400
Raw View
On 2018-06-02 19:46, Robert Ramey wrote:
> The trickiest functions: networking, linear algebra, gui, serialization,
> are all currently handled by non-iso libraries.=C2=A0 I don't see the val=
ue
> of the C++ committee trying to contribute to that.
The value is that not everyone uses these libraries, even when they
should. (Of course, this has been true to some extent even for STL.
There is some improvement there, but there are still some gaps; no COW
containers, no Unicode... but we may get there eventually.)
Better tooling could help, but until we have that...
Eigen=C2=B9 is, for me, a poster child of something that *ought* to be
standardized, and it's interesting to compare Eigen to P0267. Eigen,
especially if we drop all the approximation stuff and focus on the more
fundamental types and mathematical operations, is extremely static and
well defined. It's also *tremendously* useful; any application with even
curses-level "graphics" would benefit from its standardization. It also
doesn't exist in a space where there are many competing conceptual
approaches to its problem domain. This is in sharp contrast to
"graphics", or even "input" (or ASIO, for that matter), which have many
competing approaches. (Compare e.g. GTK vs. Qt vs. MFC vs. AWT vs. ...,
all of which use very different approaches to accomplish very similar
tasks.)
....That said, I'm not familiar with GLM. At the low level (e.g.
considering only non-sparse vectors and matrices, and only basic
operations), does it provide anything that Eigen does not?
--=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/09f79d15-46b2-616b-a702-da8e98f4632b%40gmail.com=
..
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 4 Jun 2018 16:23:45 -0400
Raw View
On 2018-06-04 11:59, Nicol Bolas wrote:
> "Evolution, capitalism, art, politics and other fields which are not overly
> centralized" all prove to us that you eventually wind up with *multiple
> competing* standards, with no one standard winning out in the end. Windows,
> MacOS, and dozens of flavors of Linux all exist, despite doing the same
> basic thing. Qt and Gnome still exist, despite doing the same thing, with
> no sign that either is going to "win" over the other. I can keep going, but
> my point is clear: your model ends up with lots of competing, incompatible
> things that all do the same basic thing, not a single standard.
....and this *isn't necessarily a bad thing* (certainly it isn't in
capitalism, as the connotations usually associated with "monopoly" ought
to make clear).
Standardization is good when those multiple competing standards really
*are* doing the same thing. Having different ways to express "a linear
algebra vector of two doubles" is unhelpful. Having different ways to
design user interfaces is *good*, because not every solution is equally
good for all users.
--
Matthew
--
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/982458b0-f897-e2ad-b164-d49c06508ba0%40gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 4 Jun 2018 16:33:01 -0700 (PDT)
Raw View
------=_Part_37313_2114294981.1528155181193
Content-Type: multipart/alternative;
boundary="----=_Part_37314_1285534315.1528155181193"
------=_Part_37314_1285534315.1528155181193
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Monday, June 4, 2018 at 4:05:35 PM UTC-4, Matthew Woehlke wrote:
>
> On 2018-06-02 19:46, Robert Ramey wrote:=20
> > The trickiest functions: networking, linear algebra, gui, serialization=
,=20
> > are all currently handled by non-iso libraries. I don't see the value=
=20
> > of the C++ committee trying to contribute to that.=20
>
> The value is that not everyone uses these libraries, even when they=20
> should. (Of course, this has been true to some extent even for STL.=20
> There is some improvement there, but there are still some gaps; no COW=20
> containers, no Unicode... but we may get there eventually.)=20
>
> Better tooling could help, but until we have that...=20
>
> Eigen=C2=B9 is, for me, a poster child of something that *ought* to be=20
> standardized, and it's interesting to compare Eigen to P0267. Eigen,=20
> especially if we drop all the approximation stuff and focus on the more=
=20
> fundamental types and mathematical operations, is extremely static and=20
> well defined. It's also *tremendously* useful; any application with even=
=20
> curses-level "graphics" would benefit from its standardization. It also=
=20
> doesn't exist in a space where there are many competing conceptual=20
> approaches to its problem domain. This is in sharp contrast to=20
> "graphics", or even "input" (or ASIO, for that matter), which have many=
=20
> competing approaches. (Compare e.g. GTK vs. Qt vs. MFC vs. AWT vs. ...,=
=20
> all of which use very different approaches to accomplish very similar=20
> tasks.)=20
>
> ...That said, I'm not familiar with GLM. At the low level (e.g.=20
> considering only non-sparse vectors and matrices, and only basic=20
> operations), does it provide anything that Eigen does not?
>
Eh, probably not.
I brought up GLM in relation to Eigen because you see GLM a lot in the=20
open-source OpenGL world. The main things GLM brings to the table are about=
=20
usability, not functionality. It's comparatively tiny. It follows GLSL=20
conventions, so if you know one, you know the other. It's header-only=20
(easier to install). And it doesn't have complexities that aren't=20
especially useful for its particular userbase (arbitrarily sized and/or=20
sparse vectors/matrices don't really matter in a lot of basic 3D rendering=
=20
applications), which makes it much less complex.
But these are things that would be irrelevant for the purposes of=20
standardization.
--=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/812873d5-4e54-407c-87cd-8d35f7614844%40isocpp.or=
g.
------=_Part_37314_1285534315.1528155181193
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, June 4, 2018 at 4:05:35 PM UTC-4, Matthew Woehl=
ke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2018-06-02 19:46, =
Robert Ramey wrote:
<br>> The trickiest functions: networking, linear algebra, gui, serializ=
ation,
<br>> are all currently handled by non-iso libraries.=C2=A0 I don't =
see the value
<br>> of the C++ committee trying to contribute to that.
<br>
<br>The value is that not everyone uses these libraries, even when they
<br>should. (Of course, this has been true to some extent even for STL.
<br>There is some improvement there, but there are still some gaps; no COW
<br>containers, no Unicode... but we may get there eventually.)
<br>
<br>Better tooling could help, but until we have that...
<br>
<br>Eigen=C2=B9 is, for me, a poster child of something that *ought* to be
<br>standardized, and it's interesting to compare Eigen to P0267. Eigen=
,
<br>especially if we drop all the approximation stuff and focus on the more
<br>fundamental types and mathematical operations, is extremely static and
<br>well defined. It's also *tremendously* useful; any application with=
even
<br>curses-level "graphics" would benefit from its standardizatio=
n. It also
<br>doesn't exist in a space where there are many competing conceptual
<br>approaches to its problem domain. This is in sharp contrast to
<br>"graphics", or even "input" (or ASIO, for that matt=
er), which have many
<br>competing approaches. (Compare e.g. GTK vs. Qt vs. MFC vs. AWT vs. ...,
<br>all of which use very different approaches to accomplish very similar
<br>tasks.)
<br>
<br>...That said, I'm not familiar with GLM. At the low level (e.g.
<br>considering only non-sparse vectors and matrices, and only basic
<br>operations), does it provide anything that Eigen does not?<br></blockqu=
ote><div><br></div><div>Eh, probably not.</div><div><br></div><div>I brough=
t up GLM in relation to Eigen because you see GLM a lot in the open-source =
OpenGL world. The main things GLM brings to the table are about usability, =
not functionality. It's comparatively tiny. It follows GLSL conventions=
, so if you know one, you know the other. It's header-only (easier to i=
nstall). And it doesn't have complexities that aren't especially us=
eful for its particular userbase (arbitrarily sized and/or sparse vectors/m=
atrices don't really matter in a lot of basic 3D rendering applications=
), which makes it much less complex.</div><div><br></div><div>But these are=
things that would be irrelevant for the purposes of standardization.<br></=
div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/812873d5-4e54-407c-87cd-8d35f7614844%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/812873d5-4e54-407c-87cd-8d35f7614844=
%40isocpp.org</a>.<br />
------=_Part_37314_1285534315.1528155181193--
------=_Part_37313_2114294981.1528155181193--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 4 Jun 2018 16:41:50 -0700 (PDT)
Raw View
------=_Part_28238_1265658556.1528155710190
Content-Type: multipart/alternative;
boundary="----=_Part_28239_620731281.1528155710190"
------=_Part_28239_620731281.1528155710190
Content-Type: text/plain; charset="UTF-8"
On Monday, June 4, 2018 at 4:23:47 PM UTC-4, Matthew Woehlke wrote:
>
> On 2018-06-04 11:59, Nicol Bolas wrote:
> > "Evolution, capitalism, art, politics and other fields which are not
> overly
> > centralized" all prove to us that you eventually wind up with *multiple
> > competing* standards, with no one standard winning out in the end.
> Windows,
> > MacOS, and dozens of flavors of Linux all exist, despite doing the same
> > basic thing. Qt and Gnome still exist, despite doing the same thing,
> with
> > no sign that either is going to "win" over the other. I can keep going,
> but
> > my point is clear: your model ends up with lots of competing,
> incompatible
> > things that all do the same basic thing, not a single standard.
>
> ...and this *isn't necessarily a bad thing*
It isn't necessarily a good one either.
(certainly it isn't in
> capitalism, as the connotations usually associated with "monopoly" ought
> to make clear).
>
> Standardization is good when those multiple competing standards really
> *are* doing the same thing. Having different ways to express "a linear
> algebra vector of two doubles" is unhelpful. Having different ways to
> design user interfaces is *good*, because not every solution is equally
> good for all users.
>
In some cases that may be true. But in general? What makes GTK in any way
better than Qt, from an *objective* user perspective? Or vice-versa?
From what I've seen, the difference between widget toolkits for the user
tends to be like the difference between different brands of paper towels.
They may have different patterns on them, but they all soak up water.
Programmers tend to be far more invested in these trivial differences than
actual users.
That's not to say that there are no differences in toolkits. Certainly
there are different approaches. But they almost always end up in pretty
much the same place from the user's perspective. Users may be able to tell
one widget toolkit from the other, but they're all doing the same stuff.
The principle issue with GUIs is that there are fundamentally different
kinds of *interfaces* out there, and you cannot effectively have a
one-size-fits-all approach to them (no matter how much Microsoft tries).
It's not a Qt vs. GTK vs. MFC thing. It's a mouse&keyboard vs. touch thing.
--
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/2508b58c-0f80-4521-91a8-f52fae4e20df%40isocpp.org.
------=_Part_28239_620731281.1528155710190
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, June 4, 2018 at 4:23:47 PM UTC-4, Matth=
ew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2018-06-04=
11:59, Nicol Bolas wrote:
<br>> "Evolution, capitalism, art, politics and other fields which =
are not overly=20
<br>> centralized" all prove to us that you eventually wind up with=
*multiple=20
<br>> competing* standards, with no one standard winning out in the end.=
Windows,=20
<br>> MacOS, and dozens of flavors of Linux all exist, despite doing the=
same=20
<br>> basic thing. Qt and Gnome still exist, despite doing the same thin=
g, with=20
<br>> no sign that either is going to "win" over the other. I =
can keep going, but=20
<br>> my point is clear: your model ends up with lots of competing, inco=
mpatible=20
<br>> things that all do the same basic thing, not a single standard.
<br>
<br>...and this *isn't necessarily a bad thing*</blockquote><div><br></=
div><div>It isn't necessarily a good one either.<br></div><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"> (certainly it isn't in
<br>capitalism, as the connotations usually associated with "monopoly&=
quot; ought
<br>to make clear).
<br>
<br>Standardization is good when those multiple competing standards really
<br>*are* doing the same thing. Having different ways to express "a li=
near
<br>algebra vector of two doubles" is unhelpful. Having different ways=
to
<br>design user interfaces is *good*, because not every solution is equally
<br>good for all users.<br></blockquote><div><br></div><div>In some cases t=
hat may be true. But in general? What makes GTK in any way better than Qt, =
from an <i>objective</i> user perspective? Or vice-versa?</div><div><br></d=
iv><div>From what I've seen, the difference between widget toolkits for=
the user tends to be like the difference between different brands of paper=
towels. They may have different patterns on them, but they all soak up wat=
er. Programmers tend to be far more invested in these trivial differences t=
han actual users.</div><div><br></div><div>That's not to say that there=
are no differences in toolkits. Certainly there are different approaches. =
But they almost always end up in pretty much the same place from the user&#=
39;s perspective. Users may be able to tell one widget toolkit from the oth=
er, but they're all doing the same stuff.<br></div><div><br></div><div>=
The principle issue with GUIs is that there are fundamentally different kin=
ds of <i>interfaces</i> out there, and you cannot effectively have a one-si=
ze-fits-all approach to them (no matter how much Microsoft tries). It's=
not a Qt vs. GTK vs. MFC thing. It's a mouse&keyboard vs. touch th=
ing.<br></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2508b58c-0f80-4521-91a8-f52fae4e20df%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2508b58c-0f80-4521-91a8-f52fae4e20df=
%40isocpp.org</a>.<br />
------=_Part_28239_620731281.1528155710190--
------=_Part_28238_1265658556.1528155710190--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 04 Jun 2018 18:34:54 -0700
Raw View
On Monday, 4 June 2018 16:41:50 PDT Nicol Bolas wrote:
> The principle issue with GUIs is that there are fundamentally different
> kinds of *interfaces* out there, and you cannot effectively have a
> one-size-fits-all approach to them (no matter how much Microsoft tries).
Microsoft *doesn't* try. They have several toolkits of theirs and their
applications tend to change L&F every couple of years.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/2480376.QyW7h1Xanl%40tjmaciei-mobl1.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 5 Jun 2018 09:34:58 -0400
Raw View
On 2018-06-04 19:41, Nicol Bolas wrote:
> On Monday, June 4, 2018 at 4:23:47 PM UTC-4, Matthew Woehlke wrote:
>> Standardization is good when those multiple competing standards really
>> *are* doing the same thing. Having different ways to express "a linear
>> algebra vector of two doubles" is unhelpful. Having different ways to
>> design user interfaces is *good*, because not every solution is equally
>> good for all users.
>
> In some cases that may be true. But in general? What makes GTK in any way
> better than Qt, from an *objective* user perspective? Or vice-versa?
I'm *not* a fan of GTK, so I can only give a biased answer :-). As far
as what makes *Qt* great, well... The layout system makes it trivially
easy to design resizable interfaces, and almost hard *not* to do so. The
event mechanism (signals/slots) is IMO the best design I've ever seen,
and has tremendous advantages such as queuing and thread safety.
Yet, many, many people use GTK, and some even use wxWidgets, and of
course there's whatever Windows is using today. Presumably there is
*something* about these other systems that people find desirable that
they use them instead of Qt.
> From what I've seen, the difference between widget toolkits for the user
> tends to be like the difference between different brands of paper towels.
That's *somewhat* true, if mostly irrelevant. The major differences are
for *developers*, which is IMO pretty important. The use of
signals/slots as opposed to some other event mechanism is invisible to
users, but makes a huge difference in developer productivity, especially
when you start needing cross-thread communication (which is just dead
simple in Qt).
That said, it's rare to find a user interface made with Qt that isn't
resizable, but I see interfaces made with GTK all the time that are
either fixed-size or resize much more poorly than would a similar
interface made with Qt. (Qt applications also tend to let the user move
the toolbars, which is rare in GTK.) So there are *some* user-visible
differences.
This is sort of like comparing printf to iostreams. As far as the user
is concerned, they both do the same job. Would you use that to argue
that iostreams should not exist?
--
Matthew
--
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/31077b82-bb39-5244-dbbd-2563626eb6c4%40gmail.com.
.
Author: Vinnie Falco <vinnie.falco@gmail.com>
Date: Wed, 6 Jun 2018 07:59:50 -0700 (PDT)
Raw View
------=_Part_16153_1411607319.1528297190710
Content-Type: multipart/alternative;
boundary="----=_Part_16154_781821465.1528297190711"
------=_Part_16154_781821465.1528297190711
Content-Type: text/plain; charset="UTF-8"
On Monday, June 4, 2018 at 2:58:51 AM UTC-7, Richard Hodges wrote:
> if we have standard file and network, why not standard visual display,
> standard human interaction, standard audio?
There's a very good reason why networking should be standardized but
graphical user interfaces should not. It is because a universal abstraction
for networking is far easier to develop than it is to develop a universal
abstraction for graphics and user interface components. By "universal" I
mean an abstraction which is zero cost (a distinguishing feature of C++)
and can take advantage of (almost) all of the features of platform or
hardware-specifics. It is very easy to design a graphics/GUI library that
only gives you a limit subset of common features across all platforms that
support GUIs (such as hardware acceleration).
How do I know these things? Because we have had wonderful abstractions for
networking, but no abstractions or poor abstractions for graphics and user
interfaces. No graphics/GUI standard has jumped out ahead of the pack and
demonstrated ubiquity despite tons of resources being poured into it at the
commercial level. The 3 major platforms (Windows, OS X, Linux) do not even
agree on a particular API. This suggests that the problem domain of
designing a universal programmatic API to graphics is HARD.
I have personal doubts that such a universal abstraction exists for
graphics. I feel that the best possible outcome of a push to standardize 2d
graphics is that we will get something that is mediocre in comparison to
existing solutions. Perhaps it will be useful for "education" or "casual
use" (whatever that means). But I don't think that's enough of a reason to
standardize it.
--
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/12e65f35-e04b-4c68-a7bd-381a99a1f95d%40isocpp.org.
------=_Part_16154_781821465.1528297190711
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, June 4, 2018 at 2:58:51 AM UTC-7, Richard Hodge=
s wrote:<br>> if we have standard file and network, why not standard vis=
ual display,<div>> standard human interaction, standard audio?<br> </div=
><div><br></div><div>There's a very good reason why networking should b=
e standardized but graphical user interfaces should not. It is because a un=
iversal abstraction for networking is far easier to develop than it is to d=
evelop a universal abstraction for graphics and user interface components. =
By "universal" I mean an abstraction which is zero cost (a distin=
guishing feature of C++) and can take advantage of (almost) all of the feat=
ures of platform or hardware-specifics. It is very easy to design a graphic=
s/GUI library that only gives you a limit subset of common features across =
all platforms that support GUIs (such as hardware acceleration).</div><div>=
<br></div><div>How do I know these things? Because we have had wonderful ab=
stractions for networking, but no abstractions or poor abstractions for gra=
phics and user interfaces. No graphics/GUI standard has jumped out ahead of=
the pack and demonstrated ubiquity despite tons of resources being poured =
into it at the commercial level. The 3 major platforms (Windows, OS X, Linu=
x) do not even agree on a particular API. This suggests that the problem do=
main of designing a universal programmatic API to graphics is HARD.</div><d=
iv><br></div><div>I have personal doubts that such a universal abstraction =
exists for graphics. I feel that the best possible outcome of a push to sta=
ndardize 2d graphics is that we will get something that is mediocre in comp=
arison to existing solutions. Perhaps it will be useful for "education=
" or "casual use" (whatever that means). But I don't thi=
nk that's enough of a reason to standardize it.<br><br></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/12e65f35-e04b-4c68-a7bd-381a99a1f95d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/12e65f35-e04b-4c68-a7bd-381a99a1f95d=
%40isocpp.org</a>.<br />
------=_Part_16154_781821465.1528297190711--
------=_Part_16153_1411607319.1528297190710--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Wed, 6 Jun 2018 16:39:51 +0100
Raw View
--000000000000f8ec55056dfafa5e
Content-Type: text/plain; charset="UTF-8"
> The 3 major platforms (Windows, OS X, Linux) do not even agree on a
particular API.
Actually they do. If you want to write portable 3D graphics you use OpenGL
and not Direct3d.
There have been a number of excellent portable abstraction layers for
graphics. Ogre3d (showing its age) is one notable example. When I used it,
it provided very effective abstractions, seamlessly supporting both directx
and opengl as a back end (including their different matrix and co-ordinate
conventions).
When it comes to standards and vendors, I am of the same mind as Jim
Morrison's avatar in Wayne's World 2:
"If you build it, they will come..."
On Wed, 6 Jun 2018 at 15:59, Vinnie Falco <vinnie.falco@gmail.com> wrote:
> On Monday, June 4, 2018 at 2:58:51 AM UTC-7, Richard Hodges wrote:
> > if we have standard file and network, why not standard visual display,
> > standard human interaction, standard audio?
>
> There's a very good reason why networking should be standardized but
> graphical user interfaces should not. It is because a universal abstraction
> for networking is far easier to develop than it is to develop a universal
> abstraction for graphics and user interface components. By "universal" I
> mean an abstraction which is zero cost (a distinguishing feature of C++)
> and can take advantage of (almost) all of the features of platform or
> hardware-specifics. It is very easy to design a graphics/GUI library that
> only gives you a limit subset of common features across all platforms that
> support GUIs (such as hardware acceleration).
>
> How do I know these things? Because we have had wonderful abstractions for
> networking, but no abstractions or poor abstractions for graphics and user
> interfaces. No graphics/GUI standard has jumped out ahead of the pack and
> demonstrated ubiquity despite tons of resources being poured into it at the
> commercial level. The 3 major platforms (Windows, OS X, Linux) do not even
> agree on a particular API. This suggests that the problem domain of
> designing a universal programmatic API to graphics is HARD.
>
> I have personal doubts that such a universal abstraction exists for
> graphics. I feel that the best possible outcome of a push to standardize 2d
> graphics is that we will get something that is mediocre in comparison to
> existing solutions. Perhaps it will be useful for "education" or "casual
> use" (whatever that means). But I don't think that's enough of a reason to
> standardize it.
>
> --
> 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/12e65f35-e04b-4c68-a7bd-381a99a1f95d%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/12e65f35-e04b-4c68-a7bd-381a99a1f95d%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/CALvx3hZYVJi%3Dey%3D4EphniCt3HEMVSF%3DkDkbKvWdmFtGMBCSjNw%40mail.gmail.com.
--000000000000f8ec55056dfafa5e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"color:rgb(34,34,34);font-family:s=
ans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;fo=
nt-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:sta=
rt;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;=
background-color:rgb(255,255,255);text-decoration-style:initial;text-decora=
tion-color:initial;float:none;display:inline">The 3 major platforms (Window=
s, OS X, Linux) do not even agree on a particular API.</span><div><span sty=
le=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:=
normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:4=
00;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:no=
ne;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);te=
xt-decoration-style:initial;text-decoration-color:initial;float:none;displa=
y:inline"><br></span></div><div><span style=3D"color:rgb(34,34,34);font-fam=
ily:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:norm=
al;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-alig=
n:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing=
:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-d=
ecoration-color:initial;float:none;display:inline">Actually they do. If you=
want to write portable 3D graphics you use OpenGL and not Direct3d.</span>=
</div><div><span style=3D"color:rgb(34,34,34);font-family:sans-serif;font-s=
ize:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:=
normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0=
px;text-transform:none;white-space:normal;word-spacing:0px;background-color=
:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initi=
al;float:none;display:inline"><br></span></div><div><span style=3D"color:rg=
b(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-va=
riant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spac=
ing:normal;text-align:start;text-indent:0px;text-transform:none;white-space=
:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-=
style:initial;text-decoration-color:initial;float:none;display:inline">Ther=
e have been a number of excellent portable abstraction layers for graphics.=
Ogre3d (showing its age) is one notable example. When I used it, it provid=
ed very effective abstractions, seamlessly supporting both directx and open=
gl as a back end (including their different matrix and co-ordinate conventi=
ons).</span></div><div><span style=3D"color:rgb(34,34,34);font-family:sans-=
serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-v=
ariant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;t=
ext-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;back=
ground-color:rgb(255,255,255);text-decoration-style:initial;text-decoration=
-color:initial;float:none;display:inline"><br></span></div><div><span style=
=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:no=
rmal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400=
;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none=
;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text=
-decoration-style:initial;text-decoration-color:initial;float:none;display:=
inline">When it comes to standards and vendors, I am of the same mind as Ji=
m Morrison's avatar in Wayne's World 2:=C2=A0</span></div><div><spa=
n style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-s=
tyle:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-wei=
ght:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transfo=
rm:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,25=
5);text-decoration-style:initial;text-decoration-color:initial;float:none;d=
isplay:inline"><br></span></div><div><span style=3D"color:rgb(34,34,34);fon=
t-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures=
:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-sp=
acing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;t=
ext-decoration-color:initial;float:none;display:inline">"If you build =
it, they will come..."</span></div><div><span style=3D"color:rgb(34,34=
,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-l=
igatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:nor=
mal;text-align:start;text-indent:0px;text-transform:none;white-space:normal=
;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:i=
nitial;text-decoration-color:initial;float:none;display:inline"><br></span>=
</div><div>=C2=A0=C2=A0<br></div></div><br><div class=3D"gmail_quote"><div =
dir=3D"ltr">On Wed, 6 Jun 2018 at 15:59, Vinnie Falco <<a href=3D"mailto=
:vinnie.falco@gmail.com">vinnie.falco@gmail.com</a>> wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr">On Monday, June 4, 2018 at 2:5=
8:51 AM UTC-7, Richard Hodges wrote:<br>> if we have standard file and n=
etwork, why not standard visual display,<div>> standard human interactio=
n, standard audio?<br> </div><div><br></div><div>There's a very good re=
ason why networking should be standardized but graphical user interfaces sh=
ould not. It is because a universal abstraction for networking is far easie=
r to develop than it is to develop a universal abstraction for graphics and=
user interface components. By "universal" I mean an abstraction =
which is zero cost (a distinguishing feature of C++) and can take advantage=
of (almost) all of the features of platform or hardware-specifics. It is v=
ery easy to design a graphics/GUI library that only gives you a limit subse=
t of common features across all platforms that support GUIs (such as hardwa=
re acceleration).</div><div><br></div><div>How do I know these things? Beca=
use we have had wonderful abstractions for networking, but no abstractions =
or poor abstractions for graphics and user interfaces. No graphics/GUI stan=
dard has jumped out ahead of the pack and demonstrated ubiquity despite ton=
s of resources being poured into it at the commercial level. The 3 major pl=
atforms (Windows, OS X, Linux) do not even agree on a particular API. This =
suggests that the problem domain of designing a universal programmatic API =
to graphics is HARD.</div><div><br></div><div>I have personal doubts that s=
uch a universal abstraction exists for graphics. I feel that the best possi=
ble outcome of a push to standardize 2d graphics is that we will get someth=
ing that is mediocre in comparison to existing solutions. Perhaps it will b=
e useful for "education" or "casual use" (whatever that=
means). But I don't think that's enough of a reason to standardize=
it.<br><br></div></div>
<p></p>
-- <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" target=3D"_=
blank">std-proposals+unsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/12e65f35-e04b-4c68-a7bd-381a99a1f95d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/12e65f35-e04b-=
4c68-a7bd-381a99a1f95d%40isocpp.org</a>.<br>
</blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hZYVJi%3Dey%3D4EphniCt3HEMVSF%3=
DkDkbKvWdmFtGMBCSjNw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZYVJ=
i%3Dey%3D4EphniCt3HEMVSF%3DkDkbKvWdmFtGMBCSjNw%40mail.gmail.com</a>.<br />
--000000000000f8ec55056dfafa5e--
.
Author: Rene Rivera <grafikrobot@gmail.com>
Date: Wed, 6 Jun 2018 10:57:11 -0500
Raw View
--0000000000005df77e056dfb38f9
Content-Type: text/plain; charset="UTF-8"
On Wed, Jun 6, 2018 at 10:39 AM, Richard Hodges <hodges.r@gmail.com> wrote:
> > The 3 major platforms (Windows, OS X, Linux) do not even agree on a
> particular API.
>
> Actually they do. If you want to write portable 3D graphics you use OpenGL
> and not Direct3d.
>
With the recent news from Apple that is clearly not the case. More and more
software is moving to the newer, and fragmented, rendering APIs. So I think
saying they do not agree on a particular rendering API is a reasonably
accurate statement.
--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
--
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/CAHEh_Gh1uD9504eTfkQLcpH8we6iRkKGCxnWOYao%3DYPcqY7L1w%40mail.gmail.com.
--0000000000005df77e056dfb38f9
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 W=
ed, Jun 6, 2018 at 10:39 AM, Richard Hodges <span dir=3D"ltr"><<a href=
=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a>>=
</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"><span cla=
ss=3D"">>=C2=A0<span style=3D"color:rgb(34,34,34);font-family:sans-serif=
;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-varian=
t-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-i=
ndent:0px;text-transform:none;white-space:normal;word-spacing:0px;backgroun=
d-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-colo=
r:initial;float:none;display:inline">The 3 major platforms (Windows, OS X, =
Linux) do not even agree on a particular API.</span><div><span style=3D"col=
or:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;fo=
nt-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter=
-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-=
space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decora=
tion-style:initial;text-decoration-color:initial;float:none;display:inline"=
><br></span></div></span><div><span style=3D"color:rgb(34,34,34);font-famil=
y:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal=
;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:=
start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0=
px;background-color:rgb(255,255,255);text-decoration-style:initial;text-dec=
oration-color:initial;float:none;display:inline">Actually they do. If you w=
ant to write portable 3D graphics you use OpenGL and not Direct3d.</span></=
div></div></blockquote><div><br></div><div>With the recent news from Apple =
that is clearly not the case. More and more software is moving to the newer=
, and fragmented, rendering APIs. So I think saying they do not agree on a =
particular rendering API is a reasonably accurate statement.</div><div><br>=
</div></div>-- <br><div class=3D"gmail_signature" data-smartmail=3D"gmail_s=
ignature"><div dir=3D"ltr"><div><div dir=3D"ltr">-- Rene Rivera<br>-- Grafi=
k - Don't Assume Anything<br>-- Robot Dreams -=C2=A0<a href=3D"http://r=
obot-dreams.net/" target=3D"_blank">http://robot-dreams.net</a><br><br></di=
v></div></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" 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/CAHEh_Gh1uD9504eTfkQLcpH8we6iRkKGCxnW=
OYao%3DYPcqY7L1w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_Gh1uD9504=
eTfkQLcpH8we6iRkKGCxnWOYao%3DYPcqY7L1w%40mail.gmail.com</a>.<br />
--0000000000005df77e056dfb38f9--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Wed, 6 Jun 2018 17:04:37 +0100
Raw View
--000000000000882db7056dfb5367
Content-Type: text/plain; charset="UTF-8"
On Wed, 6 Jun 2018 at 16:57, Rene Rivera <grafikrobot@gmail.com> wrote:
> On Wed, Jun 6, 2018 at 10:39 AM, Richard Hodges <hodges.r@gmail.com>
> wrote:
>
>> > The 3 major platforms (Windows, OS X, Linux) do not even agree on a
>> particular API.
>>
>> Actually they do. If you want to write portable 3D graphics you use
>> OpenGL and not Direct3d.
>>
>
> With the recent news from Apple that is clearly not the case. More and
> more software is moving to the newer, and fragmented, rendering APIs. So I
> think saying they do not agree on a particular rendering API is a
> reasonably accurate statement.
>
I'm not saying you're wrong. Have I been misled by this?
"OpenGL is the foundation for hardware-accelerated graphics in macOS."
source: https://developer.apple.com/opengl/
>
> --
> -- Rene Rivera
> -- Grafik - Don't Assume Anything
> -- Robot Dreams - http://robot-dreams.net
>
> --
> 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/CAHEh_Gh1uD9504eTfkQLcpH8we6iRkKGCxnWOYao%3DYPcqY7L1w%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_Gh1uD9504eTfkQLcpH8we6iRkKGCxnWOYao%3DYPcqY7L1w%40mail.gmail.com?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/CALvx3hatsgrPt205cadx8YE0QfB8rCqKCRX5mqrAn-utVpCNCQ%40mail.gmail.com.
--000000000000882db7056dfb5367
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed=
, 6 Jun 2018 at 16:57, Rene Rivera <<a href=3D"mailto:grafikrobot@gmail.=
com">grafikrobot@gmail.com</a>> wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote">On Wed, Jun 6, 2018 at 10:39 AM, Richard Hodges <span=
dir=3D"ltr"><<a href=3D"mailto:hodges.r@gmail.com" target=3D"_blank">ho=
dges.r@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr"><span>>=C2=A0<span style=3D"color:rgb(=
34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-vari=
ant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacin=
g:normal;text-align:start;text-indent:0px;text-transform:none;white-space:n=
ormal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-st=
yle:initial;text-decoration-color:initial;float:none;display:inline">The 3 =
major platforms (Windows, OS X, Linux) do not even agree on a particular AP=
I.</span><div><span style=3D"color:rgb(34,34,34);font-family:sans-serif;fon=
t-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-ca=
ps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-inden=
t:0px;text-transform:none;white-space:normal;word-spacing:0px;background-co=
lor:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:in=
itial;float:none;display:inline"><br></span></div></span><div><span style=
=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:no=
rmal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400=
;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none=
;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text=
-decoration-style:initial;text-decoration-color:initial;float:none;display:=
inline">Actually they do. If you want to write portable 3D graphics you use=
OpenGL and not Direct3d.</span></div></div></blockquote><div><br></div><di=
v>With the recent news from Apple that is clearly not the case. More and mo=
re software is moving to the newer, and fragmented, rendering APIs. So I th=
ink saying they do not agree on a particular rendering API is a reasonably =
accurate statement.</div></div></div></div></blockquote><div><br></div><div=
>I'm not saying you're wrong. Have I been misled by this?</div><div=
><br></div><div>"OpenGL is the foundation for hardware-accelerated gra=
phics in macOS."</div><div><br></div><div>source:=C2=A0<a href=3D"http=
s://developer.apple.com/opengl/">https://developer.apple.com/opengl/</a></d=
iv><div><br></div><div>=C2=A0</div><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 class=3D"gmail_extra"><div class=3D"gmail_=
quote"><div><br></div></div>-- <br><div class=3D"gmail-m_-50241637863716643=
13gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr">-- Rene Rivera<br=
>-- Grafik - Don't Assume Anything<br>-- Robot Dreams -=C2=A0<a href=3D=
"http://robot-dreams.net/" target=3D"_blank">http://robot-dreams.net</a><br=
><br></div></div></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" 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@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHEh_Gh1uD9504eTfkQLcpH8we6iRkKGCxnW=
OYao%3DYPcqY7L1w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAHEh_Gh1uD9504eTfkQLcpH8we6iRkKGCxnWOYao%3DYPcqY7L1w%40mail.gmail.c=
om</a>.<br>
</blockquote></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hatsgrPt205cadx8YE0QfB8rCqKCRX5=
mqrAn-utVpCNCQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hatsgrPt205=
cadx8YE0QfB8rCqKCRX5mqrAn-utVpCNCQ%40mail.gmail.com</a>.<br />
--000000000000882db7056dfb5367--
.
Author: Rene Rivera <grafikrobot@gmail.com>
Date: Wed, 6 Jun 2018 11:07:52 -0500
Raw View
--0000000000007e42a7056dfb5e17
Content-Type: text/plain; charset="UTF-8"
On Wed, Jun 6, 2018 at 11:04 AM, Richard Hodges <hodges.r@gmail.com> wrote:
>
>
> On Wed, 6 Jun 2018 at 16:57, Rene Rivera <grafikrobot@gmail.com> wrote:
>
>> On Wed, Jun 6, 2018 at 10:39 AM, Richard Hodges <hodges.r@gmail.com>
>> wrote:
>>
>>> > The 3 major platforms (Windows, OS X, Linux) do not even agree on a
>>> particular API.
>>>
>>> Actually they do. If you want to write portable 3D graphics you use
>>> OpenGL and not Direct3d.
>>>
>>
>> With the recent news from Apple that is clearly not the case. More and
>> more software is moving to the newer, and fragmented, rendering APIs. So I
>> think saying they do not agree on a particular rendering API is a
>> reasonably accurate statement.
>>
>
> I'm not saying you're wrong. Have I been misled by this?
>
> "OpenGL is the foundation for hardware-accelerated graphics in macOS."
>
> source: https://developer.apple.com/opengl/
>
From <https://developer.apple.com/macos/whats-new/>
"Apps built using OpenGL and OpenCL will continue to run in macOS 10.14,
but these legacy technologies are deprecated in macOS 10.14. Games and
graphics-intensive apps that use OpenGL should now adopt Metal. Similarly,
apps that use OpenCL for computational tasks should now adopt Metal and
Metal Performance Shaders."
--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
--
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/CAHEh_Gh%3DNv9%2Bo01%2BauyjB2rrHuxAqdipZH-HiN9-yKKqRP6LcQ%40mail.gmail.com.
--0000000000007e42a7056dfb5e17
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 W=
ed, Jun 6, 2018 at 11:04 AM, Richard Hodges <span dir=3D"ltr"><<a href=
=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a>>=
</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 di=
r=3D"ltr"><br><br><div class=3D"gmail_quote"><span class=3D"gmail-"><div di=
r=3D"ltr">On Wed, 6 Jun 2018 at 16:57, Rene Rivera <<a href=3D"mailto:gr=
afikrobot@gmail.com" target=3D"_blank">grafikrobot@gmail.com</a>> wrote:=
<br></div><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=
"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Wed, Jun 6, 2018=
at 10:39 AM, Richard Hodges <span dir=3D"ltr"><<a href=3D"mailto:hodges=
..r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a>></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"><span>&=
gt;=C2=A0<span style=3D"color:rgb(34,34,34);font-family:sans-serif;font-siz=
e:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:no=
rmal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px=
;text-transform:none;white-space:normal;word-spacing:0px;background-color:r=
gb(255,255,255);text-decoration-style:initial;text-decoration-color:initial=
;float:none;display:inline">The 3 major platforms (Windows, OS X, Linux) do=
not even agree on a particular API.</span><div><span style=3D"color:rgb(34=
,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-varian=
t-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:=
normal;text-align:start;text-indent:0px;text-transform:none;white-space:nor=
mal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-styl=
e:initial;text-decoration-color:initial;float:none;display:inline"><br></sp=
an></div></span><div><span style=3D"color:rgb(34,34,34);font-family:sans-se=
rif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-var=
iant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;tex=
t-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;backgr=
ound-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-c=
olor:initial;float:none;display:inline">Actually they do. If you want to wr=
ite portable 3D graphics you use OpenGL and not Direct3d.</span></div></div=
></blockquote><div><br></div><div>With the recent news from Apple that is c=
learly not the case. More and more software is moving to the newer, and fra=
gmented, rendering APIs. So I think saying they do not agree on a particula=
r rendering API is a reasonably accurate statement.</div></div></div></div>=
</blockquote><div><br></div></span><div>I'm not saying you're wrong=
.. Have I been misled by this?</div><div><br></div><div>"OpenGL is the =
foundation for hardware-accelerated graphics in macOS."</div><div><br>=
</div><div>source:=C2=A0<a href=3D"https://developer.apple.com/opengl/" tar=
get=3D"_blank">https://developer.<wbr>apple.com/opengl/</a></div></div></di=
v></blockquote><div><br></div><div>From <<a href=3D"https://developer.ap=
ple.com/macos/whats-new/">https://developer.apple.com/macos/whats-new/</a>&=
gt;</div><div><br></div><div>"Apps built using OpenGL and OpenCL will =
continue to run in macOS 10.14, but these legacy technologies are deprecate=
d in macOS 10.14. Games and graphics-intensive apps that use OpenGL should =
now adopt Metal. Similarly, apps that use OpenCL for computational tasks sh=
ould now adopt Metal and Metal Performance Shaders."</div><div><br></d=
iv></div><div><br></div>-- <br><div class=3D"gmail_signature"><div dir=3D"l=
tr"><div><div dir=3D"ltr">-- Rene Rivera<br>-- Grafik - Don't Assume An=
ything<br>-- Robot Dreams -=C2=A0<a href=3D"http://robot-dreams.net/" targe=
t=3D"_blank">http://robot-dreams.net</a><br><br></div></div></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" 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/CAHEh_Gh%3DNv9%2Bo01%2BauyjB2rrHuxAqd=
ipZH-HiN9-yKKqRP6LcQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_Gh%3D=
Nv9%2Bo01%2BauyjB2rrHuxAqdipZH-HiN9-yKKqRP6LcQ%40mail.gmail.com</a>.<br />
--0000000000007e42a7056dfb5e17--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 6 Jun 2018 13:48:42 -0400
Raw View
On 2018-06-06 10:59, Vinnie Falco wrote:
> There's a very good reason why networking should be standardized but
> graphical user interfaces should not. It is because a universal abstraction
> for networking is far easier to develop than it is to develop a universal
> abstraction for graphics and user interface components. By "universal" I
> mean an abstraction which is zero cost (a distinguishing feature of C++)
> and can take advantage of (almost) all of the features of platform or
> hardware-specifics. It is very easy to design a graphics/GUI library that
> only gives you a limit subset of common features across all platforms that
> support GUIs (such as hardware acceleration).
>
> How do I know these things? Because we have had wonderful abstractions for
> networking, but no abstractions or poor abstractions for graphics and user
> interfaces. No graphics/GUI standard has jumped out ahead of the pack and
> demonstrated ubiquity despite tons of resources being poured into it at the
> commercial level. The 3 major platforms (Windows, OS X, Linux) do not even
> agree on a particular API.
This is true for *UI* libraries. As others have pointed out, at the
lower level, there is OpenGL (though that is superseded by Vulkan).
I'm curious, though, what *networking* library is in this position.
TTBOMK, there isn't one above the socket layer. (And don't say "ASIO",
that is *far* from universally used.)
Should we adopt OpenGL (or Vulkan) into the standard library? I don't
know. On the plus side, doing so would mean that everyone can count on
it being available, which is good, especially as we would probably want
to standardize at least some of GLUT (or an equivalent) in the process,
which would be helpful since GLUT itself has somewhat less availability
than the rest of OpenGL. On the down side, I doubt standardizing it
would do anything as far as Microsoft and Apple insisting on ignoring it
and developing their own, proprietary libraries, so as far as the goal
of getting everyone to use the same thing, I don't see that happening.
--
Matthew
--
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/c3897b12-ddcf-d094-2cd1-14ef312b8196%40gmail.com.
.
Author: mihailnajdenov@gmail.com
Date: Wed, 6 Jun 2018 11:12:20 -0700 (PDT)
Raw View
------=_Part_4028_1563668.1528308740142
Content-Type: multipart/alternative;
boundary="----=_Part_4029_371777698.1528308740142"
------=_Part_4029_371777698.1528308740142
Content-Type: text/plain; charset="UTF-8"
On Wednesday, June 6, 2018 at 8:48:46 PM UTC+3, Matthew Woehlke wrote:
>
> On 2018-06-06 10:59, Vinnie Falco wrote:
> > There's a very good reason why networking should be standardized but
> > graphical user interfaces should not. It is because a universal
> abstraction
> > for networking is far easier to develop than it is to develop a
> universal
> > abstraction for graphics and user interface components. By "universal" I
> > mean an abstraction which is zero cost (a distinguishing feature of C++)
> > and can take advantage of (almost) all of the features of platform or
> > hardware-specifics. It is very easy to design a graphics/GUI library
> that
> > only gives you a limit subset of common features across all platforms
> that
> > support GUIs (such as hardware acceleration).
> >
> > How do I know these things? Because we have had wonderful abstractions
> for
> > networking, but no abstractions or poor abstractions for graphics and
> user
> > interfaces. No graphics/GUI standard has jumped out ahead of the pack
> and
> > demonstrated ubiquity despite tons of resources being poured into it at
> the
> > commercial level. The 3 major platforms (Windows, OS X, Linux) do not
> even
> > agree on a particular API.
>
> This is true for *UI* libraries. As others have pointed out, at the
> lower level, there is OpenGL (though that is superseded by Vulkan).
>
> I'm curious, though, what *networking* library is in this position.
> TTBOMK, there isn't one above the socket layer. (And don't say "ASIO",
> that is *far* from universally used.)
>
> Should we adopt OpenGL (or Vulkan) into the standard library? I don't
> know. On the plus side, doing so would mean that everyone can count on
> it being available, which is good, especially as we would probably want
> to standardize at least some of GLUT (or an equivalent) in the process,
> which would be helpful since GLUT itself has somewhat less availability
> than the rest of OpenGL. On the down side, I doubt standardizing it
> would do anything as far as Microsoft and Apple insisting on ignoring it
> and developing their own, proprietary libraries, so as far as the goal
> of getting everyone to use the same thing, I don't see that happening.
>
OpenGL and Vulcan are not of that wide use because they are low level, I am
willing to speculate few guys per engine/platform. Usage is limited to
graphics programmers.
OpenGL and Vulcan are just one way of doing things. Diversity is moderate.
OpenGL and Vulcan change all the time. Dynamic is high, very high.
Implementation burden is also extremely high.
Performance and consistency across implementations will become a real
issue.
>
> --
> Matthew
>
--
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/b459ca38-7266-4cf3-953b-849c8f276250%40isocpp.org.
------=_Part_4029_371777698.1528308740142
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, June 6, 2018 at 8:48:46 PM UTC+3, Ma=
tthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2018-06=
-06 10:59, Vinnie Falco wrote:
<br>> There's a very good reason why networking should be standardiz=
ed but=20
<br>> graphical user interfaces should not. It is because a universal ab=
straction=20
<br>> for networking is far easier to develop than it is to develop a un=
iversal=20
<br>> abstraction for graphics and user interface components. By "u=
niversal" I=20
<br>> mean an abstraction which is zero cost (a distinguishing feature o=
f C++)=20
<br>> and can take advantage of (almost) all of the features of platform=
or=20
<br>> hardware-specifics. It is very easy to design a graphics/GUI libra=
ry that=20
<br>> only gives you a limit subset of common features across all platfo=
rms that=20
<br>> support GUIs (such as hardware acceleration).
<br>>=20
<br>> How do I know these things? Because we have had wonderful abstract=
ions for=20
<br>> networking, but no abstractions or poor abstractions for graphics =
and user=20
<br>> interfaces. No graphics/GUI standard has jumped out ahead of the p=
ack and=20
<br>> demonstrated ubiquity despite tons of resources being poured into =
it at the=20
<br>> commercial level. The 3 major platforms (Windows, OS X, Linux) do =
not even=20
<br>> agree on a particular API.
<br>
<br>This is true for *UI* libraries. As others have pointed out, at the
<br>lower level, there is OpenGL (though that is superseded by Vulkan).
<br>
<br>I'm curious, though, what *networking* library is in this position.
<br>TTBOMK, there isn't one above the socket layer. (And don't say =
"ASIO",
<br>that is *far* from universally used.)
<br>
<br>Should we adopt OpenGL (or Vulkan) into the standard library? I don'=
;t
<br>know. On the plus side, doing so would mean that everyone can count on
<br>it being available, which is good, especially as we would probably want
<br>to standardize at least some of GLUT (or an equivalent) in the process,
<br>which would be helpful since GLUT itself has somewhat less availability
<br>than the rest of OpenGL. On the down side, I doubt standardizing it
<br>would do anything as far as Microsoft and Apple insisting on ignoring i=
t
<br>and developing their own, proprietary libraries, so as far as the goal
<br>of getting everyone to use the same thing, I don't see that happeni=
ng.
<br></blockquote><div><br></div><div>OpenGL and Vulcan are not of that wide=
use because they are low level, I am willing to speculate few guys per eng=
ine/platform. Usage is limited to graphics programmers.=C2=A0</div><div><sp=
an style=3D"display: inline !important; float: none; background-color: tran=
sparent; color: rgb(34, 34, 34); font-family: "Arial","Helve=
tica",sans-serif; font-size: 13px; font-style: normal; font-variant: n=
ormal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: le=
ft; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-=
text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">OpenGL and=
Vulcan are just one way of doing things. Diversity is moderate.</span></di=
v><div><span style=3D"text-align: left; color: rgb(34, 34, 34); text-transf=
orm: none; text-indent: 0px; letter-spacing: normal; font-family: "Ari=
al","Helvetica",sans-serif; font-size: 13px; font-variant: n=
ormal; word-spacing: 0px; display: inline !important; white-space: normal; =
orphans: 2; float: none; -webkit-text-stroke-width: 0px; background-color: =
transparent;"><span style=3D"display: inline !important; float: none; backg=
round-color: transparent; color: rgb(34, 34, 34); font-family: "Arial&=
quot;,"Helvetica",sans-serif; font-size: 13px; font-style: normal=
; font-variant: normal; font-weight: 400; letter-spacing: normal; orphans: =
2; text-align: left; text-decoration: none; text-indent: 0px; text-transfor=
m: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing:=
0px;">OpenGL and Vulcan change all the time. Dynamic is high, very high.=
=C2=A0</span></span></div><div><b></b><i></i><u></u><sub></sub><sup></sup><=
strike></strike><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike=
><br></div><div>Implementation burden is also extremely high.=C2=A0<br>Perf=
ormance and consistency across implementations will become a real issue.=C2=
=A0<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>--=20
<br>Matthew
<br></blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b459ca38-7266-4cf3-953b-849c8f276250%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b459ca38-7266-4cf3-953b-849c8f276250=
%40isocpp.org</a>.<br />
------=_Part_4029_371777698.1528308740142--
------=_Part_4028_1563668.1528308740142--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Wed, 6 Jun 2018 15:02:55 -0400
Raw View
--000000000000338e87056dfdd17c
Content-Type: text/plain; charset="UTF-8"
Another problem with standardization of libraries is the language used. An
implementation is free to say "the behavior is whatever this code does."
The standard has trouble with things like that, because it either winds up
specifying the implementation, or it has to try to say in words what the
essence of the code is, and it's hard to get that right without inviting
adversarial interpretations that then need to be accounted for. Or you
have the equally unappealing references to other documents, such as
[filesystem] being full of *as if by POSIX stat* clauses.
Similarly, standardized libraries that involve generic code have to specify
in excruciating detail what happens with dependent types that throw from
unfortunate places, or have unusual overloaded operators, while
implementations can again say "the behavior is whatever this code does."
followed closely by "if you do crazy stuff it will fail in mysterious ways,
so don't do that."
(Of course excruciating language isn't limited to the library. There is an
occasional refrain on these news groups that "you can't learn C++ by
reading the Standard." That's a bug, not a feature.)
--
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/CAHSYqdZsdz7qfouBqEZ2wJ_Q7ZMmWbBtXULEAk0q1qyctHqAHw%40mail.gmail.com.
--000000000000338e87056dfdd17c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Another problem with standardization of libraries is the l=
anguage used.=C2=A0 An implementation is free to say "the behavior is =
whatever this code does."=C2=A0 The standard has trouble with things l=
ike that, because it either winds up specifying the implementation, or it h=
as to try to say in words what the essence of the code is, and it's har=
d to get that right without inviting adversarial interpretations that then =
need to be accounted for.=C2=A0 Or you have the equally unappealing referen=
ces to other documents, such as [filesystem] being full of <i><b>as if by P=
OSIX stat</b></i>=C2=A0clauses.<br><br>Similarly, standardized libraries th=
at involve generic code have to specify in excruciating detail what happens=
with dependent types that throw from unfortunate places, or have unusual o=
verloaded operators, while implementations can again say=C2=A0
<span style=3D"text-decoration-style:initial;text-decoration-color:initial;=
float:none;display:inline">"the behavior is whatever this code does.&q=
uot; followed closely by "if you do crazy stuff it will fail in myster=
ious ways, so don't do that."<br><br>(Of course excruciating langu=
age isn't limited to the library.=C2=A0 There is an occasional refrain =
on these news groups that "you can't learn C++ by reading the Stan=
dard."=C2=A0 That's a bug, not a feature.)</span></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZsdz7qfouBqEZ2wJ_Q7ZMmWbBtXULE=
Ak0q1qyctHqAHw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZsdz7qfouB=
qEZ2wJ_Q7ZMmWbBtXULEAk0q1qyctHqAHw%40mail.gmail.com</a>.<br />
--000000000000338e87056dfdd17c--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 6 Jun 2018 15:35:02 -0400
Raw View
On 2018-06-06 14:12, mihailnajdenov@gmail.com wrote:
> OpenGL and Vulcan are not of that wide use because they are low level,
They are *hugely* used. They may not be used *directly*, but the sort of
folks that are using them indirectly are just as likely to be using the
C++ standard library at one remove.
> I am willing to speculate few guys per engine/platform. Usage is
> limited to graphics programmers.
....and there is no reason to expect that P0267 would be any different.
In fact, that is a LOT of reason to expect it would be even *less*
widely used, in both direct *and indirect* use. (In particular,
developers of higher level libraries are likely to ignore it if it is
not the best performing option.)
> OpenGL and Vulcan are just one way of doing things. Diversity is moderate.
> OpenGL and Vulcan change all the time. Dynamic is high, very high.
>
> Implementation burden is also extremely high.
> Performance and consistency across implementations will become a real
> issue.
....all of which is *exactly* why P0267 is horribly misguided and why C++
should *NOT* be pursuing standardization of a graphics API.
Now, as far as "just one way of doing things", the same is true with
networking and file I/O...
--
Matthew
--
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/a344faad-d61a-4a42-a66c-1067a48df617%40gmail.com.
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Thu, 7 Jun 2018 09:26:36 +0100
Raw View
--000000000000609703056e090b34
Content-Type: text/plain; charset="UTF-8"
On Wed, 6 Jun 2018 at 17:07, Rene Rivera <grafikrobot@gmail.com> wrote:
> On Wed, Jun 6, 2018 at 11:04 AM, Richard Hodges <hodges.r@gmail.com>
> wrote:
>
>>
>>
>> On Wed, 6 Jun 2018 at 16:57, Rene Rivera <grafikrobot@gmail.com> wrote:
>>
>>> On Wed, Jun 6, 2018 at 10:39 AM, Richard Hodges <hodges.r@gmail.com>
>>> wrote:
>>>
>>>> > The 3 major platforms (Windows, OS X, Linux) do not even agree on a
>>>> particular API.
>>>>
>>>> Actually they do. If you want to write portable 3D graphics you use
>>>> OpenGL and not Direct3d.
>>>>
>>>
>>> With the recent news from Apple that is clearly not the case. More and
>>> more software is moving to the newer, and fragmented, rendering APIs. So I
>>> think saying they do not agree on a particular rendering API is a
>>> reasonably accurate statement.
>>>
>>
>> I'm not saying you're wrong. Have I been misled by this?
>>
>> "OpenGL is the foundation for hardware-accelerated graphics in macOS."
>>
>> source: https://developer.apple.com/opengl/
>>
>
> From <https://developer.apple.com/macos/whats-new/>
>
> "Apps built using OpenGL and OpenCL will continue to run in macOS 10.14,
> but these legacy technologies are deprecated in macOS 10.14. Games and
> graphics-intensive apps that use OpenGL should now adopt Metal. Similarly,
> apps that use OpenCL for computational tasks should now adopt Metal and
> Metal Performance Shaders."
>
>
Ah I see. It's a swift/obj-c wrapper around opengl and opencl.
All the more reason for an international c++ standard for 3d graphics IMHO
(even if separate or an optional appendix to the isocpp standard). Now we
have *yet another* half-baked unilateral attempt to prevent developers from
writing portable applications.
A pox on these software giants.
>
> --
> -- Rene Rivera
> -- Grafik - Don't Assume Anything
> -- Robot Dreams - http://robot-dreams.net
>
> --
> 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/CAHEh_Gh%3DNv9%2Bo01%2BauyjB2rrHuxAqdipZH-HiN9-yKKqRP6LcQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_Gh%3DNv9%2Bo01%2BauyjB2rrHuxAqdipZH-HiN9-yKKqRP6LcQ%40mail.gmail.com?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/CALvx3haLuG6PsQ4dCzXzMmxstaxsBEqHzwXXsczCxj9BCYfxag%40mail.gmail.com.
--000000000000609703056e090b34
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed=
, 6 Jun 2018 at 17:07, Rene Rivera <<a href=3D"mailto:grafikrobot@gmail.=
com">grafikrobot@gmail.com</a>> wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e">On Wed, Jun 6, 2018 at 11:04 AM, Richard Hodges <span dir=3D"ltr"><<a=
href=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a=
>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"ltr"><br><br><div class=3D"gmail_quote"><span class=3D"m_-5926614=
374718101122gmail-"><div dir=3D"ltr">On Wed, 6 Jun 2018 at 16:57, Rene Rive=
ra <<a href=3D"mailto:grafikrobot@gmail.com" target=3D"_blank">grafikrob=
ot@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail=
_quote">On Wed, Jun 6, 2018 at 10:39 AM, Richard Hodges <span dir=3D"ltr">&=
lt;<a href=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.c=
om</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr"><span>>=C2=A0<span style=3D"color:rgb(34,34,34);font=
-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:=
normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-=
align:start;text-indent:0px;text-transform:none;white-space:normal;word-spa=
cing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;te=
xt-decoration-color:initial;float:none;display:inline">The 3 major platform=
s (Windows, OS X, Linux) do not even agree on a particular API.</span><div>=
<span style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;fo=
nt-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font=
-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-tra=
nsform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,25=
5,255);text-decoration-style:initial;text-decoration-color:initial;float:no=
ne;display:inline"><br></span></div></span><div><span style=3D"color:rgb(34=
,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-varian=
t-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:=
normal;text-align:start;text-indent:0px;text-transform:none;white-space:nor=
mal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-styl=
e:initial;text-decoration-color:initial;float:none;display:inline">Actually=
they do. If you want to write portable 3D graphics you use OpenGL and not =
Direct3d.</span></div></div></blockquote><div><br></div><div>With the recen=
t news from Apple that is clearly not the case. More and more software is m=
oving to the newer, and fragmented, rendering APIs. So I think saying they =
do not agree on a particular rendering API is a reasonably accurate stateme=
nt.</div></div></div></div></blockquote><div><br></div></span><div>I'm =
not saying you're wrong. Have I been misled by this?</div><div><br></di=
v><div>"OpenGL is the foundation for hardware-accelerated graphics in =
macOS."</div><div><br></div><div>source:=C2=A0<a href=3D"https://devel=
oper.apple.com/opengl/" target=3D"_blank">https://developer.apple.com/openg=
l/</a></div></div></div></blockquote><div><br></div><div>From <<a href=
=3D"https://developer.apple.com/macos/whats-new/" target=3D"_blank">https:/=
/developer.apple.com/macos/whats-new/</a>></div><div><br></div><div>&quo=
t;Apps built using OpenGL and OpenCL will continue to run in macOS 10.14, b=
ut these legacy technologies are deprecated in macOS 10.14. Games and graph=
ics-intensive apps that use OpenGL should now adopt Metal. Similarly, apps =
that use OpenCL for computational tasks should now adopt Metal and Metal Pe=
rformance Shaders."</div><div><br></div></div></div></div></blockquote=
><div><br></div><div>Ah I see. It's a swift/obj-c wrapper around opengl=
and opencl.</div><div><br></div><div>All the more reason for an internatio=
nal c++ standard for 3d graphics IMHO (even if separate or an optional appe=
ndix to the isocpp standard). Now we have *yet another* half-baked unilater=
al attempt to prevent developers from writing portable applications.</div><=
div><br></div><div>A pox on these software giants.</div><div><br></div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"=
gmail_extra"><div class=3D"gmail_quote"><div></div></div><div><br></div>-- =
<br><div class=3D"m_-5926614374718101122gmail_signature"><div dir=3D"ltr"><=
div><div dir=3D"ltr">-- Rene Rivera<br>-- Grafik - Don't Assume Anythin=
g<br>-- Robot Dreams -=C2=A0<a href=3D"http://robot-dreams.net/" target=3D"=
_blank">http://robot-dreams.net</a><br><br></div></div></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" 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@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHEh_Gh%3DNv9%2Bo01%2BauyjB2rrHuxAqd=
ipZH-HiN9-yKKqRP6LcQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAHEh_Gh%3DNv9%2Bo01%2BauyjB2rrHuxAqdipZH-HiN9-yKKqRP6LcQ%40mail=
..gmail.com</a>.<br>
</blockquote></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3haLuG6PsQ4dCzXzMmxstaxsBEqHzwXX=
sczCxj9BCYfxag%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3haLuG6PsQ4d=
CzXzMmxstaxsBEqHzwXXsczCxj9BCYfxag%40mail.gmail.com</a>.<br />
--000000000000609703056e090b34--
.
Author: yakitori1010@gmail.com
Date: Sat, 11 Aug 2018 18:19:48 -0700 (PDT)
Raw View
------=_Part_1157_1461210641.1534036788119
Content-Type: multipart/alternative;
boundary="----=_Part_1158_49404780.1534036788119"
------=_Part_1158_49404780.1534036788119
Content-Type: text/plain; charset="UTF-8"
hello.
i think anti paper is hateful.
thay look down the game programmer.
game programmer is make economy.
but as i think the 2d paper is too big.
they refer to bad model as GDI+.
i think the paper is near the GDI+.
who want to service the brush,path,matrix.
i need two and one.
Window IO.Surface Spec. and Parameter defines.
other is make by self and others.
why force the full carry at first time by like ms.
why need Surface? it is for doublebuffering and imaging.
imaging is the factory method create to surface.
the surface dispatch to display to done.
if surface spec is nothing. to self refresh the window.
it is very slow in now age.
why not font?
the system defined font system is greater soluton.
but it is finaly pixel.not need Spec on standard.i know it is useful.
last.
i need 2d graphics for my task.
but they drop thinking point.
need more discussion.
--
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/3217c680-4cf2-4098-8512-dde3347bef79%40isocpp.org.
------=_Part_1158_49404780.1534036788119
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>hello.</div><div><br></div><div>i think anti paper is=
hateful.</div><div>thay look down the game programmer.</div><div>game prog=
rammer is make economy.</div><div>but as i think the 2d paper is too big.</=
div><div>they refer to bad model as GDI+.</div><div>i think the paper is ne=
ar the GDI+.</div><div>who want to service the brush,path,matrix.</div><div=
>i need two and one.</div><div>Window IO.Surface Spec. and Parameter define=
s.</div><div>other is make by self and others.</div><div>why force the full=
carry at first time by like ms.</div><div><br></div><div>why need Surface?=
it is for doublebuffering and imaging.</div><div>imaging is the factory me=
thod create to surface.</div><div>the surface dispatch to display to done.<=
/div><div>if surface spec is nothing. to self refresh the window.</div><div=
>it is very slow in now age.</div><div><br></div><div>why not font?</div><d=
iv>the system defined font system is greater soluton.</div><div>but it is f=
inaly pixel.not need Spec on standard.i know it is useful.</div><div><br></=
div><div>last.</div><div>i need 2d graphics for my task.</div><div>but they=
drop thinking point.</div><div>need more discussion.</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3217c680-4cf2-4098-8512-dde3347bef79%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3217c680-4cf2-4098-8512-dde3347bef79=
%40isocpp.org</a>.<br />
------=_Part_1158_49404780.1534036788119--
------=_Part_1157_1461210641.1534036788119--
.
Author: Rene Rivera <grafikrobot@gmail.com>
Date: Sat, 11 Aug 2018 21:20:11 -0500
Raw View
--00000000000076e44d0573339e1e
Content-Type: text/plain; charset="UTF-8"
On Sat, Aug 11, 2018 at 8:19 PM <yakitori1010@gmail.com> wrote:
> hello.
>
> i think anti paper is hateful.
> thay look down the game programmer.
>
Speaking as a game programmer I can say I did not get the impression of the
paper being hateful to anyone, especially game programmers. In the contrary
it seems to go out of it's way to take into consideration the concerns of
game programmers and others.
> last.
> i need 2d graphics for my task.
>
I don't doubt it. But do none of existing 2d libraries satisfy your
requirement?
--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
--
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/CAHEh_Giw77e%3Daz_dr0N%2BfySwyXyb00CroNU_O%3DuCFfztksbNSA%40mail.gmail.com.
--00000000000076e44d0573339e1e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug 11=
, 2018 at 8:19 PM <<a href=3D"mailto:yakitori1010@gmail.com">yakitori101=
0@gmail.com</a>> wrote:<br></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>hello.</div><div><br></div><div>i think anti paper is hateful=
..</div><div>thay look down the game programmer.</div></div></blockquote><di=
v><br></div><div>Speaking as a game programmer I can say I did not get the =
impression of the paper being hateful to anyone, especially game programmer=
s. In the contrary it seems to go out of it's way to take into consider=
ation the concerns of game programmers and others.</div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>last.<br></div><div>i ne=
ed 2d graphics for my task.</div></div></blockquote><div><br></div><div>I d=
on't doubt it. But do none of existing 2d libraries satisfy your requir=
ement?</div><div><br></div></div>-- <br><div dir=3D"ltr" class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=
=3D"ltr">-- Rene Rivera<br>-- Grafik - Don't Assume Anything<br>-- Robo=
t Dreams -=C2=A0<a href=3D"http://robot-dreams.net/" target=3D"_blank">http=
://robot-dreams.net</a><br><br></div></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" 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/CAHEh_Giw77e%3Daz_dr0N%2BfySwyXyb00Cr=
oNU_O%3DuCFfztksbNSA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_Giw77=
e%3Daz_dr0N%2BfySwyXyb00CroNU_O%3DuCFfztksbNSA%40mail.gmail.com</a>.<br />
--00000000000076e44d0573339e1e--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Sun, 12 Aug 2018 11:46:07 +0200
Raw View
--000000000000426820057339d9f4
Content-Type: text/plain; charset="UTF-8"
On Sun, 12 Aug 2018 at 04:20, Rene Rivera <grafikrobot@gmail.com> wrote:
> On Sat, Aug 11, 2018 at 8:19 PM <yakitori1010@gmail.com> wrote:
>
>> hello.
>>
>> i think anti paper is hateful.
>> thay look down the game programmer.
>>
>
> Speaking as a game programmer I can say I did not get the impression of
> the paper being hateful to anyone, especially game programmers. In the
> contrary it seems to go out of it's way to take into consideration the
> concerns of game programmers and others.
>
>
>> last.
>> i need 2d graphics for my task.
>>
>
> I don't doubt it. But do none of existing 2d libraries satisfy your
> requirement?
>
I think this the crux of it.
Of course the obvious answer is "yes". There are many fantastic graphics
libraries...
....and after spending 2 weeks of one's life trying to get them to compile
and run on all the platforms you want to support (because we all want to
write cross-platform software, right?) most of us lose the will to live and
go back to our horrible but reliable jobs not programming games.
Standardising platform I/O - including graphics, consoles, keyboards, mice
and sound etc - would put the onus on the compiler-writing community to
solve this once for each platform, with the benefits being fanned out to
the global developer community. This is an O(1) solution in terms of
man-hours.
The current situation is that a million developers must solve the same
infuriating problems a million times, and they must do it every time a
library or a compiler suite goes through a version increment. This is at
best O(N).
In terms of lost man-hours alone, there is no possible argument that can be
made against standardisation of tools and libraries.
> --
> -- Rene Rivera
> -- Grafik - Don't Assume Anything
> -- Robot Dreams - http://robot-dreams.net
>
> --
> 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/CAHEh_Giw77e%3Daz_dr0N%2BfySwyXyb00CroNU_O%3DuCFfztksbNSA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_Giw77e%3Daz_dr0N%2BfySwyXyb00CroNU_O%3DuCFfztksbNSA%40mail.gmail.com?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/CALvx3haAgHkWMb3Y-St-VN%2BDzsp6dUP61WHSs7extgG7RJ5qAQ%40mail.gmail.com.
--000000000000426820057339d9f4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sun=
, 12 Aug 2018 at 04:20, Rene Rivera <<a href=3D"mailto:grafikrobot@gmail=
..com">grafikrobot@gmail.com</a>> wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat=
, Aug 11, 2018 at 8:19 PM <<a href=3D"mailto:yakitori1010@gmail.com" tar=
get=3D"_blank">yakitori1010@gmail.com</a>> wrote:<br></div><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"><div>hello.</div><div><br></div><div>i t=
hink anti paper is hateful.</div><div>thay look down the game programmer.</=
div></div></blockquote><div><br></div><div>Speaking as a game programmer I =
can say I did not get the impression of the paper being hateful to anyone, =
especially game programmers. In the contrary it seems to go out of it's=
way to take into consideration the concerns of game programmers and others=
..</div><div>=C2=A0</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"><di=
v>last.<br></div><div>i need 2d graphics for my task.</div></div></blockquo=
te><div><br></div><div>I don't doubt it. But do none of existing 2d lib=
raries satisfy your requirement?</div></div></div></blockquote><div><br></d=
iv><div>I think this the crux of it.</div><div><br></div><div>Of course the=
obvious answer is "yes". There are many fantastic graphics libra=
ries...</div><div><br></div><div>...and after spending 2 weeks of one's=
life trying to get them to compile and run on all the platforms you want t=
o support (because we all want to write cross-platform software, right?) mo=
st of us lose the will to live and go back to our horrible but reliable job=
s not programming games.</div><div><br></div><div>Standardising platform I/=
O - including graphics, consoles, keyboards, mice and sound etc - would put=
the onus on the compiler-writing community to solve this once for each pla=
tform, with the benefits being fanned out to the global developer community=
.. This is an O(1) solution in terms of man-hours.</div><div><br></div><div>=
The current situation is that a million developers must solve the same infu=
riating problems a million times, and they must do it every time a library =
or a compiler suite goes through a version increment. This is at best O(N).=
</div><div><br></div><div>In terms of lost man-hours alone, there is no pos=
sible argument that can be made against standardisation of tools and librar=
ies.</div><div>=C2=A0<br></div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div class=3D"gmail_quote"><div><br></div></div>-- <br><=
div dir=3D"ltr" class=3D"m_-4141836092543651799gmail_signature" data-smartm=
ail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr">-- Rene Rive=
ra<br>-- Grafik - Don't Assume Anything<br>-- Robot Dreams -=C2=A0<a hr=
ef=3D"http://robot-dreams.net/" target=3D"_blank">http://robot-dreams.net</=
a><br><br></div></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" 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@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHEh_Giw77e%3Daz_dr0N%2BfySwyXyb00Cr=
oNU_O%3DuCFfztksbNSA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAHEh_Giw77e%3Daz_dr0N%2BfySwyXyb00CroNU_O%3DuCFfztksbNSA%40mail=
..gmail.com</a>.<br>
</blockquote></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3haAgHkWMb3Y-St-VN%2BDzsp6dUP61W=
HSs7extgG7RJ5qAQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3haAgHkWMb=
3Y-St-VN%2BDzsp6dUP61WHSs7extgG7RJ5qAQ%40mail.gmail.com</a>.<br />
--000000000000426820057339d9f4--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 12 Aug 2018 07:59:06 -0700 (PDT)
Raw View
------=_Part_1257_903006579.1534085946725
Content-Type: multipart/alternative;
boundary="----=_Part_1258_15418216.1534085946726"
------=_Part_1258_15418216.1534085946726
Content-Type: text/plain; charset="UTF-8"
On Sunday, August 12, 2018 at 5:46:20 AM UTC-4, Richard Hodges wrote:
>
> On Sun, 12 Aug 2018 at 04:20, Rene Rivera <grafi...@gmail.com
> <javascript:>> wrote:
>
>> On Sat, Aug 11, 2018 at 8:19 PM <yakito...@gmail.com <javascript:>>
>> wrote:
>>
>>> hello.
>>>
>>> i think anti paper is hateful.
>>> thay look down the game programmer.
>>>
>>
>> Speaking as a game programmer I can say I did not get the impression of
>> the paper being hateful to anyone, especially game programmers. In the
>> contrary it seems to go out of it's way to take into consideration the
>> concerns of game programmers and others.
>>
>>
>>> last.
>>> i need 2d graphics for my task.
>>>
>>
>> I don't doubt it. But do none of existing 2d libraries satisfy your
>> requirement?
>>
>
> I think this the crux of it.
>
> Of course the obvious answer is "yes". There are many fantastic graphics
> libraries...
>
> ...and after spending 2 weeks of one's life trying to get them to compile
> and run on all the platforms you want to support (because we all want to
> write cross-platform software, right?) most of us lose the will to live and
> go back to our horrible but reliable jobs not programming games.
>
So the problem has nothing to do with its appropriateness for the standard
library. It's the fact that C++ has a terrible build/package environment.
If you could download and use other libraries more easily, then you
wouldn't need it to be in the standard library at all. We should not adopt
standard library components primarily because C++ has a terrible
build/package environment.
Also, we are used to standard libraries being fast, high-performance tools.
Containers, algorithms, these are usually well-optimized stuff in standard
library implementations. So people tend to instinctively assume that the
standard library's implementation of the graphics proposal would be equally
high quality.
So let's compare the quality of other high-level stuff in the standard
library. Iostreams is pretty notorious for bad performance. People always
blame iostream's performance primarily on its interface, the many virtual
functions and the need for locale support. So maybe we can excuse it as
being as good as iostreams' design allows.
But what about Regex? From what I've gathered from others, most standard
library regex implementations perform poorly. Boost.Regex is frequently
much faster <https://stackoverflow.com/a/50611867/734069>, despite having
virtually identical interfaces to `std::regex`. Here, there's no question;
this is pure QoI, and the standard libraries aren't providing it. Despite
having had a over decade to do so (regex was part of TR1, after all).
What that tells me is that standard library implementers just don't care
about higher-level stuff. Oh, they'll tick the feature box on their list of
what the compiler supports. But unless big name users of their platforms
*make* them optimize these things, they will not. And most big name users
of C++ platforms aren't interested in using these high level tools. If you
have a big C++ project and you needed regular expressions, you use some
library. If `std::regex` didn't provide equivalent performance to that
library, you ignored it.
2D graphics would be in an even worse position. There are plenty of
applications that just don't care about graphics or are perfectly happy
with their existing solutions. They are not going to start using this
unknown standard library component. And if they don't start using it,
implementers will not start optimizing it.
It's a vicious cycle.
So in the end, what you would have is an easy-to-install but terribly
performing tool. If you want to make little toy or learning applications,
it's fine. You can make Tetris or Pac-Man with that (though both of those
require text rendering, which the graphics TS did not have). But you would
not be able to use it to make any kind of 2D game where performance
actually matters. So if you're serious about making a 2D game, you will
eventually have to go do the work to install that library.
So who exactly would be helped by adding a standard library component that
pretends to offer a solution, but if you're actually serious about that
domain, you'll have to ditch for something real? Again, iostreams offers
the perfect example of this sort of thing. You don't tend to see it get
used in high-performance applications (which is ultimately what C++ is
for), and you can't really blame people for that.
Why do we need to spend a huge amount of time to standardize the new
terrible standard library component that nobody uses? Best to nip it in the
bud before spending that time.
Standardising platform I/O - including graphics, consoles, keyboards, mice
> and sound etc - would put the onus on the compiler-writing community to
> solve this once for each platform, with the benefits being fanned out to
> the global developer community. This is an O(1) solution in terms of
> man-hours.
>
> The current situation is that a million developers must solve the same
> infuriating problems a million times, and they must do it every time a
> library or a compiler suite goes through a version increment. This is at
> best O(N).
>
> In terms of lost man-hours alone, there is no possible argument that can
> be made against standardisation of tools and libraries.
>
I'm not sure what "N" represents here (number of platforms, number of
libraries, number of GPUs? And it's not like there's only one standard
library implementation, or even one per-platform), but it doesn't really
matter. The analysis is flawed in that it assumes that all man hours are
equal.
Performance graphics is a specialty field. As such, there's going to be a
significant quality difference from a graphics library written by people
who spend most of their time optimizing the usual C++ code and a graphics
library written by people who actually know graphics.
Sure, more people will be investing more time in competing 2D graphics
libraries overall. But the quality of those libraries will be better.
They're written by people who (presumably) know what they're doing. And if
they aren't, then they will be out-competed by those who do.
In a perfect world, maybe the standard library vendors would produce work
of equivalent quality. But the C++ world is not, and will never be,
perfect. Best to improve the good and mitigate the bad.
--
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/d0b57f4a-3e3d-4ddd-8511-ef9334ebd76f%40isocpp.org.
------=_Part_1258_15418216.1534085946726
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, August 12, 2018 at 5:46:20 AM UTC-4, Richard Ho=
dges 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"><d=
iv class=3D"gmail_quote"><div dir=3D"ltr">On Sun, 12 Aug 2018 at 04:20, Ren=
e Rivera <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"ABsQNCHRDQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascr=
ipt:';return true;" onclick=3D"this.href=3D'javascript:';return=
true;">grafi...@gmail.com</a>> wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat,=
Aug 11, 2018 at 8:19 PM <<a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"ABsQNCHRDQAJ" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D'javascript:';return true;" onclick=3D"this.href=3D'javascr=
ipt:';return true;">yakito...@gmail.com</a>> wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div>hello.</div><div><br></div><d=
iv>i think anti paper is hateful.</div><div>thay look down the game program=
mer.</div></div></blockquote><div><br></div><div>Speaking as a game program=
mer I can say I did not get the impression of the paper being hateful to an=
yone, especially game programmers. In the contrary it seems to go out of it=
's way to take into consideration the concerns of game programmers and =
others.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div>last.<br></div><div>i need 2d graphics for my task.</div></div></bl=
ockquote><div><br></div><div>I don't doubt it. But do none of existing =
2d libraries satisfy your requirement?</div></div></div></blockquote><div><=
br></div><div>I think this the crux of it.</div><div><br></div><div>Of cour=
se the obvious answer is "yes". There are many fantastic graphics=
libraries...</div><div><br></div><div>...and after spending 2 weeks of one=
's life trying to get them to compile and run on all the platforms you =
want to support (because we all want to write cross-platform software, righ=
t?) most of us lose the will to live and go back to our horrible but reliab=
le jobs not programming games.</div></div></div></blockquote><div><br></div=
><div>So the problem has nothing to do with its appropriateness for the sta=
ndard library. It's the fact that C++ has a terrible build/package envi=
ronment. If you could download and use other libraries more easily, then yo=
u wouldn't need it to be in the standard library at all. We should not =
adopt standard library components primarily because C++ has a terrible buil=
d/package environment.<br></div><div><br></div><div>Also, we are used to st=
andard libraries being fast, high-performance tools. Containers, algorithms=
, these are usually well-optimized stuff in standard library implementation=
s. So people tend to instinctively assume that the standard library's i=
mplementation of the graphics proposal would be equally high quality.</div>=
<div><br></div><div>So let's compare the quality of other high-level st=
uff in the standard library. Iostreams is pretty notorious for bad performa=
nce. People always blame iostream's performance primarily on its interf=
ace, the many virtual functions and the need for locale support. So maybe w=
e can excuse it as being as good as iostreams' design allows.<br></div>=
<div><br></div><div>But what about Regex? From what I've gathered from =
others, most standard library regex implementations perform poorly. <a href=
=3D"https://stackoverflow.com/a/50611867/734069">Boost.Regex is frequently =
much faster</a>, despite having virtually identical interfaces to `std::reg=
ex`. Here, there's no question; this is pure QoI, and the standard libr=
aries aren't providing it. Despite having had a over decade to do so (r=
egex was part of TR1, after all).<br></div><div><br></div><div>What that te=
lls me is that standard library implementers just don't care about high=
er-level stuff. Oh, they'll tick the feature box on their list of what =
the compiler supports. But unless big name users of their platforms <i>make=
</i> them optimize these things, they will not. And most big name users of =
C++ platforms aren't interested in using these high level tools. If you=
have a big C++ project and you needed regular expressions, you use some li=
brary. If `std::regex` didn't provide equivalent performance to that li=
brary, you ignored it.</div><div><br></div><div>2D graphics would be in an =
even worse position. There are plenty of applications that just don't c=
are about graphics or are perfectly happy with their existing solutions. Th=
ey are not going to start using this unknown standard library component. An=
d if they don't start using it, implementers will not start optimizing =
it.</div><div><br></div><div>It's a vicious cycle.<br></div><div><br></=
div><div>So in the end, what you would have is an easy-to-install but terri=
bly performing tool. If you want to make little toy or learning application=
s, it's fine. You can make Tetris or Pac-Man with that (though both of =
those require text rendering, which the graphics TS did not have). But you =
would not be able to use it to make any kind of 2D game where performance a=
ctually matters. So if you're serious about making a 2D game, you will =
eventually have to go do the work to install that library.</div><div><br></=
div><div>So who exactly would be helped by adding a standard library compon=
ent that pretends to offer a solution, but if you're actually serious a=
bout that domain, you'll have to ditch for something real? Again, iostr=
eams offers the perfect example of this sort of thing. You don't tend t=
o see it get used in high-performance applications (which is ultimately wha=
t C++ is for), and you can't really blame people for that.</div><div><b=
r></div><div>Why do we need to spend a huge amount of time to standardize t=
he new terrible standard library component that nobody uses? Best to nip it=
in the bud before spending that time.<br></div><br><div></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 class=3D"gmail_quote=
"><div></div><div>Standardising platform I/O - including graphics, consoles=
, keyboards, mice and sound etc - would put the onus on the compiler-writin=
g community to solve this once for each platform, with the benefits being f=
anned out to the global developer community. This is an O(1) solution in te=
rms of man-hours. <br></div></div></div></blockquote><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 class=3D"gmail_quote"><div><br=
></div><div>The current situation is that a million developers must solve t=
he same infuriating problems a million times, and they must do it every tim=
e a library or a compiler suite goes through a version increment. This is a=
t best O(N).</div></div></div></blockquote><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></div></blockquote><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><div class=3D"gmail_quote"><div></=
div><div>In terms of lost man-hours alone, there is no possible argument th=
at can be made against standardisation of tools and libraries.</div></div><=
/div></blockquote><div><br></div><div>I'm not sure what "N" r=
epresents here (number of platforms, number of libraries, number of GPUs? A=
nd it's not like there's only one standard library implementation, =
or even one per-platform), but it doesn't really matter. The analysis i=
s flawed in that it assumes that all man hours are equal.</div><div><br></d=
iv><div>Performance graphics is a specialty field. As such, there's goi=
ng to be a significant quality difference from a graphics library written b=
y people who spend most of their time optimizing the usual C++ code and a g=
raphics library written by people who actually know graphics.</div><div><br=
></div><div>Sure, more people will be investing more time in competing 2D g=
raphics libraries overall. But the quality of those libraries will be bette=
r. They're written by people who (presumably) know what they're doi=
ng. And if they aren't, then they will be out-competed by those who do.=
</div><div><br></div><div>In a perfect world, maybe the standard library ve=
ndors would produce work of equivalent quality. But the C++ world is not, a=
nd will never be, perfect. Best to improve the good and mitigate the bad.<b=
r></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d0b57f4a-3e3d-4ddd-8511-ef9334ebd76f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d0b57f4a-3e3d-4ddd-8511-ef9334ebd76f=
%40isocpp.org</a>.<br />
------=_Part_1258_15418216.1534085946726--
------=_Part_1257_903006579.1534085946725--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Sun, 12 Aug 2018 18:40:23 +0200
Raw View
--000000000000c179ff05733fa2a3
Content-Type: text/plain; charset="UTF-8"
On Sun, 12 Aug 2018 at 16:59, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Sunday, August 12, 2018 at 5:46:20 AM UTC-4, Richard Hodges wrote:
>>
>> On Sun, 12 Aug 2018 at 04:20, Rene Rivera <grafi...@gmail.com> wrote:
>>
>>> On Sat, Aug 11, 2018 at 8:19 PM <yakito...@gmail.com> wrote:
>>>
>>>> hello.
>>>>
>>>> i think anti paper is hateful.
>>>> thay look down the game programmer.
>>>>
>>>
>>> Speaking as a game programmer I can say I did not get the impression of
>>> the paper being hateful to anyone, especially game programmers. In the
>>> contrary it seems to go out of it's way to take into consideration the
>>> concerns of game programmers and others.
>>>
>>>
>>>> last.
>>>> i need 2d graphics for my task.
>>>>
>>>
>>> I don't doubt it. But do none of existing 2d libraries satisfy your
>>> requirement?
>>>
>>
>> I think this the crux of it.
>>
>> Of course the obvious answer is "yes". There are many fantastic graphics
>> libraries...
>>
>> ...and after spending 2 weeks of one's life trying to get them to compile
>> and run on all the platforms you want to support (because we all want to
>> write cross-platform software, right?) most of us lose the will to live and
>> go back to our horrible but reliable jobs not programming games.
>>
>
> So the problem has nothing to do with its appropriateness for the standard
> library. It's the fact that C++ has a terrible build/package environment.
> If you could download and use other libraries more easily, then you
> wouldn't need it to be in the standard library at all. We should not adopt
> standard library components primarily because C++ has a terrible
> build/package environment.
>
> Also, we are used to standard libraries being fast, high-performance
> tools. Containers, algorithms, these are usually well-optimized stuff in
> standard library implementations. So people tend to instinctively assume
> that the standard library's implementation of the graphics proposal would
> be equally high quality.
>
> So let's compare the quality of other high-level stuff in the standard
> library. Iostreams is pretty notorious for bad performance. People always
> blame iostream's performance primarily on its interface, the many virtual
> functions and the need for locale support. So maybe we can excuse it as
> being as good as iostreams' design allows.
>
> But what about Regex? From what I've gathered from others, most standard
> library regex implementations perform poorly. Boost.Regex is frequently
> much faster <https://stackoverflow.com/a/50611867/734069>, despite having
> virtually identical interfaces to `std::regex`. Here, there's no question;
> this is pure QoI, and the standard libraries aren't providing it. Despite
> having had a over decade to do so (regex was part of TR1, after all).
>
> What that tells me is that standard library implementers just don't care
> about higher-level stuff. Oh, they'll tick the feature box on their list of
> what the compiler supports. But unless big name users of their platforms
> *make* them optimize these things, they will not. And most big name users
> of C++ platforms aren't interested in using these high level tools. If you
> have a big C++ project and you needed regular expressions, you use some
> library. If `std::regex` didn't provide equivalent performance to that
> library, you ignored it.
>
HTTP and HTML are standards. Vendors fought a vicious war over 20 years to
ensure that they had the "best" implementations. The result is an extremely
functional internet. Standards are only good.
>
> 2D graphics would be in an even worse position. There are plenty of
> applications that just don't care about graphics or are perfectly happy
> with their existing solutions. They are not going to start using this
> unknown standard library component. And if they don't start using it,
> implementers will not start optimizing it.
>
> It's a vicious cycle.
>
> So in the end, what you would have is an easy-to-install but terribly
> performing tool. If you want to make little toy or learning applications,
> it's fine. You can make Tetris or Pac-Man with that (though both of those
> require text rendering, which the graphics TS did not have). But you would
> not be able to use it to make any kind of 2D game where performance
> actually matters. So if you're serious about making a 2D game, you will
> eventually have to go do the work to install that library.
>
> So who exactly would be helped by adding a standard library component that
> pretends to offer a solution, but if you're actually serious about that
> domain, you'll have to ditch for something real? Again, iostreams offers
> the perfect example of this sort of thing. You don't tend to see it get
> used in high-performance applications (which is ultimately what C++ is
> for), and you can't really blame people for that.
>
> Why do we need to spend a huge amount of time to standardize the new
> terrible standard library component that nobody uses? Best to nip it in the
> bud before spending that time.
>
> Standardising platform I/O - including graphics, consoles, keyboards, mice
>> and sound etc - would put the onus on the compiler-writing community to
>> solve this once for each platform, with the benefits being fanned out to
>> the global developer community. This is an O(1) solution in terms of
>> man-hours.
>>
>
>> The current situation is that a million developers must solve the same
>> infuriating problems a million times, and they must do it every time a
>> library or a compiler suite goes through a version increment. This is at
>> best O(N).
>>
>
>> In terms of lost man-hours alone, there is no possible argument that can
>> be made against standardisation of tools and libraries.
>>
>
> I'm not sure what "N" represents here (number of platforms, number of
> libraries, number of GPUs? And it's not like there's only one standard
> library implementation, or even one per-platform), but it doesn't really
> matter. The analysis is flawed in that it assumes that all man hours are
> equal.
>
N is the number of teams who need to use a graphics library. At the moment,
every single one must figure out how to select, compile, patch, bugfix
(because, you know, open source) and figure out why a given library works
on one platform and not another. This is an utter waste of time.
I agree that packaging is a massive problem for c++, indeed its biggest
problem. I have some ideas on how to address that, and will be starting a
project to that effect once the Summer is over. In my view there is no
excuse for things refusing to "just work".
>
> Performance graphics is a specialty field. As such, there's going to be a
> significant quality difference from a graphics library written by people
> who spend most of their time optimizing the usual C++ code and a graphics
> library written by people who actually know graphics.
>
> Sure, more people will be investing more time in competing 2D graphics
> libraries overall. But the quality of those libraries will be better.
> They're written by people who (presumably) know what they're doing. And if
> they aren't, then they will be out-competed by those who do.
>
If these competing libraries are mandated to support a standard interface,
selection and retrofitting becomes a non-issue. You simply test and choose
the most suitable conforming implementation. In this case, standards do
nothing but good. Standards are why computers and operating systems can
talk to each other regardless of the machiavellian natures of their
manufacturers.
>
> In a perfect world, maybe the standard library vendors would produce work
> of equivalent quality. But the C++ world is not, and will never be,
> perfect. Best to improve the good and mitigate the bad.
>
I say we should focus on building the perfect world. And we should build in
ways to allow good vendors to profit from excellence.
> --
> 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/d0b57f4a-3e3d-4ddd-8511-ef9334ebd76f%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d0b57f4a-3e3d-4ddd-8511-ef9334ebd76f%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/CALvx3hb1y9hhMLBFpPZ0%3DgJ_zzU0qJMzsktB146ASOthYxwb5A%40mail.gmail.com.
--000000000000c179ff05733fa2a3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sun=
, 12 Aug 2018 at 16:59, Nicol Bolas <<a href=3D"mailto:jmckesson@gmail.c=
om">jmckesson@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr">On Sunday, August 12, 2018 at 5:46:20 AM UTC-4, Richar=
d Hodges 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"><di=
v class=3D"gmail_quote"><div dir=3D"ltr">On Sun, 12 Aug 2018 at 04:20, Rene=
Rivera <<a rel=3D"nofollow">grafi...@gmail.com</a>> wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote">=
<div dir=3D"ltr">On Sat, Aug 11, 2018 at 8:19 PM <<a rel=3D"nofollow">ya=
kito...@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div>hello.</div><div><br></div><div>i think anti paper is h=
ateful.</div><div>thay look down the game programmer.</div></div></blockquo=
te><div><br></div><div>Speaking as a game programmer I can say I did not ge=
t the impression of the paper being hateful to anyone, especially game prog=
rammers. In the contrary it seems to go out of it's way to take into co=
nsideration the concerns of game programmers and others.</div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>last.<br></div><di=
v>i need 2d graphics for my task.</div></div></blockquote><div><br></div><d=
iv>I don't doubt it. But do none of existing 2d libraries satisfy your =
requirement?</div></div></div></blockquote><div><br></div><div>I think this=
the crux of it.</div><div><br></div><div>Of course the obvious answer is &=
quot;yes". There are many fantastic graphics libraries...</div><div><b=
r></div><div>...and after spending 2 weeks of one's life trying to get =
them to compile and run on all the platforms you want to support (because w=
e all want to write cross-platform software, right?) most of us lose the wi=
ll to live and go back to our horrible but reliable jobs not programming ga=
mes.</div></div></div></blockquote><div><br></div><div>So the problem has n=
othing to do with its appropriateness for the standard library. It's th=
e fact that C++ has a terrible build/package environment. If you could down=
load and use other libraries more easily, then you wouldn't need it to =
be in the standard library at all. We should not adopt standard library com=
ponents primarily because C++ has a terrible build/package environment.<br>=
</div><div><br></div><div>Also, we are used to standard libraries being fas=
t, high-performance tools. Containers, algorithms, these are usually well-o=
ptimized stuff in standard library implementations. So people tend to insti=
nctively assume that the standard library's implementation of the graph=
ics proposal would be equally high quality.</div><div><br></div><div>So let=
's compare the quality of other high-level stuff in the standard librar=
y. Iostreams is pretty notorious for bad performance. People always blame i=
ostream's performance primarily on its interface, the many virtual func=
tions and the need for locale support. So maybe we can excuse it as being a=
s good as iostreams' design allows.<br></div><div><br></div><div>But wh=
at about Regex? From what I've gathered from others, most standard libr=
ary regex implementations perform poorly. <a href=3D"https://stackoverflow.=
com/a/50611867/734069" target=3D"_blank">Boost.Regex is frequently much fas=
ter</a>, despite having virtually identical interfaces to `std::regex`. Her=
e, there's no question; this is pure QoI, and the standard libraries ar=
en't providing it. Despite having had a over decade to do so (regex was=
part of TR1, after all).<br></div><div><br></div><div>What that tells me i=
s that standard library implementers just don't care about higher-level=
stuff. Oh, they'll tick the feature box on their list of what the comp=
iler supports. But unless big name users of their platforms <i>make</i> the=
m optimize these things, they will not. And most big name users of C++ plat=
forms aren't interested in using these high level tools. If you have a =
big C++ project and you needed regular expressions, you use some library. I=
f `std::regex` didn't provide equivalent performance to that library, y=
ou ignored it.</div></div></blockquote><div><br></div><div>HTTP and HTML ar=
e standards. Vendors fought a vicious war over 20 years to ensure that they=
had the "best" implementations. The result is an extremely funct=
ional internet. Standards are only good.</div><div>=C2=A0</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><br></div><div>2D graphics would b=
e in an even worse position. There are plenty of applications that just don=
't care about graphics or are perfectly happy with their existing solut=
ions. They are not going to start using this unknown standard library compo=
nent. And if they don't start using it, implementers will not start opt=
imizing it.</div><div><br></div><div>It's a vicious cycle.<br></div><di=
v><br></div><div>So in the end, what you would have is an easy-to-install b=
ut terribly performing tool. If you want to make little toy or learning app=
lications, it's fine. You can make Tetris or Pac-Man with that (though =
both of those require text rendering, which the graphics TS did not have). =
But you would not be able to use it to make any kind of 2D game where perfo=
rmance actually matters. So if you're serious about making a 2D game, y=
ou will eventually have to go do the work to install that library.</div><di=
v><br></div><div>So who exactly would be helped by adding a standard librar=
y component that pretends to offer a solution, but if you're actually s=
erious about that domain, you'll have to ditch for something real? Agai=
n, iostreams offers the perfect example of this sort of thing. You don'=
t tend to see it get used in high-performance applications (which is ultima=
tely what C++ is for), and you can't really blame people for that.</div=
><div><br></div><div>Why do we need to spend a huge amount of time to stand=
ardize the new terrible standard library component that nobody uses? Best t=
o nip it in the bud before spending that time.<br></div><br><div></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_qu=
ote"><div></div><div>Standardising platform I/O - including graphics, conso=
les, keyboards, mice and sound etc - would put the onus on the compiler-wri=
ting community to solve this once for each platform, with the benefits bein=
g fanned out to the global developer community. This is an O(1) solution in=
terms of man-hours. <br></div></div></div></blockquote><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div><br=
></div><div>The current situation is that a million developers must solve t=
he same infuriating problems a million times, and they must do it every tim=
e a library or a compiler suite goes through a version increment. This is a=
t best O(N).</div></div></div></blockquote><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></div></blockquote><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div></div><div>In t=
erms of lost man-hours alone, there is no possible argument that can be mad=
e against standardisation of tools and libraries.</div></div></div></blockq=
uote><div><br></div><div>I'm not sure what "N" represents her=
e (number of platforms, number of libraries, number of GPUs? And it's n=
ot like there's only one standard library implementation, or even one p=
er-platform), but it doesn't really matter. The analysis is flawed in t=
hat it assumes that all man hours are equal.</div></div></blockquote><div><=
br></div><div>N is the number of teams who need to use a graphics library. =
At the moment, every single one must figure out how to select, compile, pat=
ch, bugfix (because, you know, open source) and figure out why a given libr=
ary works on one platform and not another. This is an utter waste of time.<=
/div><div><br></div><div>I agree that packaging is a massive problem for c+=
+, indeed its biggest problem. I have some ideas on how to address that, an=
d will be starting a project to that effect once the Summer is over. In my =
view there is no excuse for things refusing to "just work".</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><br><=
/div><div>Performance graphics is a specialty field. As such, there's g=
oing to be a significant quality difference from a graphics library written=
by people who spend most of their time optimizing the usual C++ code and a=
graphics library written by people who actually know graphics.</div><div><=
br></div><div>Sure, more people will be investing more time in competing 2D=
graphics libraries overall. But the quality of those libraries will be bet=
ter. They're written by people who (presumably) know what they're d=
oing. And if they aren't, then they will be out-competed by those who d=
o.</div></div></blockquote><div><br></div><div>If these competing libraries=
are mandated to support a standard interface, selection and retrofitting b=
ecomes a non-issue. You simply test and choose the most suitable conforming=
implementation. In this case, standards do nothing but good. Standards are=
why computers and operating systems can talk to each other regardless of t=
he machiavellian natures of their manufacturers.</div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>In a perfec=
t world, maybe the standard library vendors would produce work of equivalen=
t quality. But the C++ world is not, and will never be, perfect. Best to im=
prove the good and mitigate the bad.<br></div></div></blockquote><div><br><=
/div><div>I say we should focus on building the perfect world. And we shoul=
d build in ways to allow good vendors to profit from excellence.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div></di=
v>
<p></p>
-- <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" target=3D"_=
blank">std-proposals+unsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d0b57f4a-3e3d-4ddd-8511-ef9334ebd76f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d0b57f4a-3e3d-=
4ddd-8511-ef9334ebd76f%40isocpp.org</a>.<br>
</blockquote></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hb1y9hhMLBFpPZ0%3DgJ_zzU0qJMzsk=
tB146ASOthYxwb5A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hb1y9hhML=
BFpPZ0%3DgJ_zzU0qJMzsktB146ASOthYxwb5A%40mail.gmail.com</a>.<br />
--000000000000c179ff05733fa2a3--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 12 Aug 2018 16:07:18 -0700 (PDT)
Raw View
------=_Part_1252_1598300104.1534115238210
Content-Type: multipart/alternative;
boundary="----=_Part_1253_1090551049.1534115238210"
------=_Part_1253_1090551049.1534115238210
Content-Type: text/plain; charset="UTF-8"
On Sunday, August 12, 2018 at 12:40:36 PM UTC-4, Richard Hodges wrote:
>
> On Sun, 12 Aug 2018 at 16:59, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
>
>> On Sunday, August 12, 2018 at 5:46:20 AM UTC-4, Richard Hodges wrote:
>>>
>>> On Sun, 12 Aug 2018 at 04:20, Rene Rivera <grafi...@gmail.com> wrote:
>>>
>>>> On Sat, Aug 11, 2018 at 8:19 PM <yakito...@gmail.com> wrote:
>>>>
>>>>> hello.
>>>>>
>>>>> i think anti paper is hateful.
>>>>> thay look down the game programmer.
>>>>>
>>>>
>>>> Speaking as a game programmer I can say I did not get the impression of
>>>> the paper being hateful to anyone, especially game programmers. In the
>>>> contrary it seems to go out of it's way to take into consideration the
>>>> concerns of game programmers and others.
>>>>
>>>>
>>>>> last.
>>>>> i need 2d graphics for my task.
>>>>>
>>>>
>>>> I don't doubt it. But do none of existing 2d libraries satisfy your
>>>> requirement?
>>>>
>>>
>>> I think this the crux of it.
>>>
>>> Of course the obvious answer is "yes". There are many fantastic graphics
>>> libraries...
>>>
>>> ...and after spending 2 weeks of one's life trying to get them to
>>> compile and run on all the platforms you want to support (because we all
>>> want to write cross-platform software, right?) most of us lose the will to
>>> live and go back to our horrible but reliable jobs not programming games.
>>>
>>
>> So the problem has nothing to do with its appropriateness for the
>> standard library. It's the fact that C++ has a terrible build/package
>> environment. If you could download and use other libraries more easily,
>> then you wouldn't need it to be in the standard library at all. We should
>> not adopt standard library components primarily because C++ has a terrible
>> build/package environment.
>>
>> Also, we are used to standard libraries being fast, high-performance
>> tools. Containers, algorithms, these are usually well-optimized stuff in
>> standard library implementations. So people tend to instinctively assume
>> that the standard library's implementation of the graphics proposal would
>> be equally high quality.
>>
>> So let's compare the quality of other high-level stuff in the standard
>> library. Iostreams is pretty notorious for bad performance. People always
>> blame iostream's performance primarily on its interface, the many virtual
>> functions and the need for locale support. So maybe we can excuse it as
>> being as good as iostreams' design allows.
>>
>> But what about Regex? From what I've gathered from others, most standard
>> library regex implementations perform poorly. Boost.Regex is frequently
>> much faster <https://stackoverflow.com/a/50611867/734069>, despite
>> having virtually identical interfaces to `std::regex`. Here, there's no
>> question; this is pure QoI, and the standard libraries aren't providing it.
>> Despite having had a over decade to do so (regex was part of TR1, after
>> all).
>>
>> What that tells me is that standard library implementers just don't care
>> about higher-level stuff. Oh, they'll tick the feature box on their list of
>> what the compiler supports. But unless big name users of their platforms
>> *make* them optimize these things, they will not. And most big name
>> users of C++ platforms aren't interested in using these high level tools.
>> If you have a big C++ project and you needed regular expressions, you use
>> some library. If `std::regex` didn't provide equivalent performance to that
>> library, you ignored it.
>>
>
> HTTP and HTML are standards. Vendors fought a vicious war over 20 years to
> ensure that they had the "best" implementations. The result is an extremely
> functional internet. Standards are only good.
>
This "extremely functional internet" is based on people spending an
inordinate amount of time compensating for blatantly non-conformant,
sometimes horribly inefficient, and possibly flat-out *broken*
implementations of these standards, such that developers have to
*constantly* test every webpage on a myriad of versions of a myriad of
browsers just to make sure they actually work. The "extremely functional
internet" is very much not write once, run anywhere.
Standards are only good when *followed*. When followed and
well-implemented. How is having regex in the C++ standard good if nobody
uses it because of how terrible implementations are? The time spent
implementing it, however badly, is wasted. The time spent standardizing it
is wasted. The time spent updating that part of the standard, keeping it in
sync with the rest, is wasted.
How is this a good, productive use of peoples' time?
Nobody is going to ditch a standard library implementation over regex;
they'll just download and use a different regex library. This is because
changing standard library implementations is often a lot harder than
installing a normal library. Also, it ensures that you get what you want
rather than playing pot-luck with whatever implementations give you.
Standards are not "only good"; they fail. They fail all the time. You just
don't hear about the failures because... they failed; people don't tend to
talk about failures unless they are spectacular. Standards which go
unimplemented or unused have failed.
IOstreams is mostly a failure. Regex in C++ failed. We don't need more
failures in C++; certainly not 100+ pages of them.
Standardising platform I/O - including graphics, consoles, keyboards, mice
>>> and sound etc - would put the onus on the compiler-writing community to
>>> solve this once for each platform, with the benefits being fanned out to
>>> the global developer community. This is an O(1) solution in terms of
>>> man-hours.
>>>
>>
>>> The current situation is that a million developers must solve the same
>>> infuriating problems a million times, and they must do it every time a
>>> library or a compiler suite goes through a version increment. This is at
>>> best O(N).
>>>
>>
>>> In terms of lost man-hours alone, there is no possible argument that can
>>> be made against standardisation of tools and libraries.
>>>
>>
>> I'm not sure what "N" represents here (number of platforms, number of
>> libraries, number of GPUs? And it's not like there's only one standard
>> library implementation, or even one per-platform), but it doesn't really
>> matter. The analysis is flawed in that it assumes that all man hours are
>> equal.
>>
>
> N is the number of teams who need to use a graphics library. At the
> moment, every single one must figure out how to select, compile, patch,
> bugfix (because, you know, open source) and figure out why a given library
> works on one platform and not another. This is an utter waste of time.
>
How would this change by making it part of the standard library? Oh yes,
you don't need to compile or install the standard library. But the standard
library is hardly immune to bugs. And standard library bugs are usually
harder to get rid of precisely *because* you didn't compile/install it. You
have to go get its source code (if available) and then build from that. And
to preserve your patches, you now need to effectively fork and frequently
remerge from the main standard library line.
This is an O(N) problem; this time will be "wasted" either way.
I agree that packaging is a massive problem for c++, indeed its biggest
> problem. I have some ideas on how to address that, and will be starting a
> project to that effect once the Summer is over.
>
Remember: the reason C++ got into this mess to begin with was that everyone
decided to write their own build systems. Everyone decided that they had
their own needs and wrote incompatible build systems.
So the last thing C++ needs is 10 different package management systems on
top of its numerous build systems.
There are already several similar projects underway with this goal in mind.
Instead of making your own, pick the one you like the best. Even if you
don't like it *at all*, just being better than the rest is enough. Spend
your time helping it improve faster and making it better.
C++ wins if we get *one* package management system. C++ loses if we get 10
incompatible ones.
In a perfect world, maybe the standard library vendors would produce work
>> of equivalent quality. But the C++ world is not, and will never be,
>> perfect. Best to improve the good and mitigate the bad.
>>
>
> I say we should focus on building the perfect world.
>
At what cost? The saying "the perfect is the enemy of the good" is often an
overused platitude, but it is very apt in this case.
The C++ standards committee only has finite amounts of time. LEWG is
already overloaded; at the last meeting, they only reviewed *half* of the
papers submitted for the standard library. And there, 2D graphics was
talked about only for a single evening. A proper review of the 2D graphics
TS would have absorbed a great deal of LWG's time
<https://botondballo.wordpress.com/2018/03/28/trip-report-c-standards-meeting-in-jacksonville-march-2018/>,
leaving even more things undone.
What should be sacrificed for 2D graphics? `span`? Low-level filesystems
work? Text formatting? Executors? Networking? Library support for
`constexpr` heap allocations? What should be sacrificed on this altar?
How many other things in C++ is this "perfect world" worth?
--
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/152720b0-b5f2-48e1-ab3e-e1c33fb6b39d%40isocpp.org.
------=_Part_1253_1090551049.1534115238210
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, August 12, 2018 at 12:40:36 PM UTC-4, Richard H=
odges wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div class=3D"gmail_quote"><div dir=3D"ltr">On Sun, 12 Aug 2018 at 16:59, Ni=
col Bolas <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"7jpJV7znDQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javasc=
ript:';return true;" onclick=3D"this.href=3D'javascript:';retur=
n true;">jmck...@gmail.com</a>> wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr">On Sunday, August 12, 2018 at 5:46:20 AM UTC-4, Ric=
hard Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div class=3D"gmail_quote"><div dir=3D"ltr">On Sun, 12 Aug 2018 at 04:20, R=
ene Rivera <<a rel=3D"nofollow">grafi...@gmail.com</a>> wrote:<br></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 class=3D"gmail_quot=
e"><div dir=3D"ltr">On Sat, Aug 11, 2018 at 8:19 PM <<a rel=3D"nofollow"=
>yakito...@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div>hello.</div><div><br></div><div>i think anti paper i=
s hateful.</div><div>thay look down the game programmer.</div></div></block=
quote><div><br></div><div>Speaking as a game programmer I can say I did not=
get the impression of the paper being hateful to anyone, especially game p=
rogrammers. In the contrary it seems to go out of it's way to take into=
consideration the concerns of game programmers and others.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>last.<br></di=
v><div>i need 2d graphics for my task.</div></div></blockquote><div><br></d=
iv><div>I don't doubt it. But do none of existing 2d libraries satisfy =
your requirement?</div></div></div></blockquote><div><br></div><div>I think=
this the crux of it.</div><div><br></div><div>Of course the obvious answer=
is "yes". There are many fantastic graphics libraries...</div><d=
iv><br></div><div>...and after spending 2 weeks of one's life trying to=
get them to compile and run on all the platforms you want to support (beca=
use we all want to write cross-platform software, right?) most of us lose t=
he will to live and go back to our horrible but reliable jobs not programmi=
ng games.</div></div></div></blockquote><div><br></div><div>So the problem =
has nothing to do with its appropriateness for the standard library. It'=
;s the fact that C++ has a terrible build/package environment. If you could=
download and use other libraries more easily, then you wouldn't need i=
t to be in the standard library at all. We should not adopt standard librar=
y components primarily because C++ has a terrible build/package environment=
..<br></div><div><br></div><div>Also, we are used to standard libraries bein=
g fast, high-performance tools. Containers, algorithms, these are usually w=
ell-optimized stuff in standard library implementations. So people tend to =
instinctively assume that the standard library's implementation of the =
graphics proposal would be equally high quality.</div><div><br></div><div>S=
o let's compare the quality of other high-level stuff in the standard l=
ibrary. Iostreams is pretty notorious for bad performance. People always bl=
ame iostream's performance primarily on its interface, the many virtual=
functions and the need for locale support. So maybe we can excuse it as be=
ing as good as iostreams' design allows.<br></div><div><br></div><div>B=
ut what about Regex? From what I've gathered from others, most standard=
library regex implementations perform poorly. <a href=3D"https://stackover=
flow.com/a/50611867/734069" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fstackove=
rflow.com%2Fa%2F50611867%2F734069\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE=
hPVKEitRXKiMAj-Phql9Ou6Yt1g';return true;" onclick=3D"this.href=3D'=
https://www.google.com/url?q\x3dhttps%3A%2F%2Fstackoverflow.com%2Fa%2F50611=
867%2F734069\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEhPVKEitRXKiMAj-Phql9O=
u6Yt1g';return true;">Boost.Regex is frequently much faster</a>, despit=
e having virtually identical interfaces to `std::regex`. Here, there's =
no question; this is pure QoI, and the standard libraries aren't provid=
ing it. Despite having had a over decade to do so (regex was part of TR1, a=
fter all).<br></div><div><br></div><div>What that tells me is that standard=
library implementers just don't care about higher-level stuff. Oh, the=
y'll tick the feature box on their list of what the compiler supports. =
But unless big name users of their platforms <i>make</i> them optimize thes=
e things, they will not. And most big name users of C++ platforms aren'=
t interested in using these high level tools. If you have a big C++ project=
and you needed regular expressions, you use some library. If `std::regex` =
didn't provide equivalent performance to that library, you ignored it.<=
/div></div></blockquote><div><br></div><div>HTTP and HTML are standards. Ve=
ndors fought a vicious war over 20 years to ensure that they had the "=
best" implementations. The result is an extremely functional internet.=
Standards are only good.</div></div></div></blockquote><div><br></div><div=
>This "extremely functional internet" is based on people spending=
an inordinate amount of time compensating for blatantly non-conformant, so=
metimes horribly inefficient, and possibly flat-out <i>broken</i> implement=
ations of these standards, such that developers have to <i>constantly</i> t=
est every webpage on a myriad of versions of a myriad of browsers just to m=
ake sure they actually work. The "extremely functional internet" =
is very much not write once, run anywhere.<br></div><div><br></div><div>Sta=
ndards are only good when <i>followed</i>. When followed and well-implement=
ed. How is having regex in the C++ standard good if nobody uses it because =
of how terrible implementations are? The time spent implementing it, howeve=
r badly, is wasted. The time spent standardizing it is wasted. The time spe=
nt updating that part of the standard, keeping it in sync with the rest, is=
wasted.</div><div><br></div><div><div>How is this a good, productive use o=
f peoples' time?</div><div><br></div>Nobody is going to ditch a standar=
d library implementation over regex; they'll just download and use a di=
fferent regex library. This is because changing standard library implementa=
tions is often a lot harder than installing a normal library. Also, it ensu=
res that you get what you want rather than playing pot-luck with whatever i=
mplementations give you.<br></div><div><br></div>Standards are not "on=
ly good"; they fail. They fail all the time. You just don't hear a=
bout the failures because... they failed; people don't tend to talk abo=
ut failures unless they are spectacular. Standards which go unimplemented o=
r unused have failed.<br><div><br></div><div>IOstreams is mostly a failure.=
Regex in C++ failed. We don't need more failures in C++; certainly not=
100+ pages of them.<br></div><div></div><div></div><div><br></div><blockqu=
ote 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 class=3D"gmail_q=
uote"><div></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></div=
><div></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 c=
lass=3D"gmail_quote"><div></div><div>Standardising platform I/O - including=
graphics, consoles, keyboards, mice and sound etc - would put the onus on =
the compiler-writing community to solve this once for each platform, with t=
he benefits being fanned out to the global developer community. This is an =
O(1) solution in terms of man-hours. <br></div></div></div></blockquote><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_q=
uote"><div><br></div><div>The current situation is that a million developer=
s must solve the same infuriating problems a million times, and they must d=
o it every time a library or a compiler suite goes through a version increm=
ent. This is at best O(N).</div></div></div></blockquote><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div><br></div></blockquote><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>=
</div><div>In terms of lost man-hours alone, there is no possible argument =
that can be made against standardisation of tools and libraries.</div></div=
></div></blockquote><div><br></div><div>I'm not sure what "N"=
represents here (number of platforms, number of libraries, number of GPUs?=
And it's not like there's only one standard library implementation=
, or even one per-platform), but it doesn't really matter. The analysis=
is flawed in that it assumes that all man hours are equal.</div></div></bl=
ockquote><div><br></div><div>N is the number of teams who need to use a gra=
phics library. At the moment, every single one must figure out how to selec=
t, compile, patch, bugfix (because, you know, open source) and figure out w=
hy a given library works on one platform and not another. This is an utter =
waste of time.</div></div></div></blockquote><div><br></div><div>How would =
this change by making it part of the standard library? Oh yes, you don'=
t need to compile or install the standard library. But the standard library=
is hardly immune to bugs. And standard library bugs are usually harder to =
get rid of precisely <i>because</i> you didn't compile/install it. You =
have to go get its source code (if available) and then build from that. And=
to preserve your patches, you now need to effectively fork and frequently =
remerge from the main standard library line.</div><div><br></div><div>This =
is an O(N) problem; this time will be "wasted" either way.</div><=
div><br></div><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"=
><div class=3D"gmail_quote"><div></div><div>I agree that packaging is a mas=
sive problem for c++, indeed its biggest problem. I have some ideas on how =
to address that, and will be starting a project to that effect once the Sum=
mer is over.</div></div></div></blockquote><div><br></div><div><div>Remembe=
r: the reason C++ got into this mess to begin with was that=20
everyone decided to write their own build systems. Everyone decided that
they had their own needs and wrote incompatible build systems.</div><div><=
br></div><div>So the last thing C++ needs is 10 different package managemen=
t systems on top of its numerous build systems.</div><div><br></div>There a=
re already several similar projects underway with this goal in mind. Instea=
d of making your own, pick the one you like the best. Even if you don't=
like it <i>at all</i>, just being better than the rest is enough. Spend yo=
ur time helping it improve faster and making it better.</div><div><br></div=
>C++ wins if we get <i>one</i> package management system. C++ loses if we g=
et 10 incompatible ones.<div><br></div><div></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div>In a perfect world, maybe the sta=
ndard library vendors would produce work of equivalent quality. But the C++=
world is not, and will never be, perfect. Best to improve the good and mit=
igate the bad.<br></div></div></blockquote><div><br></div><div>I say we sho=
uld focus on building the perfect world.</div></div></div></blockquote><div=
><br></div><div>At what cost? The saying "the perfect is the enemy of =
the good" is often an overused platitude, but it is very apt in this c=
ase.</div><div><br></div><div>The C++ standards committee only has finite a=
mounts of time. LEWG is already overloaded; at the last meeting, they only =
reviewed <i>half</i> of the papers submitted for the standard library. And =
there, 2D graphics was talked about only for a single evening. A proper rev=
iew of the 2D graphics TS would have <a href=3D"https://botondballo.wordpre=
ss.com/2018/03/28/trip-report-c-standards-meeting-in-jacksonville-march-201=
8/">absorbed a great deal of LWG's time</a>, leaving even more things u=
ndone.</div><div><br></div><div>What should be sacrificed for 2D graphics? =
`span`? Low-level filesystems work? Text formatting? Executors? Networking?=
Library support for `constexpr` heap allocations? What should be sacrifice=
d on this altar?</div><div><br></div><div>How many other things in C++ is t=
his "perfect world" worth?<br></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/152720b0-b5f2-48e1-ab3e-e1c33fb6b39d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/152720b0-b5f2-48e1-ab3e-e1c33fb6b39d=
%40isocpp.org</a>.<br />
------=_Part_1253_1090551049.1534115238210--
------=_Part_1252_1598300104.1534115238210--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Mon, 13 Aug 2018 08:51:22 +0200
Raw View
--0000000000000e28ac05734b864f
Content-Type: text/plain; charset="UTF-8"
On Mon, 13 Aug 2018 at 01:07, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Sunday, August 12, 2018 at 12:40:36 PM UTC-4, Richard Hodges wrote:
>>
>> On Sun, 12 Aug 2018 at 16:59, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> On Sunday, August 12, 2018 at 5:46:20 AM UTC-4, Richard Hodges wrote:
>>>>
>>>> On Sun, 12 Aug 2018 at 04:20, Rene Rivera <grafi...@gmail.com> wrote:
>>>>
>>>>> On Sat, Aug 11, 2018 at 8:19 PM <yakito...@gmail.com> wrote:
>>>>>
>>>>>> hello.
>>>>>>
>>>>>> i think anti paper is hateful.
>>>>>> thay look down the game programmer.
>>>>>>
>>>>>
>>>>> Speaking as a game programmer I can say I did not get the impression
>>>>> of the paper being hateful to anyone, especially game programmers. In the
>>>>> contrary it seems to go out of it's way to take into consideration the
>>>>> concerns of game programmers and others.
>>>>>
>>>>>
>>>>>> last.
>>>>>> i need 2d graphics for my task.
>>>>>>
>>>>>
>>>>> I don't doubt it. But do none of existing 2d libraries satisfy your
>>>>> requirement?
>>>>>
>>>>
>>>> I think this the crux of it.
>>>>
>>>> Of course the obvious answer is "yes". There are many fantastic
>>>> graphics libraries...
>>>>
>>>> ...and after spending 2 weeks of one's life trying to get them to
>>>> compile and run on all the platforms you want to support (because we all
>>>> want to write cross-platform software, right?) most of us lose the will to
>>>> live and go back to our horrible but reliable jobs not programming games.
>>>>
>>>
>>> So the problem has nothing to do with its appropriateness for the
>>> standard library. It's the fact that C++ has a terrible build/package
>>> environment. If you could download and use other libraries more easily,
>>> then you wouldn't need it to be in the standard library at all. We should
>>> not adopt standard library components primarily because C++ has a terrible
>>> build/package environment.
>>>
>>> Also, we are used to standard libraries being fast, high-performance
>>> tools. Containers, algorithms, these are usually well-optimized stuff in
>>> standard library implementations. So people tend to instinctively assume
>>> that the standard library's implementation of the graphics proposal would
>>> be equally high quality.
>>>
>>> So let's compare the quality of other high-level stuff in the standard
>>> library. Iostreams is pretty notorious for bad performance. People always
>>> blame iostream's performance primarily on its interface, the many virtual
>>> functions and the need for locale support. So maybe we can excuse it as
>>> being as good as iostreams' design allows.
>>>
>>> But what about Regex? From what I've gathered from others, most standard
>>> library regex implementations perform poorly. Boost.Regex is frequently
>>> much faster <https://stackoverflow.com/a/50611867/734069>, despite
>>> having virtually identical interfaces to `std::regex`. Here, there's no
>>> question; this is pure QoI, and the standard libraries aren't providing it.
>>> Despite having had a over decade to do so (regex was part of TR1, after
>>> all).
>>>
>>> What that tells me is that standard library implementers just don't care
>>> about higher-level stuff. Oh, they'll tick the feature box on their list of
>>> what the compiler supports. But unless big name users of their platforms
>>> *make* them optimize these things, they will not. And most big name
>>> users of C++ platforms aren't interested in using these high level tools.
>>> If you have a big C++ project and you needed regular expressions, you use
>>> some library. If `std::regex` didn't provide equivalent performance to that
>>> library, you ignored it.
>>>
>>
>> HTTP and HTML are standards. Vendors fought a vicious war over 20 years
>> to ensure that they had the "best" implementations. The result is an
>> extremely functional internet. Standards are only good.
>>
>
> This "extremely functional internet" is based on people spending an
> inordinate amount of time compensating for blatantly non-conformant,
> sometimes horribly inefficient, and possibly flat-out *broken*
> implementations of these standards, such that developers have to
> *constantly* test every webpage on a myriad of versions of a myriad of
> browsers just to make sure they actually work. The "extremely functional
> internet" is very much not write once, run anywhere.
>
> Standards are only good when *followed*. When followed and
> well-implemented. How is having regex in the C++ standard good if nobody
> uses it because of how terrible implementations are? The time spent
> implementing it, however badly, is wasted. The time spent standardizing it
> is wasted. The time spent updating that part of the standard, keeping it in
> sync with the rest, is wasted.
>
> How is this a good, productive use of peoples' time?
>
> Nobody is going to ditch a standard library implementation over regex;
> they'll just download and use a different regex library. This is because
> changing standard library implementations is often a lot harder than
> installing a normal library. Also, it ensures that you get what you want
> rather than playing pot-luck with whatever implementations give you.
>
> Standards are not "only good"; they fail. They fail all the time. You just
> don't hear about the failures because... they failed; people don't tend to
> talk about failures unless they are spectacular. Standards which go
> unimplemented or unused have failed.
>
> IOstreams is mostly a failure. Regex in C++ failed. We don't need more
> failures in C++; certainly not 100+ pages of them.
>
> Standardising platform I/O - including graphics, consoles, keyboards, mice
>>>> and sound etc - would put the onus on the compiler-writing community to
>>>> solve this once for each platform, with the benefits being fanned out to
>>>> the global developer community. This is an O(1) solution in terms of
>>>> man-hours.
>>>>
>>>
>>>> The current situation is that a million developers must solve the same
>>>> infuriating problems a million times, and they must do it every time a
>>>> library or a compiler suite goes through a version increment. This is at
>>>> best O(N).
>>>>
>>>
>>>> In terms of lost man-hours alone, there is no possible argument that
>>>> can be made against standardisation of tools and libraries.
>>>>
>>>
>>> I'm not sure what "N" represents here (number of platforms, number of
>>> libraries, number of GPUs? And it's not like there's only one standard
>>> library implementation, or even one per-platform), but it doesn't really
>>> matter. The analysis is flawed in that it assumes that all man hours are
>>> equal.
>>>
>>
>> N is the number of teams who need to use a graphics library. At the
>> moment, every single one must figure out how to select, compile, patch,
>> bugfix (because, you know, open source) and figure out why a given library
>> works on one platform and not another. This is an utter waste of time.
>>
>
> How would this change by making it part of the standard library? Oh yes,
> you don't need to compile or install the standard library. But the standard
> library is hardly immune to bugs. And standard library bugs are usually
> harder to get rid of precisely *because* you didn't compile/install it.
> You have to go get its source code (if available) and then build from that.
> And to preserve your patches, you now need to effectively fork and
> frequently remerge from the main standard library line.
>
> This is an O(N) problem; this time will be "wasted" either way.
>
> I agree that packaging is a massive problem for c++, indeed its biggest
>> problem. I have some ideas on how to address that, and will be starting a
>> project to that effect once the Summer is over.
>>
>
> Remember: the reason C++ got into this mess to begin with was that
> everyone decided to write their own build systems. Everyone decided that
> they had their own needs and wrote incompatible build systems.
>
> So the last thing C++ needs is 10 different package management systems on
> top of its numerous build systems.
>
> There are already several similar projects underway with this goal in
> mind. Instead of making your own, pick the one you like the best. Even if
> you don't like it *at all*, just being better than the rest is enough.
> Spend your time helping it improve faster and making it better.
>
> C++ wins if we get *one* package management system. C++ loses if we get
> 10 incompatible ones.
>
I agree here. I have yet to find one that actually works. There needs to be
one, which appeals to everyone. Which means it must do everything, with
utter simplicity, for all target platforms. It must also appeal to
commercial software-producing firms so that the commercial licence can fund
its maintenance and development.
> In a perfect world, maybe the standard library vendors would produce work
>>> of equivalent quality. But the C++ world is not, and will never be,
>>> perfect. Best to improve the good and mitigate the bad.
>>>
>>
>> I say we should focus on building the perfect world.
>>
>
> At what cost? The saying "the perfect is the enemy of the good" is often
> an overused platitude, but it is very apt in this case.
>
> The C++ standards committee only has finite amounts of time. LEWG is
> already overloaded; at the last meeting, they only reviewed *half* of the
> papers submitted for the standard library. And there, 2D graphics was
> talked about only for a single evening. A proper review of the 2D graphics
> TS would have absorbed a great deal of LWG's time
> <https://botondballo.wordpress.com/2018/03/28/trip-report-c-standards-meeting-in-jacksonville-march-2018/>,
> leaving even more things undone.
>
> What should be sacrificed for 2D graphics? `span`? Low-level filesystems
> work? Text formatting? Executors? Networking? Library support for
> `constexpr` heap allocations? What should be sacrificed on this altar?
>
> How many other things in C++ is this "perfect world" worth?
>
The committee is clearly a bottleneck, I do agree. What could be done to
widen it?
--
> 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/152720b0-b5f2-48e1-ab3e-e1c33fb6b39d%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/152720b0-b5f2-48e1-ab3e-e1c33fb6b39d%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/CALvx3hZAPyyjoT%3D2WH1ceK_bhB7HEmVC5A_f36JPAd4M-gfi%3Dg%40mail.gmail.com.
--0000000000000e28ac05734b864f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon=
, 13 Aug 2018 at 01:07, Nicol Bolas <<a href=3D"mailto:jmckesson@gmail.c=
om">jmckesson@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr">On Sunday, August 12, 2018 at 12:40:36 PM UTC-4, Richa=
rd Hodges 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"><d=
iv class=3D"gmail_quote"><div dir=3D"ltr">On Sun, 12 Aug 2018 at 16:59, Nic=
ol Bolas <<a rel=3D"nofollow">jmck...@gmail.com</a>> wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Sunday, August 12, 2018 =
at 5:46:20 AM UTC-4, Richard Hodges wrote:<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 class=3D"gmail_quote"><div dir=3D"ltr">On Sun,=
12 Aug 2018 at 04:20, Rene Rivera <<a rel=3D"nofollow">grafi...@gmail.c=
om</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug 11, 2018 at 8:19 PM=
<<a rel=3D"nofollow">yakito...@gmail.com</a>> wrote:<br></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>hello.</div><div><br></div><=
div>i think anti paper is hateful.</div><div>thay look down the game progra=
mmer.</div></div></blockquote><div><br></div><div>Speaking as a game progra=
mmer I can say I did not get the impression of the paper being hateful to a=
nyone, especially game programmers. In the contrary it seems to go out of i=
t's way to take into consideration the concerns of game programmers and=
others.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div>last.<br></div><div>i need 2d graphics for my task.</div></div></b=
lockquote><div><br></div><div>I don't doubt it. But do none of existing=
2d libraries satisfy your requirement?</div></div></div></blockquote><div>=
<br></div><div>I think this the crux of it.</div><div><br></div><div>Of cou=
rse the obvious answer is "yes". There are many fantastic graphic=
s libraries...</div><div><br></div><div>...and after spending 2 weeks of on=
e's life trying to get them to compile and run on all the platforms you=
want to support (because we all want to write cross-platform software, rig=
ht?) most of us lose the will to live and go back to our horrible but relia=
ble jobs not programming games.</div></div></div></blockquote><div><br></di=
v><div>So the problem has nothing to do with its appropriateness for the st=
andard library. It's the fact that C++ has a terrible build/package env=
ironment. If you could download and use other libraries more easily, then y=
ou wouldn't need it to be in the standard library at all. We should not=
adopt standard library components primarily because C++ has a terrible bui=
ld/package environment.<br></div><div><br></div><div>Also, we are used to s=
tandard libraries being fast, high-performance tools. Containers, algorithm=
s, these are usually well-optimized stuff in standard library implementatio=
ns. So people tend to instinctively assume that the standard library's =
implementation of the graphics proposal would be equally high quality.</div=
><div><br></div><div>So let's compare the quality of other high-level s=
tuff in the standard library. Iostreams is pretty notorious for bad perform=
ance. People always blame iostream's performance primarily on its inter=
face, the many virtual functions and the need for locale support. So maybe =
we can excuse it as being as good as iostreams' design allows.<br></div=
><div><br></div><div>But what about Regex? From what I've gathered from=
others, most standard library regex implementations perform poorly. <a hre=
f=3D"https://stackoverflow.com/a/50611867/734069" rel=3D"nofollow" target=
=3D"_blank">Boost.Regex is frequently much faster</a>, despite having virtu=
ally identical interfaces to `std::regex`. Here, there's no question; t=
his is pure QoI, and the standard libraries aren't providing it. Despit=
e having had a over decade to do so (regex was part of TR1, after all).<br>=
</div><div><br></div><div>What that tells me is that standard library imple=
menters just don't care about higher-level stuff. Oh, they'll tick =
the feature box on their list of what the compiler supports. But unless big=
name users of their platforms <i>make</i> them optimize these things, they=
will not. And most big name users of C++ platforms aren't interested i=
n using these high level tools. If you have a big C++ project and you neede=
d regular expressions, you use some library. If `std::regex` didn't pro=
vide equivalent performance to that library, you ignored it.</div></div></b=
lockquote><div><br></div><div>HTTP and HTML are standards. Vendors fought a=
vicious war over 20 years to ensure that they had the "best" imp=
lementations. The result is an extremely functional internet. Standards are=
only good.</div></div></div></blockquote><div><br></div><div>This "ex=
tremely functional internet" is based on people spending an inordinate=
amount of time compensating for blatantly non-conformant, sometimes horrib=
ly inefficient, and possibly flat-out <i>broken</i> implementations of thes=
e standards, such that developers have to <i>constantly</i> test every webp=
age on a myriad of versions of a myriad of browsers just to make sure they =
actually work. The "extremely functional internet" is very much n=
ot write once, run anywhere.<br></div><div><br></div><div>Standards are onl=
y good when <i>followed</i>. When followed and well-implemented. How is hav=
ing regex in the C++ standard good if nobody uses it because of how terribl=
e implementations are? The time spent implementing it, however badly, is wa=
sted. The time spent standardizing it is wasted. The time spent updating th=
at part of the standard, keeping it in sync with the rest, is wasted.</div>=
<div><br></div><div><div>How is this a good, productive use of peoples'=
time?</div><div><br></div>Nobody is going to ditch a standard library impl=
ementation over regex; they'll just download and use a different regex =
library. This is because changing standard library implementations is often=
a lot harder than installing a normal library. Also, it ensures that you g=
et what you want rather than playing pot-luck with whatever implementations=
give you.<br></div><div><br></div>Standards are not "only good";=
they fail. They fail all the time. You just don't hear about the failu=
res because... they failed; people don't tend to talk about failures un=
less they are spectacular. Standards which go unimplemented or unused have =
failed.<br><div><br></div><div>IOstreams is mostly a failure. Regex in C++ =
failed. We don't need more failures in C++; certainly not 100+ pages of=
them.<br></div><div></div><div></div><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div></div><blockq=
uote 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 class=3D"gmail_quote=
"><div></div><div>Standardising platform I/O - including graphics, consoles=
, keyboards, mice and sound etc - would put the onus on the compiler-writin=
g community to solve this once for each platform, with the benefits being f=
anned out to the global developer community. This is an O(1) solution in te=
rms of man-hours. <br></div></div></div></blockquote><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div><br></di=
v><div>The current situation is that a million developers must solve the sa=
me infuriating problems a million times, and they must do it every time a l=
ibrary or a compiler suite goes through a version increment. This is at bes=
t O(N).</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:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div></div><div>In terms =
of lost man-hours alone, there is no possible argument that can be made aga=
inst standardisation of tools and libraries.</div></div></div></blockquote>=
<div><br></div><div>I'm not sure what "N" represents here (nu=
mber of platforms, number of libraries, number of GPUs? And it's not li=
ke there's only one standard library implementation, or even one per-pl=
atform), but it doesn't really matter. The analysis is flawed in that i=
t assumes that all man hours are equal.</div></div></blockquote><div><br></=
div><div>N is the number of teams who need to use a graphics library. At th=
e moment, every single one must figure out how to select, compile, patch, b=
ugfix (because, you know, open source) and figure out why a given library w=
orks on one platform and not another. This is an utter waste of time.</div>=
</div></div></blockquote><div><br></div><div>How would this change by makin=
g it part of the standard library? Oh yes, you don't need to compile or=
install the standard library. But the standard library is hardly immune to=
bugs. And standard library bugs are usually harder to get rid of precisely=
<i>because</i> you didn't compile/install it. You have to go get its s=
ource code (if available) and then build from that. And to preserve your pa=
tches, you now need to effectively fork and frequently remerge from the mai=
n standard library line.</div><div><br></div><div>This is an O(N) problem; =
this time will be "wasted" either way.</div><div><br></div><block=
quote 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 class=3D"gmail_quot=
e"><div></div><div>I agree that packaging is a massive problem for c++, ind=
eed its biggest problem. I have some ideas on how to address that, and will=
be starting a project to that effect once the Summer is over.</div></div><=
/div></blockquote><div><br></div><div><div>Remember: the reason C++ got int=
o this mess to begin with was that=20
everyone decided to write their own build systems. Everyone decided that
they had their own needs and wrote incompatible build systems.</div><div><=
br></div><div>So the last thing C++ needs is 10 different package managemen=
t systems on top of its numerous build systems.</div><div><br></div>There a=
re already several similar projects underway with this goal in mind. Instea=
d of making your own, pick the one you like the best. Even if you don't=
like it <i>at all</i>, just being better than the rest is enough. Spend yo=
ur time helping it improve faster and making it better.</div><div><br></div=
>C++ wins if we get <i>one</i> package management system. C++ loses if we g=
et 10 incompatible ones.</div></blockquote><div><br></div><div>I agree here=
.. I have yet to find one that actually works. There needs to be one, which =
appeals to everyone. Which means it must do everything, with utter simplici=
ty, for all target platforms. It must also appeal to commercial software-pr=
oducing firms so that the commercial licence can fund its maintenance and d=
evelopment.</div><div><br></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><br></div><div></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr"><div>In a perfect world, maybe the standard library vendors wo=
uld produce work of equivalent quality. But the C++ world is not, and will =
never be, perfect. Best to improve the good and mitigate the bad.<br></div>=
</div></blockquote><div><br></div><div>I say we should focus on building th=
e perfect world.</div></div></div></blockquote><div><br></div><div>At what =
cost? The saying "the perfect is the enemy of the good" is often =
an overused platitude, but it is very apt in this case.</div><div><br></div=
><div>The C++ standards committee only has finite amounts of time. LEWG is =
already overloaded; at the last meeting, they only reviewed <i>half</i> of =
the papers submitted for the standard library. And there, 2D graphics was t=
alked about only for a single evening. A proper review of the 2D graphics T=
S would have <a href=3D"https://botondballo.wordpress.com/2018/03/28/trip-r=
eport-c-standards-meeting-in-jacksonville-march-2018/" target=3D"_blank">ab=
sorbed a great deal of LWG's time</a>, leaving even more things undone.=
</div><div><br></div><div>What should be sacrificed for 2D graphics? `span`=
? Low-level filesystems work? Text formatting? Executors? Networking? Libra=
ry support for `constexpr` heap allocations? What should be sacrificed on t=
his altar?</div><div><br></div><div>How many other things in C++ is this &q=
uot;perfect world" worth?<br></div></div></blockquote><div><br></div><=
div>The committee is clearly a bottleneck, I do agree. What could be done t=
o widen it?</div><div><br></div><div><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">-- <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" target=3D"_=
blank">std-proposals+unsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/152720b0-b5f2-48e1-ab3e-e1c33fb6b39d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/152720b0-b5f2-=
48e1-ab3e-e1c33fb6b39d%40isocpp.org</a>.<br>
</blockquote></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hZAPyyjoT%3D2WH1ceK_bhB7HEmVC5A=
_f36JPAd4M-gfi%3Dg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZAPyyj=
oT%3D2WH1ceK_bhB7HEmVC5A_f36JPAd4M-gfi%3Dg%40mail.gmail.com</a>.<br />
--0000000000000e28ac05734b864f--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Mon, 13 Aug 2018 03:13:31 -0400
Raw View
--0000000000006258fb05734bd540
Content-Type: text/plain; charset="UTF-8"
On Mon, Aug 13, 2018, 2:51 AM Richard Hodges <hodges.r@gmail.com> wrote:
> The committee is clearly a bottleneck, I do agree. What could be done to
> widen it?
>
Libraries don't belong in language standards. If, during library design,
someone thinks that a language change would be helpful, then they can write
a proposal just for that.
People are being misled by history. STL and iostreams were the new shiny
and a great way to show off what C++ could do, and C had a library, so
everyone thought that a C++ standard ought to have one too. That was
wrong, and doesn't need to be compounded with filesystems, regular
expressions, Bessel functions, networking, or graphics. Special interest
groups with subject-matter expertise can go off and standardize C++
interfaces if they're so inclined.
>
--
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/CAHSYqdYFjvjxhSbSzWwLTMBj1veUMwp-H5S1QA%2B1t2J10QeFdQ%40mail.gmail.com.
--0000000000006258fb05734bd540
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr">=
On Mon, Aug 13, 2018, 2:51 AM Richard Hodges <<a href=3D"mailto:hodges.r=
@gmail.com">hodges.r@gmail.com</a>> wrote:<br></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 class=3D"gmail_quote"><div>The committee i=
s clearly a bottleneck, I do agree. What could be done to widen it?</div></=
div></div></blockquote></div><div dir=3D"auto"><br></div><div dir=3D"auto">=
Libraries don't belong in language standards.=C2=A0 If, during library =
design, someone thinks that a language change would be helpful, then they c=
an write a proposal just for that.</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">People are being misled by history.=C2=A0 STL and iostreams were=
the new shiny and a great way to show off what C++ could do, and C had a l=
ibrary, so everyone thought that a C++ standard ought to have one too.=C2=
=A0 That was wrong, and doesn't need to be compounded with filesystems,=
regular expressions, Bessel functions, networking, or graphics.=C2=A0 Spec=
ial interest groups with subject-matter expertise can go off and standardiz=
e C++ interfaces if they're so inclined.</div><div class=3D"gmail_quote=
" dir=3D"auto"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYFjvjxhSbSzWwLTMBj1veUMwp-H5S1=
QA%2B1t2J10QeFdQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYFjvjxhS=
bSzWwLTMBj1veUMwp-H5S1QA%2B1t2J10QeFdQ%40mail.gmail.com</a>.<br />
--0000000000006258fb05734bd540--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Mon, 13 Aug 2018 09:58:19 +0200
Raw View
--00000000000094197305734c7517
Content-Type: text/plain; charset="UTF-8"
On Mon, 13 Aug 2018 at 09:13, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Mon, Aug 13, 2018, 2:51 AM Richard Hodges <hodges.r@gmail.com> wrote:
>
>> The committee is clearly a bottleneck, I do agree. What could be done to
>> widen it?
>>
>
> Libraries don't belong in language standards. If, during library design,
> someone thinks that a language change would be helpful, then they can write
> a proposal just for that.
>
> People are being misled by history. STL and iostreams were the new shiny
> and a great way to show off what C++ could do, and C had a library, so
> everyone thought that a C++ standard ought to have one too. That was
> wrong, and doesn't need to be compounded with filesystems, regular
> expressions, Bessel functions, networking, or graphics. Special interest
> groups with subject-matter expertise can go off and standardize C++
> interfaces if they're so inclined.
>
Actually you have a strong point, as does Nicol. The root of the problem is
that there is no standard way to reliably distribute the output of those
special interest groups across target platforms and build systems.
If we could solve this, everything else library-related becomes a non-issue.
> --
> 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/CAHSYqdYFjvjxhSbSzWwLTMBj1veUMwp-H5S1QA%2B1t2J10QeFdQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYFjvjxhSbSzWwLTMBj1veUMwp-H5S1QA%2B1t2J10QeFdQ%40mail.gmail.com?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/CALvx3haf6_%3DHaaY-Pmy5EZqVUnQS4VTFs53bRwuWaGq_K9dRjg%40mail.gmail.com.
--00000000000094197305734c7517
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon=
, 13 Aug 2018 at 09:13, Hyman Rosen <<a href=3D"mailto:hyman.rosen@gmail=
..com">hyman.rosen@gmail.com</a>> wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"auto"><div class=3D"gmail_quote" dir=3D"auto"><div dir=
=3D"ltr">On Mon, Aug 13, 2018, 2:51 AM Richard Hodges <<a href=3D"mailto=
:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a>> wrote:<br=
></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 class=3D"gmail_=
quote"><div>The committee is clearly a bottleneck, I do agree. What could b=
e done to widen it?</div></div></div></blockquote></div><div dir=3D"auto"><=
br></div><div dir=3D"auto">Libraries don't belong in language standards=
..=C2=A0 If, during library design, someone thinks that a language change wo=
uld be helpful, then they can write a proposal just for that.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">People are being misled by history.=
=C2=A0 STL and iostreams were the new shiny and a great way to show off wha=
t C++ could do, and C had a library, so everyone thought that a C++ standar=
d ought to have one too.=C2=A0 That was wrong, and doesn't need to be c=
ompounded with filesystems, regular expressions, Bessel functions, networki=
ng, or graphics.=C2=A0 Special interest groups with subject-matter expertis=
e can go off and standardize C++ interfaces if they're so inclined.</di=
v></div></blockquote><div><br></div><div>Actually you have a strong point, =
as does Nicol. The root of the problem is that there is no standard way to =
reliably distribute the output of those special interest groups across targ=
et platforms and build systems.=C2=A0</div><div><br></div><div>If we could =
solve this, everything else library-related becomes a non-issue.</div><div>=
=C2=A0</div><div>=C2=A0</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"aut=
o"><div class=3D"gmail_quote" dir=3D"auto"><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div>
<p></p>
-- <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" target=3D"_=
blank">std-proposals+unsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYFjvjxhSbSzWwLTMBj1veUMwp-H5S1=
QA%2B1t2J10QeFdQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAHSYqdYFjvjxhSbSzWwLTMBj1veUMwp-H5S1QA%2B1t2J10QeFdQ%40mail.gmail.c=
om</a>.<br>
</blockquote></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3haf6_%3DHaaY-Pmy5EZqVUnQS4VTFs5=
3bRwuWaGq_K9dRjg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3haf6_%3DH=
aaY-Pmy5EZqVUnQS4VTFs53bRwuWaGq_K9dRjg%40mail.gmail.com</a>.<br />
--00000000000094197305734c7517--
.
Author: yakitori1010@gmail.com
Date: Mon, 13 Aug 2018 01:38:16 -0700 (PDT)
Raw View
------=_Part_1413_69064337.1534149496520
Content-Type: multipart/alternative;
boundary="----=_Part_1414_792348870.1534149496520"
------=_Part_1414_792348870.1534149496520
Content-Type: text/plain; charset="UTF-8"
i say one of memory.
do you know BASIC lang.
it is not visual basic.
i am grow by Basic.
Basic is completly creative.
but it have some problem in spec.
i decide to go next.
the next is c lang.
it time i fall in despier.
nothing need of all.
graphic sound input
what happen??
crash my head.
as C++ cant aid it.
but c++ give me to many stady.
i can write one of sysrem.without some effecttive.
can you sell prodact it deposit warranty to other.
if other as hobbist too?
yes.i am not hate hobbist.but i need strong warranty.
one more.
do you hear c lang mean.
i am hear mean the computer.
now age's computer have many entertainment element.
but it is cant control by default.
some person on my old way.
i want to solve it.
i want to happy working for any way.
do you want to hard to hard the working? it for bisiness?
i think computer's life is bottleneck by c/c++.
C/C++ need more rich.Building needs good base.
any way the problem is the paper biggest.
need power for diet.
--
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/cf2aff90-d259-40c7-8c89-8d65b58fe3fb%40isocpp.org.
------=_Part_1414_792348870.1534149496520
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>i say one of memory.</div><div><br></div><div>do you =
know BASIC lang.</div><div>it is not visual basic.</div><div>i am grow by B=
asic.</div><div>Basic is completly creative.</div><div>but it have some pro=
blem in spec.</div><div>i decide to go next.</div><div>the next is c lang.<=
/div><div>it time i fall in despier.</div><div>nothing <span style=3D"backg=
round-color: transparent; border-bottom-color: rgb(34, 34, 34); border-bott=
om-style: none; border-bottom-width: 0px; border-image-outset: 0; border-im=
age-repeat: stretch; border-image-slice: 100%; border-image-source: none; b=
order-image-width: 1; border-left-color: rgb(34, 34, 34); border-left-style=
: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34); border=
-right-style: none; border-right-width: 0px; border-top-color: rgb(34, 34, =
34); border-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34);=
display: inline; float: none; font-family: &quot;Arial&quot;,&=
quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: normal; f=
ont-variant: normal; font-weight: 400; letter-spacing: normal; margin-botto=
m: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; p=
adding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px=
; text-align: left; text-decoration: none; text-indent: 0px; text-transform=
: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: =
0px;">need </span>of=C2=A0 all.</div><div>graphic sound input</div><div>wha=
t happen??</div><div>crash my head.</div><div>as C++ cant aid it.</div><div=
>but c++ give me to many stady.</div><div>i can write one of sysrem.without=
some effecttive.</div><div><br></div><div>can you sell prodact it deposit =
warranty to other.</div><div>if other as hobbist too?</div><div>yes.i am no=
t hate hobbist.but i need strong warranty.</div><div><br></div><div>one mor=
e.</div><div>do you hear c lang mean.</div><div>i am hear mean the computer=
..</div><div>now age's computer have many entertainment element.</div><d=
iv>but it is cant control by default.</div><div>some person on my old way.<=
/div><div>i want to solve it.</div><div>i want to happy working for any way=
..</div><div><br></div><div>do you want to hard to hard the working? it for =
bisiness?</div><div><br></div><div>i think computer's life is bottlenec=
k by c/c++.</div><div>C/C++ need more rich.Building needs good base.</div><=
div><br></div><div>any way the problem is the paper biggest.</div><div>need=
power for diet.</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cf2aff90-d259-40c7-8c89-8d65b58fe3fb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cf2aff90-d259-40c7-8c89-8d65b58fe3fb=
%40isocpp.org</a>.<br />
------=_Part_1414_792348870.1534149496520--
------=_Part_1413_69064337.1534149496520--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 13 Aug 2018 11:37:18 -0400
Raw View
On 2018-08-12 19:07, Nicol Bolas wrote:
> On Sunday, August 12, 2018 at 12:40:36 PM UTC-4, Richard Hodges wrote:
>> I agree that packaging is a massive problem for c++, indeed its biggest
>> problem. I have some ideas on how to address that, and will be starting a
>> project to that effect once the Summer is over.
>
> Remember: the reason C++ got into this mess to begin with was that everyone
> decided to write their own build systems. Everyone decided that they had
> their own needs and wrote incompatible build systems.
>
> So the last thing C++ needs is 10 different package management systems on
> top of its numerous build systems.
I don't *necessarily* see that as a problem... if those 10 different
package management systems run on 10 different operating systems.
Where package management works *well* is when it is deeply integrated
with the guts of the operating system. The fact that we have apt, dnf
and homebrew is not a problem. It's trying to use several different
pacakge managers on the same computer that turns into a problem.
(Now, at the same time, that's not to say that it wouldn't be a lot
easier on the people trying to get their software packaged if there
weren't so many options...)
BTW, it would help if we all agreed on how to *describe* our packages.
That is the goal behind https://mwoehlke.github.io/cps/. *Finding and
using* packages isn't quite the same problem as *installing* packages,
and indeed the two often don't intersect, even though they could (and
arguably should). This probably has a lot to do, however, with package
managers generally trying to support all sorts of "stuff", including
things that aren't strictly "software" (e.g. fonts, icon themes), while
the "how to find and use" problem can be language-specific. (CPS is
aimed mainly at C/C++, though it has some rudimentary support for Java.)
On 2018-08-13 02:51, Richard Hodges wrote:
> I agree here. I have yet to find one that actually works. There needs
> to be one, which appeals to everyone. Which means it must do
> everything, with utter simplicity, for all target platforms.
If you try to replace apt/dnf/etc. *without* doing so at the distro
level, I *guarantee* you are just going to run into
https://xkcd.com/927/ and make things worse. For that matter, if you try
to start something new without taking into account what apt/dnf/etc.
already provide, that's just a recipe for outright failure.
--
Matthew
--
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/8d604a5e-7e1b-c6c4-0e03-e3137579dc94%40gmail.com.
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Mon, 13 Aug 2018 17:48:23 +0200
Raw View
2018-08-13 17:37 GMT+02:00 Matthew Woehlke <mwoehlke.floss@gmail.com>:
> If you try to replace apt/dnf/etc. *without* doing so at the distro
> level, I *guarantee* you are just going to run into
> https://xkcd.com/927/ and make things worse. For that matter, if you try
> to start something new without taking into account what apt/dnf/etc.
> already provide, that's just a recipe for outright failure.
Is it? For Java, Javascript, PHP and Ruby it seems to work quite well.
--
Olaf
--
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/CAA7U3HPFEW_%2BW9E021LhfuBN8Wo5mGZoGDboh7Cb-L0RcLUqhw%40mail.gmail.com.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 13 Aug 2018 12:15:27 -0400
Raw View
On 2018-08-13 11:48, Olaf van der Spek wrote:
> 2018-08-13 17:37 GMT+02:00 Matthew Woehlke wrote:
>> If you try to replace apt/dnf/etc. *without* doing so at the distro
>> level, I *guarantee* you are just going to run into
>> https://xkcd.com/927/ and make things worse. For that matter, if you try
>> to start something new without taking into account what apt/dnf/etc.
>> already provide, that's just a recipe for outright failure.
>
> Is it? For Java, Javascript, PHP and Ruby it seems to work quite well.
....and none of those are trying to *replace* apt/dnf/etc. None of them
infringe on the core operating system, or indeed, I suspect even compete
with it much. OTOH, pip is something of a mess because it *does* compete
directly with apt/dnf/etc... as a result, we have system python,
"system" pip installs, user-local pip installs, virtual environments,
anaconda, python packages installed via other mechanisms to none of the
above...
....oh, and, don't forget that developers are still going to need support
for local installs that may not even be packaged at all...
The languages you mentioned can get away with having an ecosystem that
is totally divorced from the core operating system because they aren't
providing things that *every* user demands. For example, a desktop, or a
web browser. Those are going to depend on things like libjpeg, which
means *at best* anything that competes with the system package manager
is going to mean having duplicate copies of those dependencies.
Personally, I think the value of trying to create yet another package
manager for C/C++ packages is... dubious at best. (Except for Windows,
because Windows doesn't already have a good one.)
--
Matthew
--
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/42112917-d345-96d3-e86e-4e307cbe984f%40gmail.com.
.
Author: Robert Ramey <ramey@rrsd.com>
Date: Mon, 13 Aug 2018 09:15:41 -0700
Raw View
On 8/13/18 12:13 AM, Hyman Rosen wrote:
> On Mon, Aug 13, 2018, 2:51 AM Richard Hodges <hodges.r@gmail.com=20
> <mailto:hodges.r@gmail.com>> wrote:
>=20
> The committee is clearly a bottleneck, I do agree. What could be
> done to widen it?
>=20
>=20
> Libraries don't belong in language standards.=C2=A0 If, during library=20
> design, someone thinks that a language change would be helpful, then=20
> they can write a proposal just for that.
>=20
> People are being misled by history.=C2=A0 STL and iostreams were the new=
=20
> shiny and a great way to show off what C++ could do, and C had a=20
> library, so everyone thought that a C++ standard ought to have one too. =
=20
> That was wrong, and doesn't need to be compounded with filesystems,=20
> regular expressions, Bessel functions, networking, or graphics.=C2=A0 Spe=
cial=20
> interest groups with subject-matter expertise can go off and standardize=
=20
> C++ interfaces if they're so inclined.
I agree with this.
The intent of the original C library was to make C portable across=20
operating systems, Just as the C language intent was to make code=20
portable across machine architectures. So the C library contains things=20
like printf etc. which had to be implemented in an operating system=20
specific way. The thing to do is follow this lead. So things which are=20
coupled to the operating system like filesystem, low level graphic, are=20
interesting candidates for a C++ standard library. Other things should=20
be handled separately and written to C++ language standard but be not=20
part of any concept of standard library.
Robert Ramey
--=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/pksanb%24ja7%241%40blaine.gmane.org.
.
Author: Giovanni Piero Deretta <gpderetta@gmail.com>
Date: Mon, 13 Aug 2018 11:05:14 -0700 (PDT)
Raw View
------=_Part_1533_1062525115.1534183514708
Content-Type: multipart/alternative;
boundary="----=_Part_1534_956876819.1534183514708"
------=_Part_1534_956876819.1534183514708
Content-Type: text/plain; charset="UTF-8"
On Friday, June 1, 2018 at 1:00:49 PM UTC+1, mihailn...@gmail.com wrote:
>
> Hello, I recently stumbled into p1062R0 (Diet Graphics)
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html>
>
> I wholeheartedly agree, the Committee should not pursue *any* from of
> "Graphics Programing".
>
> Here is why:
> - *Impossible* to keep up-to date with modern trends - *both* hardware,
> algorithms and APIs to address the hardware change all the time.
> - *Impossible *to look (or perform) nearly the same on all platforms or
> implementations.
> - *Impossible* to be complete and useful for the real world - useful
> graphics programming framework is way bigger the standard library itself!
> - *Impossible* to keep up to date in terms of user requests - new
> primitives, strokes, colors, brushes, filters, helper functions,
> customization points, etc etc etc etc etc
> - *Heavy* *burden* on the implementations.
> - *Limited use *as a percent of c++ community in comparison to many
> other features and libraries, including higher level ones like filesystem
> - *Will open the floodgates* for *Proposals Related To Graphics* *and* *Proposals
> Which Build On Top Of Graphics, *which the Committee (and the community)
> will waste time considering, probably without even having the expertise for
> that!
>
>
>
And still we have standardized stdin/stdout/stderr. You are not going to
use them to write a word processor or a fully featured logger, but they are
still useful. There are plenty of applications where graphics are only a
secondary concern which would benefit from a simple built in graphic
library.
Lack of resources or difficulty to find an agreement between vendors can
all be practical reasons not to include them in C++ of course.
--
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/7a17143d-7479-4bdd-8be1-36c31c0e678c%40isocpp.org.
------=_Part_1534_956876819.1534183514708
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, June 1, 2018 at 1:00:49 PM UTC+1, mihailn...@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"=
><div>Hello, I recently stumbled into=C2=A0<a href=3D"http://www.open-std.o=
rg/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html" target=3D"_blank" rel=3D"n=
ofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhtt=
p%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2018%2Fp1=
062r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGtIqi7NfG5HOA38FwOR16TH3=
hR_g';return true;" onclick=3D"this.href=3D'http://www.google.com/u=
rl?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%=
2F2018%2Fp1062r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGtIqi7NfG5HOA=
38FwOR16TH3hR_g';return true;">p1062R0 (Diet Graphics)</a></div><div><b=
r></div><div>I wholeheartedly agree, the Committee should not pursue <i>any=
</i> from of "Graphics Programing".</div><div><br></div><div>Here=
is why:</div><div>=C2=A0- <b>Impossible</b> to keep up-to date with modern=
trends - <i>both</i> hardware, algorithms and APIs to address the hardware=
change all the time.</div><div><span style=3D"display:inline!important;flo=
at:none;background-color:transparent;color:rgb(34,34,34);font-family:"=
Arial","Helvetica",sans-serif;font-size:13px;font-style:norm=
al;font-variant:normal;font-weight:400;letter-spacing:normal;text-align:lef=
t;text-decoration:none;text-indent:0px;text-transform:none;white-space:norm=
al;word-spacing:0px">=C2=A0- </span><b>Impossible </b><span style=3D"displa=
y:inline!important;float:none;background-color:transparent;color:rgb(34,34,=
34);font-family:"Arial","Helvetica",sans-serif;font-siz=
e:13px;font-style:normal;font-variant:normal;font-weight:400;letter-spacing=
:normal;text-align:left;text-decoration:none;text-indent:0px;text-transform=
:none;white-space:normal;word-spacing:0px">to look (or perform) nearly the =
same on all platforms or <span style=3D"display:inline!important;float:none=
;background-color:transparent;color:rgb(34,34,34);font-family:"Arial&q=
uot;,"Helvetica",sans-serif;font-size:13px;font-style:normal;font=
-variant:normal;font-weight:400;letter-spacing:normal;text-align:left;text-=
decoration:none;text-indent:0px;text-transform:none;white-space:normal;word=
-spacing:0px">implementations</span>.</span><span style=3D"display:inline!i=
mportant;float:none;background-color:transparent;color:rgb(34,34,34);font-f=
amily:"Arial","Helvetica",sans-serif;font-size:13px;fon=
t-style:normal;font-variant:normal;font-weight:400;letter-spacing:normal;te=
xt-align:left;text-decoration:none;text-indent:0px;text-transform:none;whit=
e-space:normal;word-spacing:0px">=C2=A0</span><br></div><div>=C2=A0- <b>Imp=
ossible</b> to be complete and useful for the real world - useful graphics =
programming framework is way bigger the standard library itself!</div><div>=
=C2=A0- <b>Impossible</b> to keep up to date in terms of user requests - ne=
w primitives, strokes, colors, brushes, filters, helper functions, customiz=
ation points, etc etc etc etc etc</div><div><span style=3D"display:inline!i=
mportant;float:none;background-color:transparent;color:rgb(34,34,34);font-f=
amily:"Arial","Helvetica",sans-serif;font-size:13px;fon=
t-style:normal;font-variant:normal;font-weight:400;letter-spacing:normal;te=
xt-align:left;text-decoration:none;text-indent:0px;text-transform:none;whit=
e-space:normal;word-spacing:0px">=C2=A0- </span><b>Heavy</b><span style=3D"=
display:inline!important;float:none;background-color:transparent;color:rgb(=
34,34,34);font-family:"Arial","Helvetica",sans-serif;fo=
nt-size:13px;font-style:normal;font-variant:normal;font-weight:400;letter-s=
pacing:normal;text-align:left;text-decoration:none;text-indent:0px;text-tra=
nsform:none;white-space:normal;word-spacing:0px"> <b>burden</b> on the impl=
ementations.=C2=A0</span><b></b><i></i><u></u><sub></sub><sup></sup><strike=
></strike><br></div><div>=C2=A0- <b>Limited use </b>as a percent of c++ com=
munity in comparison to many other features and libraries, including higher=
level ones like filesystem=C2=A0</div><div>=C2=A0- <b>Will open the floodg=
ates</b> for <i>Proposals Related To Graphics</i> <b>and</b> <i>Proposals W=
hich Build On Top Of Graphics, </i>which the Committee (and the community) =
will waste time considering, probably without even having the expertise for=
that!</div><div>=C2=A0</div><div><br></div></div></blockquote><div><br><br=
>And still we have standardized stdin/stdout/stderr. You are not going to u=
se them to write a word processor or a fully featured logger, but they are =
still useful. There are plenty of applications where graphics are only a se=
condary concern which would benefit from a simple built in graphic library.=
<br><br>Lack of resources or difficulty to find an agreement between vendo=
rs can all be practical reasons not to include them in C++ of course.<br>=
=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" 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/7a17143d-7479-4bdd-8be1-36c31c0e678c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7a17143d-7479-4bdd-8be1-36c31c0e678c=
%40isocpp.org</a>.<br />
------=_Part_1534_956876819.1534183514708--
------=_Part_1533_1062525115.1534183514708--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Mon, 13 Aug 2018 20:18:47 +0200
Raw View
--0000000000008832060573552040
Content-Type: text/plain; charset="UTF-8"
On Mon, 13 Aug 2018 at 17:37, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:
> On 2018-08-12 19:07, Nicol Bolas wrote:
> > On Sunday, August 12, 2018 at 12:40:36 PM UTC-4, Richard Hodges wrote:
> >> I agree that packaging is a massive problem for c++, indeed its biggest
> >> problem. I have some ideas on how to address that, and will be starting
> a
> >> project to that effect once the Summer is over.
> >
> > Remember: the reason C++ got into this mess to begin with was that
> everyone
> > decided to write their own build systems. Everyone decided that they had
> > their own needs and wrote incompatible build systems.
> >
> > So the last thing C++ needs is 10 different package management systems
> on
> > top of its numerous build systems.
>
> I don't *necessarily* see that as a problem... if those 10 different
> package management systems run on 10 different operating systems.
>
> Where package management works *well* is when it is deeply integrated
> with the guts of the operating system. The fact that we have apt, dnf
> and homebrew is not a problem. It's trying to use several different
> pacakge managers on the same computer that turns into a problem.
>
> (Now, at the same time, that's not to say that it wouldn't be a lot
> easier on the people trying to get their software packaged if there
> weren't so many options...)
>
> BTW, it would help if we all agreed on how to *describe* our packages.
> That is the goal behind https://mwoehlke.github.io/cps/. *Finding and
> using* packages isn't quite the same problem as *installing* packages,
> and indeed the two often don't intersect, even though they could (and
> arguably should). This probably has a lot to do, however, with package
> managers generally trying to support all sorts of "stuff", including
> things that aren't strictly "software" (e.g. fonts, icon themes), while
> the "how to find and use" problem can be language-specific. (CPS is
> aimed mainly at C/C++, though it has some rudimentary support for Java.)
>
> On 2018-08-13 02:51, Richard Hodges wrote:
> > I agree here. I have yet to find one that actually works. There needs
> > to be one, which appeals to everyone. Which means it must do
> > everything, with utter simplicity, for all target platforms.
> If you try to replace apt/dnf/etc. *without* doing so at the distro
> level, I *guarantee* you are just going to run into
> https://xkcd.com/927/ and make things worse. For that matter, if you try
> to start something new without taking into account what apt/dnf/etc.
> already provide, that's just a recipe for outright failure.
>
I am only interested with building in a 100% cross-platform way. DNF etc
are great for building on *your linux machine* but utterly useless for
building *for any machine*.
When I say dependency/package manager, what I want is: "here is my program
- it depends (optionally) on this, that and the other. We're building it
for fedora, windows, iOS, etc. Go build it. Find or build any missing
dependencies ad stop bothering me with this nonsense".
A dependency manager for building on the local machine is not interesting.
It's a solved problem, but it doesn't solve my problem.
>
> --
> Matthew
>
> --
> 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/8d604a5e-7e1b-c6c4-0e03-e3137579dc94%40gmail.com
> .
>
--
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/CALvx3hZsj34JNpVbDJ1x6-H_nhtmGSfaf6GQG7MG18GWZLnjmQ%40mail.gmail.com.
--0000000000008832060573552040
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon=
, 13 Aug 2018 at 17:37, Matthew Woehlke <<a href=3D"mailto:mwoehlke.flos=
s@gmail.com">mwoehlke.floss@gmail.com</a>> wrote:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">On 2018-08-12 19:07, Nicol Bolas wrote:<br>
> On Sunday, August 12, 2018 at 12:40:36 PM UTC-4, Richard Hodges wrote:=
<br>
>> I agree that packaging is a massive problem for c++, indeed its bi=
ggest <br>
>> problem. I have some ideas on how to address that, and will be sta=
rting a <br>
>> project to that effect once the Summer is over.<br>
> <br>
> Remember: the reason C++ got into this mess to begin with was that eve=
ryone <br>
> decided to write their own build systems. Everyone decided that they h=
ad <br>
> their own needs and wrote incompatible build systems.<br>
> <br>
> So the last thing C++ needs is 10 different package management systems=
on <br>
> top of its numerous build systems.<br>
<br>
I don't *necessarily* see that as a problem... if those 10 different<br=
>
package management systems run on 10 different operating systems.<br>
<br>
Where package management works *well* is when it is deeply integrated<br>
with the guts of the operating system. The fact that we have apt, dnf<br>
and homebrew is not a problem. It's trying to use several different<br>
pacakge managers on the same computer that turns into a problem.<br>
<br>
(Now, at the same time, that's not to say that it wouldn't be a lot=
<br>
easier on the people trying to get their software packaged if there<br>
weren't so many options...)<br>
<br>
BTW, it would help if we all agreed on how to *describe* our packages.<br>
That is the goal behind <a href=3D"https://mwoehlke.github.io/cps/" rel=3D"=
noreferrer" target=3D"_blank">https://mwoehlke.github.io/cps/</a>. *Finding=
and<br>
using* packages isn't quite the same problem as *installing* packages,<=
br>
and indeed the two often don't intersect, even though they could (and<b=
r>
arguably should). This probably has a lot to do, however, with package<br>
managers generally trying to support all sorts of "stuff", includ=
ing<br>
things that aren't strictly "software" (e.g. fonts, icon them=
es), while<br>
the "how to find and use" problem can be language-specific. (CPS =
is<br>
aimed mainly at C/C++, though it has some rudimentary support for Java.)<br=
>
<br>
On 2018-08-13 02:51, Richard Hodges wrote:<br>
> I agree here. I have yet to find one that actually works. There needs<=
br>
> to be one, which appeals to everyone. Which means it must do <br>
> everything, with utter simplicity, for all target platforms.<br>
If you try to replace apt/dnf/etc. *without* doing so at the distro<br>
level, I *guarantee* you are just going to run into<br>
<a href=3D"https://xkcd.com/927/" rel=3D"noreferrer" target=3D"_blank">http=
s://xkcd.com/927/</a> and make things worse. For that matter, if you try<br=
>
to start something new without taking into account what apt/dnf/etc.<br>
already provide, that's just a recipe for outright failure.<br></blockq=
uote><div><br></div><div>I am only interested with building in a 100% cross=
-platform way. DNF etc are great for building on *your linux machine* but u=
tterly useless for building *for any machine*.</div><div><br></div><div>Whe=
n I say dependency/package manager, what I want is: "here is my progra=
m - it depends (optionally) on this, that and the other. We're building=
it for fedora, windows, iOS, etc. Go build it. Find or build any missing d=
ependencies ad stop bothering me with this nonsense".</div><div><br></=
div><div>A dependency manager for building on the local machine is not inte=
resting. It's a solved problem, but it doesn't solve my problem.</d=
iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-- <br>
Matthew<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8d604a5e-7e1b-c6c4-0e03-e3137579dc94%=
40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/8d604a5e-7e1b-c6c4-0e03-e3137579dc94%40=
gmail.com</a>.<br>
</blockquote></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hZsj34JNpVbDJ1x6-H_nhtmGSfaf6GQ=
G7MG18GWZLnjmQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZsj34JNpVb=
DJ1x6-H_nhtmGSfaf6GQG7MG18GWZLnjmQ%40mail.gmail.com</a>.<br />
--0000000000008832060573552040--
.
Author: Domen Vrankar <domen.vrankar@gmail.com>
Date: Tue, 14 Aug 2018 00:46:51 +0200
Raw View
--000000000000f1c0c3057358e0fa
Content-Type: text/plain; charset="UTF-8"
2018-08-13 17:48 GMT+02:00 Olaf van der Spek <olafvdspek@gmail.com>:
> 2018-08-13 17:37 GMT+02:00 Matthew Woehlke <mwoehlke.floss@gmail.com>:
> > If you try to replace apt/dnf/etc. *without* doing so at the distro
> > level, I *guarantee* you are just going to run into
> > https://xkcd.com/927/ and make things worse. For that matter, if you try
> > to start something new without taking into account what apt/dnf/etc.
> > already provide, that's just a recipe for outright failure.
>
> Is it? For Java, Javascript, PHP and Ruby it seems to work quite well.
>
In this community dependency management systems are starting to sound like
something that will solve all our dependency issues so we don't need to
worry about the libraries as the dependency system is connected to the
aether from where it will pull libraries that will solve all our problems.
I can understand that the committee is swamped with work and can't work on
all big features that we can think of and that C++ standard library
implementers are in the same position but using a lie to the children on us
is a bit off.
I'm not certain how people still manage to praise things like Maven package
management or Nuget packages and so on. It's possible that the teams I
worked with in the past were not using them correctly (or that they are
already outdated and Java, C# and all the other languages already got their
new fancy package management systems that work) but as far as I'm concerned
programming language level package management solves nothing at best - it
just postpones the issues until later when you have less time all of them
can explode in your face at once.
So a longer explanation... The only package management systems that I
worked with and were doing their jobs fairly well were Fedora's dnf (and
yum before that) and Ubuntu's apt. The reason that I'm adding the distro
names along side the package management systems is that the only way they
didn't make my hair fall out was to stay with the latest version of the
operating system (quite often not an option for companies) so that distro
maintainers were the ones doing the heavy lifting of providing consistent
packages that were hopefully up to date with the latest upstream releases.
If they weren't... Well that's a whole new problem (meaning sometimes
compiling a ton of dependencies and those tend to snowball).
The second issue with dependency management systems is that once those are
available people tend to invite every man and his dog to become a
dependency. I know that that's a company/team issue but package management
systems tend to increase it. On one hand you have C++ where as it currently
stands we don't have modules and a standardized package management system
so libraries tend to be bigger and contain more stuff so you think
carefully if the will use size outweighs the will not use size of the
library before you add it as a dependency. On the other hand when I worked
with Java teams the packages were smaller so they added dependencies more
liberally at least until they got out of hands because of the inter package
version dependencies issues. From where I stand that's what you get when
you have allot of small components - allot of people are reusing them but
require different versions so they start colliding until the shared
libraries dependency hell is where you go on vacation after your nerves
break due to small components dependency hell.
I'm honestly happy that C++ is close to getting modules but on the other
hand I'm afraid that once they start mixing with package management systems
they'll cause the mess that I'm used to from other languages.
In the end for me language level dependency management systems (apt/dnf
don't count here as they are most of the time being used as OS level
dependency management systems) are just like Java checked exceptions - they
sound nice in theory and get you hyped but once you have to start using
them you tend form a different opinion.
Regards,
Domen
--
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/CAKgx6B%2BfkkdB_ag3E6NiZGVvdsf424%2BrZ40kwSzriWLRhw6S1w%40mail.gmail.com.
--000000000000f1c0c3057358e0fa
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">2018=
-08-13 17:48 GMT+02:00 Olaf van der Spek <span dir=3D"ltr"><<a href=3D"m=
ailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a>><=
/span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><span class=3D"">2018-08-13 17:37=
GMT+02:00 Matthew Woehlke <<a href=3D"mailto:mwoehlke.floss@gmail.com">=
mwoehlke.floss@gmail.com</a>>:<br>
> If you try to replace apt/dnf/etc. *without* doing so at the distro<br=
>
> level, I *guarantee* you are just going to run into<br>
> <a href=3D"https://xkcd.com/927/" rel=3D"noreferrer" target=3D"_blank"=
>https://xkcd.com/927/</a> and make things worse. For that matter, if you t=
ry<br>
> to start something new without taking into account what apt/dnf/etc.<b=
r>
> already provide, that's just a recipe for outright failure.<br>
<br>
</span>Is it? For Java, Javascript, PHP and Ruby it seems to work quite wel=
l.<br></blockquote><div><br></div><div>In this community dependency managem=
ent systems are starting to sound like something that will solve all our de=
pendency issues so we don't need to worry about the libraries as the de=
pendency system is connected to the aether from where it will pull librarie=
s that will solve all our problems. I can understand that the=20
committee=20
is swamped with work and can't work on all big features that we can thi=
nk of and that C++ standard library implementers are in the same position b=
ut using a lie to the children on us is a bit off.<br></div><div><br></div>=
<div>
<div>I'm not certain how people still manage to praise things=20
like Maven package management or Nuget packages and so on. It's possibl=
e
that the teams I worked with in the past were not using them correctly (or=
that=20
they are already outdated and Java, C# and all the other languages=20
already got their new fancy package management systems that work) but as
far as I'm concerned programming language level package management sol=
ves nothing at best - it just postpones the issues until later when you hav=
e less time all of them can explode in your face at once.<br><br></div><div=
>So
a longer explanation... The only package management systems that I=20
worked with and were doing their jobs fairly well were Fedora's dnf (an=
d
yum before that) and Ubuntu's apt. The reason that I'm adding the=
=20
distro names along side the package management systems is that the only=20
way they didn't make my hair fall out was to stay with the latest=20
version of the operating system (quite often not an option for=20
companies) so that distro maintainers were the ones doing the heavy=20
lifting of providing consistent packages that were hopefully up to date=20
with the latest upstream releases. If they weren't... Well that's a=
=20
whole new problem (meaning sometimes compiling a ton of dependencies and
those tend to snowball).</div><div><br></div><div>The second issue with
dependency management systems is that once those are available people=20
tend to invite every man and his dog to become a dependency. I know that
that's a company/team issue but package management systems tend to=20
increase it. On one hand you have C++ where as it currently stands we=20
don't have modules and a standardized package management system so=20
libraries tend to be bigger and contain more stuff so you think=20
carefully if the will use size outweighs the will not use size of the=20
library before you add it as a dependency. On the other hand when I=20
worked with Java teams the packages were smaller so they added=20
dependencies more liberally at least until they got out of hands because
of the inter package version dependencies issues. From where I stand=20
that's what you get when you have allot of small components - allot of=
=20
people are reusing them but require different versions so they start=20
colliding until the shared libraries dependency hell is where you go on=20
vacation after your nerves break due to small components dependency=20
hell.</div><div><br></div><div>I'm honestly happy that C++ is close to=
=20
getting modules but on the other hand I'm afraid that once they start=
=20
mixing with package management systems they'll cause the mess that I=
9;m=20
used to from other languages.</div><div><br></div><div>In the end for me la=
nguage level dependency management systems (apt/dnf don't count here as=
they are most of the time being used as OS level dependency management sys=
tems) are just like Java checked exceptions - they sound nice in theory and=
get you hyped but once you have to start using them you tend form a differ=
ent opinion.</div><div><br></div><div>Regards,</div><div>Domen <br></div></=
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" 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/CAKgx6B%2BfkkdB_ag3E6NiZGVvdsf424%2Br=
Z40kwSzriWLRhw6S1w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6B%2Bfkk=
dB_ag3E6NiZGVvdsf424%2BrZ40kwSzriWLRhw6S1w%40mail.gmail.com</a>.<br />
--000000000000f1c0c3057358e0fa--
.
Author: Domen Vrankar <domen.vrankar@gmail.com>
Date: Tue, 14 Aug 2018 01:08:43 +0200
Raw View
--00000000000026e1840573592ff6
Content-Type: text/plain; charset="UTF-8"
2018-08-13 9:13 GMT+02:00 Hyman Rosen <hyman.rosen@gmail.com>:
> On Mon, Aug 13, 2018, 2:51 AM Richard Hodges <hodges.r@gmail.com> wrote:
>
>> The committee is clearly a bottleneck, I do agree. What could be done to
>> widen it?
>>
>
> Libraries don't belong in language standards. If, during library design,
> someone thinks that a language change would be helpful, then they can write
> a proposal just for that.
>
> People are being misled by history. STL and iostreams were the new shiny
> and a great way to show off what C++ could do, and C had a library, so
> everyone thought that a C++ standard ought to have one too. That was
> wrong, and doesn't need to be compounded with filesystems, regular
> expressions, Bessel functions, networking, or graphics. Special interest
> groups with subject-matter expertise can go off and standardize C++
> interfaces if they're so inclined.
>
>>
It's hard to agree with you... I never worked on really high performance
stuff so that's probably the reason why I don't recall those failures. For
me they were always good enough solutions that I was able to use for
prototyping and even production software.
It's nice that everybody has a plethora of time to implement everything
themselves, search for standard library alternatives before they know that
they will be the bottleneck in the particular software on which they work
and work on large scale products that need to handle millions of users and
so on. Unfortunately for me I come from the different direction - software
that has to first get established before it is feasible to poor allot of
money and effort into.
For such software you're between a rock and a hard place - you need to ship
fast and on low budget but later the successful products need to scale.
Well... You go with Java or PHP and on one hand hope that the product will
succeed as then you'll be able to continue working on it but on the other
hand you silently hope that it doesn't grow too much as then you'll have to
rewrite everything as those Java guys just don't like JNI.
From where I stand C++ went too much into large scale high performance
software while not caring how you get the software to that point.
Regards,
Domen
--
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/CAKgx6B%2BGxmOU6_xhHAOcVbU7r9mp0GrkSEo2jbPC9YHz2gmMxQ%40mail.gmail.com.
--00000000000026e1840573592ff6
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">2018=
-08-13 9:13 GMT+02:00 Hyman Rosen <span dir=3D"ltr"><<a href=3D"mailto:h=
yman.rosen@gmail.com" target=3D"_blank">hyman.rosen@gmail.com</a>></span=
>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><span class=3D""><di=
v class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr">On Mon, Aug 13, 2018,=
2:51 AM Richard Hodges <<a href=3D"mailto:hodges.r@gmail.com" target=3D=
"_blank">hodges.r@gmail.com</a>> wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>The committee is c=
learly a bottleneck, I do agree. What could be done to widen it?</div></div=
></div></blockquote></div><div dir=3D"auto"><br></div></span><div dir=3D"au=
to">Libraries don't belong in language standards.=C2=A0 If, during libr=
ary design, someone thinks that a language change would be helpful, then th=
ey can write a proposal just for that.</div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">People are being misled by history.=C2=A0 STL and iostreams =
were the new shiny and a great way to show off what C++ could do, and C had=
a library, so everyone thought that a C++ standard ought to have one too.=
=C2=A0 That was wrong, and doesn't need to be compounded with filesyste=
ms, regular expressions, Bessel functions, networking, or graphics.=C2=A0 S=
pecial interest groups with subject-matter expertise can go off and standar=
dize C++ interfaces if they're so inclined.</div><div class=3D"gmail_qu=
ote" dir=3D"auto"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div><span class=3D"">
</span></blockquote><div><br></div><div>It's hard to agree with you... =
I never worked on really high performance stuff so that's probably the =
reason why I don't recall those failures. For me they were always good =
enough solutions that I was able to use for prototyping and even production=
software.<br></div><div><br></div><div>It's nice that everybody has a =
plethora of time to implement everything themselves, search for standard li=
brary alternatives before they know that they will be the bottleneck in the=
particular software on which they work and work on large scale products th=
at need to handle millions of users and so on. Unfortunately for me I come =
from the different direction - software that has to first get established b=
efore it is feasible to poor allot of money and effort into.</div><div><br>=
</div><div>For such software you're between a rock and a hard place - y=
ou need to ship fast and on low budget but later the successful products ne=
ed to scale. Well... You go with Java or PHP and on one hand hope that the =
product will succeed as then you'll be able to continue working on it b=
ut on the other hand you silently hope that it doesn't grow too much as=
then you'll have to rewrite everything as those Java guys just don'=
;t like JNI.</div><div><br></div><div>From where I stand C++ went too much =
into large scale high performance software while not caring how you get the=
software to that point.</div><div><br></div><div>Regards,</div><div>Domen<=
br></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" 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/CAKgx6B%2BGxmOU6_xhHAOcVbU7r9mp0GrkSE=
o2jbPC9YHz2gmMxQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6B%2BGxmOU=
6_xhHAOcVbU7r9mp0GrkSEo2jbPC9YHz2gmMxQ%40mail.gmail.com</a>.<br />
--00000000000026e1840573592ff6--
.
Author: Domen Vrankar <domen.vrankar@gmail.com>
Date: Tue, 14 Aug 2018 01:47:13 +0200
Raw View
--000000000000d7b72e057359b80a
Content-Type: text/plain; charset="UTF-8"
2018-08-13 1:07 GMT+02:00 Nicol Bolas <jmckesson@gmail.com>:
> On Sunday, August 12, 2018 at 12:40:36 PM UTC-4, Richard Hodges wrote:
>>
>> On Sun, 12 Aug 2018 at 16:59, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> On Sunday, August 12, 2018 at 5:46:20 AM UTC-4, Richard Hodges wrote:
>>>>
>>>> On Sun, 12 Aug 2018 at 04:20, Rene Rivera <grafi...@gmail.com> wrote:
>>>>
>>>>> On Sat, Aug 11, 2018 at 8:19 PM <yakito...@gmail.com> wrote:
>>>>>
>>>>>> hello.
>>>>>>
>>>>>> i think anti paper is hateful.
>>>>>> thay look down the game programmer.
>>>>>>
>>>>>
>>>>> Speaking as a game programmer I can say I did not get the impression
>>>>> of the paper being hateful to anyone, especially game programmers. In the
>>>>> contrary it seems to go out of it's way to take into consideration the
>>>>> concerns of game programmers and others.
>>>>>
>>>>>
>>>>>> last.
>>>>>> i need 2d graphics for my task.
>>>>>>
>>>>>
>>>>> I don't doubt it. But do none of existing 2d libraries satisfy your
>>>>> requirement?
>>>>>
>>>>
>>>> I think this the crux of it.
>>>>
>>>> Of course the obvious answer is "yes". There are many fantastic
>>>> graphics libraries...
>>>>
>>>> ...and after spending 2 weeks of one's life trying to get them to
>>>> compile and run on all the platforms you want to support (because we all
>>>> want to write cross-platform software, right?) most of us lose the will to
>>>> live and go back to our horrible but reliable jobs not programming games.
>>>>
>>>
>>> So the problem has nothing to do with its appropriateness for the
>>> standard library. It's the fact that C++ has a terrible build/package
>>> environment. If you could download and use other libraries more easily,
>>> then you wouldn't need it to be in the standard library at all. We should
>>> not adopt standard library components primarily because C++ has a terrible
>>> build/package environment.
>>>
>>> Also, we are used to standard libraries being fast, high-performance
>>> tools. Containers, algorithms, these are usually well-optimized stuff in
>>> standard library implementations. So people tend to instinctively assume
>>> that the standard library's implementation of the graphics proposal would
>>> be equally high quality.
>>>
>>> So let's compare the quality of other high-level stuff in the standard
>>> library. Iostreams is pretty notorious for bad performance. People always
>>> blame iostream's performance primarily on its interface, the many virtual
>>> functions and the need for locale support. So maybe we can excuse it as
>>> being as good as iostreams' design allows.
>>>
>>> But what about Regex? From what I've gathered from others, most standard
>>> library regex implementations perform poorly. Boost.Regex is frequently
>>> much faster <https://stackoverflow.com/a/50611867/734069>, despite
>>> having virtually identical interfaces to `std::regex`. Here, there's no
>>> question; this is pure QoI, and the standard libraries aren't providing it.
>>> Despite having had a over decade to do so (regex was part of TR1, after
>>> all).
>>>
>>> What that tells me is that standard library implementers just don't care
>>> about higher-level stuff. Oh, they'll tick the feature box on their list of
>>> what the compiler supports. But unless big name users of their platforms
>>> *make* them optimize these things, they will not. And most big name
>>> users of C++ platforms aren't interested in using these high level tools.
>>> If you have a big C++ project and you needed regular expressions, you use
>>> some library. If `std::regex` didn't provide equivalent performance to that
>>> library, you ignored it.
>>>
>>
>> HTTP and HTML are standards. Vendors fought a vicious war over 20 years
>> to ensure that they had the "best" implementations. The result is an
>> extremely functional internet. Standards are only good.
>>
>
> This "extremely functional internet" is based on people spending an
> inordinate amount of time compensating for blatantly non-conformant,
> sometimes horribly inefficient, and possibly flat-out *broken*
> implementations of these standards, such that developers have to
> *constantly* test every webpage on a myriad of versions of a myriad of
> browsers just to make sure they actually work. The "extremely functional
> internet" is very much not write once, run anywhere.
>
It's hard not to agree with you in this regard but...
> Standards are only good when *followed*. When followed and
> well-implemented. How is having regex in the C++ standard good if nobody
> uses it because of how terrible implementations are? The time spent
> implementing it, however badly, is wasted. The time spent standardizing it
> is wasted. The time spent updating that part of the standard, keeping it in
> sync with the rest, is wasted.
>
> How is this a good, productive use of peoples' time?
>
> Nobody is going to ditch a standard library implementation over regex;
> they'll just download and use a different regex library. This is because
> changing standard library implementations is often a lot harder than
> installing a normal library. Also, it ensures that you get what you want
> rather than playing pot-luck with whatever implementations give you.
>
I don't recall the failure regex in C++ standard... In large scale, high
performance software this may be true (not my department - we've had much
larger bottlenecks elsewhere and most of the time still managed to get away
with it).
Before regex came into standard we preferred writing bash scripts for such
things or harder to maintain find/replace/substring/repeat C++ code if the
data could not be transformed before entering the program. Not a high
performance solution but since we didn't need the regex features that often
it was good enough and preferred to adding an additional external
dependency.
> Standards are not "only good"; they fail. They fail all the time. You just
> don't hear about the failures because... they failed; people don't tend to
> talk about failures unless they are spectacular. Standards which go
> unimplemented or unused have failed.
>
> IOstreams is mostly a failure. Regex in C++ failed. We don't need more
> failures in C++; certainly not 100+ pages of them.
>
> Standardising platform I/O - including graphics, consoles, keyboards, mice
>>>> and sound etc - would put the onus on the compiler-writing community to
>>>> solve this once for each platform, with the benefits being fanned out to
>>>> the global developer community. This is an O(1) solution in terms of
>>>> man-hours.
>>>>
>>>
>>>> The current situation is that a million developers must solve the same
>>>> infuriating problems a million times, and they must do it every time a
>>>> library or a compiler suite goes through a version increment. This is at
>>>> best O(N).
>>>>
>>>
>>>> In terms of lost man-hours alone, there is no possible argument that
>>>> can be made against standardisation of tools and libraries.
>>>>
>>>
>>> I'm not sure what "N" represents here (number of platforms, number of
>>> libraries, number of GPUs? And it's not like there's only one standard
>>> library implementation, or even one per-platform), but it doesn't really
>>> matter. The analysis is flawed in that it assumes that all man hours are
>>> equal.
>>>
>>
>> N is the number of teams who need to use a graphics library. At the
>> moment, every single one must figure out how to select, compile, patch,
>> bugfix (because, you know, open source) and figure out why a given library
>> works on one platform and not another. This is an utter waste of time.
>>
>
> How would this change by making it part of the standard library? Oh yes,
> you don't need to compile or install the standard library. But the standard
> library is hardly immune to bugs. And standard library bugs are usually
> harder to get rid of precisely *because* you didn't compile/install it.
> You have to go get its source code (if available) and then build from that.
> And to preserve your patches, you now need to effectively fork and
> frequently remerge from the main standard library line.
>
> This is an O(N) problem; this time will be "wasted" either way.
>
> I agree that packaging is a massive problem for c++, indeed its biggest
>> problem. I have some ideas on how to address that, and will be starting a
>> project to that effect once the Summer is over.
>>
>
> Remember: the reason C++ got into this mess to begin with was that
> everyone decided to write their own build systems. Everyone decided that
> they had their own needs and wrote incompatible build systems.
>
> So the last thing C++ needs is 10 different package management systems on
> top of its numerous build systems.
>
> There are already several similar projects underway with this goal in
> mind. Instead of making your own, pick the one you like the best. Even if
> you don't like it *at all*, just being better than the rest is enough.
> Spend your time helping it improve faster and making it better.
>
> C++ wins if we get *one* package management system. C++ loses if we get
> 10 incompatible ones.
>
> In a perfect world, maybe the standard library vendors would produce work
>>> of equivalent quality. But the C++ world is not, and will never be,
>>> perfect. Best to improve the good and mitigate the bad.
>>>
>>
>> I say we should focus on building the perfect world.
>>
>
> At what cost? The saying "the perfect is the enemy of the good" is often
> an overused platitude, but it is very apt in this case.
>
> The C++ standards committee only has finite amounts of time. LEWG is
> already overloaded; at the last meeting, they only reviewed *half* of the
> papers submitted for the standard library. And there, 2D graphics was
> talked about only for a single evening. A proper review of the 2D graphics
> TS would have absorbed a great deal of LWG's time
> <https://botondballo.wordpress.com/2018/03/28/trip-report-c-standards-meeting-in-jacksonville-march-2018/>,
> leaving even more things undone.
>
> What should be sacrificed for 2D graphics? `span`? Low-level filesystems
> work? Text formatting? Executors? Networking? Library support for
> `constexpr` heap allocations? What should be sacrificed on this altar?
>
> How many other things in C++ is this "perfect world" worth?
>
I agree with you here - 2D graphics proposal as it was presented is not
worth it. But that doesn't mean that language level package management
system would solve anything or that it wouldn't be feasible to add drawing
areas to the standard. I always hate it when I have to use OpenGL C api -
maybe that has changed with Vulkan C++ library that is supported by the
Khronos group (haven't checked it out yet) - and what is even more annoying
that quite often I can't use a graphics library in combination with my code
because they either try to force you to use the drawing area that their
library provides or have your rendering code conform to their api so much
that it's easier to just open up two windows and render your stuff on one
and the libraries on the other (not really scalable - maybe not even
solvable).
But if you want things to sacrifice on the altar... Even though I'll use
them once they get into the standard I'd sacrifice constexpr heap
allocations, low-level filesystem and text formatting for a definition of a
rendering surface (local and remote screen as well as back buffers that are
used for multi pass rendering) and some 2D and 3D math stuff (things that
are for example implemented in GLM library) even if the standard
implementations would perform worse than the libraries that I'm currently
using. For me prototyping and low resource input at the beginning of a
project are just as important as when the project gets more funding and
larger scope due to it being well received by the market. And for such
software (that wasn't born with high performance demands but requires them
once it has to scale) it's annoying to first have to write and maintain a
Java/C#/PHP version (prototypes quite often become first part of the
software - not smart but it happens - so prototyping languages win) and
then try to scale it into a different language once the demands grow.
For me this is not a learnability issue but a software scaling issue.
Regards,
Domen
--
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/CAKgx6B%2BXtX0eXnR8dxd-Cd29Ksjrv%2BoAqZ6QkDjGF9zkDY6%3D6Q%40mail.gmail.com.
--000000000000d7b72e057359b80a
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">2018=
-08-13 1:07 GMT+02:00 Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:j=
mckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span>:<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">On Sunday, August 12, 201=
8 at 12:40:36 PM UTC-4, Richard Hodges wrote:<span class=3D""><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div=
dir=3D"ltr">On Sun, 12 Aug 2018 at 16:59, Nicol Bolas <<a rel=3D"nofoll=
ow">jmck...@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr">On Sunday, August 12, 2018 at 5:46:20 AM UTC-4, Richard =
Hodges wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_quote"><div dir=3D"ltr">On Sun, 12 Aug 2018 at 04:20, Rene R=
ivera <<a rel=3D"nofollow">grafi...@gmail.com</a>> wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><d=
iv dir=3D"ltr">On Sat, Aug 11, 2018 at 8:19 PM <<a rel=3D"nofollow">yaki=
to...@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr"><div>hello.</div><div><br></div><div>i think anti paper is hat=
eful.</div><div>thay look down the game programmer.</div></div></blockquote=
><div><br></div><div>Speaking as a game programmer I can say I did not get =
the impression of the paper being hateful to anyone, especially game progra=
mmers. In the contrary it seems to go out of it's way to take into cons=
ideration the concerns of game programmers and others.</div><div>=C2=A0</di=
v><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>last.<br></div><div>=
i need 2d graphics for my task.</div></div></blockquote><div><br></div><div=
>I don't doubt it. But do none of existing 2d libraries satisfy your re=
quirement?</div></div></div></blockquote><div><br></div><div>I think this t=
he crux of it.</div><div><br></div><div>Of course the obvious answer is &qu=
ot;yes". There are many fantastic graphics libraries...</div><div><br>=
</div><div>...and after spending 2 weeks of one's life trying to get th=
em to compile and run on all the platforms you want to support (because we =
all want to write cross-platform software, right?) most of us lose the will=
to live and go back to our horrible but reliable jobs not programming game=
s.</div></div></div></blockquote><div><br></div><div>So the problem has not=
hing to do with its appropriateness for the standard library. It's the =
fact that C++ has a terrible build/package environment. If you could downlo=
ad and use other libraries more easily, then you wouldn't need it to be=
in the standard library at all. We should not adopt standard library compo=
nents primarily because C++ has a terrible build/package environment.<br></=
div><div><br></div><div>Also, we are used to standard libraries being fast,=
high-performance tools. Containers, algorithms, these are usually well-opt=
imized stuff in standard library implementations. So people tend to instinc=
tively assume that the standard library's implementation of the graphic=
s proposal would be equally high quality.</div><div><br></div><div>So let&#=
39;s compare the quality of other high-level stuff in the standard library.=
Iostreams is pretty notorious for bad performance. People always blame ios=
tream's performance primarily on its interface, the many virtual functi=
ons and the need for locale support. So maybe we can excuse it as being as =
good as iostreams' design allows.<br></div><div><br></div><div>But what=
about Regex? From what I've gathered from others, most standard librar=
y regex implementations perform poorly. <a href=3D"https://stackoverflow.co=
m/a/50611867/734069" rel=3D"nofollow" target=3D"_blank">Boost.Regex is freq=
uently much faster</a>, despite having virtually identical interfaces to `s=
td::regex`. Here, there's no question; this is pure QoI, and the standa=
rd libraries aren't providing it. Despite having had a over decade to d=
o so (regex was part of TR1, after all).<br></div><div><br></div><div>What =
that tells me is that standard library implementers just don't care abo=
ut higher-level stuff. Oh, they'll tick the feature box on their list o=
f what the compiler supports. But unless big name users of their platforms =
<i>make</i> them optimize these things, they will not. And most big name us=
ers of C++ platforms aren't interested in using these high level tools.=
If you have a big C++ project and you needed regular expressions, you use =
some library. If `std::regex` didn't provide equivalent performance to =
that library, you ignored it.</div></div></blockquote><div><br></div><div>H=
TTP and HTML are standards. Vendors fought a vicious war over 20 years to e=
nsure that they had the "best" implementations. The result is an =
extremely functional internet. Standards are only good.</div></div></div></=
blockquote><div><br></div></span><div>This "extremely functional inter=
net" is based on people spending an inordinate amount of time compensa=
ting for blatantly non-conformant, sometimes horribly inefficient, and poss=
ibly flat-out <i>broken</i> implementations of these standards, such that d=
evelopers have to <i>constantly</i> test every webpage on a myriad of versi=
ons of a myriad of browsers just to make sure they actually work. The "=
;extremely functional internet" is very much not write once, run anywh=
ere.<br></div></div></blockquote><div><br></div><div>It's hard not to a=
gree with you in this regard but...<br></div><div>=C2=A0</div><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"><div>Standards are only good when <i>fol=
lowed</i>. When followed and well-implemented. How is having regex in the C=
++ standard good if nobody uses it because of how terrible implementations =
are? The time spent implementing it, however badly, is wasted. The time spe=
nt standardizing it is wasted. The time spent updating that part of the sta=
ndard, keeping it in sync with the rest, is wasted.</div><div><br></div><di=
v><div>How is this a good, productive use of peoples' time?</div><div><=
br></div>Nobody is going to ditch a standard library implementation over re=
gex; they'll just download and use a different regex library. This is b=
ecause changing standard library implementations is often a lot harder than=
installing a normal library. Also, it ensures that you get what you want r=
ather than playing pot-luck with whatever implementations give you.<br></di=
v></div></blockquote><div><br></div><div>I don't recall the failure reg=
ex in C++ standard... In large scale, high performance software this may be=
true (not my department - we've had much larger bottlenecks elsewhere =
and most of the time still managed to get away with it).</div><div><br></di=
v><div>Before regex came into standard we preferred writing bash scripts=20
for such things or harder to maintain find/replace/substring/repeat C++=20
code
if the data could not be transformed before entering the program. Not a hig=
h performance solution but since we didn't need the regex features that=
often it was good enough and preferred to adding an additional external de=
pendency.<br></div><div>=C2=A0</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">Standards are not "only good"; they fail. They fail all =
the time. You just don't hear about the failures because... they failed=
; people don't tend to talk about failures unless they are spectacular.=
Standards which go unimplemented or unused have failed.<br><div><br></div>=
<div>IOstreams is mostly a failure. Regex in C++ failed. We don't need =
more failures in C++; certainly not 100+ pages of them.<br></div><span clas=
s=3D""><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"=
gmail_quote"><div>Standardising platform I/O - including graphics, consoles=
, keyboards, mice and sound etc - would put the onus on the compiler-writin=
g community to solve this once for each platform, with the benefits being f=
anned out to the global developer community. This is an O(1) solution in te=
rms of man-hours. <br></div></div></div></blockquote><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div><br></di=
v><div>The current situation is that a million developers must solve the sa=
me infuriating problems a million times, and they must do it every time a l=
ibrary or a compiler suite goes through a version increment. This is at bes=
t O(N).</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:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>In terms of lost man=
-hours alone, there is no possible argument that can be made against standa=
rdisation of tools and libraries.</div></div></div></blockquote><div><br></=
div><div>I'm not sure what "N" represents here (number of pla=
tforms, number of libraries, number of GPUs? And it's not like there=
9;s only one standard library implementation, or even one per-platform), bu=
t it doesn't really matter. The analysis is flawed in that it assumes t=
hat all man hours are equal.</div></div></blockquote><div><br></div><div>N =
is the number of teams who need to use a graphics library. At the moment, e=
very single one must figure out how to select, compile, patch, bugfix (beca=
use, you know, open source) and figure out why a given library works on one=
platform and not another. This is an utter waste of time.</div></div></div=
></blockquote><div><br></div></span><div>How would this change by making it=
part of the standard library? Oh yes, you don't need to compile or ins=
tall the standard library. But the standard library is hardly immune to bug=
s. And standard library bugs are usually harder to get rid of precisely <i>=
because</i> you didn't compile/install it. You have to go get its sourc=
e code (if available) and then build from that. And to preserve your patche=
s, you now need to effectively fork and frequently remerge from the main st=
andard library line.</div><div><br></div><div>This is an O(N) problem; this=
time will be "wasted" either way.</div><span class=3D""><div><br=
></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 class=
=3D"gmail_quote"><div>I agree that packaging is a massive problem for c++, =
indeed its biggest problem. I have some ideas on how to address that, and w=
ill be starting a project to that effect once the Summer is over.</div></di=
v></div></blockquote><div><br></div></span><div><div>Remember: the reason C=
++ got into this mess to begin with was that=20
everyone decided to write their own build systems. Everyone decided that
they had their own needs and wrote incompatible build systems.</div><div><=
br></div><div>So the last thing C++ needs is 10 different package managemen=
t systems on top of its numerous build systems.</div><div><br></div>There a=
re already several similar projects underway with this goal in mind. Instea=
d of making your own, pick the one you like the best. Even if you don't=
like it <i>at all</i>, just being better than the rest is enough. Spend yo=
ur time helping it improve faster and making it better.</div><div><br></div=
>C++ wins if we get <i>one</i> package management system. C++ loses if we g=
et 10 incompatible ones.<span class=3D""><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div>In a perfect world, maybe the =
standard library vendors would produce work of equivalent quality. But the =
C++ world is not, and will never be, perfect. Best to improve the good and =
mitigate the bad.<br></div></div></blockquote><div><br></div><div>I say we =
should focus on building the perfect world.</div></div></div></blockquote><=
div><br></div></span><div>At what cost? The saying "the perfect is the=
enemy of the good" is often an overused platitude, but it is very apt=
in this case.</div><div><br></div><div>The C++ standards committee only ha=
s finite amounts of time. LEWG is already overloaded; at the last meeting, =
they only reviewed <i>half</i> of the papers submitted for the standard lib=
rary. And there, 2D graphics was talked about only for a single evening. A =
proper review of the 2D graphics TS would have <a href=3D"https://botondbal=
lo.wordpress.com/2018/03/28/trip-report-c-standards-meeting-in-jacksonville=
-march-2018/" target=3D"_blank">absorbed a great deal of LWG's time</a>=
, leaving even more things undone.</div><div><br></div><div>What should be =
sacrificed for 2D graphics? `span`? Low-level filesystems work? Text format=
ting? Executors? Networking? Library support for `constexpr` heap allocatio=
ns? What should be sacrificed on this altar?</div><div><br></div><div>How m=
any other things in C++ is this "perfect world" worth?<br></div><=
/div><span class=3D"">
</span></blockquote><div><br></div><div>I agree with you here - 2D graphics=
proposal as it was presented is not worth it. But that doesn't mean th=
at language level package management system would solve anything or that it=
wouldn't be feasible to add drawing areas to the standard. I always ha=
te it when I have to use OpenGL C api - maybe that has changed with Vulkan =
C++ library that is supported by the Khronos group (haven't checked it =
out yet) - and what is even more annoying that quite often I can't use =
a graphics library in combination with my code because they either try to f=
orce you to use the drawing area that their library provides or have your r=
endering code conform to their api so much that it's easier to just ope=
n up two windows and render your stuff on one and the libraries on the othe=
r (not really scalable - maybe not even solvable).</div></div><div class=3D=
"gmail_quote"><br></div><div class=3D"gmail_quote">But if you want things t=
o sacrifice on the altar... Even though I'll use them once they get int=
o the standard I'd sacrifice constexpr heap allocations, low-level file=
system and text formatting for a definition of a rendering surface (local a=
nd remote screen as well as back buffers that are used for multi pass rende=
ring) and some 2D and 3D math stuff (things that are for example implemente=
d in GLM library) even if the standard implementations would perform worse =
than the libraries that I'm currently using. For me prototyping and low=
resource input at the beginning of a project are just as important as when=
the project gets more funding and larger scope due to it being well receiv=
ed by the market. And for such software (that wasn't born with high per=
formance demands but requires them once it has to scale) it's annoying =
to first have to write and maintain a Java/C#/PHP version (prototypes quite=
often become first part of the software - not smart but it happens - so pr=
ototyping languages win) and then try to scale it into a different language=
once the demands grow.</div><div class=3D"gmail_quote"><br></div><div clas=
s=3D"gmail_quote">For me this is not a learnability issue but a software sc=
aling issue.<br></div><div class=3D"gmail_quote"><br></div><div class=3D"gm=
ail_quote">Regards,</div><div class=3D"gmail_quote">Domen<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" 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/CAKgx6B%2BXtX0eXnR8dxd-Cd29Ksjrv%2BoA=
qZ6QkDjGF9zkDY6%3D6Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6B%2BX=
tX0eXnR8dxd-Cd29Ksjrv%2BoAqZ6QkDjGF9zkDY6%3D6Q%40mail.gmail.com</a>.<br />
--000000000000d7b72e057359b80a--
.