Danger!Don't use ...

[RexLee]

I am reading my book on c++ and I realize that there a lot of things to watch out for. (EX. Doing.. might cause a memory leak.) So what are some things that a programmer should do or should never do to avoid problems.(Anything that might cause issues.)

[P1X3]

Always avoid statement "new".

Always avoid pointers.

[Xploda]

Always statement "new".

Always avoid pointers.

Where did you hear the statement that you shouldn't use pointers? 

C++ and other languages like C are all about pointers. If you're not using pointers, you might as well use something like C# or Java...

[Frodo]

Where did you hear the statement that you shouldn't use pointers? 

C++ and other languages like C are all about pointers. If you're not using pointers, you might as well use something like C# or Java...

True, try to avoid using too much new statements, otherwise you will get in trouble with your memory (no garbage collection).

In the beginning it is also important to think about call-by-value and call-by-reference.

[RexLee]

How much memory is used for new statements?Does it affect the program so much?

[lutzee]

How much memory is used for new statements?Does it affect the program so much?

You obviously don't quite understand. New statements will reserve as much space as the typedef needs. Of course, if you don't tell the OS you no longer need it, it still thinks the memory is registered. Hence memory leak. Using new statements is not a bad thing if you correctly manage your memory. I believe part of the problem at the moment is people are too scared to even attempt memory management and thus opt for GC languages. Learning to memory manage yourself will help so much in the long run. And looks great to an employer.

[Dr3nz4r]

always try to not use "Goto".. might end up in dataloss or programm crashes

[Spartan-S63]

Always statement "new".

Always avoid pointers.

A statement like that is like making an excuse for why someone's a poor programmer (that's not directed at you). The very power of C/C++ comes from the use of pointers. Statements that tell people to avoid pointers is just creating an excuse for why memory leaks exist. Now, don't get me wrong, not everything should be a pointer, but when they're needed, you should use them. Don't avoid them, use them when they're most appropriate. There's nothing particularly dangerous about them unless you don't understand them and if you don't understand pointers, you probably shouldn't be using C/C++ until you do.

[wolfsinner]

The most important thing to look out for if you're writing C++ code is:

• If you allocate memory in the heap (using malloc, or any of the alloc functions), never lose sight of that memory address. When you don't need it, free it. Not freeing heap blocks is the single biggest source for memory leaks.
• If you're writing object code, write a destructor for every class you make. This destructor needs to take into account anything that it stores by reference (e.g., if your object has a pointer to another object, or to a memory block, be sure to free that if you won't be needing it again). Also make sure that you free every object you no longer need (the destructor is automatically called upon a delete call on an object).

 

One of the best things you can do to get used to memory management is writing heap-based data structures like linked lists and binary trees. Aside from giving you some basic knowledge on data structures (which are a must for any programmer), they require you to use memory dynamically. Then stress test it to check for memory leaks (I'm pretty sure Valgrind also tests for memory leaks, so you can use that).

 

Other things:

• In most cases, whenever you run into a segmentation fault, it means that you're accessing memory which you can't access, or you're trying to de-reference a NULL (0) pointer. (Again, you can use Valgrind to help you with this)
• If you're writing a function which returns a pointer, don't return the address of a local variable. Local variables are stored in what is called the execution stack, which grows and gets smaller with subsequent function calls and local variable declarations. So whenever a function stops its execution, you can be pretty sure that the correct value of its local variables won't stay there for long.
• This is a bit more advanced, but you'll get there at some point. Don't use recursion with any chance you get. Most recursive implementations are memory hogs when compared to their iterative counterparts. Only use recursion if there is a clear efficiency gain. When you get there, also read about memoization.

 

I'll update/write a new post if I remember anything else. :)

Good luck!

[manon_gfx]

If you are using c++, don't use NULL. Just use 0. In c++ NULL is defined as 0. Using NULL will just create confusion and issues between C and C++ programs.

[WanderingFool]

Well the biggest don't do, for me, would be macro functions which take in variables.

 

#define TEST(a) a / a

 

I have seen people fall into the trap of saying that given integers test will always return 1, or div/0 error.  With TEST(a + b) though it equals a + b / a + b, or a + b + b/a

 

Slightly safer

#define TEST(a) (a)/(a)

 

but still TEST(a++) = a++ / a++ so a get incremented twice.

 

So in general watch out when you use macro functions.  And when making macro functions (which I would recommend against, in most cases) make sure it is properly documented and will be understood the dangers of using it.

 

 

While this case doesn't really apply to c++ (or at least to my knowledge), for other languages you have to watch out for float and double comparisons.  This example is from java

if(d.equals(d2))    return true;if(d == d2)    return false;

There is actually cases where false is returned. (-0.0 and 0.0 are not equal, but comparison is equal).  For NaN equal function is true, but NaN == NaN is false