Welcome to the Lounge

Gerry Schmitz wrote:

So, I compared definitions and "calculating" indicates simplicity whereas "computing" indicates complexity.

Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.

#realJSOP wrote:

Now I can relax...

• Confusion between a variable and its value. If you think of a variable as being a value rather than having a value, pointers don't make sense.
• Having no down-to-earth view of what memory is. If you view it as a mystical black box where value are associated to variables by some unholy combination of the name of a variable and a particular function invocation or whatever (to be able to handle recursion), pointers don't make sense.

• Given Class* p, p += n is p + n * sizeof(Class), not p + n. For a long time, I worked in a language where this wasn't the case, so I've rediscovered it several times.
• The idiomatic if(p) instead of if(p != nullptr). I still refuse to write the former, probably because I never used C and because nullptr was equivalent to UINTPTR_MAX in the language that I used.
• Smart pointers, particularly unique_ptr. These are great, but adopting them isn't always transparent. It took me a while to find a bug that was caused by the implementation of unique_ptr::reset, which was equivalent to
  C++

  item = this->ptr_;
  this->ptr_ = nullptr;
  delete item;

  I had code that needed to know the object being deleted, so it got broken when it started using unique_ptr::get instead of looking at a raw pointer. The workaround (ctx_ being the unique_ptr) was
  C++

  auto ctx = ctx_.get();
  delete ctx;
  ctx_.release();

Quote:

There is a subtle near-ambiguity in the C syntax for two-dimensional array
references. Let us elucidate it, and then turn it to our advantage. Consider the
array reference to a (say) float value a[i][j], where i and j are expressions
that evaluate to type int. A C compiler will emit quite different machine code for
this reference, depending on how the identifier a has been declared. If a has been
declared as a fixed-size array, e.g., float a[5][9], then the machine code is: “to
the address a add 9 times i, then add j, return the value thus addressed.” Notice that
the constant 9 needs to be known in order to effect the calculation, and an integer
multiplication is required (see Figure 1.2.1).
Suppose, on the other hand, that a has been declared by float **a. Then
the machine code for a[i][j] is: “to the address of a add i, take the value thus
addressed as a new address, add j to it, return the value addressed by this new
address.” Notice that the underlying size of a[][] does not enter this calculation
at all, and that there is no multiplication; an additional indirection replaces it. We
thus have, in general, a faster and more versatile scheme than the previous one. The
price that we pay is the storage requirement for one array of pointers (to the rows
of a[][]), and the slight inconvenience of remembering to initialize those pointers
when we declare an array.
Here is our bottom line: We avoid the fixed-size two-dimensional arrays of C as
being unsuitable data structures for representing matrices in scientific computing. We
adopt instead the convention “pointer to array of pointers,” with the array elements
pointing to the first element in the rows of each matrix.