What exactly is a pointer?

Curious, what does this mean as an input argument?

const uint8 *& Buffer

Along those lines, what’s **?

I’m only into month two, holy ****. I can second the part about treating it like a scripting language as well. But it means I have to go back through my code adding consts and checking memory usage everywhere periodically.

It is a reference to a pointer to const data.



void test(const int *& arg){
     static int test = 1;//static value persists between calls; not thread-safe
     if (arg){//allowed
          std::cout << *arg << std::endl; //allowed.
     }
     arg = &test;//allowed;
     *arg = 1; //compile error.
}


Pointer to pointer.



    int a = 0;
    int *b = &a;
    int **c = &b;
    **c = 1;//a is now 1.


Got it. Convoluted, but it makes sense after reading the whole thread again.

Language will get significantly more convoluted if you make it to templates and lambda functions.

I’d like to elaborate a bit on my previous post.

Here’s silly example:



#include <iostream>
#include <vector>
#include <algorithm>


template<typename T, typename T2> void fill(T &arg, T2 func){	
	std::generate(arg.begin(), arg.end(), func);
}

int main(){
	std::vector<int> tmp(10);
	int i = 0;
	fill(tmp, &](){return i++;});
	std::for_each(tmp.begin(), tmp.end(), ](int &arg){
		std::cout << arg << std::endl;
	});
}


That require C++11 compliant compiler, MSVC should be able to handle that, though.

Also, C++ include standard library which contains such amazing things as std::future, std::algorithm, etc. Those are template-based and they can be used on any type that meets requirements. Templates allow you to do arcane things like template metaprogramming and they distance you from low-level ideas like looking at memory directly. hen there’s also inconsistency regarding support of features in the latest C++ standard. For example, msvc used to have the worst C++11 support(IIRC they were missing custom literals, utf8/unicode strings and a lot of other stuff), although it seems that things are improving in VS2015. At some point you’ll dive into C++ standard and learn about “undefined behavior” and might turn into language lawyer. Then the committee will release next version of language, and you’ll need to relearn half of it.

The foundation of the language require at least one 1000+ page introduction/reference book(Bjarne stroustroup’s books works for that) that you’ll read and keep as nearby reference and (optionally) 1300+ page language lawyer book that describes language so you can always decide what is defined and what is undefined behavior, then you’ll need to spend few years to wrap your head around that. The amount of tools is immense and there’s large number of ways to use and misuse them, that’s why you’re gonna need the amount of time listed.

That is why I said that expecting to know foundations is unreasonable. Payoffs are big, and language rewards discipline, but not every person has this kind of time.

Judging by what I saw in UE engine and its documentation in the short time I spent using it, it seems that UE4 programming team put significant effort into making the language accessible to people with less C++ experience, so you should use facilities that were specifically designed to make people’s lives easier.

Which means, when your goal is to make games, you should make games instead of studying C++ “till you are ready”. You are never going to be completely ready, and there always will be more information to learn.

So, when the goal is game-making, people should use C++ as if it were a scripting language.

But many engine users are learning in hopes of someday making a job out of it;
If you tell people to follow this path they must not have such intentions, because that mindset most likely will never land the new commer a job making games.
Companies have too many options nowadays, too many guys trying to develop games as a living; if they can’t master C++ and some scripting languages… is close to impossible for them to land a job from that company they love, working as a programmer.
The average Unity/UE4 coder will never make it, at max a job working for small replaceable studios.
If they want a job, they must master the C++ hell;

To work for the bigger companies,
Knowledge of machine code is required too, OpenGL, databases, voodoo and kung-fu as well.
Also, must have a ponny tail, bad beard and googles and must be fat or they won’t believe the guy is a good programmer :wink:

I don’t think NegInfinity is right on a couple of things.

The fundamentals won’t take you 5 years. All the fancy features up to C++14, sure, they might, but the basis of the language definitely not, a month or two if you’ve got programming experience I’d say.
You need a basic understanding of the language, you don’t have to master it. Pointers and references however you should learn about more since especially pointers tend to cause all kinds of problems. That is why references and smart pointers were added in the first place, but even with those you can easily **** up.
For instance you have to know that variables you made on a stack (e.g. “char[128] myArrayOfChars;”) are gone when the function returns (possibly even when they go out of scope, not sure about that), so any remaining references to them will point to some arbitrary point in memory that may have just about anything in it. Also smart pointers aren’t all that smart, they have set conditions on when they will deallocate memory.

Also const uint8 *& Buffer is a constant reference to a pointer to a uint8, not a reference to a pointer to constant memory. A constant reference means you cannot change the value it references, in this case, the pointer. I believe this is recursive, meaning the pointer itself is also constant so you cannot edit that value either. The point is that some other function might, while you are reading it.
I’m a little unsure about the recursive part as I don’t see what the point of a const reference to a pointer would be then, it’s just en extra fetch operation and pointers aren’t so large you’d like to reference them :S .

I have to disagree, people who want to learn C++ and be involved in games are really uncommon. People who want to design levels or make pretty pictures or playtest are way, way more plentiful. In fact, even having an all-round skillset is rare, most people get good at one thing and just do that and nothing else - or even just one design tool. Knowing how to model AND texture in three or four different programs puts you ahead of the pack. Doing content stuff and programming as well? You’re a one-man-band and can carry a whole team. This and the Unity community are producing incredibly talented, self-driven rockstars of game development.

The gaming world is laid wide open for anyone really motivated. Sure, there’s plenty of big old studios happy to lay all their staff off after a mandatory crunch, but those are no longer the only option. Think about it: would you rather work on CoD 23 or No Man’s Sky? The former is a meatgrinder and the latter locks themselves away for three months prototyping new games and just being creative. I know which one I’d go for.

I got my current role with the understanding that I’d learn C++ to do what they needed in UE, so lucky breaks do happen and I did learn it in about two months. I’m still learning though (this is actually month three) hence why you guys helping me is so warmly appreciated. Neg is right that the serious stuff is out of my reach at the moment - but maybe not five years out of reach. I got lucky finding a job with such kickass people but it can definitely be done.

With the *& thing, I think that in this case it’s the result of the pointer being generally available and then referencing that in case it changes, which makes sense in the context since it’s a texture asset import/export. Once NegInfinity explained it it clicked for me, especially since he happens to be doing the same thing I’m trying to do at the moment.

For example I’m currently writing to a texture asynchronously and then each tick that writing texture out to somewhere else. I also have a blank texture and a lock that tells me if the texture is being written to at the moment. I check the lock and return either. It’d be far better if I simply changed the pointer to the stand-in texture and started writing to the original memory space, then changed it back. Then if I want to use that pointer, I reference it in case it changes. I’ve found I end up redoing half my plugin each time I learn something new about C++ and this is going to be no exception.

If you learn C++ programming, you’ll be able to make game engines. That’s not the same thing as making games. You can make many engines and never release a single game.

I’m simply telling people to concentrate on game making. You can make job out of it too - you’ll become UE4 engine specialist. C++ is larger and more complex topic than “C++ in Unreal Engine 4”.

They will. You can pick basic syntax in 3 days, but that’s literally first 3 letters of the alphabet, not foundation.

You’re mistaken there, because you can reassign the referenced pointer. So it is not constant.

Constant reference to pointer to uint8 is
“uint8 * const & ref”



int test(int * const & ref){
	ref = 0;//error
	*ref = 1;//allowed
}




//const reference to pointer
int test(int * const & ref){
	ref = 0;//error
	*ref = 1;//allowed
}

//reference to pointer to const
int test2(const int * & ref){
	ref = 0;//allowed
	*ref = 1;//error
}

//const reference to const pointer
int test3(const int * const & ref){
	ref = 0;//error
	*ref = 1;//error
}


Some people change declaration order of const and int (int const instead of const int), and read the whole thing right to left, which helps them in order not to get confused.

It seems I’ve missed a few things about the interplay of const and pointers/references. Still, the value pointed to is not necessarily constant, you just can’t change it ‘from there’, that’s what I meant.

EDIT: Shouldn’t the last one be reference to const pointer to const int?
EDIT2: and the first one reference to const pointer? src: c++ - What is the difference between const int*, const int * const, and int const *? - Stack Overflow

That’s not relevant. Const denotes that compiler will prevent you from trying to change the value in the current scope. It doesn’t matter whether value is really read-only, the purpose of the keyword is to prevent you from shooting yourself in the foot. It is a safeguard. Thinking whether value is really constant or not won’t get you anywhere. You can still try change it using const_cast, which will trigger undefined behavior (and most likely crash the program) if compiler placed it into read-only memory location. Using const_cast would indicate “I really know what I’m doing” and should be avoided when possible. Additionally const (struct/class) value can actually be changeable under the hood and hold non-const fields in it using mutable keyword. At that point you get difference between semantic “constness” and “real” “constness”.

If you really wanna be specific that’ll be
1st is reference to (constant pointer value) which points to (changeable integer value);
3rd is reference to (constant pointer value) which points to (constant integer value);
And you could further elaborate that “points to (changeable/non-changeable integer value)” means “holds address or equivalent representation that converts to either null-ptr, undefined value, memory location, to which compiler will explicitly allow/forbid write access”.
But where’s fun in that?

Anyway, I think I’m done with the topic. Have fun.

Indeed. Knowledge of cache-temporal and -spatial locality are vastly important issues for writing high-throughput game code, among many other concepts. But even hobbyists’ throughput can be improved by many multiples with significant understanding under their belt. However, most people creating with the Unreal Engine have an idea of a real game that they’d like to release, which is why they’re picking up game development in the first place.

The core of the matter is: if you don’t want to spend the time to learn C++ (a completely reasonable desire) then you should choose Blueprints as your scripting tool. Blueprints encompasses most engine-level function calls that you would end up using in C++; and frankly, if you are trying to do anything out of the scope of Blueprints, it generally requires you to know quite well what you’re doing in C++, at least to the level of being able to read and understand large object-oriented code projects (the UE4 engine code you’ll be modifying!).

‘5 years’ and ‘full-time’ are insanely arbitrary, given peoples’ different rates of learning and backgrounds. Perhaps a foundational understanding of C++ will take a grievously long time to attain if you have no Computer Science/Organizational theory (please actually read my post) going into it, but if you learn the concepts in the proper order, learning enough to be an efficient UE4 C++ programmer should take a small fraction of your estimate, ‘part-time.’

A disappointingly, semantically insubstantial rebuttal…

I wholeheartedly agree. Also, congratulations on your position, your employers obviously think very much of you.

Thanks! Just wait till you see what we’re bringing to UE!

Finally someone’s answer contains: examples to EVERY case, explanations, opposites, conclusions AND useful extra knowledge… i think u won that challenge, lighting up cloudy brains even 7 years later! A true hero :smiley: