I can't give timings since I haven't progressed to the point where the whole thing actually compiles, but the compiler goes through the various translation units noticably quicker than before. HOWEVER: it does appear to be compiling much faster. Right now I'm not getting a good vibe yet. I would really hate converting all my source to modules, only to find out it randomly breaks if you look at it wrong. I'm concerned about how fragile all this is.
Plus, it may not even be possible: what if a 3rd-party library includes one of those headers? And figuring out where those came from is, as I said earlier, a complete and utter pain. It appears to be a bit of an all-or-nothing deal: either you rip out all of your STL-related includes, and replace them all by import directives, or you get an endless stream of C2953 (see above). Intellisense doesn't quite understand what's going on here, and now flags optional as an error. Yay, success! However, there are still some issues: Of course this means optional must now be used without std. If I add an additional using namespace stdlib (in the importing file) it seems to work. Trying to use optional as stdlib::optional gets me ' error C2059: syntax error: '<'' (and of course, I get to add the stdlib:: qualifier everywhere). The workaround is to put it in a namespace instead: module But I know MSVC currently has a bug when using using to bring an existing function or class into a module. Any use of 'optional' (without the std:: qualifier) gives me error ' error C7568: argument list missing after assumed function template 'optional''. Maybe I should try to make my own 'std.core'? module I don't particularly want to have a bunch of #ifdef directives at the top of every file just to be able to do the correct imports. This is definitely something that should be improved both the reporting from the compiler (it would help a lot to see the entire path towards the offending include file), and the include guard mechanism itself, so it works across headers and modules.Īn additional concern is whether other compilers will implement the same division of the standard library as Microsoft has done. But it's an absolutely massive pain trying to figure out which header is causing the problem: there is precisely zero help from the compiler here. Fair enough: the compiler is seeing the same header twice, and the include guards, being #defines, are of course not visible to the module. I found a post suggesting I disable the warning, but it doesn't exactly give me warm feelings.Ī much worse problem is that if any STL-related header is included above the import directive, you'll get endless numbers of errors like "error C2953: 'std::ranges::in_fun_result': class template has already been defined". This immediately triggers a bunch of warnings like "warning C5050: Possible incompatible environment while importing module 'std.core': _DEBUG is defined in current command line and not in module command line". The simplest is by using import std.core. There are a few different ways to do this.
0 kommentar(er)
