Why not put PlayerViewPoint Loc and Rot as private member variables instead?

[NicolasEspinozaR]

Hi,
So, Is it truly necessary to declare variables every tick, as in Grabber.cpp, inside void UGrabber::TickComponent?

// Called every frame
void UGrabber::TickComponent(float DeltaTime, ......
{
	Super::TickComponent(DeltaTime, TickType, ThisTickFunction);

	// Get player view point every tick	
	FVector PlayerViewPointLocation;
	FRotator PlayerViewPointRotation;
.....
}

Wouldn’t have been easier to put them under Grabber.h as

UCLASS( ClassGroup=(Custom), meta=(BlueprintSpawnableComponent) )
class BUILDINGESCAPE_API UGrabber : public UActorComponent
{
	GENERATED_BODY()

private:
	FVector PlayerViewPointLocation;
	FRotator PlayerViewPointRotation;

for example?

Cheers
/Nicolas.

[QueueButton]

It really depends on what you’re doing. IDE’s may fuss about certain things in certain times as well so you know the devs who worked on the IDE (or whatever) opinion of where things should go as well at specific times.

But, generally, if you are not using class/header global for the variables then perhaps they should be local to the block/function only.

There’s also possible performance and also memory usage to think about as well. Re-creating objects may cost more performance vs say checking a bool and the more global the variable the more likely it is to stay in memory (besides static,etc which I’m not getting into here). Oh, and also garbage collection, and probably more I might of missed.

So there’s a good amount to think about.

[Rai_Kesh]

You could do that, I don’t think it will cause any problem. I tried doing that an it worked fine for me but i am not sure why we are declaring that in every tick, it may cause some performance issue too i guess but it’ll be negligible here in this project if i am right. Not sure though as i too am a beginner. Maybe Ben did that to make it fast and easy for new students to understand, or maybe he didn’t thought of it.

[QueueButton]

Maybe Ben did that to make it fast and easy for new students to understand, or maybe he didn’t thought of it.

That’s possible. If they over complicate it, beginners to code will get lost or it will be too much too soon.

You can really complicate things to the point nearly no one who’s learning would do it. I mean at this time in the course you wouldn’t even understand how threading is taking place, how to diagnose performance, how to freeze up the UI, how to use another variable in another thread that’s in another class, fixing memory leaks, and a lot more.

You won’t really understand until you have at least a year of quality programming under your belt.

[Rai_Kesh]

You won’t really understand until you have at least a year of quality programming under your belt.

I think this is true especially if you are dealing with OOP not to mention that Ben also used some generic programming concept(at least at two spots if i remember correctly) and if a beginner is being introduced to all these stuffs while keeping in mind all the performance and memory then i guess it will really demotivate a lot of students. OOP alone is enough to raise a million questions in the mind of a beginner like when to use a class and when to use inheritance etc(though we didn’t see much of this in the course if i remember correctly but the examples of the concepts of OOP out there will scare the hell off a beginner for sure). Also around that particular video a lot new things was introduced so i think he did it to make life of his student a bit easier. Besides we can always use OOP concepts whenever needed as long as it’s not causing an issue.

[NicolasEspinozaR]

I guess is right, there are optimization issues that we are not tackling at the moment (and probably never will, I dunno yet). I guess in the way the code is presented now is easy to understand what is happening. The more complexity there is, the scary it becomes.

Thank you all for your answers

BR
Nicolas.

[DanM]

Rule 1 always profile before doing anything in the name of performance.

With that said It’s almost definitely better to have them as local variables, they aren’t being used by other functions so there’s no reason to store them as part of the class which would mean having them in memory for the entire duration of the lifetime of the object.

Whereas with a local variable the compiler can make smarter optimisation decisions and possibly optimise them away which it can’t do if it’s part of the class’ layout.