#C++ types
In the absence of a standard, there are no bugs, only implementations. The
bugs are in the eyes of the creator, not the user. What the user sees is
how it works. Even with a moving target, you must teach beginners about the
real world. Ivory tower stuff might be OK in a college classroom but not on
the job. When the real world changes, you change what you teach.
>I prefer to say what is right….
Who is to say what is right when there is no standard? Us? That would only
be our presumptuous interpretation of the unsanctioned existing
documentation. Say your idea of "what is right" if you care, but stand back
when the student/reader's code doesn't work.
It is often better to orient a lesson to a targeted implementation and say
so. You eliminate the myriad and complicated qualifications of the
many-compiler, many-version, all-things-to-all-people-at-all-times
approach. I learned that lesson by writing two books that had compile-time
conditionals so the code would compile with every obscure pre-ANSI C
compiler I could get my hands on. The header files were unreadable, there
were too many makefiles, and by the time the books got into print, a lot of
the methods had changed. Some of the compilers had faded into the
baseboard, too. De Smet? Eco-C? Let's C? Wizard C? CI C-86? Some of them
might still be out there, but they aren't contenders. We are fortunate that
C++ hasn't gotten into that kind of mess yet, but it could. Particularly
with class libraries.
Al Stevens