[Development] Request for early MOC support for C++20 Modules

Thiago Macieira thiago.macieira at intel.com
Mon Dec 18 12:57:38 CET 2023


On Monday, 18 December 2023 07:54:07 -03 Giuseppe D'Angelo via Development 
wrote:
> If anything I think this discussion ties up with the one about the
> future of moc, and whether it should become a compiler plugin. In
> principle this would bypass the problem of parsing the binary module
> formats -- leave it to the compiler infra, and just get the info you
> need out of the `import`s.

Either that or use reflection.

> > Qt should make the commitment that will support at most one module format.
> > Any compiler that doesn't operate on those will not have their modules
> > supported.
> > 
> > I don't know if this is the same content that CMake had to support. It's
> > possible it isn't because CMake doesn't need to know about the classes,
> > enums, variables, functions, and all other entities declared, which are
> > part of the translation unit. Moc does need that.
> 
> ... which is really, what info does moc exactly need out of a #include /
> import?

Since 4.0 or 5.0 (too long ago) we actually parse everything included for 
extra information. I don't know exactly what we need from included files, but 
we do need something.

In particular, we do need macros themselves, so we can perform proper 
expansion in the classes we're trying to generate meta objects for. If this is 
something that will never come from imports, great, it's a major barrier 
removed.

The question is what else.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5163 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20231218/b779803d/attachment.bin>


More information about the Development mailing list