A
Andreas Dehmel
Sure I would. _Any_ standard should not reflect the state of the art of
the oldest and dumbest systems around and thus drag everything down
to their level but rather use what the majority of systems offer and
what the majority of developers need, at least on a basic level.
And I find it highly amusing that on the one hand you think it'd be a problem
that systems too dumb to implement a standard like I suggest would have to
use non-standard extensions, but at the same time it's apparently no
problem to you that everybody who needs "exotic" things like real-world
filesystem access (with non-8-bit charsets and directories) already has
to use non-standard extensions because you simply can not get the job
done within the lame-excuse-for-a-standard we have.
Wherever the standard goes, someone will have to use proprietary entensions
as a consequence. I merely think the ones forced to do so should be the
ancient/exotic systems and not everybody else. Legacy systems can be
K&R-C compliant for all I care, but even taking them into account for new
standards is a huge mistake. It only serves the vanity of legacy systems
and their representatives (``look, 60ies technology and still standard-
compliant'') while screwing everybody else.
It is not to accomodate the needs of the dumbest possible system, neither
should a college degree cater for the non-intelligence of the common
retard, and for the same reason: to do so would render it meaningless.
Those who can't cut it can't cut it. Tough, get over it, better luck
next time.
A global standard _is_ there to provide people basing their work on that
standard (in this case all C/C++-developers worldwide) with a solid
foundation to work on. If that standard is so vague you can't base
your work on it in the first place (like the areas of the C++-standard
we've covered in this thread for e.g. desktop/workstation applications),
that standard has failed.
Andreas