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

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

On Thu, 2003-08-14 at 01:00, Gabriel Dos Reis wrote:
> skaller <skaller@ozemail.com.au> writes:
> 
> Here we go
> 
>   >  Besides, usefullness lies in the eye of
>   > the beholder.  Indeed from your above remarks I would conclude that this
>   > warning would also be useful to you, because you already made an error in
>   > your assumptions, namely that you can call non-virtual members.
> 
>   Nope, I'd never use a ctor-initialiser to initialise a variable 
>   or base other than with a parameter to the constructor, or, at worst,
>   a component of a structure.
> 
>   *If I have to do any calculations, they go in the body,*
>   and I have to ask myself how I ended up with that,
>   because it's symptomatic of a design fault.
> 
> I don't consider that quote out of context.

It was out of context to state that it was taught to
init things in ctor initialisers rather than the body ..
quoting ONLY that part of my text you have asterisks
around above -- as if I'd be recommending that, contrary
to what you claim is taught .. when in fact it is 
completely the opposite as you can
see from the full text.

You see quite clearly from the full text the general rule:
use ctor initialises with simple expressions, which agrees
with what you said is taught, but in fact goes further
by also requiring the initialisers to be simple.

It is in fact precisely this conflict -- that the initialiser value
in ctor-initialisers must be simple, and also that they're
prefered over the body, which leads to a conflict when
one has to decide which rule to break: simplicity or position.
I always break position: I'd rather put complex expressions
in the body -- and there are lots of reasons for this,
the most compelling being the ability to catch exceptions and
the ability to factor the code with local variables.
Of course some calculations require loops, so there is little
alternative to the constructor body, other than delocalisation
by way of a helper function.

In any case, when I have to do that, as I said I consider
that there is probably a design problem .. and I go looking
for it. [And it is almost always over-aggressive encapsulation]


> if they did that way on purpose, then it was deliberate.  But my point
> was that maybe the code was written that way because of no clue.

The problem I have understanding that point is I can't see
any other alternative :-) More precisely *someone* didn't
have a clue .. the person that coded the nasty code may
have had to compromise because of someone *else*s bad code :-)

> In fact, I tend to find errors like that one in C++ codes written by
> people with strong Java background and relatively less practice in C++.

yeah, that makes sense.