Also, there is a option in the Visual Studio installer to have a “Game development with C++” thing installed. Is this necessary, and/or would it help with making a game? Is there anything else that is good for working with C++ in Unreal?
Also I’m new to C++ but have experince with C# so I as wondering about ., ->, and ::. I think that :: is used for accessing static values, and -> is for accessing instance values, but what about .?
Also, why does Unreal name all your classes A[Your Class Name], and why do you have to use a pointer for things like UStaticMeshComponent?
Thanks in advance for helping me with beginner questions.
Worth noting: This naming convention is not optional. If you don’t stick to the naming convention, your stuff won’t build, or won’t work if it does.
In the .h file for an actor there are two publics::
class [GameName]_API AMyActor : public AActor
{
GENERATED_BODY()
public:
// Sets default values for this actor's properties
AMyActor();
protected:
// Called when the game starts or when spawned
virtual void BeginPlay() override;
public:
// Called every frame
virtual void Tick(float DeltaTime) override;
};
Is there a reason for this? Should only certain things be put under each one?
You should always keep your header file and your cpp file in the same order, and you should keep related code next to each other. You can have multiple private/public/protected sections in the header file to keep different bits of related code together (so you can have a bunch of private or protected variables related to a single feature, and then public functions to access that feature, and keep them all next to each other). It’s good code organization, and also if you try to initialize variables in your C++ constructor out of order, you’ll get some nice big fat warnings from the code compiler, because that can mess things up.
In this specific case, it goes constructor, then BeginPlay, then Tick, because that’s basically how the class flows – your first code runs in constructor, then your second code runs in BeginPlay, and then Tick runs continuously after that. If you were to add PostInitialization, I’d put it between constructor and BeginPlay, and if I were to add a OnDestroy or a destructor, i’d put it at the end, and everything else in between Tick and Destructor/OnDestroy
Basically, keep like features together and try to keep flow in mind.
I think your best option there is to get modern hardware. Visual Studio and Rider both have good Intellisense functionality, but you’re crippled if you don’t have a SSD and a large quantity of RAM to hold the caches.
There is exactly nothing in the language, compiler, or runtime that requires this.
Many people may think this is a good idea for organization/navigation purposes, but that doesn’t mean “you should always” do that – just that it’s a good idea if it helps you navigate.
The original question was about whether there’s some underlying language or engine functionality tied to there being multiple public sections. The answer is that, no, there is no reason, other than that’s what the programmer who wrote the code felt like doing. All “public” bits are equally public, and all “private” bits are equally prive, and all “protected” bits are equally protected. Even the order of functions in the header doesn’t really matter, except in very esoteric cases where you want to call code built by one version of the code from code built by another version of the code (having to do with vtable layout/ordering.) This approximately never matters. When it does, “add new things at the bottom, and never delete anything, even if it’s not used” is the simplest way to make it work.
I thought I made it clear that none of that was necessary (except for when you are initializing in your constructor!) but was a good idea / standard practice from an organizational standpoint. And I’d also forgotten about the case where a header change could blow up another binary that depends on your code, even if you change no code at all, simply because that situation does almost never ever come up when you’re dealing with the entire code base, as we usually are here. . . so thanks for also reminding me of a concept i’d completely forgotten about
Yeah, the only time you suddenly need to worry about this is when you need to support user-built mods (or editor variants, or whatever) at the binary-compatibility layer.
And then, it suddenly matters a whole lot, and the bug reports and stack traces will be all kinds of … amazing … when they mis-match, and nobody will understand what’s going on!
… Not that that would ever have happened to me, so I wouldn’t know …
You have 666 views, and I have to make it 667 so I can keep you out of trouble, so I would study one more thing (one more view) is the way unreal handles classes and all the other stuff such as uproperty tags and similar things so you don’t get a headake it’s called unreal C++ + plus plus api code and you would be getting lots and lots of → -> → components and load on pointer to some functions.
it’s called unreal C++ + plus plus api code and you would be getting lots and lots of → -> → components and load on pointer to some functions.