0

Strange C++ Code

I found this piece of code:

#include
using namespace std;
int main() {
const int a = 10;
int *b = (int *)&a;
*b = 20;
cout << a << ā€˜\nā€™ << *b << endl; return 0; } [/sourcecode] The output of the above code is 10, 20. Because the compiler, upon finding a constant, does compile time optimizations. Casting away constness is undefined and anything can happen (like sth mentioned above).

1

Dijsktra in “The Humble Programmer”

Dijkstra in his Turing lecture The Humble Programmer, says/writes some classic things. First, he tells us that the two most popular opinions about programming are not worth the salt:

  • That to program, one has to be puzzle minded.
  • That programming is essentially all about optimizing the computational process.

He says that, in the earlier days, the automatic computer (a term that is not recognized now) was mild in its power and so programming was a small problem. But now they have become gigantic in power and so programming has also become a gigantic problem:

In this sense the electronic industry has not solved a single problem, it has only created them, it has created the problem of using its products. To put it in another way: as the power of available machines grew by a factor of more than a thousand, society’s ambition to apply these machines grew in proportion, and it was the poor programmer who found his job in this exploded field of tension between ends and means.

He says some profound words:

…I have the feeling that one of the most important aspects of any computing tool is its influence on the thinking habits of those that try to use it…

He comments about the software development process in the economic context that:

…as long as machines were the largest item on the budget, the programming profession could get away with its clumsy techniques, but that umbrella will fold very rapidly.

And regarding proving a program’s correctness, he says:

..We all know that the only mental tool by means of which a very finite piece of reasoning can cover a myriad cases is called abstraction; as a result the effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programmer. In this connection it might be worth-while to point out that the purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise. Of course I have tried to find a fundamental cause that would prevent our abstraction mechanisms from being sufficiently effective. But no matter how hard I tried, I did not find such a cause. As a result I tend to the assumption -up till now not disproved by experience- that by suitable application of our powers of abstraction, the intellectual effort needed to conceive or to understand a program need not grow more than proportional to program length.

Finally he concludes:

It has already taught us a few lessons and the one I have chosen to stress in this talk is the following. We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers.