I wonder where to use C++ and Blueprint. It is known that C++ for core functionalities and BP for some simple logic but I want to learn what are these core functionalities? Can you give one example for each(core func. and simple logic)
Performance is probably the main reason to use c++ instead of BP, even taking into account the new BP-to-c++ feature, but for me that’s not the most important reason to use c++. C++ is more versatile, more well-structured, and more easily maintainable/scalable than BP (if used well, of course). I’d also say it’s faster to work with most of the time, but that’s because I have a decent amount of experience with c++ and coding in general.
I’d say anything that can be seen as a “system” as opposed to a simple “operation” should probably be made in c++, because I find systems easier to manage and easier to understand in c++. I will also avoid doing every-frame operations in BP as much as I can, for performance reasons.
You can make a full game in BP, or a full game in c++. There are no rules, really. It’s just a question of what you’re comfortable with and how willing you are to extract the most out of the engine
I would like to know why do you inherit UMG widget from c++? What is the point? If you create it in blueprint entirely what would you lose?
(sorry I edited that part out of my answer, but I’ll answer anyway)
it’s just easier, faster (in the long run), clearer, and more powerful in general to implement any kind of functionality in c++, imo. With some exceptions
Unless we’re talking about doing simple stuff like opening levels, playing sounds, working with UMG, etc…, I don’t really see a reason to use BP over c++, aside from not knowing how to code or not having the time to learn
The real meat of game development will be things like doing GameManagers, networking, custom character controls, custom technology (procedural anims, level generation, etc…), inventory systems, game entity infrastructure in general, AI, weapon systems, custom editor tools (like a visual game state debugger window for example), etc… and those are a nightmare to do in BP in the long run. It’s so simple and fast to make an ultra-basic “hello world” game in blueprints, but the problem comes when you want to make more than just that
But… as always, it depends. It depends on your project, your experience, and your personal tastes
One more question: It is still hard to understand for me why I should use pointers. I red some articles but still do not get it. What is the best way to understand pointers?
Pointers are basically a feature that lets you remember the actual memory address of where a data is stored. That way, if you have a pointer to the player’s object, you can access it directly instead of going through a bunch of references ( MyGameInstance()->GameManager()->GetPlayer() ) to get it every time
Their whole purpose is to make memory access faster in general
Languages like C# manage this in the background automatically, but there is a performance price to pay for that. Actually even UE4’s weird flavor of c++ does part of that “auto memory management” for you when it comes to UCLASSes and UPROPERTIES, but you still have to declare variables as pointer types
C++ for all game logic. I then set default properties in Blueprints only.
I don’t use the node graph unless I’m using UMG, personally - but even then I do most of the logic in C++ and just set references to the individual widgets I want to manipulate in the BP.
As a programmer your most precious commodity is time, so work the best way that suits you and if it runs at your target framerate, who cares! 
Also, regarding pointers, reading this whole thread of answers will probably enlighten you: http://stackoverflow.com/questions/13223399/deleting-a-pointer-in-c
Personally I try and make systems dead simple for design and art. Most logic I put in C++ and then expose events like “Play Damage effects”, and event then as an engineer I review the state of the blueprints and might port stuff back to C++ if its getting too complex.
I do all code structure in C++, it just is so much easier to navigate. Almost every Blueprint that I have has a base class in C++, some of them are just properties at first and prototype gameplay functionality in the Blueprint, but then move functions into C++. I don’t have anything in Blueprints called every tick, but I do put some functionality that is on a slower timer. Tick code I put all in C++.
I use it like the folks above - I write the heavy stuff in C++ and expose some events for artists/designers to use, i.e. my shooting would be in C++, but I might have an OnShootFX() event in BP, which an artist can use to drive particle effects etc.
If someone is doing all C++ and not even setting properties and asset ptrs via blueprints/editor, they’re crazy. Hard-coding asset paths is ridiculous and a probable sign of someone refusing to accept change (i.e. ‘hardcore’ C++ programmers). If it works for them, great, but I would always recommend against it.
Yes, I agree.
A couple of months ago I was a hardcorde C++ only kind of guy, but Blueprints really come in handy when you do stuff like data-instances of classes, for example create BP derivates of a C++ Weapon Class, where you then just set the values for the damage, the projectile class and stuff like that.
Also I use it for UMG and HUD, what is way easier to sketch out with Blueprints. Eventually I end up porting that stuff to C++ later on, but the almost instant compile speed of Blueprints with no need of restarting anything makes a great platform for testing stuff.
And yes, system: C++. Functionalitys: C++ or BP. Stuff your 3D-Artist or some other non-c++ guys from your team needs to change: BP