Linked by Thom Holwerda on Mon 13th Aug 2007 17:57 UTC
General Development "A good programming language is far more than a simple collection of features. My ideal is to provide a set of facilities that smoothly work together to support design and programming styles of a generality beyond my imagination. Here, I briefly outline rules of thumb (guidelines, principles) that are being applied in the design of C++0x. Then, I present the state of the standards process (we are aiming for C++09) and give examples of a few of the proposals such as concepts, generalized initialization, being considered in the ISO C++ standards committee. Since there are far more proposals than could be presented in an hour, I'll take questions." Dr. Bjarne Stroustrup is the original designer and implementer of the C++ Programming Language.
Thread beginning with comment 263646
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: C: Esperanto
by falemagn on Wed 15th Aug 2007 11:00 UTC in reply to "RE[4]: C: Esperanto"
falemagn
Member since:
2005-07-06

rayiner,

your example in C++ would be best implemented with an iterator or with the foreach macro described earlier. All your example proves is that when there's no link between syntax and semantics the compiler cannot optimize unnecessary code away, therefore the solution is to create that link, which is what an interator pattern does.

Reply Parent Score: 1

RE[6]: C: Esperanto
by rayiner on Wed 15th Aug 2007 14:51 in reply to "RE[5]: C: Esperanto"
rayiner Member since:
2005-07-06

My example was to show that it's easy for the optimizer to get rid of range checks. The code shown was how naive range-checks would be inserted, before optimization.

In any case, using an iterator in a tight loop is a bad idea. The iterator version would expand into something like:

double* ptr = vec;
double sum = 0.0;
while(ptr != vec.end) {
double t0 = *ptr;
if(ptr != vec.end) ++ptr; // will be eliminated
sum += (t0 * t0);
}

The range-check can be eliminated because the condition protecting it is made redundent by the loop-end test. This is exactly the same reason the range-check can be eliminated in the other example I showed.

However, this example is worse because it replaces array accesses with pointer arithmetic. The compiler will eventually lower the array accesses to pointer arithmetic anyway, but late in the optimizer. Before that, keeping things in array form makes classical loop/array optimizations (eg: dependence analysis) much easier.

Reply Parent Score: 2