Date: Sun, 30 Jun 2024 20:10:33 +0100
On Sun, 30 Jun 2024, 18:30 Tiago Freire via Std-Proposals, <
std-proposals_at_[hidden]> wrote:
> Not sure if looking at MSVC is the right thing, seems like a it has been
> direct at the gcc mailing list, so it might be an issue with that compiler.
>
He CC'd Stephan T. Lavavej as well. Because it's an unhinged rant, and
should be ignored.
Since GCC doesn't provide a 'std' module, it's not possible that there is a
problem when using it. But sure, let's all speculate what the problem might
be.
I wonder if that has something to do with the fact identifiers are
> "visible" by default, which means every single thing that it sees is going
> to get exported regardless of either or not it gets used.
> If that is the case I would say that whomever setup the project did it
> incorrectly.
> But I don't know.
> As far as I can tell the standard doesn't dictate how machine code gets
> generated, and the compiler is free to discard anything that isn't used.
> I'm not saying that there isn't a problem, I'm just saying that this isn't
> the right venue.
>
So far nobody has showed a real problem that can be analysed or discussed
sensibly.
> -----Original Message-----
> From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of
> Marcin Jaczewski via Std-Proposals
> Sent: Sunday, June 30, 2024 19:20
> To: std-proposals_at_[hidden]
> Cc: Marcin Jaczewski <marcinjaczewski86_at_[hidden]>; Bo Persson <
> bo_at_[hidden]>
> Subject: Re: [std-proposals] Freestanding std modules
>
> niedz., 30 cze 2024 o 17:22 Bo Persson via Std-Proposals <
> std-proposals_at_[hidden]> napisaĆ(a):
> >
> > On 2024-06-30 at 15:39, Ville Voutilainen via Std-Proposals wrote:
> > > On Sun, 30 Jun 2024 at 16:30, Bo Persson via Std-Proposals
> > > <std-proposals_at_[hidden]> wrote:
> > >>
> > >> On 2024-06-30 at 14:28, Marcin Jaczewski via Std-Proposals wrote:
> > >>> On GCC mailing list I notice email:
> > >>> https://gcc.gnu.org/pipermail/gcc/2024-June/244252.html
> > >>> Aside of misguided author (profanities & sending it to gcc instead
> > >>> of here) some of his concerns could be valid.
> > >>>
> > >>> Example: there is a freestanding version of the standard library
> module?
> > >>> Or how to reduce blot that `import std;` can cause even if I only
> > >>> use part of it like `std::vector` or `std::unique_ptr` but I do
> > >>> not plan touching `std::regexp` or io.
> > >>>
> > >>> Maybe something like `import std.core;` (like MSVC did) or use
> > >>> import headers like `import <iostream>;`?
> > >>>
> > >>> Or is this simply a QoI issue and the committee does not need to
> > >>> consider how big is binary after `import std;`?
> > >>
> > >> Is this a real problem, or just an upset user?
> > >>
> > >> I don't have your embedded compiler, so tried this on Visual Studio:
> > >>
> > >> import std;
> > >>
> > >> int main()
> > >> {}
> > >>
> > >> and get an 11 kB exe-file.
> > >>
> > >> Is that too much bloat?
> > >
> > > If you remove that import, how large is your exe-file?
> >
> > Exactly the same. :-)
> >
> >
>
> How exactly did you tested it? You have a local VS?
> I tried checking it on godbolt but as I see, it's not fully supported yet.
>
> Now I wonder if this thanks to some special handling for `std` or will it
> work similar in user defined modules? Like I could create a 20MiB helper
> module with tons of functions but if I use only one of them then the final
> binary will only grow by a couple of kB.
>
> >
> >
> >
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
std-proposals_at_[hidden]> wrote:
> Not sure if looking at MSVC is the right thing, seems like a it has been
> direct at the gcc mailing list, so it might be an issue with that compiler.
>
He CC'd Stephan T. Lavavej as well. Because it's an unhinged rant, and
should be ignored.
Since GCC doesn't provide a 'std' module, it's not possible that there is a
problem when using it. But sure, let's all speculate what the problem might
be.
I wonder if that has something to do with the fact identifiers are
> "visible" by default, which means every single thing that it sees is going
> to get exported regardless of either or not it gets used.
> If that is the case I would say that whomever setup the project did it
> incorrectly.
> But I don't know.
> As far as I can tell the standard doesn't dictate how machine code gets
> generated, and the compiler is free to discard anything that isn't used.
> I'm not saying that there isn't a problem, I'm just saying that this isn't
> the right venue.
>
So far nobody has showed a real problem that can be analysed or discussed
sensibly.
> -----Original Message-----
> From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of
> Marcin Jaczewski via Std-Proposals
> Sent: Sunday, June 30, 2024 19:20
> To: std-proposals_at_[hidden]
> Cc: Marcin Jaczewski <marcinjaczewski86_at_[hidden]>; Bo Persson <
> bo_at_[hidden]>
> Subject: Re: [std-proposals] Freestanding std modules
>
> niedz., 30 cze 2024 o 17:22 Bo Persson via Std-Proposals <
> std-proposals_at_[hidden]> napisaĆ(a):
> >
> > On 2024-06-30 at 15:39, Ville Voutilainen via Std-Proposals wrote:
> > > On Sun, 30 Jun 2024 at 16:30, Bo Persson via Std-Proposals
> > > <std-proposals_at_[hidden]> wrote:
> > >>
> > >> On 2024-06-30 at 14:28, Marcin Jaczewski via Std-Proposals wrote:
> > >>> On GCC mailing list I notice email:
> > >>> https://gcc.gnu.org/pipermail/gcc/2024-June/244252.html
> > >>> Aside of misguided author (profanities & sending it to gcc instead
> > >>> of here) some of his concerns could be valid.
> > >>>
> > >>> Example: there is a freestanding version of the standard library
> module?
> > >>> Or how to reduce blot that `import std;` can cause even if I only
> > >>> use part of it like `std::vector` or `std::unique_ptr` but I do
> > >>> not plan touching `std::regexp` or io.
> > >>>
> > >>> Maybe something like `import std.core;` (like MSVC did) or use
> > >>> import headers like `import <iostream>;`?
> > >>>
> > >>> Or is this simply a QoI issue and the committee does not need to
> > >>> consider how big is binary after `import std;`?
> > >>
> > >> Is this a real problem, or just an upset user?
> > >>
> > >> I don't have your embedded compiler, so tried this on Visual Studio:
> > >>
> > >> import std;
> > >>
> > >> int main()
> > >> {}
> > >>
> > >> and get an 11 kB exe-file.
> > >>
> > >> Is that too much bloat?
> > >
> > > If you remove that import, how large is your exe-file?
> >
> > Exactly the same. :-)
> >
> >
>
> How exactly did you tested it? You have a local VS?
> I tried checking it on godbolt but as I see, it's not fully supported yet.
>
> Now I wonder if this thanks to some special handling for `std` or will it
> work similar in user defined modules? Like I could create a 20MiB helper
> module with tons of functions but if I use only one of them then the final
> binary will only grow by a couple of kB.
>
> >
> >
> >
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2024-06-30 19:11:57