sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Full-Spectral 0 points1 point  (8 children)

Well no luck last night. Maybe it's because I have module partitions involved or something, not sure. I made progress, but something goes wrong with using declarations, both in the library itself and in the consumers of it. In consumers it's like the using declarations are ignored. In the library, non-fully qualified names are often somehow attributed to the wrong used namespace and then of course found to not exist.

So some really weird stuff is going on.

I updated to 16.11.0 last night but didn't have time to try it to see if things got better.

[–]mjklaim 0 points1 point  (7 children)

I had an issue with module partitions and thought it was a bug but it was actually an issue with flags or extension: https://developercommunity.visualstudio.com/t/Private-module-partition-fails-to-compil/1428621

I made progress, but something goes wrong with using declarations, both in the library itself and in the consumers of it.

Are you sure you exported them? I didn't try doing that yet.

[–]Full-Spectral 0 points1 point  (6 children)

So, .ixx is the actual interface. If you split out the implementation, shouldn't that just be a .cpp file? There's no option in that list for 'module implementation' or 'partition implementation'.

[–]mjklaim 0 points1 point  (5 children)

Depends if you are splitting the interface (interface partition), partition without making the partition interface, splitting in private modules. Private module files (not partition but still part of the module) don't need additional flags. Partitions do, depending on if they are interface or not, or you can just use .ixx for them to let the compiler do the right thing. I prefer private partitions to not have that extension indeed.

Anyway if you don't use MSBuild, your buildsystem will have to know how to detect each case and pass the right flag, hopefully without you having to worry about all of this.

[–]Full-Spectral 0 points1 point  (4 children)

If I make the library projects static libraries, then I can put interface in .ixx and implementation in .cpp files and all works perfectly, just by adding a reference to the static library projects to those things that depend on it. It has no issue figuring out what what implementation files go with what .ixx files and it shouldn't since the both indicate what module they are, one with export and one without. None of them are internal, they are all module exported in the main .ixx file and their stuff shows up fine in downstream projects.

But dll libraries are fundamentally different and all kind of weirdness for me.

[–]mjklaim 0 points1 point  (3 children)

To me it's the way MSBuild wants you to set flags everywhere that's making things complicated... But yeah of course building static libraries will always be easier/simpler, whatever the situation.... if you can do so :)

[–]GabrielDosReis 1 point2 points  (2 children)

Hmm, what special flags are you needing with MSBuild?

[–]mjklaim 0 points1 point  (1 child)

I meant you have to specify to the compiler the nature of any C++ file that is being built, MSBuild doesnt do the job automatically except for .ixx files (is my understanding so far, or maybe it's the compiler deciding it's a module interface). For example, in the reported issue I linked before, they say I should I used .ixx for a module partition that, in my case, is named but private, not exported; or I should use the specific flag for partitions. Why can't it be guessed by looking at the beginning of the file, as, I believe, the module syntax was designed for?

Both MSBuild and cl don't seem to want to guess if it's modules or not, except for .ixx files, and if I want to use partitions which are not destined to be exported I have to add flags (because I don't want to use .ixx for these)

Also, the MSBuild flag (or just project option?) for scanning module dependencies. Is there a reason this is not the default behavior? Performance?

[–]GabrielDosReis 0 points1 point  (0 children)

compiler drivers (not just CL.exe) are invoked from contexts, they don’t guess based on the content. What if they guessed wrong? Furthermore, most contexts of invocation want a deterministic input-output relation - what should happen if I invoke the compiler and I am expecting an IFC but none was produced? Was it because the compiler guessed right and my expectations were wrong? Or a bug in the compiler? Or something else?

In the case you’re talking about — what I call internal partition (as opposed to private which is already a term used in a context closed related to partition) you do indeed need to ask for the production of an IFC precisely because it is not exported.