Is there even a downside to using CPP? Serious question...

Very new to CPP, more experienced on the blueprint side.

I’m noticing that you can still make your every day blueprint actor types, except with CPP you can include custom CPP methods without going through all the scripting. But at the same time, mix scripting with your CPP code.

It feels like you can just mix and match whenever you want. With that said, is there actually a downside to CPP (besides the potential learning curve)? Can you make a CPP project but still have all the same benefits of blueprint scripting?

Blueprint is getting better, but IMHO nothing beats plain old texts when it comes to programming. In my experience using UE4 so far, best workflow we found is to code everything in C++ and let designers animate or set parameters or customize a little bit of behavior through blueprints.

For example, we have a gun class in C++, a muzzle scene component to play muzzle fire from and a variable for muzzle fire particle effect asset.
Designers derive a blueprint from this base class and call it AK47 for example, he adds his own mesh, position the muzzle scene component, assign muzzle fire particle effect asset.
Everything just “works” without designers coding, and without coders needing know too much about the “visual” side of the gun.
It works pretty well in our case, and when we add BlueprintImplementableEvent functions, designers can “code” response to certain events that happen in the game.

In my biased opinion, nope!

The general consensus if you’re doing a C++ project, is to write all of your code in C++ and then Abstract those classes in Blueprint, and simply setup the default parameters. For example, say you have two characters which only differ in terms of their visual appearance or their voices - don’t create a class for each Character in your game, create one Character class in C++ that does all the lifting, then create two Blueprints of that C++ class, and set all the parameters there.

This is what I figured but I wanted to ask first because I plan on making a new CPP based project.

The problem is that I don’t really know CPP. I have experience in C# and while visiting guides I’m finding CPP has a lot of similarities. But I worry that I will hit a lot of walls during development, due to my lack of CPP knowledge. However, if CPP and Blueprints can flow seamlessly together I have nothing to worry about. I can code what I know in CPP and work in blueprints when I get stuck. It might seem counter-productive at first, but this will allow me to continue testing and working on new material while I research and learn on lesser problems.

With all that being said I’m really excited to start working on my new project knowing I can take my current knowledge of blueprints and smoothly transition between CPP and visual scripting. This is great!

Blueprints are better for prototyping gameplay. Other than that, the only downside I see is the long initial compile times when working with a source version.

If you don’t know C++, best to use Visual Studio as your editor. Intellisense, for all its downsides, is rather useful to get your feet wet. When you get more advanced, you can graduate to a faster editor. I use the Atom text editor, sacrificing code linting and autocompletion for pure speed, quick file find times, and ease of use.

The hardest thing to get about C/C++ is pointers. Not because they’re difficult; they’re probably the simplest and most powerful feature of the language. What makes it difficult (for some people, I assume) is the fact that it’s so alien and different to the normal way of thinking in a automatic-memory-management language. Now, I can’t really speak about C#, but it looks like it has pointers in a limited context, so that shouldn’t be too difficult for you.

I do mostly understand pointers. I’m also using Visual Studio 2015 as that’s what I’m used to from C#. You mentioned automatic-memory-management, which from my understanding UE4 does support in the form of garbage collection? I’m aware of scope in terms of protected, static, global, local and so on. Would I be correct in assuming that any actors destroyed using a class will also clear any variables in memory linked to said actor from class? You don’t have to manually clear out pointers and such, do you? I wouldn’t think so, but again, being new to CPP it seems worth asking.

UE4 does have a mostly automatic memory management system, things like TSharedPtr/Ref for reference counting, etc, but you are still programming in C++, so if you move beyond the UE4 framework to implement any systems of your own, you’ll be dealing with that.

Variables in classes are automatically destroyed by C++ itself, but pointers are not automatically free()d. Unreal’s smart pointer library helps with this, and almost all memory management is handled by engine internals anyway. In fact, it is a Bad Idea to call free() or delete on a object in the engine architecture.

In my understanding, only use a raw pointer (type* name) if you know the object pointed to absolutely exists (passing a class variable from the owning class) and you know the pointer will only exist for a short time. There are some exceptions to this, but those are mostly common sense based.

In summary, to destroy an actor, call Actor *-ish -> Destroy() [or whatever the current API name is]. Don’t do delete Actor *-ish / free(Actor *-ish). UE4 internals take over at Destroy(), handling everything from there.

EDIT: Also, this post is useful: