C++ avoiding pointers

Started by
15 comments, last by Jason Z 9 years, 9 months ago

Don't avoid pointers out of fear; if you're purposely avoiding them then maybe C++ isn't for you, you might be better off using another language. You can make some pretty intense gfx games with C# (if you're writing for the Windows eco-system.) As already stated there are a number of rules-of-thumb, some tried and true patterns, and some really great new support in C++0x that make pointer management pretty easy.

Another thing you can do; when I was starting out with C I sat own with my compiler (and GCC or CLang is really nice for this, you can just install cywin and the gcc toolchain if you're not willing to stray from windows) and worked through some example pointer patterns until I got a fairly deep understanding of how they work. It didn't take long either.

If you want to be a proficient programmer with graphics you should invest the time it takes to be comfortable with pointers. Either that or just write tic-tac-toe games with other languages. Smart phone developers seem to do pretty well.

Since programming in C and later moving to C++ professionally for 15 years (university and learning by myself before that), and understanding all the nuances of pointers, even I on rare occasions forget to delete/free() some pointer. And that always causes some problem, often hard to track down ones.

Using smart pointers can remove that small bug that all humans are prone to create.So, it isn't about being "afraid" of pointers, it's just common sense.

Heck, I'm a really good driver, why would I need an air bag in my car? I don't ever make a mistake while driving....

My Gamedev Journal: 2D Game Making, the Easy Way

---(Old Blog, still has good info): 2dGameMaking
-----
"No one ever posts on that message board; it's too crowded." - Yoga Berra (sorta)

Advertisement
So, it isn't about being "afraid" of pointers...

Isn't that something you should ask the OP about? Sounds to that's exactly what he was talking about.

Dynamic memory allocation is useful (and required) in the following instances:
  1. Your object is too large for the stack.
  2. Your object needs to persist outside the lifetime of the allocating scope (i.e. past the '}')
  3. You want to share your object across multiple threads (usually a bad idea).
  4. You have some kind of stupid control flow requiring it, like throwing gotos around everywhere (really just a specialization of #2).

#2 is pretty much unavoidable in any reasonably complex program, but what's important is to recognize when it's necessary.

Um, 3 is often unavoidable in any useful program, and very common. that's why locks and mutexes are for. You don't share access so much as control access serially to one or more threads.


The real proper use of these are all based on _lifetimes_. Who is responsible for creating the object? Who is responsible for destroying? Are users of the object just borrowing it for a while or do they need to take over responsibility of the lifetime? If they're just borrowing the object, how long do they need to borrow it for?
Quoted for emphasis.

I honestly find given proper design thinking about ownerships and lifetimes beats smart pointers at large.

Previously "Krohm"

There is nothing wrong with using dynamic memory. In fact, for any suitably non-trivial application you will find it impossible to NOT have dynamic memory allocation.

If you're doing this in C++ then you should be using modern C++ methodologies, such as smart pointers.

Additionally, when implementing your own classes that contain raw pointers you should always be sure to implement the rule of three at the minimum, rule of five at best.


While understanding and following the Rule of Three/Five is important, I would suggest striving for the Rule of Zero. (Which is basically a variation on the single responsibility principle)

EXACTLYYYYY finally one man on earth understands programming. damn. why is it so hard to make people forget about those damned rule of 3/5 ?

There is nothing wrong with using dynamic memory. In fact, for any suitably non-trivial application you will find it impossible to NOT have dynamic memory allocation.

If you're doing this in C++ then you should be using modern C++ methodologies, such as smart pointers.

Additionally, when implementing your own classes that contain raw pointers you should always be sure to implement the rule of three at the minimum, rule of five at best.


While understanding and following the Rule of Three/Five is important, I would suggest striving for the Rule of Zero. (Which is basically a variation on the single responsibility principle)

EXACTLYYYYY finally one man on earth understands programming. damn. why is it so hard to make people forget about those damned rule of 3/5 ?


Because it's still important to know, especially if (when) you write your own resource management classes.

EXACTLYYYYY finally one man on earth understands programming. damn. why is it so hard to make people forget about those damned rule of 3/5 ?


Not knowing the rule of 3/5 is like not knowing for loops. You have a giant gaping hole in your knowledge just waiting to come along and bite you on the ass.

There are a great many situations where the "rule of zero" will not work conveniently without you implementing the appropriate containers or proxies (which need to obey the rule of 3/5, by the way) in order to have your "rule of zero." Two examples where you need non-trivial handling of objects where the standard library is lacking convenient containers: handle duplication and COM with proper reference handling, unlike most DirectX code.

In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.

EXACTLYYYYY finally one man on earth understands programming. damn. why is it so hard to make people forget about those damned rule of 3/5 ?


Not knowing the rule of 3/5 is like not knowing for loops. You have a giant gaping hole in your knowledge just waiting to come along and bite you on the ass.

There are a great many situations where the "rule of zero" will not work conveniently without you implementing the appropriate containers or proxies (which need to obey the rule of 3/5, by the way) in order to have your "rule of zero." Two examples where you need non-trivial handling of objects where the standard library is lacking convenient containers: handle duplication and COM with proper reference handling, unlike most DirectX code.

This, plus the rule of zero depends on your compiler being able to automatically generate appropriate default equivalents for move ctor/assignment operator. That isn't available everywhere just yet (although the situation seems to be improving). Many people will be using older compilers, so you can't blindly forget about the rule of 3/5.

This topic is closed to new replies.

Advertisement