------=_Part_192_28588983.1393931910273
Content-Type: text/plain; charset=UTF-8

Proposal: http://htmlpreview.github.io/?https://github.com/sftrabbit/ModernMain/blob/c84c1d4d87d9e4733d92a13096ed4350e1461782/proposal.htm
Source: https://github.com/sftrabbit/ModernMain

I've drafted up some thoughts I had on introducing a form of main that
takes program arguments as a std::vector<std::string>. For example:

#include <string>
#include <vector>
#include <iostream>

int main(std::vector<std::string> args)
{
for (const auto& arg : args) {
std::cout << arg << "\n";
}
}

As far as I can tell, it seems like a viable proposal that would be
welcomed by many (but may also be a little controversial). My main concerns
are with the approach to exception handling, but I don't think it's a
particularly bad way of doing it. Please take a look at the Open Questions
section.

This is my first attempt at writing a proposal draft, so let me know of any
rookie mistakes I'm making. I also do not admittedly have much of a
detailed understanding of compiler implementations, so I don't know if
there's something about this that makes it completely infeasible.

Thanks,
Joseph Mansfield

--

---
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_192_28588983.1393931910273
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Proposal:&nbsp;http://htmlpreview.github.io/?https://=
github.com/sftrabbit/ModernMain/blob/c84c1d4d87d9e4733d92a13096ed4350e14617=
82/proposal.htm</div><div>Source:&nbsp;https://github.com/sftrabbit/ModernM=
ain</div><div><br></div>I've drafted up some thoughts I had on introducing =
a form of <font face=3D"courier new, monospace">main</font><font face=3D"ar=
ial, sans-serif">&nbsp;that takes program arguments as a </font><font face=
=3D"courier new, monospace">std::vector&lt;std::string&gt;</font><font face=
=3D"arial, sans-serif">. For example:</font><div><font face=3D"arial, sans-=
serif"><br></font></div><div><div><font face=3D"courier new, monospace">#in=
clude &lt;string&gt;</font></div><div><font face=3D"courier new, monospace"=
>#include &lt;vector&gt;</font></div><div><font face=3D"courier new, monosp=
ace">#include &lt;iostream&gt;</font></div><div><font face=3D"courier new, =
monospace"><br></font></div><div><font face=3D"courier new, monospace">int =
main(std::vector&lt;std::string&gt; args)</font></div><div><font face=3D"co=
urier new, monospace">{</font></div><div><font face=3D"courier new, monospa=
ce"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>for (c=
onst auto&amp; arg : args) {</font></div><div><font face=3D"courier new, mo=
nospace"><span class=3D"Apple-tab-span" style=3D"white-space:pre">  </span>=
std::cout &lt;&lt; arg &lt;&lt; "\n";</font></div><div><font face=3D"courie=
r new, monospace"><span class=3D"Apple-tab-span" style=3D"white-space:pre">=
 </span>}</font></div><div><font face=3D"courier new, monospace">}</font></=
div><div><font face=3D"arial, sans-serif"><br></font></div><div><font face=
=3D"arial, sans-serif">As far as I can tell, it seems like a viable proposa=
l that would be welcomed by many (but may also be a little controversial). =
My main concerns are with the approach to exception handling, but I don't t=
hink it's a particularly bad way of doing it. Please take a look at the Ope=
n Questions section.</font></div><div><span style=3D"font-family: arial, sa=
ns-serif;"><br></span></div><div><span style=3D"font-family: arial, sans-se=
rif;">This is my first attempt at writing a proposal draft, so let me know =
of any rookie mistakes I'm making.&nbsp;I also do not admittedly have much =
of a detailed understanding of compiler implementations, so I don't know if=
 there's something about this that makes it completely infeasible.</span></=
div></div><div><span style=3D"font-family: arial, sans-serif;"><br></span><=
/div><div><span style=3D"font-family: arial, sans-serif;">Thanks,</span></d=
iv><div><span style=3D"font-family: arial, sans-serif;">Joseph Mansfield</s=
pan></div></div>

<p></p>

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

------=_Part_192_28588983.1393931910273--

.

On 4 March 2014 13:18, Joseph Mansfield <sftrabbit@gmail.com> wrote:
> As far as I can tell, it seems like a viable proposal that would be welcomed
> by many (but may also be a little controversial). My main concerns are with
> the approach to exception handling, but I don't think it's a particularly
> bad way of doing it. Please take a look at the Open Questions section.


I think I would prefer not handling the exceptions raised in the construction
of the arguments of main. Modifying the function-try-block rules just for main
seems like a very bad bang/buck ratio trade-off to me.

Another question that comes to mind is whether this approach is really what
we want - if argument parsing is important, shouldn't we have a standardized
getopt-library? What is the current state-of-the-art of those?

Another question is whether we need this once we have array_view.  See
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3851.pdf
If I can easily put on array_view on top of argv, I have significantly decreased
the need to have argv as a vector<string>. That of course makes me think
whether instead of vector<string>, it should be array_view<string_view>
instead?

--

---
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/.

.

--Apple-Mail=_E1EEC913-17BA-4D36-B9D7-7A03676C84F5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1

A less ambitious form I have been hoping to see would be:

int main(std::initializer_list<const char *> args)
{
 for (const auto& arg : args) {
  std::cout << arg << "\n";
 }
}

This seems to be a more typical C++11/14 rendering of the variable number o=
r arguments
passed on the command line today.

Need to find the time to see if I can hack up Clang or gcc well enough to m=
ake this work,
I believe it should simply be an alternate representation of the existing d=
ata structure.

AlisdairM


On Mar 4, 2014, at 6:18 AM, Joseph Mansfield <sftrabbit@gmail.com> wrote:

> Proposal: http://htmlpreview.github.io/?https://github.com/sftrabbit/Mode=
rnMain/blob/c84c1d4d87d9e4733d92a13096ed4350e1461782/proposal.htm
> Source: https://github.com/sftrabbit/ModernMain
>=20
> I've drafted up some thoughts I had on introducing a form of main that ta=
kes program arguments as a std::vector<std::string>. For example:
>=20
> #include <string>
> #include <vector>
> #include <iostream>
>=20
> int main(std::vector<std::string> args)
> {
>  for (const auto& arg : args) {
>   std::cout << arg << "\n";
>  }
> }
>=20
> As far as I can tell, it seems like a viable proposal that would be welco=
med by many (but may also be a little controversial). My main concerns are =
with the approach to exception handling, but I don't think it's a particula=
rly bad way of doing it. Please take a look at the Open Questions section.
>=20
> This is my first attempt at writing a proposal draft, so let me know of a=
ny rookie mistakes I'm making. I also do not admittedly have much of a deta=
iled understanding of compiler implementations, so I don't know if there's =
something about this that makes it completely infeasible.
>=20
> Thanks,
> Joseph Mansfield
>=20
> --=20
> =20
> ---=20
> You received this message because you are subscribed to the Google Groups=
 "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to std-proposals+unsubscribe@isocpp.org.
> 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-propo=
sals/.

--=20

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

--Apple-Mail=_E1EEC913-17BA-4D36-B9D7-7A03676C84F5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dus-ascii"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode=
: space; -webkit-line-break: after-white-space; ">A less ambitious form I h=
ave been hoping to see would be:<div><br></div><div><div><font face=3D"cour=
ier new, monospace">int main(std::initializer_list&lt;const char *&gt; args=
)</font></div><div><font face=3D"courier new, monospace">{</font></div><div=
><font face=3D"courier new, monospace"><span class=3D"Apple-tab-span" style=
=3D"white-space: pre; "> </span>for (const auto&amp; arg : args) {</font></=
div><div><font face=3D"courier new, monospace"><span class=3D"Apple-tab-spa=
n" style=3D"white-space: pre; ">  </span>std::cout &lt;&lt; arg &lt;&lt; "\=
n";</font></div><div><font face=3D"courier new, monospace"><span class=3D"A=
pple-tab-span" style=3D"white-space: pre; "> </span>}</font></div><div><fon=
t face=3D"courier new, monospace">}</font></div><div><font face=3D"courier =
new, monospace"><br></font></div><div>This seems to be a more typical C++11=
/14 rendering of the variable number or arguments</div><div>passed on the c=
ommand line today.</div><div><br></div><div>Need to find the time to see if=
 I can hack up Clang or gcc well enough to make this work,</div><div>I beli=
eve it should simply be an alternate representation of the existing data st=
ructure.</div><div><br></div><div>AlisdairM</div><div><div><br></div><div><=
br></div><div>On Mar 4, 2014, at 6:18 AM, Joseph Mansfield &lt;<a href=3D"m=
ailto:sftrabbit@gmail.com">sftrabbit@gmail.com</a>&gt; wrote:</div><br clas=
s=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">=
<div>Proposal:&nbsp;<a href=3D"http://htmlpreview.github.io/?https://github=
..com/sftrabbit/ModernMain/blob/c84c1d4d87d9e4733d92a13096ed4350e1461782/pro=
posal.htm">http://htmlpreview.github.io/?https://github.com/sftrabbit/Moder=
nMain/blob/c84c1d4d87d9e4733d92a13096ed4350e1461782/proposal.htm</a></div><=
div>Source:&nbsp;<a href=3D"https://github.com/sftrabbit/ModernMain">https:=
//github.com/sftrabbit/ModernMain</a></div><div><br></div>I've drafted up s=
ome thoughts I had on introducing a form of <font face=3D"courier new, mono=
space">main</font><font face=3D"arial, sans-serif">&nbsp;that takes program=
 arguments as a </font><font face=3D"courier new, monospace">std::vector&lt=
;std::string&gt;</font><font face=3D"arial, sans-serif">. For example:</fon=
t><div><font face=3D"arial, sans-serif"><br></font></div><div><div><font fa=
ce=3D"courier new, monospace">#include &lt;string&gt;</font></div><div><fon=
t face=3D"courier new, monospace">#include &lt;vector&gt;</font></div><div>=
<font face=3D"courier new, monospace">#include &lt;iostream&gt;</font></div=
><div><font face=3D"courier new, monospace"><br></font></div><div><font fac=
e=3D"courier new, monospace">int main(std::vector&lt;std::string&gt; args)<=
/font></div><div><font face=3D"courier new, monospace">{</font></div><div><=
font face=3D"courier new, monospace"><span class=3D"Apple-tab-span" style=
=3D"white-space:pre"> </span>for (const auto&amp; arg : args) {</font></div=
><div><font face=3D"courier new, monospace"><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">  </span>std::cout &lt;&lt; arg &lt;&lt; "\n";</f=
ont></div><div><font face=3D"courier new, monospace"><span class=3D"Apple-t=
ab-span" style=3D"white-space:pre"> </span>}</font></div><div><font face=3D=
"courier new, monospace">}</font></div><div><font face=3D"arial, sans-serif=
"><br></font></div><div><font face=3D"arial, sans-serif">As far as I can te=
ll, it seems like a viable proposal that would be welcomed by many (but may=
 also be a little controversial). My main concerns are with the approach to=
 exception handling, but I don't think it's a particularly bad way of doing=
 it. Please take a look at the Open Questions section.</font></div><div><sp=
an style=3D"font-family: arial, sans-serif;"><br></span></div><div><span st=
yle=3D"font-family: arial, sans-serif;">This is my first attempt at writing=
 a proposal draft, so let me know of any rookie mistakes I'm making.&nbsp;I=
 also do not admittedly have much of a detailed understanding of compiler i=
mplementations, so I don't know if there's something about this that makes =
it completely infeasible.</span></div></div><div><span style=3D"font-family=
: arial, sans-serif;"><br></span></div><div><span style=3D"font-family: ari=
al, sans-serif;">Thanks,</span></div><div><span style=3D"font-family: arial=
, sans-serif;">Joseph Mansfield</span></div></div><div><br class=3D"webkit-=
block-placeholder"></div>

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

--Apple-Mail=_E1EEC913-17BA-4D36-B9D7-7A03676C84F5--

.

------=_Part_3947_31584423.1393933399836
Content-Type: text/plain; charset=UTF-8

Sure, it's possible to provide no way to catch those exceptions, and let
them propagate and terminate the program. After all, is there even a
reasonable way in which that exception could be handled?

I like your suggestion of array_view<string_view> a lot. I think it makes
much more sense (we do not care about the underlying type) and would even
avoid the exception handling problem. It would also make this feature
easier to implement.

On Tuesday, 4 March 2014 11:33:55 UTC, Ville Voutilainen wrote:
>
> On 4 March 2014 13:18, Joseph Mansfield <sftr...@gmail.com <javascript:>>
> wrote:
> > As far as I can tell, it seems like a viable proposal that would be
> welcomed
> > by many (but may also be a little controversial). My main concerns are
> with
> > the approach to exception handling, but I don't think it's a
> particularly
> > bad way of doing it. Please take a look at the Open Questions section.
>
>
> I think I would prefer not handling the exceptions raised in the
> construction
> of the arguments of main. Modifying the function-try-block rules just for
> main
> seems like a very bad bang/buck ratio trade-off to me.
>
> Another question that comes to mind is whether this approach is really
> what
> we want - if argument parsing is important, shouldn't we have a
> standardized
> getopt-library? What is the current state-of-the-art of those?
>
> Another question is whether we need this once we have array_view.  See
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3851.pdf
> If I can easily put on array_view on top of argv, I have significantly
> decreased
> the need to have argv as a vector<string>. That of course makes me think
> whether instead of vector<string>, it should be array_view<string_view>
> instead?
>

--

---
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_3947_31584423.1393933399836
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Sure, it's possible to provide no way to catch those excep=
tions, and let them propagate and terminate the program. After all, is ther=
e even a reasonable way in which that exception could be handled?<div><br><=
/div><div>I like your suggestion of <font face=3D"courier new, monospace">a=
rray_view&lt;string_view&gt;</font> a lot. I think it makes much more sense=
 (we do not care about the underlying type) and would even avoid the except=
ion handling problem. It would also make this feature easier to implement.<=
/div><div><br>On Tuesday, 4 March 2014 11:33:55 UTC, Ville Voutilainen  wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">On 4 March 2014 13:18, Jose=
ph Mansfield &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"5Nt6hrsaQ6sJ" onmousedown=3D"this.href=3D'javascript:';return true=
;" onclick=3D"this.href=3D'javascript:';return true;">sftr...@gmail.com</a>=
&gt; wrote:
<br>&gt; As far as I can tell, it seems like a viable proposal that would b=
e welcomed
<br>&gt; by many (but may also be a little controversial). My main concerns=
 are with
<br>&gt; the approach to exception handling, but I don't think it's a parti=
cularly
<br>&gt; bad way of doing it. Please take a look at the Open Questions sect=
ion.
<br>
<br>
<br>I think I would prefer not handling the exceptions raised in the constr=
uction
<br>of the arguments of main. Modifying the function-try-block rules just f=
or main
<br>seems like a very bad bang/buck ratio trade-off to me.
<br>
<br>Another question that comes to mind is whether this approach is really =
what
<br>we want - if argument parsing is important, shouldn't we have a standar=
dized
<br>getopt-library? What is the current state-of-the-art of those?
<br>
<br>Another question is whether we need this once we have array_view. &nbsp=
;See
<br><a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3851.pd=
f" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?=
q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2014%2=
Fn3851.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNGr4Y4sO6yk5uaGv5VzhBKavrsAHQ'=
;return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3=
A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2014%2Fn3851.pdf=
\46sa\75D\46sntz\0751\46usg\75AFQjCNGr4Y4sO6yk5uaGv5VzhBKavrsAHQ';return tr=
ue;">http://open-std.org/JTC1/SC22/<wbr>WG21/docs/papers/2014/n3851.<wbr>pd=
f</a>
<br>If I can easily put on array_view on top of argv, I have significantly =
decreased
<br>the need to have argv as a vector&lt;string&gt;. That of course makes m=
e think
<br>whether instead of vector&lt;string&gt;, it should be array_view&lt;str=
ing_view&gt;
<br>instead?
<br></blockquote></div></div>

<p></p>

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

------=_Part_3947_31584423.1393933399836--

.

2014-03-04 12:33 GMT+01:00 Ville Voutilainen <ville.voutilainen@gmail.com>:
> That of course makes me think
> whether instead of vector<string>, it should be array_view<string_view>
> instead?

Yes, I had the same reaction to this. Sounds very appealing to me and
wouldn't introduce problems related to exceptions. Alternative
candidates with similar advantage could be

std::initializer_list<std::string_view>

It should be noted that in both cases it would be invalid to modify
the contents of these arrays. C and C++ allow content modifications
and several libraries and even specifications (e.g. C++ CORBA mapping)
take advantage of this freedom.

Following Alisdair's revised suggestion the fully backward compatible
way would be a signature using

std::initializer_list<char*>

instead. This would also allow to modify the individual contents of list.

- Daniel

--

---
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 4 March 2014 13:45, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrote:
> 2014-03-04 12:33 GMT+01:00 Ville Voutilainen <ville.voutilainen@gmail.com=
>:
>> That of course makes me think
>> whether instead of vector<string>, it should be array_view<string_view>
>> instead?
>
> Yes, I had the same reaction to this. Sounds very appealing to me and
> wouldn't introduce problems related to exceptions. Alternative
> candidates with similar advantage could be
>
> std::initializer_list<std::string_view>
>
> It should be noted that in both cases it would be invalid to modify
> the contents of these arrays. C and C++ allow content modifications
> and several libraries and even specifications (e.g. C++ CORBA mapping)
> take advantage of this freedom.

Hmm, so does the argument handling in eg. QApplication, it removes the
arguments that Qt recognizes.

>
> Following Alisdair's revised suggestion the fully backward compatible
> way would be a signature using
> std::initializer_list<char*>
> instead. This would also allow to modify the individual contents of list.


Sure, but as mentioned, things like QApplication modify the argument array,=
 too,
by modifying argc.

We seem to be finding arguments for the case of vector<string>. ;)

--=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/.

.

My principle reason to start with 'initializer_list<char *>' is that it avo=
id entangling
the language and library any further.  Currently, the compiler is not expec=
ted to
understand either 'vector', nor 'string', not 'basic_string<CharT, TraitsT,=
 AllocatorT>',
not how to combine them.

It is required to turn sequences of identifiers into an initializer_list, s=
o that boat
already sailed.  Likewise, 'char *' is a built in type that the compiler kn=
ows about.

The 'initializer_list' should also fairly trivially map to the existing dat=
a structures,
but that is just a bonus.  My real concern is that I do not want to see 've=
ctor',
'basic_string' nor any typedefs thereof crossing the library -> compiler bo=
undary.

You will note, for example, that none of the 'exception'-derived classes th=
at the
language might throw have a constructor taking a 'std::string', and that is=
 quite
intentional.  Likewise, most library-mandated exceptions are derived from e=
ither
rutime_error or logic_error, which do take 'std::string' arguments.

AlisdairM

On Mar 4, 2014, at 6:49 AM, Ville Voutilainen <ville.voutilainen@gmail.com>=
 wrote:

> On 4 March 2014 13:45, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrote=
:
>> 2014-03-04 12:33 GMT+01:00 Ville Voutilainen <ville.voutilainen@gmail.co=
m>:
>>> That of course makes me think
>>> whether instead of vector<string>, it should be array_view<string_view>
>>> instead?
>>=20
>> Yes, I had the same reaction to this. Sounds very appealing to me and
>> wouldn't introduce problems related to exceptions. Alternative
>> candidates with similar advantage could be
>>=20
>> std::initializer_list<std::string_view>
>>=20
>> It should be noted that in both cases it would be invalid to modify
>> the contents of these arrays. C and C++ allow content modifications
>> and several libraries and even specifications (e.g. C++ CORBA mapping)
>> take advantage of this freedom.
>=20
> Hmm, so does the argument handling in eg. QApplication, it removes the
> arguments that Qt recognizes.
>=20
>>=20
>> Following Alisdair's revised suggestion the fully backward compatible
>> way would be a signature using
>> std::initializer_list<char*>
>> instead. This would also allow to modify the individual contents of list=
..
>=20
>=20
> Sure, but as mentioned, things like QApplication modify the argument arra=
y, too,
> by modifying argc.
>=20
> We seem to be finding arguments for the case of vector<string>. ;)
>=20
> --=20
>=20
> ---=20
> You received this message because you are subscribed to the Google Groups=
 "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to std-proposals+unsubscribe@isocpp.org.
> 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-propo=
sals/.

--=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/.

.

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

Regardless of any solution, this proposal should perhaps be discussed in co=
nsideration of the fact that the main direct beneficiary of such an additio=
n to the standard is getopts - level functionality.

Ville Voutillainen is right in his original assessment. First of all, shoul=
d this issue of modifying the main signature be treated as a separate one f=
rom getopts? I think not.



"Daniel Kr=C3=BCgler" <daniel.kruegler@gmail.com> wrote:
>2014-03-04 12:33 GMT+01:00 Ville Voutilainen
><ville.voutilainen@gmail.com>:
>> That of course makes me think
>> whether instead of vector<string>, it should be
>array_view<string_view>
>> instead?
>
>Yes, I had the same reaction to this. Sounds very appealing to me and
>wouldn't introduce problems related to exceptions. Alternative
>candidates with similar advantage could be
>
>std::initializer_list<std::string_view>
>
>It should be noted that in both cases it would be invalid to modify
>the contents of these arrays. C and C++ allow content modifications
>and several libraries and even specifications (e.g. C++ CORBA mapping)
>take advantage of this freedom.
>
>Following Alisdair's revised suggestion the fully backward compatible
>way would be a signature using
>
>std::initializer_list<char*>
>
>instead. This would also allow to modify the individual contents of
>list.
>
>- Daniel
>
>--=20
>
>---=20
>You received this message because you are subscribed to the Google
>Groups "ISO C++ Standard - Future Proposals" group.
>To unsubscribe from this group and stop receiving emails from it, send
>an email to std-proposals+unsubscribe@isocpp.org.
>To post to this group, send email to std-proposals@isocpp.org.
>Visit this group at
>http://groups.google.com/a/isocpp.org/group/std-proposals/.

--=20

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

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

<html><head></head><body><p dir=3D"ltr">Regardless of any solution, this pr=
oposal should perhaps be discussed in consideration of the fact that the ma=
in direct beneficiary of such an addition to the standard is getopts - leve=
l functionality.</p>
<p dir=3D"ltr">Ville Voutillainen is right in his original assessment. Firs=
t of all, should this issue of modifying the main signature be treated as a=
 separate one from getopts? I think not.</p>
<br><br><div class=3D"gmail_quote">&quot;Daniel Kr=C3=BCgler&quot; &lt;dani=
el.kruegler@gmail.com&gt; wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); paddi=
ng-left: 1ex;">
<pre class=3D"k9mail">2014-03-04 12:33 GMT+01:00 Ville Voutilainen &lt;vill=
e.voutilainen@gmail.com&gt;:<br /><blockquote class=3D"gmail_quote" style=
=3D"margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left=
: 1ex;"> That of course makes me think<br /> whether instead of vector&lt;s=
tring&gt;, it should be array_view&lt;string_view&gt;<br /> instead?<br /><=
/blockquote><br />Yes, I had the same reaction to this. Sounds very appeali=
ng to me and<br />wouldn't introduce problems related to exceptions. Altern=
ative<br />candidates with similar advantage could be<br /><br />std::initi=
alizer_list&lt;std::string_view&gt;<br /><br />It should be noted that in b=
oth cases it would be invalid to modify<br />the contents of these arrays. =
C and C++ allow content modifications<br />and several libraries and even s=
pecifications (e.g. C++ CORBA mapping)<br />take advantage of this freedom.=
<br /><br />Following Alisdair's revised suggestion the fully backward comp=
atible<br />way would be a
signature using<br /><br />std::initializer_list&lt;char*&gt;<br /><br />in=
stead. This would also allow to modify the individual contents of list.<br =
/><br />- Daniel<br /></pre></blockquote></div></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 />

------KHM8R6D23NG5T9KUTVBSA0NS6L5VZP--


.

On 4 March 2014 13:55, Alisdair Meredith <alisdairm@me.com> wrote:
> My principle reason to start with 'initializer_list<char *>' is that it avoid entangling
> the language and library any further.  Currently, the compiler is not expected to
> understand either 'vector', nor 'string', not 'basic_string<CharT, TraitsT, AllocatorT>',
> not how to combine them.
>
> It is required to turn sequences of identifiers into an initializer_list, so that boat
> already sailed.  Likewise, 'char *' is a built in type that the compiler knows about.
>
> The 'initializer_list' should also fairly trivially map to the existing data structures,
> but that is just a bonus.  My real concern is that I do not want to see 'vector',
> 'basic_string' nor any typedefs thereof crossing the library -> compiler boundary.
>
> You will note, for example, that none of the 'exception'-derived classes that the
> language might throw have a constructor taking a 'std::string', and that is quite
> intentional.  Likewise, most library-mandated exceptions are derived from either
> rutime_error or logic_error, which do take 'std::string' arguments.

Regardless of which types we choose, we have existing practice that modifies
the bag of arguments. initializer_list doesn't allow for that, unless
of course the
user has to know to copy it into a container before attempting modifications.
That more or less takes us back to the square one.

I also don't think a bag of char* is much of a step forward.

Implementations are already allowed to support a main signature that would
provide eg. vector<string>. I guess we could start by implementing
such solutions
and convincing a vendor to include such an extension.

--

---
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/.

.

Initializer_list means that you cannot change the pointer values, but you can certainly
change the contents of what is pointed to, if that is desired.

Also, vector<string> has a constructor that will concert from an initializer_list<char *>,
making it very simple for users to build that representation if that is what they choose,
but without putting the burden and unspecified complexity into every compiler.  I am
very resistant to making compilers more intimate with complex library types, I am
very welcoming of proposals to make the command line interface more usable.

AlisdairM

On Mar 4, 2014, at 7:05 AM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

> On 4 March 2014 13:55, Alisdair Meredith <alisdairm@me.com> wrote:
>> My principle reason to start with 'initializer_list<char *>' is that it avoid entangling
>> the language and library any further.  Currently, the compiler is not expected to
>> understand either 'vector', nor 'string', not 'basic_string<CharT, TraitsT, AllocatorT>',
>> not how to combine them.
>>
>> It is required to turn sequences of identifiers into an initializer_list, so that boat
>> already sailed.  Likewise, 'char *' is a built in type that the compiler knows about.
>>
>> The 'initializer_list' should also fairly trivially map to the existing data structures,
>> but that is just a bonus.  My real concern is that I do not want to see 'vector',
>> 'basic_string' nor any typedefs thereof crossing the library -> compiler boundary.
>>
>> You will note, for example, that none of the 'exception'-derived classes that the
>> language might throw have a constructor taking a 'std::string', and that is quite
>> intentional.  Likewise, most library-mandated exceptions are derived from either
>> rutime_error or logic_error, which do take 'std::string' arguments.
>
> Regardless of which types we choose, we have existing practice that modifies
> the bag of arguments. initializer_list doesn't allow for that, unless
> of course the
> user has to know to copy it into a container before attempting modifications.
> That more or less takes us back to the square one.
>
> I also don't think a bag of char* is much of a step forward.
>
> Implementations are already allowed to support a main signature that would
> provide eg. vector<string>. I guess we could start by implementing
> such solutions
> and convincing a vendor to include such an extension.
>
> --
>
> ---
> 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/.

.

Correction - vector does NOT have a constructor that will treat 'initalizer_list<char *>'
the same as 'initializer_list<string>' when contracting a 'vector<string>'.  I am not sure
if that is something the L(E)WG should be separately investigating.

AlisdairM

On Mar 4, 2014, at 7:05 AM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

> On 4 March 2014 13:55, Alisdair Meredith <alisdairm@me.com> wrote:
>> My principle reason to start with 'initializer_list<char *>' is that it avoid entangling
>> the language and library any further.  Currently, the compiler is not expected to
>> understand either 'vector', nor 'string', not 'basic_string<CharT, TraitsT, AllocatorT>',
>> not how to combine them.
>>
>> It is required to turn sequences of identifiers into an initializer_list, so that boat
>> already sailed.  Likewise, 'char *' is a built in type that the compiler knows about.
>>
>> The 'initializer_list' should also fairly trivially map to the existing data structures,
>> but that is just a bonus.  My real concern is that I do not want to see 'vector',
>> 'basic_string' nor any typedefs thereof crossing the library -> compiler boundary.
>>
>> You will note, for example, that none of the 'exception'-derived classes that the
>> language might throw have a constructor taking a 'std::string', and that is quite
>> intentional.  Likewise, most library-mandated exceptions are derived from either
>> rutime_error or logic_error, which do take 'std::string' arguments.
>
> Regardless of which types we choose, we have existing practice that modifies
> the bag of arguments. initializer_list doesn't allow for that, unless
> of course the
> user has to know to copy it into a container before attempting modifications.
> That more or less takes us back to the square one.
>
> I also don't think a bag of char* is much of a step forward.
>
> Implementations are already allowed to support a main signature that would
> provide eg. vector<string>. I guess we could start by implementing
> such solutions
> and convincing a vendor to include such an extension.
>
> --
>
> ---
> 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/.

.

2014-03-04 12:49 GMT+01:00 Ville Voutilainen <ville.voutilainen@gmail.com>:
>> Following Alisdair's revised suggestion the fully backward compatible
>> way would be a signature using
>> std::initializer_list<char*>
>> instead. This would also allow to modify the individual contents of list.
>
>
> Sure, but as mentioned, things like QApplication modify the argument array, too,
> by modifying argc.

This seems not to be a real problem, because QApplication et. al can
take std::initializer_list<char*> and return a array_view<char*> for
example, which contains the modified list.

- Daniel

--

---
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 4 March 2014 14:09, Alisdair Meredith <alisdairm@me.com> wrote:
> Initializer_list means that you cannot change the pointer values, but you can certainly
> change the contents of what is pointed to, if that is desired.

That doesn't help. The existing code modifies the argv+argc
combination by modifying
the argc part. I can't shrink an initializer_list.

--

---
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 4 March 2014 14:17, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrote:
>> Sure, but as mentioned, things like QApplication modify the argument arr=
ay, too,
>> by modifying argc.
> This seems not to be a real problem, because QApplication et. al can
> take std::initializer_list<char*> and return a array_view<char*> for
> example, which contains the modified list.


Well, if we go down that path and require such semantic modifying of
things that are out there in the wild, why is Corba's argv+argc
handling an issue?
How popular do we expect this initializer_list<char*> (or any alternative o=
f it)
to be, if it requires changing boatloads of existing code? With such
considerations
in mind, the case for standardizing such a signature seems to become
rather weak.

--=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/.

.

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

Is it completely necessary for all forms of main to be compatible? If some
libraries require the existing forms because they do some manipulation of
the argv pointers and argc, that's fine - those forms can be used. It's the
library's concern if it only provides such an interface. If using the new
form of main while the libraries continue to only have this interface, the
new args parameter may be converted to an appropriate form to pass to the
library.


On 4 March 2014 12:17, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrote:

> 2014-03-04 12:49 GMT+01:00 Ville Voutilainen <ville.voutilainen@gmail.com
> >:
> >> Following Alisdair's revised suggestion the fully backward compatible
> >> way would be a signature using
> >> std::initializer_list<char*>
> >> instead. This would also allow to modify the individual contents of
> list.
> >
> >
> > Sure, but as mentioned, things like QApplication modify the argument
> array, too,
> > by modifying argc.
>
> This seems not to be a real problem, because QApplication et. al can
> take std::initializer_list<char*> and return a array_view<char*> for
> example, which contains the modified list.
>
> - Daniel
>
> --
>
> ---
> 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/FMAAdCVGiZU/=
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/.
>

--=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/.

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

<div dir=3D"ltr">Is it completely necessary for all forms of main to be com=
patible? If some libraries require the existing forms because they do some =
manipulation of the argv pointers and argc, that&#39;s fine - those forms c=
an be used. It&#39;s the library&#39;s concern if it only provides such an =
interface. If using the new form of main while the libraries continue to on=
ly have this interface, the new args parameter may be converted to an appro=
priate form to pass to the library.<div class=3D"gmail_extra">

<br><br><div class=3D"gmail_quote">On 4 March 2014 12:17, Daniel Kr=FCgler =
<span dir=3D"ltr">&lt;<a href=3D"mailto:daniel.kruegler@gmail.com" target=
=3D"_blank">daniel.kruegler@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">

2014-03-04 12:49 GMT+01:00 Ville Voutilainen &lt;<a href=3D"mailto:ville.vo=
utilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt;:<br>
<div class=3D"">&gt;&gt; Following Alisdair&#39;s revised suggestion the fu=
lly backward compatible<br>
&gt;&gt; way would be a signature using<br>
&gt;&gt; std::initializer_list&lt;char*&gt;<br>
&gt;&gt; instead. This would also allow to modify the individual contents o=
f list.<br>
&gt;<br>
&gt;<br>
&gt; Sure, but as mentioned, things like QApplication modify the argument a=
rray, too,<br>
&gt; by modifying argc.<br>
<br>
</div>This seems not to be a real problem, because QApplication et. al can<=
br>
take std::initializer_list&lt;char*&gt; and return a array_view&lt;char*&gt=
; for<br>
example, which contains the modified list.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
- Daniel<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/FMAAdCVGiZU/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/FMAAdCVGiZU=
/unsubscribe</a>.<br>


To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
<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 />

--047d7b15a4b7d13cea04f3c70edb--

.

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

It wouldn't require changing boatloads of existing code because the
existing forms of main will continue to suffice. One day, the libraries may
adapt to the changes and provide a more general interface.


On 4 March 2014 12:22, Ville Voutilainen <ville.voutilainen@gmail.com>wrote=
:

> On 4 March 2014 14:17, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrote=
:
> >> Sure, but as mentioned, things like QApplication modify the argument
> array, too,
> >> by modifying argc.
> > This seems not to be a real problem, because QApplication et. al can
> > take std::initializer_list<char*> and return a array_view<char*> for
> > example, which contains the modified list.
>
>
> Well, if we go down that path and require such semantic modifying of
> things that are out there in the wild, why is Corba's argv+argc
> handling an issue?
> How popular do we expect this initializer_list<char*> (or any alternative
> of it)
> to be, if it requires changing boatloads of existing code? With such
> considerations
> in mind, the case for standardizing such a signature seems to become
> rather weak.
>
> --
>
> ---
> 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/FMAAdCVGiZU/=
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/.
>

--=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/.

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

<div dir=3D"ltr">It wouldn&#39;t require changing boatloads of existing cod=
e because the existing forms of main will continue to suffice. One day, the=
 libraries may adapt to the changes and provide a more general interface.</=
div>

<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 4 March 20=
14 12:22, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D"mailto:ville.v=
outilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.com</a>&gt;=
</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 4 March 2014 14:17, Danie=
l Kr=FCgler &lt;<a href=3D"mailto:daniel.kruegler@gmail.com">daniel.kruegle=
r@gmail.com</a>&gt; wrote:<br>


&gt;&gt; Sure, but as mentioned, things like QApplication modify the argume=
nt array, too,<br>
&gt;&gt; by modifying argc.<br>
&gt; This seems not to be a real problem, because QApplication et. al can<b=
r>
&gt; take std::initializer_list&lt;char*&gt; and return a array_view&lt;cha=
r*&gt; for<br>
&gt; example, which contains the modified list.<br>
<br>
<br>
</div>Well, if we go down that path and require such semantic modifying of<=
br>
things that are out there in the wild, why is Corba&#39;s argv+argc<br>
handling an issue?<br>
How popular do we expect this initializer_list&lt;char*&gt; (or any alterna=
tive of it)<br>
to be, if it requires changing boatloads of existing code? With such<br>
considerations<br>
in mind, the case for standardizing such a signature seems to become<br>
rather weak.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/FMAAdCVGiZU/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/FMAAdCVGiZU=
/unsubscribe</a>.<br>


To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<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 />

--047d7bd90ede8208de04f3c715dd--

.

On 4 March 2014 14:31, Joseph Mansfield <sftrabbit@gmail.com> wrote:
> It wouldn't require changing boatloads of existing code because the existing
> forms of main will continue to suffice. One day, the libraries may adapt to
> the changes and provide a more general interface.


Sure. The question is philosophical. :) Why add these signatures if they are
going to be adopted by a small crowd of people? I have at least one answer -
adding such signatures would make the language easier for non-experts.
This takes us back to the earlier points - if we want to cater for non-experts,
we sure as hell should not have char* in the mix.

--

---
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/.

.

--047d7ba983ce02007304f3c741f8
Content-Type: text/plain; charset=ISO-8859-1

This is why I still like the idea of array_view<string_view>, despite the
tangling with the standard library and incompatibility with existing
definitions. I think this would actually be widely adopted and could become
the new default way to define main. Newcomers would only need to learn
about the other forms if they start working with a library that takes argcand
argv, and even then it might become common practice to use the new form and
convert to that form. Either way, some people are going to have to convert
one way or the other. I feel like it makes sense to modernise it now and
get it over with.

Maybe I'm too optimistic!


On 4 March 2014 12:35, Ville Voutilainen <ville.voutilainen@gmail.com>wrote:

> On 4 March 2014 14:31, Joseph Mansfield <sftrabbit@gmail.com> wrote:
> > It wouldn't require changing boatloads of existing code because the
> existing
> > forms of main will continue to suffice. One day, the libraries may adapt
> to
> > the changes and provide a more general interface.
>
>
> Sure. The question is philosophical. :) Why add these signatures if they
> are
> going to be adopted by a small crowd of people? I have at least one answer
> -
> adding such signatures would make the language easier for non-experts.
> This takes us back to the earlier points - if we want to cater for
> non-experts,
> we sure as hell should not have char* in the mix.
>
> --
>
> ---
> 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/FMAAdCVGiZU/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/.
>

--

---
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/.

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

<div dir=3D"ltr">This is why I still like the idea of <font face=3D"courier=
 new, monospace">array_view&lt;string_view&gt;</font>, despite the tangling=
 with the standard library and incompatibility with existing definitions. I=
 think this would actually be widely adopted and could become the new defau=
lt way to define <font face=3D"courier new, monospace">main</font>. Newcome=
rs would only need to learn about the other forms if they start working wit=
h a library that takes <font face=3D"courier new, monospace">argc</font> an=
d <font face=3D"courier new, monospace">argv</font><font face=3D"arial, hel=
vetica, sans-serif">, and even then it might become common practice to use =
the new form and convert to that form. Either way, some people are going to=
 have to convert one way or the other. I feel like it makes sense to modern=
ise it now and get it over with.</font><div>

<font face=3D"arial, helvetica, sans-serif"><br></font></div><div><font fac=
e=3D"arial, helvetica, sans-serif">Maybe I&#39;m too optimistic!</font></di=
v></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 4 =
March 2014 12:35, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D"mailto=
:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.com=
</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 4 March 2014 14:31, Josep=
h Mansfield &lt;<a href=3D"mailto:sftrabbit@gmail.com">sftrabbit@gmail.com<=
/a>&gt; wrote:<br>


&gt; It wouldn&#39;t require changing boatloads of existing code because th=
e existing<br>
&gt; forms of main will continue to suffice. One day, the libraries may ada=
pt to<br>
&gt; the changes and provide a more general interface.<br>
<br>
<br>
</div>Sure. The question is philosophical. :) Why add these signatures if t=
hey are<br>
going to be adopted by a small crowd of people? I have at least one answer =
-<br>
adding such signatures would make the language easier for non-experts.<br>
This takes us back to the earlier points - if we want to cater for non-expe=
rts,<br>
we sure as hell should not have char* in the mix.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/FMAAdCVGiZU/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/FMAAdCVGiZU=
/unsubscribe</a>.<br>


To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<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 />

--047d7ba983ce02007304f3c741f8--

.

--Apple-Mail-8BC3D524-A1F5-4D38-A5F3-51BE1AA87C4D
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

And that is why I favor 'initializer_list<char *>' ;)

There are a wife range of types that would be interesting to support, with
Various ways of spelling 'array' and 'string' and then combining the two.

The standard 'argv' formulation is arcane and strange to most developers
Who learned C++ in the lady decade of so, without coming through C first.
'initializer_list' and 'char *' are fundamental parts of our vocabulary, an=
d
the vast majority of the interesting other types should be convertible from
an 'initializer_list<char *>' while the other inter operation stories will =
be very
much on a case-by-case basis.

When seeking a widely-used vocabulary type, pick the simplest type possible
that meets the needs.  Generally folks with more demanding needs will accep=
t
wrapping the primitive type with their facility, but the more complex that =
type
becomes, the stronger the desire to have an independent feature instead.

'initializer_list' was specifically created to act as vocabulary in such ci=
rcumstances.
I will concede that 'char *' is less appealing to modern audiences, but the=
 vast majority
of string-like things already know how to construct from one.

Sent from my iPad

> On 4 Mar 2014, at 07:43, Joseph Mansfield <sftrabbit@gmail.com> wrote:
>=20
> This is why I still like the idea of array_view<string_view>, despite the=
 tangling with the standard library and incompatibility with existing defin=
itions. I think this would actually be widely adopted and could become the =
new default way to define main. Newcomers would only need to learn about th=
e other forms if they start working with a library that takes argc and argv=
, and even then it might become common practice to use the new form and con=
vert to that form. Either way, some people are going to have to convert one=
 way or the other. I feel like it makes sense to modernise it now and get i=
t over with.
>=20
> Maybe I'm too optimistic!
>=20
>=20
>> On 4 March 2014 12:35, Ville Voutilainen <ville.voutilainen@gmail.com> w=
rote:
>> On 4 March 2014 14:31, Joseph Mansfield <sftrabbit@gmail.com> wrote:
>> > It wouldn't require changing boatloads of existing code because the ex=
isting
>> > forms of main will continue to suffice. One day, the libraries may ada=
pt to
>> > the changes and provide a more general interface.
>>=20
>>=20
>> Sure. The question is philosophical. :) Why add these signatures if they=
 are
>> going to be adopted by a small crowd of people? I have at least one answ=
er -
>> adding such signatures would make the language easier for non-experts.
>> This takes us back to the earlier points - if we want to cater for non-e=
xperts,
>> we sure as hell should not have char* in the mix.
>>=20
>> --
>>=20
>> ---
>> You received this message because you are subscribed to a topic in the G=
oogle Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit https://groups.google.com/a/isocpp=
..org/d/topic/std-proposals/FMAAdCVGiZU/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-prop=
osals/.
>=20
> --=20
>=20
> ---=20
> You received this message because you are subscribed to the Google Groups=
 "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to std-proposals+unsubscribe@isocpp.org.
> 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-propo=
sals/.

--=20

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

--Apple-Mail-8BC3D524-A1F5-4D38-A5F3-51BE1AA87C4D
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div>And that is why I favor 'initializ=
er_list&lt;char *&gt;' ;)</div><div><br></div><div>There are a wife range o=
f types that would be interesting to support, with</div><div>Various ways o=
f spelling 'array' and 'string' and then combining the two.</div><div><br><=
/div><div>The standard 'argv' formulation is arcane and strange to most dev=
elopers</div><div>Who learned C++ in the lady decade of so, without coming =
through C first.</div><div>'initializer_list' and 'char *' are fundamental =
parts of our vocabulary, and</div><div>the vast majority of the interesting=
 other types should be convertible from</div><div>an 'initializer_list&lt;c=
har *&gt;' while the other inter operation stories will be very</div><div>m=
uch on a case-by-case basis.</div><div><br></div><div>When seeking a widely=
-used vocabulary type, pick the simplest type possible</div><div>that meets=
 the needs. &nbsp;Generally  folks with more demanding needs will accept</d=
iv><div>wrapping the primitive type with their facility, but the more compl=
ex that type</div><div>becomes, the stronger the desire to have an independ=
ent feature instead.</div><div><br></div><div>'initializer_list' was specif=
ically created to act as vocabulary in such circumstances.</div><div>I will=
 concede that 'char *' is less appealing to modern audiences, but the vast =
majority</div><div>of string-like things already know how to construct from=
 one.</div><div><br>Sent from my iPad</div><div><br>On 4 Mar 2014, at 07:43=
, Joseph Mansfield &lt;<a href=3D"mailto:sftrabbit@gmail.com">sftrabbit@gma=
il.com</a>&gt; wrote:<br><br></div><blockquote type=3D"cite"><div><div dir=
=3D"ltr">This is why I still like the idea of <font face=3D"courier new, mo=
nospace">array_view&lt;string_view&gt;</font>, despite the tangling with th=
e standard library and incompatibility with existing definitions. I think t=
his would actually be widely adopted and could become the new default way t=
o define <font face=3D"courier new, monospace">main</font>. Newcomers would=
 only need to learn about the other forms if they start working with a libr=
ary that takes <font face=3D"courier new, monospace">argc</font> and <font =
face=3D"courier new, monospace">argv</font><font face=3D"arial, helvetica, =
sans-serif">, and even then it might become common practice to use the new =
form and convert to that form. Either way, some people are going to have to=
 convert one way or the other. I feel like it makes sense to modernise it n=
ow and get it over with.</font><div>

<font face=3D"arial, helvetica, sans-serif"><br></font></div><div><font fac=
e=3D"arial, helvetica, sans-serif">Maybe I'm too optimistic!</font></div></=
div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 4 Marc=
h 2014 12:35, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D"mailto:vil=
le.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.com</a>=
&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 4 March 2014 14:31, Josep=
h Mansfield &lt;<a href=3D"mailto:sftrabbit@gmail.com">sftrabbit@gmail.com<=
/a>&gt; wrote:<br>


&gt; It wouldn't require changing boatloads of existing code because the ex=
isting<br>
&gt; forms of main will continue to suffice. One day, the libraries may ada=
pt to<br>
&gt; the changes and provide a more general interface.<br>
<br>
<br>
</div>Sure. The question is philosophical. :) Why add these signatures if t=
hey are<br>
going to be adopted by a small crowd of people? I have at least one answer =
-<br>
adding such signatures would make the language easier for non-experts.<br>
This takes us back to the earlier points - if we want to cater for non-expe=
rts,<br>
we sure as hell should not have char* in the mix.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/FMAAdCVGiZU/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/FMAAdCVGiZU=
/unsubscribe</a>.<br>


To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--Apple-Mail-8BC3D524-A1F5-4D38-A5F3-51BE1AA87C4D--

.

--047d7bd90ede6aea7804f3c79d0d
Content-Type: text/plain; charset=ISO-8859-1

What are your concerns about initializer_list<string_view>? Then we have
the appropriate vocabulary (string_view will be fundamental one day), a
modern approach to strings, and no issues with exceptions. The only
downside I see (other than incompatibility, which I'm abandoning for now)
is the language-library tangling - perhaps a necessary evil.


On 4 March 2014 12:52, Alisdair Meredith <alisdairm@me.com> wrote:

> And that is why I favor 'initializer_list<char *>' ;)
>
> There are a wife range of types that would be interesting to support, with
> Various ways of spelling 'array' and 'string' and then combining the two.
>
> The standard 'argv' formulation is arcane and strange to most developers
> Who learned C++ in the lady decade of so, without coming through C first.
> 'initializer_list' and 'char *' are fundamental parts of our vocabulary,
> and
> the vast majority of the interesting other types should be convertible from
> an 'initializer_list<char *>' while the other inter operation stories will
> be very
> much on a case-by-case basis.
>
> When seeking a widely-used vocabulary type, pick the simplest type possible
> that meets the needs.  Generally folks with more demanding needs will
> accept
> wrapping the primitive type with their facility, but the more complex that
> type
> becomes, the stronger the desire to have an independent feature instead.
>
> 'initializer_list' was specifically created to act as vocabulary in such
> circumstances.
> I will concede that 'char *' is less appealing to modern audiences, but
> the vast majority
> of string-like things already know how to construct from one.
>
> Sent from my iPad
>
> On 4 Mar 2014, at 07:43, Joseph Mansfield <sftrabbit@gmail.com> wrote:
>
> This is why I still like the idea of array_view<string_view>, despite the
> tangling with the standard library and incompatibility with existing
> definitions. I think this would actually be widely adopted and could become
> the new default way to define main. Newcomers would only need to learn
> about the other forms if they start working with a library that takes argcand
> argv, and even then it might become common practice to use the new form
> and convert to that form. Either way, some people are going to have to
> convert one way or the other. I feel like it makes sense to modernise it
> now and get it over with.
>
> Maybe I'm too optimistic!
>
>
> On 4 March 2014 12:35, Ville Voutilainen <ville.voutilainen@gmail.com>wrote:
>
>> On 4 March 2014 14:31, Joseph Mansfield <sftrabbit@gmail.com> wrote:
>> > It wouldn't require changing boatloads of existing code because the
>> existing
>> > forms of main will continue to suffice. One day, the libraries may
>> adapt to
>> > the changes and provide a more general interface.
>>
>>
>> Sure. The question is philosophical. :) Why add these signatures if they
>> are
>> going to be adopted by a small crowd of people? I have at least one
>> answer -
>> adding such signatures would make the language easier for non-experts.
>> This takes us back to the earlier points - if we want to cater for
>> non-experts,
>> we sure as hell should not have char* in the mix.
>>
>> --
>>
>> ---
>> 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/FMAAdCVGiZU/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/.
>>
>
>  --
>
> ---
> 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 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/FMAAdCVGiZU/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/.
>

--

---
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/.

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

<div dir=3D"ltr">What are your concerns about <font face=3D"courier new, mo=
nospace">initializer_list&lt;string_view&gt;</font><font face=3D"arial, hel=
vetica, sans-serif">? Then we have the appropriate vocabulary (</font><font=
 face=3D"courier new, monospace">string_view</font><font face=3D"arial, hel=
vetica, sans-serif"> will be fundamental one day), a modern approach to str=
ings, and no issues with exceptions. The only downside I see (other than in=
compatibility, which I&#39;m abandoning for now) is the language-library ta=
ngling - perhaps a necessary evil.</font></div>

<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 4 March 20=
14 12:52, Alisdair Meredith <span dir=3D"ltr">&lt;<a href=3D"mailto:alisdai=
rm@me.com" target=3D"_blank">alisdairm@me.com</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">

<div dir=3D"auto"><div>And that is why I favor &#39;initializer_list&lt;cha=
r *&gt;&#39; ;)</div><div><br></div><div>There are a wife range of types th=
at would be interesting to support, with</div><div>Various ways of spelling=
 &#39;array&#39; and &#39;string&#39; and then combining the two.</div>

<div><br></div><div>The standard &#39;argv&#39; formulation is arcane and s=
trange to most developers</div><div>Who learned C++ in the lady decade of s=
o, without coming through C first.</div><div>&#39;initializer_list&#39; and=
 &#39;char *&#39; are fundamental parts of our vocabulary, and</div>

<div>the vast majority of the interesting other types should be convertible=
 from</div><div>an &#39;initializer_list&lt;char *&gt;&#39; while the other=
 inter operation stories will be very</div><div>much on a case-by-case basi=
s.</div>

<div><br></div><div>When seeking a widely-used vocabulary type, pick the si=
mplest type possible</div><div>that meets the needs. =A0Generally  folks wi=
th more demanding needs will accept</div><div>wrapping the primitive type w=
ith their facility, but the more complex that type</div>

<div>becomes, the stronger the desire to have an independent feature instea=
d.</div><div><br></div><div>&#39;initializer_list&#39; was specifically cre=
ated to act as vocabulary in such circumstances.</div><div>I will concede t=
hat &#39;char *&#39; is less appealing to modern audiences, but the vast ma=
jority</div>

<div>of string-like things already know how to construct from one.</div><di=
v><br>Sent from my iPad</div><div><div class=3D"h5"><div><br>On 4 Mar 2014,=
 at 07:43, Joseph Mansfield &lt;<a href=3D"mailto:sftrabbit@gmail.com" targ=
et=3D"_blank">sftrabbit@gmail.com</a>&gt; wrote:<br>

<br></div></div></div><blockquote type=3D"cite"><div><div><div class=3D"h5"=
><div dir=3D"ltr">This is why I still like the idea of <font face=3D"courie=
r new, monospace">array_view&lt;string_view&gt;</font>, despite the tanglin=
g with the standard library and incompatibility with existing definitions. =
I think this would actually be widely adopted and could become the new defa=
ult way to define <font face=3D"courier new, monospace">main</font>. Newcom=
ers would only need to learn about the other forms if they start working wi=
th a library that takes <font face=3D"courier new, monospace">argc</font> a=
nd <font face=3D"courier new, monospace">argv</font><font face=3D"arial, he=
lvetica, sans-serif">, and even then it might become common practice to use=
 the new form and convert to that form. Either way, some people are going t=
o have to convert one way or the other. I feel like it makes sense to moder=
nise it now and get it over with.</font><div>



<font face=3D"arial, helvetica, sans-serif"><br></font></div><div><font fac=
e=3D"arial, helvetica, sans-serif">Maybe I&#39;m too optimistic!</font></di=
v></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 4 =
March 2014 12:35, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D"mailto=
:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.com=
</a>&gt;</span> wrote:<br>



<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On 4 March 2014 14:31, Joseph Mansfield=
 &lt;<a href=3D"mailto:sftrabbit@gmail.com" target=3D"_blank">sftrabbit@gma=
il.com</a>&gt; wrote:<br>




&gt; It wouldn&#39;t require changing boatloads of existing code because th=
e existing<br>
&gt; forms of main will continue to suffice. One day, the libraries may ada=
pt to<br>
&gt; the changes and provide a more general interface.<br>
<br>
<br>
</div>Sure. The question is philosophical. :) Why add these signatures if t=
hey are<br>
going to be adopted by a small crowd of people? I have at least one answer =
-<br>
adding such signatures would make the language easier for non-experts.<br>
This takes us back to the earlier points - if we want to cater for non-expe=
rts,<br>
we sure as hell should not have char* in the mix.<br>
<div><div><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/FMAAdCVGiZU/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/FMAAdCVGiZU=
/unsubscribe</a>.<br>




To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/FMAAdCVGiZU/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/FMAAdCVGiZU=
/unsubscribe</a>.<br>


To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<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 />

--047d7bd90ede6aea7804f3c79d0d--

.

On 4 March 2014 15:09, Joseph Mansfield <sftrabbit@gmail.com> wrote:
> What are your concerns about initializer_list<string_view>? Then we have the
> appropriate vocabulary (string_view will be fundamental one day), a modern
> approach to strings, and no issues with exceptions. The only downside I see
> (other than incompatibility, which I'm abandoning for now) is the
> language-library tangling - perhaps a necessary evil.


For what it's worth, char* is not a part of my vocabulary. It's an
arcane legacy type
the traces of which I eradicate wherever I go. Having this supposedly-modern
signature of main use it is not a step forward, as I said, it's a step nowhere.

--

---
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_1777_18100710.1393942963982
Content-Type: text/plain; charset=UTF-8

The best for beginners (and for our eyes) would be to support the following
syntax:

int main(auto args)
{
   for (x : args)
      std::cout << x << "\n";
}

Of course, the type of args would be either array_view<string_view>,
initializer_list<string_view> or initializer_list<char*>. But it takes at
least an intermediate user to understand what an
array_view/string_view/initializer_list is.

On Tuesday, March 4, 2014 8:24:14 AM UTC-5, Ville Voutilainen wrote:

> On 4 March 2014 15:09, Joseph Mansfield <sftr...@gmail.com <javascript:>>
> wrote:
> > What are your concerns about initializer_list<string_view>? Then we have
> the
> > appropriate vocabulary (string_view will be fundamental one day), a
> modern
> > approach to strings, and no issues with exceptions. The only downside I
> see
> > (other than incompatibility, which I'm abandoning for now) is the
> > language-library tangling - perhaps a necessary evil.
>
>
> For what it's worth, char* is not a part of my vocabulary. It's an
> arcane legacy type
> the traces of which I eradicate wherever I go. Having this
> supposedly-modern
> signature of main use it is not a step forward, as I said, it's a step
> nowhere.
>

--

---
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_1777_18100710.1393942963982
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>The best for beginners (and for our eyes) would be to=
 support the following syntax:</div><div>&nbsp;</div><div><font face=3D"cou=
rier new,monospace">int main(auto args)</font></div><div><font face=3D"cour=
ier new,monospace">{</font></div><div><font face=3D"courier new,monospace">=
&nbsp;&nbsp; for (x : args)</font><div><font face=3D"courier new,monospace"=
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; std::cout &lt;&lt;&nbsp;x &lt;&lt; "\n";</f=
ont></div></div><div><font face=3D"courier new,monospace">}</font></div><di=
v>&nbsp;</div><div>Of course, the type of args would be either array_view&l=
t;string_view&gt;, initializer_list&lt;string_view&gt; or initializer_list&=
lt;char*&gt;. But it takes at least an intermediate user to understand what=
 an array_view/string_view/initializer_list is.</div><div><br>On Tuesday, M=
arch 4, 2014 8:24:14 AM UTC-5, Ville Voutilainen wrote:</div><blockquote st=
yle=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;" class=
=3D"gmail_quote">On 4 March 2014 15:09, Joseph Mansfield &lt;<a onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascr=
ipt:';return true;" href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"2UxHbFS3nG0J">sftr...@gmail.com</a>&gt; wrote:
<br>&gt; What are your concerns about initializer_list&lt;string_view&gt;? =
Then we have the
<br>&gt; appropriate vocabulary (string_view will be fundamental one day), =
a modern
<br>&gt; approach to strings, and no issues with exceptions. The only downs=
ide I see
<br>&gt; (other than incompatibility, which I'm abandoning for now) is the
<br>&gt; language-library tangling - perhaps a necessary evil.
<br>
<br>
<br>For what it's worth, char* is not a part of my vocabulary. It's an
<br>arcane legacy type
<br>the traces of which I eradicate wherever I go. Having this supposedly-m=
odern
<br>signature of main use it is not a step forward, as I said, it's a step =
nowhere.
<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_1777_18100710.1393942963982--

.

--bcaec529992939907304f3c8ef42
Content-Type: text/plain; charset=ISO-8859-1

Am 04.03.2014 15:22 schrieb "Alex B" <devalexb@gmail.com>:
>
> The best for beginners (and for our eyes) would be to support the
following syntax:
>
> int main(auto args)
> {
>    for (x : args)
>       std::cout << x << "\n";
> }
>
> Of course, the type of args would be either array_view<string_view>,
initializer_list<string_view> or initializer_list<char*>. But it takes at
least an intermediate user to understand what an
array_view/string_view/initializer_list is.
>

I disagree. People would need to know what concept the type passed to main
needs to model (and recursively, of the possible element type of the
iterable thing of args). It doesn't free the user of reading documentation.

I would argue that it takes more to understand that than to understand
either initializer list or array view and stringview.

--

---
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/.

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

<p dir=3D"ltr"><br>
Am 04.03.2014 15:22 schrieb &quot;Alex B&quot; &lt;<a href=3D"mailto:devale=
xb@gmail.com">devalexb@gmail.com</a>&gt;:<br>
&gt;<br>
&gt; The best for beginners (and for our eyes) would be to support the foll=
owing syntax:<br>
&gt; =A0<br>
&gt; int main(auto args)<br>
&gt; {<br>
&gt; =A0=A0 for (x : args)<br>
&gt; =A0=A0=A0=A0=A0 std::cout &lt;&lt;=A0x &lt;&lt; &quot;\n&quot;;<br>
&gt; }<br>
&gt; =A0<br>
&gt; Of course, the type of args would be either array_view&lt;string_view&=
gt;, initializer_list&lt;string_view&gt; or initializer_list&lt;char*&gt;. =
But it takes at least an intermediate user to understand what an array_view=
/string_view/initializer_list is.<br>

&gt;</p>
<p dir=3D"ltr">I disagree. People would need to know what concept the type =
passed to main needs to model (and recursively, of the possible element typ=
e of the iterable thing of args). It doesn&#39;t free the user of reading d=
ocumentation.</p>

<p dir=3D"ltr">I would argue that it takes more to understand that than to =
understand either initializer list or array view and stringview.<br>
</p>

<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 />

--bcaec529992939907304f3c8ef42--

.

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

In view of the reasons discussed in
http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm I think you
refer you should refer to this as "auto&&" if you want to safeguard the
interest of novices and range semantics. Understanding these reasons means
that they are not really novice anymore. Regardless, modifying the
signature of main is just asking for the sake of string parsing seems like
an overkill to me.


On Tue, Mar 4, 2014 at 4:22 PM, Alex B <devalexb@gmail.com> wrote:

> The best for beginners (and for our eyes) would be to support the
> following syntax:
>
> int main(auto args)
> {
>    for (x : args)
>       std::cout << x << "\n";
> }
>
> Of course, the type of args would be either array_view<string_view>,
> initializer_list<string_view> or initializer_list<char*>. But it takes at
> least an intermediate user to understand what an
> array_view/string_view/initializer_list is.
>
> On Tuesday, March 4, 2014 8:24:14 AM UTC-5, Ville Voutilainen wrote:
>
>> On 4 March 2014 15:09, Joseph Mansfield <sftr...@gmail.com> wrote:
>> > What are your concerns about initializer_list<string_view>? Then we
>> have the
>> > appropriate vocabulary (string_view will be fundamental one day), a
>> modern
>> > approach to strings, and no issues with exceptions. The only downside I
>> see
>> > (other than incompatibility, which I'm abandoning for now) is the
>> > language-library tangling - perhaps a necessary evil.
>>
>>
>> For what it's worth, char* is not a part of my vocabulary. It's an
>> arcane legacy type
>> the traces of which I eradicate wherever I go. Having this
>> supposedly-modern
>> signature of main use it is not a step forward, as I said, it's a step
>> nowhere.
>>
>  --
>
> ---
> 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/.

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

<div dir=3D"ltr">In view of the reasons discussed in <a href=3D"http://open=
-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm">http://open-std.org/jtc=
1/sc22/wg21/docs/papers/2014/n3853.htm</a> I think you refer you should ref=
er to this as &quot;auto&amp;&amp;&quot; if you want to safeguard the inter=
est of novices and range semantics. Understanding these reasons means that =
they are not really novice anymore. Regardless, modifying the signature of =
main is just asking for the sake of string parsing seems like an overkill t=
o me.<br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue,=
 Mar 4, 2014 at 4:22 PM, Alex B <span dir=3D"ltr">&lt;<a href=3D"mailto:dev=
alexb@gmail.com" target=3D"_blank">devalexb@gmail.com</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>The best for beginners (and for our eyes) would be to=
 support the following syntax:</div><div>=C2=A0</div><div><font face=3D"cou=
rier new,monospace">int main(auto args)</font></div><div><font face=3D"cour=
ier new,monospace">{</font></div>
<div><font face=3D"courier new,monospace">=C2=A0=C2=A0 for (x : args)</font=
><div><font face=3D"courier new,monospace">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 s=
td::cout &lt;&lt;=C2=A0x &lt;&lt; &quot;\n&quot;;</font></div></div><div><f=
ont face=3D"courier new,monospace">}</font></div>
<div>=C2=A0</div><div>Of course, the type of args would be either array_vie=
w&lt;string_view&gt;, initializer_list&lt;string_view&gt; or initializer_li=
st&lt;char*&gt;. But it takes at least an intermediate user to understand w=
hat an array_view/string_view/initializer_list is.</div>
<div><br>On Tuesday, March 4, 2014 8:24:14 AM UTC-5, Ville Voutilainen wrot=
e:</div><div><div class=3D"h5"><blockquote style=3D"margin:0px 0px 0px 0.8e=
x;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px=
;border-left-style:solid" class=3D"gmail_quote">
On 4 March 2014 15:09, Joseph Mansfield &lt;<a>sftr...@gmail.com</a>&gt; wr=
ote:
<br>&gt; What are your concerns about initializer_list&lt;string_view&gt;? =
Then we have the
<br>&gt; appropriate vocabulary (string_view will be fundamental one day), =
a modern
<br>&gt; approach to strings, and no issues with exceptions. The only downs=
ide I see
<br>&gt; (other than incompatibility, which I&#39;m abandoning for now) is =
the
<br>&gt; language-library tangling - perhaps a necessary evil.
<br>
<br>
<br>For what it&#39;s worth, char* is not a part of my vocabulary. It&#39;s=
 an
<br>arcane legacy type
<br>the traces of which I eradicate wherever I go. Having this supposedly-m=
odern
<br>signature of main use it is not a step forward, as I said, it&#39;s a s=
tep nowhere.
<br></blockquote></div></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<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">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a113a9ab689877204f3c8f3a1--

.

--Apple-Mail=_46F7C6E9-50D4-4D2E-97A4-4AE13DDBD039
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On Mar 4, 2014, at 9:24 PM, Ville Voutilainen <ville.voutilainen@gmail.com>=
 wrote:

> On 4 March 2014 15:09, Joseph Mansfield <sftrabbit@gmail.com> wrote:
>> What are your concerns about initializer_list<string_view>? Then we have=
 the
>> appropriate vocabulary (string_view will be fundamental one day), a mode=
rn
>> approach to strings, and no issues with exceptions. The only downside I =
see
>> (other than incompatibility, which I'm abandoning for now) is the
>> language-library tangling - perhaps a necessary evil.
>=20
>=20
> For what it's worth, char* is not a part of my vocabulary. It's an
> arcane legacy type
> the traces of which I eradicate wherever I go. Having this supposedly-mod=
ern
> signature of main use it is not a step forward, as I said, it's a step no=
where.

Already the compiler must differentiate between the signatures main() and m=
ain(char**,int), and push parameters accordingly. How hard can it be to syn=
thesize a call to something else, using the data structure provided to the =
latter signature? It's futile to try to eliminate the argv data structure, =
since it may be part of the initial process memory image. So let's focus on=
 copying its content to something more convenient.

std::initializer_list<char*> can be generated from (argv,argc) using just a=
 couple instructions on any architecture. Say we want to go from that to st=
d::vector<std::string>.

std::vector<std::string> has an implicit conversion from std::initializer_l=
ist<std::string> . And std::string has an implicit conversion from char *. =
If we pretend that we have a braced-init-list, not a fully-formed std::init=
ializer_list, then semantics work out. To reverse the translation process o=
f char *, we can make believe that they are string literals.

So, why not allow main to have any single parameter that can be initialized=
 by a braced-init-list of string literals? Pretend the command line is past=
ed into the source code. If we go so far as to allow aggregate initializati=
on, this works out wonderfully for small programs that otherwise would spen=
d disproportionate effort on parsing. The implementation can print a canned=
 message if the number of arguments does not provide a well-formed list-ini=
tialization.

--=20

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

--Apple-Mail=_46F7C6E9-50D4-4D2E-97A4-4AE13DDBD039
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Mar 4=
, 2014, at 9:24 PM, Ville Voutilainen &lt;<a href=3D"mailto:ville.voutilain=
en@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:</div><br class=3D"=
Apple-interchange-newline"><blockquote type=3D"cite">On 4 March 2014 15:09,=
 Joseph Mansfield &lt;<a href=3D"mailto:sftrabbit@gmail.com">sftrabbit@gmai=
l.com</a>&gt; wrote:<br><blockquote type=3D"cite">What are your concerns ab=
out initializer_list&lt;string_view&gt;? Then we have the<br>appropriate vo=
cabulary (string_view will be fundamental one day), a modern<br>approach to=
 strings, and no issues with exceptions. The only downside I see<br>(other =
than incompatibility, which I'm abandoning for now) is the<br>language-libr=
ary tangling - perhaps a necessary evil.<br></blockquote><br><br>For what i=
t's worth, char* is not a part of my vocabulary. It's an<br>arcane legacy t=
ype<br>the traces of which I eradicate wherever I go. Having this supposedl=
y-modern<br>signature of main use it is not a step forward, as I said, it's=
 a step nowhere.<br></blockquote><div><br></div><div>Already the compiler m=
ust differentiate between the signatures <font face=3D"Courier">main()</fon=
t> and <font face=3D"Courier">main(char**,int)</font>, and push parameters =
accordingly. How hard can it be to synthesize a call to something else, usi=
ng the data structure provided to the latter signature? It&rsquo;s futile t=
o try to eliminate the <font face=3D"Courier">argv</font> data structure, s=
ince it may be part of the initial process memory image. So let&rsquo;s foc=
us on copying its content to something more convenient.</div><div><br></div=
><div><font face=3D"Courier">std::initializer_list&lt;char*&gt;</font> can =
be generated from (<font face=3D"Courier">argv</font>,<font face=3D"Courier=
">argc</font>) using just a couple instructions on any architecture. Say we=
 want to go from that to <font face=3D"Courier">std::vector&lt;std::string&=
gt;</font>.</div><div><br></div><div><font face=3D"Courier">std::vector&lt;=
std::string&gt;</font> has an implicit conversion from&nbsp;<font face=3D"C=
ourier">std::initializer_list&lt;std::string&gt;</font>&nbsp;. And <font fa=
ce=3D"Courier">std::string</font> has an implicit conversion from <font fac=
e=3D"Courier">char *</font>. If we pretend that we have a <i>braced-init-li=
st</i>, not a fully-formed&nbsp;<font face=3D"Courier">std::initializer_lis=
t</font>, then semantics work out. To reverse the translation process of <f=
ont face=3D"Courier">char *</font>, we can make believe that they are strin=
g literals.</div><div><br></div><div>So, why not allow <font face=3D"Courie=
r">main</font> to have any single parameter that can be initialized by a <i=
>braced-init-list</i> of string literals? Pretend the command line is paste=
d into the source code. If we go so far as to allow aggregate initializatio=
n, this works out wonderfully for small programs that otherwise would spend=
 disproportionate effort on parsing. The implementation can print a canned =
message if the number of arguments does not provide a well-formed list-init=
ialization.</div><div><br></div></div></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 />

--Apple-Mail=_46F7C6E9-50D4-4D2E-97A4-4AE13DDBD039--

.

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

In addition, I see no reason why instead of modifying the signature of
main, a library extension in the spirit of Boost.Program_options should not
be proposed instead (
http://www.boost.org/doc/libs/1_55_0/doc/html/program_options.html).


On Tue, Mar 4, 2014 at 4:45 PM, George Makrydakis <irrequietus@gmail.com>wrote:

> In view of the reasons discussed in
> http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm I think you
> refer you should refer to this as "auto&&" if you want to safeguard the
> interest of novices and range semantics. Understanding these reasons means
> that they are not really novice anymore. Regardless, modifying the
> signature of main is just asking for the sake of string parsing seems like
> an overkill to me.
>
>
> On Tue, Mar 4, 2014 at 4:22 PM, Alex B <devalexb@gmail.com> wrote:
>
>> The best for beginners (and for our eyes) would be to support the
>> following syntax:
>>
>> int main(auto args)
>> {
>>    for (x : args)
>>       std::cout << x << "\n";
>> }
>>
>> Of course, the type of args would be either array_view<string_view>,
>> initializer_list<string_view> or initializer_list<char*>. But it takes at
>> least an intermediate user to understand what an
>> array_view/string_view/initializer_list is.
>>
>> On Tuesday, March 4, 2014 8:24:14 AM UTC-5, Ville Voutilainen wrote:
>>
>>> On 4 March 2014 15:09, Joseph Mansfield <sftr...@gmail.com> wrote:
>>> > What are your concerns about initializer_list<string_view>? Then we
>>> have the
>>> > appropriate vocabulary (string_view will be fundamental one day), a
>>> modern
>>> > approach to strings, and no issues with exceptions. The only downside
>>> I see
>>> > (other than incompatibility, which I'm abandoning for now) is the
>>> > language-library tangling - perhaps a necessary evil.
>>>
>>>
>>> For what it's worth, char* is not a part of my vocabulary. It's an
>>> arcane legacy type
>>> the traces of which I eradicate wherever I go. Having this
>>> supposedly-modern
>>> signature of main use it is not a step forward, as I said, it's a step
>>> nowhere.
>>>
>>  --
>>
>> ---
>> 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/.

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

<div dir=3D"ltr">In addition, I see no reason why instead of modifying the =
signature of main, a library extension in the spirit of Boost.Program_optio=
ns should not be proposed instead (<a href=3D"http://www.boost.org/doc/libs=
/1_55_0/doc/html/program_options.htm">http://www.boost.org/doc/libs/1_55_0/=
doc/html/program_options.htm</a>l).<br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue,=
 Mar 4, 2014 at 4:45 PM, George Makrydakis <span dir=3D"ltr">&lt;<a href=3D=
"mailto:irrequietus@gmail.com" target=3D"_blank">irrequietus@gmail.com</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">In view of the reasons disc=
ussed in <a href=3D"http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n38=
53.htm" target=3D"_blank">http://open-std.org/jtc1/sc22/wg21/docs/papers/20=
14/n3853.htm</a> I think you refer you should refer to this as &quot;auto&a=
mp;&amp;&quot; if you want to safeguard the interest of novices and range s=
emantics. Understanding these reasons means that they are not really novice=
 anymore. Regardless, modifying the signature of main is just asking for th=
e sake of string parsing seems like an overkill to me.<br>

</div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><b=
r><br><div class=3D"gmail_quote">On Tue, Mar 4, 2014 at 4:22 PM, Alex B <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:devalexb@gmail.com" target=3D"_blank">=
devalexb@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>The best for beginners (and for our eyes) would be to=
 support the following syntax:</div><div>=C2=A0</div><div><font face=3D"cou=
rier new,monospace">int main(auto args)</font></div><div><font face=3D"cour=
ier new,monospace">{</font></div>

<div><font face=3D"courier new,monospace">=C2=A0=C2=A0 for (x : args)</font=
><div><font face=3D"courier new,monospace">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 s=
td::cout &lt;&lt;=C2=A0x &lt;&lt; &quot;\n&quot;;</font></div></div><div><f=
ont face=3D"courier new,monospace">}</font></div>

<div>=C2=A0</div><div>Of course, the type of args would be either array_vie=
w&lt;string_view&gt;, initializer_list&lt;string_view&gt; or initializer_li=
st&lt;char*&gt;. But it takes at least an intermediate user to understand w=
hat an array_view/string_view/initializer_list is.</div>

<div><br>On Tuesday, March 4, 2014 8:24:14 AM UTC-5, Ville Voutilainen wrot=
e:</div><div><div><blockquote 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" class=3D"gmail_quote">

On 4 March 2014 15:09, Joseph Mansfield &lt;<a>sftr...@gmail.com</a>&gt; wr=
ote:
<br>&gt; What are your concerns about initializer_list&lt;string_view&gt;? =
Then we have the
<br>&gt; appropriate vocabulary (string_view will be fundamental one day), =
a modern
<br>&gt; approach to strings, and no issues with exceptions. The only downs=
ide I see
<br>&gt; (other than incompatibility, which I&#39;m abandoning for now) is =
the
<br>&gt; language-library tangling - perhaps a necessary evil.
<br>
<br>
<br>For what it&#39;s worth, char* is not a part of my vocabulary. It&#39;s=
 an
<br>arcane legacy type
<br>the traces of which I eradicate wherever I go. Having this supposedly-m=
odern
<br>signature of main use it is not a step forward, as I said, it&#39;s a s=
tep nowhere.
<br></blockquote></div></div></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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a11c2f4e6f61f5604f3c90773--

.

--part2329-boundary-149034235-887142176
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

If addressing this, why not address the environment (env) as well?
What if we move towards a more OO-like solution such as an object? In such =
a case, we would enable abilities such as libraries to extend from, or even=
 override and do supermessaging of more advanced procedures such as do thin=
gs before/after construction/destr of global objects, among other things.
E.g.: (while travelling, just for discussion)

class main_t
{
public:
    virtual int entry(your_favorite_signature_being_discussed) =3D 0;
P

    unordered_map<string, string>& env;

    virtual void global_ctors();
    virtual void global_dtors();
};

Having a std ability to hook the moment before of calling the globals ctor =
list and the dtor counterpart would ease a lot embedded development.
Enviado desde mi BlackBerry de Movistar (http://www.movistar.com.ar)

-----Original Message-----
From: Joseph Mansfield <sftrabbit@gmail.com>
Date: Tue, 4 Mar 2014 03:18:30=20
To: <std-proposals@isocpp.org>
Reply-To: std-proposals@isocpp.org
Subject: [std-proposals] Modern main

Proposal: http://htmlpreview.github.io/?https://github.com/sftrabbit/Modern=
Main/blob/c84c1d4d87d9e4733d92a13096ed4350e1461782/proposal.htm
Source: https://github.com/sftrabbit/ModernMain

I've drafted up some thoughts I had on introducing a form of main that=20
takes program arguments as a std::vector<std::string>. For example:

#include <string>
#include <vector>
#include <iostream>

int main(std::vector<std::string> args)
{
for (const auto& arg : args) {
std::cout << arg << "\n";
}
}

As far as I can tell, it seems like a viable proposal that would be=20
welcomed by many (but may also be a little controversial). My main concerns=
=20
are with the approach to exception handling, but I don't think it's a=20
particularly bad way of doing it. Please take a look at the Open Questions=
=20
section.

This is my first attempt at writing a proposal draft, so let me know of any=
=20
rookie mistakes I'm making. I also do not admittedly have much of a=20
detailed understanding of compiler implementations, so I don't know if=20
there's something about this that makes it completely infeasible.

Thanks,
Joseph Mansfield

--=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/.

--part2329-boundary-149034235-887142176
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>If addressing this, why not address the environment (env) as well=
?<br/>What if we move towards a more OO-like solution such as an object? In=
 such a case, we would enable abilities such as libraries to extend from, o=
r even override and do supermessaging of more advanced procedures such as d=
o things before/after construction/destr of global objects, among other thi=
ngs.<br/>E.g.: (while travelling, just for discussion)<br/><br/>class main_=
t<br/>{<br/>public:<br/>    virtual int entry(your_favorite_signature_being=
_discussed) =3D 0;<br/>P<br/><br/>    unordered_map&lt;string, string&gt;& =
env;<br/><br/>    virtual void global_ctors();<br/>    virtual void global_=
dtors();<br/>};<br/><br/>Having a std ability to hook the moment before of =
calling the globals ctor list and the dtor counterpart would ease a lot emb=
edded development.<div>Enviado desde mi BlackBerry de Movistar (http://www.=
movistar.com.ar)</div><hr/><div><b>From: </b> Joseph Mansfield &lt;sftrabbi=
t@gmail.com&gt;
</div><div><b>Date: </b>Tue, 4 Mar 2014 03:18:30 -0800 (PST)</div><div><b>T=
o: </b>&lt;std-proposals@isocpp.org&gt;</div><div><b>ReplyTo: </b> std-prop=
osals@isocpp.org
</div><div><b>Subject: </b>[std-proposals] Modern main</div><div><br/></div=
><div dir=3D"ltr"><div>Proposal:&nbsp;http://htmlpreview.github.io/?https:/=
/github.com/sftrabbit/ModernMain/blob/c84c1d4d87d9e4733d92a13096ed4350e1461=
782/proposal.htm</div><div>Source:&nbsp;https://github.com/sftrabbit/Modern=
Main</div><div><br></div>I've drafted up some thoughts I had on introducing=
 a form of <font face=3D"courier new, monospace">main</font><font face=3D"a=
rial, sans-serif">&nbsp;that takes program arguments as a </font><font face=
=3D"courier new, monospace">std::vector&lt;std::string&gt;</font><font face=
=3D"arial, sans-serif">. For example:</font><div><font face=3D"arial, sans-=
serif"><br></font></div><div><div><font face=3D"courier new, monospace">#in=
clude &lt;string&gt;</font></div><div><font face=3D"courier new, monospace"=
>#include &lt;vector&gt;</font></div><div><font face=3D"courier new, monosp=
ace">#include &lt;iostream&gt;</font></div><div><font face=3D"courier new, =
monospace"><br></font></div><div><font face=3D"courier new, monospace">int =
main(std::vector&lt;std::string&gt; args)</font></div><div><font face=3D"co=
urier new, monospace">{</font></div><div><font face=3D"courier new, monospa=
ce"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>for (c=
onst auto&amp; arg : args) {</font></div><div><font face=3D"courier new, mo=
nospace"><span class=3D"Apple-tab-span" style=3D"white-space:pre">  </span>=
std::cout &lt;&lt; arg &lt;&lt; "\n";</font></div><div><font face=3D"courie=
r new, monospace"><span class=3D"Apple-tab-span" style=3D"white-space:pre">=
 </span>}</font></div><div><font face=3D"courier new, monospace">}</font></=
div><div><font face=3D"arial, sans-serif"><br></font></div><div><font face=
=3D"arial, sans-serif">As far as I can tell, it seems like a viable proposa=
l that would be welcomed by many (but may also be a little controversial). =
My main concerns are with the approach to exception handling, but I don't t=
hink it's a particularly bad way of doing it. Please take a look at the Ope=
n Questions section.</font></div><div><span style=3D"font-family: arial, sa=
ns-serif;"><br></span></div><div><span style=3D"font-family: arial, sans-se=
rif;">This is my first attempt at writing a proposal draft, so let me know =
of any rookie mistakes I'm making.&nbsp;I also do not admittedly have much =
of a detailed understanding of compiler implementations, so I don't know if=
 there's something about this that makes it completely infeasible.</span></=
div></div><div><span style=3D"font-family: arial, sans-serif;"><br></span><=
/div><div><span style=3D"font-family: arial, sans-serif;">Thanks,</span></d=
iv><div><span style=3D"font-family: arial, sans-serif;">Joseph Mansfield</s=
pan></div></div>

<p></p>

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

</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 />

--part2329-boundary-149034235-887142176--


.

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

Sorry, editing problems, correct repetition of link:
http://www.boost.org/doc/libs/1_55_0/doc/html/program_options.html


On Tue, Mar 4, 2014 at 4:50 PM, George Makrydakis <irrequietus@gmail.com>wrote:

> In addition, I see no reason why instead of modifying the signature of
> main, a library extension in the spirit of Boost.Program_options should not
> be proposed instead (
> http://www.boost.org/doc/libs/1_55_0/doc/html/program_options.html).
>
>
> On Tue, Mar 4, 2014 at 4:45 PM, George Makrydakis <irrequietus@gmail.com>wrote:
>
>> In view of the reasons discussed in
>> http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm I think
>> you refer you should refer to this as "auto&&" if you want to safeguard the
>> interest of novices and range semantics. Understanding these reasons means
>> that they are not really novice anymore. Regardless, modifying the
>> signature of main is just asking for the sake of string parsing seems like
>> an overkill to me.
>>
>>
>> On Tue, Mar 4, 2014 at 4:22 PM, Alex B <devalexb@gmail.com> wrote:
>>
>>> The best for beginners (and for our eyes) would be to support the
>>> following syntax:
>>>
>>> int main(auto args)
>>> {
>>>    for (x : args)
>>>       std::cout << x << "\n";
>>> }
>>>
>>> Of course, the type of args would be either array_view<string_view>,
>>> initializer_list<string_view> or initializer_list<char*>. But it takes at
>>> least an intermediate user to understand what an
>>> array_view/string_view/initializer_list is.
>>>
>>> On Tuesday, March 4, 2014 8:24:14 AM UTC-5, Ville Voutilainen wrote:
>>>
>>>> On 4 March 2014 15:09, Joseph Mansfield <sftr...@gmail.com> wrote:
>>>> > What are your concerns about initializer_list<string_view>? Then we
>>>> have the
>>>> > appropriate vocabulary (string_view will be fundamental one day), a
>>>> modern
>>>> > approach to strings, and no issues with exceptions. The only downside
>>>> I see
>>>> > (other than incompatibility, which I'm abandoning for now) is the
>>>> > language-library tangling - perhaps a necessary evil.
>>>>
>>>>
>>>> For what it's worth, char* is not a part of my vocabulary. It's an
>>>> arcane legacy type
>>>> the traces of which I eradicate wherever I go. Having this
>>>> supposedly-modern
>>>> signature of main use it is not a step forward, as I said, it's a step
>>>> nowhere.
>>>>
>>>  --
>>>
>>> ---
>>> 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/.

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

<div dir=3D"ltr">Sorry, editing problems, correct repetition of link: <a hr=
ef=3D"http://www.boost.org/doc/libs/1_55_0/doc/html/program_options.html" t=
arget=3D"_blank">http://www.boost.org/doc/libs/1_55_0/doc/html/program_opti=
ons.html</a></div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, Mar 4=
, 2014 at 4:50 PM, George Makrydakis <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:irrequietus@gmail.com" target=3D"_blank">irrequietus@gmail.com</a>&gt;</s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">In addition, I see no reaso=
n why instead of modifying the signature of main, a library extension in th=
e spirit of Boost.Program_options should not be proposed instead (<a href=
=3D"http://www.boost.org/doc/libs/1_55_0/doc/html/program_options.htm" targ=
et=3D"_blank">http://www.boost.org/doc/libs/1_55_0/doc/html/program_options=
..htm</a>l).<br>

</div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><b=
r><br><div class=3D"gmail_quote">On Tue, Mar 4, 2014 at 4:45 PM, George Mak=
rydakis <span dir=3D"ltr">&lt;<a href=3D"mailto:irrequietus@gmail.com" targ=
et=3D"_blank">irrequietus@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">In view of the reasons disc=
ussed in <a href=3D"http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n38=
53.htm" target=3D"_blank">http://open-std.org/jtc1/sc22/wg21/docs/papers/20=
14/n3853.htm</a> I think you refer you should refer to this as &quot;auto&a=
mp;&amp;&quot; if you want to safeguard the interest of novices and range s=
emantics. Understanding these reasons means that they are not really novice=
 anymore. Regardless, modifying the signature of main is just asking for th=
e sake of string parsing seems like an overkill to me.<br>


</div><div><div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quot=
e">On Tue, Mar 4, 2014 at 4:22 PM, Alex B <span dir=3D"ltr">&lt;<a href=3D"=
mailto:devalexb@gmail.com" target=3D"_blank">devalexb@gmail.com</a>&gt;</sp=
an> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>The best for beginners (and for our eyes) would be to=
 support the following syntax:</div><div>=C2=A0</div><div><font face=3D"cou=
rier new,monospace">int main(auto args)</font></div><div><font face=3D"cour=
ier new,monospace">{</font></div>


<div><font face=3D"courier new,monospace">=C2=A0=C2=A0 for (x : args)</font=
><div><font face=3D"courier new,monospace">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 s=
td::cout &lt;&lt;=C2=A0x &lt;&lt; &quot;\n&quot;;</font></div></div><div><f=
ont face=3D"courier new,monospace">}</font></div>


<div>=C2=A0</div><div>Of course, the type of args would be either array_vie=
w&lt;string_view&gt;, initializer_list&lt;string_view&gt; or initializer_li=
st&lt;char*&gt;. But it takes at least an intermediate user to understand w=
hat an array_view/string_view/initializer_list is.</div>


<div><br>On Tuesday, March 4, 2014 8:24:14 AM UTC-5, Ville Voutilainen wrot=
e:</div><div><div><blockquote 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" class=3D"gmail_quote">


On 4 March 2014 15:09, Joseph Mansfield &lt;<a>sftr...@gmail.com</a>&gt; wr=
ote:
<br>&gt; What are your concerns about initializer_list&lt;string_view&gt;? =
Then we have the
<br>&gt; appropriate vocabulary (string_view will be fundamental one day), =
a modern
<br>&gt; approach to strings, and no issues with exceptions. The only downs=
ide I see
<br>&gt; (other than incompatibility, which I&#39;m abandoning for now) is =
the
<br>&gt; language-library tangling - perhaps a necessary evil.
<br>
<br>
<br>For what it&#39;s worth, char* is not a part of my vocabulary. It&#39;s=
 an
<br>arcane legacy type
<br>the traces of which I eradicate wherever I go. Having this supposedly-m=
odern
<br>signature of main use it is not a step forward, as I said, it&#39;s a s=
tep nowhere.
<br></blockquote></div></div></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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a11c12662d117f704f3c91aec--

.

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

Does that mean that we should also cater for parsing balanced single /
double quote enclosures of strings and support custom separators as well
beyond whitespace for the sake of assisting these small programs? That is
when the effort on parsing falls into the programmer, not thrust upon the
main function signature. As Daniel Gutson says in his email to the thread
why not address the environment variables as well? And it does not stop
there.

If facilitating option parsing is what the real question is all about, a
library level implementation is the better mousetrap.

On Tue, Mar 4, 2014 at 4:49 PM, David Krauss <potswa@gmail.com> wrote:
[...snip... ]

>
> So, why not allow main to have any single parameter that can be
> initialized by a *braced-init-list* of string literals? Pretend the
> command line is pasted into the source code. If we go so far as to allow
> aggregate initialization, this works out wonderfully for small programs
> that otherwise would spend disproportionate effort on parsing. The
> implementation can print a canned message if the number of arguments does
> not provide a well-formed list-initialization.
>
>  --
>

--

---
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/.

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

<div dir=3D"ltr"><div>Does that mean that we should also cater for parsing =
balanced single / double quote enclosures of strings and support custom sep=
arators as well beyond whitespace for the sake of assisting these small pro=
grams? That is when the effort on parsing falls into the programmer, not th=
rust upon the main function signature. As Daniel Gutson says in his email t=
o the thread why not address the environment variables as well? And it does=
 not stop there.<br>
<br></div>If facilitating option parsing is what the real question is all a=
bout, a library level implementation is the better mousetrap.<br><div><br><=
div><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Tue, Mar 4, 20=
14 at 4:49 PM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"mailto:potswa@=
gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span> wrote:<br>
</div><div class=3D"gmail_quote">[...snip... ]<br></div><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word">=
<div><div>
<br></div><div>So, why not allow <font face=3D"Courier">main</font> to have=
 any single parameter that can be initialized by a <i>braced-init-list</i> =
of string literals? Pretend the command line is pasted into the source code=
.. If we go so far as to allow aggregate initialization, this works out wond=
erfully for small programs that otherwise would spend disproportionate effo=
rt on parsing. The implementation can print a canned message if the number =
of arguments does not provide a well-formed list-initialization.</div>
<div><br></div></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
</div></div></blockquote></div><br></div></div></div></div>

<p></p>

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

--089e0153673e2f707a04f3c942c8--

.

--047d7b6dbdca8833f304f3c95784
Content-Type: text/plain; charset=ISO-8859-1

The proposal is not an attempt to provide a program options parsing
library, only to adapt the function that all C++ programs must have to a
C++-style signature. I think these are entirely different issues, related
only by the fact that one would likely be used as the input to another.


On 4 March 2014 14:50, George Makrydakis <irrequietus@gmail.com> wrote:

> In addition, I see no reason why instead of modifying the signature of
> main, a library extension in the spirit of Boost.Program_options should not
> be proposed instead (
> http://www.boost.org/doc/libs/1_55_0/doc/html/program_options.html).
>
>
> On Tue, Mar 4, 2014 at 4:45 PM, George Makrydakis <irrequietus@gmail.com>wrote:
>
>> In view of the reasons discussed in
>> http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm I think
>> you refer you should refer to this as "auto&&" if you want to safeguard the
>> interest of novices and range semantics. Understanding these reasons means
>> that they are not really novice anymore. Regardless, modifying the
>> signature of main is just asking for the sake of string parsing seems like
>> an overkill to me.
>>
>>
>> On Tue, Mar 4, 2014 at 4:22 PM, Alex B <devalexb@gmail.com> wrote:
>>
>>> The best for beginners (and for our eyes) would be to support the
>>> following syntax:
>>>
>>> int main(auto args)
>>> {
>>>    for (x : args)
>>>       std::cout << x << "\n";
>>> }
>>>
>>> Of course, the type of args would be either array_view<string_view>,
>>> initializer_list<string_view> or initializer_list<char*>. But it takes at
>>> least an intermediate user to understand what an
>>> array_view/string_view/initializer_list is.
>>>
>>> On Tuesday, March 4, 2014 8:24:14 AM UTC-5, Ville Voutilainen wrote:
>>>
>>>> On 4 March 2014 15:09, Joseph Mansfield <sftr...@gmail.com> wrote:
>>>> > What are your concerns about initializer_list<string_view>? Then we
>>>> have the
>>>> > appropriate vocabulary (string_view will be fundamental one day), a
>>>> modern
>>>> > approach to strings, and no issues with exceptions. The only downside
>>>> I see
>>>> > (other than incompatibility, which I'm abandoning for now) is the
>>>> > language-library tangling - perhaps a necessary evil.
>>>>
>>>>
>>>> For what it's worth, char* is not a part of my vocabulary. It's an
>>>> arcane legacy type
>>>> the traces of which I eradicate wherever I go. Having this
>>>> supposedly-modern
>>>> signature of main use it is not a step forward, as I said, it's a step
>>>> nowhere.
>>>>
>>>  --
>>>
>>> ---
>>> 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 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/FMAAdCVGiZU/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/.
>

--

---
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/.

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

<div dir=3D"ltr">The proposal is not an attempt to provide a program option=
s parsing library, only to adapt the function that all C++ programs must ha=
ve to a C++-style signature. I think these are entirely different issues, r=
elated only by the fact that one would likely be used as the input to anoth=
er.</div>

<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 4 March 20=
14 14:50, George Makrydakis <span dir=3D"ltr">&lt;<a href=3D"mailto:irrequi=
etus@gmail.com" target=3D"_blank">irrequietus@gmail.com</a>&gt;</span> wrot=
e:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">In addition, I see no reaso=
n why instead of modifying the signature of main, a library extension in th=
e spirit of Boost.Program_options should not be proposed instead (<a href=
=3D"http://www.boost.org/doc/libs/1_55_0/doc/html/program_options.htm" targ=
et=3D"_blank">http://www.boost.org/doc/libs/1_55_0/doc/html/program_options=
..htm</a>l).<br>


</div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><b=
r><br><div class=3D"gmail_quote">On Tue, Mar 4, 2014 at 4:45 PM, George Mak=
rydakis <span dir=3D"ltr">&lt;<a href=3D"mailto:irrequietus@gmail.com" targ=
et=3D"_blank">irrequietus@gmail.com</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">In view of the reasons disc=
ussed in <a href=3D"http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n38=
53.htm" target=3D"_blank">http://open-std.org/jtc1/sc22/wg21/docs/papers/20=
14/n3853.htm</a> I think you refer you should refer to this as &quot;auto&a=
mp;&amp;&quot; if you want to safeguard the interest of novices and range s=
emantics. Understanding these reasons means that they are not really novice=
 anymore. Regardless, modifying the signature of main is just asking for th=
e sake of string parsing seems like an overkill to me.<br>



</div><div><div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quot=
e">On Tue, Mar 4, 2014 at 4:22 PM, Alex B <span dir=3D"ltr">&lt;<a href=3D"=
mailto:devalexb@gmail.com" target=3D"_blank">devalexb@gmail.com</a>&gt;</sp=
an> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>The best for beginners (and for our eyes) would be to=
 support the following syntax:</div><div>=A0</div><div><font face=3D"courie=
r new,monospace">int main(auto args)</font></div><div><font face=3D"courier=
 new,monospace">{</font></div>



<div><font face=3D"courier new,monospace">=A0=A0 for (x : args)</font><div>=
<font face=3D"courier new,monospace">=A0=A0=A0=A0=A0 std::cout &lt;&lt;=A0x=
 &lt;&lt; &quot;\n&quot;;</font></div></div><div><font face=3D"courier new,=
monospace">}</font></div>



<div>=A0</div><div>Of course, the type of args would be either array_view&l=
t;string_view&gt;, initializer_list&lt;string_view&gt; or initializer_list&=
lt;char*&gt;. But it takes at least an intermediate user to understand what=
 an array_view/string_view/initializer_list is.</div>



<div><br>On Tuesday, March 4, 2014 8:24:14 AM UTC-5, Ville Voutilainen wrot=
e:</div><div><div><blockquote 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" class=3D"gmail_quote">



On 4 March 2014 15:09, Joseph Mansfield &lt;<a>sftr...@gmail.com</a>&gt; wr=
ote:
<br>&gt; What are your concerns about initializer_list&lt;string_view&gt;? =
Then we have the
<br>&gt; appropriate vocabulary (string_view will be fundamental one day), =
a modern
<br>&gt; approach to strings, and no issues with exceptions. The only downs=
ide I see
<br>&gt; (other than incompatibility, which I&#39;m abandoning for now) is =
the
<br>&gt; language-library tangling - perhaps a necessary evil.
<br>
<br>
<br>For what it&#39;s worth, char* is not a part of my vocabulary. It&#39;s=
 an
<br>arcane legacy type
<br>the traces of which I eradicate wherever I go. Having this supposedly-m=
odern
<br>signature of main use it is not a step forward, as I said, it&#39;s a s=
tep nowhere.
<br></blockquote></div></div></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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/FMAAdCVGiZU/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/FMAAdCVGiZU=
/unsubscribe</a>.<br>


To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<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 />

--047d7b6dbdca8833f304f3c95784--

.

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

That it is not an attempt to provide a program options parsing library is
fairly obvious. The fact is that the arguments passed in main are used for
option parsing in the end. Initializing a vector of strings using the
arguments passed in main is a fairly simple one - liner. So, in the end,
you are unlikely to avoid addressing that issue.


On Tue, Mar 4, 2014 at 5:12 PM, Joseph Mansfield <sftrabbit@gmail.com>wrote:

> The proposal is not an attempt to provide a program options parsing
> library, only to adapt the function that all C++ programs must have to a
> C++-style signature. I think these are entirely different issues, related
> only by the fact that one would likely be used as the input to another.
>
>
> On 4 March 2014 14:50, George Makrydakis <irrequietus@gmail.com> wrote:
>
>> In addition, I see no reason why instead of modifying the signature of
>> main, a library extension in the spirit of Boost.Program_options should not
>> be proposed instead (
>> http://www.boost.org/doc/libs/1_55_0/doc/html/program_options.html).
>>
>>
>> On Tue, Mar 4, 2014 at 4:45 PM, George Makrydakis <irrequietus@gmail.com>wrote:
>>
>>> In view of the reasons discussed in
>>> http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm I think
>>> you refer you should refer to this as "auto&&" if you want to safeguard the
>>> interest of novices and range semantics. Understanding these reasons means
>>> that they are not really novice anymore. Regardless, modifying the
>>> signature of main is just asking for the sake of string parsing seems like
>>> an overkill to me.
>>>
>>>
>>> On Tue, Mar 4, 2014 at 4:22 PM, Alex B <devalexb@gmail.com> wrote:
>>>
>>>> The best for beginners (and for our eyes) would be to support the
>>>> following syntax:
>>>>
>>>> int main(auto args)
>>>> {
>>>>    for (x : args)
>>>>       std::cout << x << "\n";
>>>> }
>>>>
>>>> Of course, the type of args would be either array_view<string_view>,
>>>> initializer_list<string_view> or initializer_list<char*>. But it takes at
>>>> least an intermediate user to understand what an
>>>> array_view/string_view/initializer_list is.
>>>>
>>>> On Tuesday, March 4, 2014 8:24:14 AM UTC-5, Ville Voutilainen wrote:
>>>>
>>>>> On 4 March 2014 15:09, Joseph Mansfield <sftr...@gmail.com> wrote:
>>>>> > What are your concerns about initializer_list<string_view>? Then we
>>>>> have the
>>>>> > appropriate vocabulary (string_view will be fundamental one day), a
>>>>> modern
>>>>> > approach to strings, and no issues with exceptions. The only
>>>>> downside I see
>>>>> > (other than incompatibility, which I'm abandoning for now) is the
>>>>> > language-library tangling - perhaps a necessary evil.
>>>>>
>>>>>
>>>>> For what it's worth, char* is not a part of my vocabulary. It's an
>>>>> arcane legacy type
>>>>> the traces of which I eradicate wherever I go. Having this
>>>>> supposedly-modern
>>>>> signature of main use it is not a step forward, as I said, it's a step
>>>>> nowhere.
>>>>>
>>>>  --
>>>>
>>>> ---
>>>> 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 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/FMAAdCVGiZU/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/.
>>
>
>  --
>
> ---
> 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/.

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

<div dir=3D"ltr">That it is not an attempt to provide a program options par=
sing library is fairly obvious. The fact is that the arguments passed in ma=
in are used for option parsing in the end. Initializing a vector of strings=
 using the arguments passed in main is a fairly simple one - liner. So, in =
the end, you are unlikely to avoid addressing that issue.<br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue,=
 Mar 4, 2014 at 5:12 PM, Joseph Mansfield <span dir=3D"ltr">&lt;<a href=3D"=
mailto:sftrabbit@gmail.com" target=3D"_blank">sftrabbit@gmail.com</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">The proposal is not an atte=
mpt to provide a program options parsing library, only to adapt the functio=
n that all C++ programs must have to a C++-style signature. I think these a=
re entirely different issues, related only by the fact that one would likel=
y be used as the input to another.</div>


<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><div cla=
ss=3D"h5">On 4 March 2014 14:50, George Makrydakis <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:irrequietus@gmail.com" target=3D"_blank">irrequietus@gmail.=
com</a>&gt;</span> wrote:<br>


</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div dir=
=3D"ltr">In addition, I see no reason why instead of modifying the signatur=
e of main, a library extension in the spirit of Boost.Program_options shoul=
d not be proposed instead (<a href=3D"http://www.boost.org/doc/libs/1_55_0/=
doc/html/program_options.htm" target=3D"_blank">http://www.boost.org/doc/li=
bs/1_55_0/doc/html/program_options.htm</a>l).<br>



</div></div></div><div><div><div><div class=3D"h5"><div class=3D"gmail_extr=
a"><br><br><div class=3D"gmail_quote">On Tue, Mar 4, 2014 at 4:45 PM, Georg=
e Makrydakis <span dir=3D"ltr">&lt;<a href=3D"mailto:irrequietus@gmail.com"=
 target=3D"_blank">irrequietus@gmail.com</a>&gt;</span> wrote:<br>



<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">In view of the reasons disc=
ussed in <a href=3D"http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n38=
53.htm" target=3D"_blank">http://open-std.org/jtc1/sc22/wg21/docs/papers/20=
14/n3853.htm</a> I think you refer you should refer to this as &quot;auto&a=
mp;&amp;&quot; if you want to safeguard the interest of novices and range s=
emantics. Understanding these reasons means that they are not really novice=
 anymore. Regardless, modifying the signature of main is just asking for th=
e sake of string parsing seems like an overkill to me.<br>




</div><div><div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quot=
e">On Tue, Mar 4, 2014 at 4:22 PM, Alex B <span dir=3D"ltr">&lt;<a href=3D"=
mailto:devalexb@gmail.com" target=3D"_blank">devalexb@gmail.com</a>&gt;</sp=
an> wrote:<br>



<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>The best for beginners (and for our eyes) would be to=
 support the following syntax:</div><div>=C2=A0</div><div><font face=3D"cou=
rier new,monospace">int main(auto args)</font></div><div><font face=3D"cour=
ier new,monospace">{</font></div>




<div><font face=3D"courier new,monospace">=C2=A0=C2=A0 for (x : args)</font=
><div><font face=3D"courier new,monospace">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 s=
td::cout &lt;&lt;=C2=A0x &lt;&lt; &quot;\n&quot;;</font></div></div><div><f=
ont face=3D"courier new,monospace">}</font></div>




<div>=C2=A0</div><div>Of course, the type of args would be either array_vie=
w&lt;string_view&gt;, initializer_list&lt;string_view&gt; or initializer_li=
st&lt;char*&gt;. But it takes at least an intermediate user to understand w=
hat an array_view/string_view/initializer_list is.</div>




<div><br>On Tuesday, March 4, 2014 8:24:14 AM UTC-5, Ville Voutilainen wrot=
e:</div><div><div><blockquote 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" class=3D"gmail_quote">




On 4 March 2014 15:09, Joseph Mansfield &lt;<a>sftr...@gmail.com</a>&gt; wr=
ote:
<br>&gt; What are your concerns about initializer_list&lt;string_view&gt;? =
Then we have the
<br>&gt; appropriate vocabulary (string_view will be fundamental one day), =
a modern
<br>&gt; approach to strings, and no issues with exceptions. The only downs=
ide I see
<br>&gt; (other than incompatibility, which I&#39;m abandoning for now) is =
the
<br>&gt; language-library tangling - perhaps a necessary evil.
<br>
<br>
<br>For what it&#39;s worth, char* is not a part of my vocabulary. It&#39;s=
 an
<br>arcane legacy type
<br>the traces of which I eradicate wherever I go. Having this supposedly-m=
odern
<br>signature of main use it is not a step forward, as I said, it&#39;s a s=
tep nowhere.
<br></blockquote></div></div></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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

<p></p>

-- <br>
=C2=A0<br>
--- <br></div></div>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/FMAAdCVGiZU/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/FMAAdCVGiZU=
/unsubscribe</a>.<br>



To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.org</a>.<div class=3D""><br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></div></blockquote></div><br></div><div class=3D"HOEnZb"><div c=
lass=3D"h5">

<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">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a1133bce2260f6a04f3ca19b1--

.

On 2014-03-04 06:55, Alisdair Meredith wrote:
> My principle reason to start with 'initializer_list<char *>' is that it avoid entangling
> the language and library any further.  Currently, the compiler is not expected to
> understand either 'vector', nor 'string', not 'basic_string<CharT, TraitsT, AllocatorT>',
> not how to combine them.

That's readily solved by having the linker include a function from the
standard library as 'main' which has the "old" signature and invokes the
user-supplied 'main' with the proposed signature. (In fact, I'm not sure
the compiler needs to be - or even /should/ be - involved here at all.
Isn't handling of the entry-point already done by the linker?)

For that matter, anyone could write that wrapper function, stick it in a
library, and have this functionality right now. Nor is the idea of
providing an executable's main() via a library which invokes other
well-known functions from the executable sources a novel idea; see e.g.
gtest for an example.

--
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/.

.

--001a11c2489623406304f3ca81dc
Content-Type: text/plain; charset=ISO-8859-1

Well, you could say that for every current usage of 'auto'; I don't see how
this is different.

You are basically saying that beginners should be made experts and too bad
if they can't or don't want to. The thing is that a lot of programmers (if
not most) don't really care about the underlying concepts and that's why
they often choose another language.


On Tue, Mar 4, 2014 at 9:43 AM, Johannes Schaub <
schaub.johannes@googlemail.com> wrote:

>
> Am 04.03.2014 15:22 schrieb "Alex B" <devalexb@gmail.com>:
>
> >
> > The best for beginners (and for our eyes) would be to support the
> following syntax:
> >
> > int main(auto args)
> > {
> >    for (x : args)
> >       std::cout << x << "\n";
> > }
> >
> > Of course, the type of args would be either array_view<string_view>,
> initializer_list<string_view> or initializer_list<char*>. But it takes at
> least an intermediate user to understand what an
> array_view/string_view/initializer_list is.
> >
>
> I disagree. People would need to know what concept the type passed to main
> needs to model (and recursively, of the possible element type of the
> iterable thing of args). It doesn't free the user of reading documentation.
>
> I would argue that it takes more to understand that than to understand
> either initializer list or array view and stringview.
>
> --
>
> ---
> 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/FMAAdCVGiZU/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/.
>

--

---
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/.

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

<div dir=3D"ltr"><div>Well, you could say that for every current usage of &=
#39;auto&#39;; I don&#39;t see how this is different.<br></div><div><br></d=
iv><div>You are basically saying that beginners should be made experts and =
too bad if they can&#39;t or don&#39;t want to. The thing is that a lot of =
programmers (if not most) don&#39;t really care about the underlying concep=
ts and that&#39;s why they often choose another language.<br>
</div><div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On=
 Tue, Mar 4, 2014 at 9:43 AM, Johannes Schaub <span dir=3D"ltr">&lt;<a href=
=3D"mailto:schaub.johannes@googlemail.com" target=3D"_blank">schaub.johanne=
s@googlemail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><p dir=3D"ltr"><br>
Am 04.03.2014 15:22 schrieb &quot;Alex B&quot; &lt;<a href=3D"mailto:devale=
xb@gmail.com" target=3D"_blank">devalexb@gmail.com</a>&gt;:</p><div class=
=3D""><br>
&gt;<br>
&gt; The best for beginners (and for our eyes) would be to support the foll=
owing syntax:<br>
&gt; =A0<br>
&gt; int main(auto args)<br>
&gt; {<br>
&gt; =A0=A0 for (x : args)<br>
&gt; =A0=A0=A0=A0=A0 std::cout &lt;&lt;=A0x &lt;&lt; &quot;\n&quot;;<br>
&gt; }<br>
&gt; =A0<br>
&gt; Of course, the type of args would be either array_view&lt;string_view&=
gt;, initializer_list&lt;string_view&gt; or initializer_list&lt;char*&gt;. =
But it takes at least an intermediate user to understand what an array_view=
/string_view/initializer_list is.<br>


&gt;</div><p></p>
<p dir=3D"ltr">I disagree. People would need to know what concept the type =
passed to main needs to model (and recursively, of the possible element typ=
e of the iterable thing of args). It doesn&#39;t free the user of reading d=
ocumentation.</p>


<p dir=3D"ltr">I would argue that it takes more to understand that than to =
understand either initializer list or array view and stringview.<br>
</p><div class=3D""><div class=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/FMAAdCVGiZU/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/FMAAdCVGiZU=
/unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div></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 />

--001a11c2489623406304f3ca81dc--

.

On 2014-03-04 08:24, Ville Voutilainen wrote:
> For what it's worth, char* is not a part of my vocabulary. It's an
> arcane legacy type the traces of which I eradicate wherever I go.

Your code contains no string literals? (Or are you considering "char*"
as different from "char const*"?)

It's not arcane. It's not legacy. It's as fundamental to the language as
'int'.

--
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/.

.

--047d7b15a4b7b0d5d104f3ca8c13
Content-Type: text/plain; charset=ISO-8859-1

I'm not a fan of the auto idea because having auto type arguments is just a
terse syntax for template arguments. There is no good reason for main to be
a template function - it will only ever be instantiated once. In addition
to this, the goal is not to remove as many concepts as possible so that
newcomers don't even need to think, but to remove concepts that modern C++
should not need to use.


On 4 March 2014 16:36, Alex B <devalexb@gmail.com> wrote:

> Well, you could say that for every current usage of 'auto'; I don't see
> how this is different.
>
> You are basically saying that beginners should be made experts and too bad
> if they can't or don't want to. The thing is that a lot of programmers (if
> not most) don't really care about the underlying concepts and that's why
> they often choose another language.
>
>
> On Tue, Mar 4, 2014 at 9:43 AM, Johannes Schaub <
> schaub.johannes@googlemail.com> wrote:
>
>>
>> Am 04.03.2014 15:22 schrieb "Alex B" <devalexb@gmail.com>:
>>
>> >
>> > The best for beginners (and for our eyes) would be to support the
>> following syntax:
>> >
>> > int main(auto args)
>> > {
>> >    for (x : args)
>> >       std::cout << x << "\n";
>> > }
>> >
>> > Of course, the type of args would be either array_view<string_view>,
>> initializer_list<string_view> or initializer_list<char*>. But it takes at
>> least an intermediate user to understand what an
>> array_view/string_view/initializer_list is.
>> >
>>
>> I disagree. People would need to know what concept the type passed to
>> main needs to model (and recursively, of the possible element type of the
>> iterable thing of args). It doesn't free the user of reading documentation.
>>
>> I would argue that it takes more to understand that than to understand
>> either initializer list or array view and stringview.
>>
>> --
>>
>> ---
>> 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/FMAAdCVGiZU/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/.
>>
>
>  --
>
> ---
> 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/FMAAdCVGiZU/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/.
>

--

---
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/.

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

<div dir=3D"ltr">I&#39;m not a fan of the auto idea because having auto typ=
e arguments is just a terse syntax for template arguments. There is no good=
 reason for main to be a template function - it will only ever be instantia=
ted once. In addition to this, the goal is not to remove as many concepts a=
s possible so that newcomers don&#39;t even need to think, but to remove co=
ncepts that modern C++ should not need to use.</div>

<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 4 March 20=
14 16:36, Alex B <span dir=3D"ltr">&lt;<a href=3D"mailto:devalexb@gmail.com=
" target=3D"_blank">devalexb@gmail.com</a>&gt;</span> wrote:<br><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">

<div dir=3D"ltr"><div>Well, you could say that for every current usage of &=
#39;auto&#39;; I don&#39;t see how this is different.<br></div><div><br></d=
iv><div>You are basically saying that beginners should be made experts and =
too bad if they can&#39;t or don&#39;t want to. The thing is that a lot of =
programmers (if not most) don&#39;t really care about the underlying concep=
ts and that&#39;s why they often choose another language.<br>


</div><div><div class=3D"h5"><div><div class=3D"gmail_extra"><br><br><div c=
lass=3D"gmail_quote">On Tue, Mar 4, 2014 at 9:43 AM, Johannes Schaub <span =
dir=3D"ltr">&lt;<a href=3D"mailto:schaub.johannes@googlemail.com" target=3D=
"_blank">schaub.johannes@googlemail.com</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><p dir=3D"ltr"><br>
Am 04.03.2014 15:22 schrieb &quot;Alex B&quot; &lt;<a href=3D"mailto:devale=
xb@gmail.com" target=3D"_blank">devalexb@gmail.com</a>&gt;:</p><div><br>
&gt;<br>
&gt; The best for beginners (and for our eyes) would be to support the foll=
owing syntax:<br>
&gt; =A0<br>
&gt; int main(auto args)<br>
&gt; {<br>
&gt; =A0=A0 for (x : args)<br>
&gt; =A0=A0=A0=A0=A0 std::cout &lt;&lt;=A0x &lt;&lt; &quot;\n&quot;;<br>
&gt; }<br>
&gt; =A0<br>
&gt; Of course, the type of args would be either array_view&lt;string_view&=
gt;, initializer_list&lt;string_view&gt; or initializer_list&lt;char*&gt;. =
But it takes at least an intermediate user to understand what an array_view=
/string_view/initializer_list is.<br>




&gt;</div><p></p>
<p dir=3D"ltr">I disagree. People would need to know what concept the type =
passed to main needs to model (and recursively, of the possible element typ=
e of the iterable thing of args). It doesn&#39;t free the user of reading d=
ocumentation.</p>




<p dir=3D"ltr">I would argue that it takes more to understand that than to =
understand either initializer list or array view and stringview.<br>
</p><div><div>

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/FMAAdCVGiZU/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/FMAAdCVGiZU=
/unsubscribe</a>.<br>



To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div></div></div></div><div class=
=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/FMAAdCVGiZU/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/FMAAdCVGiZU=
/unsubscribe</a>.<br>


To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<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 />

--047d7b15a4b7b0d5d104f3ca8c13--

.

--047d7b6dbdca4a43f004f3caa247
Content-Type: text/plain; charset=ISO-8859-1

The char* type itself is not arcane, but the interpretation of a char* as
being a pointer to the first character of a null-terminated array of
characters is. It makes char* a special case of pointer, which is something
I find extremely awkward in C++. Obviously that's not going anywhere, but
we have a better way to represent strings in C++ - we should use it.


On 4 March 2014 16:37, Matthew Woehlke <mw_triad@users.sourceforge.net>wrote:

> On 2014-03-04 08:24, Ville Voutilainen wrote:
>
>> For what it's worth, char* is not a part of my vocabulary. It's an
>> arcane legacy type the traces of which I eradicate wherever I go.
>>
>
> Your code contains no string literals? (Or are you considering "char*" as
> different from "char const*"?)
>
> It's not arcane. It's not legacy. It's as fundamental to the language as
> 'int'.
>
> --
> Matthew
>
>
> --
>
> --- 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/FMAAdCVGiZU/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/.
>

--

---
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/.

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

<div dir=3D"ltr">The char* type itself is not arcane, but the interpretatio=
n of a char* as being a pointer to the first character of a null-terminated=
 array of characters is. It makes char* a special case of pointer, which is=
 something I find extremely awkward in C++. Obviously that&#39;s not going =
anywhere, but we have a better way to represent strings in C++ - we should =
use it.</div>

<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 4 March 20=
14 16:37, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=3D"mailto:mw_triad@=
users.sourceforge.net" target=3D"_blank">mw_triad@users.sourceforge.net</a>=
&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 2014-03-04 08:24, Ville V=
outilainen wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
For what it&#39;s worth, char* is not a part of my vocabulary. It&#39;s an<=
br>
arcane legacy type the traces of which I eradicate wherever I go.<br>
</blockquote>
<br></div>
Your code contains no string literals? (Or are you considering &quot;char*&=
quot; as different from &quot;char const*&quot;?)<br>
<br>
It&#39;s not arcane. It&#39;s not legacy. It&#39;s as fundamental to the la=
nguage as &#39;int&#39;.<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
-- <br>
Matthew</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to a topic in the =
Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/FMAAdCVGiZU/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<u></u>isocpp.org/d/topic/std-<u></u>proposa=
ls/FMAAdCVGiZU/<u></u>unsubscribe</a>.<br>


To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></blockquote></div><br></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 />

--047d7b6dbdca4a43f004f3caa247--

.

On 4 March 2014 18:37, Matthew Woehlke <mw_triad@users.sourceforge.net> wrote:
>> For what it's worth, char* is not a part of my vocabulary. It's an
>> arcane legacy type the traces of which I eradicate wherever I go.
> Your code contains no string literals? (Or are you considering "char*" as
> different from "char const*"?)

No. String literals are not of type char*, nor are they of type char const*.

> It's not arcane. It's not legacy. It's as fundamental to the language as
> 'int'.

Are you trying to make the point that we should keep the signatures of main
as they are?

--

---
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/.

.

--001a11c2451833b40204f3cac8c0
Content-Type: text/plain; charset=ISO-8859-1

I am not seeing the value of changing the signature of main. User code can
always do this without any substantial effort:

int main(int argc, char **argv) {
   std::vector<std::string> args(argv, argv+argc);

Arcane? Maybe, but I feel this is the nature of the beast. It is not
obvious at all that the first argument is the program and not an argument
for example. I am all for providing a simplified system for parsing
arguments (i.e. a program options, getopt, ... variant) as that will add
value really simplifying argument processing.

Changing the type from 'int/char**' to any other variant won't help anyone
already using a library, and I imagine that most people manually handling
the arguments do it in very simple ways.

   David


On Tue, Mar 4, 2014 at 11:45 AM, Joseph Mansfield <sftrabbit@gmail.com>wrote:

> The char* type itself is not arcane, but the interpretation of a char* as
> being a pointer to the first character of a null-terminated array of
> characters is. It makes char* a special case of pointer, which is something
> I find extremely awkward in C++. Obviously that's not going anywhere, but
> we have a better way to represent strings in C++ - we should use it.
>
>
> On 4 March 2014 16:37, Matthew Woehlke <mw_triad@users.sourceforge.net>wrote:
>
>> On 2014-03-04 08:24, Ville Voutilainen wrote:
>>
>>> For what it's worth, char* is not a part of my vocabulary. It's an
>>> arcane legacy type the traces of which I eradicate wherever I go.
>>>
>>
>> Your code contains no string literals? (Or are you considering "char*" as
>> different from "char const*"?)
>>
>> It's not arcane. It's not legacy. It's as fundamental to the language as
>> 'int'.
>>
>> --
>> Matthew
>>
>>
>> --
>>
>> --- 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/FMAAdCVGiZU/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/.
>>
>
>  --
>
> ---
> 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/.

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

<div dir=3D"ltr">I am not seeing the value of changing the signature of mai=
n. User code can always do this without any substantial effort:<br><br>int =
main(int argc, char **argv) {<br>=A0 =A0std::vector&lt;std::string&gt; args=
(argv, argv+argc);<br>
<br>Arcane? Maybe, but I feel this is the nature of the beast. It is not ob=
vious at all that the first argument is the program and not an argument for=
 example. I am all for providing a simplified system for parsing arguments =
(i.e. a program options, getopt, ... variant) as that will add value really=
 simplifying argument processing. <br>
<br>Changing the type from &#39;int/char**&#39; to any other variant won&#3=
9;t help anyone already using a library, and I imagine that most people man=
ually handling the arguments do it in very simple ways.<br><br>=A0 =A0David=
</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, Mar 4=
, 2014 at 11:45 AM, Joseph Mansfield <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:sftrabbit@gmail.com" target=3D"_blank">sftrabbit@gmail.com</a>&gt;</span>=
 wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">The char* type itself is no=
t arcane, but the interpretation of a char* as being a pointer to the first=
 character of a null-terminated array of characters is. It makes char* a sp=
ecial case of pointer, which is something I find extremely awkward in C++. =
Obviously that&#39;s not going anywhere, but we have a better way to repres=
ent strings in C++ - we should use it.</div>


<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div class=3D=
"">On 4 March 2014 16:37, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=3D"=
mailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw_triad@users.sou=
rceforge.net</a>&gt;</span> wrote:<br>


</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div class=3D""><div>On 2014-03-04 08:=
24, Ville Voutilainen wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
For what it&#39;s worth, char* is not a part of my vocabulary. It&#39;s an<=
br>
arcane legacy type the traces of which I eradicate wherever I go.<br>
</blockquote>
<br></div>
Your code contains no string literals? (Or are you considering &quot;char*&=
quot; as different from &quot;char const*&quot;?)<br>
<br>
It&#39;s not arcane. It&#39;s not legacy. It&#39;s as fundamental to the la=
nguage as &#39;int&#39;.<span><font color=3D"#888888"><br>
<br>
-- <br>
Matthew</font></span></div><div><div><br><span class=3D"HOEnZb"><font color=
=3D"#888888">
<br>
-- <br>
<br>
--- You received this message because you are subscribed to a topic in the =
Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/FMAAdCVGiZU/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<u></u>isocpp.org/d/topic/std-<u></u>proposa=
ls/FMAAdCVGiZU/<u></u>unsubscribe</a>.<br>



To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@<u></u>isocpp.org</a>.</font></span><div class=3D""><br=
>

To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></div></blockquote></div><br></div><div class=3D"HOEnZb"><div c=
lass=3D"h5">

<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">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a11c2451833b40204f3cac8c0--

.

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

On 4 March 2014 10:56, David Rodr=EDguez Ibeas <dibeas@ieee.org> wrote:

> I am not seeing the value of changing the signature of main. User code ca=
n
> always do this without any substantial effort:
>
> int main(int argc, char **argv) {
>    std::vector<std::string> args(argv, argv+argc);
>
> Arcane? Maybe, but I feel this is the nature of the beast. It is not
> obvious at all that the first argument is the program and not an argument
> for example. I am all for providing a simplified system for parsing
> arguments (i.e. a program options, getopt, ... variant) as that will add
> value really simplifying argument processing.
>
> Changing the type from 'int/char**' to any other variant won't help anyon=
e
> already using a library, and I imagine that most people manually handling
> the arguments do it in very simple ways.
>

+1.

Heck, with the wrong choices we can make things *worse*.

For instance, it has been mentioned here that initializer_list might be a
good choice, yet that class does not provide array notation, so getting to
any argument but the first one requires pointer manipulation.  Is that
really better than what we have now?

The goal should be giving people an easy way to parse arguments, not a
slightly different way to declare main.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=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/.

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

<div dir=3D"ltr">On 4 March 2014 10:56, David Rodr=EDguez Ibeas <span dir=
=3D"ltr">&lt;<a href=3D"mailto:dibeas@ieee.org" target=3D"_blank">dibeas@ie=
ee.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr">I am not seeing the value of changing the signature of mai=
n. User code can always do this without any substantial effort:<br><br>int =
main(int argc, char **argv) {<br>=A0 =A0std::vector&lt;std::string&gt; args=
(argv, argv+argc);<br>


<br>Arcane? Maybe, but I feel this is the nature of the beast. It is not ob=
vious at all that the first argument is the program and not an argument for=
 example. I am all for providing a simplified system for parsing arguments =
(i.e. a program options, getopt, ... variant) as that will add value really=
 simplifying argument processing. <br>


<br>Changing the type from &#39;int/char**&#39; to any other variant won&#3=
9;t help anyone already using a library, and I imagine that most people man=
ually handling the arguments do it in very simple ways.<span class=3D"HOEnZ=
b"></span></div>

</blockquote><div><br></div><div>+1.<br><br></div><div>Heck, with the wrong=
 choices we can make things *worse*.<br><br></div><div>For instance, it has=
 been mentioned here that initializer_list might be a good choice, yet that=
 class does not provide array notation, so getting to any argument but the =
first one requires pointer manipulation.=A0 Is that really better than what=
 we have now?<br>

</div><div><br>The goal should be giving people an easy way to parse argume=
nts, not a slightly different way to declare main. <br></div></div>-- <br>=
=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@evilov=
erlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847) 691-1=
404
</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 />

--047d7b3a86f087a39504f3cade40--

.

Em ter 04 mar 2014, =E0s 11:22:58, Matthew Woehlke escreveu:
> On 2014-03-04 06:55, Alisdair Meredith wrote:
> > My principle reason to start with 'initializer_list<char *>' is that it
> > avoid entangling the language and library any further.  Currently, the
> > compiler is not expected to understand either 'vector', nor 'string', n=
ot
> > 'basic_string<CharT, TraitsT, AllocatorT>', not how to combine them.
>=20
> That's readily solved by having the linker include a function from the
> standard library as 'main' which has the "old" signature and invokes the
> user-supplied 'main' with the proposed signature. (In fact, I'm not sure
> the compiler needs to be - or even /should/ be - involved here at all.
> Isn't handling of the entry-point already done by the linker?)

Please note that the existing main() is extern "C" and therefore cannot hav=
e=20
any overloads.

I suggest finding a new name for this entry function.

> For that matter, anyone could write that wrapper function, stick it in a
> library, and have this functionality right now. Nor is the idea of
> providing an executable's main() via a library which invokes other
> well-known functions from the executable sources a novel idea; see e.g.
> gtest for an example.

See also 25 years of experience on Windows, with the entry point being=20
WinMain() and that calls the user's main() function.

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

--=20

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

.

On 2014-03-04 10:07, George Makrydakis wrote:
> Does that mean that we should also cater for parsing balanced single /
> double quote enclosures of strings and support custom separators as well
> beyond whitespace for the sake of assisting these small programs?

Huh? That's the shell's responsibility=C2=B9; by the time arguments hit C=
=20
code all of this is already handled. (Unless you're talking about=20
building argument lists to pass to something like exec(), but that's way=20
off topic here.)

(=C2=B9 ...except for some bizarre corner cases in Windows, that's for the =
OS=20
libraries to address, not the language standard, unless it is to=20
eliminate the reason for those corner cases to exist.)

--=20
Matthew

--=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/.

.

Em ter 04 mar 2014, =E0s 22:49:41, David Krauss escreveu:
> Already the compiler must differentiate between the signatures main() and
> main(char**,int), and push parameters accordingly. How hard can it be to
> synthesize a call to something else, using the data structure provided to
> the latter signature?

Very difficult.

Right now, main() and main(int, char**) as well as main(int, char**, char**=
)=20
(for the extension supplying the environment) are the same function, with t=
he=20
same ABI for most compilers. The caller doesn't know which of those functio=
ns=20
it's calling.

Might there be ABIs where the above isn't true? Sure. But my point is that,=
=20
for the majority of modern ABIs, it is true and, therefore, adding an extra=
=20
overload that takes different arguments would be quite complex.

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

--=20

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

.

Em ter 04 mar 2014, =E0s 13:45:43, Daniel Gutson escreveu:
>     virtual void global_ctors();
>     virtual void global_dtors();
> };
>=20
> Having a std ability to hook the moment before of calling the globals cto=
r
> list and the dtor counterpart would ease a lot embedded development.

Can't you replace the global_ctors() function by, you know, global=20
constructors? What's the benefit of having the virtual above?

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

--=20

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

.

On 2014-03-04 11:45, Joseph Mansfield wrote:
> The char* type itself is not arcane, but the interpretation of a char* as
> being a pointer to the first character of a null-terminated array of
> characters is. It makes char* a special case of pointer, which is something
> I find extremely awkward in C++. Obviously that's not going anywhere, but
> we have a better way to represent strings in C++ - we should use it.

Do you mean to change the type of string literals?

That may not be a bad idea, but I have trouble envisioning how you will
accomplish that without breaking every existing C++ program in
existence. At the very least I don't think it is possible except that
the new type implicitly converts to 'char const*'.

(Although I suppose it has been done already once; they used to be
'char*' and were changed to 'char const*'. That's a fairly minor change,
though.)

--
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 Tue, Mar 4, 2014 at 3:55 AM, Alisdair Meredith <alisdairm@me.com> wrote:
> My principle reason to start with 'initializer_list<char *>' is that it avoid entangling
> the language and library any further.  Currently, the compiler is not expected to
> understand either 'vector', nor 'string', not 'basic_string<CharT, TraitsT, AllocatorT>',
> not how to combine them.
>
> It is required to turn sequences of identifiers into an initializer_list, so that boat
> already sailed.  Likewise, 'char *' is a built in type that the compiler knows about.
>
> The 'initializer_list' should also fairly trivially map to the existing data structures,
> but that is just a bonus.  My real concern is that I do not want to see 'vector',
> 'basic_string' nor any typedefs thereof crossing the library -> compiler boundary.

Note that http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3810.pdf
anticipates defining a conversion from "explicit arrays" to a library
array_ref type. That doesn't mean 'vector' and 'string' should be used
by the compiler, but a few simpler types may be all right.

--

---
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-03-04 11:55, Ville Voutilainen wrote:
> On 4 March 2014 18:37, Matthew Woehlke <mw_triad@users.sourceforge.net> w=
rote:
>>> For what it's worth, char* is not a part of my vocabulary. It's an
>>> arcane legacy type the traces of which I eradicate wherever I go.
>> Your code contains no string literals? (Or are you considering "char*" a=
s
>> different from "char const*"?)
>
> No. String literals are not of type char*, nor are they of type char cons=
t*.

Really? My compiler (g++) disagrees:

   void bar(void*) {}
   int main()
   {
     bar(const_cast<int*>("none"));
     return 0;
   }

--> error: invalid const_cast from type =E2=80=98const char*=E2=80=99 to ty=
pe =E2=80=98int*=E2=80=99

--=20
Matthew

--=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/.

.

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

It was post as a rhetorical question to the OP of the proposal. As also
said in a previous post to this thread, I believe that there is no benefit
in altering main()'s function signature if that is to facilitate option
parsing because that is not the business of the main() function signature.
I have also said that it is a matter of a one liner to pass the arguments
from the "arcane" main signature to a vector of strings. Later on David
Rodriguez Ibeas uses the one liner argument to prove the value of the same
argument. Several other people have underlined the problems with this
approach. What is *really off - topic* here is that a "novice - friendly"
shorthand or "cleaner code" reason is *not a reason valid enough* to allow
for such a change *at a language level* and leaving that aside, Thiago
Macieira's replies cover the subject to even a lower level. There is really
no other real use of the the main() function signature arguments other than
deploying them for option parsing. I really do not see any benefit of
passing a vector of strings to a library for option parsing instead of the
original contents of the main function signature, given that all option
parsing libraries already accept it. Same holds for alternative ways of
representing the same concept.


On Tue, Mar 4, 2014 at 7:06 PM, Matthew Woehlke <
mw_triad@users.sourceforge.net> wrote:

> On 2014-03-04 10:07, George Makrydakis wrote:
>
>> Does that mean that we should also cater for parsing balanced single /
>> double quote enclosures of strings and support custom separators as well
>> beyond whitespace for the sake of assisting these small programs?
>>
>
> Huh? That's the shell's responsibility=C2=B9; by the time arguments hit C=
 code
> all of this is already handled. (Unless you're talking about building
> argument lists to pass to something like exec(), but that's way off topic
> here.)
>
> (=C2=B9 ...except for some bizarre corner cases in Windows, that's for th=
e OS
> libraries to address, not the language standard, unless it is to eliminat=
e
> the reason for those corner cases to exist.)
>
> --
> Matthew
>
>
> --
>
> --- You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-
> proposals/.
>

--=20

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

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

<div dir=3D"ltr">It was post as a rhetorical question to the OP of the prop=
osal. As also said in a previous post to this thread, I believe that there =
is no benefit in altering main()&#39;s function signature if that is to fac=
ilitate option parsing because that is not the business of the main() funct=
ion signature. I have also said that it is a matter of a one liner to pass =
the arguments from the &quot;arcane&quot; main signature to a vector of str=
ings. Later on David Rodriguez Ibeas uses the one liner argument to prove t=
he value of the same argument. Several other people have underlined the pro=
blems with this approach. What is <u><b>really off - topic</b></u> here is =
that a &quot;novice - friendly&quot; shorthand or &quot;cleaner code&quot; =
reason is <u><b>not a reason valid enough</b></u> to allow for such a chang=
e <u><b>at a language level</b></u> and leaving that aside, Thiago Macieira=
&#39;s replies cover the subject to even a lower level. There is really no =
other real use of the the main() function signature arguments other than de=
ploying them for option parsing. I really do not see any benefit of passing=
 a vector of strings to a library for option parsing instead of the origina=
l contents of the main function signature, given that all option parsing li=
braries already accept it. Same holds for alternative ways of representing =
the same concept.<br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue,=
 Mar 4, 2014 at 7:06 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw_triad@users.sour=
ceforge.net</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 2014-03-04 10:07, George =
Makrydakis wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Does that mean that we should also cater for parsing balanced single /<br>
double quote enclosures of strings and support custom separators as well<br=
>
beyond whitespace for the sake of assisting these small programs?<br>
</blockquote>
<br></div>
Huh? That&#39;s the shell&#39;s responsibility=C2=B9; by the time arguments=
 hit C code all of this is already handled. (Unless you&#39;re talking abou=
t building argument lists to pass to something like exec(), but that&#39;s =
way off topic here.)<br>

<br>
(=C2=B9 ...except for some bizarre corner cases in Windows, that&#39;s for =
the OS libraries to address, not the language standard, unless it is to eli=
minate the reason for those corner cases to exist.)<span class=3D"HOEnZb"><=
font color=3D"#888888"><br>

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

<p></p>

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

--001a11c1e054b5529804f3cb2abe--

.

On 4 March 2014 19:15, Matthew Woehlke <mw_triad@users.sourceforge.net> wrote:
>> No. String literals are not of type char*, nor are they of type char
>> const*.
> Really? My compiler (g++) disagrees:
>
>   void bar(void*) {}
>   int main()
>   {
>     bar(const_cast<int*>("none"));
>     return 0;
>   }
>
> --> error: invalid const_cast from type 'const char*' to type 'int*'


Your compiler correctly decayed the type of the literal into a pointer
there. That doesn't make the literal be of pointer type.

--

---
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-03-04 12:03, Thiago Macieira wrote:
> Em ter 04 mar 2014, =C3=A0s 11:22:58, Matthew Woehlke escreveu:
>> On 2014-03-04 06:55, Alisdair Meredith wrote:
>>> My principle reason to start with 'initializer_list<char *>' is that it
>>> avoid entangling the language and library any further.  Currently, the
>>> compiler is not expected to understand either 'vector', nor 'string', n=
ot
>>> 'basic_string<CharT, TraitsT, AllocatorT>', not how to combine them.
>>
>> That's readily solved by having the linker include a function from the
>> standard library as 'main' which has the "old" signature and invokes the
>> user-supplied 'main' with the proposed signature. (In fact, I'm not sure
>> the compiler needs to be - or even /should/ be - involved here at all.
>> Isn't handling of the entry-point already done by the linker?)
>
> Please note that the existing main() is extern "C" and therefore cannot h=
ave
> any overloads.

It could if the compiler were changed to give it C++ linkage based on=20
some conditions. However...

> I suggest finding a new name for this entry function.

....I tend to lean toward this myself. (In fact I was going to make the=20
same point, but you beat me to it :-).)

--=20
Matthew

--=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_301_22372369.1393953678805
Content-Type: text/plain; charset=UTF-8

Hi Joseph,

Thanks for your proposal.  I'd like to share with you a couple of ideas:

First, you are you aware you can write:

int main(int argc, char** argv)
{
    std::vector<std::string> args(argv, argv+argc);

  for (const auto& arg : args)
    {
  std::cout << arg << "\n";
  }
}

This is one line of code.

Second, if your implementation supports weak linking, you could include the
following TU with each program:

          int main(std::vector<std::string> args);

int main(int argc, char** argv) __attribute__((weak));
int main(int argc, char** argv)
{
                  return main(std::vector<string>(argv, argv+argc));

}


This weak linked version of main will only be included if the user does not
provide a definition.  Consequently if the user provides "int main(int,
char**)" then the program will work as normal and this TU will have no
effect.  If on the other hand the user provides "int main(vector<string>)"
the weak linked version will be included and will wrap up the arguments and
pass them to it.

Just some ideas for you.

Thanks,
Andrew.




On Tuesday, March 4, 2014 12:18:30 PM UTC+1, Joseph Mansfield wrote:
>
> Proposal:
> http://htmlpreview.github.io/?https://github.com/sftrabbit/ModernMain/blob/c84c1d4d87d9e4733d92a13096ed4350e1461782/proposal.htm
> Source: https://github.com/sftrabbit/ModernMain
>
> I've drafted up some thoughts I had on introducing a form of main that
> takes program arguments as a std::vector<std::string>. For example:
>
> #include <string>
> #include <vector>
> #include <iostream>
>
> int main(std::vector<std::string> args)
> {
> for (const auto& arg : args) {
> std::cout << arg << "\n";
> }
> }
>
> As far as I can tell, it seems like a viable proposal that would be
> welcomed by many (but may also be a little controversial). My main concerns
> are with the approach to exception handling, but I don't think it's a
> particularly bad way of doing it. Please take a look at the Open Questions
> section.
>
> This is my first attempt at writing a proposal draft, so let me know of
> any rookie mistakes I'm making. I also do not admittedly have much of a
> detailed understanding of compiler implementations, so I don't know if
> there's something about this that makes it completely infeasible.
>
> Thanks,
> Joseph Mansfield
>

--

---
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_301_22372369.1393953678805
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Joseph,<div><br></div><div>Thanks for your proposal. &n=
bsp;I'd like to share with you a couple of ideas:</div><div><br></div><div>=
First, you are you aware you can write:</div><div><br></div><div><div><font=
 face=3D"courier new, monospace">int main(int argc, char** argv)</font></di=
v><div><font face=3D"courier new, monospace">{</font></div></div><div><font=
 face=3D"courier new, monospace">&nbsp; &nbsp; std::vector&lt;std::string&g=
t; args(argv, argv+argc);</font></div><div><font face=3D"courier new, monos=
pace"><br></font></div><div><div><font face=3D"courier new, monospace"><spa=
n style=3D"white-space: pre;">&nbsp;   </span>for (const auto&amp; arg : ar=
gs)</font></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; {<=
/font></div><div><font face=3D"courier new, monospace"><span style=3D"white=
-space: pre;">&nbsp;       </span>std::cout &lt;&lt; arg &lt;&lt; "\n";</fo=
nt></div><div><font face=3D"courier new, monospace"><span style=3D"white-sp=
ace: pre;">&nbsp;   </span>}</font></div><div><font face=3D"courier new, mo=
nospace">}</font></div></div><div><br></div><div>This is one line of code.<=
/div><div><br></div><div>Second, if your implementation supports weak linki=
ng, you could include the following TU with each program:</div><div><br></d=
iv><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; int main(std::vector&lt;std::str=
ing&gt; args);</div><div><br></div><div><blockquote style=3D"margin: 0px 0p=
x 0px 40px; border: none; padding: 0px;"><div>int main(int argc, char** arg=
v) __attribute__((weak));</div><div>int main(int argc, char** argv)</div><d=
iv>{</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; return main(std::vector&lt;string&gt;(argv, argv+argc));<br></div></bloc=
kquote><blockquote style=3D"margin: 0px 0px 0px 40px; border: none; padding=
: 0px;"><div>}</div></blockquote><div></div></div><div><br></div><div>This =
weak linked version of main will only be included if the user does not prov=
ide a definition. &nbsp;Consequently if the user provides "int main(int, ch=
ar**)" then the program will work as normal and this TU will have no effect=
.. &nbsp;If on the other hand the user provides "int main(vector&lt;string&g=
t;)" the weak linked version will be included and will wrap up the argument=
s and pass them to it.</div><div><br></div><div>Just some ideas for you.</d=
iv><div><br></div><div>Thanks,</div><div>Andrew.</div><div><br></div><div><=
br></div><div><div><br></div><div><br></div>On Tuesday, March 4, 2014 12:18=
:30 PM UTC+1, Joseph Mansfield wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div dir=3D"ltr"><div>Proposal:&nbsp;<a href=3D"http://htmlpreview.g=
ithub.io/?https://github.com/sftrabbit/ModernMain/blob/c84c1d4d87d9e4733d92=
a13096ed4350e1461782/proposal.htm" target=3D"_blank" onmousedown=3D"this.hr=
ef=3D'http://www.google.com/url?q\75http%3A%2F%2Fhtmlpreview.github.io%2F%3=
Fhttps%3A%2F%2Fgithub.com%2Fsftrabbit%2FModernMain%2Fblob%2Fc84c1d4d87d9e47=
33d92a13096ed4350e1461782%2Fproposal.htm\46sa\75D\46sntz\0751\46usg\75AFQjC=
NGgeJ5cyn7X_dMU0xkh-DL7caJ-XA';return true;" onclick=3D"this.href=3D'http:/=
/www.google.com/url?q\75http%3A%2F%2Fhtmlpreview.github.io%2F%3Fhttps%3A%2F=
%2Fgithub.com%2Fsftrabbit%2FModernMain%2Fblob%2Fc84c1d4d87d9e4733d92a13096e=
d4350e1461782%2Fproposal.htm\46sa\75D\46sntz\0751\46usg\75AFQjCNGgeJ5cyn7X_=
dMU0xkh-DL7caJ-XA';return true;">http://htmlpreview.<wbr>github.io/?https:/=
/github.com/<wbr>sftrabbit/ModernMain/blob/<wbr>c84c1d4d87d9e4733d92a13096e=
d43<wbr>50e1461782/proposal.htm</a></div><div>Source:&nbsp;<a href=3D"https=
://github.com/sftrabbit/ModernMain" target=3D"_blank" onmousedown=3D"this.h=
ref=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fsftrabbit%=
2FModernMain\46sa\75D\46sntz\0751\46usg\75AFQjCNES1sL6PqAN3bGwE8C8SVMRbhROA=
g';return true;" onclick=3D"this.href=3D'https://www.google.com/url?q\75htt=
ps%3A%2F%2Fgithub.com%2Fsftrabbit%2FModernMain\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNES1sL6PqAN3bGwE8C8SVMRbhROAg';return true;">https://github.com/<wbr>=
sftrabbit/ModernMain</a></div><div><br></div>I've drafted up some thoughts =
I had on introducing a form of <font face=3D"courier new, monospace">main</=
font><font face=3D"arial, sans-serif">&nbsp;that takes program arguments as=
 a </font><font face=3D"courier new, monospace">std::vector&lt;std::string&=
gt;</font><font face=3D"arial, sans-serif">. For example:</font><div><font =
face=3D"arial, sans-serif"><br></font></div><div><div><font face=3D"courier=
 new, monospace">#include &lt;string&gt;</font></div><div><font face=3D"cou=
rier new, monospace">#include &lt;vector&gt;</font></div><div><font face=3D=
"courier new, monospace">#include &lt;iostream&gt;</font></div><div><font f=
ace=3D"courier new, monospace"><br></font></div><div><font face=3D"courier =
new, monospace">int main(std::vector&lt;std::string&gt; args)</font></div><=
div><font face=3D"courier new, monospace">{</font></div><div><font face=3D"=
courier new, monospace"><span style=3D"white-space:pre"> </span>for (const =
auto&amp; arg : args) {</font></div><div><font face=3D"courier new, monospa=
ce"><span style=3D"white-space:pre">  </span>std::cout &lt;&lt; arg &lt;&lt=
; "\n";</font></div><div><font face=3D"courier new, monospace"><span style=
=3D"white-space:pre"> </span>}</font></div><div><font face=3D"courier new, =
monospace">}</font></div><div><font face=3D"arial, sans-serif"><br></font><=
/div><div><font face=3D"arial, sans-serif">As far as I can tell, it seems l=
ike a viable proposal that would be welcomed by many (but may also be a lit=
tle controversial). My main concerns are with the approach to exception han=
dling, but I don't think it's a particularly bad way of doing it. Please ta=
ke a look at the Open Questions section.</font></div><div><span style=3D"fo=
nt-family:arial,sans-serif"><br></span></div><div><span style=3D"font-famil=
y:arial,sans-serif">This is my first attempt at writing a proposal draft, s=
o let me know of any rookie mistakes I'm making.&nbsp;I also do not admitte=
dly have much of a detailed understanding of compiler implementations, so I=
 don't know if there's something about this that makes it completely infeas=
ible.</span></div></div><div><span style=3D"font-family:arial,sans-serif"><=
br></span></div><div><span style=3D"font-family:arial,sans-serif">Thanks,</=
span></div><div><span style=3D"font-family:arial,sans-serif">Joseph Mansfie=
ld</span></div></div></blockquote></div></div>

<p></p>

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

------=_Part_301_22372369.1393953678805--

.

Em ter 04 mar 2014, =C3=A0s 12:15:54, Matthew Woehlke escreveu:
>    void bar(void*) {}
>    int main()
>    {
>      bar(const_cast<int*>("none"));
>      return 0;
>    }
>=20
> --> error: invalid const_cast from type =E2=80=98const char*=E2=80=99 to =
type =E2=80=98int*=E2=80=99

It's technically a const char[5] that decayed to pointer.

void bar(const char (&)[5]);
int main()
{
 bar("none");
 return 0;
}

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

--=20

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

.

On 2014-03-04 09:49, David Krauss wrote:
>
> On Mar 4, 2014, at 9:24 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>
>> On 4 March 2014 15:09, Joseph Mansfield <sftrabbit@gmail.com> wrote:
>>> What are your concerns about initializer_list<string_view>? Then we have the
>>> appropriate vocabulary (string_view will be fundamental one day), a modern
>>> approach to strings, and no issues with exceptions. The only downside I see
>>> (other than incompatibility, which I'm abandoning for now) is the
>>> language-library tangling - perhaps a necessary evil.
>>
>>
>> For what it's worth, char* is not a part of my vocabulary. It's an
>> arcane legacy type
>> the traces of which I eradicate wherever I go. Having this supposedly-modern
>> signature of main use it is not a step forward, as I said, it's a step nowhere.
>
> Already the compiler must differentiate between the signatures
> main()and main(char**,int), and push parameters accordingly.

Really? I thought the system always supplied argc and argv, and main()
is simply free to ignore them. (And besides, I thought supplying of
arguments wasn't done by the compiler at all, but by whatever system
code bootstraps the executable?)

Folks... "main" IS NOT A C++ FUNCTION. It is a *C* function with C
linkage and calling convention.

The *only* useful change to the compiler to allow main() to take a more
C++ signature is to change the current behavior that *anything* named
"main" has C linkage.

If anything happens here, there are two options:

1. Change the compiler to *generate* a "main" thunk with C linkage
having the signature 'int main(int argc, char** argv)' that performs
whatever transformations are necessary to invoke the "new" signature
(terrible idea IMHO).

2. Change the compiler to elide the implicit C linkage of 'main' (or
just don't call the new entry 'main') and change the *linker* to supply
an appropriate thunk based on the mangled entry signature that is
supplied (*much* better idea IMO). In which case you might as well allow
for more than one signature, as it is equally easy to do. The linker is
then responsible for providing these thunks, which is a trivial matter
of having a few compiled objects and choosing the appropriate one based
on the signature that is available.

(Pedantic: The compiler *may* still need to know about the name in order
to give it external visibility, if it's intolerable for the new
signature to require an ABI export decoration.)

--
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 4 March 2014 19:16, Matthew Woehlke <mw_triad@users.sourceforge.net> wrote:
> Folks... "main" IS NOT A C++ FUNCTION. It is a *C* function with C linkage
> and calling convention.

Just because it's extern "C" does not make it a C function.

--

---
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-03-04 12:32, Ville Voutilainen wrote:
> On 4 March 2014 19:16, Matthew Woehlke <mw_triad@users.sourceforge.net> wrote:
>> Folks... "main" IS NOT A C++ FUNCTION. It is a *C* function with C linkage
>> and calling convention.
>
> Just because it's extern "C" does not make it a C function.

Sure, I don't mean the body of the function (which is irrelevant; it
could be C, C++, assembler, ...), but the linkage and calling
convention. main() *MUST* be called as if it has the signature 'extern
"C" int main(int, char**, char**)'. Nothing else is possible without
OS-level changes. (I don't count providing a thunk in that; the thunk is
still main() with the above signature.)

--
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/.

.

Em ter 04 mar 2014, =C3=A0s 09:21:18, Andrew Tomazos escreveu:
> Second, if your implementation supports weak linking, you could include t=
he=20
> following TU with each program:
>=20
>           int main(std::vector<std::string> args);
>=20
> int main(int argc, char** argv) __attribute__((weak));
> int main(int argc, char** argv)
> {
>                   return main(std::vector<string>(argv, argv+argc));
>=20
> }
>=20
>=20
> This weak linked version of main will only be included if the user does n=
ot=20
> provide a definition.  Consequently if the user provides "int main(int,
> char**)" then the program will work as normal and this TU will have no
> effect.  If on the other hand the user provides "int main(vector<string>)=
"
> the weak linked version will be included and will wrap up the arguments a=
nd
> pass them to it.
>=20
> Just some ideas for you.

This still requires changes to the spec.

The first is that main() is declared as extern "C", so having the overload=
=20
there won't be possible.=20

In function =E2=80=98int main(int, char**)=E2=80=99:
error: declaration of C function =E2=80=98int main(int, char**)=E2=80=99 co=
nflicts with
error: previous declaration =E2=80=98int main(std::vector<std::basic_string=
<char> >)=E2=80=99=20
here

The second is that the standard says you're not allowed to call main() or=
=20
reference it in any way. But if you're already depending on the compiler=20
specifics and the ABI for the weak linking, this should not be a problem.=
=20
However, the compiler may complain:

warning: first argument of =E2=80=98int main(std::vector<std::basic_string<=
char> >)=E2=80=99=20
should be =E2=80=98int=E2=80=99 [-Wmain]
warning: =E2=80=98int main(std::vector<std::basic_string<char> >)=E2=80=99 =
takes only zero or=20
two arguments [-Wmain]

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

--=20

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

.

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

Yes, I actually fudged the example a little from what I actually=20
implemented.  In the framework the function is called Main not main, so it=
=20
avoids the C linkage and other main symbol issues:

int Main(std::vector<std::string> args);=20

int main(int argc, char** argv) __attribute__((weak));=20
int main(int argc, char** argv)=20
{=20
                  return Main(std::vector<string>(argv, argv+argc));=20

}=20

It has additional features beyond this, but this change should avoid both=
=20
the C linking error and the calling main prohibition you raise.


On Tuesday, March 4, 2014 8:27:19 PM UTC+1, Thiago Macieira wrote:
>
> Em ter 04 mar 2014, =C3=A0s 09:21:18, Andrew Tomazos escreveu:=20
> > Second, if your implementation supports weak linking, you could include=
=20
> the=20
> > following TU with each program:=20
> >=20
> >           int main(std::vector<std::string> args);=20
> >=20
> > int main(int argc, char** argv) __attribute__((weak));=20
> > int main(int argc, char** argv)=20
> > {=20
> >                   return main(std::vector<string>(argv, argv+argc));=20
> >=20
> > }=20
> >=20
> >=20
> > This weak linked version of main will only be included if the user does=
=20
> not=20
> > provide a definition.  Consequently if the user provides "int main(int,=
=20
> > char**)" then the program will work as normal and this TU will have no=
=20
> > effect.  If on the other hand the user provides "int=20
> main(vector<string>)"=20
> > the weak linked version will be included and will wrap up the arguments=
=20
> and=20
> > pass them to it.=20
> >=20
> > Just some ideas for you.=20
>
> This still requires changes to the spec.=20
>
> The first is that main() is declared as extern "C", so having the overloa=
d=20
> there won't be possible.=20
>
> In function =E2=80=98int main(int, char**)=E2=80=99:=20
> error: declaration of C function =E2=80=98int main(int, char**)=E2=80=99 =
conflicts with=20
> error: previous declaration =E2=80=98int main(std::vector<std::basic_stri=
ng<char>=20
> >)=E2=80=99=20
> here=20
>
> The second is that the standard says you're not allowed to call main() or=
=20
> reference it in any way. But if you're already depending on the compiler=
=20
> specifics and the ABI for the weak linking, this should not be a problem.=
=20
> However, the compiler may complain:=20
>
> warning: first argument of =E2=80=98int main(std::vector<std::basic_strin=
g<char>=20
> >)=E2=80=99=20
> should be =E2=80=98int=E2=80=99 [-Wmain]=20
> warning: =E2=80=98int main(std::vector<std::basic_string<char> >)=E2=80=
=99 takes only zero=20
> or=20
> two arguments [-Wmain]=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=20
>       PGP/GPG: 0x6EF45358; fingerprint:=20
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358=20
>
>

--=20

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

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

<div dir=3D"ltr">Yes, I actually fudged the example a little from what I ac=
tually implemented. &nbsp;In the framework the function is called Main not =
main, so it avoids the C linkage and other main symbol issues:<div><br></di=
v><div>int Main(std::vector&lt;std::string&gt; args);&nbsp;<br><br>int main=
(int argc, char** argv) __attribute__((weak));&nbsp;<br>int main(int argc, =
char** argv)&nbsp;<br>{&nbsp;<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; return Main(std::vector&lt;string&gt;(argv, argv+argc)=
);&nbsp;<br><br>}&nbsp;<br><br>It has additional features beyond this, but =
this change should avoid both the C linking error and the calling main proh=
ibition you raise.</div><div><br><br>On Tuesday, March 4, 2014 8:27:19 PM U=
TC+1, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em=
 ter 04 mar 2014, =C3=A0s 09:21:18, Andrew Tomazos escreveu:
<br>&gt; Second, if your implementation supports weak linking, you could in=
clude the=20
<br>&gt; following TU with each program:
<br>&gt;=20
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; int main(std::vector&lt;std::st=
ring&gt; args);
<br>&gt;=20
<br>&gt; int main(int argc, char** argv) __attribute__((weak));
<br>&gt; int main(int argc, char** argv)
<br>&gt; {
<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ret=
urn main(std::vector&lt;string&gt;(argv, argv+argc));
<br>&gt;=20
<br>&gt; }
<br>&gt;=20
<br>&gt;=20
<br>&gt; This weak linked version of main will only be included if the user=
 does not=20
<br>&gt; provide a definition. &nbsp;Consequently if the user provides "int=
 main(int,
<br>&gt; char**)" then the program will work as normal and this TU will hav=
e no
<br>&gt; effect. &nbsp;If on the other hand the user provides "int main(vec=
tor&lt;string&gt;)"
<br>&gt; the weak linked version will be included and will wrap up the argu=
ments and
<br>&gt; pass them to it.
<br>&gt;=20
<br>&gt; Just some ideas for you.
<br>
<br>This still requires changes to the spec.
<br>
<br>The first is that main() is declared as extern "C", so having the overl=
oad=20
<br>there won't be possible.=20
<br>
<br>In function =E2=80=98int main(int, char**)=E2=80=99:
<br>error: declaration of C function =E2=80=98int main(int, char**)=E2=80=
=99 conflicts with
<br>error: previous declaration =E2=80=98int main(std::vector&lt;std::basic=
_<wbr>string&lt;char&gt; &gt;)=E2=80=99=20
<br>here
<br>
<br>The second is that the standard says you're not allowed to call main() =
or=20
<br>reference it in any way. But if you're already depending on the compile=
r=20
<br>specifics and the ABI for the weak linking, this should not be a proble=
m.=20
<br>However, the compiler may complain:
<br>
<br>warning: first argument of =E2=80=98int main(std::vector&lt;std::basic_=
<wbr>string&lt;char&gt; &gt;)=E2=80=99=20
<br>should be =E2=80=98int=E2=80=99 [-Wmain]
<br>warning: =E2=80=98int main(std::vector&lt;std::basic_<wbr>string&lt;cha=
r&gt; &gt;)=E2=80=99 takes only zero or=20
<br>two arguments [-Wmain]
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%=
3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhq=
Ln_62FW8ag';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNC=
Nanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - thiago (AT) <a href=
=3D"http://kde.org" target=3D"_blank" onmousedown=3D"this.href=3D'http://ww=
w.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQj=
CNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http:=
//www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">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></div>

<p></p>

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

------=_Part_732_17415547.1393962225035--

.

Sometimes you need to initialize devices (by writing values into HW registe=
rs, or invoking BSP functions) or even the memory before constructing any o=
bject at all. For example, the interrupt controller initialization.
(Sorry top-posting, it's a smartphone)
Enviado desde mi BlackBerry de Movistar (http://www.movistar.com.ar)

-----Original Message-----
From: Thiago Macieira <thiago@macieira.org>
Date: Tue, 04 Mar 2014 09:10:58=20
To: <std-proposals@isocpp.org>
Reply-To: std-proposals@isocpp.org
Subject: Re: [std-proposals] Modern main

Em ter 04 mar 2014, =E0s 13:45:43, Daniel Gutson escreveu:
>     virtual void global_ctors();
>     virtual void global_dtors();
> };
>=20
> Having a std ability to hook the moment before of calling the globals cto=
r
> list and the dtor counterpart would ease a lot embedded development.

Can't you replace the global_ctors() function by, you know, global=20
constructors? What's the benefit of having the virtual above?

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

--=20

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

--=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/.

.

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

On Tue, Mar 4, 2014 at 11:03 AM, Thiago Macieira <thiago@macieira.org>wrote=
:

> Em ter 04 mar 2014, =E0s 11:22:58, Matthew Woehlke escreveu:
> > On 2014-03-04 06:55, Alisdair Meredith wrote:
> > > My principle reason to start with 'initializer_list<char *>' is that =
it
> > > avoid entangling the language and library any further.  Currently, th=
e
> > > compiler is not expected to understand either 'vector', nor 'string',
> not
> > > 'basic_string<CharT, TraitsT, AllocatorT>', not how to combine them.
> >
> > That's readily solved by having the linker include a function from the
> > standard library as 'main' which has the "old" signature and invokes th=
e
> > user-supplied 'main' with the proposed signature. (In fact, I'm not sur=
e
> > the compiler needs to be - or even /should/ be - involved here at all.
> > Isn't handling of the entry-point already done by the linker?)
>
> Please note that the existing main() is extern "C" and therefore cannot
> have
> any overloads.
>
> I suggest finding a new name for this entry function.
>
> > For that matter, anyone could write that wrapper function, stick it in =
a
> > library, and have this functionality right now. Nor is the idea of
> > providing an executable's main() via a library which invokes other
> > well-known functions from the executable sources a novel idea; see e.g.
> > gtest for an example.
>
> See also 25 years of experience on Windows, with the entry point being
> WinMain() and that calls the user's main() function.
>
>
> Well, sort of but not really...  The entry point can be named *anything*,
the CRT however expects to find either a WinMain or a main, or a DllMain
depending on compiler flags -- which determine which runtime is linked in.
And it is not just a Windows thing.  You can change entry points on most
OSes to whatever you want as long as you handle what the system passes to
you for arguments.

Regardless of what C++ wants as an entry point, you start with what the OS
gives you.

Having said that, I don't have any problem with the standard C++ entry
point providing a const std::vector<const std::string> &args, or anything
else deemed better.  I would however prefer it be a function and not an
object.

--=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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Mar 4, 2014 at 11:03 AM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid">Em ter 04 mar 2014, =E0s 11:22:58, Matthew Woehlke escreve=
u:<br>

<div>&gt; On 2014-03-04 06:55, Alisdair Meredith wrote:<br>
&gt; &gt; My principle reason to start with &#39;initializer_list&lt;char *=
&gt;&#39; is that it<br>
&gt; &gt; avoid entangling the language and library any further. =A0Current=
ly, the<br>
&gt; &gt; compiler is not expected to understand either &#39;vector&#39;, n=
or &#39;string&#39;, not<br>
&gt; &gt; &#39;basic_string&lt;CharT, TraitsT, AllocatorT&gt;&#39;, not how=
 to combine them.<br>
&gt;<br>
&gt; That&#39;s readily solved by having the linker include a function from=
 the<br>
&gt; standard library as &#39;main&#39; which has the &quot;old&quot; signa=
ture and invokes the<br>
&gt; user-supplied &#39;main&#39; with the proposed signature. (In fact, I&=
#39;m not sure<br>
&gt; the compiler needs to be - or even /should/ be - involved here at all.=
<br>
&gt; Isn&#39;t handling of the entry-point already done by the linker?)<br>
<br>
</div>Please note that the existing main() is extern &quot;C&quot; and ther=
efore cannot have<br>
any overloads.<br>
<br>
I suggest finding a new name for this entry function.<br>
<div><br>
&gt; For that matter, anyone could write that wrapper function, stick it in=
 a<br>
&gt; library, and have this functionality right now. Nor is the idea of<br>
&gt; providing an executable&#39;s main() via a library which invokes other=
<br>
&gt; well-known functions from the executable sources a novel idea; see e.g=
..<br>
&gt; gtest for an example.<br>
<br>
</div>See also 25 years of experience on Windows, with the entry point bein=
g<br>
WinMain() and that calls the user&#39;s main() function.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span><br></bloc=
kquote><div>Well, sort of but not really...=A0 The entry point can be named=
 *anything*, the CRT however expects to find either a=A0WinMain or a main, =
or a DllMain depending on=A0compiler flags -- which determine which=A0runti=
me is linked in.=A0 And it is not just a Windows thing.=A0 You can change e=
ntry points on most OSes to whatever you want as long as you handle what th=
e system passes to you for arguments.</div>
<div><br></div><div>Regardless of what C++ wants as an entry point, you sta=
rt with what the OS gives you.</div><div><br></div><div>Having said that, I=
 don&#39;t have any problem with the standard C++ entry point providing a c=
onst std::vector&lt;const std::string&gt; &amp;args, or anything else deeme=
d better.=A0 I would however prefer it be a function and not an object.</di=
v>
</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 />

--001a11c2f4e60b847804f3cda952--

.

Em ter 04 mar 2014, =E0s 19:57:51, Daniel Gutson escreveu:
> Sometimes you need to initialize devices (by writing values into HW
> registers, or invoking BSP functions) or even the memory before
> constructing any object at all. For example, the interrupt controller
> initialization. (Sorry top-posting, it's a smartphone)

Understood, but if you're at that level, you often are writing very specifi=
c=20
code and you can write assembly or even rewrite your libc.

I would advise not doing what you suggest, though. It would be extremely ea=
sy=20
to use other global objects in global_ctors before they're initialised.

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

--=20

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

.

Em ter 04 mar 2014, =E0s 11:43:44, Andrew Tomazos escreveu:
> Yes, I actually fudged the example a little from what I actually=20
> implemented.  In the framework the function is called Main not main, so i=
t=20
> avoids the C linkage and other main symbol issues:
>=20
> int Main(std::vector<std::string> args);=20
>=20
> int main(int argc, char** argv) __attribute__((weak));=20
> int main(int argc, char** argv)=20
> {=20
>                   return Main(std::vector<string>(argv, argv+argc));=20
>=20
> }=20
>=20
> It has additional features beyond this, but this change should avoid both=
=20
> the C linking error and the calling main prohibition you raise.

That solves the problem neatly. Rename the function and most problems go aw=
ay.

The C++ standard already requires functions like ::operator new() to be=20
overridable by the application, so all platforms support overriding a libra=
ry=20
function in one way or another. Therefore, providing main() in the library=
=20
should be possible with minimal changes to the compiler.

In fact, the above can be done *very* easily in almost all platforms: just=
=20
create a static library containing your traditional main().

Just be careful that this library needs to be compiler-specific, since the=
=20
compiler is allowed to instrument the main function as it pleases (ICC does=
=20
that, even though it shares the ABI of the host compiler).

PS: it's argv+argc+1.

PPS: it would be better to use vector<string_view>, since that will avoid=
=20
allocating more memory for the actual argv parameters and it would also all=
ow=20
modifying the argv. On Linux, that will cause ps to change too. And if you =
go=20
for array_view with VLAs, no heap memory allocation would be necessary.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

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

.

I don't agree. In the same way there is the library writer and the applicat=
ion writer (or library user), in embedded development usually there is the =
BSP developer (in C, generally someone with electronic engineering backgrou=
nd), the application user, and the off-the-shelf libc library already writt=
en (e.g. Newlib). Devices initialization is not performed by the (generic) =
libc, but by the app by calling the BSP primitives (written in C).

And, regarding your point, currently there is the issue of using global obj=
ects from global ctors, I don't see the restriction of not using global obj=
ects from the hook a hard to accomplish one. (May I say it would be too obv=
ious? In embedded development there are lots of similar restrictions like t=
his, such as not using devices not initialized yet or doing stuff with irqs=
 disabled).
Enviado desde mi BlackBerry de Movistar (http://www.movistar.com.ar)

-----Original Message-----
From: Thiago Macieira <thiago@macieira.org>
Date: Tue, 04 Mar 2014 12:40:48=20
To: <std-proposals@isocpp.org>
Reply-To: std-proposals@isocpp.org
Subject: Re: [std-proposals] Modern main

Em ter 04 mar 2014, =E0s 19:57:51, Daniel Gutson escreveu:
> Sometimes you need to initialize devices (by writing values into HW
> registers, or invoking BSP functions) or even the memory before
> constructing any object at all. For example, the interrupt controller
> initialization. (Sorry top-posting, it's a smartphone)

Understood, but if you're at that level, you often are writing very specifi=
c=20
code and you can write assembly or even rewrite your libc.

I would advise not doing what you suggest, though. It would be extremely ea=
sy=20
to use other global objects in global_ctors before they're initialised.

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

--=20

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

--=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/.

.

--bcaec54858caf4075a04f3cf3ad2
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Mar 4, 2014 at 9:32 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 4 March 2014 19:16, Matthew Woehlke <mw_triad@users.sourceforge.net>
> wrote:
> > Folks... "main" IS NOT A C++ FUNCTION. It is a *C* function with C
> linkage
> > and calling convention.
>
> Just because it's extern "C" does not make it a C function.


Just because it can't be overloaded does not make it extern "C". The
standard does *not* say that main is extern "C".

From an implementation POV, I see no difficulties with giving main a
different signature. When we emit the code for main, we can generate code
to forward from the traditional signature to the new one. The language
linkage is not even relevant here.

That said, I don't really see that this is a problem worth solving. It
makes the language more complex (in a way that all C++ programmers will
need to know about) in exchange for a minor syntactic convenience.

--

---
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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Mar 4, 2014 at 9:32 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On 4 March 2014 19:16, Matthew Woehlke =
&lt;<a href=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw_=
triad@users.sourceforge.net</a>&gt; wrote:<br>


&gt; Folks... &quot;main&quot; IS NOT A C++ FUNCTION. It is a *C* function =
with C linkage<br>
&gt; and calling convention.<br>
<br>
</div>Just because it&#39;s extern &quot;C&quot; does not make it a C funct=
ion.</blockquote><div><br></div><div>Just because it can&#39;t be overloade=
d does not make it extern &quot;C&quot;. The standard does *not* say that m=
ain is extern &quot;C&quot;.</div>

<div><br></div><div>From an implementation POV, I see no difficulties with =
giving main a different signature. When we emit the code for main, we can g=
enerate code to forward from the traditional signature to the new one. The =
language linkage is not even relevant here.</div>

<div><br></div><div>That said, I don&#39;t really see that this is a proble=
m worth solving. It makes the language more complex (in a way that all C++ =
programmers will need to know about) in exchange for a minor syntactic conv=
enience.</div>

</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 />

--bcaec54858caf4075a04f3cf3ad2--

.

--Apple-Mail=_CA6687D9-A207-40D5-B82B-6F93F084E887
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On Mar 5, 2014, at 1:16 AM, Matthew Woehlke <mw_triad@users.sourceforge.net=
> wrote:

> On 2014-03-04 09:49, David Krauss wrote:
>>=20
>> Already the compiler must differentiate between the signatures
>> main()and main(char**,int), and push parameters accordingly.
>=20
> Really? I thought the system always supplied argc and argv, and main() is=
 simply free to ignore them. (And besides, I thought supplying of arguments=
 wasn't done by the compiler at all, but by whatever system code bootstraps=
 the executable?)

In C, main may be (but usually isn't) the global entry point called directl=
y by the OS. In C++, there's always a wrapper to handle static initializati=
on and destruction. If the signature of int main() is always hacked to int =
main(int,char**,char**), that's just an alternative special case. I'm just =
going by memory of what I've seen in GNU, which I haven't even verified.

> Folks... "main" IS NOT A C++ FUNCTION. It is a *C* function with C linkag=
e and calling convention.

That's not true; the language linkage of main is unspecified.

> The *only* useful change to the compiler to allow main() to take a more C=
++ signature is to change the current behavior that *anything* named "main"=
 has C linkage.

Nothing prohibits C linkage functions from taking C++ parameters. They just=
 don't get name mangling, i.e. there may be no collision of names with C la=
nguage linkage. (The rule is specified separately for main because it is no=
t C linkage.)

> If anything happens here, there are two options:
>=20
> 1. Change the compiler to *generate* a "main" thunk with C linkage having=
 the signature 'int main(int argc, char** argv)' that performs whatever tra=
nsformations are necessary to invoke the "new" signature (terrible idea IMH=
O).

This is essentially what I proposed. Except it doesn't need to have linkage=
 beyond the fact of integrating with the linker such that it gets called by=
 __sinit or whatever.

--=20

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

--Apple-Mail=_CA6687D9-A207-40D5-B82B-6F93F084E887
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Mar 5=
, 2014, at 1:16 AM, Matthew Woehlke &lt;<a href=3D"mailto:mw_triad@users.so=
urceforge.net">mw_triad@users.sourceforge.net</a>&gt; wrote:</div><br class=
=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div style=3D"font=
-size: 12px; font-style: normal; font-variant: normal; font-weight: normal;=
 letter-spacing: normal; line-height: normal; orphans: auto; text-align: st=
art; text-indent: 0px; text-transform: none; white-space: normal; widows: a=
uto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On 2014-03-04 09:4=
9, David Krauss wrote:<br><blockquote type=3D"cite"><br>Already the compile=
r must differentiate between the signatures<br>main()and main(char**,int), =
and push parameters accordingly.<br></blockquote><br>Really? I thought the =
system always supplied argc and argv, and main() is simply free to ignore t=
hem. (And besides, I thought supplying of arguments wasn't done by the comp=
iler at all, but by whatever system code bootstraps the executable?)<br></d=
iv></blockquote><div><br></div><div>In C, main may be (but usually isn&rsqu=
o;t) the global entry point called directly by the OS. In C++, there&rsquo;=
s always a wrapper to handle static initialization and destruction. If the =
signature of <font face=3D"Courier">int main()</font> is always hacked to <=
font face=3D"Courier">int main(int,char**,char**)</font>, that&rsquo;s just=
 an alternative special case. I&rsquo;m just going by memory of what I&rsqu=
o;ve seen in GNU, which I haven&rsquo;t even verified.</div><br><blockquote=
 type=3D"cite"><div style=3D"font-size: 12px; font-style: normal; font-vari=
ant: normal; font-weight: normal; letter-spacing: normal; line-height: norm=
al; orphans: auto; text-align: start; text-indent: 0px; text-transform: non=
e; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-strok=
e-width: 0px;">Folks... "main" IS NOT A C++ FUNCTION. It is a *C* function =
with C linkage and calling convention.<br></div></blockquote><div><br></div=
><div>That&rsquo;s not true; the language linkage of main is unspecified.</=
div><br><blockquote type=3D"cite"><div style=3D"font-size: 12px; font-style=
: normal; font-variant: normal; font-weight: normal; letter-spacing: normal=
; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: 0px;=
 -webkit-text-stroke-width: 0px;">The *only* useful change to the compiler =
to allow main() to take a more C++ signature is to change the current behav=
ior that *anything* named "main" has C linkage.<br></div></blockquote><div>=
<br></div><div>Nothing prohibits C linkage functions from taking C++ parame=
ters. They just don&rsquo;t get name mangling, i.e. there may be no collisi=
on of names with C language linkage. (The rule is specified separately for =
main because it is not C linkage.)</div><br><blockquote type=3D"cite"><div =
style=3D"font-size: 12px; font-style: normal; font-variant: normal; font-we=
ight: normal; letter-spacing: normal; line-height: normal; orphans: auto; t=
ext-align: start; text-indent: 0px; text-transform: none; white-space: norm=
al; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">If an=
ything happens here, there are two options:<br><br>1. Change the compiler t=
o *generate* a "main" thunk with C linkage having the signature 'int main(i=
nt argc, char** argv)' that performs whatever transformations are necessary=
 to invoke the "new" signature (terrible idea IMHO).<br></div></blockquote>=
<div><br></div><div>This is essentially what I proposed. Except it doesn&rs=
quo;t need to have linkage beyond the fact of integrating with the linker s=
uch that it gets called by <font face=3D"Courier">__sinit</font> or whateve=
r.</div></div><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 />

--Apple-Mail=_CA6687D9-A207-40D5-B82B-6F93F084E887--

.

On 2014-03-04 17:14, Richard Smith wrote:
> On Tue, Mar 4, 2014 at 9:32 AM, Ville Voutilainen wrote:
>> On 4 March 2014 19:16, Matthew Woehlke wrote:
>>> Folks... "main" IS NOT A C++ FUNCTION. It is a *C* function with C
>>> linkage and calling convention.
>>
>> Just because it's extern "C" does not make it a C function.
>
> Just because it can't be overloaded does not make it extern "C". The
> standard does *not* say that main is extern "C".

This may be a detail of the operating system, in which case the language=20
standard isn't governing anyway. Maybe the above is even not true for=20
some OS.

But on Linux...:

   $ nm foo.o
   0000000000000009 T main
   0000000000000000 T _Z3fooi

(Caveat: I didn't inspect the assembly to verify the argument packing,=20
though I am not sure this is actually affected by the language?)


Also, while fiddling around trying to overload it anyway, I caused this:

   int main() {...} // yes, this is the complete declaration

....to generate the error:

   error: declaration of C function =E2=80=98int main()=E2=80=99 conflicts =
with <other>


Standard or not, it *is* a "C" declared function. (On Linux/ELF anyway.)

....which is of course why it can't be overloaded; doing so would cause a=20
symbol name collision :-).

> From an implementation POV, I see no difficulties with giving main a
> different signature.

The OS must be able to start the application. To do so (correctly), the=20
mechanism for invoking main() must be consistent. This isn't even a=20
language (C++) thing, it is a platform ABI thing.

> When we emit the code for main, we can generate code to forward from
> the traditional signature to the new one. The language linkage is not
> even relevant here.

But then you aren't "changing" the signature of main(), you're adding a=20
feature where the compiler (or linker) generates/includes/links a thunk=20
(which must conform to the platform ABI!) to call a main-like function=20
with a non-ABI-conforming signature. And sure, that's not terribly hard=20
(if you don't try to call it "main" anyway; else teaching the compiler=20
not to apply the current special handling for that name might get=20
tricky) and the "main-like function" can have whatever ABI it wants.

--=20
Matthew

--=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-03-04 19:18, David Krauss wrote:
> On Mar 5, 2014, at 1:16 AM, Matthew Woehlke wrote:
>> 1. Change the compiler to *generate* a "main" thunk with C linkage having the signature 'int main(int argc, char** argv)' that performs whatever transformations are necessary to invoke the "new" signature (terrible idea IMHO).
>
> This is essentially what I proposed. Except it doesn't need to have linkage beyond the fact of integrating with the linker such that it gets called by __sinit or whatever.

....but then you'd have to change the linker also. And if you do that,
you might as well go with option (2) where the changes are primarily or
exclusively in the linker.

IMHO option (2) makes much more sense. It makes it easier to provide
more than one option for the signature (compiler can remain blissfully
ignorant, linker just matches a mangled symbol name to the appropriate
thunk), and also sets precedent for some other language to do something
similar.

--
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/.

.

--047d7b3395add8200404f3d17d50
Content-Type: text/plain; charset=ISO-8859-1

This is the kind of discussion I would have no idea about. I can't see what
the big problem with option (1) is. It would essentially be equivalent to
the compiler renaming the new main function to some internal name and
providing a traditional main function that performs the appropriate
transformation and passes the arguments to the renamed function. Why would
this involve any changes to the linker? The linker would still be hooking
up the same old entry point.


On 5 March 2014 00:44, Matthew Woehlke <mw_triad@users.sourceforge.net>wrote:

> On 2014-03-04 19:18, David Krauss wrote:
>
>  On Mar 5, 2014, at 1:16 AM, Matthew Woehlke wrote:
>>
>>> 1. Change the compiler to *generate* a "main" thunk with C linkage
>>> having the signature 'int main(int argc, char** argv)' that performs
>>> whatever transformations are necessary to invoke the "new" signature
>>> (terrible idea IMHO).
>>>
>>
>> This is essentially what I proposed. Except it doesn't need to have
>> linkage beyond the fact of integrating with the linker such that it gets
>> called by __sinit or whatever.
>>
>
> ...but then you'd have to change the linker also. And if you do that, you
> might as well go with option (2) where the changes are primarily or
> exclusively in the linker.
>
> IMHO option (2) makes much more sense. It makes it easier to provide more
> than one option for the signature (compiler can remain blissfully ignorant,
> linker just matches a mangled symbol name to the appropriate thunk), and
> also sets precedent for some other language to do something similar.
>
> --
> Matthew
>
>
> --
>
> --- 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/FMAAdCVGiZU/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/.
>

--

---
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/.

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

<div dir=3D"ltr">This is the kind of discussion I would have no idea about.=
 I can&#39;t see what the big problem with option (1) is. It would essentia=
lly be equivalent to the compiler renaming the new main function to some in=
ternal name and providing a traditional main function that performs the app=
ropriate transformation and passes the arguments to the renamed function. W=
hy would this involve any changes to the linker? The linker would still be =
hooking up the same old entry point.</div>

<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 5 March 20=
14 00:44, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=3D"mailto:mw_triad@=
users.sourceforge.net" target=3D"_blank">mw_triad@users.sourceforge.net</a>=
&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On 2014-03-04 19:18, David Krauss wrote:<div=
 class=3D""><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Mar 5, 2014, at 1:16 AM, Matthew Woehlke wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
1. Change the compiler to *generate* a &quot;main&quot; thunk with C linkag=
e having the signature &#39;int main(int argc, char** argv)&#39; that perfo=
rms whatever transformations are necessary to invoke the &quot;new&quot; si=
gnature (terrible idea IMHO).<br>


</blockquote>
<br>
This is essentially what I proposed. Except it doesn&#39;t need to have lin=
kage beyond the fact of integrating with the linker such that it gets calle=
d by __sinit or whatever.<br>
</blockquote>
<br></div>
....but then you&#39;d have to change the linker also. And if you do that, y=
ou might as well go with option (2) where the changes are primarily or excl=
usively in the linker.<br>
<br>
IMHO option (2) makes much more sense. It makes it easier to provide more t=
han one option for the signature (compiler can remain blissfully ignorant, =
linker just matches a mangled symbol name to the appropriate thunk), and al=
so sets precedent for some other language to do something similar.<span cla=
ss=3D"HOEnZb"><font color=3D"#888888"><br>


<br>
-- <br>
Matthew</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to a topic in the =
Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/FMAAdCVGiZU/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<u></u>isocpp.org/d/topic/std-<u></u>proposa=
ls/FMAAdCVGiZU/<u></u>unsubscribe</a>.<br>


To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></blockquote></div><br></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 />

--047d7b3395add8200404f3d17d50--

.

--20cf3033474150e04004f3d2077e
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Mar 4, 2014 at 4:36 PM, Matthew Woehlke <
mw_triad@users.sourceforge.net> wrote:

> On 2014-03-04 17:14, Richard Smith wrote:
>
>> On Tue, Mar 4, 2014 at 9:32 AM, Ville Voutilainen wrote:
>>
>>  On 4 March 2014 19:16, Matthew Woehlke wrote:
>>>
>>>> Folks... "main" IS NOT A C++ FUNCTION. It is a *C* function with C
>>>> linkage and calling convention.
>>>>
>>>
>>> Just because it's extern "C" does not make it a C function.
>>>
>>
>> Just because it can't be overloaded does not make it extern "C". The
>> standard does *not* say that main is extern "C".
>>
>
> This may be a detail of the operating system, in which case the language
> standard isn't governing anyway. Maybe the above is even not true for some
> OS.
>
> But on Linux...:
>
>   $ nm foo.o
>   0000000000000009 T main
>   0000000000000000 T _Z3fooi
>
> (Caveat: I didn't inspect the assembly to verify the argument packing,
> though I am not sure this is actually affected by the language?)
>

The mangled name of 'main' is 'main', because that's what the ABI demands.
That does not imply that main is extern "C".

Also, while fiddling around trying to overload it anyway, I caused this:
>
>   int main() {...} // yes, this is the complete declaration
>
> ...to generate the error:
>
>   error: declaration of C function 'int main()' conflicts with <other>
>
>
> Standard or not, it *is* a "C" declared function. (On Linux/ELF anyway.)
>

Maybe in GCC. Not in the standard, not in Clang, and not in EDG.


> ...which is of course why it can't be overloaded; doing so would cause a
> symbol name collision :-).


It can't be overloaded because we wouldn't be able to pick which one to
call on program startup. It would be trivial for implementations to avoid a
symbol collision.


>  From an implementation POV, I see no difficulties with giving main a
>> different signature.
>>
>
> The OS must be able to start the application. To do so (correctly), the
> mechanism for invoking main() must be consistent. This isn't even a
> language (C++) thing, it is a platform ABI thing.


I explained how to do it:


>  When we emit the code for main, we can generate code to forward from
>> the traditional signature to the new one. The language linkage is not
>> even relevant here.
>>
>
> But then you aren't "changing" the signature of main(), you're adding a
> feature where the compiler (or linker) generates/includes/links a thunk
> (which must conform to the platform ABI!) to call a main-like function with
> a non-ABI-conforming signature. And sure, that's not terribly hard (if you
> don't try to call it "main" anyway; else teaching the compiler not to apply
> the current special handling for that name might get tricky) and the
> "main-like function" can have whatever ABI it wants.


I don't think you understand. We can trivially accept this:

int main(std::vector<std::string> args) {
  ...
}

.... and generate code for 'main' that accepts an int and a char**,
constructs the parameter, and then runs the body of the function. No thunk
is generated; we just generate more code for 'main'.

--

---
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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Mar 4, 2014 at 4:36 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw_triad@users=
..sourceforge.net</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On 2014-03-04 17:14, Richard Smith wrote:<br=
>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Tue, Mar 4, 2014 at 9:32 AM, Ville Voutilainen wrote:<div class=3D""><br=
>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 4 March 2014 19:16, Matthew Woehlke wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Folks... &quot;main&quot; IS NOT A C++ FUNCTION. It is a *C* function with =
C<br>
linkage and calling convention.<br>
</blockquote>
<br>
Just because it&#39;s extern &quot;C&quot; does not make it a C function.<b=
r>
</blockquote>
<br>
Just because it can&#39;t be overloaded does not make it extern &quot;C&quo=
t;. The<br>
standard does *not* say that main is extern &quot;C&quot;.<br>
</div></blockquote>
<br>
This may be a detail of the operating system, in which case the language st=
andard isn&#39;t governing anyway. Maybe the above is even not true for som=
e OS.<br>
<br>
But on Linux...:<br>
<br>
&nbsp; $ nm foo.o<br>
&nbsp; 0000000000000009 T main<br>
&nbsp; 0000000000000000 T _Z3fooi<br>
<br>
(Caveat: I didn&#39;t inspect the assembly to verify the argument packing, =
though I am not sure this is actually affected by the language?)<br></block=
quote><div><br></div><div>The mangled name of &#39;main&#39; is &#39;main&#=
39;, because that&#39;s what the ABI demands. That does not imply that main=
 is extern &quot;C&quot;.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
Also, while fiddling around trying to overload it anyway, I caused this:<br=
>
<br>
&nbsp; int main() {...} // yes, this is the complete declaration<br>
<br>
....to generate the error:<br>
<br>
&nbsp; error: declaration of C function &lsquo;int main()&rsquo; conflicts =
with &lt;other&gt;<br>
<br>
<br>
Standard or not, it *is* a &quot;C&quot; declared function. (On Linux/ELF a=
nyway.)<br></blockquote><div><br></div><div>Maybe in GCC. Not in the standa=
rd, not in Clang, and not in EDG.</div><div>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

....which is of course why it can&#39;t be overloaded; doing so would cause =
a symbol name collision :-).</blockquote><div><br></div><div>It can&#39;t b=
e overloaded because we wouldn&#39;t be able to pick which one to call on p=
rogram startup. It would be trivial for implementations to avoid a symbol c=
ollision.</div>
<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
From an implementation POV, I see no difficulties with giving main a<br>
different signature.<br>
</blockquote>
<br></div>
The OS must be able to start the application. To do so (correctly), the mec=
hanism for invoking main() must be consistent. This isn&#39;t even a langua=
ge (C++) thing, it is a platform ABI thing.</blockquote><div><br></div>
<div>I explained how to do it:</div><div>&nbsp;</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div class=3D"">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
When we emit the code for main, we can generate code to forward from<br>
the traditional signature to the new one. The language linkage is not<br>
even relevant here.<br>
</blockquote>
<br></div>
But then you aren&#39;t &quot;changing&quot; the signature of main(), you&#=
39;re adding a feature where the compiler (or linker) generates/includes/li=
nks a thunk (which must conform to the platform ABI!) to call a main-like f=
unction with a non-ABI-conforming signature. And sure, that&#39;s not terri=
bly hard (if you don&#39;t try to call it &quot;main&quot; anyway; else tea=
ching the compiler not to apply the current special handling for that name =
might get tricky) and the &quot;main-like function&quot; can have whatever =
ABI it wants.</blockquote>
<div><br></div><div>I don&#39;t think you understand. We can trivially acce=
pt this:</div><div><br></div><div>int main(std::vector&lt;std::string&gt; a=
rgs) {</div><div>&nbsp; ...</div><div>}</div><div><br></div><div>... and ge=
nerate code for &#39;main&#39; that accepts an int and a char**, constructs=
 the parameter, and then runs the body of the function. No thunk is generat=
ed; we just generate more code for &#39;main&#39;.</div>
</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 />

--20cf3033474150e04004f3d2077e--

.

Em ter 04 mar 2014, =E0s 17:34:58, Richard Smith escreveu:
> > (Caveat: I didn't inspect the assembly to verify the argument packing,
> > though I am not sure this is actually affected by the language?)
>=20
> The mangled name of 'main' is 'main', because that's what the ABI demands=
..
> That does not imply that main is extern "C".

The C++ standard does not define what the external names should be. And in =
the=20
specific case of main, since it cannot be called by C++ or have its address=
=20
taken in C++ code, it doesn't have to even generate an external symbol. If =
it=20
does, it doesn't have to be the same as the C symbol would be.

It just so happens that, for ease of implementation in most ABIs, the symbo=
l=20
for C and for C++ are the same.

> > Standard or not, it *is* a "C" declared function. (On Linux/ELF anyway.=
)
>=20
> Maybe in GCC. Not in the standard, not in Clang, and not in EDG.

Even GCC treats it specially, since it allows exactly two possible signatur=
es=20
and none else.

> I don't think you understand. We can trivially accept this:
>=20
> int main(std::vector<std::string> args) {
>   ...
> }
>=20
> ... and generate code for 'main' that accepts an int and a char**,
> constructs the parameter, and then runs the body of the function. No thun=
k
> is generated; we just generate more code for 'main'.

That is true. Since main is special anyway, the compiler *can* accept the=
=20
main() above, but emit instead:

int main(int argc, char **argv)
{
 std::vector<std::string> args(argv, argv+argc+1);
 // rest of main goes here
}

That said, I don't think we should go down that route. It's a lot easier to=
=20
just add a Main with capital M that can be implemented as a library=20
functionality than to make changes to the compilers and make it understand =
how=20
to create std::vector and std::string.

Moreover, I highly recommend that the chosen solution be noexcept. It would=
 be=20
really, really inconvenient if the launched program never reached the user'=
s=20
first line if an exception got thrown by the runtime...

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

--=20

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

.

------=_Part_149_5942370.1394002915926
Content-Type: text/plain; charset=UTF-8

On Wednesday, March 5, 2014 2:53:18 AM UTC+1, Thiago Macieira wrote:

> PS: it's argv+argc+1.



int main(int argc, char **argv)
> {
>         std::vector<std::string> args(argv, argv+argc+1);
>         // rest of main goes here
> }
>

Why did you add +1?  I think it was correct as vector<string>(argv,
argv+argc)

--

---
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_149_5942370.1394002915926
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, March 5, 2014 2:53:18 AM UTC+1, Thiago Macie=
ira wrote:<div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0=
px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); bo=
rder-left-style: solid; padding-left: 1ex;">PS: it's argv+argc+1.&nbsp;</bl=
ockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8=
ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-l=
eft-style: solid; padding-left: 1ex;">&nbsp;</blockquote><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">int main(int argc, char **argv)
<br>{
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;std::vector&lt;std::<wb=
r>string&gt; args(argv, argv+argc+1);
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// rest of main goes he=
re
<br>}
<br>
</blockquote><div><br></div><div>Why did you add +1? &nbsp;I think it was c=
orrect as vector&lt;string&gt;(argv, argv+argc)</div><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 />

------=_Part_149_5942370.1394002915926--

.

Em ter 04 mar 2014, =E0s 23:01:55, Andrew Tomazos escreveu:
> On Wednesday, March 5, 2014 2:53:18 AM UTC+1, Thiago Macieira wrote:
> > PS: it's argv+argc+1.
>=20
> int main(int argc, char **argv)
>=20
> > {
> >=20
> >         std::vector<std::string> args(argv, argv+argc+1);
> >         // rest of main goes here
> >=20
> > }
>=20
> Why did you add +1?  I think it was correct as vector<string>(argv,
> argv+argc)

Oops, I always get confused whether argv[0] is counted as a program argumen=
t.

My bad.

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

--=20

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

.

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

Le mercredi 5 mars 2014 02:53:18 UTC+1, Thiago Macieira a =C3=A9crit :
>
> Em ter 04 mar 2014, =C3=A0s 17:34:58, Richard Smith escreveu:=20
> > > (Caveat: I didn't inspect the assembly to verify the argument packing=
,=20
> > > though I am not sure this is actually affected by the language?)=20
> >=20
> > The mangled name of 'main' is 'main', because that's what the ABI=20
> demands.=20
> > That does not imply that main is extern "C".=20
>
> The C++ standard does not define what the external names should be. And i=
n=20
> the=20
> specific case of main, since it cannot be called by C++ or have its=20
> address=20
> taken in C++ code, it doesn't have to even generate an external symbol. I=
f=20
> it=20
> does, it doesn't have to be the same as the C symbol would be.=20
>
> It just so happens that, for ease of implementation in most ABIs, the=20
> symbol=20
> for C and for C++ are the same.=20
>
> > > Standard or not, it *is* a "C" declared function. (On Linux/ELF=20
> anyway.)=20
> >=20
> > Maybe in GCC. Not in the standard, not in Clang, and not in EDG.=20
>
> Even GCC treats it specially, since it allows exactly two possible=20
> signatures=20
> and none else.=20
>
> > I don't think you understand. We can trivially accept this:=20
> >=20
> > int main(std::vector<std::string> args) {=20
> >   ...=20
> > }=20
> >=20
> > ... and generate code for 'main' that accepts an int and a char**,=20
> > constructs the parameter, and then runs the body of the function. No=20
> thunk=20
> > is generated; we just generate more code for 'main'.=20
>
> That is true. Since main is special anyway, the compiler *can* accept the=
=20
> main() above, but emit instead:=20
>
> int main(int argc, char **argv)=20
> {=20
>         std::vector<std::string> args(argv, argv+argc+1);=20
>         // rest of main goes here=20
> }=20
>
> That said, I don't think we should go down that route. It's a lot easier=
=20
> to=20
> just add a Main with capital M that can be implemented as a library=20
> functionality than to make changes to the compilers and make it understan=
d=20
> how=20
> to create std::vector and std::string.=20
>

Why do we have to teach the compiler about std::vector and std::string.=20
 Just have

    int main(Foo args) {
       blah
    }=20

be compiled as

   int main(int __argc, int __argv) {
      Foo args(__argv, __argv+__argc);
      { blah }
   }

and let the user provide declarations for what is needed.  If I'm not=20
mistaken, it will allows std::vector<std::string>,=20
std::deque<std::string_view>, most of what it reasonable and provide an=20
hook point for a standard argument handling class in the future without=20
having to tweak this part again.

Note: __argv[__argc] is a null pointer, I think passing it doesn't worth=20
the trouble.

Yours

--=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_696_26987939.1394027586124
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Le mercredi 5 mars 2014 02:53:18 UTC+1, Thiago Macieira a =
=C3=A9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em ter 04 mar=
 2014, =C3=A0s 17:34:58, Richard Smith escreveu:
<br>&gt; &gt; (Caveat: I didn't inspect the assembly to verify the argument=
 packing,
<br>&gt; &gt; though I am not sure this is actually affected by the languag=
e?)
<br>&gt;=20
<br>&gt; The mangled name of 'main' is 'main', because that's what the ABI =
demands.
<br>&gt; That does not imply that main is extern "C".
<br>
<br>The C++ standard does not define what the external names should be. And=
 in the=20
<br>specific case of main, since it cannot be called by C++ or have its add=
ress=20
<br>taken in C++ code, it doesn't have to even generate an external symbol.=
 If it=20
<br>does, it doesn't have to be the same as the C symbol would be.
<br>
<br>It just so happens that, for ease of implementation in most ABIs, the s=
ymbol=20
<br>for C and for C++ are the same.
<br>
<br>&gt; &gt; Standard or not, it *is* a "C" declared function. (On Linux/E=
LF anyway.)
<br>&gt;=20
<br>&gt; Maybe in GCC. Not in the standard, not in Clang, and not in EDG.
<br>
<br>Even GCC treats it specially, since it allows exactly two possible sign=
atures=20
<br>and none else.
<br>
<br>&gt; I don't think you understand. We can trivially accept this:
<br>&gt;=20
<br>&gt; int main(std::vector&lt;std::string&gt; args) {
<br>&gt; &nbsp; ...
<br>&gt; }
<br>&gt;=20
<br>&gt; ... and generate code for 'main' that accepts an int and a char**,
<br>&gt; constructs the parameter, and then runs the body of the function. =
No thunk
<br>&gt; is generated; we just generate more code for 'main'.
<br>
<br>That is true. Since main is special anyway, the compiler *can* accept t=
he=20
<br>main() above, but emit instead:
<br>
<br>int main(int argc, char **argv)
<br>{
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;std::vector&lt;std::<wb=
r>string&gt; args(argv, argv+argc+1);
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// rest of main goes he=
re
<br>}
<br>
<br>That said, I don't think we should go down that route. It's a lot easie=
r to=20
<br>just add a Main with capital M that can be implemented as a library=20
<br>functionality than to make changes to the compilers and make it underst=
and how=20
<br>to create std::vector and std::string.
<br></blockquote><div><br></div><div>Why do we have to teach the compiler a=
bout std::vector and std::string. &nbsp;Just have</div><div><br></div><div>=
&nbsp; &nbsp; int main(Foo args) {</div><div>&nbsp; &nbsp; &nbsp; &nbsp;bla=
h</div><div>&nbsp; &nbsp; }&nbsp;</div><div><br></div><div>be compiled as</=
div><div><br></div><div>&nbsp; &nbsp;int main(int __argc, int __argv) {</di=
v><div>&nbsp; &nbsp; &nbsp; Foo args(__argv, __argv+__argc);</div><div>&nbs=
p; &nbsp; &nbsp; { blah }</div><div>&nbsp; &nbsp;}</div><div><br></div><div=
>and let the user provide declarations for what is needed. &nbsp;If I'm not=
 mistaken, it will allows std::vector&lt;std::string&gt;, std::deque&lt;std=
::string_view&gt;, most of what it reasonable and provide an hook point for=
 a standard argument handling class in the future without having to tweak t=
his part again.</div><div><br></div><div>Note: __argv[__argc] is a null poi=
nter, I think passing it doesn't worth the trouble.</div><div><br></div><di=
v>Yours</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_696_26987939.1394027586124--

.

On Tue, Mar 4, 2014 at 10:53 PM, Thiago Macieira <thiago@macieira.org> wrot=
e:
> Em ter 04 mar 2014, =E0s 17:34:58, Richard Smith escreveu:

[snip]

> That said, I don't think we should go down that route. It's a lot easier =
to
> just add a Main with capital M that can be implemented as a library
> functionality than to make changes to the compilers and make it understan=
d how
> to create std::vector and std::string.

Which other function in the C++ standard starts with a capital letter?

Regards,
--=20
Felipe Magno de Almeida

--=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 Wed, Mar 5, 2014 at 10:53 AM, Jean-Marc Bourguet
<jm.bourguet@gmail.com> wrote:
> Le mercredi 5 mars 2014 02:53:18 UTC+1, Thiago Macieira a =E9crit :

[snip]

> Why do we have to teach the compiler about std::vector and std::string.

There's also the problem with freestanding implementations that don't
have std::vector and std::string.

> Just have
>
>     int main(Foo args) {
>        blah
>     }
>
> be compiled as
>
>    int main(int __argc, int __argv) {
>       Foo args(__argv, __argv+__argc);
>       { blah }
>    }
>
> and let the user provide declarations for what is needed.  If I'm not
> mistaken, it will allows std::vector<std::string>,
> std::deque<std::string_view>, most of what it reasonable and provide an h=
ook
> point for a standard argument handling class in the future without having=
 to
> tweak this part again.
>
> Note: __argv[__argc] is a null pointer, I think passing it doesn't worth =
the
> trouble.

It would be UB to pass the null pointer for constructing a std::string
and I think
it will be UB for string_view as well without a length argument.

> Yours

Regards,
--=20
Felipe Magno de Almeida

--=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/.

.

Em qua 05 mar 2014, =E0s 12:57:14, Felipe Magno de Almeida escreveu:
> On Tue, Mar 4, 2014 at 10:53 PM, Thiago Macieira <thiago@macieira.org>=20
wrote:
> > Em ter 04 mar 2014, =E0s 17:34:58, Richard Smith escreveu:
> [snip]
>=20
> > That said, I don't think we should go down that route. It's a lot easie=
r
> > to
> > just add a Main with capital M that can be implemented as a library
> > functionality than to make changes to the compilers and make it underst=
and
> > how to create std::vector and std::string.
>=20
> Which other function in the C++ standard starts with a capital letter?

As far as I know, none. This could be the first.

Or we can find another name for it, as long as it's different from "main".

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

--=20

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

.

On 2014-03-04 20:34, Richard Smith wrote:
> I don't think you understand. We can trivially accept this:
>
> int main(std::vector<std::string> args) {
>    ...
> }
>
> ... and generate code for 'main' that accepts an int and a char**,
> constructs the parameter, and then runs the body of the function. No thunk
> is generated; we just generate more code for 'main'.

Er... yes. That's a thunk. One that inlines the wrapped function,
perhaps, but in my book it's still a thunk; a small segment of code
whose purpose is to adapt a set of arguments for a similar interface
taking a different set of arguments.

The point is that the externally visible signature of main hasn't
changed. The rest is arguing semantics, which I am sick of doing.

--
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-03-05 08:53, Jean-Marc Bourguet wrote:
> Why do we have to teach the compiler about std::vector and std::string.
>   Just have
>
>      int main(Foo args) {
>         blah
>      }
>
> be compiled as
>
>     int main(int __argc, int __argv) {
>        Foo args(__argv, __argv+__argc);
>        { blah }
>     }
>
> and let the user provide declarations for what is needed.

Hmm... that would actually allow me to write:

int main(qtCliArgs args)
{
   ...
}

....so I could live with that :-).

--
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-03-04 19:56, Joseph Mansfield wrote:
> This is the kind of discussion I would have no idea about. I can't see what
> the big problem with option (1) is. It would essentially be equivalent to
> the compiler renaming the new main function to some internal name and
> providing a traditional main function that performs the appropriate
> transformation and passes the arguments to the renamed function. Why would
> this involve any changes to the linker? The linker would still be hooking
> up the same old entry point.

Sorry, I think I was confused... you are right; forget my previous
comments :-).

My main concern with (1) is with the level of difficulty for the
compiler to determine what code must be generated. If as in Jean-Marc's
proposal it is required that the "new" signature be of the form:

   int main(ArgType arg_identifier)

....where ArgType must have a ctor taking (char**, char**), then this
makes thing much easier.

(That said, however... what about passing in the environment? We should
probably at least have a plan how that could be implemented in the
future without breaking the args-only case.)

--
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/.

.

Em qua 05 mar 2014, =E0s 11:54:09, Matthew Woehlke escreveu:
> On 2014-03-05 08:53, Jean-Marc Bourguet wrote:
> > Why do we have to teach the compiler about std::vector and std::string.
> >=20
> >   Just have
> >  =20
> >      int main(Foo args) {
> >         blah
> >      }
> >=20
> > be compiled as
> >=20
> >     int main(int __argc, int __argv) {
> >        Foo args(__argv, __argv+__argc);
> >        { blah }
> >     }
> >=20
> > and let the user provide declarations for what is needed.

Please make it instead:

 int main(int __argc, char **__argv)
 {
  Foo args(argc, argv);
  { blah; }
 }

This is far more logical. And it also allows for:

> Hmm... that would actually allow me to write:
>=20
> int main(qtCliArgs args)
> {
>    ...
> }
>=20
> ...so I could live with that :-).

int main(QCoreApplication app)
{
 ...
}


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

--=20

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

.

On 2014-03-05 12:10, Thiago Macieira wrote:
> On 2014-03-05 08:53, Jean-Marc Bourguet wrote:
>> Why do we have to teach the compiler about std::vector and std::string.
>>
>>    Just have
>>
>>       int main(Foo args) {
>>          blah
>>       }
>>
>> be compiled as
>>
>>      int main(int __argc, int __argv) {
>>         Foo args(__argv, __argv+__argc);
>>         { blah }
>>      }
>>
>> and let the user provide declarations for what is needed.
>
> Please make it instead:
>
>  int main(int __argc, char **__argv)
>  {
>   Foo args(argc, argv);
>   { blah; }
>  }
>
> This is far more logical.

While that may be true for the (argc, argv) case, unfortunately classes
that currently take (begin, end) (e.g. std::vector) could not be used
without adding a ctor that takes (size, begin). And I suspect those are
unusual (with (begin, size) being more prevalent after the STL way).

Better would be if the compiler could somehow deduce what flavor of ctor
to invoke, but I'd be suspicious of how reliable that would be. Maybe if
there is some way to tell it?

> And it also allows for:
> int main(QCoreApplication app)
> {
>  ...
> }

(Actually I realized I would need to add an additional ctor to
qtCliArgs, for similar reasons, but that's tolerable.)

--
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/.

.

Em qua 05 mar 2014, =E0s 12:47:49, Matthew Woehlke escreveu:
> While that may be true for the (argc, argv) case, unfortunately classes=
=20
> that currently take (begin, end) (e.g. std::vector) could not be used=20
> without adding a ctor that takes (size, begin). And I suspect those are=
=20
> unusual (with (begin, size) being more prevalent after the STL way).

Using std::vector<std::string> is a waste of resources anyway. It will=20
allocate memory for the vector and for each of the arguments. The procedure=
=20
can be done without memory allocation or, at most, allocating a new vector =
on=20
the stack only.

So I really don't consider std::vector to be a benchmark here.

Show me a solution using Standard Library classes that occupies zero bytes =
in=20
the heap and I'll be more inclined to agree.

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

--=20

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

.

--047d7bd6bd760fe90804f3dfeca2
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Mar 5, 2014 at 8:47 AM, Matthew Woehlke <
mw_triad@users.sourceforge.net> wrote:

> On 2014-03-04 20:34, Richard Smith wrote:
>
>> I don't think you understand. We can trivially accept this:
>>
>> int main(std::vector<std::string> args) {
>>    ...
>> }
>>
>> ... and generate code for 'main' that accepts an int and a char**,
>> constructs the parameter, and then runs the body of the function. No thunk
>> is generated; we just generate more code for 'main'.
>>
>
> Er... yes. That's a thunk. One that inlines the wrapped function, perhaps,
> but in my book it's still a thunk; a small segment of code whose purpose is
> to adapt a set of arguments for a similar interface taking a different set
> of arguments.
>
> The point is that the externally visible signature of main hasn't changed.
> The rest is arguing semantics, which I am sick of doing.


 OK, so... what's your point? I've demonstrated that this *is* possible,
and doesn't require us to pick a different name for 'main', and doesn't
break the ABI. You seem to be saying that this is somehow not OK since it
doesn't change the "signature" of main, but that's not an observable
property of the program.

--

---
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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Mar 5, 2014 at 8:47 AM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw_triad@users=
..sourceforge.net</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 2014-03-04 20:34, Richard=
 Smith wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I don&#39;t think you understand. We can trivially accept this:<br>
<br>
int main(std::vector&lt;std::string&gt; args) {<br>
=A0 =A0...<br>
}<br>
<br>
.... and generate code for &#39;main&#39; that accepts an int and a char**,<=
br>
constructs the parameter, and then runs the body of the function. No thunk<=
br>
is generated; we just generate more code for &#39;main&#39;.<br>
</blockquote>
<br></div>
Er... yes. That&#39;s a thunk. One that inlines the wrapped function, perha=
ps, but in my book it&#39;s still a thunk; a small segment of code whose pu=
rpose is to adapt a set of arguments for a similar interface taking a diffe=
rent set of arguments.<br>

<br>
The point is that the externally visible signature of main hasn&#39;t chang=
ed. The rest is arguing semantics, which I am sick of doing.</blockquote><d=
iv><br></div><div>=A0OK, so... what&#39;s your point? I&#39;ve demonstrated=
 that this *is* possible, and doesn&#39;t require us to pick a different na=
me for &#39;main&#39;, and doesn&#39;t break the ABI. You seem to be saying=
 that this is somehow not OK since it doesn&#39;t change the &quot;signatur=
e&quot; of main, but that&#39;s not an observable property of the program.<=
/div>
</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 />

--047d7bd6bd760fe90804f3dfeca2--

.

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

Le mercredi 5 mars 2014 18:10:31 UTC+1, Thiago Macieira a =C3=A9crit :
>
> Em qua 05 mar 2014, =C3=A0s 11:54:09, Matthew Woehlke escreveu:=20
> > On 2014-03-05 08:53, Jean-Marc Bourguet wrote:=20
> > > Why do we have to teach the compiler about std::vector and=20
> std::string.=20
> > >=20
> > >   Just have=20
> > >  =20
> > >      int main(Foo args) {=20
> > >         blah=20
> > >      }=20
> > >=20
> > > be compiled as=20
> > >=20
> > >     int main(int __argc, int __argv) {=20
> > >        Foo args(__argv, __argv+__argc);=20
> > >        { blah }=20
> > >     }=20
> > >=20
> > > and let the user provide declarations for what is needed.=20
>
> Please make it instead:=20
>
>         int main(int __argc, char **__argv)=20
>         {=20
>                 Foo args(argc, argv);=20
>                 { blah; }=20
>         }=20
>
> This is far more logical.=20
>

Range are represented by begin and end about everywhere in the standard=20
library, The only reason
I see to divert from that would be to follow what the range SG decide to do=
..

Yours,
--=20
Jean-Marc

--=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_216_26783985.1394098124215
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Le mercredi 5 mars 2014 18:10:31 UTC+1, Thiago Macieira a =
=C3=A9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em qua 05 mar=
 2014, =C3=A0s 11:54:09, Matthew Woehlke escreveu:
<br>&gt; On 2014-03-05 08:53, Jean-Marc Bourguet wrote:
<br>&gt; &gt; Why do we have to teach the compiler about std::vector and st=
d::string.
<br>&gt; &gt;=20
<br>&gt; &gt; &nbsp; Just have
<br>&gt; &gt; &nbsp;=20
<br>&gt; &gt; &nbsp; &nbsp; &nbsp;int main(Foo args) {
<br>&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; blah
<br>&gt; &gt; &nbsp; &nbsp; &nbsp;}
<br>&gt; &gt;=20
<br>&gt; &gt; be compiled as
<br>&gt; &gt;=20
<br>&gt; &gt; &nbsp; &nbsp; int main(int __argc, int __argv) {
<br>&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;Foo args(__argv, __argv+__argc);
<br>&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;{ blah }
<br>&gt; &gt; &nbsp; &nbsp; }
<br>&gt; &gt;=20
<br>&gt; &gt; and let the user provide declarations for what is needed.
<br>
<br>Please make it instead:
<br>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;int main(int __argc, ch=
ar **__argv)
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;Foo args(argc, argv);
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;{ blah; }
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
<br>
<br>This is far more logical.&nbsp;<br></blockquote><div><br></div><div>Ran=
ge are represented by begin and end about everywhere in the standard librar=
y, The only reason</div><div>I see to divert from that would be to follow w=
hat the range SG decide to do.</div><div><br></div><div>Yours,</div><div>--=
&nbsp;</div><div>Jean-Marc</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_216_26783985.1394098124215--

.

On Thu, Mar 6, 2014 at 6:28 AM, Jean-Marc Bourguet
<jm.bourguet@gmail.com> wrote:
> Le mercredi 5 mars 2014 18:10:31 UTC+1, Thiago Macieira a =E9crit :
>>
>> Em qua 05 mar 2014, =E0s 11:54:09, Matthew Woehlke escreveu:
>> > On 2014-03-05 08:53, Jean-Marc Bourguet wrote:
>> > > Why do we have to teach the compiler about std::vector and
>> > > std::string.
>> > >
>> > >   Just have
>> > >
>> > >      int main(Foo args) {
>> > >         blah
>> > >      }
>> > >
>> > > be compiled as
>> > >
>> > >     int main(int __argc, int __argv) {
>> > >        Foo args(__argv, __argv+__argc);
>> > >        { blah }
>> > >     }
>> > >
>> > > and let the user provide declarations for what is needed.
>>
>> Please make it instead:
>>
>>         int main(int __argc, char **__argv)
>>         {
>>                 Foo args(argc, argv);
>>                 { blah; }
>>         }
>>
>> This is far more logical.
>
>
> Range are represented by begin and end about everywhere in the standard
> library, The only reason
> I see to divert from that would be to follow what the range SG decide to =
do.

+1.

I think the whole point is to provide a better abstraction from
size/array. Though I'm not sure it really helps anybody without a
program options library.

> Yours,
> --
> Jean-Marc

Regards,
--=20
Felipe Magno de Almeida

--=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/.

.

Em qui 06 mar 2014, =E0s 01:28:43, Jean-Marc Bourguet escreveu:
> >         int main(int __argc, char **__argv)=20
> >         {=20
> >                 Foo args(argc, argv);=20
> >                 { blah; }=20
> >         }=20
> >
> > This is far more logical.=20
>=20
> Range are represented by begin and end about everywhere in the standard=
=20
> library, The only reason
> I see to divert from that would be to follow what the range SG decide to =
do.

The one exception to the range rule you mentioned is main() itself, since t=
he=20
range is passed as a size and begin pointer.

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

--=20

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

.

--047d7b86de4023fda904f3f37cb8
Content-Type: text/plain; charset=ISO-8859-1

On 6 March 2014 09:18, Felipe Magno de Almeida
<felipe.m.almeida@gmail.com>wrote:

>
>
> I think the whole point is to provide a better abstraction from
> size/array. Though I'm not sure it really helps anybody without a
> program options library.
>

I don't see how it helps anybody *with* a program options library, either.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

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

<div dir=3D"ltr">On 6 March 2014 09:18, Felipe Magno de Almeida <span dir=
=3D"ltr">&lt;<a href=3D"mailto:felipe.m.almeida@gmail.com" target=3D"_blank=
">felipe.m.almeida@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_e=
xtra"><div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
<br>
I think the whole point is to provide a better abstraction from<br>
size/array. Though I&#39;m not sure it really helps anybody without a<br>
program options library.<br></blockquote><div><br></div><div>I don&#39;t se=
e how it helps anybody <i>with</i> a program options library, either.<br></=
div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"ma=
ilto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&g=
t;=A0 (847) 691-1404
</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 />

--047d7b86de4023fda904f3f37cb8--

.

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

It was also cleared up in the early beginnings of this thread that it would not be of any use without getopt functionality. Somebody must have divided by zero immediately after that.

Nevin Liber <nevin@eviloverlord.com> wrote:
>On 6 March 2014 09:18, Felipe Magno de Almeida
><felipe.m.almeida@gmail.com>wrote:
>
>>
>>
>> I think the whole point is to provide a better abstraction from
>> size/array. Though I'm not sure it really helps anybody without a
>> program options library.
>>
>
>I don't see how it helps anybody *with* a program options library,
>either.
>--
> Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404
>
>--
>
>---
>You received this message because you are subscribed to the Google
>Groups "ISO C++ Standard - Future Proposals" group.
>To unsubscribe from this group and stop receiving emails from it, send
>an email to std-proposals+unsubscribe@isocpp.org.
>To post to this group, send email to std-proposals@isocpp.org.
>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/.

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

<html><head></head><body><p dir=3D"ltr">It was also cleared up in the early=
 beginnings of this thread that it would not be of any use without getopt f=
unctionality. Somebody must have divided by zero immediately after that.</p=
>
<br><br><div class=3D"gmail_quote">Nevin Liber &lt;nevin@eviloverlord.com&g=
t; wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8=
ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir=3D"ltr">On 6 March 2014 09:18, Felipe Magno de Almeida <span dir=
=3D"ltr">&lt;<a href=3D"mailto:felipe.m.almeida@gmail.com" target=3D"_blank=
">felipe.m.almeida@gmail.com</a>&gt;</span> wrote:<br /><div class=3D"gmail=
_extra"><div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br />
<br />
I think the whole point is to provide a better abstraction from<br />
size/array. Though I&#39;m not sure it really helps anybody without a<br />
program options library.<br /></blockquote><div><br /></div><div>I don&#39;=
t see how it helps anybody <i>with</i> a program options library, either.<b=
r /></div></div>-- <br />=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto=
:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilover=
lord.com</a>&gt;=C2=A0 (847) 691-1404
</div></div>

<p></p>
</blockquote></div></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 />

------LYSZE7BTC67MV7IPW602CGXASIVZHE--


.

------=_Part_1082_22682023.1394221180476
Content-Type: text/plain; charset=UTF-8

What you can do is create a header, called *program*:



*#ifndef PROGRAM_H#define PROGRAM_H#include <vector>#include <string>*












*int Main(const std::vector<std::string>&);int main(int argc, char**
argv){    try    {        return
Main(std::vector<std::string>(argv,argv+argc));    }    catch(...)
{        return 1;    }}#endif*


Then use it in a program:


*#include <iostream>#include <program>  *




*int Main(const std::vector<std::string>& v){     for (auto& x: v)
{          std::cout << x << std::endl;*
*     }*

*}*
On Wednesday, March 5, 2014 7:01:55 AM UTC, Andrew Tomazos wrote:

> On Wednesday, March 5, 2014 2:53:18 AM UTC+1, Thiago Macieira wrote:
>
>> PS: it's argv+argc+1.
>
>
>
> int main(int argc, char **argv)
>> {
>>         std::vector<std::string> args(argv, argv+argc+1);
>>         // rest of main goes here
>> }
>>
>
> Why did you add +1?  I think it was correct as vector<string>(argv,
> argv+argc)
>
>

--

---
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_1082_22682023.1394221180476
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>What you can do is create a header, called <strong>pr=
ogram</strong>:</div><div><font face=3D"courier new,monospace"><strong>#ifn=
def PROGRAM_H<br>#define PROGRAM_H<br>#include &lt;vector&gt;<br>#include &=
lt;string&gt;</strong></font></div><div><font face=3D"courier new,monospace=
"><strong>int Main(const std::vector&lt;std::string&gt;&amp;);<br>int main(=
int argc, char** argv)<br>{<br>&nbsp;&nbsp;&nbsp; try<br>&nbsp;&nbsp;&nbsp;=
 {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return Main(std::vector&lt=
;std::string&gt;(argv,argv+argc));<br>&nbsp;&nbsp;&nbsp; }<br>&nbsp;&nbsp;&=
nbsp; catch(...)<br>&nbsp;&nbsp;&nbsp; {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; return 1;<br>&nbsp;&nbsp;&nbsp; }<br>}<br>#endif</strong></font=
></div><p><br></p><div><font face=3D"arial,sans-serif">Then use it in a pro=
gram:</font></div><div><br></div><div><font face=3D"courier new,monospace">=
<strong>#include &lt;iostream&gt;<br>#include &lt;program&gt;&nbsp; </stron=
g></font></div><div><font face=3D"courier new,monospace"><strong>int Main(c=
onst std::vector&lt;std::string&gt;&amp; v)<br>{<br>&nbsp;&nbsp;&nbsp;&nbsp=
; for (auto&amp; x: v)<br>&nbsp;&nbsp;&nbsp;&nbsp; {<br>&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; std::cout &lt;&lt; x &lt;&lt; std::endl=
;</strong></font></div><div><font face=3D"courier new,monospace"><strong>&n=
bsp;&nbsp;&nbsp; &nbsp;}</strong></font></div><div><font face=3D"courier ne=
w,monospace"><strong>}<br></strong></font><br>On Wednesday, March 5, 2014 7=
:01:55 AM UTC, Andrew Tomazos wrote:</div><blockquote class=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;"><div=
 dir=3D"ltr">On Wednesday, March 5, 2014 2:53:18 AM UTC+1, Thiago Macieira =
wrote:<div><blockquote class=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;">PS: it's argv+argc+1.&nbsp;</blockq=
uote><blockquote class=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;">&nbsp;</blockquote><blockquote class=3D"g=
mail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-l=
eft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: s=
olid;">int main(int argc, char **argv)
<br>{
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;std::vector&lt;std::<wb=
r>string&gt; args(argv, argv+argc+1);
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// rest of main goes he=
re
<br>}
<br>
</blockquote><div><br></div><div>Why did you add +1? &nbsp;I think it was c=
orrect as vector&lt;string&gt;(argv, argv+argc)</div><div><br></div></div><=
/div></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_1082_22682023.1394221180476--

.

This is a multi-part message in MIME format.
--------------060708040102080204070108
Content-Type: text/plain; charset=UTF-8; format=flowed

On 04/03/14 22:18, Joseph Mansfield wrote:
> Proposal: http://htmlpreview.github.io/?https://github.com/sftrabbit/ModernMain/blob/c84c1d4d87d9e4733d92a13096ed4350e1461782/proposal.htm
> Source: https://github.com/sftrabbit/ModernMain
>
> I've drafted up some thoughts I had on introducing a form of main that
> takes program arguments as a std::vector<std::string>. For example:
>
> #include <string>
> #include <vector>
> #include <iostream>
>
> int main(std::vector<std::string> args)
> {
> for (const auto& arg : args) {
> std::cout << arg << "\n";
> }
> }
>

This requires the compiler to know about std::string and std::vector etc
why not instead do this
if the compiler finds a class Main the compiler
generates a main like so
int main(int argc, char *argv[]){
       Main m(argc, argv);
       return m.run();
}

where Main could be anything that has the interface

class Main {
     public:
          Main(int argc, char *argv[]);
          int run();
}

i.e. we could define Main as

#include <string>
#include <vector>
#include <iostream>

class Main {
    private:
       std::string progname;
       std::vector<std::string> args;
    public:
       Main(int argc, char *argv[]);
       int run();
}

Main::Main(int argc, char argv[])
    : progname(argv[0]),
      args(&argv[1], argv + argc)
{

}

int Main::run(){

     for(const auto& arg : args){
         std::cout << arg << std::endl;
     }
}

This allows the compiler to know as little as possible about our
implementation of a modern main.



> As far as I can tell, it seems like a viable proposal that would be
> welcomed by many (but may also be a little controversial). My main
> concerns are with the approach to exception handling, but I don't
> think it's a particularly bad way of doing it. Please take a look at
> the Open Questions section.
>
> This is my first attempt at writing a proposal draft, so let me know
> of any rookie mistakes I'm making. I also do not admittedly have much
> of a detailed understanding of compiler implementations, so I don't
> know if there's something about this that makes it completely infeasible.
>
> Thanks,
> Joseph Mansfield
> --
>
> ---
> 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/.


--


   .~.     In my life God comes first....
   /V\         but Linux is pretty high after that :-D
  /( )\    Francis (Grizzly) Smit
  ^^-^^    http://www.smit.id.au/

--

---
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/.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 04/03/14 22:18, Joseph Mansfield
      wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:0690f555-3765-4e25-b0c0-3797ae0183ff@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>Proposal:=C2=A0<a class=3D"moz-txt-link-freetext" href=3D"http=
://htmlpreview.github.io/?https://github.com/sftrabbit/ModernMain/blob/c84c=
1d4d87d9e4733d92a13096ed4350e1461782/proposal.htm">http://htmlpreview.githu=
b.io/?https://github.com/sftrabbit/ModernMain/blob/c84c1d4d87d9e4733d92a130=
96ed4350e1461782/proposal.htm</a></div>
        <div>Source:=C2=A0<a class=3D"moz-txt-link-freetext" href=3D"https:=
//github.com/sftrabbit/ModernMain">https://github.com/sftrabbit/ModernMain<=
/a></div>
        <div><br>
        </div>
        I've drafted up some thoughts I had on introducing a form of <font
          face=3D"courier new, monospace">main</font><font face=3D"arial,
          sans-serif">=C2=A0that takes program arguments as a </font><font
          face=3D"courier new, monospace">std::vector&lt;std::string&gt;</f=
ont><font
          face=3D"arial, sans-serif">. For example:</font>
        <div><font face=3D"arial, sans-serif"><br>
          </font></div>
        <div>
          <div><font face=3D"courier new, monospace">#include
              &lt;string&gt;</font></div>
          <div><font face=3D"courier new, monospace">#include
              &lt;vector&gt;</font></div>
          <div><font face=3D"courier new, monospace">#include
              &lt;iostream&gt;</font></div>
          <div><font face=3D"courier new, monospace"><br>
            </font></div>
          <div><font face=3D"courier new, monospace">int
              main(std::vector&lt;std::string&gt; args)</font></div>
          <div><font face=3D"courier new, monospace">{</font></div>
          <div><font face=3D"courier new, monospace"><span
                class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>=
for
              (const auto&amp; arg : args) {</font></div>
          <div><font face=3D"courier new, monospace"><span
                class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>=
std::cout
              &lt;&lt; arg &lt;&lt; "\n";</font></div>
          <div><font face=3D"courier new, monospace"><span
                class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>=
}</font></div>
          <div><font face=3D"courier new, monospace">}</font></div>
          <div><font face=3D"arial, sans-serif"><br>
            </font></div>
        </div>
      </div>
    </blockquote>
    <br>
    <font face=3D"arial, sans-serif">This requires the compiler to know
      about </font>std::string and std::vector etc why not instead do
    this<br>
    if the compiler finds a class Main the compiler <br>
    generates a main like so<br>
    int main(int argc, char *argv[]){<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Main m(argc, argv);<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return m.run();<br>
    }<br>
    <br>
    where Main could be anything that has the interface <br>
    <br>
    class Main {<br>
    =C2=A0=C2=A0=C2=A0 public:<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Main(int argc, char *a=
rgv[]);<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int run();<br>
    }<br>
    <br>
    i.e. we could define Main as <br>
    <br>
    <div><font face=3D"courier new, monospace">#include &lt;string&gt;</fon=
t></div>
    <div><font face=3D"courier new, monospace">#include &lt;vector&gt;</fon=
t></div>
    <div><font face=3D"courier new, monospace">#include &lt;iostream&gt;<br=
>
        <br>
        class Main {<br>
        =C2=A0=C2=A0 private:<br>
        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::string progname;<br>
        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::vector&lt;std::string&gt; args;=
<br>
        =C2=A0=C2=A0 public:<br>
        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Main(int argc, char *argv[]);<br>
        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int run();<br>
        }<br>
      </font></div>
    <br>
    Main::Main(int argc, char argv[])<br>
    =C2=A0=C2=A0 : progname(argv[0]),<br>
    =C2=A0=C2=A0=C2=A0=C2=A0 args(&amp;argv[1], argv + argc)<br>
    {<br>
    =C2=A0=C2=A0=C2=A0=C2=A0 <br>
    }<br>
    <br>
    int Main::run(){<br>
    =C2=A0=C2=A0=C2=A0 <br>
    <div><font face=3D"courier new, monospace">=C2=A0=C2=A0=C2=A0 for(const=
 auto&amp; arg
        : args){</font></div>
    <div><font face=3D"courier new, monospace">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 std::cout &lt;&lt;
        arg &lt;&lt; std::endl;</font></div>
    <div><font face=3D"courier new, monospace">=C2=A0=C2=A0=C2=A0 }</font><=
/div>
    }<br>
    <br>
    This allows the compiler to know as little as possible about our
    implementation of a modern main.<br>
    <br>
    <br>
    <br>
    <blockquote
      cite=3D"mid:0690f555-3765-4e25-b0c0-3797ae0183ff@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div><font face=3D"arial, sans-serif">As far as I can tell, it
              seems like a viable proposal that would be welcomed by
              many (but may also be a little controversial). My main
              concerns are with the approach to exception handling, but
              I don't think it's a particularly bad way of doing it.
              Please take a look at the Open Questions section.</font></div=
>
          <div><span style=3D"font-family: arial, sans-serif;"><br>
            </span></div>
          <div><span style=3D"font-family: arial, sans-serif;">This is my
              first attempt at writing a proposal draft, so let me know
              of any rookie mistakes I'm making.=C2=A0I also do not
              admittedly have much of a detailed understanding of
              compiler implementations, so I don't know if there's
              something about this that makes it completely infeasible.</sp=
an></div>
        </div>
        <div><span style=3D"font-family: arial, sans-serif;"><br>
          </span></div>
        <div><span style=3D"font-family: arial, sans-serif;">Thanks,</span>=
</div>
        <div><span style=3D"font-family: arial, sans-serif;">Joseph
            Mansfield</span></div>
      </div>
      -- <br>
      =C2=A0<br>
      --- <br>
      You received this message because you are subscribed to the Google
      Groups "ISO C++ Standard - Future Proposals" group.<br>
      To unsubscribe from this group and stop receiving emails from it,
      send an email to <a class=3D"moz-txt-link-abbreviated" href=3D"mailto=
:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org=
</a>.<br>
      To post to this group, send email to <a class=3D"moz-txt-link-abbrevi=
ated" href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>=
..<br>
      Visit this group at <a moz-do-not-send=3D"true"
        href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
    </blockquote>
    <br>
    <br>
    <div class=3D"moz-signature">-- <br>
      <pre><tt>
  .~.     In my life God comes first....=20
  /V\         but Linux is pretty high after that :-D
 /( )\    Francis (Grizzly) Smit
 ^^-^^    <a class=3D"moz-txt-link-freetext" href=3D"http://www.smit.id.au/=
">http://www.smit.id.au/</a>
</tt><pre>
</pre></pre>
    </div>
  </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 />

--------------060708040102080204070108--

.

This is a multi-part message in MIME format.
--------------080703060707000608050708
Content-Type: text/plain; charset=UTF-8; format=flowed

On 04/03/14 22:18, Joseph Mansfield wrote:
> Proposal: http://htmlpreview.github.io/?https://github.com/sftrabbit/ModernMain/blob/c84c1d4d87d9e4733d92a13096ed4350e1461782/proposal.htm
> Source: https://github.com/sftrabbit/ModernMain
>
> I've drafted up some thoughts I had on introducing a form of main that
> takes program arguments as a std::vector<std::string>. For example:
>
> #include <string>
> #include <vector>
> #include <iostream>
>
> int main(std::vector<std::string> args)
> {
> for (const auto& arg : args) {
> std::cout << arg << "\n";
> }
> }
>

This requires the compiler to know about std::string and std::vector etc
why not instead do this
if the compiler finds a class Main the compiler
generates a main like so:


int main(int argc, char *argv[]){
       Main m(argc, argv);
       return m.run();
}

where Main could be anything that has the interface

class Main {
     public:
          Main(int argc, char *argv[]);
          int run();
}

i.e. we could define Main as

#include <string>
#include <vector>
#include <iostream>

class Main {
    private:
       std::string progname;
       std::vector<std::string> args;
    public:
       Main(int argc, char *argv[]);
       int run();
}

Main::Main(int argc, char argv[])
    : progname(argv[0]),
      args(&argv[1], argv + argc)
{

}

int Main::run(){

     for(const auto& arg : args){
         std::cout << arg << std::endl;
     }
}

This allows the compiler to know as little as possible about our
implementation of a modern main.



> As far as I can tell, it seems like a viable proposal that would be
> welcomed by many (but may also be a little controversial). My main
> concerns are with the approach to exception handling, but I don't
> think it's a particularly bad way of doing it. Please take a look at
> the Open Questions section.
>
> This is my first attempt at writing a proposal draft, so let me know
> of any rookie mistakes I'm making. I also do not admittedly have much
> of a detailed understanding of compiler implementations, so I don't
> know if there's something about this that makes it completely infeasible.
>
> Thanks,
> Joseph Mansfield
> --
>
> ---
> 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/.


--


   .~.     In my life God comes first....
   /V\         but Linux is pretty high after that :-D
  /( )\    Francis (Grizzly) Smit
  ^^-^^    http://www.smit.id.au/

--

---
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/.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 04/03/14 22:18, Joseph Mansfield
      wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:0690f555-3765-4e25-b0c0-3797ae0183ff@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>Proposal:=C2=A0<a class=3D"moz-txt-link-freetext" href=3D"http=
://htmlpreview.github.io/?https://github.com/sftrabbit/ModernMain/blob/c84c=
1d4d87d9e4733d92a13096ed4350e1461782/proposal.htm">http://htmlpreview.githu=
b.io/?https://github.com/sftrabbit/ModernMain/blob/c84c1d4d87d9e4733d92a130=
96ed4350e1461782/proposal.htm</a></div>
        <div>Source:=C2=A0<a class=3D"moz-txt-link-freetext" href=3D"https:=
//github.com/sftrabbit/ModernMain">https://github.com/sftrabbit/ModernMain<=
/a></div>
        <div><br>
        </div>
        I've drafted up some thoughts I had on introducing a form of <font
          face=3D"courier new, monospace">main</font><font face=3D"arial,
          sans-serif">=C2=A0that takes program arguments as a </font><font
          face=3D"courier new, monospace">std::vector&lt;std::string&gt;</f=
ont><font
          face=3D"arial, sans-serif">. For example:</font>
        <div><font face=3D"arial, sans-serif"><br>
          </font></div>
        <div>
          <div><font face=3D"courier new, monospace">#include
              &lt;string&gt;</font></div>
          <div><font face=3D"courier new, monospace">#include
              &lt;vector&gt;</font></div>
          <div><font face=3D"courier new, monospace">#include
              &lt;iostream&gt;</font></div>
          <div><font face=3D"courier new, monospace"><br>
            </font></div>
          <div><font face=3D"courier new, monospace">int
              main(std::vector&lt;std::string&gt; args)</font></div>
          <div><font face=3D"courier new, monospace">{</font></div>
          <div><font face=3D"courier new, monospace"><span
                class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>=
for
              (const auto&amp; arg : args) {</font></div>
          <div><font face=3D"courier new, monospace"><span
                class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>=
std::cout
              &lt;&lt; arg &lt;&lt; "\n";</font></div>
          <div><font face=3D"courier new, monospace"><span
                class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>=
}</font></div>
          <div><font face=3D"courier new, monospace">}</font></div>
          <div><font face=3D"arial, sans-serif"><br>
            </font></div>
        </div>
      </div>
    </blockquote>
    <br>
    <font face=3D"arial, sans-serif">This requires the compiler to know
      about </font>std::string and std::vector etc why not instead do
    this<br>
    if the compiler finds a class Main the compiler <br>
    generates a main like so:<br>
    <br>
    <br>
    int main(int argc, char *argv[]){<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Main m(argc, argv);<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return m.run();<br>
    }<br>
    <br>
    where Main could be anything that has the interface <br>
    <br>
    class Main {<br>
    =C2=A0=C2=A0=C2=A0 public:<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Main(int argc, char *a=
rgv[]);<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int run();<br>
    }<br>
    <br>
    i.e. we could define Main as <br>
    <br>
    <div><font face=3D"courier new, monospace">#include &lt;string&gt;</fon=
t></div>
    <div><font face=3D"courier new, monospace">#include &lt;vector&gt;</fon=
t></div>
    <div><font face=3D"courier new, monospace">#include &lt;iostream&gt;<br=
>
        <br>
        class Main {<br>
        =C2=A0=C2=A0 private:<br>
        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::string progname;<br>
        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::vector&lt;std::string&gt; args;=
<br>
        =C2=A0=C2=A0 public:<br>
        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Main(int argc, char *argv[]);<br>
        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int run();<br>
        }<br>
      </font></div>
    <br>
    Main::Main(int argc, char argv[])<br>
    =C2=A0=C2=A0 : progname(argv[0]),<br>
    =C2=A0=C2=A0=C2=A0=C2=A0 args(&amp;argv[1], argv + argc)<br>
    {<br>
    =C2=A0=C2=A0=C2=A0=C2=A0 <br>
    }<br>
    <br>
    int Main::run(){<br>
    =C2=A0=C2=A0=C2=A0 <br>
    <div><font face=3D"courier new, monospace">=C2=A0=C2=A0=C2=A0 for(const=
 auto&amp; arg
        : args){</font></div>
    <div><font face=3D"courier new, monospace">=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 std::cout &lt;&lt;
        arg &lt;&lt; std::endl;</font></div>
    <div><font face=3D"courier new, monospace">=C2=A0=C2=A0=C2=A0 }</font><=
/div>
    }<br>
    <br>
    This allows the compiler to know as little as possible about our
    implementation of a modern main.<br>
    <br>
    <br>
    <br>
    <blockquote
      cite=3D"mid:0690f555-3765-4e25-b0c0-3797ae0183ff@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div><font face=3D"arial, sans-serif">As far as I can tell, it
              seems like a viable proposal that would be welcomed by
              many (but may also be a little controversial). My main
              concerns are with the approach to exception handling, but
              I don't think it's a particularly bad way of doing it.
              Please take a look at the Open Questions section.</font></div=
>
          <div><span style=3D"font-family: arial, sans-serif;"><br>
            </span></div>
          <div><span style=3D"font-family: arial, sans-serif;">This is my
              first attempt at writing a proposal draft, so let me know
              of any rookie mistakes I'm making.=C2=A0I also do not
              admittedly have much of a detailed understanding of
              compiler implementations, so I don't know if there's
              something about this that makes it completely infeasible.</sp=
an></div>
        </div>
        <div><span style=3D"font-family: arial, sans-serif;"><br>
          </span></div>
        <div><span style=3D"font-family: arial, sans-serif;">Thanks,</span>=
</div>
        <div><span style=3D"font-family: arial, sans-serif;">Joseph
            Mansfield</span></div>
      </div>
      -- <br>
      =C2=A0<br>
      --- <br>
      You received this message because you are subscribed to the Google
      Groups "ISO C++ Standard - Future Proposals" group.<br>
      To unsubscribe from this group and stop receiving emails from it,
      send an email to <a class=3D"moz-txt-link-abbreviated" href=3D"mailto=
:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org=
</a>.<br>
      To post to this group, send email to <a class=3D"moz-txt-link-abbrevi=
ated" href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>=
..<br>
      Visit this group at <a moz-do-not-send=3D"true"
        href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
    </blockquote>
    <br>
    <br>
    <div class=3D"moz-signature">-- <br>
      <pre><tt>
  .~.     In my life God comes first....=20
  /V\         but Linux is pretty high after that :-D
 /( )\    Francis (Grizzly) Smit
 ^^-^^    <a class=3D"moz-txt-link-freetext" href=3D"http://www.smit.id.au/=
">http://www.smit.id.au/</a>
</tt><pre>
</pre></pre>
    </div>
  </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 />

--------------080703060707000608050708--

.

--Apple-Mail=_C7661B93-E840-4D26-84B7-A1D86E1937B3
Content-Type: text/plain; charset=ISO-8859-1


On 2014-03-09, at 2:34 AM, Francis Smit <grizzlysmit@gmail.com> wrote:

> This requires the compiler to know about std::string and std::vector etc why not instead do this
> if the compiler finds a class Main the compiler

Then the compiler "knows about" class Main. What's the problem with the compiler knowing about things? We're not stuck with a suggestion to hard-code the standard containers into this feature.

--

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

--Apple-Mail=_C7661B93-E840-4D26-84B7-A1D86E1937B3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;03&ndash;09, at 2:34 AM, Francis Smit &lt;<a href=3D"mailto:grizzlysm=
it@gmail.com">grizzlysmit@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-=
interchange-newline"><blockquote type=3D"cite">
 =20
    <meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix"><font face=3D"arial, sans-serif">This re=
quires the compiler to know
      about </font>std::string and std::vector etc why not instead do
    this</div>
    if the compiler finds a class Main the compiler <br></div></blockquote>=
<div><br></div><div>Then the compiler &ldquo;knows about&rdquo; class Main.=
 What&rsquo;s the problem with the compiler knowing about things? We&rsquo;=
re not stuck with a suggestion to hard-code the standard containers into th=
is feature.</div></div><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 />

--Apple-Mail=_C7661B93-E840-4D26-84B7-A1D86E1937B3--

.