Date: Fri, 3 Nov 2023 04:57:30 -0400
I'd like to hear use cases that require or benefit from preprocessing
compared to other approaches like some mild code generation.
So far, I'm inclined to restrict preprocessing as proposed. Among other
reasons, preprocessing tricks are more error prone from an ODR perspective,
so they're already problematic. An interface with those sorts of tricks
would have to be carefully paired with preprocessing instructions, for
instance. We are working on mechanisms to support that, but they do not
exist yet, not portable ones anyway.
More, I think the point in the paper about this not being a breaking change
is very valid. There really aren't any existing use cases to break.
Hypothetical use cases are interesting, but mostly if they derive from
clear needs for modules to be useful. I would include practical matters of
adoptability as "clear needs", for what it's worth.
That being said, the paper seems to be hinting at significant performance
savings in certain combinations of codebase arrangements and (I assume)
clang and/or clang-scan-deps calls. It would be interesting to see some
performance indicators for these situations shared in addition to the more
abstract reasoning provided in the paper.
Bret
On Fri, Nov 3, 2023, 03:43 Boris Kolpackov via SG15 <sg15_at_[hidden]>
wrote:
> Michael Spencer via SG15 <sg15_at_[hidden]> writes:
>
> > This paper makes the following ill-formed by forbidding macro
> expansion
> > in the name of module declarations.
> >
> > version.h:
> > #ifndef VERSION_H
> > #define VERSION_H
> >
> > #define VERSION libv5
> >
> > #endif
> >
> > lib.cppm:
> > module;
> > #include "version.h"
> > export module VERSION;
>
> What about something like this:
>
> #ifdef VERSION
> export module version;
> #else
> export module final;
> #endif
>
> Sounds like it will pose the same issue but banning it feels more
> drastic.
>
> Even the use of a macro in the module name could probably have
> plausible use-cases. Say if you are trying to make a module
> that includes a version in its name:
>
> #define VERSION 2
> #define VERSIONED_NAME(n) n ## _v2
>
> And then:
>
> export module VERSIONED_NAME(utility);
>
> #if VERSION >= 2
> export void only_available_in_v2 ();
> #endif
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
compared to other approaches like some mild code generation.
So far, I'm inclined to restrict preprocessing as proposed. Among other
reasons, preprocessing tricks are more error prone from an ODR perspective,
so they're already problematic. An interface with those sorts of tricks
would have to be carefully paired with preprocessing instructions, for
instance. We are working on mechanisms to support that, but they do not
exist yet, not portable ones anyway.
More, I think the point in the paper about this not being a breaking change
is very valid. There really aren't any existing use cases to break.
Hypothetical use cases are interesting, but mostly if they derive from
clear needs for modules to be useful. I would include practical matters of
adoptability as "clear needs", for what it's worth.
That being said, the paper seems to be hinting at significant performance
savings in certain combinations of codebase arrangements and (I assume)
clang and/or clang-scan-deps calls. It would be interesting to see some
performance indicators for these situations shared in addition to the more
abstract reasoning provided in the paper.
Bret
On Fri, Nov 3, 2023, 03:43 Boris Kolpackov via SG15 <sg15_at_[hidden]>
wrote:
> Michael Spencer via SG15 <sg15_at_[hidden]> writes:
>
> > This paper makes the following ill-formed by forbidding macro
> expansion
> > in the name of module declarations.
> >
> > version.h:
> > #ifndef VERSION_H
> > #define VERSION_H
> >
> > #define VERSION libv5
> >
> > #endif
> >
> > lib.cppm:
> > module;
> > #include "version.h"
> > export module VERSION;
>
> What about something like this:
>
> #ifdef VERSION
> export module version;
> #else
> export module final;
> #endif
>
> Sounds like it will pose the same issue but banning it feels more
> drastic.
>
> Even the use of a macro in the module name could probably have
> plausible use-cases. Say if you are trying to make a module
> that includes a version in its name:
>
> #define VERSION 2
> #define VERSIONED_NAME(n) n ## _v2
>
> And then:
>
> export module VERSIONED_NAME(utility);
>
> #if VERSION >= 2
> export void only_available_in_v2 ();
> #endif
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
Received on 2023-11-03 08:57:43