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

I just want to know if there is interest in represent xml, xhtml (I know xm=
l and xhtml are the same thing but I am saying this for completeness), and =
html as a c++ std container. The reason why I ask this is to allow C++ to w=
ork on xml with algorithms and iterators rather than raw loops, recursion, =
and pointers.

--=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/6d10a34f-a079-4f8e-88be-db8f17810314%40isocpp.or=
g.

------=_Part_1416_1495442905.1489027110505--

.

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

You mean the DOM?

On 9 March 2017 at 03:38, Vishal Oza <vickoza@gmail.com> wrote:

> I just want to know if there is interest in represent xml, xhtml (I know
> xml and xhtml are the same thing but I am saying this for completeness),
> and html as a c++ std container. The reason why I ask this is to allow C++
> to work on xml with algorithms and iterators rather than raw loops,
> recursion, and pointers.
>
> --
> 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/6d10a34f-a079-4f8e-
> 88be-db8f17810314%40isocpp.org.
>

--
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/CAOU91ONxXY92oZ26-bERcMMPAAmy%3DcBn4VmTGXxQ%3DzhqXiYibQ%40mail.gmail.com.

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

<div dir=3D"ltr">You mean the DOM?</div><div class=3D"gmail_extra"><br><div=
 class=3D"gmail_quote">On 9 March 2017 at 03:38, Vishal Oza <span dir=3D"lt=
r">&lt;<a href=3D"mailto:vickoza@gmail.com" target=3D"_blank">vickoza@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I just want to=
 know if there is interest in represent xml, xhtml (I know xml and xhtml ar=
e the same thing but I am saying this for completeness), and html as a c++ =
std container. The reason why I ask this is to allow C++ to work on xml wit=
h algorithms and iterators rather than raw loops, recursion, and pointers.<=
br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6d10a34f-a079-4f8e-88be-db8f17810314%=
40isocpp.org" rel=3D"noreferrer" target=3D"_blank">https://groups.google.co=
m/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/6d10a34f-a079-4f8e-<wbr>88be=
-db8f17810314%40isocpp.org</a><wbr>.<br>
</font></span></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOU91ONxXY92oZ26-bERcMMPAAmy%3DcBn4V=
mTGXxQ%3DzhqXiYibQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91ONxXY92=
oZ26-bERcMMPAAmy%3DcBn4VmTGXxQ%3DzhqXiYibQ%40mail.gmail.com</a>.<br />

--001a114974d83f1f9e054a497f79--

.

------=_Part_1766_966524385.1489074895416
Content-Type: text/plain; charset=UTF-8

Yes, in my proposal I would suggest to have node xml objects as real object, and limit the use of pointers to stuff that handle to underlining implmenation

--
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/f86266f7-c953-4232-8a7a-7d77a600b15e%40isocpp.org.

------=_Part_1766_966524385.1489074895416--

.

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

It have been proposed before at least one time I think.
See this discussion for example:
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/4k7vboSe8S8


On 9 March 2017 at 16:54, Vishal Oza <vickoza@gmail.com> wrote:

> Yes, in my proposal I would suggest to have node xml objects as real
> object, and limit the use of pointers to stuff that handle to underlining
> implmenation
>
> --
> 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/f86266f7-c953-4232-
> 8a7a-7d77a600b15e%40isocpp.org.
>

--
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/CAOU91ONuHj6A67Xv4CvFNZ0vZJLG--gnyzpCpoMuaAzTHCckdg%40mail.gmail.com.

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

<div dir=3D"ltr">It have been proposed before at least one time I think.<di=
v>See this discussion for example:=C2=A0<a href=3D"https://groups.google.co=
m/a/isocpp.org/forum/#!topic/std-proposals/4k7vboSe8S8">https://groups.goog=
le.com/a/isocpp.org/forum/#!topic/std-proposals/4k7vboSe8S8</a></div><div><=
br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On=
 9 March 2017 at 16:54, Vishal Oza <span dir=3D"ltr">&lt;<a href=3D"mailto:=
vickoza@gmail.com" target=3D"_blank">vickoza@gmail.com</a>&gt;</span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">Yes, in my proposal I would suggest to =
have node xml objects as real object, and limit the use of pointers to stuf=
f that handle to underlining implmenation<br>
<span class=3D""><br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/f86266f7-c953-4232-8a7a-7d77a6=
00b15e%40isocpp.org" rel=3D"noreferrer" target=3D"_blank">https://groups.go=
ogle.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/f86266f7-c953-4232-<w=
br>8a7a-7d77a600b15e%40isocpp.org</a><wbr>.<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOU91ONuHj6A67Xv4CvFNZ0vZJLG--gnyzpC=
poMuaAzTHCckdg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91ONuHj6A67Xv=
4CvFNZ0vZJLG--gnyzpCpoMuaAzTHCckdg%40mail.gmail.com</a>.<br />

--f403045f50d0d61b5b054a6318aa--

.

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

On Fri, Mar 10, 2017 at 1:46 PM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.c=
om>
wrote:

> It have been proposed before at least one time I think.
> See this discussion for example: https://groups.
> google.com/a/isocpp.org/forum/#!topic/std-proposals/4k7vboSe8S8
>
>
First JSON, now XML, then YAML, and let's keep counting.
What is the problem of having libraries and letting the interface be part
of their quality, not only the implementation?
I really don't think that the STL should be such an elephant covering every
single niche. There are library vendors for that. Boost being one of them.


>
> On 9 March 2017 at 16:54, Vishal Oza <vickoza@gmail.com> wrote:
>
>> Yes, in my proposal I would suggest to have node xml objects as real
>> object, and limit the use of pointers to stuff that handle to underlinin=
g
>> implmenation
>>
>> --
>> 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/is
>> ocpp.org/d/msgid/std-proposals/f86266f7-c953-4232-8a7a-
>> 7d77a600b15e%40isocpp.org.
>>
>
> --
> 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/CAOU91ONuHj6A67Xv4CvFNZ0vZJLG-
> -gnyzpCpoMuaAzTHCckdg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91ONuHj=
6A67Xv4CvFNZ0vZJLG--gnyzpCpoMuaAzTHCckdg%40mail.gmail.com?utm_medium=3Demai=
l&utm_source=3Dfooter>
> .
>



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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/CAFdMc-1PNO1XFWKU_ug2%2B%2Bzn_mD24f_Hj5Dbfs1a1wU=
H3HUEQg%40mail.gmail.com.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Mar 10, 2017 at 1:46 PM, Klaim - Jo=C3=ABl Lamotte <span dir=3D=
"ltr">&lt;<a href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gm=
ail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr">It have been proposed before at least one time I think.<div>See this =
discussion for example:=C2=A0<a href=3D"https://groups.google.com/a/isocpp.=
org/forum/#!topic/std-proposals/4k7vboSe8S8" target=3D"_blank">https://grou=
ps.<wbr>google.com/a/isocpp.org/forum/<wbr>#!topic/std-proposals/<wbr>4k7vb=
oSe8S8</a></div><div><br></div></div></blockquote><div><br></div><div>First=
 JSON, now XML, then YAML, and let&#39;s keep counting.</div><div>What is t=
he problem of having libraries and letting the interface be part of their q=
uality, not only the implementation?</div><div>I really don&#39;t think tha=
t the STL should be such an elephant covering every single niche. There are=
 library vendors for that. Boost being one of them.</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></div></div><div><div c=
lass=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 9 =
March 2017 at 16:54, Vishal Oza <span dir=3D"ltr">&lt;<a href=3D"mailto:vic=
koza@gmail.com" target=3D"_blank">vickoza@gmail.com</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">Yes, in my proposal I would suggest to hav=
e node xml objects as real object, and limit the use of pointers to stuff t=
hat handle to underlining implmenation<br>
<span><br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/f86266f7-c953-4232-8a7a-7d77a6=
00b15e%40isocpp.org" rel=3D"noreferrer" target=3D"_blank">https://groups.go=
ogle.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/f86266f7-c953-4232-8a=
7a-<wbr>7d77a600b15e%40isocpp.org</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&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></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/CAOU91ONuHj6A67Xv4CvFNZ0vZJLG--gnyzpC=
poMuaAzTHCckdg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/<wbr>CAOU91ONuHj6A67Xv4CvFNZ0vZJLG-<wbr>-gnyzpCpoMuaAzTHCckd=
g%40mail.<wbr>gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature">Who=E2=80=99s got t=
he sweetest disposition?<br>One guess, that=E2=80=99s who?<br>Who=E2=80=99d=
 never, ever start an argument?<br>Who never shows a bit of temperament?<br=
>Who&#39;s never wrong but always right?<br>Who&#39;d never dream of starti=
ng a fight?<br>Who get stuck with all the bad luck? </div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1PNO1XFWKU_ug2%2B%2Bzn_mD24f_H=
j5Dbfs1a1wUH3HUEQg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1PNO1X=
FWKU_ug2%2B%2Bzn_mD24f_Hj5Dbfs1a1wUH3HUEQg%40mail.gmail.com</a>.<br />

--94eb2c0a6358d9ea19054a640a30--

.

------=_Part_538_101800183.1489430269978
Content-Type: multipart/alternative;
 boundary="----=_Part_539_1524418417.1489430269978"

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



On Friday, March 10, 2017 at 12:53:44 PM UTC-5, dgutson wrote:
>
>
>
> On Fri, Mar 10, 2017 at 1:46 PM, Klaim - Jo=C3=ABl Lamotte <mjk...@gmail.=
com=20
> <javascript:>> wrote:
>
>> It have been proposed before at least one time I think.
>> See this discussion for example:=20
>> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/4k7vb=
oSe8S8
>>
>>
> First JSON, now XML, then YAML, and let's keep counting.
> What is the problem of having libraries and letting the interface be part=
=20
> of their quality, not only the implementation?
> I really don't think that the STL should be such an elephant covering=20
> every single niche. There are library vendors for that. Boost being one o=
f=20
> them.
>

While I understand the argument in general, for the specific cases=20
mentioned here, there are very good arguments for providing such things.=20
It's all a matter of user-space and ease of usability.

C++ has a very small standard library. Which means that if you want to=20
actually do something in C++ of significance, you have to either write it=
=20
yourself or use a library. The problem with the latter is that C++ is also=
=20
*terrible* at making it easy to incorporate other libraries into your build=
..

Just look at Boost. It's a *gigantic* ball of stuff. If Boost had an XML=20
processor, how much other stuff would you have to include just to be able=
=20
to process XML? Do you really need all of the other stuff Boost provides?=
=20
Probably not.

And what of smaller libraries? Some of them use CMake as their build=20
system. Others use straight-up makefiles. Others do something else. And=20
they all vary in quality.

Oh sure, there is the danger of standardizing something that isn't used=20
very often, or some technology that goes out of fashion or whatever. But at=
=20
some point, C++ needs to grow up and start providing people with tools=20
beyond basic stuff like containers and algorithms. Because people need=20
those things, and the C++ world makes it very difficult to get them. Either=
=20
we provide them, or they will move on to languages that do.

--=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/2be00155-b115-4226-aa51-37ed9b3df075%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Friday, March 10, 2017 at 12:53:44 PM UTC-5, dg=
utson 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"><=
br><div><br><div class=3D"gmail_quote">On Fri, Mar 10, 2017 at 1:46 PM, Kla=
im - Jo=C3=ABl Lamotte <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"bHhH50x-DAAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;">mjk...@gmail.com</a>&gt;</span> wro=
te:<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">It have been propose=
d before at least one time I think.<div>See this discussion for example:=C2=
=A0<a href=3D"https://groups.google.com/a/isocpp.org/forum/#!topic/std-prop=
osals/4k7vboSe8S8" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D&#39;https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposa=
ls/4k7vboSe8S8&#39;;return true;" onclick=3D"this.href=3D&#39;https://group=
s.google.com/a/isocpp.org/forum/#!topic/std-proposals/4k7vboSe8S8&#39;;retu=
rn true;">https://groups.<wbr>google.com/a/isocpp.org/forum/<wbr>#!topic/st=
d-proposals/<wbr>4k7vboSe8S8</a></div><div><br></div></div></blockquote><di=
v><br></div><div>First JSON, now XML, then YAML, and let&#39;s keep countin=
g.</div><div>What is the problem of having libraries and letting the interf=
ace be part of their quality, not only the implementation?</div><div>I real=
ly don&#39;t think that the STL should be such an elephant covering every s=
ingle niche. There are library vendors for that. Boost being one of them.</=
div></div></div></div></blockquote><div><br>While I understand the argument=
 in general, for the specific cases mentioned here, there are very good arg=
uments for providing such things. It&#39;s all a matter of user-space and e=
ase of usability.<br><br>C++ has a very small standard library. Which means=
 that if you want to actually do something in C++ of significance, you have=
 to either write it yourself or use a library. The problem with the latter =
is that C++ is also <i>terrible</i> at making it easy to incorporate other =
libraries into your build.<br><br>Just look at Boost. It&#39;s a <i>giganti=
c</i> ball of stuff. If Boost had an XML processor, how much other stuff wo=
uld you have to include just to be able to process XML? Do you really need =
all of the other stuff Boost provides? Probably not.<br><br>And what of sma=
ller libraries? Some of them use CMake as their build system. Others use st=
raight-up makefiles. Others do something else. And they all vary in quality=
..<br><br>Oh sure, there is the danger of standardizing something that isn&#=
39;t used very often, or some technology that goes out of fashion or whatev=
er. But at some point, C++ needs to grow up and start providing people with=
 tools beyond basic stuff like containers and algorithms. Because people ne=
ed those things, and the C++ world makes it very difficult to get them. Eit=
her we provide them, or they will move on to languages that do.<br></div></=
div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2be00155-b115-4226-aa51-37ed9b3df075%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2be00155-b115-4226-aa51-37ed9b3df075=
%40isocpp.org</a>.<br />

------=_Part_539_1524418417.1489430269978--

------=_Part_538_101800183.1489430269978--

.

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

On Mon, Mar 13, 2017 at 3:37 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

>
>
> On Friday, March 10, 2017 at 12:53:44 PM UTC-5, dgutson wrote:
>>
>>
>>
>> On Fri, Mar 10, 2017 at 1:46 PM, Klaim - Jo=C3=ABl Lamotte <mjk...@gmail=
..com>
>> wrote:
>>
>>> It have been proposed before at least one time I think.
>>> See this discussion for example: https://groups.google
>>> .com/a/isocpp.org/forum/#!topic/std-proposals/4k7vboSe8S8
>>>
>>>
>> First JSON, now XML, then YAML, and let's keep counting.
>> What is the problem of having libraries and letting the interface be par=
t
>> of their quality, not only the implementation?
>> I really don't think that the STL should be such an elephant covering
>> every single niche. There are library vendors for that. Boost being one =
of
>> them.
>>
>
> While I understand the argument in general, for the specific cases
> mentioned here, there are very good arguments for providing such things.
> It's all a matter of user-space and ease of usability.
>
> C++ has a very small standard library. Which means that if you want to
> actually do something in C++ of significance, you have to either write it
> yourself or use a library. The problem with the latter is that C++ is als=
o
> *terrible* at making it easy to incorporate other libraries into your
> build.
>
> Just look at Boost. It's a *gigantic* ball of stuff. If Boost had an XML
> processor, how much other stuff would you have to include just to be able
> to process XML? Do you really need all of the other stuff Boost provides?
> Probably not.
>
> And what of smaller libraries? Some of them use CMake as their build
> system. Others use straight-up makefiles. Others do something else. And
> they all vary in quality.
>

This sounds me more a problem related to modules and/or standardizing the
build system (feasible or not, out of mail scope).



>
> Oh sure, there is the danger of standardizing something that isn't used
> very often, or some technology that goes out of fashion or whatever. But =
at
> some point, C++ needs to grow up and start providing people with tools
> beyond basic stuff like containers and algorithms. Because people need
> those things, and the C++ world makes it very difficult to get them. Eith=
er
> we provide them, or they will move on to languages that do.
>
> --
> 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/2be00155-b115-4226-
> aa51-37ed9b3df075%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2be00155-b1=
15-4226-aa51-37ed9b3df075%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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/CAFdMc-1HiQBm9noWX3kO_rzhL9BAfRZzOnON2cak910muHn=
GGg%40mail.gmail.com.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Mar 13, 2017 at 3:37 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>=
<br>On Friday, March 10, 2017 at 12:53:44 PM UTC-5, dgutson wrote:<span cla=
ss=3D""><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"><br><div><=
br><div class=3D"gmail_quote">On Fri, Mar 10, 2017 at 1:46 PM, Klaim - Jo=
=C3=ABl Lamotte <span dir=3D"ltr">&lt;<a rel=3D"nofollow">mjk...@gmail.com<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">It=
 have been proposed before at least one time I think.<div>See this discussi=
on for example:=C2=A0<a href=3D"https://groups.google.com/a/isocpp.org/foru=
m/#!topic/std-proposals/4k7vboSe8S8" rel=3D"nofollow" target=3D"_blank">htt=
ps://groups.google<wbr>.com/a/isocpp.org/forum/#!<wbr>topic/std-proposals/4=
k7vboSe8S<wbr>8</a></div><div><br></div></div></blockquote><div><br></div><=
div>First JSON, now XML, then YAML, and let&#39;s keep counting.</div><div>=
What is the problem of having libraries and letting the interface be part o=
f their quality, not only the implementation?</div><div>I really don&#39;t =
think that the STL should be such an elephant covering every single niche. =
There are library vendors for that. Boost being one of them.</div></div></d=
iv></div></blockquote></span><div><br>While I understand the argument in ge=
neral, for the specific cases mentioned here, there are very good arguments=
 for providing such things. It&#39;s all a matter of user-space and ease of=
 usability.<br><br>C++ has a very small standard library. Which means that =
if you want to actually do something in C++ of significance, you have to ei=
ther write it yourself or use a library. The problem with the latter is tha=
t C++ is also <i>terrible</i> at making it easy to incorporate other librar=
ies into your build.<br><br>Just look at Boost. It&#39;s a <i>gigantic</i> =
ball of stuff. If Boost had an XML processor, how much other stuff would yo=
u have to include just to be able to process XML? Do you really need all of=
 the other stuff Boost provides? Probably not.<br><br>And what of smaller l=
ibraries? Some of them use CMake as their build system. Others use straight=
-up makefiles. Others do something else. And they all vary in quality.<br><=
/div></div></blockquote><div><br></div><div>This sounds me more a problem r=
elated to modules and/or standardizing the build system (feasible or not, o=
ut of mail scope).</div><div><br></div><div>=C2=A0</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><br>Oh sure, there is the danger of sta=
ndardizing something that isn&#39;t used very often, or some technology tha=
t goes out of fashion or whatever. But at some point, C++ needs to grow up =
and start providing people with tools beyond basic stuff like containers an=
d algorithms. Because people need those things, and the C++ world makes it =
very difficult to get them. Either we provide them, or they will move on to=
 languages that do.<br></div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2be00155-b115-4226-aa51-37ed9b3df075%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/2be0=
0155-b115-4226-<wbr>aa51-37ed9b3df075%40isocpp.org</a><wbr>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature">Who=E2=80=99s got t=
he sweetest disposition?<br>One guess, that=E2=80=99s who?<br>Who=E2=80=99d=
 never, ever start an argument?<br>Who never shows a bit of temperament?<br=
>Who&#39;s never wrong but always right?<br>Who&#39;d never dream of starti=
ng a fight?<br>Who get stuck with all the bad luck? </div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1HiQBm9noWX3kO_rzhL9BAfRZzOnON=
2cak910muHnGGg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1HiQBm9noW=
X3kO_rzhL9BAfRZzOnON2cak910muHnGGg%40mail.gmail.com</a>.<br />

--001a114dcb986db3fc054aa25c12--

.

------=_Part_3455_2081808521.1489437653590
Content-Type: multipart/alternative;
 boundary="----=_Part_3456_941880485.1489437653590"

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

On Monday, March 13, 2017 at 4:14:41 PM UTC-4, dgutson wrote:
>
> On Mon, Mar 13, 2017 at 3:37 PM, Nicol Bolas <jmck...@gmail.com=20
> <javascript:>> wrote:
>
>> On Friday, March 10, 2017 at 12:53:44 PM UTC-5, dgutson wrote:
>>>
>>> On Fri, Mar 10, 2017 at 1:46 PM, Klaim - Jo=C3=ABl Lamotte <mjk...@gmai=
l.com>=20
>>> wrote:
>>>
>>>> It have been proposed before at least one time I think.
>>>> See this discussion for example:=20
>>>> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/4k7=
vboSe8S8
>>>>
>>>>
>>> First JSON, now XML, then YAML, and let's keep counting.
>>> What is the problem of having libraries and letting the interface be=20
>>> part of their quality, not only the implementation?
>>> I really don't think that the STL should be such an elephant covering=
=20
>>> every single niche. There are library vendors for that. Boost being one=
 of=20
>>> them.
>>>
>>
>> While I understand the argument in general, for the specific cases=20
>> mentioned here, there are very good arguments for providing such things.=
=20
>> It's all a matter of user-space and ease of usability.
>>
>> C++ has a very small standard library. Which means that if you want to=
=20
>> actually do something in C++ of significance, you have to either write i=
t=20
>> yourself or use a library. The problem with the latter is that C++ is al=
so=20
>> *terrible* at making it easy to incorporate other libraries into your=20
>> build.
>>
>> Just look at Boost. It's a *gigantic* ball of stuff. If Boost had an XML=
=20
>> processor, how much other stuff would you have to include just to be abl=
e=20
>> to process XML? Do you really need all of the other stuff Boost provides=
?=20
>> Probably not.
>>
>> And what of smaller libraries? Some of them use CMake as their build=20
>> system. Others use straight-up makefiles. Others do something else. And=
=20
>> they all vary in quality.
>>
>
> This sounds me more a problem related to modules and/or standardizing the=
=20
> build system (feasible or not, out of mail scope).
>

That is what makes the argument compelling. Solving the build system=20
problem is out of scope for the committee. But making the standard library=
=20
more useful out-of-the-box is *not* out of scope. So why not do something=
=20
that helps alleviate the problem to the extent that they can?

What precisely is the advantage of having a tiny standard library?=20
Ease-of-implementation might be one, but C++ is already a difficult=20
language to implement. And writing a *quality* standard library=20
implementation is quite difficult as well. So adding a few more things on=
=20
top of that isn't exactly overburdening implementers.

--=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/4eca4363-0541-4dff-ab53-993c73b4b34b%40isocpp.or=
g.

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

<div dir=3D"ltr">On Monday, March 13, 2017 at 4:14:41 PM UTC-4, dgutson wro=
te:<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 Mon, Mar 13, 2017 at 3:37 PM, Nicol Bolas <span di=
r=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"Qd68ctxZEQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><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">On Friday, March 10, 2017 at 12:53:44 PM UTC-5, dg=
utson wrote:<span><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><div class=3D"gmail_quote">On Fri, Mar 10, 2017 at 1:46 PM, Klaim - Jo=
=C3=ABl Lamotte <span dir=3D"ltr">&lt;<a rel=3D"nofollow">mjk...@gmail.com<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">It=
 have been proposed before at least one time I think.<div>See this discussi=
on for example:=C2=A0<a href=3D"https://groups.google.com/a/isocpp.org/foru=
m/#!topic/std-proposals/4k7vboSe8S8" rel=3D"nofollow" target=3D"_blank" onm=
ousedown=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/forum/#=
!topic/std-proposals/4k7vboSe8S8&#39;;return true;" onclick=3D"this.href=3D=
&#39;https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/4k7=
vboSe8S8&#39;;return true;">https://groups.<wbr>google.com/a/isocpp.org/for=
um/<wbr>#!topic/std-proposals/<wbr>4k7vboSe8S8</a></div><div><br></div></di=
v></blockquote><div><br></div><div>First JSON, now XML, then YAML, and let&=
#39;s keep counting.</div><div>What is the problem of having libraries and =
letting the interface be part of their quality, not only the implementation=
?</div><div>I really don&#39;t think that the STL should be such an elephan=
t covering every single niche. There are library vendors for that. Boost be=
ing one of them.</div></div></div></div></blockquote></span><div><br>While =
I understand the argument in general, for the specific cases mentioned here=
, there are very good arguments for providing such things. It&#39;s all a m=
atter of user-space and ease of usability.<br><br>C++ has a very small stan=
dard library. Which means that if you want to actually do something in C++ =
of significance, you have to either write it yourself or use a library. The=
 problem with the latter is that C++ is also <i>terrible</i> at making it e=
asy to incorporate other libraries into your build.<br><br>Just look at Boo=
st. It&#39;s a <i>gigantic</i> ball of stuff. If Boost had an XML processor=
, how much other stuff would you have to include just to be able to process=
 XML? Do you really need all of the other stuff Boost provides? Probably no=
t.<br><br>And what of smaller libraries? Some of them use CMake as their bu=
ild system. Others use straight-up makefiles. Others do something else. And=
 they all vary in quality.<br></div></div></blockquote><div><br></div><div>=
This sounds me more a problem related to modules and/or standardizing the b=
uild system (feasible or not, out of mail scope).</div></div></div></div></=
blockquote><div><br>That is what makes the argument compelling. Solving the=
 build system problem is out of scope for the committee. But making the sta=
ndard library more useful out-of-the-box is <i>not</i> out of scope. So why=
 not do something that helps alleviate the problem to the extent that they =
can?<br><br>What precisely is the advantage of having a tiny standard libra=
ry? Ease-of-implementation might be one, but C++ is already a difficult lan=
guage to implement. And writing a <i>quality</i> standard library implement=
ation is quite difficult as well. So adding a few more things on top of tha=
t isn&#39;t exactly overburdening implementers.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4eca4363-0541-4dff-ab53-993c73b4b34b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4eca4363-0541-4dff-ab53-993c73b4b34b=
%40isocpp.org</a>.<br />

------=_Part_3456_941880485.1489437653590--

------=_Part_3455_2081808521.1489437653590--

.

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

On Mon, Mar 13, 2017 at 5:40 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Monday, March 13, 2017 at 4:14:41 PM UTC-4, dgutson wrote:
>>
>> On Mon, Mar 13, 2017 at 3:37 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> On Friday, March 10, 2017 at 12:53:44 PM UTC-5, dgutson wrote:
>>>>
>>>> On Fri, Mar 10, 2017 at 1:46 PM, Klaim - Jo=C3=ABl Lamotte <mjk...@gma=
il.com
>>>> > wrote:
>>>>
>>>>> It have been proposed before at least one time I think.
>>>>> See this discussion for example: https://groups.google
>>>>> .com/a/isocpp.org/forum/#!topic/std-proposals/4k7vboSe8S8
>>>>>
>>>>>
>>>> First JSON, now XML, then YAML, and let's keep counting.
>>>> What is the problem of having libraries and letting the interface be
>>>> part of their quality, not only the implementation?
>>>> I really don't think that the STL should be such an elephant covering
>>>> every single niche. There are library vendors for that. Boost being on=
e of
>>>> them.
>>>>
>>>
>>> While I understand the argument in general, for the specific cases
>>> mentioned here, there are very good arguments for providing such things=
..
>>> It's all a matter of user-space and ease of usability.
>>>
>>> C++ has a very small standard library. Which means that if you want to
>>> actually do something in C++ of significance, you have to either write =
it
>>> yourself or use a library. The problem with the latter is that C++ is a=
lso
>>> *terrible* at making it easy to incorporate other libraries into your
>>> build.
>>>
>>> Just look at Boost. It's a *gigantic* ball of stuff. If Boost had an
>>> XML processor, how much other stuff would you have to include just to b=
e
>>> able to process XML? Do you really need all of the other stuff Boost
>>> provides? Probably not.
>>>
>>> And what of smaller libraries? Some of them use CMake as their build
>>> system. Others use straight-up makefiles. Others do something else. And
>>> they all vary in quality.
>>>
>>
>> This sounds me more a problem related to modules and/or standardizing th=
e
>> build system (feasible or not, out of mail scope).
>>
>
> That is what makes the argument compelling. Solving the build system
> problem is out of scope for the committee. But making the standard librar=
y
> more useful out-of-the-box is *not* out of scope. So why not do something
> that helps alleviate the problem to the extent that they can?
>

I insist: you solve the issue you mentioned with modules. Wait for them and
you and everybody will be happier xml users.


>
> What precisely is the advantage of having a tiny standard library?
> Ease-of-implementation might be one, but C++ is already a difficult
> language to implement. And writing a *quality* standard library
> implementation is quite difficult as well. So adding a few more things on
> top of that isn't exactly overburdening implementers.
>

that's it. no more contributions from me to this thread.


> --
> 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/4eca4363-0541-4dff-
> ab53-993c73b4b34b%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4eca4363-05=
41-4dff-ab53-993c73b4b34b%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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/CAFdMc-2FFWaqFedrNbBAgzfCt8rPODdqb6bmyWdorAuETOA=
NWg%40mail.gmail.com.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Mar 13, 2017 at 5:40 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On M=
onday, March 13, 2017 at 4:14:41 PM UTC-4, dgutson wrote:<span class=3D""><=
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 Mon, Mar 13, 2017 at 3:37 PM, Nicol Bolas <span dir=3D"ltr"=
>&lt;<a rel=3D"nofollow">jmck...@gmail.com</a>&gt;</span> wrote:<br><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">On Friday, March 10, 2017 at 12:53=
:44 PM UTC-5, dgutson 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><div class=3D"gmail_quote">On Fri, Mar 10, 2017 at 1=
:46 PM, Klaim - Jo=C3=ABl Lamotte <span dir=3D"ltr">&lt;<a rel=3D"nofollow"=
>mjk...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr">It have been proposed before at least one time I think.<div=
>See this discussion for example:=C2=A0<a href=3D"https://groups.google.com=
/a/isocpp.org/forum/#!topic/std-proposals/4k7vboSe8S8" rel=3D"nofollow" tar=
get=3D"_blank">https://groups.google<wbr>.com/a/isocpp.org/forum/#!<wbr>top=
ic/std-proposals/4k7vboSe8S<wbr>8</a></div><div><br></div></div></blockquot=
e><div><br></div><div>First JSON, now XML, then YAML, and let&#39;s keep co=
unting.</div><div>What is the problem of having libraries and letting the i=
nterface be part of their quality, not only the implementation?</div><div>I=
 really don&#39;t think that the STL should be such an elephant covering ev=
ery single niche. There are library vendors for that. Boost being one of th=
em.</div></div></div></div></blockquote></span><div><br>While I understand =
the argument in general, for the specific cases mentioned here, there are v=
ery good arguments for providing such things. It&#39;s all a matter of user=
-space and ease of usability.<br><br>C++ has a very small standard library.=
 Which means that if you want to actually do something in C++ of significan=
ce, you have to either write it yourself or use a library. The problem with=
 the latter is that C++ is also <i>terrible</i> at making it easy to incorp=
orate other libraries into your build.<br><br>Just look at Boost. It&#39;s =
a <i>gigantic</i> ball of stuff. If Boost had an XML processor, how much ot=
her stuff would you have to include just to be able to process XML? Do you =
really need all of the other stuff Boost provides? Probably not.<br><br>And=
 what of smaller libraries? Some of them use CMake as their build system. O=
thers use straight-up makefiles. Others do something else. And they all var=
y in quality.<br></div></div></blockquote><div><br></div><div>This sounds m=
e more a problem related to modules and/or standardizing the build system (=
feasible or not, out of mail scope).</div></div></div></div></blockquote></=
span><div><br>That is what makes the argument compelling. Solving the build=
 system problem is out of scope for the committee. But making the standard =
library more useful out-of-the-box is <i>not</i> out of scope. So why not d=
o something that helps alleviate the problem to the extent that they can?<b=
r></div></div></blockquote><div><br></div><div>I insist: you solve the issu=
e you mentioned with modules. Wait for them and you and everybody will be h=
appier xml users.</div><div>=C2=A0</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><br>What precisely is the advantage of having a tiny stan=
dard library? Ease-of-implementation might be one, but C++ is already a dif=
ficult language to implement. And writing a <i>quality</i> standard library=
 implementation is quite difficult as well. So adding a few more things on =
top of that isn&#39;t exactly overburdening implementers.<br></div></div></=
blockquote><div><br></div><div>that&#39;s it. no more contributions from me=
 to this thread.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div></div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4eca4363-0541-4dff-ab53-993c73b4b34b%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/4eca=
4363-0541-4dff-<wbr>ab53-993c73b4b34b%40isocpp.org</a><wbr>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature">Who=E2=80=99s got t=
he sweetest disposition?<br>One guess, that=E2=80=99s who?<br>Who=E2=80=99d=
 never, ever start an argument?<br>Who never shows a bit of temperament?<br=
>Who&#39;s never wrong but always right?<br>Who&#39;d never dream of starti=
ng a fight?<br>Who get stuck with all the bad luck? </div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2FFWaqFedrNbBAgzfCt8rPODdqb6bm=
yWdorAuETOANWg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2FFWaqFedr=
NbBAgzfCt8rPODdqb6bmyWdorAuETOANWg%40mail.gmail.com</a>.<br />

--001a114db8ea4e9817054aa38aba--

.

------=_Part_4271_473972604.1489533950488
Content-Type: multipart/alternative;
 boundary="----=_Part_4272_2082188789.1489533950488"

------=_Part_4272_2082188789.1489533950488
Content-Type: text/plain; charset=UTF-8

I think Nicol nailed it when it comes to describing the situation. What I
would like to see is a set of libraries that are layered on top of the
current standard library and reaches further into application land. XML
parsing is a very good example. The main difference from the current
library would be that it is a source code component rather than a
specification. This way the burden on compiler vendors is minimized, but to
be standard compliant the libraries must be delivered with the compiler
offering. Maybe ISO is not the right "host" for such an offering but
some3one must put pressure on the compiler vendors to take the effort to
integrate these libraries and distribute them in an as easy to use form as
the current libraries. To me it seems that the old conflict between open
source and commercial interests have abated enough to make something like
this possible. There are so many good libraries out there but it takes so
much time to get them into a useful state of compilation... so much wasted
programmer time.

--
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/5de8bb0d-a20e-47ee-8558-993a4d25c540%40isocpp.org.

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

<div dir=3D"ltr">I think Nicol nailed it when it comes to describing the si=
tuation. What I would like to see is a set of libraries that are layered on=
 top of the current standard library and reaches further into application l=
and. XML parsing is a very good example. The main difference from the curre=
nt<div>library would be that it is a source code component rather than a sp=
ecification. This way the burden on compiler vendors is minimized, but to b=
e standard compliant the libraries must be delivered with the compiler offe=
ring. Maybe ISO is not the right &quot;host&quot; for such an offering but =
some3one must put pressure on the compiler vendors to take the effort to in=
tegrate these libraries and distribute them in an as easy to use form as th=
e current libraries. To me it seems that the old conflict between open sour=
ce and commercial interests have abated enough to make something like this =
possible. There are so many good libraries out there but it takes so much t=
ime to get them into a useful state of compilation... so much wasted progra=
mmer time.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5de8bb0d-a20e-47ee-8558-993a4d25c540%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5de8bb0d-a20e-47ee-8558-993a4d25c540=
%40isocpp.org</a>.<br />

------=_Part_4272_2082188789.1489533950488--

------=_Part_4271_473972604.1489533950488--

.

------=_Part_2933_1842138974.1489593485558
Content-Type: multipart/alternative;
 boundary="----=_Part_2934_1689333749.1489593485559"

------=_Part_2934_1689333749.1489593485559
Content-Type: text/plain; charset=UTF-8

Op maandag 13 maart 2017 21:40:53 UTC+1 schreef Nicol Bolas:
>
> This sounds me more a problem related to modules and/or standardizing the
>> build system (feasible or not, out of mail scope).
>>
>
> That is what makes the argument compelling. Solving the build system
> problem is out of scope for the committee. But making the standard library
> more useful out-of-the-box is *not* out of scope. So why not do something
> that helps alleviate the problem to the extent that they can?
>
> What precisely is the advantage of having a tiny standard library?
> Ease-of-implementation might be one, but C++ is already a difficult
> language to implement. And writing a *quality* standard library
> implementation is quite difficult as well. So adding a few more things on
> top of that isn't exactly overburdening implementers.
>

Or you make it easier (outside of ISO committee) to consume third-party
libs and you solve problems for a lot more areas and users.

--
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/ae6006fd-ebeb-4011-bfc6-44762ed3f8c9%40isocpp.org.

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

<div dir=3D"ltr">Op maandag 13 maart 2017 21:40:53 UTC+1 schreef Nicol Bola=
s:<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"><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_quot=
e"><div>This sounds me more a problem related to modules and/or standardizi=
ng the build system (feasible or not, out of mail scope).</div></div></div>=
</div></blockquote><div><br>That is what makes the argument compelling. Sol=
ving the build system problem is out of scope for the committee. But making=
 the standard library more useful out-of-the-box is <i>not</i> out of scope=
.. So why not do something that helps alleviate the problem to the extent th=
at they can?<br><br>What precisely is the advantage of having a tiny standa=
rd library? Ease-of-implementation might be one, but C++ is already a diffi=
cult language to implement. And writing a <i>quality</i> standard library i=
mplementation is quite difficult as well. So adding a few more things on to=
p of that isn&#39;t exactly overburdening implementers.<br></div></div></bl=
ockquote><div><br></div><div>Or you make it easier (outside of ISO committe=
e) to consume third-party libs and you solve problems for a lot more areas =
and users.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ae6006fd-ebeb-4011-bfc6-44762ed3f8c9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ae6006fd-ebeb-4011-bfc6-44762ed3f8c9=
%40isocpp.org</a>.<br />

------=_Part_2934_1689333749.1489593485559--

------=_Part_2933_1842138974.1489593485558--

.

------=_Part_4734_246608343.1489608351240
Content-Type: multipart/alternative;
 boundary="----=_Part_4735_53416780.1489608351240"

------=_Part_4735_53416780.1489608351240
Content-Type: text/plain; charset=UTF-8

I think we need some endorsement from the commitee or at least from major
compiler vendors/suppliers that they will supply those libraries selected
by (some other) commitee or we will not get libraries with the "plug and
play" feeling that other languages mostly have, but C++ (and C) sorely
lacks. That is, rather strict guidelines to be eligible.


Den onsdag 15 mars 2017 kl. 16:58:05 UTC+1 skrev olafv...@gmail.com:
>
> Op maandag 13 maart 2017 21:40:53 UTC+1 schreef Nicol Bolas:
>>
>> This sounds me more a problem related to modules and/or standardizing the
>>> build system (feasible or not, out of mail scope).
>>>
>>
>> That is what makes the argument compelling. Solving the build system
>> problem is out of scope for the committee. But making the standard library
>> more useful out-of-the-box is *not* out of scope. So why not do
>> something that helps alleviate the problem to the extent that they can?
>>
>> What precisely is the advantage of having a tiny standard library?
>> Ease-of-implementation might be one, but C++ is already a difficult
>> language to implement. And writing a *quality* standard library
>> implementation is quite difficult as well. So adding a few more things on
>> top of that isn't exactly overburdening implementers.
>>
>
> Or you make it easier (outside of ISO committee) to consume third-party
> libs and you solve problems for a lot more areas and users.
>

--
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/1be038c9-e4db-4e06-a316-283709aed440%40isocpp.org.

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

<div dir=3D"ltr">I think we need some endorsement from the commitee or at l=
east from major compiler vendors/suppliers that they will supply those libr=
aries selected by (some other) commitee or we will not get libraries with t=
he &quot;plug and play&quot; feeling that other languages mostly have, but =
C++ (and C) sorely lacks. That is, rather strict guidelines to be eligible.=
<div><br><br>Den onsdag 15 mars 2017 kl. 16:58:05 UTC+1 skrev olafv...@gmai=
l.com:<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">Op maan=
dag 13 maart 2017 21:40:53 UTC+1 schreef Nicol Bolas:<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"><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>This sounds me more =
a problem related to modules and/or standardizing the build system (feasibl=
e or not, out of mail scope).</div></div></div></div></blockquote><div><br>=
That is what makes the argument compelling. Solving the build system proble=
m is out of scope for the committee. But making the standard library more u=
seful out-of-the-box is <i>not</i> out of scope. So why not do something th=
at helps alleviate the problem to the extent that they can?<br><br>What pre=
cisely is the advantage of having a tiny standard library? Ease-of-implemen=
tation might be one, but C++ is already a difficult language to implement. =
And writing a <i>quality</i> standard library implementation is quite diffi=
cult as well. So adding a few more things on top of that isn&#39;t exactly =
overburdening implementers.<br></div></div></blockquote><div><br></div><div=
>Or you make it easier (outside of ISO committee) to consume third-party li=
bs and you solve problems for a lot more areas and users.</div></div></bloc=
kquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1be038c9-e4db-4e06-a316-283709aed440%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1be038c9-e4db-4e06-a316-283709aed440=
%40isocpp.org</a>.<br />

------=_Part_4735_53416780.1489608351240--

------=_Part_4734_246608343.1489608351240--

.

On 2017-03-13 16:40, Nicol Bolas wrote:
> On Monday, March 13, 2017 at 4:14:41 PM UTC-4, dgutson wrote:
>> This sounds me more a problem related to modules and/or standardizing th=
e=20
>> build system (feasible or not, out of mail scope).
>=20
> That is what makes the argument compelling. Solving the build system=20
> problem is out of scope for the committee. But making the standard librar=
y=20
> more useful out-of-the-box is *not* out of scope. So why not do something=
=20
> that helps alleviate the problem to the extent that they can?

One of the reasons libraries like Boost, Qt, etc. are so successful is
because they are willing and able to make compatibility-breaking changes
every few years, which "core C++" historically has not been willing to do.

There are several concerns with a large standard library:

- There is no single implementation. Unless we somehow develop a system
of "blessing" a particular existing implementation when a new (hunk of)
library is added to the standard, the work load simply implementing new
stuff is... large. There are of course licensing issues with adopting an
existing implementation. Also, the various implementations are almost
certainly going to have divergence in QoI.

- Unwillingness to break compatibility will make it difficult to keep up
with new developments in software design. Just look at e.g. QML compared
to how GUI development happened in the Qt 3.x days. Or look at web
rendering technology over the last decade. Bad design choices become
immutable. Codifying solutions to these sorts of problems into a
slow-moving standard is just asking for them to become rapidly obsolete.

- Monopoly. Software, like many things, thrives on competition. Having
multiple libraries to do the same thing is both a curse and a blessing.
The library that is the best fit for my application may not be the best
fit for yours, but having choices allows each of us to use what works
best *for our use cases*. See for example the recent JSON thread and its
heated debate on DOM vs. SAX vs. StAX. One size does not fit all.
Competing libraries drive progress.

> Writing a *quality* standard library implementation is quite
> difficult as well. So adding a few more things on top of that isn't
> exactly overburdening implementers.

You assume that library implementers aren't *already* overburdened. I'm
not sure I can agree with that...

Going back to your previous comments, the real reason we have these
issues is not lack of library standardization, it is lack of packaging
and distribution standardization. If installing and using third-party
C++ libraries was as easy as installing and using third-party Python
modules, we wouldn't be having this conversation.

The work-in-progress Common Package Specification=C2=B9 hopes to alleviate
the 'consuming' side.

(=C2=B9 https://github.com/mwoehlke/cps)

--=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/58CABF76.5080502%40gmail.com.

.

On 2017-03-15 16:05, Bengt Gustafsson wrote:
> Den onsdag 15 mars 2017 kl. 16:58:05 UTC+1 skrev olafv...@gmail.com:
>> Or you make it easier (outside of ISO committee) to consume third-party
>> libs and you solve problems for a lot more areas and users.
>
> I think we need some endorsement from the commitee or at least from major
> compiler vendors/suppliers that they will supply those libraries selected
> by (some other) commitee or we will not get libraries with the "plug and
> play" feeling that other languages mostly have, but C++ (and C) sorely
> lacks. That is, rather strict guidelines to be eligible.

I don't think this is the job of compiler vendors. Rather, it is the job
of operating system distributors. Linux distributions have effectively
solved this problem a long, long time ago. What we need is better tools
for MacOS and *especially* Windows to install, update and otherwise
manage "third party" libraries.

App stores, which are sharply targeted at end user applications, aren't
the answer. While they do a good job on the user experience end, I'm not
aware that they do dependency management. There is also the problem of
dealing with differing library versions.

The battle between open and closed source software comes into play here
also. Proprietary software has the choice of either bundling all its
dependencies, effectively distributing a monolithic build, or else
ceasing to function whenever shared libraries are updated. Open source
software can be packaged by the distributor and rebuilt on demand as
needed, and anyone can contribute fixes as needed when libraries change.
In a nutshell, proprietary software is excluded from playing in the
shared libraries sandbox, while open source software is part of a
community where everyone can work together.

(Making libraries "frozen in time" is not a viable option either; see my
previous post in this thread.)

--
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/58CAC1FE.8010003%40gmail.com.

.

2017-03-16 17:49 GMT+01:00 Matthew Woehlke <mwoehlke.floss@gmail.com>:
> I don't think this is the job of compiler vendors. Rather, it is the job
> of operating system distributors. Linux distributions have effectively
> solved this problem a long, long time ago. What we need is better tools
> for MacOS and *especially* Windows to install, update and otherwise
> manage "third party" libraries.

vcpkg?

> App stores, which are sharply targeted at end user applications, aren't
> the answer. While they do a good job on the user experience end, I'm not
> aware that they do dependency management. There is also the problem of
> dealing with differing library versions.
>
> The battle between open and closed source software comes into play here
> also. Proprietary software has the choice of either bundling all its
> dependencies, effectively distributing a monolithic build, or else
> ceasing to function whenever shared libraries are updated. Open source
> software can be packaged by the distributor and rebuilt on demand as
> needed, and anyone can contribute fixes as needed when libraries change.
> In a nutshell, proprietary software is excluded from playing in the
> shared libraries sandbox, while open source software is part of a
> community where everyone can work together.

Updates to shared libs should NOT break old consumers.
If an update is incompatible it should be installed side-by-side with
the old version.


--
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/CAA7U3HMiGvtfjsZaHPheJVqOmX%2BfNd8%3D%3Dj7cgf9w-8aX1MhHWg%40mail.gmail.com.

.

On 2017-03-16 15:07, Olaf van der Spek wrote:
> 2017-03-16 17:49 GMT+01:00 Matthew Woehlke wrote:
>> I don't think this is the job of compiler vendors. Rather, it is the job
>> of operating system distributors. Linux distributions have effectively
>> solved this problem a long, long time ago. What we need is better tools
>> for MacOS and *especially* Windows to install, update and otherwise
>> manage "third party" libraries.
>
> vcpkg?

News to me. Maybe it will help; that would be nice if it does... I'm
guessing it relies on users to use CMake in order to be able to consume
the resulting packages? Or do they have their own system for that?

>> App stores, which are sharply targeted at end user applications, aren't
>> the answer. While they do a good job on the user experience end, I'm not
>> aware that they do dependency management. There is also the problem of
>> dealing with differing library versions.
>>
>> The battle between open and closed source software comes into play here
>> also. Proprietary software has the choice of either bundling all its
>> dependencies, effectively distributing a monolithic build, or else
>> ceasing to function whenever shared libraries are updated. Open source
>> software can be packaged by the distributor and rebuilt on demand as
>> needed, and anyone can contribute fixes as needed when libraries change.
>> In a nutshell, proprietary software is excluded from playing in the
>> shared libraries sandbox, while open source software is part of a
>> community where everyone can work together.
>
> Updates to shared libs should NOT break old consumers.
> If an update is incompatible it should be installed side-by-side with
> the old version.

In an ideal world, yes, but how often is that the case? This would
require that all libraries are installed in a way that their headers and
other artifacts are isolated in version-specific locations, so that
multiple versions can be installed. For most packages on most POSIX-like
platforms, that is simply not the case.

Major libraries of better quality do that, but many don't. (I know Qt
tries hard to keep both SC and BC within a minor revision, and their
major versions are usually co-installable. I would assume, but can't
verify from firsthand experience, that GTK, Boost and the like do also.
OTOH, I don't think PROJ does, and I'm not sure about such critical
libraries as libjpeg, libpng, zlib, etc., although on the plus side
there is usually a direct correlation between how often a library is
likely to *have* compatibility breaks and how likely they are to take
steps to mitigate consequences for their users. The problem children are
usually smaller, more "niche" libraries with sporadic releases and often
few developers.)

--
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/58CAE60C.1000300%40gmail.com.

.

2017-03-16 20:22 GMT+01:00 Matthew Woehlke <mwoehlke.floss@gmail.com>:
> On 2017-03-16 15:07, Olaf van der Spek wrote:
>> 2017-03-16 17:49 GMT+01:00 Matthew Woehlke wrote:
>>> I don't think this is the job of compiler vendors. Rather, it is the job
>>> of operating system distributors. Linux distributions have effectively
>>> solved this problem a long, long time ago. What we need is better tools
>>> for MacOS and *especially* Windows to install, update and otherwise
>>> manage "third party" libraries.
>>
>> vcpkg?
>
> News to me. Maybe it will help; that would be nice if it does... I'm
> guessing it relies on users to use CMake in order to be able to consume
> the resulting packages? Or do they have their own system for that?

No, if you use the IDE (or maybe just MSBuild) you only have to
install a pkg once ('globally'), you don't have to add any per-project
settings.

>>> App stores, which are sharply targeted at end user applications, aren't
>>> the answer. While they do a good job on the user experience end, I'm not
>>> aware that they do dependency management. There is also the problem of
>>> dealing with differing library versions.
>>>
>>> The battle between open and closed source software comes into play here
>>> also. Proprietary software has the choice of either bundling all its
>>> dependencies, effectively distributing a monolithic build, or else
>>> ceasing to function whenever shared libraries are updated. Open source
>>> software can be packaged by the distributor and rebuilt on demand as
>>> needed, and anyone can contribute fixes as needed when libraries change.
>>> In a nutshell, proprietary software is excluded from playing in the
>>> shared libraries sandbox, while open source software is part of a
>>> community where everyone can work together.
>>
>> Updates to shared libs should NOT break old consumers.
>> If an update is incompatible it should be installed side-by-side with
>> the old version.
>
> In an ideal world, yes, but how often is that the case? This would
> require that all libraries are installed in a way that their headers and
> other artifacts are isolated in version-specific locations, so that

Headers? I'm confused, how are headers a problem for deploying
closed-source software?

> multiple versions can be installed. For most packages on most POSIX-like
> platforms, that is simply not the case.
>
> Major libraries of better quality do that, but many don't. (I know Qt
> tries hard to keep both SC and BC within a minor revision, and their
> major versions are usually co-installable. I would assume, but can't
> verify from firsthand experience, that GTK, Boost and the like do also.
> OTOH, I don't think PROJ does, and I'm not sure about such critical
> libraries as libjpeg, libpng, zlib, etc., although on the plus side
> there is usually a direct correlation between how often a library is
> likely to *have* compatibility breaks and how likely they are to take
> steps to mitigate consequences for their users. The problem children are
> usually smaller, more "niche" libraries with sporadic releases and often
> few developers.)

Distributing closed-source software for Linux is problematic, true.


--
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/CAA7U3HPhewkzaRf-pRa4SH5CXCNBXh7%2BRtiaQjOQGiHNLVKe8g%40mail.gmail.com.

.

On 2017-03-16 15:27, Olaf van der Spek wrote:
> 2017-03-16 20:22 GMT+01:00 Matthew Woehlke wrote:
>> On 2017-03-16 15:07, Olaf van der Spek wrote:
>>> 2017-03-16 17:49 GMT+01:00 Matthew Woehlke wrote:
>>>> I don't think this is the job of compiler vendors. Rather, it is the j=
ob
>>>> of operating system distributors. Linux distributions have effectively
>>>> solved this problem a long, long time ago. What we need is better tool=
s
>>>> for MacOS and *especially* Windows to install, update and otherwise
>>>> manage "third party" libraries.
>>>
>>> vcpkg?
>>
>> News to me. Maybe it will help; that would be nice if it does... I'm
>> guessing it relies on users to use CMake in order to be able to consume
>> the resulting packages? Or do they have their own system for that?
>=20
> No, if you use the IDE (or maybe just MSBuild) you only have to
> install a pkg once ('globally'), you don't have to add any per-project
> settings.

I don't think we're on the same page...

Let's say I am writing software A that uses build system X and needs
library B. Let's say that I used vcpkg to get B on my system. How does A
know how to use B? Does vcpkg itself provide anything on top of what B
would provide if I just acquired B from its upstream and built it "the
usual way"? If it does, must X be some specific build system to take
advantage of it?

I suspect the answer is either "X must be CMake" or "X must be VS", in
which case we haven't fully solved the problem. (CPS=C2=B9 would help with
that...)

(=C2=B9 https://github.com/mwoehlke/cps)

>>> Updates to shared libs should NOT break old consumers.
>>> If an update is incompatible it should be installed side-by-side with
>>> the old version.
>>
>> In an ideal world, yes, but how often is that the case? This would
>> require that all libraries are installed in a way that their headers and
>> other artifacts are isolated in version-specific locations, so that
>=20
> Headers? I'm confused, how are headers a problem for deploying
> closed-source software?

They are a problem if I want to build any software that uses such
libraries. Remember, we're not talking about "leaf" applications:
usually you would not install multiple versions of those. We're talking
about *shared* libraries that are used by other applications.

Anyway, headers aren't the only problem; what about libraries with
run-time data files? (PROJ comes to mind again...) Headers are just the
most obvious thing likely to differ by version but not include version
information. *Every* artifact of an installed shared library needs to
reside in a version-specific location in some manner in order for
multiple versions of that library to be co-installable.

That means that either you have many, many versions of *every* library,
so that every installed version has the *exact* version of all its
dependencies that it was built against (and you can never update=C2=B2), or
else Windows needs to figure out something like SO-versioning.

(=C2=B2 Admittedly this is a mixed curse. On the one hand, the end
application knows exactly what they've got library-wise. On the other,
the application can't see bug fixes *or security updates* in a library
without rebuilding the application, which is only practical for open
source applications that are built by the end user, Gentoo-style, or
where the OS distributor distributes the build. Not being able to update
the library without also updating the application is not much different
from just using static libraries, at which point you're effectively just
dodging/ignoring the problem. Historically, Linux distributions have
looked VERY POORLY on this sort of thing.)

--=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/58CAF13D.1060600%40gmail.com.

.

2017-03-16 21:10 GMT+01:00 Matthew Woehlke <mwoehlke.floss@gmail.com>:
>>>> vcpkg?
>>>
>>> News to me. Maybe it will help; that would be nice if it does... I'm
>>> guessing it relies on users to use CMake in order to be able to consume
>>> the resulting packages? Or do they have their own system for that?
>>
>> No, if you use the IDE (or maybe just MSBuild) you only have to
>> install a pkg once ('globally'), you don't have to add any per-project
>> settings.
>
> I don't think we're on the same page...
>
> Let's say I am writing software A that uses build system X and needs
> library B. Let's say that I used vcpkg to get B on my system. How does A
> know how to use B? Does vcpkg itself provide anything on top of what B
> would provide if I just acquired B from its upstream and built it "the
> usual way"? If it does, must X be some specific build system to take
> advantage of it?
>
> I suspect the answer is either "X must be CMake" or "X must be VS", in
> which case we haven't fully solved the problem. (CPS=C2=B9 would help wit=
h
> that...)
>
> (=C2=B9 https://github.com/mwoehlke/cps)

X can be cmake or vs, if it's not I guess you'll have to point X to
the include and lib dirs vcpkg created.

>>>> Updates to shared libs should NOT break old consumers.
>>>> If an update is incompatible it should be installed side-by-side with
>>>> the old version.
>>>
>>> In an ideal world, yes, but how often is that the case? This would
>>> require that all libraries are installed in a way that their headers an=
d
>>> other artifacts are isolated in version-specific locations, so that
>>
>> Headers? I'm confused, how are headers a problem for deploying
>> closed-source software?
>
> They are a problem if I want to build any software that uses such
> libraries. Remember, we're not talking about "leaf" applications:
> usually you would not install multiple versions of those. We're talking
> about *shared* libraries that are used by other applications.

Ah.. vcpkg only concerns itself with distributing the build
dependencies, not with further distribution to end users.

> Anyway, headers aren't the only problem; what about libraries with
> run-time data files? (PROJ comes to mind again...) Headers are just the
> most obvious thing likely to differ by version but not include version
> information. *Every* artifact of an installed shared library needs to
> reside in a version-specific location in some manner in order for
> multiple versions of that library to be co-installable.
>
> That means that either you have many, many versions of *every* library,
> so that every installed version has the *exact* version of all its

You don't need the exact versions, you merely need a compatible version.
I think on Windows this currently causes tons of duplication.

> dependencies that it was built against (and you can never update=C2=B2), =
or
> else Windows needs to figure out something like SO-versioning.
>
> (=C2=B2 Admittedly this is a mixed curse. On the one hand, the end
> application knows exactly what they've got library-wise. On the other,
> the application can't see bug fixes *or security updates* in a library
> without rebuilding the application, which is only practical for open
> source applications that are built by the end user, Gentoo-style, or
> where the OS distributor distributes the build. Not being able to update
> the library without also updating the application is not much different
> from just using static libraries, at which point you're effectively just
> dodging/ignoring the problem. Historically, Linux distributions have
> looked VERY POORLY on this sort of thing.)

How so?
AFAIK Linux distros have no trouble shipping security updates of shared lib=
s.

--=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/CAA7U3HP9nZZH%3DdmVbQermN--hEcvHD_bR%3DWxrG10Bee=
CoYnBhQ%40mail.gmail.com.

.

Em quinta-feira, 16 de mar=C3=A7o de 2017, =C3=A0s 09:38:14 PDT, Matthew Wo=
ehlke=20
escreveu:
> One of the reasons libraries like Boost, Qt, etc. are so successful is
> because they are willing and able to make compatibility-breaking changes
> every few years, which "core C++" historically has not been willing to do=
..

Note that the libraries implementing the standard have done compatibility=
=20
breaks too. The standard does not say how its classes must be implemented,=
=20
only what they have to do once implemented.

> There are several concerns with a large standard library:
>=20
> - There is no single implementation. Unless we somehow develop a system
> of "blessing" a particular existing implementation when a new (hunk of)
> library is added to the standard, the work load simply implementing new
> stuff is... large. There are of course licensing issues with adopting an
> existing implementation. Also, the various implementations are almost
> certainly going to have divergence in QoI.

Don't forget that creating more work for the Standard Library developers (o=
f=20
whom there is a limited quantity) will most likely cause a drop in quality =
too=20
or a delay in providing full functionality.

> Going back to your previous comments, the real reason we have these
> issues is not lack of library standardization, it is lack of packaging
> and distribution standardization. If installing and using third-party
> C++ libraries was as easy as installing and using third-party Python
> modules, we wouldn't be having this conversation.

Or Go. All dependencies are listed by their repository URL. Go has no stati=
c=20
or shared library. It forces open source.


--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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/11826995.aWeXYnBARb%40tjmaciei-mobl1.

.

On 2017-03-17 02:01, Thiago Macieira wrote:
> Em quinta-feira, 16 de mar=C3=A7o de 2017, =C3=A0s 09:38:14 PDT, Matthew =
Woehlke=20
> escreveu:
>> One of the reasons libraries like Boost, Qt, etc. are so successful is
>> because they are willing and able to make compatibility-breaking changes
>> every few years, which "core C++" historically has not been willing to d=
o.
>=20
> Note that the libraries implementing the standard have done compatibility=
=20
> breaks too. The standard does not say how its classes must be implemented=
,=20
> only what they have to do once implemented.

Yes, but mostly BC breaks. I'm thinking more of SC, which is the only
level of compatibility that can be talked about at the specification
level, and is also more restrictive. (You can break BC without breaking
SC, but you generally can't break SC without also breaking BC.)

Well, there have been *some* SC breaks (`auto` for example), but they
tend to take a long time to push through. Compare to something like Qt,
GTK, etc. that allow SC breaks every few years and are generally
aggressive about removing "bad" API.

>> There are several concerns with a large standard library:
>>
>> - There is no single implementation. Unless we somehow develop a system
>> of "blessing" a particular existing implementation when a new (hunk of)
>> library is added to the standard, the work load simply implementing new
>> stuff is... large. There are of course licensing issues with adopting an
>> existing implementation. Also, the various implementations are almost
>> certainly going to have divergence in QoI.
>=20
> Don't forget that creating more work for the Standard Library developers =
(of=20
> whom there is a limited quantity) will most likely cause a drop in qualit=
y too=20
> or a delay in providing full functionality.

Er... right? I was certainly *trying* to imply that with the above ;-).

>> Going back to your previous comments, the real reason we have these
>> issues is not lack of library standardization, it is lack of packaging
>> and distribution standardization. If installing and using third-party
>> C++ libraries was as easy as installing and using third-party Python
>> modules, we wouldn't be having this conversation.
>=20
> Or Go. All dependencies are listed by their repository URL. Go has no sta=
tic=20
> or shared library. It forces open source.

Or perl. Or... :-)

--=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/58CC00DF.2060805%40gmail.com.

.

Em sexta-feira, 17 de mar=C3=A7o de 2017, =C3=A0s 08:29:35 PDT, Matthew Woe=
hlke=20
escreveu:
> Yes, but mostly BC breaks. I'm thinking more of SC, which is the only
> level of compatibility that can be talked about at the specification
> level, and is also more restrictive. (You can break BC without breaking
> SC, but you generally can't break SC without also breaking BC.)

Sure you can. The easiest ways: #ifdef and ambiguous overloads.

> >> Going back to your previous comments, the real reason we have these
> >> issues is not lack of library standardization, it is lack of packaging
> >> and distribution standardization. If installing and using third-party
> >> C++ libraries was as easy as installing and using third-party Python
> >> modules, we wouldn't be having this conversation.
> >=20
> > Or Go. All dependencies are listed by their repository URL. Go has no
> > static or shared library. It forces open source.
>=20
> Or perl. Or... :-)

Perl is like Python: not a compiled language. Go is compiled but does not=
=20
accept pre-compiled modules.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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/2150377.hv0FQ5dsHy%40tjmaciei-mobl1.

.

On 2017-03-17 12:22, Thiago Macieira wrote:
> Em sexta-feira, 17 de mar=C3=A7o de 2017, =C3=A0s 08:29:35 PDT, Matthew W=
oehlke=20
> escreveu:
>>>> Going back to your previous comments, the real reason we have these
>>>> issues is not lack of library standardization, it is lack of packaging
>>>> and distribution standardization. If installing and using third-party
>>>> C++ libraries was as easy as installing and using third-party Python
>>>> modules, we wouldn't be having this conversation.
>>>
>>> Or Go. All dependencies are listed by their repository URL. Go has no
>>> static or shared library. It forces open source.
>>
>> Or perl. Or... :-)
>=20
> Perl is like Python: not a compiled language. Go is compiled but does not=
=20
> accept pre-compiled modules.

Python modules can be pure Python code, but they can also include
pre-compiled code. In fact, a significant portion=C2=B9 of my
distro-installed Python modules are .so's.

Granted, the distribution system for these is either left to the OS
vendor or assumes availability of source code, however the latter case
also usually means use of a standard build system (i.e. setuptools).
Which... goes back to my original point: we need a standard way to
distribute libraries whose final installed form is a compiled artifact.
Python has generally solved this problem, and by nature doesn't have the
problems that C and C++ have with consuming third party libraries (or
modules, or whatever nomenclature applies).

Stuff like cppan=C2=B2, vcpkg=C2=B3 and CPS=E2=81=B4 could help here. FLOSS=
-based OS
distros generally solve the packaging and distribution problem, so we
just need to solve the "how to consume it" problem (CPS), which leaves
mainly Windows that still needs to solve packaging and distribution.
It's not clear if vcpkg will solve that for end users, or only for
developers (leaving application developers still needing to solve the
problem for their end users). I'm not very familiar with cppan either,
but at a glance, it looks like it may be more promising than vcpkg as an
end to end solution.

I think the best solution would be to converge on something like cppan
(which =E2=80=94 unlike vcpkg =E2=80=94 is cross platform), for build syste=
ms to learn
to integrate with cppan in order to obtain dependencies on demand, and
for OS vendors to adopt and package cppan so that it is able to install
vendor-packaged dependencies when available and to keep
non-vendor-packaged dependencies segregated in a way that plays nice
with those parts of the file system that are OS-managed.

The third step is not strictly necessary, but OS vendors will likely
have sufficient motivation to do it anyway if/when cppan becomes
popular. The second step can be as easy as teaching the build system to
suggest a cppan command to run when a dependency is not found.

Of course, this all works great for open source libraries. Vendors of
proprietary software will still have to carry the burden of producing
pre-built binaries for all supported platforms. I would hope that cppan
could still make it possible for users to obtain such packages in a
standard way, if suitable packages exist.

This brings up a related problem: what all is involved in identifying if
a pre-built binary will run on a user's platform? We need to know at
least the ISA, kernel, and kernel version, but what else? Standard
library version? Compiler? Compiler version? Others? (Not all of these
will matter for all kernels.)

(=C2=B9 At a rough count, I would say I have about 80 Python modules that a=
re
either wholly or partly pre-compiled code, out of maybe 500 modules
installed. These numbers may not count "built-in" modules in either
category, and I believe the latter number is an upper bound and might be
significantly inflated.)

(=C2=B2 https://cppan.org/)

(=C2=B3 https://github.com/Microsoft/vcpkg)

(=E2=81=B4 https://github.com/mwoehlke/cps)

--=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/58CC18D8.5010901%40gmail.com.

.

Em sexta-feira, 17 de mar=C3=A7o de 2017, =C3=A0s 10:11:52 PDT, Matthew Woe=
hlke=20
escreveu:
> On 2017-03-17 12:22, Thiago Macieira wrote:
> > Em sexta-feira, 17 de mar=C3=A7o de 2017, =C3=A0s 08:29:35 PDT, Matthew=
 Woehlke
> >=20
> > escreveu:
> >>>> Going back to your previous comments, the real reason we have these
> >>>> issues is not lack of library standardization, it is lack of packagi=
ng
> >>>> and distribution standardization. If installing and using third-part=
y
> >>>> C++ libraries was as easy as installing and using third-party Python
> >>>> modules, we wouldn't be having this conversation.
> >>>=20
> >>> Or Go. All dependencies are listed by their repository URL. Go has no
> >>> static or shared library. It forces open source.
> >>=20
> >> Or perl. Or... :-)
> >=20
> > Perl is like Python: not a compiled language. Go is compiled but does n=
ot
> > accept pre-compiled modules.
>=20
> Python modules can be pure Python code, but they can also include
> pre-compiled code. In fact, a significant portion=C2=B9 of my
> distro-installed Python modules are .so's.

That's not Python compiled code (that would be .pyc, even though those are=
=20
more of a cache nature than compiled). Those are native code implementation=
s=20
for some Python functionality. The same happens to almost all languages tha=
t=20
aren't C and C++.

It doesn't change the fact that Python is actually an interpreted language.=
 Go=20
isn't.

> Which... goes back to my original point: we need a standard way to
> distribute libraries whose final installed form is a compiled artifact.
> Python has generally solved this problem, and by nature doesn't have the
> problems that C and C++ have with consuming third party libraries (or
> modules, or whatever nomenclature applies).

The interesting thing is that the reason that makes C and C++ so attractive=
=20
for system programming is that there is no requirement to deploy it any=20
particular way. Each system can choose how to deploy it to suit its needs.

> This brings up a related problem: what all is involved in identifying if
> a pre-built binary will run on a user's platform? We need to know at
> least the ISA, kernel, and kernel version, but what else? Standard
> library version? Compiler? Compiler version? Others? (Not all of these
> will matter for all kernels.)

Yes to all of the above (including the "others").

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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/2802911.1bm84HaEJy%40tjmaciei-mobl1.

.

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

On Fri, Mar 17, 2017 at 1:01 AM, Thiago Macieira <thiago@macieira.org>
wrote:

> Don't forget that creating more work for the Standard Library developers
> (of
> whom there is a limited quantity) will most likely cause a drop in quality
> too
> or a delay in providing full functionality.
>

This argument, of course, can be used against adding *any* more standard
libraries, modifying current libraries, etc.  Maybe we should rename this
list to std-no-more-proposals.

Library vendors are on the committee.  Why not make a proposal and let them
make the choice?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
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/CAGg_6%2BMiCaOx6e%3Dq27xmWe4hzDt0_V_X%2BfGnfvmUptZtxTcZ%2BQ%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra">On Fri, Mar 17, 2017 at 1:01 AM=
, Thiago Macieira <span dir=3D"ltr">&lt;<a href=3D"mailto:thiago@macieira.o=
rg" target=3D"_blank">thiago@macieira.org</a>&gt;</span> wrote:<br><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=3D":2yg" class=3D=
"a3s aXjCH m15adadb2e6971147">Don&#39;t forget that creating more work for =
the Standard Library developers (of<br>
whom there is a limited quantity) will most likely cause a drop in quality =
too<br>
or a delay in providing full functionality.<span class=3D""><br></span></di=
v></blockquote></div><br>This argument, of course, can be used against addi=
ng *any* more standard libraries, modifying current libraries, etc.=C2=A0 M=
aybe we should rename this list to std-no-more-proposals.</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Library vendors are o=
n the committee.=C2=A0 Why not make a proposal and let them make the choice=
?</div><div class=3D"gmail_extra">--=C2=A0</div><div class=3D"gmail_extra">=
<div class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=
=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0=
 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nev=
in@eviloverlord.com</a>&gt; =C2=A0+1-847-691-1404</div></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMiCaOx6e%3Dq27xmWe4hzDt0_V_X=
%2BfGnfvmUptZtxTcZ%2BQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2B=
MiCaOx6e%3Dq27xmWe4hzDt0_V_X%2BfGnfvmUptZtxTcZ%2BQ%40mail.gmail.com</a>.<br=
 />

--001a114a94e254b9c2054af389fb--

.

On 2017-03-17 16:32, Thiago Macieira wrote:
> Em sexta-feira, 17 de mar=C3=A7o de 2017, =C3=A0s 10:11:52 PDT, Matthew W=
oehlke=20
> escreveu:
>> On 2017-03-17 12:22, Thiago Macieira wrote:
>>> Em sexta-feira, 17 de mar=C3=A7o de 2017, =C3=A0s 08:29:35 PDT, Matthew=
 Woehlke
>>> escreveu:
>>>>>> Going back to your previous comments, the real reason we have these
>>>>>> issues is not lack of library standardization, it is lack of packagi=
ng
>>>>>> and distribution standardization. If installing and using third-part=
y
>>>>>> C++ libraries was as easy as installing and using third-party Python
>>>>>> modules, we wouldn't be having this conversation.
>>>>>
>>>>> Or Go. All dependencies are listed by their repository URL. Go has no
>>>>> static or shared library. It forces open source.
>>>>
>>>> Or perl. Or... :-)
>>>
>>> Perl is like Python: not a compiled language. Go is compiled but does n=
ot
>>> accept pre-compiled modules.
>>
>> Python modules can be pure Python code, but they can also include
>> pre-compiled code. In fact, a significant portion=C2=B9 of my
>> distro-installed Python modules are .so's.
>=20
> That's not Python compiled code (that would be .pyc, even though those ar=
e=20
> more of a cache nature than compiled). Those are native code implementati=
ons=20
> for some Python functionality. The same happens to almost all languages t=
hat=20
> aren't C and C++.
>=20
> It doesn't change the fact that Python is actually an interpreted languag=
e. Go=20
> isn't.

Python modules are generally easy to be installed. Some python modules,
which presumably are in the "easily installed" category, may consist of
compiled C/C++/etc. code. Ergo, Python is a legitimate example of a
language that has apparently solved the packaging and distribution problem.

It may be that the above is true only for open source modules... but so
what? That just means that solving the problem for C++ may be harder for
proprietary software.

I don't see how furthering this discussion is beneficial to C++.

>> Which... goes back to my original point: we need a standard way to
>> distribute libraries whose final installed form is a compiled artifact.
>> Python has generally solved this problem, and by nature doesn't have the
>> problems that C and C++ have with consuming third party libraries (or
>> modules, or whatever nomenclature applies).
>=20
> The interesting thing is that the reason that makes C and C++ so attracti=
ve=20
> for system programming is that there is no requirement to deploy it any=
=20
> particular way. Each system can choose how to deploy it to suit its needs=
..

Well, then, we have a catch-22. Being able to easily consume third party
libraries requires some form of standardization.

I don't see why having such a system wouldn't allow users to opt out of
that system (you can do something similar with Python by installing
stuff in non-standard paths), but then the burden is on you to find and
use your third party components.

>> This brings up a related problem: what all is involved in identifying if
>> a pre-built binary will run on a user's platform? We need to know at
>> least the ISA, kernel, and kernel version, but what else? Standard
>> library version? Compiler? Compiler version? Others? (Not all of these
>> will matter for all kernels.)
>=20
> Yes to all of the above (including the "others").

Whee! Well, I was at least rather hoping to pin down what "others"
includes...

One of the problems CPS needs to solve is how to specify what platform a
package pertains to, so that a user searching for a package can ignore
packages that aren't built for their system (e.g. ignore i686 packages
when building x86_64 software). I'd appreciate any insight into that
problem...

--=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/58CC50A4.7050403%40gmail.com.

.

Em sexta-feira, 17 de mar=C3=A7o de 2017, =C3=A0s 14:09:56 PDT, Matthew Woe=
hlke=20
escreveu:
> Python modules are generally easy to be installed. Some python modules,
> which presumably are in the "easily installed" category, may consist of
> compiled C/C++/etc. code. Ergo, Python is a legitimate example of a
> language that has apparently solved the packaging and distribution proble=
m.

Not exactly. The modules that contain C and C++ compiled code most often do=
 so=20
because they link to a C and C++ library, which must be installed before th=
e=20
Python module is compiled.

Since that isn't a solved problem, deployment of Python modules that includ=
e=20
compiled code is not a solved problem.

Not to mention that every time I install a new computer, I have to hunt dow=
n=20
to find a compatible Python-ZOAP module, because they never compile properl=
y.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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/2602549.txobXq05QN%40tjmaciei-mobl1.

.