Topic: Why don't we make "void main" legal?
Author: Brian Bi <bbi5291@gmail.com>
Date: Thu, 5 Nov 2015 21:26:41 -0800
Raw View
--047d7b34420608c2de0523d87d1a
Content-Type: text/plain; charset=UTF-8
A lot of people seem to think `void main` is legal and I'm tired of
constantly correcting them. Why don't we just *make* it legal? Return from
`void main` would have the same effect as returning 0 from `int main` (or
not returning).
After all, there are already two signatures allowed for `main`, so there
doesn't seem to be any technical reason to not add two more.
--
*Brian Bi*
--
---
You received this message because you are 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/.
--047d7b34420608c2de0523d87d1a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>A lot of people seem to think `void main` is legal an=
d I'm tired of constantly correcting them. Why don't we just <b>mak=
e</b> it legal? Return from `void main` would have the same effect as retur=
ning 0 from `int main` (or not returning).<br><br>After all, there are alre=
ady two signatures allowed for `main`, so there doesn't seem to be any =
technical reason to not add two more.<br>-- <br><div class=3D"gmail_signatu=
re"><div dir=3D"ltr"><div><div dir=3D"ltr"><font color=3D"#c0c0c0"><i>Brian=
Bi</i></font><br></div></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" 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 />
--047d7b34420608c2de0523d87d1a--
.
Author: Jonathan Coe <jonathanbcoe@gmail.com>
Date: Fri, 6 Nov 2015 08:09:06 +0000
Raw View
--Apple-Mail-02BF1AAA-1E94-4303-AB17-67110111CB87
Content-Type: text/plain; charset=UTF-8
I often make use of return codes from programs. What would the return code from 'void main' be?
Regards
Jonathan
> On 6 Nov 2015, at 05:26, Brian Bi <bbi5291@gmail.com> wrote:
>
> A lot of people seem to think `void main` is legal and I'm tired of constantly correcting them. Why don't we just make it legal? Return from `void main` would have the same effect as returning 0 from `int main` (or not returning).
>
> After all, there are already two signatures allowed for `main`, so there doesn't seem to be any technical reason to not add two more.
> --
> Brian Bi
> --
>
> ---
> You received this message because you are 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/.
--Apple-Mail-02BF1AAA-1E94-4303-AB17-67110111CB87
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></div><div>I often make use of ret=
urn codes from programs. What would the return code from 'void main' be?</d=
iv><div><br></div><div>Regards</div><div><br></div><div>Jonathan </div=
><div><br>On 6 Nov 2015, at 05:26, Brian Bi <<a href=3D"mailto:bbi5291@g=
mail.com">bbi5291@gmail.com</a>> wrote:<br><br></div><blockquote type=3D=
"cite"><div><div dir=3D"ltr"><div>A lot of people seem to think `void main`=
is legal and I'm tired of constantly correcting them. Why don't we just <b=
>make</b> it legal? Return from `void main` would have the same effect as r=
eturning 0 from `int main` (or not returning).<br><br>After all, there are =
already two signatures allowed for `main`, so there doesn't seem to be any =
technical reason to not add two more.<br>-- <br><div class=3D"gmail_signatu=
re"><div dir=3D"ltr"><div><div dir=3D"ltr"><font color=3D"#c0c0c0"><i>Brian=
Bi</i></font><br></div></div></div></div>
</div></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" 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-02BF1AAA-1E94-4303-AB17-67110111CB87--
.
Author: Jens Maurer <Jens.Maurer@gmx.net>
Date: Fri, 06 Nov 2015 09:12:50 +0100
Raw View
On 11/06/2015 06:26 AM, Brian Bi wrote:
> A lot of people seem to think `void main` is legal and I'm tired of constantly correcting them.
Why doesn't your toolchain reject "void main"?
Other than that, my position on your suggestion is "no, not worth the
(personal + committee) effort".
Jens
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Brian Bi <bbi5291@gmail.com>
Date: Fri, 6 Nov 2015 00:36:07 -0800
Raw View
--001a11c377a28123fe0523db2205
Content-Type: text/plain; charset=UTF-8
On Fri, Nov 6, 2015 at 12:09 AM, Jonathan Coe <jonathanbcoe@gmail.com>
wrote:
> I often make use of return codes from programs. What would the return code
> from 'void main' be?
>
It would be 0.
--
*Brian Bi*
--
---
You received this message because you are 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/.
--001a11c377a28123fe0523db2205
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Nov 6, 2015 at 12:09 AM, Jonathan Coe <span dir=3D"ltr"><<a href=3D"=
mailto:jonathanbcoe@gmail.com" target=3D"_blank">jonathanbcoe@gmail.com</a>=
></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div=
></div><div>I often make use of return codes from programs. What would the =
return code from 'void main' be?</div></div></blockquote><div><br><=
/div><div>It would be 0.<br clear=3D"all"></div></div><br>-- <br><div class=
=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><font color=3D"=
#c0c0c0"><i>Brian Bi</i></font><br><div></div><div></div><div></div></div><=
/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" 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 />
--001a11c377a28123fe0523db2205--
.
Author: Morwenn <morwenn29@gmail.com>
Date: Fri, 6 Nov 2015 03:19:05 -0800 (PST)
Raw View
------=_Part_254_121563765.1446808745867
Content-Type: multipart/alternative;
boundary="----=_Part_255_1325329302.1446808745868"
------=_Part_255_1325329302.1446808745868
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Le vendredi 6 novembre 2015 09:12:53 UTC+1, Jens Maurer a =C3=A9crit :
>
> On 11/06/2015 06:26 AM, Brian Bi wrote:=20
> > A lot of people seem to think `void main` is legal and I'm tired of=20
> constantly correcting them.=20
>
> Why doesn't your toolchain reject "void main"?=20
>
> Other than that, my position on your suggestion is "no, not worth the=20
> (personal + committee) effort".=20
>
> Jens=20
>
> On the other hand, it seems kind of trivial to standardize (for once, I=
=20
don't see what woul cause bikeshed discussions about that), not returning=
=20
anything in main also returns 0 and it would save a great deal of time for=
=20
people trying to explain other and over that it's not allowed and unable to=
=20
come with a better explanation than "you can't because it's illegal" and=20
tired to hear the subsequent "why?" :p
--=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_255_1325329302.1446808745868
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Le vendredi 6 novembre 2015 09:12:53 UTC+1, Jens Maurer a =
=C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 11/06/2015=
06:26 AM, Brian Bi wrote:
<br>> A lot of people seem to think `void main` is legal and I'm tir=
ed of constantly correcting them.
<br>
<br>Why doesn't your toolchain reject "void main"?
<br>
<br>Other than that, my position on your suggestion is "no, not worth =
the
<br>(personal + committee) effort".
<br>
<br>Jens
<br>
<br></blockquote><div>On the other hand, it seems kind of trivial to standa=
rdize (for once, I don't see what woul cause bikeshed discussions about=
that), not returning anything in main also returns 0 and it would save a g=
reat deal of time for people trying to explain other and over that it's=
not allowed and unable to come with a better explanation than "you ca=
n't because it's illegal" and tired to hear the subsequent &qu=
ot;why?" :p<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" 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_255_1325329302.1446808745868--
------=_Part_254_121563765.1446808745867--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Fri, 6 Nov 2015 14:29:20 +0300
Raw View
On 2015-11-06 14:19, Morwenn wrote:
> Le vendredi 6 novembre 2015 09:12:53 UTC+1, Jens Maurer a =C3=A9crit :
>
> On 11/06/2015 06:26 AM, Brian Bi wrote:
> > A lot of people seem to think `void main` is legal and I'm tired
> of constantly correcting them.
>
> Why doesn't your toolchain reject "void main"?
>
> Other than that, my position on your suggestion is "no, not worth the
> (personal + committee) effort".
>
> Jens
>
> On the other hand, it seems kind of trivial to standardize (for once, I
> don't see what woul cause bikeshed discussions about that), not
> returning anything in main also returns 0 and it would save a great deal
> of time for people trying to explain other and over that it's not
> allowed and unable to come with a better explanation than "you can't
> because it's illegal" and tired to hear the subsequent "why?" :p
There is no precedent in the language that a function returning void=20
actually returns an int value of 0. I see that such a change only adds=20
confusion and not removes any. The ones who make the mistake need to=20
realize that every program has to return a value to the executing=20
process (e.g. a shell), and this value can be used by the process.
--=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/.
.
Author: Evan Teran <evan.teran@gmail.com>
Date: Fri, 6 Nov 2015 06:48:33 -0800 (PST)
Raw View
------=_Part_531_1026874698.1446821313384
Content-Type: multipart/alternative;
boundary="----=_Part_532_418637111.1446821313385"
------=_Part_532_418637111.1446821313385
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
@Andrey,
you're right, however there is already some special casing for main. For=20
example, there is rule that allows omitting the return entirely for main.=
=20
reaching the end of main without a return is currently defined as being=20
equivalent to having executed a "return 0;".
I'm not saying that I favor allowing main to return void, just that it's=20
not such an outlandish idea :-)
On Friday, November 6, 2015 at 6:29:24 AM UTC-5, Andrey Semashev wrote:
>
> On 2015-11-06 14:19, Morwenn wrote:=20
> > Le vendredi 6 novembre 2015 09:12:53 UTC+1, Jens Maurer a =C3=A9crit :=
=20
> >=20
> > On 11/06/2015 06:26 AM, Brian Bi wrote:=20
> > > A lot of people seem to think `void main` is legal and I'm tired=
=20
> > of constantly correcting them.=20
> >=20
> > Why doesn't your toolchain reject "void main"?=20
> >=20
> > Other than that, my position on your suggestion is "no, not worth=
=20
> the=20
> > (personal + committee) effort".=20
> >=20
> > Jens=20
> >=20
> > On the other hand, it seems kind of trivial to standardize (for once, I=
=20
> > don't see what woul cause bikeshed discussions about that), not=20
> > returning anything in main also returns 0 and it would save a great dea=
l=20
> > of time for people trying to explain other and over that it's not=20
> > allowed and unable to come with a better explanation than "you can't=20
> > because it's illegal" and tired to hear the subsequent "why?" :p=20
>
> There is no precedent in the language that a function returning void=20
> actually returns an int value of 0. I see that such a change only adds=20
> confusion and not removes any. The ones who make the mistake need to=20
> realize that every program has to return a value to the executing=20
> process (e.g. a shell), and this value can be used by the process.=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_532_418637111.1446821313385
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">@Andrey,<div><br></div><div>you're right, however ther=
e is already some special casing for main. For example, there is rule that =
allows omitting the return entirely for main. reaching the end of main with=
out a return is currently defined as being equivalent to having executed a =
"return 0;".</div><div><br></div><div>I'm not saying that I f=
avor allowing main to return void, just that it's not such an outlandis=
h idea :-)<br><br>On Friday, November 6, 2015 at 6:29:24 AM UTC-5, Andrey S=
emashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-11-06 14=
:19, Morwenn wrote:
<br>> Le vendredi 6 novembre 2015 09:12:53 UTC+1, Jens Maurer a =C3=A9cr=
it :
<br>>
<br>> =C2=A0 =C2=A0 On 11/06/2015 06:26 AM, Brian Bi wrote:
<br>> =C2=A0 =C2=A0 =C2=A0> A lot of people seem to think `void main`=
is legal and I'm tired
<br>> =C2=A0 =C2=A0 of constantly correcting them.
<br>>
<br>> =C2=A0 =C2=A0 Why doesn't your toolchain reject "void mai=
n"?
<br>>
<br>> =C2=A0 =C2=A0 Other than that, my position on your suggestion is &=
quot;no, not worth the
<br>> =C2=A0 =C2=A0 (personal + committee) effort".
<br>>
<br>> =C2=A0 =C2=A0 Jens
<br>>
<br>> On the other hand, it seems kind of trivial to standardize (for on=
ce, I
<br>> don't see what woul cause bikeshed discussions about that), no=
t
<br>> returning anything in main also returns 0 and it would save a grea=
t deal
<br>> of time for people trying to explain other and over that it's =
not
<br>> allowed and unable to come with a better explanation than "yo=
u can't
<br>> because it's illegal" and tired to hear the subsequent &q=
uot;why?" :p
<br>
<br>There is no precedent in the language that a function returning void=20
<br>actually returns an int value of 0. I see that such a change only adds=
=20
<br>confusion and not removes any. The ones who make the mistake need to=20
<br>realize that every program has to return a value to the executing=20
<br>process (e.g. a shell), and this value can be used by the process.
<br>
<br></blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_532_418637111.1446821313385--
------=_Part_531_1026874698.1446821313384--
.
Author: "dgutson ." <danielgutson@gmail.com>
Date: Fri, 6 Nov 2015 12:14:33 -0300
Raw View
On Fri, Nov 6, 2015 at 5:36 AM, Brian Bi <bbi5291@gmail.com> wrote:
> On Fri, Nov 6, 2015 at 12:09 AM, Jonathan Coe <jonathanbcoe@gmail.com>
> wrote:
>>
>> I often make use of return codes from programs. What would the return co=
de
>> from 'void main' be?
>
>
> It would be 0.
int main(){}
already returns 0. If you want to avoid the "return" statement, then
just do it. The only difference is the return type. And "int" is even
shorter to type. I see no rationale behind this.
main has to return a value taken by the executing environment.
>
> --
> Brian Bi
>
> --
>
> ---
> You received this message because you are 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
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?
--=20
---=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/.
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Fri, 6 Nov 2015 16:25:13 +0100
Raw View
--001a11352d48947a010523e0d925
Content-Type: text/plain; charset=UTF-8
On Fri, Nov 6, 2015 at 12:29 PM, Andrey Semashev <andrey.semashev@gmail.com>
wrote:
> There is no precedent in the language that a function returning void
actually returns an int value of 0.
main cannot be called from another C++ function without resorting to
undefined behaviour, and the meaning of its return code is implementation
defined. Given all its other special provisions, especially defaulting to
return 0, a void main could be defined as being equivalent to an int main
that returns 0 without any inconsistencies.
> The ones who make the mistake need to realize that every program has to
return a value to the executing process (e.g. a shell)
That is implementation-specific. If a particular implementation requires a
return code, the implementation can use a default 'success' code for a void
main.
Note I am not in favour or against the proposal. I am merely stating that
there is nothing inherently inconsistent in it.
Cheers,
V.
--
---
You received this message because you are 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/.
--001a11352d48947a010523e0d925
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Nov 6, 2015 at 12:29 PM, Andrey Semashev <span dir=3D"ltr"><<a href=
=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semashev@gma=
il.com</a>></span> wrote:<br><div><br></div><div>> There is no preced=
ent in the language that a function returning void actually returns an int =
value of 0.</div><div><br></div><div>main cannot be called from another C++=
function without resorting to undefined behaviour, and the meaning of its =
return code is implementation defined. Given all its other special provisio=
ns, especially defaulting to return 0, a void main could be defined as bein=
g equivalent to an int main that returns 0 without any inconsistencies.</di=
v><div><br></div><div>>=C2=A0<span style=3D"font-size:12.8px">The ones w=
ho make the mistake need to realize that every program has to return a valu=
e to the executing process (e.g. a shell)</span></div><div><span style=3D"f=
ont-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">Tha=
t is implementation-specific. If a particular implementation requires a ret=
urn code, the implementation can use a default 'success' code for a=
void main.</span></div><div><br></div><div>Note I am not in favour or agai=
nst the proposal. I am merely stating that there is nothing inherently inco=
nsistent in it.</div><div><br></div><div>Cheers,</div><div>V.</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" 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 />
--001a11352d48947a010523e0d925--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Fri, 6 Nov 2015 18:53:53 +0300
Raw View
On 2015-11-06 18:25, Viacheslav Usov wrote:
> On Fri, Nov 6, 2015 at 12:29 PM, Andrey Semashev
> <andrey.semashev@gmail.com <mailto:andrey.semashev@gmail.com>> wrote:
>
> > There is no precedent in the language that a function returning void
> actually returns an int value of 0.
>
> main cannot be called from another C++ function without resorting to
> undefined behaviour, and the meaning of its return code is
> implementation defined. Given all its other special provisions,
> especially defaulting to return 0, a void main could be defined as being
> equivalent to an int main that returns 0 without any inconsistencies.
IMHO, every special casing regarding main is an unfortunate legacy.
Frankly, I didn't know about the implicit "return 0;", but now that I'm
aware of it, it looks like an ugly hack to me. I think it's not
something that can be called a good practice and adding yet more special
cases about main only makes it worse.
> > The ones who make the mistake need to realize that every program has
> to return a value to the executing process (e.g. a shell)
>
> That is implementation-specific. If a particular implementation requires
> a return code, the implementation can use a default 'success' code for a
> void main.
Thing is, you don't know what is a 'success' code on a particular
platform. The best you could do in the standard is to say that the
actual return code is implementation-specific, which does not help with
portability. Or it could say the return code is 0, whether or not it
counts as success on the current platform. It already does that with
implicit 'return 0;', but to my mind the standard should not make the
decision about the return code for the user.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 6 Nov 2015 09:59:52 -0600
Raw View
--001a113d9cbad730ad0523e15703
Content-Type: text/plain; charset=UTF-8
On 6 November 2015 at 02:12, Jens Maurer <Jens.Maurer@gmx.net> wrote:
> Why doesn't your toolchain reject "void main"?
>
> Other than that, my position on your suggestion is "no, not worth the
> (personal + committee) effort".
>
+1. And it would add yet another incompatibility with C for no good reason.
--
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/.
--001a113d9cbad730ad0523e15703
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 6 November 2015 at 02:12, Jens Maurer <span dir=3D"ltr"=
><<a href=3D"mailto:Jens.Maurer@gmx.net" target=3D"_blank">Jens.Maurer@g=
mx.net</a>></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">Why doesn't your toolchain re=
ject "void main"?<br>
<br>
Other than that, my position on your suggestion is "no, not worth the<=
br>
(personal + committee) effort".<br></blockquote><div><br></div><div>+1=
..=C2=A0 And it would add yet another incompatibility with C for no good rea=
son.</div></div>-- <br><div class=3D"gmail_signature">=C2=A0Nevin ":-)=
" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" tar=
get=3D"_blank">nevin@eviloverlord.com</a>>=C2=A0 (847) 691-1404</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" 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 />
--001a113d9cbad730ad0523e15703--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Fri, 06 Nov 2015 12:35:45 -0500
Raw View
On 2015-11-06 09:48, Evan Teran wrote:
> there is already some special casing for main. For
> example, there is rule that allows omitting the return entirely for main.
> reaching the end of main without a return is currently defined as being
> equivalent to having executed a "return 0;".
Really? For *every other* function returning an int, falling off the end
is UB, but main gets an exception? That exception ought to be taken out
and shot dead...
--
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/.
.
Author: Moritz Klammler <moritz.klammler@gmail.com>
Date: Fri, 06 Nov 2015 18:39:38 +0100
Raw View
>> main cannot be called from another C++ function without resorting to
>> undefined behaviour, and the meaning of its return code is
>> implementation defined. Given all its other special provisions,
>> especially defaulting to return 0, a void main could be defined as
>> being equivalent to an int main that returns 0 without any
>> inconsistencies.
>
> IMHO, every special casing regarding main is an unfortunate
> legacy. Frankly, I didn't know about the implicit "return 0;", but now
> that I'm aware of it, it looks like an ugly hack to me. I think it's
> not something that can be called a good practice and adding yet more
> special cases about main only makes it worse.
I agree with this. I think the "falling off the end of `main` is an
implicit `return 0;`"-rule is an ugly hack. It would have been better
to not have this special rule and instead allow `void main` which would
return a status code indicating success to the environment. However,
the unfortunate rule is already there and it is too late to change this
now. Adding yet another rule doesn't improve the situation.
> Thing is, you don't know what is a 'success' code on a particular
> platform. The best you could do in the standard is to say that the
> actual return code is implementation-specific, which does not help
> with portability. Or it could say the return code is 0, whether or not
> it counts as success on the current platform. It already does that
> with implicit 'return 0;', but to my mind the standard should not make
> the decision about the return code for the user.
I don't think that this is correct. The standard already mandates that
return 0;
and
return EXIT_SUCCESS; // from <cstdlib>
indicate successful termination. How this is translated to the
convention used in the target environment and whether that environment
even has a notion of a program reporting success is a different question
but implementations already have to deal with it today.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 6 Nov 2015 11:50:48 -0600
Raw View
--001a1143026e8cf0860523e2e45c
Content-Type: text/plain; charset=UTF-8
On 6 November 2015 at 11:35, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:
> Really? For *every other* function returning an int, falling off the end
> is UB, but main gets an exception? That exception ought to be taken out
> and shot dead...
>
It came from C. In the early days, there was no such thing as "void" and
all functions had to return something. When it came time to standardize C,
it was more important to codify existing practice in the hopes that vendors
would follow the emerging standard rather than making gratuitously breaking
changes.
In other words, if you don't like this behavior, you should have complained
about it in the 70s & 80s. :-)
--
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/.
--001a1143026e8cf0860523e2e45c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 6 November 2015 at 11:35, Matthew Woehlke <span dir=3D"=
ltr"><<a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoe=
hlke.floss@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Really? For *every =
other* function returning an int, falling off the end<br>
is UB, but main gets an exception? That exception ought to be taken out<br>
and shot dead...<br></blockquote><div><br></div><div>It came from C.=C2=A0 =
In the early days, there was no such thing as "void" and all func=
tions had to return something.=C2=A0 When it came time to standardize C, it=
was more important to codify existing practice in the hopes that vendors w=
ould follow the emerging standard rather than making gratuitously breaking =
changes.</div><div><br></div><div>In other words, if you don't like thi=
s behavior, you should have complained about it in the 70s & 80s. :-)</=
div><div>--=C2=A0<br></div></div><div class=3D"gmail_signature">=C2=A0Nevin=
":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlor=
d.com" target=3D"_blank">nevin@eviloverlord.com</a>>=C2=A0 (847) 691-140=
4</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" 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 />
--001a1143026e8cf0860523e2e45c--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 06 Nov 2015 10:17:07 -0800
Raw View
On Friday 06 November 2015 12:35:45 Matthew Woehlke wrote:
> Really? For *every other* function returning an int, falling off the end
> is UB, but main gets an exception? That exception ought to be taken out
> and shot dead...
main is already special, as you're not allowed to take its address or call it.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "'Johannes Schaub' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Fri, 6 Nov 2015 19:50:09 +0100
Raw View
We should not standardize existing confusion, but existing practice.
Noone informed writes "void main" today, at least I don't see a sane
reason. That would be similar to standardizing namelookup of dependent
names into dependent base classes just because people try to write it
and fall over it. For backward compatibility, you probably have other
difficulties with such code (void main) aswell, such as the ill-formed
conversion of string literals to "char*" introduced by C++11.
In addition to that, one can always write a void main if one wants, in
a different namespace
namespace VoidMain {
void main() {
}
}
int main() {
VoidMain::main();
}
So given that this is a valid workaround (IMO), I think it's not worth
to stadnardize writing the void directly.
2015-11-06 6:26 GMT+01:00 Brian Bi <bbi5291@gmail.com>:
> A lot of people seem to think `void main` is legal and I'm tired of
> constantly correcting them. Why don't we just make it legal? Return from
> `void main` would have the same effect as returning 0 from `int main` (or
> not returning).
>
> After all, there are already two signatures allowed for `main`, so there
> doesn't seem to be any technical reason to not add two more.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Fri, 6 Nov 2015 20:13:49 +0100
Raw View
--001a114444ae1eea7c0523e40b6e
Content-Type: text/plain; charset=UTF-8
On Fri, Nov 6, 2015 at 6:26 AM, Brian Bi <bbi5291@gmail.com> wrote:
> A lot of people seem to think `void main` is legal and I'm tired of
> constantly correcting them. Why don't we just *make* it legal? Return
> from `void main` would have the same effect as returning 0 from `int main`
> (or not returning).
>
> After all, there are already two signatures allowed for `main`, so there
> doesn't seem to be any technical reason to not add two more.
>
The idea of a standard C++ main function has come up before.
Rather than proposing this narrow change, how about proposing new main
signatures that:
1. Takes no arguments, a C++ argument sequence or a C++ argument sequence
and environment. With datatypes that are compatible with the standard
library.
2. Uses C++ exceptions as the standard error handling mechanism (rather
than the return value of main).
3. Provide an exception base type that is convertible to an exit code.
4. The main function has implicit catch handlers for derived types from
point 3, std::exception derived classes, and a catch all. The behavior is
well-defined in all cases.
Such new main function kinds can be easily prototyped by changing the name
to Main (for development) and then providing a wrapper from the current
standard mains.
For example if you intend to propose:
void main();
void main(Args args);
void main(Args args, Env env);
as the new blessed main signatures, you can implement them today as:
void Main();
void Main(Args args);
void Main(Args args, Env env);
and write a wrapper library from int main(...) that calls them. You can
even use weak-linking so that the signature that the user implements is
selected correctly. Once you are happy with this you can write up a formal
proposal to standardize the semantics as new possible "main" (lowercase)
signatures.
--
---
You received this message because you are 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/.
--001a114444ae1eea7c0523e40b6e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Nov 6, 2015 at 6:26 AM, Brian Bi <span dir=3D"ltr"><<a href=3D"mailt=
o:bbi5291@gmail.com" target=3D"_blank">bbi5291@gmail.com</a>></span> wro=
te:<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;padding-left:1ex"><div dir=3D"ltr"><div>A lot of people seem to think=
`void main` is legal and I'm tired of constantly correcting them. Why =
don't we just <b>make</b> it legal? Return from `void main` would have =
the same effect as returning 0 from `int main` (or not returning).<br><br>A=
fter all, there are already two signatures allowed for `main`, so there doe=
sn't seem to be any technical reason to not add two more.<span class=3D=
""><font color=3D"#888888"><br></font></span></div></div></blockquote></div=
><br></div><div class=3D"gmail_extra">The idea of a standard C++ main funct=
ion has come up before.</div><div class=3D"gmail_extra"><br></div><div clas=
s=3D"gmail_extra">Rather than proposing this narrow change, how about propo=
sing new main signatures that:</div><div class=3D"gmail_extra"><br></div><d=
iv class=3D"gmail_extra">1. Takes no arguments, a C++ argument sequence or =
a C++ =C2=A0argument sequence and environment.=C2=A0 With datatypes that ar=
e compatible with the standard library.</div><div class=3D"gmail_extra">2. =
Uses C++ exceptions as the standard error handling mechanism (rather than t=
he return value of main).</div><div class=3D"gmail_extra">3. Provide an exc=
eption base type that is convertible to an exit code.</div><div class=3D"gm=
ail_extra">4. The main function has implicit catch handlers for derived typ=
es from point 3, std::exception derived classes, and a catch all.=C2=A0 The=
behavior is well-defined in all cases.</div><div class=3D"gmail_extra"><br=
></div><div class=3D"gmail_extra">Such new main function kinds can be easil=
y prototyped by changing the name to Main (for development) and then provid=
ing a wrapper from the current standard mains.</div><div class=3D"gmail_ext=
ra"><br></div><div class=3D"gmail_extra">For example if you intend to propo=
se:</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=
=C2=A0 =C2=A0 void main();</div><div class=3D"gmail_extra"><div class=3D"gm=
ail_extra"><div class=3D"gmail_extra">=C2=A0 =C2=A0 void main(Args args);</=
div><div><div class=3D"gmail_extra">=C2=A0 =C2=A0 void main(Args args, Env =
env);</div></div><div><br></div><div>as the new blessed main signatures, yo=
u can implement them today as:</div><div><br></div><div><div class=3D"gmail=
_extra">=C2=A0 =C2=A0 void Main();</div><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_extra">=C2=A0 =C2=A0 void Main(Args =
args);</div><div><div class=3D"gmail_extra">=C2=A0 =C2=A0 void Main(Args ar=
gs, Env env);</div></div><div><br></div><div>and write a wrapper library fr=
om int main(...) that calls them.=C2=A0 You can even use weak-linking so th=
at the signature that the user implements is selected correctly.=C2=A0 Once=
you are happy with this you can write up a formal proposal to standardize =
the semantics as new possible "main" (lowercase) signatures.</div=
><div><br></div><div><br></div></div></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" 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 />
--001a114444ae1eea7c0523e40b6e--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 6 Nov 2015 13:28:15 -0600
Raw View
--001a1143026e0ef8850523e441ca
Content-Type: text/plain; charset=UTF-8
On 6 November 2015 at 13:13, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> 1. Takes no arguments, a C++ argument sequence or a C++ argument sequence
> and environment. With datatypes that are compatible with the standard
> library.
> 2. Uses C++ exceptions as the standard error handling mechanism (rather
> than the return value of main).
> 3. Provide an exception base type that is convertible to an exit code.
> 4. The main function has implicit catch handlers for derived types from
> point 3, std::exception derived classes, and a catch all. The behavior is
> well-defined in all cases.
>
> Such new main function kinds can be easily prototyped by changing the name
> to Main (for development) and then providing a wrapper from the current
> standard mains.
>
If you really believe this is a problem worth solving, you should do
exactly that and put it into your production code bases before proposing
such a complicated beast for the standard.
The signature I might like to see in the future is int
main(std::array_view<std::string_view> args). I don't see any need for the
complicated exception handling scheme, though.
--
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/.
--001a1143026e0ef8850523e441ca
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 6 November 2015 at 13:13, Andrew Tomazos <span dir=3D"l=
tr"><<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrew=
tomazos@gmail.com</a>></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:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span=
class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote">1. Takes =
no arguments, a C++ argument sequence or a C++ =C2=A0argument sequence and =
environment.=C2=A0 With datatypes that are compatible with the standard lib=
rary.<br></div></div></span><div class=3D"gmail_extra">2. Uses C++ exceptio=
ns as the standard error handling mechanism (rather than the return value o=
f main).</div><div class=3D"gmail_extra">3. Provide an exception base type =
that is convertible to an exit code.</div><div class=3D"gmail_extra">4. The=
main function has implicit catch handlers for derived types from point 3, =
std::exception derived classes, and a catch all.=C2=A0 The behavior is well=
-defined in all cases.</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">Such new main function kinds can be easily prototyped by c=
hanging the name to Main (for development) and then providing a wrapper fro=
m the current standard mains.</div></div></blockquote><div><br></div><div>I=
f you really believe this is a problem worth solving, you should do exactly=
that and put it into your production code bases before proposing such a co=
mplicated beast for the standard.</div><div><br></div><div>The signature I =
might like to see in the future is <font face=3D"monospace, monospace" size=
=3D"1">int main(std::array_view<std::string_view> args)</font>.=C2=A0=
I don't see any need for the complicated exception handling scheme, th=
ough.</div></div>-- <br><div class=3D"gmail_signature">=C2=A0Nevin ":-=
)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" ta=
rget=3D"_blank">nevin@eviloverlord.com</a>>=C2=A0 (847) 691-1404</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" 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 />
--001a1143026e0ef8850523e441ca--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Fri, 6 Nov 2015 20:58:56 +0100
Raw View
--001a1149742071f3800523e4ac71
Content-Type: text/plain; charset=UTF-8
On Fri, Nov 6, 2015 at 8:28 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 6 November 2015 at 13:13, Andrew Tomazos <andrewtomazos@gmail.com>
> wrote:
>
>> 1. Takes no arguments, a C++ argument sequence or a C++ argument
>> sequence and environment. With datatypes that are compatible with the
>> standard library.
>> 2. Uses C++ exceptions as the standard error handling mechanism (rather
>> than the return value of main).
>> 3. Provide an exception base type that is convertible to an exit code.
>> 4. The main function has implicit catch handlers for derived types from
>> point 3, std::exception derived classes, and a catch all. The behavior is
>> well-defined in all cases.
>>
>> Such new main function kinds can be easily prototyped by changing the
>> name to Main (for development) and then providing a wrapper from the
>> current standard mains.
>>
>
> If you really believe this is a problem worth solving, you should do
> exactly that and put it into your production code bases before proposing
> such a complicated beast for the standard.
>
Actually, already done. In several different production codebases in
fact. I'm not aware of open source examples though. Notably things like
Qt use a different approach of two-line boilerplate:
int main(int argc, char** argv) {
SomeApplicationObject app(argc,argv);
return app.execute();
}
to do the wrapping.
The signature I might like to see in the future is int
> main(std::array_view<std::string_view> args). I don't see any need for
> the complicated exception handling scheme, though.
>
Sure, thats something for the proposal author to think about during the
design process/research for a proposed standard facility.
The advantage of using exceptions over returned error codes is the same for
main as for any function. The error can be thrown from a nested function
call and it is automatically propogated up the unwound call stack. With
C-style returned error codes the propogation has to be done in a verbose
error-prone fashion "by hand".
For me personally, I don't feel motivated to work on the proposal, because
the non-standard wrapping technique is easy and enough for me - and
something you only have to implement once per codebase. I wouldn't
discourage someone from working on it though, and if they do their homework
and come up with a good (and thorough) design for new standard C++-specific
main signatures/semantics - I would support the proposal. It is, after
all, just a small pure addition.
--
---
You received this message because you are 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/.
--001a1149742071f3800523e4ac71
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Nov 6, 2015 at 8:28 PM, Nevin Liber <span dir=3D"ltr"><<a href=3D"ma=
ilto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span c=
lass=3D"">On 6 November 2015 at 13:13, Andrew Tomazos <span dir=3D"ltr"><=
;<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos=
@gmail.com</a>></span> wrote:<br></span><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><span><div class=3D"gmail_extra"><div class=3D"gmail_quote">1. =
Takes no arguments, a C++ argument sequence or a C++ =C2=A0argument sequenc=
e and environment.=C2=A0 With datatypes that are compatible with the standa=
rd library.<br></div></div></span><div class=3D"gmail_extra">2. Uses C++ ex=
ceptions as the standard error handling mechanism (rather than the return v=
alue of main).</div><div class=3D"gmail_extra">3. Provide an exception base=
type that is convertible to an exit code.</div><div class=3D"gmail_extra">=
4. The main function has implicit catch handlers for derived types from poi=
nt 3, std::exception derived classes, and a catch all.=C2=A0 The behavior i=
s well-defined in all cases.</div><div class=3D"gmail_extra"><br></div><div=
class=3D"gmail_extra">Such new main function kinds can be easily prototype=
d by changing the name to Main (for development) and then providing a wrapp=
er from the current standard mains.</div></div></blockquote><div><br></div>=
</span><div>If you really believe this is a problem worth solving, you shou=
ld do exactly that and put it into your production code bases before propos=
ing such a complicated beast for the standard.</div></div></div></div></blo=
ckquote><div>=C2=A0</div><div>Actually, already done.=C2=A0 In several diff=
erent production codebases in fact.=C2=A0 I'm not aware of open source =
examples though.=C2=A0 Notably things like Qt use a different approach of t=
wo-line boilerplate:</div><div><br></div><div>=C2=A0 =C2=A0int main(int arg=
c, char** argv) {</div><div>=C2=A0 =C2=A0 =C2=A0 SomeApplicationObject app(=
argc,argv);</div><div>=C2=A0 =C2=A0 =C2=A0 return app.execute();</div><div>=
=C2=A0 =C2=A0}</div><div><br></div><div>to do the wrapping.</div><div><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote"><div></div><div>The signature I might like =
to see in the future is <font face=3D"monospace, monospace" size=3D"1">int =
main(std::array_view<std::string_view> args)</font>.=C2=A0 I don'=
t see any need for the complicated exception handling scheme, though.</div>=
</div></div></div></blockquote></div><br></div><div class=3D"gmail_extra">S=
ure, thats something for the proposal author to think about during the desi=
gn process/research for a proposed standard facility.</div><div class=3D"gm=
ail_extra"><br></div><div class=3D"gmail_extra">The advantage of using exce=
ptions over returned error codes is the same for main as for any function.=
=C2=A0 The error can be thrown from a nested function call and it is automa=
tically propogated up the unwound call stack.=C2=A0 With C-style returned e=
rror codes the propogation has to be done in a verbose error-prone fashion =
"by hand".</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">For me personally, I don't feel motivated to work on t=
he proposal, because the non-standard wrapping technique is easy and enough=
for me - and something you only have to implement once per codebase.=C2=A0=
I wouldn't discourage someone from working on it though, and if they d=
o their homework and come up with a good (and thorough) design for new stan=
dard C++-specific main signatures/semantics - I would support the proposal.=
=C2=A0 It is, after all, just a small pure addition.</div><div class=3D"gma=
il_extra"><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" 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 />
--001a1149742071f3800523e4ac71--
.
Author: garet@approachfoundation.org
Date: Fri, 6 Nov 2015 12:12:27 -0800 (PST)
Raw View
------=_Part_1378_1129746870.1446840747875
Content-Type: multipart/alternative;
boundary="----=_Part_1379_12227258.1446840747875"
------=_Part_1379_12227258.1446840747875
Content-Type: text/plain; charset=UTF-8
This seems like a good idea.C++ usually allows you as much flexibility as
it can provide - enough to 'hang yourself with' often being cited. A
variety of C++ features don't seem particularly useful on their own at
first yet people keep finding novel uses we don't anticipate.
I would argue it should return NULL or double NULL. Returning 0 seems like
a typed value.
On Friday, November 6, 2015 at 1:09:10 AM UTC-7, Jonathan Coe wrote:
>
> I often make use of return codes from programs. What would the return code
> from 'void main' be?
>
> Regards
>
> Jonathan
>
> On 6 Nov 2015, at 05:26, Brian Bi <bbi...@gmail.com <javascript:>> wrote:
>
> A lot of people seem to think `void main` is legal and I'm tired of
> constantly correcting them. Why don't we just *make* it legal? Return
> from `void main` would have the same effect as returning 0 from `int main`
> (or not returning).
>
> After all, there are already two signatures allowed for `main`, so there
> doesn't seem to be any technical reason to not add two more.
> --
> *Brian Bi*
>
> --
>
> ---
> You received this message because you are 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-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> 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/.
------=_Part_1379_12227258.1446840747875
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This seems like a good idea.C++ usually allows you as much=
flexibility as it can provide - enough to 'hang yourself with' oft=
en being cited. A variety of C++ features don't seem particularly usefu=
l on their own at first yet people keep finding novel uses we don't ant=
icipate.<br><br>I would argue it should return NULL or double NULL. Returni=
ng 0 seems like a typed value. <br><br>=C2=A0<br><br>On Friday, November 6,=
2015 at 1:09:10 AM UTC-7, Jonathan Coe wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"auto"><div></div><div>I often make use of retur=
n codes from programs. What would the return code from 'void main' =
be?</div><div><br></div><div>Regards</div><div><br></div><div>Jonathan=C2=
=A0</div><div><br>On 6 Nov 2015, at 05:26, Brian Bi <<a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"Dr1oaVuTFQAJ" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">bbi...@gmail.com</a>>=
; wrote:<br><br></div><blockquote type=3D"cite"><div><div dir=3D"ltr"><div>=
A lot of people seem to think `void main` is legal and I'm tired of con=
stantly correcting them. Why don't we just <b>make</b> it legal? Return=
from `void main` would have the same effect as returning 0 from `int main`=
(or not returning).<br><br>After all, there are already two signatures all=
owed for `main`, so there doesn't seem to be any technical reason to no=
t add two more.<br>-- <br><div><div dir=3D"ltr"><div><div dir=3D"ltr"><font=
color=3D"#c0c0c0"><i>Brian Bi</i></font><br></div></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" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
Dr1oaVuTFQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"Dr1oaVuTFQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';ret=
urn true;" onclick=3D"this.href=3D'http://groups.google.com/a/isocpp.or=
g/group/std-proposals/';return true;">http://groups.google.com/a/<wbr>i=
socpp.org/group/std-<wbr>proposals/</a>.<br>
</div></blockquote></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" 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_1379_12227258.1446840747875--
------=_Part_1378_1129746870.1446840747875--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Fri, 06 Nov 2015 15:12:34 -0500
Raw View
On 2015-11-06 13:17, Thiago Macieira wrote:
> On Friday 06 November 2015 12:35:45 Matthew Woehlke wrote:
>> Really? For *every other* function returning an int, falling off the end
>> is UB, but main gets an exception? That exception ought to be taken out
>> and shot dead...
>
> main is already special, as you're not allowed to take its address or call it.
Sure, and I'm not proposing to make "main" completely not-special. Just
saying that *particular* point of special-ness seems excessive and
undesirable.
(That said, I'm not planning to officially propose it; it seems not
likely to happen, and not likely worth the effort.)
--
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/.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Fri, 06 Nov 2015 15:26:28 -0500
Raw View
On 2015-11-06 14:58, Andrew Tomazos wrote:
> Actually, already done. In several different production codebases in
> fact. I'm not aware of open source examples though. Notably things like
> Qt use a different approach of two-line boilerplate:
>
> int main(int argc, char** argv) {
> SomeApplicationObject app(argc,argv);
> return app.execute();
> }
>
> to do the wrapping.
That's... not a great example. Almost all of my Qt-application main()'s
have a bunch of additional logic. Very few actually subclass
QApplication. Most look more like:
int main(...)
{
QApplication app(argc, argv);
MainWindow w;
w.show();
return app.exec();
}
....and then there are the ones that look like:
int main(...)
{
qtCliArgs args;
// Set up CLI options and positional arguments
args.parseOrDie();
QApplication app(args.qtArgc(), args.qtArgv());
// Set application version, organization, etc.
// Other stuff
MainWindow w;
w.show();
return app.exec();
}
....so claiming that your snippet is "boilerplate" isn't entirely true.
At least, not so much that it's common enough that users don't sometimes
need to do something different.
On the same token, you bring up a fair point why having a "C++ main"
isn't necessarily a good idea (it would at least need to be optional).
Although a version that does the minimum possible over the C version
(i.e. array_view of string_view) is probably okay (if nothing else, that
can be made to "decay" somewhat gracefully back into the C version if
that's needed.
I should note that an alternative is to have some library functions that
embody a "typical" implementation of main(), that take a pointer to a
"user main" to be called. This sort of thing could readily encapsulate
e.g. the exception handling ideas proposed, while leaving them opt-in.
(For that matter, you could provide the "C++ main" in this manner. You'd
just still have something like "int main(...) {
std::dispatch_main(&real_main, argc, argv); }".)
--
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/.
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Fri, 6 Nov 2015 21:43:42 +0100
Raw View
--089e0103f0588aafe20523e54c60
Content-Type: text/plain; charset=UTF-8
On Fri, Nov 6, 2015 at 9:26 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:
> On 2015-11-06 14:58, Andrew Tomazos wrote:
> > Actually, already done. In several different production codebases in
> > fact. I'm not aware of open source examples though. Notably things like
> > Qt use a different approach of two-line boilerplate:
> >
> > int main(int argc, char** argv) {
> > SomeApplicationObject app(argc,argv);
> > return app.execute();
> > }
> >
> > to do the wrapping.
>
> That's... not a great example. Almost all of my Qt-application main()'s
> have a bunch of additional logic. Very few actually subclass
> QApplication. Most look more like:
>
> int main(...)
> {
> QApplication app(argc, argv);
> MainWindow w;
> w.show();
> return app.exec();
> }
>
Sure, that's what I meant.
> ...and then there are the ones that look like:
>
> int main(...)
> {
> qtCliArgs args;
> // Set up CLI options and positional arguments
>
> args.parseOrDie();
>
> QApplication app(args.qtArgc(), args.qtArgv());
> // Set application version, organization, etc.
>
> // Other stuff
>
> MainWindow w;
> w.show();
>
> return app.exec();
> }
>
> ...so claiming that your snippet is "boilerplate" isn't entirely true.
> At least, not so much that it's common enough that users don't sometimes
> need to do something different.
>
> On the same token, you bring up a fair point why having a "C++ main"
> isn't necessarily a good idea (it would at least need to be optional).
> Although a version that does the minimum possible over the C version
> (i.e. array_view of string_view) is probably okay (if nothing else, that
> can be made to "decay" somewhat gracefully back into the C version if
> that's needed.
>
The existing C main signatures would remain available, so if you need to do
something weird that isn't covered by the new standard C++ main signatures,
you can use them.
Each program has to define exactly one main functions with exactly one of
the main signatures. The set of possible main signatures would include the
current ones and the new ones. If you define one of the current ones, the
behavior is as it is now. If you define one of the new ones, the main
function has the new semantics.
I should note that an alternative is to have some library functions that
> embody a "typical" implementation of main(), that take a pointer to a
> "user main" to be called. This sort of thing could readily encapsulate
> e.g. the exception handling ideas proposed, while leaving them opt-in.
> (For that matter, you could provide the "C++ main" in this manner. You'd
> just still have something like "int main(...) {
> std::dispatch_main(&real_main, argc, argv); }".)
>
I don't understand. I think just adding new possible main signatures is
the way to go. See above.
--
---
You received this message because you are 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/.
--089e0103f0588aafe20523e54c60
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Nov 6, 2015 at 9:26 PM, Matthew Woehlke <span dir=3D"ltr"><<=
a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss=
@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span cl=
ass=3D"">On 2015-11-06 14:58, Andrew Tomazos wrote:<br>
> Actually, already done.=C2=A0 In several different production codebase=
s in<br>
> fact.=C2=A0 I'm not aware of open source examples though.=C2=A0 No=
tably things like<br>
> Qt use a different approach of two-line boilerplate:<br>
><br>
>=C2=A0 =C2=A0 int main(int argc, char** argv) {<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SomeApplicationObject app(argc,argv);<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0return app.execute();<br>
>=C2=A0 =C2=A0 }<br>
><br>
> to do the wrapping.<br>
<br>
</span>That's... not a great example. Almost all of my Qt-application m=
ain()'s<br>
have a bunch of additional logic. Very few actually subclass<br>
QApplication. Most look more like:<br>
<br>
=C2=A0 int main(...)<br>
=C2=A0 {<br>
=C2=A0 =C2=A0 =C2=A0QApplication app(argc, argv);<br>
=C2=A0 =C2=A0 =C2=A0MainWindow w;<br>
=C2=A0 =C2=A0 =C2=A0w.show();<br>
=C2=A0 =C2=A0 =C2=A0return app.exec();<br>
=C2=A0 }<br></blockquote><div><br></div><div>Sure, that's what I meant.=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
....and then there are the ones that look like:<br>
<br>
=C2=A0 int main(...)<br>
=C2=A0 {<br>
=C2=A0 =C2=A0 qtCliArgs args;<br>
=C2=A0 =C2=A0 // Set up CLI options and positional arguments<br>
<br>
=C2=A0 =C2=A0 args.parseOrDie();<br>
<br>
=C2=A0 =C2=A0 QApplication app(args.qtArgc(), args.qtArgv());<br>
=C2=A0 =C2=A0 // Set application version, organization, etc.<br>
<br>
=C2=A0 =C2=A0 // Other stuff<br>
<br>
=C2=A0 =C2=A0 =C2=A0MainWindow w;<br>
=C2=A0 =C2=A0 =C2=A0w.show();<br>
<br>
=C2=A0 =C2=A0 =C2=A0return app.exec();<br>
=C2=A0 }<br>
<br>
....so claiming that your snippet is "boilerplate" isn't entir=
ely true.<br>
At least, not so much that it's common enough that users don't some=
times<br>
need to do something different.<br>
<br>
On the same token, you bring up a fair point why having a "C++ main&qu=
ot;<br>
isn't necessarily a good idea (it would at least need to be optional).<=
br>
Although a version that does the minimum possible over the C version<br>
(i.e. array_view of string_view) is probably okay (if nothing else, that<br=
>
can be made to "decay" somewhat gracefully back into the C versio=
n if<br>
that's needed.<br></blockquote><div>=C2=A0</div><div>The existing C mai=
n signatures would remain available, so if you need to do something weird t=
hat isn't covered by the new standard C++ main signatures, you can use =
them.</div><div><br></div><div>Each program has to define exactly one main =
functions with exactly one of the main signatures.=C2=A0 The set of possibl=
e main signatures would include the current ones and the new ones.=C2=A0 If=
you define one of the current ones, the behavior is as it is now.=C2=A0 If=
you define one of the new ones, the main function has the new semantics.</=
div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex">
I should note that an alternative is to have some library functions that<br=
>
embody a "typical" implementation of main(), that take a pointer =
to a<br>
"user main" to be called. This sort of thing could readily encaps=
ulate<br>
e.g. the exception handling ideas proposed, while leaving them opt-in.<br>
(For that matter, you could provide the "C++ main" in this manner=
.. You'd<br>
just still have something like "int main(...) {<br>
std::dispatch_main(&real_main, argc, argv); }".)<br></blockquote><=
div><br></div><div>I don't understand.=C2=A0 I think just adding new po=
ssible main signatures is the way to go.=C2=A0 See above.</div><div><br></d=
iv></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" 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 />
--089e0103f0588aafe20523e54c60--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Fri, 06 Nov 2015 15:54:27 -0500
Raw View
On 2015-11-06 15:43, Andrew Tomazos wrote:
> On Fri, Nov 6, 2015 at 9:26 PM, Matthew Woehlke wrote:
>> On the same token, you bring up a fair point why having a "C++ main"
>> isn't necessarily a good idea (it would at least need to be optional).
>> Although a version that does the minimum possible over the C version
>> (i.e. array_view of string_view) is probably okay (if nothing else, that
>> can be made to "decay" somewhat gracefully back into the C version if
>> that's needed.
>=20
> The existing C main signatures would remain available, so if you need to =
do
> something weird that isn't covered by the new standard C++ main signature=
s,
> you can use them.
>=20
> Each program has to define exactly one main functions with exactly one of
> the main signatures. The set of possible main signatures would include t=
he
> current ones and the new ones. If you define one of the current ones, th=
e
> behavior is as it is now. If you define one of the new ones, the main
> function has the new semantics.
>=20
>> I should note that an alternative is to have some library functions that
>> embody a "typical" implementation of main(), that take a pointer to a
>> "user main" to be called. This sort of thing could readily encapsulate
>> e.g. the exception handling ideas proposed, while leaving them opt-in.
>> (For that matter, you could provide the "C++ main" in this manner. You'd
>> just still have something like "int main(...) {
>> std::dispatch_main(&real_main, argc, argv); }".)
>=20
> I don't understand. I think just adding new possible main signatures is
> the way to go. See above.
How would you differentiate between "I want magic exception handling
behavior" vs. not in a function signature? I was thinking more
specifically of that case.
If the only change is to use low-level "C++" types vs. "C" types (i.e.
array_view, string_view vs. char*), then I agree that I don't see an
issue simply providing additional signature options and making the
compiler sort it out.
Aside:
Do compilers=C2=B9 *actually* sort out how to call main() right now? Or do
they just rely on being able to supply arguments that aren't actually
used? Right now I don't think there is a problem if the loader sets up
to call 'int main(int argc, char* argv)' but actually calls 'int
main()'. Things will go badly, however, if what is actually called is
'int main(std::array_view<std::string_view>)', because that's not layout
compatible with "(int, char*)". (I suppose the compiler would just need
to know if it see such a main to rewrite its name and insert a stub with
the C signature to bootstrap the C++ main. Just saying, though...)
(=C2=B9 MSVC probably does; there is already weird stuff happening on that
platform. I'm not sure that's the case across the board, however.)
--=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/.
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Fri, 6 Nov 2015 22:16:00 +0100
Raw View
--001a114974201379b50523e5c0d0
Content-Type: text/plain; charset=UTF-8
On Fri, Nov 6, 2015 at 9:54 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:
> On 2015-11-06 15:43, Andrew Tomazos wrote:
> > On Fri, Nov 6, 2015 at 9:26 PM, Matthew Woehlke wrote:
> >> On the same token, you bring up a fair point why having a "C++ main"
> >> isn't necessarily a good idea (it would at least need to be optional).
> >> Although a version that does the minimum possible over the C version
> >> (i.e. array_view of string_view) is probably okay (if nothing else, that
> >> can be made to "decay" somewhat gracefully back into the C version if
> >> that's needed.
> >
> > The existing C main signatures would remain available, so if you need to
> do
> > something weird that isn't covered by the new standard C++ main
> signatures,
> > you can use them.
> >
> > Each program has to define exactly one main functions with exactly one of
> > the main signatures. The set of possible main signatures would include
> the
> > current ones and the new ones. If you define one of the current ones,
> the
> > behavior is as it is now. If you define one of the new ones, the main
> > function has the new semantics.
> >
> >> I should note that an alternative is to have some library functions that
> >> embody a "typical" implementation of main(), that take a pointer to a
> >> "user main" to be called. This sort of thing could readily encapsulate
> >> e.g. the exception handling ideas proposed, while leaving them opt-in.
> >> (For that matter, you could provide the "C++ main" in this manner. You'd
> >> just still have something like "int main(...) {
> >> std::dispatch_main(&real_main, argc, argv); }".)
> >
> > I don't understand. I think just adding new possible main signatures is
> > the way to go. See above.
>
> How would you differentiate between "I want magic exception handling
> behavior" vs. not in a function signature? I was thinking more
> specifically of that case.
>
You wouldn't. If you pick one of the new signatures you get the new
semantics. If you pick one of the old signatures you get the old
semantics. What exactly the new signatures and new semantics are, is the
job of the proposal author to design. Whatever it is will need be good
enough to get a supermajority of committee votes to be adopted.
If the only change is to use low-level "C++" types vs. "C" types (i.e.
> array_view, string_view vs. char*), then I agree that I don't see an
> issue simply providing additional signature options and making the
> compiler sort it out.
>
I don't see anything special about the new semantics including a definition
of what happens on an uncaught exception.
--
---
You received this message because you are 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/.
--001a114974201379b50523e5c0d0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Nov 6, 2015 at 9:54 PM, Matthew Woehlke <span dir=3D"ltr"><<=
a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss=
@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2015-=
11-06 15:43, Andrew Tomazos wrote:<br>
<span class=3D"">> On Fri, Nov 6, 2015 at 9:26 PM, Matthew Woehlke wrote=
:<br>
>> On the same token, you bring up a fair point why having a "C+=
+ main"<br>
>> isn't necessarily a good idea (it would at least need to be op=
tional).<br>
>> Although a version that does the minimum possible over the C versi=
on<br>
>> (i.e. array_view of string_view) is probably okay (if nothing else=
, that<br>
>> can be made to "decay" somewhat gracefully back into the=
C version if<br>
>> that's needed.<br>
><br>
> The existing C main signatures would remain available, so if you need =
to do<br>
> something weird that isn't covered by the new standard C++ main si=
gnatures,<br>
> you can use them.<br>
><br>
> Each program has to define exactly one main functions with exactly one=
of<br>
> the main signatures.=C2=A0 The set of possible main signatures would i=
nclude the<br>
> current ones and the new ones.=C2=A0 If you define one of the current =
ones, the<br>
> behavior is as it is now.=C2=A0 If you define one of the new ones, the=
main<br>
> function has the new semantics.<br>
><br>
>> I should note that an alternative is to have some library function=
s that<br>
>> embody a "typical" implementation of main(), that take a=
pointer to a<br>
>> "user main" to be called. This sort of thing could readi=
ly encapsulate<br>
>> e.g. the exception handling ideas proposed, while leaving them opt=
-in.<br>
>> (For that matter, you could provide the "C++ main" in th=
is manner. You'd<br>
>> just still have something like "int main(...) {<br>
>> std::dispatch_main(&real_main, argc, argv); }".)<br>
><br>
> I don't understand.=C2=A0 I think just adding new possible main si=
gnatures is<br>
> the way to go.=C2=A0 See above.<br>
<br>
</span>How would you differentiate between "I want magic exception han=
dling<br>
behavior" vs. not in a function signature? I was thinking more<br>
specifically of that case.<br></blockquote><div>=C2=A0</div><div>You wouldn=
't.=C2=A0 If you pick one of the new signatures you get the new semanti=
cs.=C2=A0 If you pick one of the old signatures you get the old semantics.=
=C2=A0 What exactly the new signatures and new semantics are, is the job of=
the proposal author to design.=C2=A0 Whatever it is will need be good enou=
gh to get a supermajority of committee votes to be adopted.</div><div><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
If the only change is to use low-level "C++" types vs. "C&qu=
ot; types (i.e.<br>
array_view, string_view vs. char*), then I agree that I don't see an<br=
>
issue simply providing additional signature options and making the<br>
compiler sort it out.<br></blockquote><div><br></div><div>I don't see a=
nything special about the new semantics including a definition of what happ=
ens on an uncaught exception.</div><div><br></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" 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 />
--001a114974201379b50523e5c0d0--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Fri, 6 Nov 2015 22:20:14 +0100
Raw View
--001a1144493838c1020523e5cf14
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Fri, Nov 6, 2015 at 9:54 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:
> Do compilers=C2=B9 *actually* sort out how to call main() right now?
I'm not sure I understand the question. Implementations provide an
implicitly-linked library that contains an entry point (that isn't main).
The program is loaded into memory and then there is a jump instruction to
the entry point. Code starts executing that sets up the "enviornment",
performs dynamic initialization, etc, and then once that is done, main is
executed like any other function. Likewise on the other-side there is
teardown code.
--=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/.
--001a1144493838c1020523e5cf14
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Nov 6, 2015 at 9:54 PM, Matthew Woehlke <span dir=3D"ltr"><<=
a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss=
@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Do compi=
lers=C2=B9 *actually* sort out how to call main() right now?</blockquote><d=
iv><br></div><div>I'm not sure I understand the question.=C2=A0 Impleme=
ntations provide an implicitly-linked library that contains an entry point =
(that isn't main).=C2=A0 The program is loaded into memory and then the=
re is a jump instruction to the entry point.=C2=A0 Code starts executing th=
at sets up the "enviornment", performs dynamic initialization, et=
c, and then once that is done, main is executed like any other function.=C2=
=A0 Likewise on the other-side there is teardown code.</div><div><br></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" 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 />
--001a1144493838c1020523e5cf14--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Fri, 06 Nov 2015 16:34:25 -0500
Raw View
On 2015-11-06 16:20, Andrew Tomazos wrote:
> On Fri, Nov 6, 2015 at 9:54 PM, Matthew Woehlke wrote:
>> Do compilers=C2=B9 *actually* sort out how to call main() right now?
>=20
> I'm not sure I understand the question. Implementations provide an
> implicitly-linked library that contains an entry point (that isn't main).
> The program is loaded into memory and then there is a jump instruction to
> the entry point. Code starts executing that sets up the "enviornment",
> performs dynamic initialization, etc, and then once that is done, main is
> executed like any other function. Likewise on the other-side there is
> teardown code.
And does that code *differ* depending on whether main is 'int main()' or
'int main(int argc, char** argv)' or... etc.? Right now, depending on
the ABI of main, I don't think it needs to; the existing variants share
a common initial sequence of arguments, so if the callee (i.e. main)
receives 3 arguments but only wanted 2, it doesn't matter. It *will*
matter if main wants (std::array_view<std::string_view>) and gets (int,
char**), i.e. the loader code ("true" entry point) will newly have to be
different depending on the signature of main. (Or else rename the user's
main to inject an additional bootstrap layer.)
As I said, that's *probably* not an issue... just pointing it out.
--=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/.
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Fri, 6 Nov 2015 22:53:48 +0100
Raw View
Am 06.11.2015 um 22:34 schrieb Matthew Woehlke:
> On 2015-11-06 16:20, Andrew Tomazos wrote:
>> On Fri, Nov 6, 2015 at 9:54 PM, Matthew Woehlke wrote:
>>> Do compilers=C2=B9 *actually* sort out how to call main() right now?
>> I'm not sure I understand the question. Implementations provide an
>> implicitly-linked library that contains an entry point (that isn't main)=
..
>> The program is loaded into memory and then there is a jump instruction t=
o
>> the entry point. Code starts executing that sets up the "enviornment",
>> performs dynamic initialization, etc, and then once that is done, main i=
s
>> executed like any other function. Likewise on the other-side there is
>> teardown code.
> And does that code *differ* depending on whether main is 'int main()' or
> 'int main(int argc, char** argv)' or... etc.? Right now, depending on
> the ABI of main, I don't think it needs to; the existing variants share
> a common initial sequence of arguments, so if the callee (i.e. main)
> receives 3 arguments but only wanted 2, it doesn't matter. It *will*
> matter if main wants (std::array_view<std::string_view>) and gets (int,
> char**), i.e. the loader code ("true" entry point) will newly have to be
> different depending on the signature of main. (Or else rename the user's
> main to inject an additional bootstrap layer.)
>
> As I said, that's *probably* not an issue... just pointing it out.
>
It obviously differs but that doesn't matter. What the "true" entry=20
point looks like is irrelevant because it is never the main you write=20
and has a single platform specific signature. At some point along the=20
loading process the system calls a compiler generated function, which=20
also has a fixed signature, which calls static constructors, then your=20
main, then static destructors. The step where it calls main() is=20
obviously dependent on main's signature but that's just part of the=20
initialization code the compiler has to generate for every program. Some=20
systems allow you to replace the "true" entry point but at that point=20
you might as well throw away your sanity.
--=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/.
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Fri, 6 Nov 2015 13:59:00 -0800
Raw View
--001a11440b00df343e0523e6591a
Content-Type: text/plain; charset=UTF-8
On Fri, Nov 6, 2015 at 7:59 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 6 November 2015 at 02:12, Jens Maurer <Jens.Maurer@gmx.net> wrote:
>
>> Why doesn't your toolchain reject "void main"?
>>
>> Other than that, my position on your suggestion is "no, not worth the
>> (personal + committee) effort".
>>
>
> +1. And it would add yet another incompatibility with C for no good
> reason.
>
Allowing code that is not valid C to be valid C++ does not add an
incompatibility with C.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11440b00df343e0523e6591a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Nov 6, 2015 at 7:59 AM, Nevin Liber <span dir=3D"ltr"><<a href=3D"ma=
ilto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span c=
lass=3D"">On 6 November 2015 at 02:12, Jens Maurer <span dir=3D"ltr"><<a=
href=3D"mailto:Jens.Maurer@gmx.net" target=3D"_blank">Jens.Maurer@gmx.net<=
/a>></span> wrote:<br></span><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><span class=3D""><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Why doesn't =
your toolchain reject "void main"?<br>
<br>
Other than that, my position on your suggestion is "no, not worth the<=
br>
(personal + committee) effort".<br></blockquote><div><br></div></span>=
<div>+1.=C2=A0 And it would add yet another incompatibility with C for no g=
ood reason.</div></div></div></div></blockquote><div><br></div><div>Allowin=
g code that is not valid C to be valid C++ does not add an incompatibility =
with C.</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" 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 />
--001a11440b00df343e0523e6591a--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 06 Nov 2015 14:48:45 -0800
Raw View
On Friday 06 November 2015 12:12:27 garet@approachfoundation.org wrote:
> I would argue it should return NULL or double NULL. Returning 0 seems like
> a typed value.
What's a double NULL? Are you talking about std::tuple<nullptr, nullptr> ?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 06 Nov 2015 15:03:30 -0800
Raw View
On Friday 06 November 2015 15:54:27 Matthew Woehlke wrote:
> Do compilers=C2=B9 *actually* sort out how to call main() right now?=20
Usually, the platform runtime takes care of calling main. The compiler just=
=20
generates a regular C function of name "main" to be called by the runtime. =
On=20
Windows, that's called from WinMain; on Unix systems, there's some kind of=
=20
low-level assembly that calls your main function.
However, compilers *do* treat main specially. For example, take the output =
of=20
these two otherwise identical functions with the ICC compiler:
int f() { return 0; }
int main() { return 0; }
Assembly output: http://goo.gl/5ich8D
> Or do
> they just rely on being able to supply arguments that aren't actually
> used?=20
I think virtually all of them do, since all the C compilers were built with=
=20
the ability to call functions without prototypes and with variadic paramete=
rs.=20
It's possible for some specialised compiler to detect which type of main() =
you=20
have and bring in different runtimes, but I've never seen one.
> Right now I don't think there is a problem if the loader sets up
> to call 'int main(int argc, char* argv)' but actually calls 'int
> main()'. Things will go badly, however, if what is actually called is
> 'int main(std::array_view<std::string_view>)', because that's not layout
> compatible with "(int, char*)". (I suppose the compiler would just need
> to know if it see such a main to rewrite its name and insert a stub with
> the C signature to bootstrap the C++ main. Just saying, though...)
Right, which it could do, as we've seen that
a) compilers already do generate different code for main
b) you cannot call back into main or take its address
But which std::array_view are we talking about? The one that comes with=20
libstdc++, the one in libc++ or the one in Dinkumware? There are some=20
platforms where you *can* select which Standard Library to use one may not =
be=20
layout-compatible with the other.
--=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/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 06 Nov 2015 15:05:19 -0800
Raw View
On Friday 06 November 2015 14:48:45 Thiago Macieira wrote:
> On Friday 06 November 2015 12:12:27 garet@approachfoundation.org wrote:
> > I would argue it should return NULL or double NULL. Returning 0 seems like
> > a typed value.
>
> What's a double NULL? Are you talking about std::tuple<nullptr, nullptr> ?
I meant std::tuple<std::nullptr_t, std::nullptr_t>.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Sat, 7 Nov 2015 14:40:35 +0100
Raw View
--047d7b5d4a7e3ecd710523f381ef
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Fri, Nov 6, 2015 at 9:54 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:
[...]
> (=C2=B9 MSVC probably does; there is already weird stuff happening on tha=
t
platform.
Not really, even though the details have changed over time. main is pretty
much a regular function with (implicit) "C" linkage called by the runtime.
Because of the "C" linkage, it can in fact be defined with arbitrary
argument and return types. In case of the void return type, it returns 0,
probably via the implicit return 0 machinery.
Cheers,
V.
--=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/.
--047d7b5d4a7e3ecd710523f381ef
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Nov 6, 2015 at 9:54 PM, Matthew Woehlke <span dir=3D"ltr"><<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>></span> wrote:<br><div><br></div><div>[...]</div><div><br></div=
><div>> (=C2=B9 MSVC probably does; there is already weird stuff happeni=
ng on that platform.</div><div><br></div><div>Not really, even though the d=
etails have changed over time. main is pretty much a regular function with =
(implicit) "C" linkage called by the runtime. Because of the &quo=
t;C" linkage, it can in fact be defined with arbitrary argument and re=
turn types. In case of the void return type, it returns 0, probably via the=
implicit return 0 machinery.</div><div><br></div><div>Cheers,</div><div>V.=
</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" 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 />
--047d7b5d4a7e3ecd710523f381ef--
.
Author: Myriachan <myriachan@gmail.com>
Date: Mon, 9 Nov 2015 14:17:22 -0800 (PST)
Raw View
------=_Part_1949_1274296685.1447107442932
Content-Type: multipart/alternative;
boundary="----=_Part_1950_495829900.1447107442932"
------=_Part_1950_495829900.1447107442932
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, November 6, 2015 at 3:03:35 PM UTC-8, Thiago Macieira wrote:
>
> On Friday 06 November 2015 15:54:27 Matthew Woehlke wrote:=20
> > Do compilers=C2=B9 *actually* sort out how to call main() right now?=20
>
> Usually, the platform runtime takes care of calling main. The compiler=20
> just=20
> generates a regular C function of name "main" to be called by the runtime=
..=20
> On=20
> Windows, that's called from WinMain; on Unix systems, there's some kind o=
f=20
> low-level assembly that calls your main function.=20
>
>
The above is more about Visual C++ than Windows in general. Windows, like=
=20
Linux and many other UNIXes, doesn't care at all about your main()=20
function. The executable contains a pointer to the entry point. The entry=
=20
point is code defined by the implementation, and it's coded to call a=20
C-linkage function named main() and returning int. Accordingly, you=20
sometimes see code that puts extern "C" on main.
In Visual C++, there are several possible entry points, controllable by the=
=20
linker options or the source code. Each entry point corresponds to a=20
programmer-level entry point in the form of a C function. For main(), the=
=20
actual entry point is mainCRTStartup, part of the Visual C++ C runtime=20
library. That is the standard-compliant one. Others include wmain=20
(wmainCRTStartup), WinMain (WinMainCRTStartup), wWinMain=20
(wWinMainCRTStartup), and DllMain (DllMainCRTStartup). Each of these entry=
=20
point types ends up with a different programmer-implemented "main"=20
function, rather than a function actually named main().
WinMain() is used instead of main() with non-Unicode programs that are=20
GUI-based instead of console-based. WinMain() is not the actual entry=20
point; WinMainCRTStartup is in that case.
In Windows, information is lost if you use main(): you get a lossy=20
conversion of the command line to the active code page. You have to use=20
wmain() if you want to see the actual command line. wmain() is like this:
extern "C" int __cdecl wmain(int argc, wchar_t **argv, wchar_t **envp);
The extern "C" and __cdecl aren't really needed, because Visual C++=20
special-cases those names, just like with main(), to always be C and=20
__cdecl linkage. The third parameter is Visual C++-specific. The compiler=
=20
uses __cdecl so that the C runtime can call main/wmain with the envp=20
parameter regardless of whether the program has that parameter. =20
(Similarly, the Standard allows omitting the standard argc and argv=20
parameters, and __cdecl facilitates that as well).
Just wanted to give a Windows perspective on this.
Melissa
--=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_1950_495829900.1447107442932
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, November 6, 2015 at 3:03:35 PM UTC-8, Thiago Ma=
cieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Friday 06 Nove=
mber 2015 15:54:27 Matthew Woehlke wrote:
<br>> Do compilers=C2=B9 *actually* sort out how to call main() right no=
w?=20
<br>
<br>Usually, the platform runtime takes care of calling main. The compiler =
just=20
<br>generates a regular C function of name "main" to be called by=
the runtime. On=20
<br>Windows, that's called from WinMain; on Unix systems, there's s=
ome kind of=20
<br>low-level assembly that calls your main function.
<br>
<br></blockquote><div><br>The above is more about Visual C++ than Windows i=
n general.=C2=A0 Windows, like Linux and many other UNIXes, doesn't car=
e at all about your main() function.=C2=A0 The executable contains a pointe=
r to the entry point.=C2=A0 The entry point is code defined by the implemen=
tation, and it's coded to call a C-linkage function named main() and re=
turning int.=C2=A0 Accordingly, you sometimes see code that puts extern &qu=
ot;C" on main.<br><br>In Visual C++, there are several possible entry =
points, controllable by the linker options or the source code.=C2=A0 Each e=
ntry point corresponds to a programmer-level entry point in the form of a C=
function.=C2=A0 For main(), the actual entry point is mainCRTStartup, part=
of the Visual C++ C runtime library.=C2=A0 That is the standard-compliant =
one.=C2=A0 Others include wmain (wmainCRTStartup), WinMain (WinMainCRTStart=
up), wWinMain (wWinMainCRTStartup), and DllMain (DllMainCRTStartup).=C2=A0 =
Each of these entry point types ends up with a different programmer-impleme=
nted "main" function, rather than a function actually named main(=
).<br><br>WinMain() is used instead of main() with non-Unicode programs tha=
t are GUI-based instead of console-based.=C2=A0 WinMain() is not the actual=
entry point; WinMainCRTStartup is in that case.<br><br>In Windows, informa=
tion is lost if you use main(): you get a lossy conversion of the command l=
ine to the active code page.=C2=A0 You have to use wmain() if you want to s=
ee the actual command line.=C2=A0 wmain() is like this:<br><br>extern "=
;C" int __cdecl wmain(int argc, wchar_t **argv, wchar_t **envp);<br><b=
r>The extern "C" and __cdecl aren't really needed, because Vi=
sual C++ special-cases those names, just like with main(), to always be C a=
nd __cdecl linkage.=C2=A0 The third parameter is Visual C++-specific.=C2=A0=
The compiler uses __cdecl so that the C runtime can call main/wmain with t=
he envp parameter regardless of whether the program has that parameter.=C2=
=A0 (Similarly, the Standard allows omitting the standard argc and argv par=
ameters, and __cdecl facilitates that as well).<br><br>Just wanted to give =
a Windows perspective on this.<br><br>Melissa<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" 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_1950_495829900.1447107442932--
------=_Part_1949_1274296685.1447107442932--
.