How to determine if an object is a pointer

Unreal Courses Ask
#1

Currently going through lecture 124. Using Physics Handles.
https://www.udemy.com/course/unrealcourse/learn/lecture/17707356#overview

At 04:15 the lecturer instructs us to hover over PhysicsHandle.
This way, we can determine if PhysicsHandle is a pointer or not.

This is assuming that Intellisense is working.
If Intellisense is broken, how can we determine if an object is a pointer?

I looked in the Unreal docs.

https://docs.unrealengine.com/4.26/en-US/API/Runtime/Engine/PhysicsEngine/UPhysicsHandleComponent/__ctor/

I’m not seeing anything obvious that states that UPhysicsHandleComponent is a pointer.

Other objects have asterisks beside their type.

I’m using VS Code 1.56.2
and latest version of Unreal
on Linux Ubuntu LTS 20.04

Alternatively, if someone knows how to get Intellisense working (it is broken for many people) then that would be excellent.
My own attempts at fixing Intellisense have not worked.

VS code intellesense not working!
404 Page Not Found for functions
#2

Because it was declared as such previously., BE_38 Using FindComponentByClass() to be specific.

If by object you mean the actual terminology of “object” that is, loosely, “a region of memory of some type of some value”. Then it would be declared as such e.g.

Type* Foo;

If you meant the type which you seem to have meant based on what you say next.

You can have a pointer to any type, int, FString, bool. Nothing* about the type says whether or not the object is.

Anything that exists in the game world is going to have to be dynamically created during runtime which means the use of pointers.

* I guess it could be argued that’s a little misleading due aforementioned reason.

#3

Sorry, I will be more specific.

At the timestamp of the linked lecture, the lecturer tells us to hover over the variable to determine if we need a ARROW " → " operator or a DOT “.” operator.

He uses Intellisense extensively.

Using Intellisense he constructs the next couple of functions.
By hovering over the function he shows us what varaibles are required and what operators to use (DOT or ARROW).

He assumes it is working, but also acknowledges in previous lectures that it may not be.
That is the problem.
His lectures are superb! But this is a major roadblock in the tuition.

So what I mean by “how can we determine if an object is a pointer?”
is how to determine what kind of operator to use.

He states that UPhysicsHandleComponent is a pointer, therefore we use the ARROW operator.

I suppose the most straightforward solution to this is having an Intellisense setup that is the same as the lecturer.

You mentioned something in a thread a few days ago…
Is there a known and working fix for Intellisense? I’m not the only one with this issue and there must be a fix that half of us are unaware of.

Do we add the directories containing the header files we are using
(ie- /Engine/Source/Runtime/Core/Public for the CoreMinimal.h header file) to a certain configuration file ?

Thanks for your time.

#4

You shouldn’t need to do anything. What version of Unreal are you using? 4.25 to 4.26.0 has issues generating VS Code projects, and it seems the C/C++ extension on macOS has issues, is that what you’re using?

#5

Unreal version 4.26.2 (it was compiled a week ago and the release date is 14th April.

Linux Ubuntu 20.04

Intellisense was so bad that for the BullCows project all the code beneath the #include … lines was underlined in red squiggles!

The code compliled fine, as the fault was with Intellisense only.

Other users on other Unreal forums said that this was due to Intellisense not knowing where the #include … .h files were (even though VS Code compiler knew).

EDIT:
If I may ask, did previous fixes involve pasting about 200 lines worth into the “defines”: section of the configuration files ?
https://drive.google.com/file/d/10TyPGe_3xewDJ9SCqYg1eHgrByNFXIoG/view
Here is the link.
However it appears to be for Windows users.

Is there a similar fix we should be aware of ?

EDIT 2:
Intellisense Error Output in VS Code:

[10/06/2021, 9:48:04 pm] For C source files, IntelliSenseMode was changed from "linux-clang-x64" to "linux-gcc-x64" based on compiler args and querying compilerPath: "/usr/bin/gcc"
[10/06/2021, 9:48:05 pm] For C++ source files, IntelliSenseMode was changed from "linux-clang-x64" to "linux-gcc-x64" based on compiler args and querying compilerPath: "/usr/bin/gcc"
[10/06/2021, 9:48:05 pm] Unable to resolve configuration with compilerPath "cl.exe".  Using "/usr/bin/gcc" instead.
[10/06/2021, 9:48:18 pm] "Grabber.cpp" not found in "/home/chickpea/ue/UnrealEngine/Engine/Source/ThirdParty/ShaderConductor/ShaderConductor/External/DirectXShaderCompiler/tools/clang/bindings/python/tests/cindex/INPUTS/compile_commands.json". 'includePath' from c_cpp_properties.json in folder 'Building_Escape' will be used for this file instead.
[10/06/2021, 9:53:40 pm] "Grabber.cpp" not found in "/home/chickpea/ue/UnrealEngine/Engine/Source/ThirdParty/ShaderConductor/ShaderConductor/External/DirectXShaderCompiler/tools/clang/bindings/python/tests/cindex/INPUTS/compile_commands.json". 'includePath' from c_cpp_properties.json in folder 'Building_Escape' will be used for this file instead.

Note: even adding the directory containing Grabber.cpp into the c_cpp_properties.json file will not enable Intellisense to see the file.

Hovering over #include “Grabber.h” in the Grabber.cpp file which is part of our Building Escape tutorial reveals:

#include errors detected. Consider updating your compile_commands.json or includePath. Squiggles are disabled for this translation unit (/home/chickpea/Documents/Unreal Projects/Building_Escape/Source/Building_Escape/Grabber.cpp).C/C++(1696)
cannot open source file "UBT_COMPILED_PLATFORM/UBT_COMPILED_PLATFORMPlatformCompilerPreSetup.h" (dependency of "Grabber.h")C/C++(1696)

Hovering over #include “Engine/World.h” reveals:

cannot open source file "Engine/World.h"C/C++(1696)

I have already added the directories containing each of these header files into c_cpp_properties.json file.

{
            "name": "Linux",
            "includePath": [
                "/usr/include",
                "/usr/local/include",
                "/usr/include/c++/7.2.0",
                "/usr/include/c++/7.2.0/backward",
                "/usr/include/c++/7.2.0/bits",
                "/usr/include/linux",
                "/usr/include/x86_64-linux-gnu",
                "/usr/include/x86_64-linux-gnu/c++/7.2.0",
                "${workspaceRoot}",
                "/home/chickpea/Documents/Unreal Projects/Building_Escape/Source",
                "/home/chickpea/ue/UnrealEngine/Engine/Source/Runtime/Core/Public",
                "/home/chickpea/ue/UnrealEngine/Engine/Source/Runtime/Engine/Classes/Engine"
            ],
            "defines": ["${default}"],
            "intelliSenseMode": "clang-x64",
            "browse": {
                "path": [
                    "/usr/include",
                    "/usr/local/include",
                    "${workspaceRoot}"
                ],
                "limitSymbolsToIncludedHeaders": true,
                "databaseFilename": ""
            },
            "compilerPath": "/usr/bin/gcc",
            "cStandard": "gnu17",
            "cppStandard": "gnu++14",
            "compileCommands": "/home/chickpea/ue/UnrealEngine/Engine/Source/ThirdParty/ShaderConductor/ShaderConductor/External/DirectXShaderCompiler/tools/clang/bindings/python/tests/cindex/INPUTS/compile_commands.json"
        }

I wish I were more knowledgeable on this subject.
I’m not sure where to look - are there quirks that experienced folk are aware of?

#6

That was the workaround for the issue in 4.25. 4.26 changed the way IntelliSense gets the project information, via compile commands. So IntelliSense is given the same command the compiler would invoke.

@SHuRiKeN may be able to assist you better than I regarding IntelliSense on Linux.

#7

Thanks for your time Dan.

So modifying c_cpp_properties.json* doesn’t seem to be the solution.

Do I need to message @SHuRiKeN or will they be alerted to this thread by the mention of their username?

For what it’s worth, I just discovered this post on StackExchange.

Also note that as of this posting 5/6/2021 Intellisense will continue to have difficulty loading CoreMinimal.h because of a separate and unrelated problem relating to macro expansion. You may see:

cannot open source file "UBT_COMPILED_PLATFORM/UBT_COMPILED_PLATFORMPlatformCompilerPreSetup.h" (dependency of "CoreMinimal.h")

So while CoreMinimal.h will still appear red-underlined, the reason is different now. That’s progress!

Note:
Looking at the rest of that post, we can see that they are using the current 4.26 version.

So it appears that the bug you mentioned from 4.25 is still around.
I think I found the Unreal bug report:

It lists the fault as fixed… but there are still issues.

#8

They would have gotten a notification with the mention.

Do you have compileCommands files/folders? They should be within the .vscode directory.

#9

Yes I do have compileCommands files.

The files are huge so I won’t link them here.
But they go like…

“file”: “/home/chickpea/Documents/Unreal Projects/Building_Escape/Source/Building_Escape/Building_Escape.cpp”,
several text pages of compiler commands…
“directory”: “/home/chickpea/ue/UnrealEngine/Engine/Source”

And so forth.

#10

@Bananas Hi, Defines were meant to be used in 4.25, in 4.26 compile commands is used.

regenerate project files and try find and replace all -

"command": "

with

"command": "\"\"

in the compileCommands_YourProjectName.json file. However this must be done every time you refresh the project for now. Will assist you further if this works.

1 Like
#11

Hello,

I did the replacement.

[11/06/2021, 10:09:32 am] For C source files, IntelliSenseMode was changed from "linux-clang-x64" to "linux-gcc-x64" based on compiler args and querying compilerPath: "/usr/bin/gcc"
[11/06/2021, 10:09:32 am] For C++ source files, IntelliSenseMode was changed from "linux-clang-x64" to "linux-gcc-x64" based on compiler args and querying compilerPath: "/usr/bin/gcc"
[11/06/2021, 10:09:32 am] For C source files, IntelliSenseMode was changed from "linux-clang-x64" to "linux-gcc-x64" based on compiler args and querying compilerPath: "/usr/bin/gcc"
[11/06/2021, 10:09:32 am] For C++ source files, IntelliSenseMode was changed from "linux-clang-x64" to "linux-gcc-x64" based on compiler args and querying compilerPath: "/usr/bin/gcc"
[11/06/2021, 10:09:32 am] Unable to resolve configuration with compilerPath "cl.exe".  Using "/usr/bin/gcc" instead.
[11/06/2021, 10:09:32 am] "Grabber.cpp" not found in "/home/chickpea/ue/UnrealEngine/Engine/Source/ThirdParty/ShaderConductor/ShaderConductor/External/DirectXShaderCompiler/tools/clang/bindings/python/tests/cindex/INPUTS/compile_commands.json". 'includePath' from c_cpp_properties.json in folder 'Building_Escape' will be used for this file instead.

Error messages unchanged.
Behaviour unchanged - following the lectures to determine if an item is a pointer or not by hovering the mouse, or loading function parameters does not work.

Do you wish me to post any config files ?

Thankyou for helping.

EDIT:
All the #include … .h" lines of code have red squiggles with the error:

#include errors detected. Consider updating your compile_commands.json or includePath. Squiggles are disabled for this translation unit (/home/chickpea/Documents/Unreal Projects/Building_Escape/Source/Building_Escape/Grabber.cpp).C/C++(1696)
cannot open source file "UBT_COMPILED_PLATFORM/UBT_COMPILED_PLATFORMPlatformCompilerPreSetup.h" (dependency of "Grabber.h")C/C++(1696)

Is this an old bug that has not been properly patched, even though the Unreal bug report says Fixed?
One of the last posts to DanM has a another user with the current 4.26 version experiencing this same issue.

#12

Hi @Bananas

You don’t have to use Intellisense in order to determine whether it’s an object or a pointer, this is a possible but not the only way of doing it. There is another way which comes in first place. You should check an object’s declaration to see whether it’s an object or a pointer. For example:

UPhysicsHandleComponent PhysicsHandle; // this is an object

UPhysicsHandleComponent* PhysicsHandle; // this is a pointer (the * indicates it)

So, it depends on how you declared it and if you look into your header file you will see that PhysicsHandle is declared as PhysicsHandleComponent* which is a pointer. If you declared it without a *, it would be an object.

Same here, just check a function’s declaration to see what kind of arguments it receives: objects or pointers.

#13

Hi Artemachka,

Absoutely, I agree, that would be easy if we had already used the objects/variables.

In the Building_Escape we are instructed to use a UPhysicsHandleComponent, then the lecturer ponders on whether to use a DOT operator or ARROW operator.

As we have not previously used this type, I looked at the Unreal Documentation.

Unfortunately, being a beginner coder, I can’t see anything that would suggest that UPhysicsHandleComponent is a pointer (and therefore needing to use an ARROW operator).

That was actually my question in the first post, before all the Intellisense workings.

Using the UPhysicsHandleComponent as an example, how do we determine what is a pointer by reading the Documentation.
The lecturers just used Intellisense to find out.

Wait, we can use UPhysicsHandleComponent as a non-pointer object?
The lecturer seems quite strict on what is a pointer and what is not.

Example: For the OpenDoor.cpp file, we use:
GetOwner()->GetActorRotation()
not:
GetOwner().GetActorRotation()
because GetOwner() is a pointer.

Indeed, Intellisense does look like an indulgent crutch, but the lecturers use it to make decisions, which leaves me scratching my head as to how they would otherwise make these determinations.

Cheers.

#14

UPhysicsHandleComponent itself is a type and you can create objects or pointers of that type. So, if you declare like this:

It means that you declare an object called PhysicsHandle of type UPhysicsHandleComponent.
And if you go like this:

It means that you declare a pointer called PhysicsHandle of type UPhysicsHandleComponent.

GetOwner() is a function which returns a pointer, so after calling it you get a pointer and you have to use arrow operator instead of dot operator.

#15

Thankyou, that careful wording clarifies things.

I reckon lectures are excellent, make no mistake.
But it can be very easy for a lecturer to slip into a familar venacular (IS a pointer vs. RETURNS a pointer), which newcomers take literally.

Hmm, yes. Well stated.
.
.
.

AActor * GetOwner() const

GetOwner() returns a pointer to AActor.
.
.
.

UPrimitiveComponent * ComponentToGrab

And as used in the lecture:

UPrimitiveComponent * ComponentToGrab = HitResult.GetComponent()

So let me see…
HitResult.GetComponent() returns a direct object.

We declare ComponentToGrab as a pointer to that object, with ComponentToGrab being a datatype of UPrimitiveComponent.

That sounds like I’m on the right track?

#16

You are on the right track, although one thing is incorrect:

This returns a pointer, not an object. And you can see that from GetComponent() declaration or (as I specify here) from UE documentation:

UPrimitiveComponent * GetComponent() const

Its return type is UPrimitiveComponent* which is a pointer.

#17

Becoming clearer, thankyou.

#18

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.

Privacy & Terms