Is it a good idea to change the way some base class functions are implemented to avoid copy constructors?

Development Programming & Scripting C++
, , , , , ,
1

This code is from the programming quick starter guide:

void AFloatingActor::Tick( float DeltaTime )
{
    Super::Tick( DeltaTime );

    FVector NewLocation = GetActorLocation();
    float DeltaHeight = (FMath::Sin(RunningTime + DeltaTime) - FMath::Sin(RunningTime));
    NewLocation.Z += DeltaHeight * 20.0f;       //Scale our height by a factor of 20
    RunningTime += DeltaTime;
    SetActorLocation(NewLocation);
}

I had a question regarding design choices. This code has calls to copy constructors. Let’s take a look at this line specifically

        FVector NewLocation = GetActorLocation();

A return value is initialized and then passed to the copy constructor of FVector. This will happen on every “tick” of the game running. Let’s suppose I have lot’s of vectors in this Tick function. Perhaps, inside of this Tick function, I also add some other similar classes that are having their copy constructors called as well. Perhaps some of those copy constructors do a lot of work. Would it make sense to change the engine base class code so that FVector is dynamically allocated before Tick is ever allowed to run, and then a smart pointer is is passed to the GetActorLocation function which updates the information that is stored in memory? Or does that compromise certain design choices of UE? Or am I just confused :)?

2

SyMutex that was very bad advice.

first of all this is invalid since the GetActorLocation is not returning the location as a reference

const FVector& CurrentActorLocation = GetActorLocation();

const cast should not be used in most cases, usually if something is const there is a reason for it (except if the programmer didn’t know what he was doing or if const correctness wasn’t observed)

also in regards to the original question, yes it might seem a little bit inefficient to return FVector instead of a FVector& BUT what is more important is to understand why that is the case, a loock at the engine source code provides some insight!

	/** Returns the location of the RootComponent of this Actor*/ 
	FORCEINLINE FVector GetActorLocation() const
	{
		return GetActorLocation(RootComponent);
	}

as you can see it will actually get the location from its root component , the root component can be anything.
It might or might not store the Location internally or it might compute it every frame.
Thus this method cannot return a “const FVector&”.

I suggest to read up on some general C++ good practices :slight_smile:

3

I’m betting you are planning on upgrading your version of unreal at some point. Do you really want to integrate all of those changes?

Assuming that you are experiencing performance issues, a quick profile will quickly show that this FVector construction is the least of your worries. This is an inline function, that with most compilers and on most platforms in an optimized build will turn into a vector register assignment. Or for example on pipe-lined Intel hardware as 3 floating point assignments, these will most likely all execute at the same time.

Imho, you’d do much better trying to solve problems that actually exist.

The benefit of using a third party engine like Unreal, is that you don’t have to worry about the minutia. This free’s you to focus on things that really matter, like content, and core gameplay mechanics.

When you reach a point where you find there is a problem, then focus on a specific fix.

And if it turns out that this FVector constructor is causing you problems, I would recommend deriving your own “AFloatingActor” class, and implement the Tick() function how you wish. You’ll save yourself a ton of time integrating engine changes.

cheers -