New to c++, need help with advanced topics

[Marcus Kwok]

I was supposed to say there is a bias towards describing types, rather
than variables.

I'm not sure who said it, and it is of course personal preference. Both
are equally valid.

From what I've seen, Bjarne Stroustrup prefers the former (FWIW).

Agreed, see http://www.research.att.com/~bs/bs_faq2.html#whitespace

The choice between "int* p;" and "int *p;" is not about right and
wrong, but about style and emphasis. C emphasized expressions;
declarations were often considered little more than a necessary evil.
C++, on the other hand, has a heavy emphasis on types.

A "typical C programmer" writes "int *p;" and explains it "*p is what
is the int" emphasizing syntax, and may point to the C (and C++)
declaration grammar to argue for the correctness of the style.
Indeed, the * binds to the name p in the grammar.

A "typical C++ programmer" writes "int* p;" and explains it "p is a
pointer to an int" emphasizing type. Indeed the type of p is int*.
I clearly prefer that emphasis and see it as important for using the
more advanced parts of C++ well.

...

Whenever something can be done in two ways, someone will be confused.
Whenever something is a matter of taste, discussions can drag on
forever.

 

[Niklas Norrthon]

I should have added

If, because of language rules, you are forced to declare a variable
before its first use, declare it as late as possible and initialise it
to some defined value anyway.


int i = 0;

Here we are in disagreement. I see no reason why one would init a
variable, if it assigned on the very next line of code.

If I really wanted to init the variable I'd rather do:

int = 0;

for (; i < some_max_val; ++i) { // and so on...

There is no harm in doing it your way, but I think my way is
perfectly acceptable too, and even prefered, since it makes
the code clearer. It's somewhat related assigning NULL to a
pointer after a call to free, which is totally unnecessary
if the variable goes out of scope on the next line of code...

/Niklas Norrthon

 

[deane_gavin]

Here we are in disagreement. I see no reason why one would init a
variable, if it assigned on the very next line of code.

The reason is to avoid ever having uninitialised variables around. That
way, when I restructure the code, I can guarantee that, no matter what
stupid mistake I make, the bug I introduce will not be a hard to track
down, appears to only break in release mode, undefined behaviour bug
caused by trying to use an uninitialised variable. Always initialising
the variable is a simple technique to avoid ever having that problem.

If I really wanted to init the variable I'd rather do:

int = 0;

for (; i < some_max_val; ++i) { // and so on...

There is no harm in doing it your way, but I think my way is
perfectly acceptable too, and even prefered, since it makes
the code clearer.

I certainly never suggested doing that!

Explicitly assigning the initial value to the loop variable is
certainly preferable to relying on previous code. But that point is
orthogonal to whether you should ever allow uninitialised variables in
your code.

It's somewhat related assigning NULL to a
pointer after a call to free, which is totally unnecessary
if the variable goes out of scope on the next line of code...

Well, I suppose I wouldn't care too much about initialising i in code
like this

void f()
{
// ... do lots of stuff
int i; // immediately going out of scope
}

but I've never written code like that.

Using RAII principles, all resource release happens in destructors, so
I find that pointers do indeed go out of scope immediately after delete
is called on them. But if I was going to keep a pointer hanging around
for reuse, I would consider setting it to null for the same reason.

Gavin Deane