Some APU code files not visible in Visual Studio.

[bonimy]

Issue

In Visual Studio, under the APU folder, there are some files (header and source) not included in the solution explorer. Here is what we see so far:

However, when looking in the file explorer, we see some files not referenced.

These files are explicitly included in the source code:

But I'm not sure this is the preferred way to add .cpp files. Especially since they aren't visible in the Visual Studio solution explorer. Further, including code this way removes certain Visual Studio features, namely Intellisense and syntax highlighting. Instead, we see this:

The APU file include structure also suffers from other include file errors, so that some files that are included, aren't properly highlighted.

Resolution

Refactor the preprocessor code to a format that Visual Studio likes, without changing any of the functional code.

Proposed tags

• windows
• documentation
• emulation-apu

[qwertymodo]

Ok, I think this is possible with a combination of setting the "File Type" property to "C++ Header File", which tells VS not to try to compile those .cpp files separately, as well as adding a couple of header #include's at the top of each of them. The #ifdef guards should nop those includes out at compile time, but they will allow Intellisense to find the necessary symbols. I'll take a shot at it.

[bonimy]

I remember being told there might be some cross-platform challenges in trying to alter the code too. My memory is fuzzy, but I just wanted to bring the point up in case any code does get changed.

[qwertymodo]

It's looking like it's going to be trickier than I thought, because Intellisense is being too smart for it's own good, but then coming up short and only getting halfway there. Basically, it knows that the .cpp files are being #included by smp.cpp, so it backtraces into smp.cpp and discovers all of the #defines which control the #include guards, but it doesn't manage to actually trace into the included headers to find the defined classes. Also, smp.hpp doesn't have any #ifdef guards, but adding them doesn't help because of the catch-22 situation I just described. I feel like there has to be a way to make it work, but at the end of the day, this is just a very... unorthodox code structure for C++.