Declared property first conflicts when function parameters of the same name

Development Programming & Scripting
1

I’ve hit his bug a few times and I finally figured out the exact condition that triggers it. Before it seemed to be happening randomly to some classes and not to others. Basically Anytime you Define a class field/property and then later on a function that uses a parameter with the same name the UBT throws an error stating that the function parameter conflicts with previously declared class field. HOWEVER move the field farther down below the declaration of the function… and as if by magic UBT does not care anymore. I’m not sure if this is happening with only propertys with classes or if regular types such as ints, floats, etc are effected as well…

This code Fails:

class myClass
{
protected:
    class ASomeClass * someClass;

public:
    void SetSomeClass(ASomeClass * someClass)
}

myClass:SetSomeClass(ASomeClass * someClass)
{
    this->someClass = someClass;
}

This Code Passes

class myClass
{

public:
    void SetSomeClass(ASomeClass * someClass)

protected:
    class ASomeClass * someClass;
}

myClass:SetSomeClass(ASomeClass * someClass)
{
    this->someClass = someClass;
}

You may ask why is this important… well it’s a matter of how I keep the areas of my own code ordered. Related sections are grouped together.

2

Hey -

Can you post the compile errors you’re getting are? Are both sets of code completely in the header file? When I test with the function definition in the .cpp file both sets of code will compile without issue. If I try to define the function in the header file then I get varying errors for each set.

3

Are you using those with UPROPERTY / UFUNCTION? If so, I found UE really doesn’t like if your function params have the same name as your properties. I usually just end up calling the params InSomeName

4

I don’t think it’s a bug. You can’t do it in Blueprints and since you’re effectively exposing that class to BP it makes sense to have the same limitation.

But I agree it’s inconvenient

5

Hello -

I have them separated out, declaration in the .h, implementation in the .cpp. I am also using UPROPERTY and UFUNCTION specifiers and the class is a UCLASS. I apologize if I over simplified the example. I will have to post the error later as I do not have the code in front of me at the moment.

6

Yeah, I thought the same thing. They are both UPROPERTY/UFUNCTION but the intresting thing I found is that if you declare the UPROPERTY at the END of your class declaration it works fine, but you move the UPROPERTY before any function that has a parameter with the same name and it explodes. Basically it shouldn’t do this anyway, and I am not fond of changing my own code standards because the build tool has a bug here.

However I really don’t care when or how it gets fixed but it is one of those things Epic and other developers should be aware of. Maybe one day they will fix it, it really is a minor annoyance once you know how to get around it.

7

Hey -

It seems there may be an issue with the variable/parameter shadowing. This has been reported (UE-27579) for further investigation. The best solutions would be to either define the function first as you pointed out or to use independent names for the variable / function parameter.

Cheers

8

Oh no, this is defiantly a bug, a very minor bug, but a bug none the less. Just because I put a UPROPERTY or UFUNCTION does not mean it is exposed to blueprints it means it is exposed to the garbage collector to keep track of. Further more, you CAN do it, you just don’t declare the property first and it compiles fine HENCE a bug.

9

I stand corrected :slight_smile:

10

It’s all good :slight_smile: But I had sort of just dealt with this for a while. If it was not for the fact that I discovered that the ORDER of the declarations mattered I’d have agreed with you that it was not a bug. I originally thought “Oh I just can’t do that” but then there where some times when I could. That was what made me suspicious that there is a bug in the system itself but I did not know to replicate it. I mean the code would compile just fine at first, then I’d go in and refactor something and suddenly compiler errors abound for something I had been doing all along. It was bazaar until I realized.