-
Notifications
You must be signed in to change notification settings - Fork 0
Stuff to avoid
Will mainly be referencing C++ Primer 5th edition
Expression that mix signed and unsigned values can yield surprising results when the signed value is negative. It is essential to remember that signed values are automatically converted to unsigned.
unsigned int a = 123; //unsigned numbers are positive numbers, do u recall what u learn in DE?
int b = -144; //this is signed as can be either positive or negative
Uninitialized pointers are a common source of run-time errors.
As with any other uninitialized variable, what happens when we use an uninitialized pointer is undefined. Using an uninitialized pointer almost always results in run-time crash. However, debugging the resulting crashes can be surprisingly hard.
There is no way to distinguish a valid address from an invalid one formed from the bits that happen to be in the memory in which the pointer was allocated.
int *p3; //dangerous! don't even try to do this
Although C++ supports C-style strings, they should not be used by C++ programs. C-style strings are a surprisingly rich source of bugs and are the root cause of many security problems. They're also harder to use!
#include <cstring> //don't even include this!
Consider this: you are using two libraries called Foo and Bar:
using namespace foo;
using namespace bar;
Everything works fine, and you can call Blah()
from Foo and Quux()
from Bar without problems. But one day you upgrade to a new version of Foo 2.0, which now offers a function called Quux()
. Now you've got a conflict: Both Foo 2.0 and Bar import Quux()
into your global namespace. This is going to take some effort to fix, especially if the function parameters happen to match.
If you had used foo::Blah()
and bar::Quux()
, then the introduction of foo::Quux()
would have been a non-event.
Source: stackoverflow