Compiler Error when including InstancedSkinnedMeshComponent.h

[anonymous-edc (Anonymous User)]

Linking this forum thread as it is the exact same issue I am running into.

500×500 2.84 KB

Did you find a solution to this, that doesn’t involve getting the engine source code? I’d rather just stick with the binaries from the launcher. I don’t understand how other files are able to include this one without running into the same issue honestly, unless the binaries were built with slightly different code then what’s provided.

I am attempting to include InstancedSkinnedMeshComponent.h in a cpp in a plugin. Just adding the include causes a compile error, “error C3837: attributes are not allowed in this context”.

It seems to be successfully included in other engine code, but including it anywhere in our project code fails to compile. I wasn’t able to ascertain why it worked in engine code and not ours.

[anonymous-edc (Anonymous User)]

Steps to Reproduce
Include InstancedSkinnedMeshComponent.h in another file. For the repro project it was added to the game project’s module cpp file.

[Louimatic (Louis Cresswell)]

Hi there,

As others in that thread have pointed out, this is caused by the UE_EXPERIMENTAL macro in InstancedSkinnedMeshComponent.h. This macro will trigger a compilation warning on non-engine files.

There are a few ways to get around this without modifying the source code of the engine. The apparent preferred method is to wrap any calls to experimental classes with the PRAGMA_DISABLE_EXPERIMENTAL_WARNINGS & PRAGMA_ENABLE_EXPERIMENTAL_WARNINGS macros. e.g:

PRAGMA_DISABLE_EXPERIMENTAL_WARNINGS
#include "Components/InstancedSkinnedMeshComponent.h"
PRAGMA_ENABLE_EXPERIMENTAL_WARNINGS

There are quite a few examples of this in the engine code. However when doing some tests for this case I was unable to get this method to compile. I had much more success with the following methods:

• Adding bValidateExperimentalApi = false; to the build.cs will cause any experimental API calls for an entire module/plugin to be accepted.
• Adding bTreatAsEngineModule = true; to the build.cs will work similarly for modules other than the main game module (One that uses IMPLEMENT_PRIMARY_GAME_MODULE). However it’s worth noting that this will also cause any Internal API calls to be accepted.

- Louis

[Louimatic (Louis Cresswell)]

Hi again,

Thank you for clarifying, I feel i couldn’t see the forest through the trees. Looking into this a bit more I think you are correct. This instance doesn’t adhere to the guidelines in the documentation and testing it with that change shows it to be working correctly. I will submit a bug report for this which you can track here once it is live on the public issue tracker.

Thanks for your help with this,

Louis

[anonymous-edc (Anonymous User)]

To clarify, the macro is causing the compiler error C3837. Not the compiler warning C4996 used to warn about experimental code use.

The pragmas do not work because the macros suppress warnings about experimental code, it does not fix the compiler error which refers to the improper placement of an attribute.

I believe that, “class” needs to be before UE_EXPERIMENTAL instead of after it. This change does appear to fix the C3837 error, and a bunch of experimental warnings are reported instead, some of which seem to come from engine code that may need to be pragma wrapped.

Using, “bValidateExperimentalApi=false” does work as a workaround for now. But I do believe there is an actual error here.