Re: [Development] Request for early MOC support for C++20 Modules
Il 15/12/23 21:33, Thiago Macieira ha scritto: Is the file format for the imported modules already standardised? Is it in the C++ standard? I don't remember seeing it there. If it's not a standard (ISO C++ standard or otherwise), we'd need to write format parsers for each compiler, which raises the cost for supporting modules considerably, especially if the compilers aren't committing to a stable format in the first place. There's no such thing as a standardized binary format. There's been discussions about it years ago, but it's far from being (widely?) adopted, see for instance: https://github.com/GabrielDosReis/ipr 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. 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? Thank you, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - Trusted Software Excellence smime.p7s Description: Firma crittografica S/MIME -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Request for early MOC support for C++20 Modules
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 smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] 6.7 FF vs. C++20 comparisons
On Sat, 16 Dec 2023 at 13:22, apoenitz wrote: > > On Fri, Dec 15, 2023 at 05:40:28AM +, Marc Mutz via Development wrote: > > On 13.12.23 18:36, Thiago Macieira wrote: > > > So, +1 for me on going ahead. > > > > Thanks! > > > > Is anyone else here for/against? > > To me this doesn't look like a new feature, so I don't see the feature freeze > blocking this formally. I don't see how it's not a new feature. "Convert more classes to opt in to C++20 three-way comparison" reads like a new feature to me for every word of it. > Maybe I am just generally lacking a certain sense of urgency here to have > this kind of changes, but I think it would be better to avoid the risk by > simply not doing it. I don't understand why it needs to be rushed into 6.7, instead of doing it without such rush for 6.8. Thus my take on this is -1. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
