------=_Part_2241_896794695.1416858705845
Content-Type: multipart/alternative;
 boundary="----=_Part_2242_1388204219.1416858705846"

------=_Part_2242_1388204219.1416858705846
Content-Type: text/plain; charset=UTF-8

I think that the Standard ought to permit something that I do anyway, which
is const-qualify main's argv parameter:

int main(int argc, const char *const *argv);

Currently, only () and (int, char **) are permitted.


Other things I feel about main():

1. I think that the Standard ought to say that explicitly specifying the
linkage of main is permissible, but only if it matches the implementation's
use of main().  E.g., the following would be permissible on compilers that
choose to make main extern "C":

extern "C" int main();

In practice, this is already the case.  Calling-convention specifiers are
also permitted in practice as well, but this is a linkage thing anyway.
(MSVC permits extern "C" int __cdecl main(int, char *[]), with __cdecl
being significant in that environment.)


2. I think that there ought to be the ability to have main() take
parameters of type other than char characters:

int main(int argc, char *argv[]);
int wmain(int argc, wchar_t *argv[]);
int c16main(int argc, char16_t *argv[]);
int c32main(int argc, char32_t *argv[]);

Melissa

--

---
You received this message because you are 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_2242_1388204219.1416858705846
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think that the Standard ought to permit something that I=
 do anyway, which is <span style=3D"font-family: courier new,monospace;">co=
nst</span>-qualify <span style=3D"font-family: courier new,monospace;">main=
</span>'s <span style=3D"font-family: courier new,monospace;">argv</span> p=
arameter:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(=
250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bord=
er-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> m=
ain</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> argc</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">char</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
*</span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">argv</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br></span></div></code></div><br>Currently, o=
nly <span style=3D"font-family: courier new,monospace;">()</span> and <span=
 style=3D"font-family: courier new,monospace;">(int, char **)</span> are pe=
rmitted.<br><br><br>Other things I feel about <span style=3D"font-family: c=
ourier new,monospace;">main()</span>:<br><br>1. I think that the Standard o=
ught to say that explicitly specifying the linkage of main is permissible, =
but only if it matches the implementation's use of <span style=3D"font-fami=
ly: courier new,monospace;">main()</span>.&nbsp; E.g., the following would =
be permissible on compilers that choose to make main <span style=3D"font-fa=
mily: courier new,monospace;">extern "C"</span>:<br><br><div class=3D"prett=
yprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(18=
7, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word=
;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D=
"color: #008;" class=3D"styled-by-prettify">extern</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;=
" class=3D"styled-by-prettify">"C"</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> main</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span></div></code></div><br>In practice, this is already the case.&nbsp; =
Calling-convention specifiers are also permitted in practice as well, but t=
his is a linkage thing anyway.&nbsp; (MSVC permits <span style=3D"font-fami=
ly: courier new,monospace;">extern "C" int __cdecl main(int, char *[])</spa=
n>, with <span style=3D"font-family: courier new,monospace;">__cdecl</span>=
 being significant in that environment.)<br><br><br>2. I think that there o=
ught to be the ability to have main() take parameters of type other than <s=
pan style=3D"font-family: courier new,monospace;">char</span> characters:<b=
r><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 2=
50); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1=
px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpr=
ettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">int</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> main</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> argc</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">char</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify">argv</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">[]);</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> wmain</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> argc</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>wchar_t</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">argv</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">[]);</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color:=
 #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> c16main</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> argc</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> c=
har16_t </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">argv</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">[]);</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> c32main</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> argc</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> char32_t </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>argv</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[]);<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
</div></code></div><br>Melissa<br><br></div>

<p></p>

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

------=_Part_2242_1388204219.1416858705846--
------=_Part_2241_896794695.1416858705845--

.

Why not allow the second parameter to be a std::array<std::string>, or
some other variation?

--

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

.

On 2014-11-24 15:53, Douglas Boffey wrote:
> Why not allow the second parameter to be a std::array<std::string>, or
> some other variation?

I take it you mean std::vector<std::string>...

The obvious reason is that changing the qualifiers is just a matter of
what the compiler lets you do with the variable and its contents; the
memory contents are exactly the same. Changing to std::string would
require changes to how the entry point is called (and the loader would
need to know what flavor of entry point it is calling, etc.).

I also seem to recall some discussion on this point previously and it
turning into a can of worms...

Changing the standard to explicitly allow something that works anyway is
much more straight forward.

--
Matthew

--

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

.

On Monday 24 November 2014 11:51:45 Myriachan wrote:
> I think that the Standard ought to permit something that I do anyway, which
> is const-qualify main's argv parameter:
>
> int main(int argc, const char *const *argv);
>
> Currently, only () and (int, char **) are permitted.

Why? The reason why it's not const is because the data is actually modifiable.
If you don't want to modify it, you don't have to, but why should the
signature be changed?

> Other things I feel about main():
>
> 1. I think that the Standard ought to say that explicitly specifying the
> linkage of main is permissible, but only if it matches the implementation's
> use of main().  E.g., the following would be permissible on compilers that
> choose to make main extern "C":
>
> extern "C" int main();

In other words, any such thing will only appear in a header supplied by the
compiler, since the compiler is the only thing that knows what the
implementation's definition of main is. So what's the point?

Remember: you cannot take the address of main() or call main() again.

> 2. I think that there ought to be the ability to have main() take
> parameters of type other than char characters:
>
> int main(int argc, char *argv[]);
> int wmain(int argc, wchar_t *argv[]);
> int c16main(int argc, char16_t *argv[]);
> int c32main(int argc, char32_t *argv[]);

I like this idea, to an extent. It would solve the problems of data loss on a
main() function on Windows by allowing us to have a portable Unicode entry
point.

But I don't think this will work, due to runtime and possible data loss issues
elsewhere. Having two possibilities is difficult, but possible. Having four is
very difficult, not to mention what would happen if more than one of those is
provided in a given program.

In order to make the above work on a generic Unix system, you'd probably do:
 1) provide a weak main() function that converts from the locale's 8-bit
encoding to UCS-4 and call c32main()
 2) provide a weak c32main() that converts from UCS-4 to UTF-16 and call
c16main()
 3) provide a weak c16main() that converts from UTF-16 to wchar_t (somehow,
since the standard does not provide a function to do that) and then calls
wmain()

Note that the error message for forgetting the any of the four variants is
that wmain is not defined.

On Windows, it would be like this:
 1) provide a weak wmain() that does a reinterpret_cast and calls c16main()
 2) provide a weak c16main() that does the conversion to UCS-4 and calls
c32main()
 3) provide a weak c32main() that converts to ANSI and calls main()

And all along it would allocate more memory for the conversions (well, the
UCS-4 to UTF-16 conversion can be done in-place).

What's more, you also lose the ability to edit the program arguments. On
Linux, if you modify the argv array, the changes are reflected on the output of
ps, but only the 8-bit version.

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

.

On Monday 24 November 2014 19:56:58 Thiago Macieira wrote:
> In order to make the above work on a generic Unix system, you'd probably do:
> 1) provide a weak main() function that converts from the locale's 8-bit
> encoding to UCS-4 and call c32main()
>  2) provide a weak c32main() that converts from UCS-4 to UTF-16 and call
> c16main()
>  3) provide a weak c16main() that converts from UTF-16 to wchar_t (somehow,
> since the standard does not provide a function to do that) and then calls
> wmain()
>
> Note that the error message for forgetting the any of the four variants is
> that wmain is not defined.
>
> On Windows, it would be like this:
>  1) provide a weak wmain() that does a reinterpret_cast and calls c16main()
>  2) provide a weak c16main() that does the conversion to UCS-4 and calls
> c32main()
>  3) provide a weak c32main() that converts to ANSI and calls main()

Actually, the only way this would work is if the compiler emitted an external
symbol called "main" whenever it saw one of those four functions.
Unfortunately, it doesn't solve this problem:

> And all along it would allocate more memory for the conversions (well, the
> UCS-4 to UTF-16 conversion can be done in-place).

This still requires allocating memory, which may fail. And it requires knowing
what the system locale is in order to convert from 8-bit, before the first line
of user code...

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

--

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

.

------=_Part_1415_754397550.1416947795286
Content-Type: multipart/alternative;
 boundary="----=_Part_1416_416170962.1416947795286"

------=_Part_1416_416170962.1416947795286
Content-Type: text/plain; charset=UTF-8

On Monday, November 24, 2014 9:28:40 PM UTC-8, Thiago Macieira wrote:
>
> > Note that the error message for forgetting the any of the four variants
> is
> > that wmain is not defined.
> >
> > On Windows, it would be like this:
> >  1) provide a weak wmain() that does a reinterpret_cast and calls
> c16main()
> >  2) provide a weak c16main() that does the conversion to UCS-4 and calls
> > c32main()
> >  3) provide a weak c32main() that converts to ANSI and calls main()
>
>
Visual Studio already has a wmain(), which is why I pointed this out.  Note
that in Windows, main() is a compiler concept, not a system one; this is
comparable to "start" of crt0.o on the major POSIX systems.

extern "C" int __cdecl wmain();
extern "C" int __cdecl wmain(int argc, wchar_t **argv);
extern "C" int __cdecl wmain(int argc, wchar_t **argv, wchar_t **envp);

Actually, the only way this would work is if the compiler emitted an
> external
> symbol called "main" whenever it saw one of those four functions.
> Unfortunately, it doesn't solve this problem:
>
>
How Microsoft's compiler works is that the compiler emits a linker
directive into the .obj file if it sees a function named ::wmain defined.
Specifically, it emits /ENTRY:wmainCRTStartup to change the entry point of
the module to wmainCRTStartup().  wmainCRTStartup() is the "start"
equivalent in Windows.  mainCRTStartup(), the default, calls main(), and
wmainCRTStartup() calls wmain().  mainCRTStartup() handles any conversion
if required.  If c16main() or c32main() existed, they likely would be based
upon a similar model.  wmainCRTStartup would likely use a hack to call
c16main so as to avoid a 4th copy of the startup code.

> And all along it would allocate more memory for the conversions (well,
> the
> > UCS-4 to UTF-16 conversion can be done in-place).
>
> This still requires allocating memory, which may fail. And it requires
> knowing
> what the system locale is in order to convert from 8-bit, before the first
> line
> of user code...
>
>
Systems generally have code before either main() or the global constructors
anyway.  It's already the case that in Windows, using main() instead of
wmain() loses information from the command line due to the system code
page/locale.  Windows has to allocate memory for the argv buffer
regardless, because Windows has command lines as a singe string, and the C
runtime library needs to split it up into argv format.

POSIX systems have less to worry about.

Perhaps wmain(), c16main() and c32main() could be optional but recommended
in the Standard?  In other words, specifying (figuratively), "if these
entry points do exist, they function as the following...".

Melissa

--

---
You received this message because you are 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_1416_416170962.1416947795286
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, November 24, 2014 9:28:40 PM UTC-8, Thiago Maci=
eira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; Note that the =
error message for forgetting the any of the four variants is=20
<br>&gt; that wmain is not defined.
<br>&gt;=20
<br>&gt; On Windows, it would be like this:
<br>&gt; &nbsp;1) provide a weak wmain() that does a reinterpret_cast and c=
alls c16main()
<br>&gt; &nbsp;2) provide a weak c16main() that does the conversion to UCS-=
4 and calls=20
<br>&gt; c32main()
<br>&gt; &nbsp;3) provide a weak c32main() that converts to ANSI and calls =
main()
<br>
<br></blockquote><div><br>Visual Studio already has a <span style=3D"font-f=
amily: courier new,monospace;">wmain()</span>, which is why I pointed this =
out.&nbsp; Note that in Windows, <span style=3D"font-family: courier new,mo=
nospace;">main()</span> is a compiler concept, not a system one; this is co=
mparable to "start" of <span style=3D"font-family: courier new,monospace;">=
crt0.o</span> on the major POSIX systems.<br><br><div class=3D"prettyprint"=
 style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187,=
 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><cod=
e class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color:=
 #008;" class=3D"styled-by-prettify">extern</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=
=3D"styled-by-prettify">"C"</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> __cdecl wmain</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span><span style=3D"color: #008;" class=3D"styled-by-prettify">extern</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #080;" class=3D"styled-by-prettify">"C"</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> __cdecl wmain</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> argc</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">wcha=
r_t</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">**</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">argv</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">extern</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"=
styled-by-prettify">"C"</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> __=
cdecl wmain</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> argc</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">wchar_t</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">**</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">argv</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">wchar_=
t</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">**</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">envp</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br></span></div></code></div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">Actually, the only way this wo=
uld work is if the compiler emitted an external=20
<br>symbol called "main" whenever it saw one of those four functions.=20
<br>Unfortunately, it doesn't solve this problem:
<br>
<br></blockquote><div><br>How Microsoft's compiler works is that the compil=
er emits a linker directive into the <span style=3D"font-family: courier ne=
w,monospace;">.obj</span> file if it sees a function named <span style=3D"f=
ont-family: courier new,monospace;">::wmain</span> defined.&nbsp; Specifica=
lly, it emits <span style=3D"font-family: courier new,monospace;">/ENTRY:wm=
ainCRTStartup</span> to change the entry point of the module to <span style=
=3D"font-family: courier new,monospace;">wmainCRTStartup()</span>.&nbsp; <s=
pan style=3D"font-family: courier new,monospace;">wmainCRTStartup()</span> =
is the "start" equivalent in Windows.&nbsp; <span style=3D"font-family: cou=
rier new,monospace;">mainCRTStartup()</span>, the default, calls <span styl=
e=3D"font-family: courier new,monospace;">main()</span>, and <span style=3D=
"font-family: courier new,monospace;">wmainCRTStartup()</span> calls <span =
style=3D"font-family: courier new,monospace;">wmain()</span>.&nbsp; <span s=
tyle=3D"font-family: courier new,monospace;">mainCRTStartup()</span> handle=
s any conversion if required.&nbsp; If <span style=3D"font-family: courier =
new,monospace;">c16main()</span> or <span style=3D"font-family: courier new=
,monospace;">c32main()</span> existed, they likely would be based upon a si=
milar model.&nbsp; wmainCRTStartup would likely use a hack to call c16main =
so as to avoid a 4th copy of the startup code.<br><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">&gt; And all along it would allocate more mem=
ory for the conversions (well, the=20
<br>&gt; UCS-4 to UTF-16 conversion can be done in-place).
<br>
<br>This still requires allocating memory, which may fail. And it requires =
knowing=20
<br>what the system locale is in order to convert from 8-bit, before the fi=
rst line=20
<br>of user code...
<br>
<br></blockquote><div><br>Systems generally have code before either <span s=
tyle=3D"font-family: courier new,monospace;">main()</span> or the global co=
nstructors anyway.&nbsp; It's already the case that in Windows, using <span=
 style=3D"font-family: courier new,monospace;">main()</span> instead of <sp=
an style=3D"font-family: courier new,monospace;">wmain()</span> loses infor=
mation from the command line due to the system code page/locale.&nbsp; Wind=
ows has to allocate memory for the <span style=3D"font-family: courier new,=
monospace;">argv</span> buffer regardless, because Windows has command line=
s as a singe string, and the C runtime library needs to split it up into <s=
pan style=3D"font-family: courier new,monospace;">argv</span> format.<br><b=
r>POSIX systems have less to worry about.<br><br>Perhaps <span style=3D"fon=
t-family: courier new,monospace;">wmain()</span>, <span style=3D"font-famil=
y: courier new,monospace;">c16main()</span> and <span style=3D"font-family:=
 courier new,monospace;">c32main()</span> could be optional but recommended=
 in the Standard?&nbsp; In other words, specifying (figuratively), "if thes=
e entry points do exist, they function as the following...".<br></div><br>M=
elissa<br></div>

<p></p>

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

------=_Part_1416_416170962.1416947795286--
------=_Part_1415_754397550.1416947795286--

.

On Tuesday 25 November 2014 12:36:35 Myriachan wrote:
> Visual Studio already has a wmain(), which is why I pointed this out.  Note
> that in Windows, main() is a compiler concept, not a system one; this is
> comparable to "start" of crt0.o on the major POSIX systems.
>
> extern "C" int __cdecl wmain();
> extern "C" int __cdecl wmain(int argc, wchar_t **argv);
> extern "C" int __cdecl wmain(int argc, wchar_t **argv, wchar_t **envp);

Actually, it's a regular function. The real entry point is WinMain and the
runtime needs to split the arguments into argv before proceeding.

>
> > Actually, the only way this would work is if the compiler emitted an
> > external
> > symbol called "main" whenever it saw one of those four functions.
>
> > Unfortunately, it doesn't solve this problem:

> How Microsoft's compiler works is that the compiler emits a linker
> directive into the .obj file if it sees a function named ::wmain defined.
> Specifically, it emits /ENTRY:wmainCRTStartup to change the entry point of
> the module to wmainCRTStartup().  wmainCRTStartup() is the "start"
> equivalent in Windows.  mainCRTStartup(), the default, calls main(), and
> wmainCRTStartup() calls wmain().  mainCRTStartup() handles any conversion
> if required.  If c16main() or c32main() existed, they likely would be based
> upon a similar model.  wmainCRTStartup would likely use a hack to call
> c16main so as to avoid a 4th copy of the startup code.

Microsoft's solution would not work for everyone. It implies having control
over the linker, which is not always the case for C++ compiler writers. Hence
what I said that the solution is to always have a "main", regardless of what
the user typed.

> > And all along it would allocate more memory for the conversions (well,
> > the
> >
> > > UCS-4 to UTF-16 conversion can be done in-place).
> >
> > This still requires allocating memory, which may fail. And it requires
> > knowing
> > what the system locale is in order to convert from 8-bit, before the first
> > line
> > of user code...
>
> Systems generally have code before either main() or the global constructors
> anyway.  It's already the case that in Windows, using main() instead of
> wmain() loses information from the command line due to the system code
> page/locale.  Windows has to allocate memory for the argv buffer
> regardless, because Windows has command lines as a singe string, and the C
> runtime library needs to split it up into argv format.
>
> POSIX systems have less to worry about.

They have the locale to worry about in your proposal. It might imply having to
load a plugin for iconv() before main() gets run in order to do the
conversion.

This is not impossible, just way too complex for the benefit.

> Perhaps wmain(), c16main() and c32main() could be optional but recommended
> in the Standard?  In other words, specifying (figuratively), "if these
> entry points do exist, they function as the following...".

Then the standard also needs to define a macro that the compiler will set when
it does support those alternate entry points, so code can properly decide
whether to have a c16main() or a plain main().

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

--

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

.

------=_Part_1141_626782142.1417454541106
Content-Type: multipart/alternative;
 boundary="----=_Part_1142_920172059.1417454541106"

------=_Part_1142_920172059.1417454541106
Content-Type: text/plain; charset=UTF-8

On Tuesday, November 25, 2014 5:31:34 PM UTC-10, Thiago Macieira wrote:
>
> On Tuesday 25 November 2014 12:36:35 Myriachan wrote:
> > Visual Studio already has a wmain(), which is why I pointed this out.
>  Note
> > that in Windows, main() is a compiler concept, not a system one; this is
> > comparable to "start" of crt0.o on the major POSIX systems.
> >
> > extern "C" int __cdecl wmain();
> > extern "C" int __cdecl wmain(int argc, wchar_t **argv);
> > extern "C" int __cdecl wmain(int argc, wchar_t **argv, wchar_t **envp);
>
> Actually, it's a regular function. The real entry point is WinMain and the
> runtime needs to split the arguments into argv before proceeding.
>
>
For .exe applications, there are four possible entry points:

mainCRTStartup - non-Unicode console application (main)
wmainCRTStartup - Unicode console application (wmain)
WinMainCRTStartup - non-Unicode windowed application (WinMain)
wWinMainCRTStartup - Unicode windowed application (wWinMain)

In MSVC, main, wmain, WinMain and wWinMain are all almost-regular
functions.  The calling of global constructors and the splitting of argv is
handled in *ainCRTStartup, along with many other things.  They call *ain
normally.  The only real differences between the *ain functions and
ordinary functions in MSVC are warning on exotic argument types, not
allowing overloading, and automatic issuance of effectively #pragma
comment(linker, "/ENTRY:wmainCRTStartup") if a non-"main" main function is
used so that the alternate main gets set called (and avoiding the linker
error from a missing main).

Microsoft's solution would not work for everyone. It implies having control
> over the linker, which is not always the case for C++ compiler writers.
> Hence
> what I said that the solution is to always have a "main", regardless of
> what
> the user typed.
>
>
Yes; some implementations handle global constructors by making main extern
"C", putting the calls to the global constructors invisibly at the top of
main, and literally calling atexit to schedule global objects'
destruction.  The solution on these platforms would be to have
c16main/c32main/wmain either generate a main that converts parameters and
calls them, or actually be named main at the linker level and generate code
to do the conversion at the beginning.

> Systems generally have code before either main() or the global
> constructors
> > anyway.  It's already the case that in Windows, using main() instead of
> > wmain() loses information from the command line due to the system code
> > page/locale.  Windows has to allocate memory for the argv buffer
> > regardless, because Windows has command lines as a singe string, and the
> C
> > runtime library needs to split it up into argv format.
> >
> > POSIX systems have less to worry about.
>
> They have the locale to worry about in your proposal. It might imply
> having to
> load a plugin for iconv() before main() gets run in order to do the
> conversion.
>
> This is not impossible, just way too complex for the benefit.
>
>
The C runtime already has to have code before main to initialize the
locale.  wmain could be defined such that it is acceptable to simply call
mbstowcs on the arguments.

> Perhaps wmain(), c16main() and c32main() could be optional but
> recommended
> > in the Standard?  In other words, specifying (figuratively), "if these
> > entry points do exist, they function as the following...".
>
> Then the standard also needs to define a macro that the compiler will set
> when
> it does support those alternate entry points, so code can properly decide
> whether to have a c16main() or a plain main().
>
>
That is true.

Melissa

--

---
You received this message because you are 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_1142_920172059.1417454541106
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, November 25, 2014 5:31:34 PM UTC-10, 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 Tuesday 25 Nov=
ember 2014 12:36:35 Myriachan wrote:
<br>&gt; Visual Studio already has a wmain(), which is why I pointed this o=
ut. &nbsp;Note
<br>&gt; that in Windows, main() is a compiler concept, not a system one; t=
his is
<br>&gt; comparable to "start" of crt0.o on the major POSIX systems.
<br>&gt;=20
<br>&gt; extern "C" int __cdecl wmain();
<br>&gt; extern "C" int __cdecl wmain(int argc, wchar_t **argv);
<br>&gt; extern "C" int __cdecl wmain(int argc, wchar_t **argv, wchar_t **e=
nvp);
<br>
<br>Actually, it's a regular function. The real entry point is WinMain and =
the=20
<br>runtime needs to split the arguments into argv before proceeding.
<br>
<br></blockquote><div><br>For .exe applications, there are four possible en=
try points:<br><br>mainCRTStartup - non-Unicode console application (main)<=
br>wmainCRTStartup - Unicode console application (wmain)<br>WinMainCRTStart=
up - non-Unicode windowed application (WinMain)<br>wWinMainCRTStartup - Uni=
code windowed application (wWinMain)<br><br>In MSVC, main, wmain, WinMain a=
nd wWinMain are all almost-regular functions.&nbsp; The calling of global c=
onstructors and the splitting of argv is handled in *ainCRTStartup, along w=
ith many other things.&nbsp; They call *ain normally.&nbsp; The only real d=
ifferences between the *ain functions and ordinary functions in MSVC are wa=
rning on exotic argument types, not allowing overloading, and automatic iss=
uance of effectively #pragma comment(linker, "/ENTRY:wmainCRTStartup") if a=
 non-"main" main function is used so that the alternate main gets set calle=
d (and avoiding the linker error from a missing main).<br><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">Microsoft's solution would not work f=
or everyone. It implies having control=20
<br>over the linker, which is not always the case for C++ compiler writers.=
 Hence=20
<br>what I said that the solution is to always have a "main", regardless of=
 what=20
<br>the user typed.
<br>
<br></blockquote><div><br>Yes; some implementations handle global construct=
ors by making main extern "C", putting the calls to the global constructors=
 invisibly at the top of main, and literally calling atexit to schedule glo=
bal objects' destruction.&nbsp; The solution on these platforms would be to=
 have c16main/c32main/wmain either generate a main that converts parameters=
 and calls them, or actually be named main at the linker level and generate=
 code to do the conversion at the beginning.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">&gt; Systems generally have code before either =
main() or the global constructors
<br>&gt; anyway. &nbsp;It's already the case that in Windows, using main() =
instead of
<br>&gt; wmain() loses information from the command line due to the system =
code
<br>&gt; page/locale. &nbsp;Windows has to allocate memory for the argv buf=
fer
<br>&gt; regardless, because Windows has command lines as a singe string, a=
nd the C
<br>&gt; runtime library needs to split it up into argv format.
<br>&gt;=20
<br>&gt; POSIX systems have less to worry about.
<br>
<br>They have the locale to worry about in your proposal. It might imply ha=
ving to=20
<br>load a plugin for iconv() before main() gets run in order to do the=20
<br>conversion.
<br>
<br>This is not impossible, just way too complex for the benefit.
<br>
<br></blockquote><div><br>The C runtime already has to have code before mai=
n to initialize the locale.&nbsp; wmain could be defined such that it is ac=
ceptable to simply call mbstowcs on the arguments.<br><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">&gt; Perhaps wmain(), c16main() and c32ma=
in() could be optional but recommended
<br>&gt; in the Standard? &nbsp;In other words, specifying (figuratively), =
"if these
<br>&gt; entry points do exist, they function as the following...".
<br>
<br>Then the standard also needs to define a macro that the compiler will s=
et when=20
<br>it does support those alternate entry points, so code can properly deci=
de=20
<br>whether to have a c16main() or a plain main().
<br>
<br></blockquote><div><br>That is true.<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1142_920172059.1417454541106--
------=_Part_1141_626782142.1417454541106--

.

On Monday 01 December 2014 09:22:21 Myriachan wrote:
> > They have the locale to worry about in your proposal. It might imply
> > having to
> > load a plugin for iconv() before main() gets run in order to do the
> > conversion.
> >
> > This is not impossible, just way too complex for the benefit.
>
> The C runtime already has to have code before main to initialize the
> locale.  wmain could be defined such that it is acceptable to simply call
> mbstowcs on the arguments.

The C runtime on Unix systems does not initialise the locale before main. It
does not initialise the locale at all, until you call setlocale(). Until then,
the runtime operates under the "C" locale, which usually implies US-ASCII as
the charset and it's really not what you want (if it was, you could have stuck
to main()).

Moreover, in order to know what charset is the default for a given locale, the
runtime needs to open files in /usr/share/locale. Programmers will also have to
care that the interpretation of parameters changes according to environment
variables and files present -- the environment variables are especially
important, since many app-launch tools like systemd and the launcher on
Blackberry clear the environment before launching the target application,
leading to applications misbehaving when not under debugging.

Like I said, this is possible, just very difficult and tricky.

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

--

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

.

------=_Part_1134_1775749446.1417713911101
Content-Type: multipart/alternative;
 boundary="----=_Part_1135_1440696563.1417713911101"

------=_Part_1135_1440696563.1417713911101
Content-Type: text/plain; charset=UTF-8



On Monday, November 24, 2014 4:19:42 PM UTC-5, Matthew Woehlke wrote:
>
> On 2014-11-24 15:53, Douglas Boffey wrote:
> > Why not allow the second parameter to be a std::array<std::string>, or
> > some other variation?
>
> I take it you mean std::vector<std::string>...
>
>
A better option might be:

int main(std::array_view<std::string_view>) {
}


Then the runtime doesn't need to heap allocate memory for the strings or a
vector. The raw argv strings themselves can be allocated by the system
using whatever method it likes. Wide versions of course could be used here
as well.

--

---
You received this message because you are 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_1135_1440696563.1417713911101
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, November 24, 2014 4:19:42 PM UTC-5, Mat=
thew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2014-11-=
24 15:53, Douglas Boffey wrote:
<br>&gt; Why not allow the second parameter to be a std::array&lt;std::stri=
ng&gt;, or
<br>&gt; some other variation?
<br>
<br>I take it you mean std::vector&lt;std::string&gt;...
<br>
<br></blockquote><div><br>A better option might be:<br><br><div class=3D"pr=
ettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb=
(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-w=
ord;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> main</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">array_view</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">string_vie=
w</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;)</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span></div></code></div><br><br>Then the =
runtime doesn't need to heap allocate memory for the strings or a vector. T=
he raw argv strings themselves can be allocated by the system using whateve=
r method it likes. Wide versions of course could be used here as well.<br><=
/div></div>

<p></p>

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

------=_Part_1135_1440696563.1417713911101--
------=_Part_1134_1775749446.1417713911101--

.

On 4 December 2014 at 19:25, Matthew Fioravante <fmatthew5876@gmail.com> wrote:
> A better option might be:
>
> int main(std::array_view<std::string_view>) {
> }
>
>
> Then the runtime doesn't need to heap allocate memory for the strings or a
> vector. The raw argv strings themselves can be allocated by the system using
> whatever method it likes. Wide versions of course could be used here as
> well.


Ah, it looks like we're rehashing
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/FMAAdCVGiZU/v6OsmXVTXG0J

--

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

.

On 2014-11-24 14:51, Myriachan wrote:
> I think that the Standard ought to permit something that I do anyway,
> which is const-qualify main's argv parameter:
>
> |
> int main(int argc,const char*const*argv);
> |
>
> Currently, only () and (int, char **) are permitted.

Yes, this would be nice.  I used to define my main functions like this
all the time, but it occasionally got me into trouble, so I stopped, and
not being able to makes me sad.  (I'm not sure of the details of the
trouble because it happened to someone else using my code, but it may
have had to do with SWIG.)

There are definite benefits to this form of declaration.  Quite a few
frameworks or argument parsing routines (including the widely used POSIX
getopt) expect you to pass argv to them and they will mess with it
(removing or permuting entries relevant to them).  By declaring your
argv const you can make it clear that no such messing about is occurring
in your argument handling and thus make it easier to reason about.

John Bytheway

--

---
You received this message because you are 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/.

.

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

On 24 November 2014 at 13:51, Myriachan <myriachan@gmail.com> wrote:

> int main(int argc, const char *const *argv);
>

Given that I normally have to have a high level try-catch block anyway, I
find that doing something like:

int mymain(int argc, const char* const argv[])

{ /* ... */ }


int main(int argc, char* argv[])

{

    try { return mymain(argc, argv); }

    catch(...) { /* ... */ }

}

accomplishes the same thing, and doesn't require a language change.
--
 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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra">On 24 November 2014 at 13:51, M=
yriachan <span dir=3D"ltr">&lt;<a href=3D"mailto:myriachan@gmail.com" targe=
t=3D"_blank">myriachan@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le:solid;padding-left:1ex"><div style=3D"background-color:rgb(250,250,250);=
border:1px solid rgb(187,187,187);word-wrap:break-word"><code><div><span st=
yle=3D"color:rgb(0,0,136)">int</span><span style=3D"color:rgb(0,0,0)"> main=
</span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rg=
b(0,0,136)">int</span><span style=3D"color:rgb(0,0,0)"> argc</span><span st=
yle=3D"color:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> </sp=
an><span style=3D"color:rgb(0,0,136)">const</span><span style=3D"color:rgb(=
0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">char</span><span style=
=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">*</span>=
<span style=3D"color:rgb(0,0,136)">const</span><span style=3D"color:rgb(0,0=
,0)"> </span><span style=3D"color:rgb(102,102,0)">*</span><span style=3D"co=
lor:rgb(0,0,0)">argv</span><span style=3D"color:rgb(102,102,0)">);</span><s=
pan style=3D"color:rgb(0,0,0)"><br></span></div></code></div></blockquote><=
/div><div class=3D"gmail_extra"><br></div>Given that I normally have to hav=
e a high level try-catch block anyway, I find that doing something like:</d=
iv><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><p style=
=3D"margin:0px;font-size:11px;font-family:Menlo"><span style=3D"color:rgb(1=
87,44,162)">int</span> mymain(<span style=3D"color:rgb(187,44,162)">int</sp=
an> argc, <span style=3D"color:rgb(187,44,162)">const</span> <span style=3D=
"color:rgb(187,44,162)">char</span>*=C2=A0<span style=3D"color:rgb(187,44,1=
62)">const</span> argv[])</p>
<p style=3D"margin:0px;font-size:11px;font-family:Menlo;color:rgb(0,132,0)"=
><span style=3D"color:rgb(0,0,0)">{ </span>/* ... */<span style=3D"color:rg=
b(0,0,0)"> }</span></p>
<p style=3D"margin:0px;font-size:11px;font-family:Menlo;min-height:13px"><b=
r></p>
<p style=3D"margin:0px;font-size:11px;font-family:Menlo"><span style=3D"col=
or:rgb(187,44,162)">int</span> main(<span style=3D"color:rgb(187,44,162)">i=
nt</span> argc, <span style=3D"color:rgb(187,44,162)">char</span>* argv[])<=
/p>
<p style=3D"margin:0px;font-size:11px;font-family:Menlo">{</p>
<p style=3D"margin:0px;font-size:11px;font-family:Menlo">=C2=A0 =C2=A0 <spa=
n style=3D"color:rgb(187,44,162)">try</span> { <span style=3D"color:rgb(187=
,44,162)">return</span> mymain(argc, argv); }</p>
<p style=3D"margin:0px;font-size:11px;font-family:Menlo">=C2=A0 =C2=A0 <spa=
n style=3D"color:rgb(187,44,162)">catch</span>(...) { <span style=3D"color:=
rgb(0,132,0)">/* ... */</span> }</p>
<p style=3D"margin:0px;font-size:11px;font-family:Menlo">}</p><div><br></di=
v></div><div class=3D"gmail_extra"><div>accomplishes the same thing, and do=
esn&#39;t require a language change.</div>-- <br><div class=3D"gmail_signat=
ure">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:n=
evin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113437164dd8d1050979f254--

.