Frustration at myself...feeling truly lost anymore...anyone have this problem?

[BHX]

Well I thought, due to personal problems, that I would have to leave the site, but the problems were thankfully resolved. That and my wife has always supported me in my programming and dreams of being a game programmer and didn't want me to leave the last site I am part of.

Unfortunately, my confidence in my programming abilities is still suffering (borderline non-existent really) which has led to major frustration. I went through a book this past week Beginning C++ Through Game Programming to find that after 17 years I don't don't know pointers (beyond int a = 24; int *p = &a; as the book went into pointer functions string *function(string *name); that returned the address of the variable), and operator overloading (basically Chapters 8, 9, and 10 surprised me by not fully understanding them).

This made me wonder what else I don't know that I should have known by this time. Dealt my confidence another blow at that point. This led to me being severely frustrated at myself (and feeling utterly stupid at that point).

Here lately, I doubt myself so much that I feel completely lost and further away from my dream of game programming than I was when I first started as a beginner. Does anyone ever go through this? Does anyone go through it to the extent that I appear to?

[Disch]

I know all about being overly critical of yourself. I used to do a number on myself in that regard. I'm a lot better about it now, but I still think I'm harder on myself than anyone else is on me.

Unfortunately I don't really have any advice as for good ways to overcome it.


What I can say, though, is that if you want to pursue your dream of game programming... then just do it. All it takes is time and effort.

(basically Chapters 8, 9, and 10 surprised me by not fully understanding them).

This made me wonder what else I don't know that I should have known by this time

"Education is the progressive realization of our ignorance"

The more you learn the more you see just how little you know. You can't let that discourage you, because it just gets more and more extreme as you go along. Instead, it should excite you!

Reading about some programming topic in a book and realizing you don't know everything about it is normal. I don't know if there's many people here who could read an entire programming book and not take something out of it. If you didn't know everything about pointers or operator overloading... that just means you haven't had cause to use it yet.



Really it sounds to me like you should code more. I think that would solve a lot of your problems. Write code. You can even write sloppy, bad code that would be embarrassing to show off. The beauty about doing your own project is that you don't have to care what anyone else thinks about the code... you just have to care about how the finished product works.

In the process of writing that code, you'll improve. You'll see where/how your code is sloppy and you'll correct those mistakes in future code you write. Then in that code you'll discover whole new things that you're doing wrong and will correct yet again. It's just the natural process. Nobody starts our writing perfect code. Hell I've been writing code for 15+ years now and I look at code I've written as recently as 2 years ago and am amazed at how much I've grown since then.

So yeah. Pick a project and do it. Experience and time are the best teachers. If you're willing to entertain projects... I'd like to pitch my NES emu idea again. ;) Or if that's too overwhelming you can start with an NSF player (same idea... but only the CPU and APU so it plays just the music -- that's actually how I got started in emulation).

[Dy7SLyTq]

i didnt read through all of what disch said cause im tired, but i find it helps to take a project that you cant do, and learn along the way (well when writing your own code. i feel like this would be bad advice when writing it professionaly). one example is my pointer class im working on. its teaching me a lot about pointers that i didnt know and wouldnt have known. same with my compiler. im asking questions that i wouldnt have asked otherwise and now see jit compilers in a whole new light (of course it also introduced me to regular expressions. <shudder>)

[Disch]

(of course it also introduced me to regular expressions. <shudder>)

God help you.

Hahahaha

[Mats]

You should definitely push yourself to do some new projects! Perhaps you could join in this?

http://www.cplusplus.com/forum/lounge/118595/

Or maybe you can learn to use some of the new C++11 libraries or just some random useful ones like SDL or some boost libraries?

And you definitely should not leave this forum. Helping people on here will help your own coding.

[Dy7SLyTq]

God help you.

im pretty sure that bastard satan came up with them, so i doubt even god can help me in that realm :'( and you should definitly join the ai team!

[BHX]

Yeah, I'm staying on the forum. I only have GCC 4.7.2 and Clang 3.0.6 so I don't know how many C++11 features are available in each. Think I have boost, SDL, SFML, Allegro, OpenGL, Qt, and maybe a few others. I need to think of projects to do, just have to overcome my self doubt (somehow!).

[Computergeek01]

I'm glad to see that you're staying BHXSpecter, there aren't many of us that are self taught and seeing others here let's me know that I'm not wasting my time because I didn't go to school for this. What kind of games do you want to make? Do you have any ideas that are within reach (less then a year to completion)?

As for building self confidence I can say from my own experience that it is better to finish a smaller project, no matter how crappy you code it, then it is to aim to high and never hit your mark. If you need ideas then take a board game and implement it in C++. Nothing like Chess or Go, start off with something like Trouble, Poker and the like.

Don't feel self conscious about your code, the biggest grips on here are using the code brackets and spacing. I'm pretty sure that you're aware of both of those.

Don't get hung up about not knowing how to use function pointers. The times you need to actually use them are so few and far between that I can only really think of one use for them. The only reason I even know about them is because I was fiddling around with thread injection for a few months and I still get tripped up when it comes to casting them from void pointers.

[Dy7SLyTq]

for the record, being self taught sucks... because i had to teach myself it took me a long time to understand basic concepts like boolean values or command line arguments <edit>(although i didnt know about this site yet or the joy that is udacity)</edit>. i would also upgrade to gcc 4.8.1; i dedicated a day to bootstrapping it and installing clang. it was definitly worht it for the error handling and the features added. it would probably be less time for you because i was going from 4.6 to 4.8

[N36fSL3A]

I like being self taught. Since I've learned Ruby and GML to some extent basic C++ was easy for me until I hit pointers and such, then I went crazy. To this day I do not understand function pointers, now I have to use GLEW to load a 2.1+ OpenGL context :(

I'm glad you're staying, like Disch I would recommend a NES emulator, matter of fact, would you like to work on one together?

[Dy7SLyTq]

function pointers arent that difficult of a concept tbh, just weird so it makes them harder to understand. its just Datatype (*FunctionPointerName) (DatatypesForArgsFunctionTakesOrVoidIfNone) = &SomeFunctionWithTheSameSignature you can then use it as function arguments to make things like atexit ie int atexit (void (*func)(void)); ie atexit takes the name of a function that returns void and takes no parameters. i believe foreach() uses it

[chrisname]

Lumpkin wrote:

I do not understand function pointers, now I have to use GLEW to load a 2.1+ OpenGL context :(

Well, with GLEW, you don't really have to understand function pointers because it hides them from you.

What is it about function pointers that you find difficult to understand, anyway? Conceptually they're not that complicated, although the implementation of them in C (and therefore C++) isn't perfect. On any modern machine that you're likely to encounter, a function pointer is just the same as any other pointer, except that where a normal pointer's value is the address of a variable, a function pointer's value is the address of a function. If it's using function pointers that you don't understand, the basic idea is that you pass them when you want to allow a module to call a function that it otherwise wouldn't know about. In that context they're usually called callback functions or callbacks, but the terms are interchangeable. One instance where you might use use callbacks is with some kind of event-based architecture. Something like this, for example:

//-- In a library of some description...
// This typedef lets us use event_callback_t as a type.
typedef void*(* event_callback_t)(void*);
// Note: The * outside of the parentheses denotes that the function returns
// a pointer to void (void*). The one inside denotes that we're declaring a
// function pointer (Idk why it's necessary considering T*(foo) is not a valid
// declaration, but whatever).

static void* draw_callback_arg;
static event_callback_t draw_callback;
// we could also have written 'static void*(* on_draw_callback)(void*);'

void on_draw(event_callback_t render_function, void* arg)
// we could also have written 'void on_draw(void*(* render_function)(void*), void* arg);'
{
    // Save our own pointer to the function. An advantage of function pointers over
    // value pointers is that you don't have to make copies of them - they're
    // not going anywhere.
    draw_callback = render_function;
    // And speaking of creating copies of value pointers, let's not do that here.
    draw_callback_arg = arg;
}

// ...

void* call_render_callback()
{
    // Call the callback function as if it were a regular function, and not a pointer to one.
    return draw_callback(draw_callback_arg);
}

// ...

void* render(void* arg)
{
    Window* window = (Window*)arg;
    window.draw(something);
    return window;
}

// A long time afterwards, in a source file far, far away...
int main()
{
    Window* window = create_window();
    // Pass the address of the render function to the on_draw function, which sets the
    // function to call when the system wants to redraw the window (or
    // whatever). Note the lack of parentheses: we're not calling render and
    // passing its return value, we are passing the function itself.
    // Note that the address-of operator (&) is optional for some reason.
    on_draw(render, (void*)window);
    return 0;
}

You may be pleased to know that, in C++, function pointers have largely been superseded by function objects (classes with an overloaded operator() method, which allows them to be passed around as functions, but called as objects). Example:

// This is a function object (also known as a functor). It is a class that can be
// instantiated, and its instances (objects) can be called like functions, hence
// "function object".
struct is_nelson_mandela_dead {
    bool operator()()
    {
        return true; // No, really, look it up.
    }
};

// Note that I put std::function<bool()> here. Any function pointer of type 
// bool(*)(), function object with
// an operator() overload that takes no arguments and returns a bool, or any 
// lambda function taking no
// arguments and returning bool, can bind to it.
void check_if_nelson_mandela_is_dead(std::function<bool()> checker)
{
    // Call checker::operator(). This calls is_nelson_mandela_dead::operator().
    if (checker())
        std::cout << "Looks like Nelson Mandela is dead :(" << std::endl;
}

int main()
{
    // Create an object of type is_nelson_mandela_dead and pass it to
    // check_if_nelson_mandela_is_dead.
    // Note the inclusion of the parentheses because we're calling the
    // constructor of is_nelson_mandela_dead.
    check_if_nelson_mandela_is_dead(is_nelson_mandela_dead());
    return 0;
}

Hope that helps.

Computergeek01 wrote:

I still get tripped up when it comes to casting them from void pointers.

That may be because -- and someone correct me if I'm wrong, but I don't think I am -- casting a function pointer to a value pointer is undefined behaviour. I believe the reason is for portability: some machines use a segmented memory model where code and data are separate, so a value pointer to 0xABCDABCD and a function pointer to 0xABCDABCD could point to different locations. Modern day computers use a flat memory model (or, at least, pretend they do, as in the case of x86) so you *can* get away with that, but it's still undefined in C and C++ AFAIK, and compilers tend to just up and remove any code that relies on undefined behaviour. Compiler writers feel that, as undefined code is, by definition, not standard, they can optimise it out without breaking standards (technically they're making your code more standards-compliant). I agree with them, although I think they could at least generate a warning.

[BHX]

Well this is a function from the book I mentioned that made me realized I didn't know anything above the basics of declaring them.

string *ptrToElement(vector<string> *const pVec, int i)
{
	// returns address of the string in position i of vector that pVec points to
	return &((*pVec)[i]);
}

I just saw that and went 'HUH?!'.

I was confused on the returning the address of the pointer pVec[i] when the call was for a pointer to string type.

[LB]

@BHXSpecter: that example contains no function pointers. Did you copy and paste the wrong example?

[BHX]

Didn't say that was a function pointer. Just said that function made me realize I didn't know pointers as good as I thought.

[N36fSL3A]

Don't stress over it. It isn't worth it.

Well, with GLEW, you don't really have to understand function pointers because it hides them from you.

That's why I use GLEW.

The code was helpful but I don't even understand the use for function pointers in the first place.

[LB]

BHXSpecter wrote:

Didn't say that was a function pointer. Just said that function made me realize I didn't know pointers as good as I thought.

Ah. Well why does it confuse you? Nested expressions can be confusing, are you sure it's not the nested nature of it throwing you off?

[3qX21hU5]

I find that I much prefer the syntax of std::function (IE std::function<void()>) over C function pointers. They are much easier to understand and spot in the code and make them much easier to work with.

The code was helpful but I don't even understand the use for function pointers in the first place.

They provide you a way to call a function without knowing exactly what function you are going to call (All you need to know is the return type and params). This can come in handy in a bunch of different situations.

They are most commonly used for callbacks. For example in GUI programming you will see very heavy usage of function pointers (Though they usually will have added layers of abstraction to it).

They are also very useful for plugin code and code extensions. For example I have been playing with a in game console for debugging purposes and I wanted a way to easily plug in new commands into the console. A very simple way to handle this is to use function pointers. Using them I can now easily implement new commands that can be executed without modifying the existing class.

I have personally used them quite a bit in a few games to pass commands through scene graphs also.

[Disch]

string *ptrToElement(vector<string> *const pVec, int i)
{
	// returns address of the string in position i of vector that pVec points to
	return &((*pVec)[i]);
}

omitting the const for simplicity:

1) pVec is a pointer to a string vector vector<string>*

2) *pVec dereferences the pointer, giving you a string vector: vector<string>

3) (*pVec) puts parenthesis around it to assure operator precedence. Still have a vector<string>

4) (*pVec)[i] indexes the vector, giving you the string at position 'i'. Expression is now a single string from the vector: string

5) ((*pVec)[i]) put it all in parenthesis again. Still a string

6) &((*pVec)[i]) - the & operator gets the address of that string. IE: we obtain a pointer to element 'i' in this vector: string*

7) return &((*pVec)[i]) returns that pointer.

[N36fSL3A]

All that piece of code is doing is dereferencing the pointer to the vector with the '*' operator, then it gets the requested element with the '[]' operator that std::vectors overload. After that, it simply just returns the reference to the element. This stuff is the things you already told us you know. You can rewrite it like:

std::string *ptrToElement(std::vector<std::string> &vec, size_t i)
{
    return &vec[i];
}

The book just added extra nonsense for no reason.

EDIT: Damnit Disch you sniped me :(

My browser lagged out when I originally posted this and it turned out it didn't post on time...