reimplement: SHC_3BB0A8C1_0x00479DF0 100%

[TheRedDaemon]

No description provided.

[gynt]

Why the space between includes? I don't really mind, just curious.

[TheRedDaemon]

I just like to make up some structure. My mind currently works roughly like this:

#include "mainForFile.func.hpp"

#include "other.func.hpp"
#include "other2.hpp"

#include "global.hpp"

#include "msAndOther.h"

May vary, certain is usually just main func.hpp first and additional microsoft headers and such last.

[gynt]

Sounds good to me. Perhaps you can codify this into our clang-format (different PR)? (not to be 100% foolproof, but rather working most of the time) https://clang.llvm.org/docs/ClangFormatStyleOptions.html#includecategories

[TheRedDaemon]

So, I tested around a bit, and the following things are relevant:

• Messing with the import of course makes many header files invalid, which will show up when they are changed the next time.
• I am almost able to recreate the structure I mentioned, but there is one thing: I can not isolate the "main" file for the cpp file, since there is nothing in the filename of the current cpp to match to the hpp file. Two solutions I could think of, both containing changing the include:
  • Adding the class to the filename. Might fail with the globals, e.g. "SoundSystem..cpp"
  • Using another form for them and just handling them as another include category:
    • relative: ..\SoundSystem.func.hpp
    • <>: <OpenSHC/Audio/MSS/SoundSystem.func.hpp>
      • This one is a bit less standard, since it uses the "external/system" syntax convention with <>, but in the end, we so far have used full non-relative paths anyway.

What do you think? Change something? Leave it manually as it is now?

[gynt]

Oh so you can't really isolate the fact that the cop file's main hpp file is the same name as the parent directory of the cop file? That is too bad! Lets leave like it is, or is there value in what you created so far? I am fine with a 75% solution as long as the manual 25% isn't ugly. Or is it always reporting errors in that case? Then we should leave it I guess.

[TheRedDaemon]

My current settings have no "manual" anymore, since they would pull everything into the logic I described, for example this form (assuming <> would be used):

#include <OpenSHC/Audio/MSS/SoundSystem.func.hpp>

#include "OpenSHC/Audio/MSS/SoundSystem.hpp"
#include "OpenSHC/Audio/MSS/UnkSoundFlagsAndLoopCount.hpp"
#include "OpenSHC/Audio/MSS/enums/SHC_SoundStream.hpp"

#include "OpenSHC/Globals/BOOL_WasInteracting.hpp"

#include "ucp3.h"
#include <iostream>

The alternative with relative:

#include "../SoundSystem.func.hpp"

#include "OpenSHC/Audio/MSS/SoundSystem.hpp"
#include "OpenSHC/Audio/MSS/UnkSoundFlagsAndLoopCount.hpp"
#include "OpenSHC/Audio/MSS/enums/SHC_SoundStream.hpp"

#include "OpenSHC/Globals/BOOL_WasInteracting.hpp"

#include "ucp3.h"
#include <iostream>

If no special handling for the "main" file is used, it gets sorted into the OpenSHC blob and other func.hpp might end up over them:

#include "OpenSHC/Audio/MSS/SoundSystem.func.hpp"
#include "OpenSHC/Audio/MSS/SoundSystem.hpp"
#include "OpenSHC/Audio/MSS/UnkSoundFlagsAndLoopCount.hpp"
#include "OpenSHC/Audio/MSS/enums/SHC_SoundStream.hpp"

#include "OpenSHC/Globals/BOOL_WasInteracting.hpp"

#include "ucp3.h"
#include <iostream>

I would be happy with either solution, after all, our linting only takes changed files into account, so this would have later effects.

[gynt]

I like the alternative with relative paths best!