Re: Request for a C++ warning for undefined behaviour

[skaller <skaller at ozemail dot com dot au>]

On Wed, 2003-08-13 at 23:05, Gabriel Dos Reis wrote:
> skaller <skaller@ozemail.com.au> writes:
> 

> Well, initialization within the member-initalizer list is taught to be 
> good style; and initialization within the constructor body is also
> "known fraught with errors".

Yes, I agree. But my point refered to complex calculations.
So again please don't quote out of context: I said that if
I have to do a complex calculation, it goes in the body,
and is indicative of a design problem: i.e. there might
be one, though not necessarily. I'd be a bit worried though:
enough to write an explanatory comment perhaps.

> | So what? If the member isn't default constructed,
> | AND i need to do a calculation to initialise it,
> | there is a design error somewhere in there.
> 
> I don't think that necessary follows.  I would say that there is a
> design error -depending- on the kind of calculations that need to be
> carried out.  Not just because there is a calculation.

It is clear that you can always qualify everything: and the rules
I give are general guidelines to which there will occasionally
be an exception.

Still, I've never seen one :-)

The things is ..people have "ALL these problems" with C++ ..
and I never seem to have them. 

Of course, I do make heaps of mistakes! But they *always*
fall into a small class of errors. I don't make any
of the other kinds of mistakes because I don't use
flawed techniques that lead to them.

The fact that a very large number of errors can be avoided
by a few simple rules suggests something doesn't it?

Such as: don't use overloading except where you have to.
Forget about OO, it doesn't work.

> | Of course it does. Initialising it with a complex
> | expression, however, is just bad coding practice,
> | or, if it seems necessary, bad design.
> 
> That is different from previous assertions of yours.  And I can be
> made to agree with the new formulation.

Sometimes I seem to have to repeat something 10 different ways
before I'm understood. I wish I could communicate better :(

> | >From the example I conclude otherwise. I conclude Michael 
> | is asking for the flag to help detect garbage within garbage
> | which was *deliberately* put in, and my reaction is:
> 
> We have no evidence that the garbage was deliberately being put in.
> That can come from ignorance also.

That doesn't change anything. I'm not claiming someone tried
to deliberately sabotage the code! I'm saying that they
wrote the code the way they did on purpose.

> | it hardly seems worthwhile trying to help people sort out
> | their garbage when they're supposed to be programming.
> | 
> | They ought to learn how to program at school, it isn't
> | gcc's job to teach them: its a compiler, not an interactive
> | tutorial :-)
> 
> sure, but then we should remove all warnings :-/

As I tried to say before: I don't agree. There are class
of errors that are easy to make in C++ even when using
good practices. 

The obvious one that comes to mind is a type error.

> | This comment refers to the original coder and NOT to
> | Michael, who appears to have been stuck with having to fix it.
> 
> that comment is not very useful for Matt.

I was just trying to make it clear I wasn't being critical of
someone who found themselves having to maintain such code.
They have a real problem to solve.

I'm not against providing diagnostics! on the contrary,
I think there more the better, provided there is a flexible
way to control them -- which is why my other issue is raised:
you can't have a flexible set of warning control options 
unless you have a robust (error tolerant) handling of them, 
and the current handling is fragile (meaning, any mistake 
breaks the build).

the current design decision -- fragility -- is generally
the correct techique for most design and coding, IMHO.
However, errors are one place where handling should
be robust. That's a general statement too: it applies
to all error handling including management of C++
exceptions (don't write complicated error handlers,
they're useless if they have more errors in them than
the code they're reporting on).