Topic: Clarification on P1203: Modular Main
Author: Jim Porter <itsjimporter@gmail.com>
Date: Wed, 17 Oct 2018 17:24:54 -0700
Raw View
P1203: Modular Main looks like it addresses a concern I had with modules
quite some time ago[1]; specifically, whether you can define a "generic
main()" in a module-based library to use, instead of forcing users to
write their own main(). However, since the paper is fairly brief, and I
haven't followed the modules work closely, I wanted to confirm whether
this scenario would be supported by P1203.
My use case is primarily for providing a generic main() function for a
unit testing framework to allow users of the framework to avoid having
to write their own. Currently, I inject the main() via an #include
statement, and all the user-written tests are defined within static
globals[2].
It may turn out that this method has other issues when used with
modules, but I wanted to see if it's even possible under P1203. As the
paper wisely notes, tests for a module probably need to live *within*
that module in order to see non-exported names. However, initializing
your tests within the constructors of static globals would cause them to
be created even when merely *using* the module. Perhaps there's an easy
alternative here that retains the expressiveness of my current solution,
but I'm not sure what it would be just yet...
- Jim
[1]
https://groups.google.com/a/isocpp.org/d/msg/modules/naaN9T3cmMM/oeT1Ig7WaTYJ
[2]
https://github.com/jimporter/mettle/blob/master/examples/test_01_basic.cpp
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4b4d0424-8b26-5584-d431-36d2b868e382%40gmail.com.
.
Author: inkwizytoryankes@gmail.com
Date: Thu, 18 Oct 2018 16:33:57 -0700 (PDT)
Raw View
------=_Part_2444_537374162.1539905637774
Content-Type: multipart/alternative;
boundary="----=_Part_2445_779128431.1539905637774"
------=_Part_2445_779128431.1539905637774
Content-Type: text/plain; charset="UTF-8"
On Thursday, October 18, 2018 at 2:24:56 AM UTC+2, Jim Porter wrote:
>
> P1203: Modular Main looks like it addresses a concern I had with modules
> quite some time ago[1]; specifically, whether you can define a "generic
> main()" in a module-based library to use, instead of forcing users to
> write their own main(). However, since the paper is fairly brief, and I
> haven't followed the modules work closely, I wanted to confirm whether
> this scenario would be supported by P1203.
>
> My use case is primarily for providing a generic main() function for a
> unit testing framework to allow users of the framework to avoid having
> to write their own. Currently, I inject the main() via an #include
> statement, and all the user-written tests are defined within static
> globals[2].
>
> It may turn out that this method has other issues when used with
> modules, but I wanted to see if it's even possible under P1203. As the
> paper wisely notes, tests for a module probably need to live *within*
> that module in order to see non-exported names. However, initializing
> your tests within the constructors of static globals would cause them to
> be created even when merely *using* the module. Perhaps there's an easy
> alternative here that retains the expressiveness of my current solution,
> but I'm not sure what it would be just yet...
>
> - Jim
>
> [1]
>
> https://groups.google.com/a/isocpp.org/d/msg/modules/naaN9T3cmMM/oeT1Ig7WaTYJ
> [2]
> https://github.com/jimporter/mettle/blob/master/examples/test_01_basic.cpp
This will have interesting side effect, with this user could use "main"
with different parameters:
include std.main;
int std::main(std::view<std::string_view> args)
{
}
This would need some tweaks to modules proposition (`std::main` is declared
in `std.main` but defined in some other module).
We avoid all concerns with old proposition that change `main` arguments
(like allocation before `main`) because we have still normal main around
and simply it call new main.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a22cf9f7-f415-4f82-9798-49d11f4d8f68%40isocpp.org.
------=_Part_2445_779128431.1539905637774
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, October 18, 2018 at 2:24:56 AM UTC+2,=
Jim Porter wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">P1203: Modul=
ar Main looks like it addresses a concern I had with modules=20
<br>quite some time ago[1]; specifically, whether you can define a "ge=
neric=20
<br>main()" in a module-based library to use, instead of forcing users=
to=20
<br>write their own main(). However, since the paper is fairly brief, and I=
=20
<br>haven't followed the modules work closely, I wanted to confirm whet=
her=20
<br>this scenario would be supported by P1203.
<br>
<br>My use case is primarily for providing a generic main() function for a=
=20
<br>unit testing framework to allow users of the framework to avoid having=
=20
<br>to write their own. Currently, I inject the main() via an #include=20
<br>statement, and all the user-written tests are defined within static=20
<br>globals[2].
<br>
<br>It may turn out that this method has other issues when used with=20
<br>modules, but I wanted to see if it's even possible under P1203. As =
the=20
<br>paper wisely notes, tests for a module probably need to live *within*=
=20
<br>that module in order to see non-exported names. However, initializing=
=20
<br>your tests within the constructors of static globals would cause them t=
o=20
<br>be created even when merely *using* the module. Perhaps there's an =
easy=20
<br>alternative here that retains the expressiveness of my current solution=
,=20
<br>but I'm not sure what it would be just yet...
<br>
<br>- Jim
<br>
<br>[1]=20
<br><a href=3D"https://groups.google.com/a/isocpp.org/d/msg/modules/naaN9T3=
cmMM/oeT1Ig7WaTYJ" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D'https://groups.google.com/a/isocpp.org/d/msg/modules/naaN9T3cmMM=
/oeT1Ig7WaTYJ';return true;" onclick=3D"this.href=3D'https://groups=
..google.com/a/isocpp.org/d/msg/modules/naaN9T3cmMM/oeT1Ig7WaTYJ';return=
true;">https://groups.google.com/a/<wbr>isocpp.org/d/msg/modules/<wbr>naaN=
9T3cmMM/oeT1Ig7WaTYJ</a>
<br>[2]=20
<br><a href=3D"https://github.com/jimporter/mettle/blob/master/examples/tes=
t_01_basic.cpp" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjimporte=
r%2Fmettle%2Fblob%2Fmaster%2Fexamples%2Ftest_01_basic.cpp\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNFeEaAt1Q8hA5NOJTYf83eCtxHc7A';return true;" oncl=
ick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithu=
b.com%2Fjimporter%2Fmettle%2Fblob%2Fmaster%2Fexamples%2Ftest_01_basic.cpp\x=
26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFeEaAt1Q8hA5NOJTYf83eCtxHc7A';re=
turn true;">https://github.com/jimporter/<wbr>mettle/blob/master/examples/<=
wbr>test_01_basic.cpp</a></blockquote><div><br></div><div>This will have in=
teresting side effect, with this user could use "main" with diffe=
rent parameters:</div><div><br></div><div><div style=3D"background-color: r=
gb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; b=
order-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code c=
lass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">include std</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">main</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</=
span><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: #000;" class=3D"styled-by-prettify">std</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">view</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">string_view</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">></span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> args</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan 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"co=
lor: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span></div></code></div><br>This woul=
d need some tweaks to modules proposition (`std::main` is declared in `std.=
main` but defined in some other module).</div><div>We avoid all concerns wi=
th old proposition that change `main` arguments (like allocation before `ma=
in`) because we have still normal main around and simply it call new main.<=
br></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a22cf9f7-f415-4f82-9798-49d11f4d8f68%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a22cf9f7-f415-4f82-9798-49d11f4d8f68=
%40isocpp.org</a>.<br />
------=_Part_2445_779128431.1539905637774--
------=_Part_2444_537374162.1539905637774--
.
Author: Serdar Sanli <mserdarsanli@gmail.com>
Date: Fri, 19 Oct 2018 14:34:19 -0700 (PDT)
Raw View
------=_Part_337_787962224.1539984859798
Content-Type: multipart/alternative;
boundary="----=_Part_338_1662788878.1539984859798"
------=_Part_338_1662788878.1539984859798
Content-Type: text/plain; charset="UTF-8"
I proposed something different to tackle the same problem before:
https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/E3ljdlN3f5c/TD79wZvfCgAJ
That thread has some interesting discussion which might be of interest
Serdar
On Thursday, 18 October 2018 01:24:56 UTC+1, Jim Porter wrote:
>
> P1203: Modular Main looks like it addresses a concern I had with modules
> quite some time ago[1]; specifically, whether you can define a "generic
> main()" in a module-based library to use, instead of forcing users to
> write their own main(). However, since the paper is fairly brief, and I
> haven't followed the modules work closely, I wanted to confirm whether
> this scenario would be supported by P1203.
>
> My use case is primarily for providing a generic main() function for a
> unit testing framework to allow users of the framework to avoid having
> to write their own. Currently, I inject the main() via an #include
> statement, and all the user-written tests are defined within static
> globals[2].
>
> It may turn out that this method has other issues when used with
> modules, but I wanted to see if it's even possible under P1203. As the
> paper wisely notes, tests for a module probably need to live *within*
> that module in order to see non-exported names. However, initializing
> your tests within the constructors of static globals would cause them to
> be created even when merely *using* the module. Perhaps there's an easy
> alternative here that retains the expressiveness of my current solution,
> but I'm not sure what it would be just yet...
>
> - Jim
>
> [1]
>
> https://groups.google.com/a/isocpp.org/d/msg/modules/naaN9T3cmMM/oeT1Ig7WaTYJ
> [2]
> https://github.com/jimporter/mettle/blob/master/examples/test_01_basic.cpp
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e711a143-0e6c-4403-917a-9a080089de0d%40isocpp.org.
------=_Part_338_1662788878.1539984859798
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I proposed something different to tackle the same pro=
blem before: https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposa=
ls/E3ljdlN3f5c/TD79wZvfCgAJ</div><div>That thread has some interesting disc=
ussion which might be of interest</div><div><br></div><div>Serdar<br></div>=
<br>On Thursday, 18 October 2018 01:24:56 UTC+1, Jim Porter wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">P1203: Modular Main looks like it addr=
esses a concern I had with modules=20
<br>quite some time ago[1]; specifically, whether you can define a "ge=
neric=20
<br>main()" in a module-based library to use, instead of forcing users=
to=20
<br>write their own main(). However, since the paper is fairly brief, and I=
=20
<br>haven't followed the modules work closely, I wanted to confirm whet=
her=20
<br>this scenario would be supported by P1203.
<br>
<br>My use case is primarily for providing a generic main() function for a=
=20
<br>unit testing framework to allow users of the framework to avoid having=
=20
<br>to write their own. Currently, I inject the main() via an #include=20
<br>statement, and all the user-written tests are defined within static=20
<br>globals[2].
<br>
<br>It may turn out that this method has other issues when used with=20
<br>modules, but I wanted to see if it's even possible under P1203. As =
the=20
<br>paper wisely notes, tests for a module probably need to live *within*=
=20
<br>that module in order to see non-exported names. However, initializing=
=20
<br>your tests within the constructors of static globals would cause them t=
o=20
<br>be created even when merely *using* the module. Perhaps there's an =
easy=20
<br>alternative here that retains the expressiveness of my current solution=
,=20
<br>but I'm not sure what it would be just yet...
<br>
<br>- Jim
<br>
<br>[1]=20
<br><a href=3D"https://groups.google.com/a/isocpp.org/d/msg/modules/naaN9T3=
cmMM/oeT1Ig7WaTYJ" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D'https://groups.google.com/a/isocpp.org/d/msg/modules/naaN9T3cmMM=
/oeT1Ig7WaTYJ';return true;" onclick=3D"this.href=3D'https://groups=
..google.com/a/isocpp.org/d/msg/modules/naaN9T3cmMM/oeT1Ig7WaTYJ';return=
true;">https://groups.google.com/a/<wbr>isocpp.org/d/msg/modules/<wbr>naaN=
9T3cmMM/oeT1Ig7WaTYJ</a>
<br>[2]=20
<br><a href=3D"https://github.com/jimporter/mettle/blob/master/examples/tes=
t_01_basic.cpp" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjimporte=
r%2Fmettle%2Fblob%2Fmaster%2Fexamples%2Ftest_01_basic.cpp\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNFeEaAt1Q8hA5NOJTYf83eCtxHc7A';return true;" oncl=
ick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithu=
b.com%2Fjimporter%2Fmettle%2Fblob%2Fmaster%2Fexamples%2Ftest_01_basic.cpp\x=
26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFeEaAt1Q8hA5NOJTYf83eCtxHc7A';re=
turn true;">https://github.com/jimporter/<wbr>mettle/blob/master/examples/<=
wbr>test_01_basic.cpp</a>
<br></blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e711a143-0e6c-4403-917a-9a080089de0d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e711a143-0e6c-4403-917a-9a080089de0d=
%40isocpp.org</a>.<br />
------=_Part_338_1662788878.1539984859798--
------=_Part_337_787962224.1539984859798--
.