Dave Dunfield wrote:
It would to
some compiler authors. (who sometimes have a different
reality than you and I do)
:-)
(I'm a compiler writer)
Good I need a Free Compiler ... OH wait you may want $$$.
I like the left to right idea A + B -> C
A long debated viewpoint - but I think a better
solution would be to
emit diagnostics when such conditions are found - the problem is, although
it's simple to detect with simple variables, the use of pointers or
function calls with side-effects can make it impossible to detect such
situations. In this respect, C is like assembly - You have to know what
you are doing and avoid these traps. Perhaps the real solution is one
of education.
But at least with the older C you could find your FEET to shoot.
For humor check here.
http://www.uwsg.iu.edu/usail/library/humor/shoot.foot.html
Absolutely - even standardized C allows for may
implementation dependant
aspects. This is a necessary evil due to the nature of a very widely
accomodating portable language.
Portable only if you assume BYTES are 8 bits (unsigned) now days.
Any language of significant power allows you to hang
yourself. The trick
is knowing how to handle the rope - my early computing history involved
more assembly language than anything else, and thinking from that
perspective, I have no problems understanding and avoiding these details.
It also helps that I know very precisely what code my compiler will generate
for various constructs. - and yeah, at times in "quick and dirties" I've
coded stuff invoking undefined behaviour knowing what to expect from my
own toolset (ducking).
So is the languages the problem or the hardware for clean coding?
And just what is reasonable memory size anyhow ...
Dave
--
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools:
www.dunfield.com
com Collector of vintage computing equipment:
http://www.classiccmp.org/dunfield/index.html
.