Does UE 4.10 support UCLASS/USTRUCT in namespaces?

I am using UE 4.10.2, with the editor prebuilt for windows, with VS 2015, and Windows 10 as my OS.

The UE4 Programming Guide’s Coding Standards section on Namespaces (Coding Standard | Unreal Engine Documentation) states that namespaces may be used to organize classes, functions, variables, with a few caveats.

These caveats don’t seem to stipulate that you can’t use UCLASS or USTRUCT definitions for your classes defined inside a namespace. They even require a namespace for enums.

However, when I attempt to compile a project in UE 4.10.2, on windows with a class defined using UCLASS as follows:

MyClass.h:

// MyClass.h

#pragma once

#include "Actor.h"
#include "MyClass.generated.h"

namespace MyNamespace {

UCLASS()
class MYPROJECT_API AMyClass : public AActor
{
    GENERATED_BODY()
  public:
    AMyClass();
};

} // namespace MyNamespace

MyClasscpp:

// MyClass.cpp

#include "MyProject.h"
#include "MyClass.h"

namespace MyNamespace {

AMyClass::AMyClass()
{}

} // namespace Mynamespace

I get the following compile error:

CompilerResultsLog:Error: Error c:\users\nick\MyProject\source\MyProject\MyClass.h(4) : fatal error C1083: Cannot open include file: 'MyClass.generated.h': No such file or directory

I also attempted to compile with the “MyClass.generated.h” include inside the namespace (and no changes to the cpp), like so:

MyClass.h:

// MyClass.h

#pragma once

#include "Actor.h"

namespace MyNamespace {

#include "MyClass.generated.h"

UCLASS()
class MYPROJECT_API AMyClass : public AActor
{
    GENERATED_BODY()
  public:
    AMyClass();
};

} // namespace MyNamespace

But then I got these errors:

CompilerResultsLog:Error: Error C:/Users/Nick/MyProject/Source/Stratagem/MyProject.h(38)  : Expected an include at the top of the header: '#include "MyProject.generated.h"'
CompilerResultsLog:Error: Error Error: Failed to generate code for MyProjectEditor - error code: OtherCompilationError (5)

I don’t see any other reasonable way to arrange the includes and namespace (although I did try a few unreasonable ones, with no luck).

I found this forum thread: Using namespaces with UCLASS - C++ - Unreal Engine Forums
The responses, from 2014, indicate that UCLASS/USTRUCT was most likely not supported with Unreal Build Tool at that time.

It appears to me that namespaces with UCLASS/USTRUCT still simply aren’t supported by Unreal Build Tool - is the documentation just incorrect/misleading or am I just missing something necessary to make this work? I fail to see how namespace could be said to “work” with UE if they can’t be used with UBT classes…

Yeah from the link you posted it looks like they never supported this syntax nor they plan to.

Hi,

No, we don’t plan to support namespaces for USTRUCTs, UCLASSes etc. Our coding standards also apply to non-UTHINGs code, where we do make (limited) use of namespaces.

Steve

This seems pretty important to note when the use of namespaces is mentioned in the coding standard. Is there any way of asking someone at Epic to update it?

I’ve added a clause to the coding standards to reflect the inability to use namespaces around UTHINGs. I will see about getting the website updated with this and other changes, as it is rather out of date.

Steve

Cool. I’m also wondering, is there any particular reason this isn’t planned to be supported?

Mainly that it’s a feature that comes along with a lot of implicit baggage. UnrealHeaderTool would need to be able to made to understand namespaces, so we’d have to add UNAMESPACE() macro to parse it and a new UNamespace type added to be an appropriate outer for the things declared within it, as well as generating code which would need to forward declare everything (for better or worse, we implicitly forward declare a lot of types using elaborated type specifiers - Elaborated type specifier - cppreference.com - which is problematic for namespaced types). The editor and blueprints would also need to be able to deal with them (and in BP’s case - create them), and our object naming convention would need to change.

So it’s simply an engineering choice - this feature would be a lot of work for a (perceived) relative lack of benefit.

Steve