------=_Part_204_267118848.1415929593341
Content-Type: text/plain; charset=UTF-8

Any thoughts about standardizing POSIX getopt.h and getopt.cpp (and its
variant getoptlong) ?

That would be really of high value for porting CLI applications
cross-platform.

--

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

------=_Part_204_267118848.1415929593341
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><div>Any thoughts about standardizing POSIX getopt.h and getopt.cpp (and its variant getoptlong) ? </div><div><br></div><div>That would be really of high value&nbsp;for porting CLI applications cross-platform.</div></div>

<p></p>

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

------=_Part_204_267118848.1415929593341--

.

On 2014=E2=80=9311=E2=80=9314, at 9:46 AM, adeel.bm@gmail.com wrote:

> Any thoughts about standardizing POSIX getopt.h and getopt.cpp (and its v=
ariant getoptlong) ?

POSIX is already a standard.

> That would be really of high value for porting CLI applications cross-pla=
tform.

Ask your platform vendor to implement it. (Who hasn=E2=80=99t?)

C++ does define =E2=80=9Cstreams=E2=80=9D with byte, text, and code-point o=
rientation, but not much in the way of operational semantics. User interfac=
es are rightly left to the OS.

--=20

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

.

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

Oh I meant C++ ISO standard.. :)

I was hoping, there may be some level of abstraction taken out from those=
=20
headers and include in ISOC++.

> Who hasn't

Microsoft and apparently they don't have plan. @STL stated that we must use=
=20
Boost.Program_options here (in comments section):=20
http://blogs.msdn.com/b/vcblog/archive/2014/11/12/visual-studio-2015-previe=
w-now-available.aspx?PageIndex=3D3#comments
..

Now here is the thing, many folks don't want to include boost in their=20
projects for these small discrepancies, rather they would opt for adding=20
"guards", which -- I believe -- doesn't go hand-in-hand with what ISOCPP is=
=20
trying to bring to the table.



On Friday, November 14, 2014 4:18:42 AM UTC+2, David Krauss wrote:

>
> On 2014=E2=80=9311=E2=80=9314, at 9:46 AM, adee...@gmail.com <javascript:=
> wrote:=20
>
> > Any thoughts about standardizing POSIX getopt.h and getopt.cpp (and its=
=20
> variant getoptlong) ?=20
>
> POSIX is already a standard.=20
>
> > That would be really of high value for porting CLI applications=20
> cross-platform.=20
>
> Ask your platform vendor to implement it. (Who hasn=E2=80=99t?)=20
>
> C++ does define =E2=80=9Cstreams=E2=80=9D with byte, text, and code-point=
 orientation, but=20
> not much in the way of operational semantics. User interfaces are rightly=
=20
> left to the OS.

--=20

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

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

<div dir=3D"ltr"><div>Oh I meant C++ ISO standard.. :)</div><div><br></div>=
<div>I was hoping, there may be some level of abstraction taken out from th=
ose headers and include in ISOC++.</div><div><br></div><div>&gt; Who hasn't=
</div><div><br></div><div>Microsoft and apparently they don't have plan. @S=
TL stated that we must use Boost.Program_options here (in comments section)=
: <a href=3D"http://blogs.msdn.com/b/vcblog/archive/2014/11/12/visual-studi=
o-2015-preview-now-available.aspx?PageIndex=3D3#comments">http://blogs.msdn=
..com/b/vcblog/archive/2014/11/12/visual-studio-2015-preview-now-available.a=
spx?PageIndex=3D3#comments</a>.</div><div><br></div><div>Now here is the th=
ing, many&nbsp;folks don't want to include boost in their projects for thes=
e small discrepancies, rather they would opt for adding "guards", which --&=
nbsp;I believe --&nbsp;doesn't go hand-in-hand with what ISOCPP is trying t=
o bring to the table.</div><div><br></div><div><br><br>On Friday, November =
14, 2014 4:18:42 AM UTC+2, David Krauss wrote:</div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-le=
ft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: so=
lid;">
<br>On 2014=E2=80=9311=E2=80=9314, at 9:46 AM, <a onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;" href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"T4Li=
CuORVaIJ">adee...@gmail.com</a> wrote:
<br>
<br>&gt; Any thoughts about standardizing POSIX getopt.h and getopt.cpp (an=
d its variant getoptlong) ?
<br>
<br>POSIX is already a standard.
<br>
<br>&gt; That would be really of high value for porting CLI applications cr=
oss-platform.
<br>
<br>Ask your platform vendor to implement it. (Who hasn=E2=80=99t?)
<br>
<br>C++ does define =E2=80=9Cstreams=E2=80=9D with byte, text, and code-poi=
nt orientation, but not much in the way of operational semantics. User inte=
rfaces are rightly left to the OS.</blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_207_127381134.1415933418987--

.

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

Being C++, we probably wouldn't standardize the C getopt interfaces, but
there's definitely some interest in command-line parsing. Boost libraries
or other existing practice are always a good start if you want to propose
something.

On Thu, Nov 13, 2014 at 5:46 PM, <adeel.bm@gmail.com> wrote:

> Any thoughts about standardizing POSIX getopt.h and getopt.cpp (and its
> variant getoptlong) ?
>
> That would be really of high value for porting CLI applications
> cross-platform.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr">Being C++, we probably wouldn&#39;t standardize the C geto=
pt interfaces, but there&#39;s definitely some interest in command-line par=
sing. Boost libraries or other existing practice are always a good start if=
 you want to propose something.<br><div class=3D"gmail_extra"><br><div clas=
s=3D"gmail_quote">On Thu, Nov 13, 2014 at 5:46 PM,  <span dir=3D"ltr">&lt;<=
a href=3D"mailto:adeel.bm@gmail.com" target=3D"_blank" class=3D"cremed">ade=
el.bm@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"><di=
v dir=3D"ltr"><div>Any thoughts about standardizing POSIX getopt.h and geto=
pt.cpp (and its variant getoptlong) ? </div><div><br></div><div>That would =
be really of high value=C2=A0for porting CLI applications cross-platform.</=
div></div><span class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

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

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c1f80408c14f0507ccdc19--

.

------=_Part_9_1691682596.1415967004029
Content-Type: text/plain; charset=UTF-8

On Friday, November 14, 2014 3:50:19 AM UTC+1, adee...@gmail.com wrote:
>
> Now here is the thing, many folks don't want to include boost in their
> projects for these small discrepancies,
>

Why not?

 rather they would opt for adding "guards", which -- I believe -- doesn't
go hand-in-hand with what ISOCPP is trying to bring to the table.

What's "guards"?
Wouldn't getopt make more sense in ISO C?

--

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

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

<div dir=3D"ltr">On Friday, November 14, 2014 3:50:19 AM UTC+1, adee...@gma=
il.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div>Now here is the thing, many&nbsp;folks don't want to include boost in =
their projects for these small discrepancies, </div></div></blockquote><div=
><br></div><div>Why not?</div><div><br></div><div>&nbsp;rather they would o=
pt for adding "guards", which --&nbsp;I believe --&nbsp;doesn't go hand-in-=
hand with what ISOCPP is trying to bring to the table.</div><div><br></div>=
<div>What's "guards"?</div><div>Wouldn't getopt make more sense in ISO C?</=
div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_9_1691682596.1415967004029--

.

--part1403-boundary-1917562533-1918638443
Content-Type: text/plain; charset=UTF-8

Fwiw, http://getoptpp.googlecode.com (though >6 years old) proved useful, and could be taken into account as a possible approach.
-----Original Message-----
From: "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 13 Nov 2014 23:48:29
To: <std-proposals@isocpp.org>
Reply-To: std-proposals@isocpp.org
Subject: Re: [std-proposals] Standard getopt and its variants

Being C++, we probably wouldn't standardize the C getopt interfaces, but
there's definitely some interest in command-line parsing. Boost libraries
or other existing practice are always a good start if you want to propose
something.

On Thu, Nov 13, 2014 at 5:46 PM, <adeel.bm@gmail.com> wrote:

> Any thoughts about standardizing POSIX getopt.h and getopt.cpp (and its
> variant getoptlong) ?
>
> That would be really of high value for porting CLI applications
> cross-platform.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

--

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

--part1403-boundary-1917562533-1918638443
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><html><head><=
meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type"></h=
ead><body>Fwiw, http://getoptpp.googlecode.com (though &gt;6 years old) pro=
ved useful, and could be taken into account as a possible approach.<hr/><di=
v><b>From: </b> "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals"=
 &lt;std-proposals@isocpp.org&gt;
</div><div><b>Date: </b>Thu, 13 Nov 2014 23:48:29 -0800</div><div><b>To: </=
b>&lt;std-proposals@isocpp.org&gt;</div><div><b>ReplyTo: </b> std-proposals=
@isocpp.org
</div><div><b>Subject: </b>Re: [std-proposals] Standard getopt and its vari=
ants</div><div><br/></div><div dir=3D"ltr">Being C++, we probably wouldn&#3=
9;t standardize the C getopt interfaces, but there&#39;s definitely some in=
terest in command-line parsing. Boost libraries or other existing practice =
are always a good start if you want to propose something.<br><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">On Thu, Nov 13, 2014 at 5:46 PM=
,  <span dir=3D"ltr">&lt;<a href=3D"mailto:adeel.bm@gmail.com" target=3D"_b=
lank" class=3D"cremed">adeel.bm@gmail.com</a>&gt;</span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div>Any thoughts about standardizi=
ng POSIX getopt.h and getopt.cpp (and its variant getoptlong) ? </div><div>=
<br></div><div>That would be really of high value=C2=A0for porting CLI appl=
ications cross-platform.</div></div><span class=3D"HOEnZb"><font color=3D"#=
888888">

<p></p>

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

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

</body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--part1403-boundary-1917562533-1918638443--


.

------=_Part_1037_1774721294.1415990663041
Content-Type: text/plain; charset=UTF-8

> What "guards"?

For instance; we are using getopt guard from MinGW in sass-win
https://github.com/darrenkopp/sassc-win.

> Wouldn't getopt make more sense in ISO C?

Yes, I guess this proposal belongs to http://www.open-std.org/ then.


On Friday, November 14, 2014 2:10:04 PM UTC+2, Olaf van der Spek wrote:

> On Friday, November 14, 2014 3:50:19 AM UTC+1, adee...@gmail.com wrote:
>>
>> Now here is the thing, many folks don't want to include boost in their
>> projects for these small discrepancies,
>>
>
> Why not?
>
>  rather they would opt for adding "guards", which -- I believe -- doesn't
> go hand-in-hand with what ISOCPP is trying to bring to the table.
>
> What's "guards"?
> Wouldn't getopt make more sense in ISO C?
>

--

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

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

<div dir=3D"ltr"><div>&gt; What "guards"?</div><div><br></div><div>For inst=
ance; we are using getopt guard from MinGW in sass-win <a href=3D"https://g=
ithub.com/darrenkopp/sassc-win">https://github.com/darrenkopp/sassc-win</a>=
..</div><div><br></div><div>&gt; Wouldn't getopt make more sense in ISO C?</=
div><div><br></div><div>Yes,&nbsp;I&nbsp;guess&nbsp;this proposal&nbsp;belo=
ngs to <a href=3D"http://www.open-std.org/">http://www.open-std.org/</a>&nb=
sp;then.</div><div><br><br>On Friday, November 14, 2014 2:10:04 PM UTC+2, O=
laf van der Spek wrote:</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204,=
 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">=
On Friday, November 14, 2014 3:50:19 AM UTC+1, <a>adee...@gmail.com</a> wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; pa=
dding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: =
1px; border-left-style: solid;"><div dir=3D"ltr"><div>Now here is the thing=
, many&nbsp;folks don't want to include boost in their projects for these s=
mall discrepancies, </div></div></blockquote><div><br></div><div>Why not?</=
div><div><br></div><div>&nbsp;rather they would opt for adding "guards", wh=
ich --&nbsp;I believe --&nbsp;doesn't go hand-in-hand with what ISOCPP is t=
rying to bring to the table.</div><div><br></div><div>What's "guards"?</div=
><div>Wouldn't getopt make more sense in ISO C?</div></div></blockquote></d=
iv>

<p></p>

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

------=_Part_1037_1774721294.1415990663041--

.

On Friday 14 November 2014 10:44:23 adeel.bm@gmail.com wrote:
> > What "guards"?
>
> For instance; we are using getopt guard from MinGW in sass-win
> https://github.com/darrenkopp/sassc-win.

You didn't answer what a "guard" is.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

------=_Part_1220_1412075908.1416001415580
Content-Type: text/plain; charset=UTF-8

In case the header file is missing from the compiler's lib, use the
fallback header. Mostly used in case of supporting windows, where C99
headers are not available. Similar concept I as the multi-inclusion guards.

On Friday, November 14, 2014 9:06:19 PM UTC+2, Thiago Macieira wrote:
>
> On Friday 14 November 2014 10:44:23 adee...@gmail.com <javascript:>
> wrote:
> > > What "guards"?
> >
> > For instance; we are using getopt guard from MinGW in sass-win
> > https://github.com/darrenkopp/sassc-win.
>
> You didn't answer what a "guard" is.
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
>

--

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

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

<div dir=3D"ltr">In case the header file is missing from the compiler's lib=
, use the fallback header. Mostly used in case of supporting windows, where=
 C99 headers are not available. Similar concept I as the&nbsp;multi-inclusi=
on guards.<br><br>On Friday, November 14, 2014 9:06:19 PM UTC+2, Thiago Mac=
ieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px =
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-lef=
t-width: 1px; border-left-style: solid;">On Friday 14 November 2014 10:44:2=
3 <a onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this=
..href=3D'javascript:';return true;" href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"HcM5-5aCnoYJ">adee...@gmail.com</a> wrote:
<br>&gt; &gt; What "guards"?
<br>&gt;=20
<br>&gt; For instance; we are using getopt guard from MinGW in sass-win=20
<br>&gt; <a onmousedown=3D"this.href=3D'https://www.google.com/url?q\75http=
s%3A%2F%2Fgithub.com%2Fdarrenkopp%2Fsassc-win\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHB8VXc7kGMW3oHp3Qb9U0efLgDxg';return true;" onclick=3D"this.href=3D'h=
ttps://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fdarrenkopp%2Fsassc=
-win\46sa\75D\46sntz\0751\46usg\75AFQjCNHB8VXc7kGMW3oHp3Qb9U0efLgDxg';retur=
n true;" href=3D"https://github.com/darrenkopp/sassc-win" target=3D"_blank"=
>https://github.com/darrenkopp/<wbr>sassc-win</a>.
<br>
<br>You didn't answer what a "guard" is.
<br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D'http://www=
..google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\07=
51\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" href=3D"http:/=
/macieira.info" target=3D"_blank">macieira.info</a> - thiago (AT) <a onmous=
edown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.org\46=
sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;=
" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.or=
g\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return t=
rue;" href=3D"http://kde.org" target=3D"_blank">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1220_1412075908.1416001415580--

.

So what's the problem?

On Fri, Nov 14, 2014 at 10:43 PM,  <adeel.bm@gmail.com> wrote:
> In case the header file is missing from the compiler's lib, use the fallback
> header. Mostly used in case of supporting windows, where C99 headers are not
> available. Similar concept I as the multi-inclusion guards.
>
> On Friday, November 14, 2014 9:06:19 PM UTC+2, Thiago Macieira wrote:
>>
>> On Friday 14 November 2014 10:44:23 adee...@gmail.com wrote:
>> > > What "guards"?
>> >
>> > For instance; we are using getopt guard from MinGW in sass-win
>> > https://github.com/darrenkopp/sassc-win.
>>
>> You didn't answer what a "guard" is.
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>    Software Architect - Intel Open Source Technology Center
>>       PGP/GPG: 0x6EF45358; fingerprint:
>>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/CNDl0nYrlko/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.



--
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 11/14/2014 1:48 AM, 'Jeffrey Yasskin' via ISO C++ Standard - Future
Proposals wrote:
> Being C++, we probably wouldn't standardize the C getopt interfaces, but
> there's definitely some interest in command-line parsing. Boost
> libraries or other existing practice are always a good start if you want
> to propose something.

I've actually been thinking about command-line parsing a lot lately,
mainly because I'm bumping up against the edge of what
Boost.Program_Options can do. If there really is interest in an options
parser for ISO C++, I might have something to present in a couple of months.

However, I'm not convinced that this is the sort of library that C++
needs (at least, not right now). I'm not entirely sure a
one-size-fits-all solution for command-line parsing exists, and it would
be a shame to standardize something that didn't suffice for many people.

Option-parsing conventions are also tied to the OS, and ISO C++ might be
the wrong place to define such a convention. POSIX systems generally use
"-" for options, while Windows uses "/"; would ISO C++ need to pick one
as the "blessed" prefix, or would users be required to specify which
they want?

Going back to the original author's argument that users don't want to
add a Boost dependency for things, I think this is mostly tilting at
windmills. Still, there's some merit in the idea of a "modular Boost",
where you don't need to grab the entire project just to use the one
library you want. That's more of a discussion for the Boost list, though.

- Jim

--

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

.

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

On Sat, Nov 15, 2014 at 9:47 AM, Jim Porter <jvp4846@g.rit.edu> wrote:

> On 11/14/2014 1:48 AM, 'Jeffrey Yasskin' via ISO C++ Standard - Future
> Proposals wrote:
>
>> Being C++, we probably wouldn't standardize the C getopt interfaces, but
>> there's definitely some interest in command-line parsing. Boost
>> libraries or other existing practice are always a good start if you want
>> to propose something.
>>
>
> I've actually been thinking about command-line parsing a lot lately,
> mainly because I'm bumping up against the edge of what
> Boost.Program_Options can do. If there really is interest in an options
> parser for ISO C++, I might have something to present in a couple of months.
>
> However, I'm not convinced that this is the sort of library that C++ needs
> (at least, not right now). I'm not entirely sure a one-size-fits-all
> solution for command-line parsing exists, and it would be a shame to
> standardize something that didn't suffice for many people.
>
> Option-parsing conventions are also tied to the OS, and ISO C++ might be
> the wrong place to define such a convention. POSIX systems generally use
> "-" for options, while Windows uses "/"; would ISO C++ need to pick one as
> the "blessed" prefix, or would users be required to specify which they want?
>
> Going back to the original author's argument that users don't want to add
> a Boost dependency for things, I think this is mostly tilting at windmills.
> Still, there's some merit in the idea of a "modular Boost", where you don't
> need to grab the entire project just to use the one library you want.
> That's more of a discussion for the Boost list, though.


I can't say that a command-line-parsing library is definitely a good idea,
but there's been interest in it in the past. For cross-platform options,
take a look at what scripting languages have done, and consider the
Filesystem TS's approach of having an explicit "native" option.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Nov 15, 2014 at 9:47 AM, Jim Porter <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:jvp4846@g.rit.edu" target=3D"_blank" class=3D"cremed">jvp4846@g.rit.ed=
u</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">=
On 11/14/2014 1:48 AM, &#39;Jeffrey Yasskin&#39; via ISO C++ Standard - Fut=
ure Proposals wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Being C++, we probably wouldn&#39;t standardize the C getopt interfaces, bu=
t<br>
there&#39;s definitely some interest in command-line parsing. Boost<br>
libraries or other existing practice are always a good start if you want<br=
>
to propose something.<br>
</blockquote>
<br></span>
I&#39;ve actually been thinking about command-line parsing a lot lately, ma=
inly because I&#39;m bumping up against the edge of what Boost.Program_Opti=
ons can do. If there really is interest in an options parser for ISO C++, I=
 might have something to present in a couple of months.<br>
<br>
However, I&#39;m not convinced that this is the sort of library that C++ ne=
eds (at least, not right now). I&#39;m not entirely sure a one-size-fits-al=
l solution for command-line parsing exists, and it would be a shame to stan=
dardize something that didn&#39;t suffice for many people.<br>
<br>
Option-parsing conventions are also tied to the OS, and ISO C++ might be th=
e wrong place to define such a convention. POSIX systems generally use &quo=
t;-&quot; for options, while Windows uses &quot;/&quot;; would ISO C++ need=
 to pick one as the &quot;blessed&quot; prefix, or would users be required =
to specify which they want?<br>
<br>
Going back to the original author&#39;s argument that users don&#39;t want =
to add a Boost dependency for things, I think this is mostly tilting at win=
dmills. Still, there&#39;s some merit in the idea of a &quot;modular Boost&=
quot;, where you don&#39;t need to grab the entire project just to use the =
one library you want. That&#39;s more of a discussion for the Boost list, t=
hough.</blockquote><div><br></div></div>I can&#39;t say that a command-line=
-parsing library is definitely a good idea, but there&#39;s been interest i=
n it in the past. For cross-platform options, take a look at what scripting=
 languages have done, and consider the Filesystem TS&#39;s approach of havi=
ng an explicit &quot;native&quot; option.</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e01634038bae71e0507e99ea8--

.

On 15 November 2014 20:07, 'Jeffrey Yasskin' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> On Sat, Nov 15, 2014 at 9:47 AM, Jim Porter <jvp4846@g.rit.edu> wrote:
>>
>> On 11/14/2014 1:48 AM, 'Jeffrey Yasskin' via ISO C++ Standard - Future
>> Proposals wrote:
>>>
>>> Being C++, we probably wouldn't standardize the C getopt interfaces, but
>>> there's definitely some interest in command-line parsing. Boost
>>> libraries or other existing practice are always a good start if you want
>>> to propose something.
>>
>>
>> I've actually been thinking about command-line parsing a lot lately,
>> mainly because I'm bumping up against the edge of what Boost.Program_Options
>> can do. If there really is interest in an options parser for ISO C++, I
>> might have something to present in a couple of months.
>>
>> However, I'm not convinced that this is the sort of library that C++ needs
>> (at least, not right now). I'm not entirely sure a one-size-fits-all
>> solution for command-line parsing exists, and it would be a shame to
>> standardize something that didn't suffice for many people.
>>
>> Option-parsing conventions are also tied to the OS, and ISO C++ might be
>> the wrong place to define such a convention. POSIX systems generally use "-"
>> for options, while Windows uses "/"; would ISO C++ need to pick one as the
>> "blessed" prefix, or would users be required to specify which they want?
>>
>> Going back to the original author's argument that users don't want to add
>> a Boost dependency for things, I think this is mostly tilting at windmills.
>> Still, there's some merit in the idea of a "modular Boost", where you don't
>> need to grab the entire project just to use the one library you want. That's
>> more of a discussion for the Boost list, though.
>
>
> I can't say that a command-line-parsing library is definitely a good idea,
> but there's been interest in it in the past. For cross-platform options,
> take a look at what scripting languages have done, and consider the
> Filesystem TS's approach of having an explicit "native" option.


And do remember that using slashes is just.. ..unwise. Even on windows.
I don't know whether option parsing/handling is general enough to be
standardized. I know it would be damn useful for writing cross-platform
code especially for users to whom boost is too much of a dependency.

--

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

.

This looks like a candidate Y/N EWG vote.

If I could get "enough" people here to take a look at the library I mention=
ed (getoptpp), I could make a quick presentation for Lenexa for such a Y/N =
vote to determine whether it's worth keeping forward or not. A full proposa=
l without such a vote seems to me a risk of a waste of time.
-----Original Message-----
From: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 15 Nov 2014 20:16:10=20
To: <std-proposals@isocpp.org>
Reply-To: std-proposals@isocpp.org
Subject: Re: [std-proposals] Re: Standard getopt and its variants

On 15 November 2014 20:07, 'Jeffrey Yasskin' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> On Sat, Nov 15, 2014 at 9:47 AM, Jim Porter <jvp4846@g.rit.edu> wrote:
>>
>> On 11/14/2014 1:48 AM, 'Jeffrey Yasskin' via ISO C++ Standard - Future
>> Proposals wrote:
>>>
>>> Being C++, we probably wouldn't standardize the C getopt interfaces, bu=
t
>>> there's definitely some interest in command-line parsing. Boost
>>> libraries or other existing practice are always a good start if you wan=
t
>>> to propose something.
>>
>>
>> I've actually been thinking about command-line parsing a lot lately,
>> mainly because I'm bumping up against the edge of what Boost.Program_Opt=
ions
>> can do. If there really is interest in an options parser for ISO C++, I
>> might have something to present in a couple of months.
>>
>> However, I'm not convinced that this is the sort of library that C++ nee=
ds
>> (at least, not right now). I'm not entirely sure a one-size-fits-all
>> solution for command-line parsing exists, and it would be a shame to
>> standardize something that didn't suffice for many people.
>>
>> Option-parsing conventions are also tied to the OS, and ISO C++ might be
>> the wrong place to define such a convention. POSIX systems generally use=
 "-"
>> for options, while Windows uses "/"; would ISO C++ need to pick one as t=
he
>> "blessed" prefix, or would users be required to specify which they want?
>>
>> Going back to the original author's argument that users don't want to ad=
d
>> a Boost dependency for things, I think this is mostly tilting at windmil=
ls.
>> Still, there's some merit in the idea of a "modular Boost", where you do=
n't
>> need to grab the entire project just to use the one library you want. Th=
at's
>> more of a discussion for the Boost list, though.
>
>
> I can't say that a command-line-parsing library is definitely a good idea=
,
> but there's been interest in it in the past. For cross-platform options,
> take a look at what scripting languages have done, and consider the
> Filesystem TS's approach of having an explicit "native" option.


And do remember that using slashes is just.. ..unwise. Even on windows.
I don't know whether option parsing/handling is general enough to be
standardized. I know it would be damn useful for writing cross-platform
code especially for users to whom boost is too much of a dependency.

--=20

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

--=20

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

.

------=_Part_1838_371399204.1416089647578
Content-Type: text/plain; charset=UTF-8

Hello,

Thank you for setting the course straight. :)

I am not C++ developer by trade. I sometimes contribute with tiny C++
chores to GitHub and rarely on my job, for performance-oriented tasks.
This is a kind of pattern I have been observing on GitHub repositories that
if you package the header and implementation files to complement a
functionality missing in certain compiler (msvcr for example), it comes as
(comparatively) unappealing. VC guys on the other hand, seems to be
unconvinced by anything non-standard C/C++. Which I think is good because
if they do provide a vendor-specific command line utility library, it might
not work with POSIX systems.

> Option-parsing conventions are also tied to the OS, and ISO C++ might be
> the wrong place to define such a convention. POSIX systems generally use
> "-" for options, while Windows uses "/"; would ISO C++ need to pick one
> as the "blessed" prefix, or would users be required to specify which
> they want?

Apparently, Windows is confused; in command prompt, it uses forward slashes
in options and back slashes in path. On powershell, it allows hyphened
options (in addition to command prompt style options) and also allows
forward slashes in path. For instance, this:

*rm -r ./node_modules*

works on powershell. The counterpart in cmd is:

*rmdir /s .\node_modules*

(which also works in powershell but not vice versa)

Perhaps, the spec may just use hyphen as primary identifier for options and
forward slash as secondary one.

Nonetheless, both appear to have edge cases, when there are whitespaces in
path.
Wrapping the path in (single/double) quotes differentiates it from options:

*(1) command --some-option -o '/path/to -some/destination'*

No doubt, backslashes cause more confusion. Consider these commands:

*(2) command /a/b .\path\to-some\destination /x*
*(3) command /foo/bar '/path/to some/destination' /xyz*

Since powershell supports mix-mode (and also supports cmd style commands),
#2's parsing can be erroneous, if we use forward slash in path:

*(4) command /a/b ./path/to-some/destination /x*

In this case, there is a tie between first set of options and path. I am
not sure, how powershell's command parser make decisions in such edge cases.

Perhaps there exists a sane strategy to handle these edge cases (or even
more complicated ones) -- as you put; *one-size-fits-all*.


*-- best*
Adeel


On Saturday, November 15, 2014 7:48:23 PM UTC+2, Jim Porter wrote:

> On 11/14/2014 1:48 AM, 'Jeffrey Yasskin' via ISO C++ Standard - Future
> Proposals wrote:
> > Being C++, we probably wouldn't standardize the C getopt interfaces, but
> > there's definitely some interest in command-line parsing. Boost
> > libraries or other existing practice are always a good start if you want
> > to propose something.
>
> I've actually been thinking about command-line parsing a lot lately,
> mainly because I'm bumping up against the edge of what
> Boost.Program_Options can do. If there really is interest in an options
> parser for ISO C++, I might have something to present in a couple of
> months.
>
> However, I'm not convinced that this is the sort of library that C++
> needs (at least, not right now). I'm not entirely sure a
> one-size-fits-all solution for command-line parsing exists, and it would
> be a shame to standardize something that didn't suffice for many people.
>
> Option-parsing conventions are also tied to the OS, and ISO C++ might be
> the wrong place to define such a convention. POSIX systems generally use
> "-" for options, while Windows uses "/"; would ISO C++ need to pick one
> as the "blessed" prefix, or would users be required to specify which
> they want?
>
> Going back to the original author's argument that users don't want to
> add a Boost dependency for things, I think this is mostly tilting at
> windmills. Still, there's some merit in the idea of a "modular Boost",
> where you don't need to grab the entire project just to use the one
> library you want. That's more of a discussion for the Boost list, though.
>
> - Jim
>
>

--

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

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

<div dir=3D"ltr"><div>Hello,</div><div><br></div><div>Thank you&nbsp;for se=
tting the course straight. :)</div><div><br></div><div>I am not C++ develop=
er by trade. I sometimes contribute with tiny C++ chores to GitHub and&nbsp=
;rarely on my job, for performance-oriented tasks.</div><div>This is a kind=
 of pattern I have been observing on GitHub repositories that if you packag=
e the header and&nbsp;implementation files to complement a functionality mi=
ssing in certain compiler (msvcr for example), it comes as (comparatively) =
unappealing. VC guys on the other hand, seems to&nbsp;be unconvinced by any=
thing non-standard C/C++. Which I think is good&nbsp;because if they do pro=
vide a vendor-specific command line utility library, it&nbsp;might not&nbsp=
;work with POSIX systems.&nbsp;</div><div><br></div><div>&gt; Option-parsin=
g conventions are also tied to the OS, and ISO C++ might be  <br>&gt; the w=
rong place to define such a convention. POSIX systems generally use  <br>&g=
t; "-" for options, while Windows uses "/"; would ISO C++ need to pick one =
 <br>&gt; as the "blessed" prefix, or would users be required to specify wh=
ich  <br>&gt; they want? <br></div><div><br></div><div>Apparently,&nbsp;Win=
dows is confused; in command prompt, it uses forward slashes in options and=
 back slashes in path. On powershell, it allows hyphened options&nbsp;(in a=
ddition to command prompt style options) and also allows forward slashes in=
 path. For instance, this:</div><div><br></div><div><strong>rm -r ./node_mo=
dules</strong></div><div><br></div><div>works on powershell. The counterpar=
t in cmd is:</div><div><br></div><div><strong>rmdir /s .\node_modules</stro=
ng></div><div><br></div><div>(which also works in powershell but not vice v=
ersa)</div><div><br></div><div>Perhaps, the spec&nbsp;may&nbsp;just use&nbs=
p;hyphen as primary identifier for options and forward slash as&nbsp;second=
ary one.</div><div><br></div><div>Nonetheless, both appear to have edge cas=
es, when there are whitespaces in path. </div><div>Wrapping the path in (si=
ngle/double) quotes&nbsp;differentiates it from options:</div><div><br></di=
v><div><strong>(1) command --some-option -o&nbsp;'/path/to -some/destinatio=
n'</strong></div><div><br></div><div>No doubt,&nbsp;backslashes&nbsp;cause =
more confusion. Consider these commands:</div><div><br></div><div><strong>(=
2)&nbsp;command /a/b&nbsp;.\path\to-some\destination /x</strong></div><div>=
<strong>(3)&nbsp;command /foo/bar&nbsp;'/path/to some/destination' /xyz</st=
rong></div><div><br></div><div>Since powershell supports mix-mode (and also=
 supports cmd style commands), #2's parsing can be erroneous, if we use for=
ward slash in path:</div><div><br></div><div><strong>(4) command /a/b ./pat=
h/to-some/destination /x</strong></div><div><br></div><div>In this case, th=
ere is a tie between first set of options and path. I&nbsp;am not sure, how=
&nbsp;powershell's command parser&nbsp;make decisions in&nbsp;such edge cas=
es.</div><div><br></div><div>Perhaps there&nbsp;exists a&nbsp;sane strategy=
 to handle these edge cases (or even more complicated ones)&nbsp;--&nbsp;as=
 you put; <em>one-size-fits-all</em>.</div><div><br></div><div><br></div><d=
iv><em>-- best</em></div><div>Adeel</div><div><br></div><div><br>On Saturda=
y, November 15, 2014 7:48:23 PM UTC+2, Jim Porter wrote:</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex;=
 border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left=
-style: solid;">On 11/14/2014 1:48 AM, 'Jeffrey Yasskin' via ISO C++ Standa=
rd - Future=20
<br>Proposals wrote:
<br>&gt; Being C++, we probably wouldn't standardize the C getopt interface=
s, but
<br>&gt; there's definitely some interest in command-line parsing. Boost
<br>&gt; libraries or other existing practice are always a good start if yo=
u want
<br>&gt; to propose something.
<br>
<br>I've actually been thinking about command-line parsing a lot lately,=20
<br>mainly because I'm bumping up against the edge of what=20
<br>Boost.Program_Options can do. If there really is interest in an options=
=20
<br>parser for ISO C++, I might have something to present in a couple of mo=
nths.
<br>
<br>However, I'm not convinced that this is the sort of library that C++=20
<br>needs (at least, not right now). I'm not entirely sure a=20
<br>one-size-fits-all solution for command-line parsing exists, and it woul=
d=20
<br>be a shame to standardize something that didn't suffice for many people=
..
<br>
<br>Option-parsing conventions are also tied to the OS, and ISO C++ might b=
e=20
<br>the wrong place to define such a convention. POSIX systems generally us=
e=20
<br>"-" for options, while Windows uses "/"; would ISO C++ need to pick one=
=20
<br>as the "blessed" prefix, or would users be required to specify which=20
<br>they want?
<br>
<br>Going back to the original author's argument that users don't want to=
=20
<br>add a Boost dependency for things, I think this is mostly tilting at=20
<br>windmills. Still, there's some merit in the idea of a "modular Boost",=
=20
<br>where you don't need to grab the entire project just to use the one=20
<br>library you want. That's more of a discussion for the Boost list, thoug=
h.
<br>
<br>- Jim
<br>
<br></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1838_371399204.1416089647578--

.

On 11/15/2014 4:14 PM, adeel.bm@gmail.com wrote:
> VC guys on the other hand, seems to be unconvinced by anything
> non-standard C/C++.

Oh, don't I wish. Honestly, if I had to pick a compiler that had the
greatest number of non-standard extensions, it'd almost certainly be
MSVC. (A good example of this in action is to look at the amount of work
the clang developers have had to do in order to make clang a drop-in
replacement for cl.exe.)

It does, however, seem that there's a fairly strong resistance to making
MSVC a better C99/C11 compiler, or a more-complete implementation of
POSIX. It seems that most C99 support in MSVC just comes from C++
requiring it, not from C99 itself.

> Perhaps there exists a sane strategy to handle these edge cases (or
> even more complicated ones) -- as you put; /one-size-fits-all/.

I think the closest to a one-size-fits-all command line parser is
Boost.Program_Options (but even that still isn't quite there). Unlike
many other such libraries, it's quite extensible, and allows you to
parse options from .ini files or environment variables. It's even
possible (and in fact, pretty easy) to make your own parsers; for
instance, I wrote a simple Boost.Program_Options parser that parses
command-line options from code comments (think like file variables in
emacs).

Boost.Program_Options isn't without its problems though. It can be
fairly obnoxious to forward arguments on to other programs, and much of
its design could be simplified with C++11/14 features. I've been
planning on writing my own command-line parser to address these issues,
but it's not a very high priority at the moment. However, perhaps such a
library (independent from Boost) would suit your needs regardless of
whether it was an ISO-standardized library.

- Jim

--

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

.

------=_Part_305_1605149644.1416094010413
Content-Type: text/plain; charset=UTF-8



On Saturday, November 15, 2014 11:14:07 PM UTC+1, adee...@gmail.com wrote:
>
> This is a kind of pattern I have been observing on GitHub repositories
> that if you package the header and implementation files to complement a
> functionality missing in certain compiler (msvcr for example), it comes as
> (comparatively) unappealing. VC guys on the other hand, seems to be
> unconvinced by anything non-standard C/C++. Which I think is good because
> if they do provide a vendor-specific command line utility library, it might
> not work with POSIX systems.
>
>>
>>
So the (real) problem is difficulty in consuming C++ libs (on Windows)?


--

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

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

<div dir=3D"ltr"><br><br>On Saturday, November 15, 2014 11:14:07 PM UTC+1, =
adee...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div>This is a kind of pattern I have been observing on GitHub r=
epositories that if you package the header and&nbsp;implementation files to=
 complement a functionality missing in certain compiler (msvcr for example)=
, it comes as (comparatively) unappealing. VC guys on the other hand, seems=
 to&nbsp;be unconvinced by anything non-standard C/C++. Which I think is go=
od&nbsp;because if they do provide a vendor-specific command line utility l=
ibrary, it&nbsp;might not&nbsp;work with POSIX systems.&nbsp;<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-lef=
t:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-=
style:solid"><br></blockquote></div></blockquote><div><br></div><div>So the=
 (real) problem is difficulty in consuming C++ libs (on Windows)?</div><div=
>&nbsp;</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_305_1605149644.1416094010413--

.

------=_Part_552_1767113501.1416096383562
Content-Type: text/plain; charset=UTF-8

> Oh, don't I wish. Honestly, if I had to pick a compiler that had the
greatest number of non-standard extensions,

Their recent blogs and comments conversations suggest they are embracing
standard C++ and cleaning the non-standard support. That's what I read
but looks like there is more to that story. :)

On Sunday, November 16, 2014 12:43:29 AM UTC+2, Jim Porter wrote:

> On 11/15/2014 4:14 PM, adee...@gmail.com <javascript:> wrote:
> > VC guys on the other hand, seems to be unconvinced by anything
> > non-standard C/C++.
>
> Oh, don't I wish. Honestly, if I had to pick a compiler that had the
> greatest number of non-standard extensions, it'd almost certainly be
> MSVC. (A good example of this in action is to look at the amount of work
> the clang developers have had to do in order to make clang a drop-in
> replacement for cl.exe.)
>
> It does, however, seem that there's a fairly strong resistance to making
> MSVC a better C99/C11 compiler, or a more-complete implementation of
> POSIX. It seems that most C99 support in MSVC just comes from C++
> requiring it, not from C99 itself.
>
> > Perhaps there exists a sane strategy to handle these edge cases (or
> > even more complicated ones) -- as you put; /one-size-fits-all/.
>
> I think the closest to a one-size-fits-all command line parser is
> Boost.Program_Options (but even that still isn't quite there). Unlike
> many other such libraries, it's quite extensible, and allows you to
> parse options from .ini files or environment variables. It's even
> possible (and in fact, pretty easy) to make your own parsers; for
> instance, I wrote a simple Boost.Program_Options parser that parses
> command-line options from code comments (think like file variables in
> emacs).
>
> Boost.Program_Options isn't without its problems though. It can be
> fairly obnoxious to forward arguments on to other programs, and much of
> its design could be simplified with C++11/14 features. I've been
> planning on writing my own command-line parser to address these issues,
> but it's not a very high priority at the moment. However, perhaps such a
> library (independent from Boost) would suit your needs regardless of
> whether it was an ISO-standardized library.
>
> - Jim
>
>

--

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

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

<div dir=3D"ltr"><div>&gt; Oh, don't I wish. Honestly, if I had to pick a c=
ompiler that had the  <br>greatest number of non-standard extensions,</div>=
<div><br></div><div>Their recent blogs and comments conversations suggest&n=
bsp;they are&nbsp;embracing standard C++ and&nbsp;cleaning the&nbsp;non-sta=
ndard support. That's what I&nbsp;read but&nbsp;looks like there is more to=
 that story. :)<br><br>On Sunday, November 16, 2014 12:43:29 AM UTC+2, Jim =
Porter wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;">On 11/15/2014 4:14 PM, <a o=
nmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;" href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"bGh11olhC_8J">adee...@gmail.com</a> wrote:
<br>&gt; VC guys on the other hand, seems to be unconvinced by anything
<br>&gt; non-standard C/C++.
<br>
<br>Oh, don't I wish. Honestly, if I had to pick a compiler that had the=20
<br>greatest number of non-standard extensions, it'd almost certainly be=20
<br>MSVC. (A good example of this in action is to look at the amount of wor=
k=20
<br>the clang developers have had to do in order to make clang a drop-in=20
<br>replacement for cl.exe.)
<br>
<br>It does, however, seem that there's a fairly strong resistance to makin=
g=20
<br>MSVC a better C99/C11 compiler, or a more-complete implementation of=20
<br>POSIX. It seems that most C99 support in MSVC just comes from C++=20
<br>requiring it, not from C99 itself.
<br>
<br>&gt; Perhaps there exists a sane strategy to handle these edge cases (o=
r
<br>&gt; even more complicated ones) -- as you put; /one-size-fits-all/.
<br>
<br>I think the closest to a one-size-fits-all command line parser is=20
<br>Boost.Program_Options (but even that still isn't quite there). Unlike=
=20
<br>many other such libraries, it's quite extensible, and allows you to=20
<br>parse options from .ini files or environment variables. It's even=20
<br>possible (and in fact, pretty easy) to make your own parsers; for=20
<br>instance, I wrote a simple Boost.Program_Options parser that parses=20
<br>command-line options from code comments (think like file variables in=
=20
<br>emacs).
<br>
<br>Boost.Program_Options isn't without its problems though. It can be=20
<br>fairly obnoxious to forward arguments on to other programs, and much of=
=20
<br>its design could be simplified with C++11/14 features. I've been=20
<br>planning on writing my own command-line parser to address these issues,=
=20
<br>but it's not a very high priority at the moment. However, perhaps such =
a=20
<br>library (independent from Boost) would suit your needs regardless of=20
<br>whether it was an ISO-standardized library.
<br>
<br>- Jim
<br>
<br></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_552_1767113501.1416096383562--

.

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

I'm personally favorable on command line parsing in the standard library,
but I'm skeptical of getoptpp's choice to use the stream operators for it.

LEWG will be happy to look at any papers folks write. We're likely to say
"yes, do more work" for any proposal that's not fully fleshed out, so it's
probably a good idea to include specific questions we should answer in
order to help direct that more work. We'll also appreciate comparisons to a
wide range of existing practice, rather than just a single library.

On Sat, Nov 15, 2014 at 11:41 AM, Daniel Gutson <danielgutson@gmail.com>
wrote:

> This looks like a candidate Y/N EWG vote.
>
> If I could get "enough" people here to take a look at the library I
> mentioned (getoptpp), I could make a quick presentation for Lenexa for such
> a Y/N vote to determine whether it's worth keeping forward or not. A full
> proposal without such a vote seems to me a risk of a waste of time.
> -----Original Message-----
> From: Ville Voutilainen <ville.voutilainen@gmail.com>
> Date: Sat, 15 Nov 2014 20:16:10
> To: <std-proposals@isocpp.org>
> Reply-To: std-proposals@isocpp.org
> Subject: Re: [std-proposals] Re: Standard getopt and its variants
>
> On 15 November 2014 20:07, 'Jeffrey Yasskin' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
> > On Sat, Nov 15, 2014 at 9:47 AM, Jim Porter <jvp4846@g.rit.edu> wrote:
> >>
> >> On 11/14/2014 1:48 AM, 'Jeffrey Yasskin' via ISO C++ Standard - Future
> >> Proposals wrote:
> >>>
> >>> Being C++, we probably wouldn't standardize the C getopt interfaces,
> but
> >>> there's definitely some interest in command-line parsing. Boost
> >>> libraries or other existing practice are always a good start if you
> want
> >>> to propose something.
> >>
> >>
> >> I've actually been thinking about command-line parsing a lot lately,
> >> mainly because I'm bumping up against the edge of what
> Boost.Program_Options
> >> can do. If there really is interest in an options parser for ISO C++, I
> >> might have something to present in a couple of months.
> >>
> >> However, I'm not convinced that this is the sort of library that C++
> needs
> >> (at least, not right now). I'm not entirely sure a one-size-fits-all
> >> solution for command-line parsing exists, and it would be a shame to
> >> standardize something that didn't suffice for many people.
> >>
> >> Option-parsing conventions are also tied to the OS, and ISO C++ might be
> >> the wrong place to define such a convention. POSIX systems generally
> use "-"
> >> for options, while Windows uses "/"; would ISO C++ need to pick one as
> the
> >> "blessed" prefix, or would users be required to specify which they want?
> >>
> >> Going back to the original author's argument that users don't want to
> add
> >> a Boost dependency for things, I think this is mostly tilting at
> windmills.
> >> Still, there's some merit in the idea of a "modular Boost", where you
> don't
> >> need to grab the entire project just to use the one library you want.
> That's
> >> more of a discussion for the Boost list, though.
> >
> >
> > I can't say that a command-line-parsing library is definitely a good
> idea,
> > but there's been interest in it in the past. For cross-platform options,
> > take a look at what scripting languages have done, and consider the
> > Filesystem TS's approach of having an explicit "native" option.
>
>
> And do remember that using slashes is just.. ..unwise. Even on windows.
> I don't know whether option parsing/handling is general enough to be
> standardized. I know it would be damn useful for writing cross-platform
> code especially for users to whom boost is too much of a dependency.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr">I&#39;m personally favorable on command line parsing in th=
e standard library, but I&#39;m skeptical of getoptpp&#39;s choice to use t=
he stream operators for it.<div><br></div><div>LEWG will be happy to look a=
t any papers folks write. We&#39;re likely to say &quot;yes, do more work&q=
uot; for any proposal that&#39;s not fully fleshed out, so it&#39;s probabl=
y a good idea to include specific questions we should answer in order to he=
lp direct that more work. We&#39;ll also appreciate comparisons to a wide r=
ange of existing practice, rather than just a single library.<br><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Nov 15, 2014 at 11:=
41 AM, Daniel Gutson <span dir=3D"ltr">&lt;<a href=3D"mailto:danielgutson@g=
mail.com" target=3D"_blank" class=3D"cremed">danielgutson@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">This looks like a candidat=
e Y/N EWG vote.<br>
<br>
If I could get &quot;enough&quot; people here to take a look at the library=
 I mentioned (getoptpp), I could make a quick presentation for Lenexa for s=
uch a Y/N vote to determine whether it&#39;s worth keeping forward or not. =
A full proposal without such a vote seems to me a risk of a waste of time.<=
br>
<div class=3D"HOEnZb"><div class=3D"h5">-----Original Message-----<br>
From: Ville Voutilainen &lt;<a href=3D"mailto:ville.voutilainen@gmail.com" =
class=3D"cremed">ville.voutilainen@gmail.com</a>&gt;<br>
Date: Sat, 15 Nov 2014 20:16:10<br>
To: &lt;<a href=3D"mailto:std-proposals@isocpp.org" class=3D"cremed">std-pr=
oposals@isocpp.org</a>&gt;<br>
Reply-To: <a href=3D"mailto:std-proposals@isocpp.org" class=3D"cremed">std-=
proposals@isocpp.org</a><br>
Subject: Re: [std-proposals] Re: Standard getopt and its variants<br>
<br>
On 15 November 2014 20:07, &#39;Jeffrey Yasskin&#39; via ISO C++ Standard -=
<br>
Future Proposals &lt;<a href=3D"mailto:std-proposals@isocpp.org" class=3D"c=
remed">std-proposals@isocpp.org</a>&gt; wrote:<br>
&gt; On Sat, Nov 15, 2014 at 9:47 AM, Jim Porter &lt;<a href=3D"mailto:jvp4=
846@g.rit.edu" class=3D"cremed">jvp4846@g.rit.edu</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On 11/14/2014 1:48 AM, &#39;Jeffrey Yasskin&#39; via ISO C++ Stand=
ard - Future<br>
&gt;&gt; Proposals wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Being C++, we probably wouldn&#39;t standardize the C getopt i=
nterfaces, but<br>
&gt;&gt;&gt; there&#39;s definitely some interest in command-line parsing. =
Boost<br>
&gt;&gt;&gt; libraries or other existing practice are always a good start i=
f you want<br>
&gt;&gt;&gt; to propose something.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; I&#39;ve actually been thinking about command-line parsing a lot l=
ately,<br>
&gt;&gt; mainly because I&#39;m bumping up against the edge of what Boost.P=
rogram_Options<br>
&gt;&gt; can do. If there really is interest in an options parser for ISO C=
++, I<br>
&gt;&gt; might have something to present in a couple of months.<br>
&gt;&gt;<br>
&gt;&gt; However, I&#39;m not convinced that this is the sort of library th=
at C++ needs<br>
&gt;&gt; (at least, not right now). I&#39;m not entirely sure a one-size-fi=
ts-all<br>
&gt;&gt; solution for command-line parsing exists, and it would be a shame =
to<br>
&gt;&gt; standardize something that didn&#39;t suffice for many people.<br>
&gt;&gt;<br>
&gt;&gt; Option-parsing conventions are also tied to the OS, and ISO C++ mi=
ght be<br>
&gt;&gt; the wrong place to define such a convention. POSIX systems general=
ly use &quot;-&quot;<br>
&gt;&gt; for options, while Windows uses &quot;/&quot;; would ISO C++ need =
to pick one as the<br>
&gt;&gt; &quot;blessed&quot; prefix, or would users be required to specify =
which they want?<br>
&gt;&gt;<br>
&gt;&gt; Going back to the original author&#39;s argument that users don&#3=
9;t want to add<br>
&gt;&gt; a Boost dependency for things, I think this is mostly tilting at w=
indmills.<br>
&gt;&gt; Still, there&#39;s some merit in the idea of a &quot;modular Boost=
&quot;, where you don&#39;t<br>
&gt;&gt; need to grab the entire project just to use the one library you wa=
nt. That&#39;s<br>
&gt;&gt; more of a discussion for the Boost list, though.<br>
&gt;<br>
&gt;<br>
&gt; I can&#39;t say that a command-line-parsing library is definitely a go=
od idea,<br>
&gt; but there&#39;s been interest in it in the past. For cross-platform op=
tions,<br>
&gt; take a look at what scripting languages have done, and consider the<br=
>
&gt; Filesystem TS&#39;s approach of having an explicit &quot;native&quot; =
option.<br>
<br>
<br>
And do remember that using slashes is just.. ..unwise. Even on windows.<br>
I don&#39;t know whether option parsing/handling is general enough to be<br=
>
standardized. I know it would be damn useful for writing cross-platform<br>
code especially for users to whom boost is too much of a dependency.<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" class=3D"=
cremed">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"cremed">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" class=3D"cremed">http://groups.google.com=
/a/isocpp.org/group/std-proposals/</a>.<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" class=3D"=
cremed">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"cremed">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" class=3D"cremed">http://groups.google.com=
/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--bcaec520f59f7806d20507ef99e1--

.

On 2014=E2=80=9311=E2=80=9316, at 9:15 AM, 'Jeffrey Yasskin' via ISO C++ St=
andard - Future Proposals <std-proposals@isocpp.org> wrote:

> We'll also appreciate comparisons to a wide range of existing practice, r=
ather than just a single library.

Coverage of program configuration in general would be nice. Some operating =
systems provide a persistent key-value storage facility per application, se=
parate from the file system. Then there=E2=80=99s environment variables, ba=
ked-in globals, and config files.

Several libraries exist to combine these input sources, including Boost.Pro=
gram_options as mentioned. Which sources are supported on a given platform =
may be implementation-defined, and perhaps indicated by a conditional macro=
 or such. Then the standard can avoid predicating the new functionality on =
the existence of a command line (or its particular encoding/syntax).

--=20

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

.

On 2014-11-15 12:47, Jim Porter wrote:
> However, I'm not convinced that this is the sort of library that C++
> needs (at least, not right now). I'm not entirely sure a
> one-size-fits-all solution for command-line parsing exists, and it would
> be a shame to standardize something that didn't suffice for many people.

I've worked with quite a few CLI libraries in the past, including
vul_arg (which is on the overly primitive side), boost::program_options
(which is overly complicated for most uses) and KCmdLineArgs (which is
just about on the sweet spot, except for requiring kdelibs or at least
Qt). I've also written my own which is heavily based on the KCmdLineArgs
API with a few tweaks and is pure Qt.

One thing I've found is that it's convenient in Qt applications to deal
with QString (and also to be able to be QApplication-aware). However
this is obviously impractical for applications that don't use Qt. So
that's a moderately strong point against there being a
"one-size-fits-all" library.

It's too bad we can't just use Python's argparse :-). In my experience
that's the best balance between power and simplicity that I've seen.
Unfortunately it gets some of that by Python being what it is (i.e. One
True String Class in particular; see above points re: Qt).

--
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2014-11-15 17:14, adeel.bm@gmail.com wrote:
> Nonetheless, both ['-' and '/' to indicate options] appear to have
> edge cases, when there are whitespaces in path.

You're creating an issue where none exists. It is the shell's job to
deal with argument quoting. By the time arguments land in argv, the
program should assume that each position of argv is a distinct argument,
and should never, ever try to reassemble them to account for things like
paths containing whitespace.

(Okay, some programs may do so "as a convenience", but I would call the
correctness of this dubious at best, and would *strongly* discourage any
standard library from even considering it.)

This is of course different from the case that the CLA library should
understand implicit argument splitting (e.g. {'-B1'} and {'-B', '1'}
should have the same effect for an option '-B' taking a value).

--
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 11/17/2014 12:43 PM, Matthew Woehlke wrote:
> On 2014-11-15 17:14, adeel.bm@gmail.com wrote:
>> Nonetheless, both ['-' and '/' to indicate options] appear to have
>> edge cases, when there are whitespaces in path.
>
> You're creating an issue where none exists. It is the shell's job to
> deal with argument quoting. By the time arguments land in argv, the
> program should assume that each position of argv is a distinct argument,
> and should never, ever try to reassemble them to account for things like
> paths containing whitespace.

Unfortunately, not all application entry points have an argv:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms633559%28v=vs.85%29.aspx

- Jim


--

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

.

------=_Part_1370_886953431.1416311046001
Content-Type: text/plain; charset=UTF-8


>
> This is of course different from the case that the CLA library should
> understand implicit argument splitting (e.g. {'-B1'} and {'-B', '1'}
> should have the same effect for an option '-B' taking a value).
>
> On a *nix, I would expect {'-B1'} to be equivalent to {'-B', '-1'}, not
{'-B', '1'}, but I expect other O/S or O/S families might treat such an
argument like that.  Just one more incompatibility a CLA library would have
to deal with ;)

--

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

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

<div dir=3D"ltr"><BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: =
0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class=3Dgmail_quote>This is of course=
 different from the case that the CLA library should <BR>understand implici=
t argument splitting (e.g. {'-B1'} and {'-B', '1'} <BR>should have the same=
 effect for an option '-B' taking a value). <BR><BR></BLOCKQUOTE>
<DIV>On a *nix, I would expect {'-B1'} to be equivalent to {'-B', '-1'}, no=
t {'-B', '1'}, but I expect other O/S or O/S families might treat such an a=
rgument like that.&nbsp; Just one more incompatibility a CLA library would =
have to deal with ;)</DIV></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1370_886953431.1416311046001--

.

On 2014-11-18 06:44, Douglas Boffey wrote:
>> This is of course different from the case that the CLA library should
>> understand implicit argument splitting (e.g. {'-B1'} and {'-B', '1'}
>> should have the same effect for an option '-B' taking a value).
>
> On a *nix, I would expect {'-B1'} to be equivalent to {'-B', '-1'}, not
> {'-B', '1'}, but I expect other O/S or O/S families might treat such an
> argument like that.  Just one more incompatibility a CLA library would have
> to deal with ;)

No, it doesn't work that way (see e.g. grep for an example, {'-B1'} ==
{'-B', '1'}. It actually depends on the option type of '-B'; if '-B'
takes a value, *everything* in the same argument following the 'B' flag
is considered as the value for 'B'. Otherwise as in your example,
anything following is considered as another candidate flag. (Note that
this only works with '-' options, not with '--'.)

Again, using grep as an example, {'-lRA1'} == {'-l', '-R', '-A', '1'},
because only '-A' takes a value.

This is at least the way GNU option parsing is implemented, as well as
my own library, but (without actually checking various argument parsers)
I suspect it's fairly standard, at least among parsers with any level of
sophistication.

This does mean that the parser is expected to know prior to parsing at
least *if* the flag takes a value or not (some will also know the *type*
of value, i.e. int, string, etc.). This is standard for almost any
parser. You tell it about the various permitted options *first*; it's
not just blindly trying to figure out what means what.

--
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2014-11-17 20:44, Jim Porter wrote:
> On 11/17/2014 12:43 PM, Matthew Woehlke wrote:
>> On 2014-11-15 17:14, adeel.bm@gmail.com wrote:
>>> Nonetheless, both ['-' and '/' to indicate options] appear to have
>>> edge cases, when there are whitespaces in path.
>>
>> You're creating an issue where none exists. It is the shell's job to
>> deal with argument quoting. By the time arguments land in argv, the
>> program should assume that each position of argv is a distinct argument,
>> and should never, ever try to reassemble them to account for things like
>> paths containing whitespace.
>
> Unfortunately, not all application entry points have an argv:
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms633559%28v=vs.85%29.aspx

Well, then, it should be the platform's job to make up for their
non-standard entry point. Not the C++ standard's and not the argument
parsing utilities. It's not the standard's job to address the quirks of
individual platforms through standardese; that way lies madness (among
other things).

(Related, the parser should ideally accept any iterable list of
string-like entities (char*, wide_string, etc.).)

--
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_718_1198960855.1416339265154
Content-Type: text/plain; charset=UTF-8



On Thursday, November 13, 2014 8:46:33 PM UTC-5, adee...@gmail.com wrote:
>
> Any thoughts about standardizing POSIX getopt.h and getopt.cpp (and its
> variant getoptlong) ?
>
> That would be really of high value for porting CLI applications
> cross-platform.
>

I notice that Qt has a relatively new component that might inform the
design of this:
http://qt-project.org/doc/qt-5/qcommandlineparser.html

I've not used this myself but I've been very happy with their solution of
what I think is a related issue:  program settings (*.ini, *.conf, register
depending on OS).  QSettings is a good abstraction over the Windows
register and *nix configuration files IMHO.  The only problem with
standardizing something like this is we'd want XML parsing first (for Mac
configs in this case).

--

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

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

<div dir=3D"ltr"><br><br>On Thursday, November 13, 2014 8:46:33 PM UTC-5, a=
dee...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div>Any thoughts about standardizing POSIX getopt.h and getopt.c=
pp (and its variant getoptlong) ? </div><div><br></div><div>That would be r=
eally of high value&nbsp;for porting CLI applications cross-platform.</div>=
</div></blockquote><div><br>I notice that Qt has a relatively new component=
 that might inform the design of this:<br>http://qt-project.org/doc/qt-5/qc=
ommandlineparser.html<br><br>I've not used this myself but I've been very h=
appy with their solution of what I think is a related issue:&nbsp; program =
settings (*.ini, *.conf, register depending on OS).&nbsp; QSettings is a go=
od abstraction over the Windows register and *nix configuration files IMHO.=
&nbsp; The only problem with standardizing something like this is we'd want=
 XML parsing first (for Mac configs in this case).<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_718_1198960855.1416339265154--

.

On 2014=E2=80=9311=E2=80=9319, at 3:34 AM, 3dw4rd@verizon.net wrote:

> I notice that Qt has a relatively new component that might inform the des=
ign of this:
> http://qt-project.org/doc/qt-5/qcommandlineparser.html
>=20
> I've not used this myself but I've been very happy with their solution of=
 what I think is a related issue:  program settings (*.ini, *.conf, registe=
r depending on OS).  QSettings is a good abstraction over the Windows regis=
ter and *nix configuration files IMHO.  The only problem with standardizing=
 something like this is we'd want XML parsing first (for Mac configs in thi=
s case).

Mac/iOS configs are handled by the OS.

As I mentioned earlier, Boost.Program_options is another point of reference=
..

A key-value settings access library would be more useful than a parser.

--=20

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

.