: Ivan Vecerina wrote:
: > I am just a user of the C++ language (albeit an "advanced" one).
: > Yet I studied the standard because I care for formal correctness
: > of my programs.
: > Unfortunately, if feel I am in a small minority (<5%?).
: > I take it as my responsibility to write code that actually works
: > according to the formal specification of the language.
:
: So you believe that your programs are actually correct because
: you are trying to make them correct?
Of course not, and using test cases etc is a crucial thing (too).
: Even if you don't consider
: *very* important obvious easy bugs like reading from NULL
: (substitute with an analogous thing in C++), can you prove that your
: programs are conforming to standard in those places that actually
: require reading standard, e.g. those are not covered in faqs and
: textbooks?
No, but if I do not care about what is formally correct, I may:
- dereference the one-past-the-end address of an array,
or do arithmetic outside its valid range of addresses.
- reinvent my own offsetof macro (or, in C++, use it on a non-POD
type), which (at least in C++) cannot portably be done.
- forget about events that will cause iterator invalidation
on the particular container that I am using (C++).
- forget that the result of the division or modulo of a negative
integer may depend on the target platform
- forget to implement a placement-delete operator function
matching my placement-new operator (to pick one of the many
dark corners of the C++ language).
- write code that is not exception safe, not thread safe.
- forget about buffer overflows and other security risks...
These are just few random picks...
: > It is sad, but most (C++) programmers seem to satisfy themselves
: > with knowing that their code passes casual tests, or at best,
: > available test cases. They don't even care about undefined
: > behavior and the invisible failures/leaks that may come with it.
: > They never go beyond reading recipe books (a la "Effective C++").
:
: What you said is indeed bad, but not having/reading (all the time,
: having it on your desktop, sleeping with it and so on) the standard
: doesn't mean bad programming.
Yet isn't it important to be aware that a formal specification exists?
There are often many ways to write code that will work and pass
test cases. Yet usually a good fraction of those "working
implementations" will have portability, reliability, or security
issues. To be able to choose among the many working approaches,
it is important to understand what is formally correct, and
what isn't.
This has eventually driven me to be *wanting* to consult the standard.
: Reading from NULL is undefined behavior, isn't it? Most C and C++
: programmers know they should not try to access memory pointed by
: NULL without any standard, still it happens all the time (not all the
: time in C++ I guess, but you have similar easy problems, don't you).
NULL-dereferencing is now captured as a runtime error on most
platforms, just as standard C++ library implementations are
providing debug modes that can capture many usage errors.
But in C like in C++, there are many other ways to silently
trigger undefined or platform-specific behavior.
: I don't mean *you* are a bad programmer or something, but putting
: "don't even care about undefined behavior and the invisible
: failures/leaks" here as if it was an attribute of
not-having-a-standard
: programmer is not fair.
This is not what I intended to express, and I am sorry if this
is how my post was understood. I admitted myself using an outdated
copy of the C++ standard, and a pre-final version of the C standard;
I would be worried by a developer who has only read the standard
specification, and none of the great books about C and C++.
But I do believe that a professionnal C or C++ developer who does
care about the correctness of his work is very likely to be drawn to
reading and studying portions of the language specification,
as well as a number of great books (such as those that have a "highly
recommended" rating in ACCU's book reviews for advanced C/C++).
: By the way, to my shame, I find C Faq far more useful than latest
: C standard. In C++ the situation must be different since you often
: need to determine whether something is your bug or compiler bug, while
: in C you can safely suspect yourself but not the compiler
It is very true that in C++, non-compliances of compilers and libraries
has amplified the importance of having access to the formal spec.
Finding C++ platform bugs still happens to me in 2006...
Kind regards,
Ivan