Add polymorphism. I can't see any reason this isn't doable outside of function naming. That's fixable.
"Simple" "templates" based on structure aggregation to make workable generics (list/tree/map etc)
Clean vector math support (like OGLES)
Friday, 6 May 2016
Thursday, 5 May 2016
Fixing C 3
The embedded guys would, really, like you to standardise the bit shift operations and add rotations will you are there, no... seriously!
Wednesday, 4 May 2016
Fixing C 2
Following on from the previous post.
Something I've always fancied to help handle error cases is for/else and while/else
for (int x = start_value; x > 0; --x) {
do_some_work(x,y);
} else {
dont_do_some_work();
}
... and the same for while loops.
You see, the loop construct has to test the initial condition before retesting when the loop loops around. It would not be hard to add an "else" clause e.g. if the loop is never executed then please do this.
It would save the coder writing an additional "if" test and can trivially be used to catch errors e.g. what do you do (or not do) in the above case if start_value is 0.
Something I've always fancied to help handle error cases is for/else and while/else
for (int x = start_value; x > 0; --x) {
do_some_work(x,y);
} else {
dont_do_some_work();
}
... and the same for while loops.
You see, the loop construct has to test the initial condition before retesting when the loop loops around. It would not be hard to add an "else" clause e.g. if the loop is never executed then please do this.
It would save the coder writing an additional "if" test and can trivially be used to catch errors e.g. what do you do (or not do) in the above case if start_value is 0.
"Fixing C"
There's an interesting debates going on at embedded.com and eetimes.com about Fixing C
There's a lot of debate about removing brackets, semi-colons, using pythonesque tabbing etc but a lot of this is probably "syntactic sugar" that will lead to further unexpected problems.
On that note (syntactic) one of the few changes I would make would be the removal of the "single line statement"
if (something > something_else)
a_single_line_statement(something_else);
WHY?!
Because it leads to hell! It is FAR too easy to see someone plug a line of code in and have everything go wrong. Especially when debugging and a printk/printf/debug() line is added.
It is not so hard to use {} to delimit that and the rule about "what is a code block" becomes crystal clear.
I'd apply the same rule to empty code blocks
for(unsigned x = 0; some_array[x]--; x += some_array[x]) ;
Why not just write {} instead of ;
Now, let's not get into why the structure notation uses the same braces as code blocks. But the answer is... there's only so many braces and C uses them all (and C++ augments them with <>!)
But - what else is there?
Proper bounds checking, user defined literals (notably for strings with length instead of null termination), rotate operators and more besides.
There's a lot of debate about removing brackets, semi-colons, using pythonesque tabbing etc but a lot of this is probably "syntactic sugar" that will lead to further unexpected problems.
On that note (syntactic) one of the few changes I would make would be the removal of the "single line statement"
if (something > something_else)
a_single_line_statement(something_else);
WHY?!
Because it leads to hell! It is FAR too easy to see someone plug a line of code in and have everything go wrong. Especially when debugging and a printk/printf/debug() line is added.
It is not so hard to use {} to delimit that and the rule about "what is a code block" becomes crystal clear.
I'd apply the same rule to empty code blocks
for(unsigned x = 0; some_array[x]--; x += some_array[x]) ;
Why not just write {} instead of ;
Now, let's not get into why the structure notation uses the same braces as code blocks. But the answer is... there's only so many braces and C uses them all (and C++ augments them with <>!)
But - what else is there?
Proper bounds checking, user defined literals (notably for strings with length instead of null termination), rotate operators and more besides.
Subscribe to:
Posts (Atom)