Date: Sun, 30 Jun 2024 21:01:42 +0300
On Sun, 30 Jun 2024 at 20:54, Marcin Jaczewski
<marcinjaczewski86_at_[hidden]> wrote:
> Probably the best mental model of how modules work is "object files"
> as Ville said,
> instead of classic `#include` files. This mean would be better to have
> few big modules
> than many small form usage perspective as the overall final binary
> should be similar.
> (this would not even be problem with recompiation as we have module partitions)
The size of the module has nothing to do with the size of your
program. And imports of one big
module are splendidly fast, and in many cases faster than importing
multiple smaller modules.
Such results have been measured with prototype implementations of One
Big Standard Module
and multiple smaller standard modules, for instance, when Microsoft
prototyped such options
with their implementation.
> > > There is no issue with any compiler here, nor with the design of C++
> > > modules. The sender of the email that started this whole discussion is
> > > unhinged.
> >
> > To clarify, I mean the email sent to the gcc list. :)
>
> @Ville uff... I was start worrying that I was this person :D
My apologies for the momentary potential for confusion; I was indeed
referring to the person who
posted the message on the gcc mailing list, that person has a
multi-year history of posting garbage
like that both on gcc mailing lists and gcc bugzilla, and many other
forums, including this one.
Due to that person's use of multiple email addresses to post such
garbage, banning that garbage
is a game of whack-a-mole.
<marcinjaczewski86_at_[hidden]> wrote:
> Probably the best mental model of how modules work is "object files"
> as Ville said,
> instead of classic `#include` files. This mean would be better to have
> few big modules
> than many small form usage perspective as the overall final binary
> should be similar.
> (this would not even be problem with recompiation as we have module partitions)
The size of the module has nothing to do with the size of your
program. And imports of one big
module are splendidly fast, and in many cases faster than importing
multiple smaller modules.
Such results have been measured with prototype implementations of One
Big Standard Module
and multiple smaller standard modules, for instance, when Microsoft
prototyped such options
with their implementation.
> > > There is no issue with any compiler here, nor with the design of C++
> > > modules. The sender of the email that started this whole discussion is
> > > unhinged.
> >
> > To clarify, I mean the email sent to the gcc list. :)
>
> @Ville uff... I was start worrying that I was this person :D
My apologies for the momentary potential for confusion; I was indeed
referring to the person who
posted the message on the gcc mailing list, that person has a
multi-year history of posting garbage
like that both on gcc mailing lists and gcc bugzilla, and many other
forums, including this one.
Due to that person's use of multiple email addresses to post such
garbage, banning that garbage
is a game of whack-a-mole.
Received on 2024-06-30 18:01:56