In article <1994Mar18.032331.11690@sco.COM> simon@sco.COM (Simon Tooke) writes:
> ...
>
>Third, almost all C++ compilers feel free to generate the above warnings
>just about any time they please.  I have certainly seen them on objects
>(compiled via cfront) whose only purpose in life was to be constructed and
>destructed.  It really is a quality of implementation issue; there is nothing
>in the draft standard that mandates or forbids such warnings.

You're quite correct - I just tried this with g++, and hey presto it generated
a warning. Looks like what I have to do is complain to Microsoft (all my C++
programming to date has been with the MS compiler).

Thanks.


PaulB->msgCount++

---------------------------------------------
Paul Butcher, Harlequin Ltd, Barrington Hall,
Barrington, Cambridgeshire, CB2 5RG, UK

Phone: +44 223 872522  Fax: +44 223 872519

Hi!

Please excuse me if this message covers a topic which has already been
discussed recently - I don't usually read this group and therefore don't know
what's been going on...

Recently I came across what I consider to be a annoying limitation of C++
compared to C. Two of the most useful (IHMO) warnings that a C compiler can
give are:

    Unreferenced local variable 'foo'.

and

    Variable 'foo' is set but not used.

Both these warnings can often point to oversights on the part of the
programmer.

Unfortunately in C++ I don't believe it's possible for the compiler to
generate these warnings for most objects (those objects that have either a
constructor or destructor). This is because an object may be declared *purely*
for the side-effects of its constructor or destructor (e.g. when programming
in Windows I have an class "CHourglassCursor" where the constructor sets the
cursor to an hourglass and the destructor sets it back to whatever it was
before - this means that I never forget to reset the cursor).

Using objects in this manner is a powerful technique, but I'm not sure it's
worth the price if I have to lose the two above warnings.

This got me to wondering if there could be any way to declare that the
constructor and destructor of a class have no side-effects (i.e. no effects on
the state of anything except the object itself). This would be similar,
although not identical, to declaring a "const" member function. This would
allow the compiler to generate "set but not used" warning for objects of this
variety.

What do you think?


PaulB->msgCount++

---------------------------------------------
Paul Butcher, Harlequin Ltd, Barrington Hall,
Barrington, Cambridgeshire, CB2 5RG, UK

Phone: +44 223 872522  Fax: +44 223 872519

In <paulb.36.000E04D0@harlequin.co.uk> paulb@harlequin.co.uk (Paul Butcher) writes:
...
>Recently I came across what I consider to be a annoying limitation of C++
>compared to C. Two of the most useful (IHMO) warnings that a C compiler can
>give are:
>
>    Unreferenced local variable 'foo'.
>
>and
>
>    Variable 'foo' is set but not used.
>
>Both these warnings can often point to oversights on the part of the
>programmer.
>
>Unfortunately in C++ I don't believe it's possible for the compiler to
>generate these warnings for most objects (those objects that have either a
>constructor or destructor). This is because an object may be declared *purely*
>for the side-effects of its constructor or destructor (e.g. when programming
>in Windows I have an class "CHourglassCursor" where the constructor sets the
>cursor to an hourglass and the destructor sets it back to whatever it was
>before - this means that I never forget to reset the cursor).
>
>Using objects in this manner is a powerful technique, but I'm not sure it's
>worth the price if I have to lose the two above warnings.
>
>This got me to wondering if there could be any way to declare that the
>constructor and destructor of a class have no side-effects (i.e. no effects on
>the state of anything except the object itself). This would be similar,
>although not identical, to declaring a "const" member function. This would
>allow the compiler to generate "set but not used" warning for objects of this
>variety.

>What do you think?

First off, standards _don't_ mandate warnings; a program is either well-formed
or it isn't.  If if is well-formed but likely to be in error according to
some heuristic, a _good_ compiler is permitted to warn the programmer.
(and it follows that _bad_ compilers are permitted to core dump, but then
they aren't conformant, since they have to be able to process a well-formed-
but-sickly lump-of-code...)

Second, one Martian's idea of what constitutes a side effect differs wildly
from another; you'ld be surprised.  (for example, memory allocation can be
a side effect)

Third, almost all C++ compilers feel free to generate the above warnings
just about any time they please.  I have certainly seen them on objects
(compiled via cfront) whose only purpose in life was to be constructed and
destructed.  It really is a quality of implementation issue; there is nothing
in the draft standard that mandates or forbids such warnings.

-simon tooke

===============================================================================
Simon Tooke  (not speaking for) SCO Canada, Inc.         Voice:  (416) 922-1937
....!scocan!simon             simon@sco.com                Fax:  (416) 922-2704
130 Bloor St. West. Suite 1001, Toronto, Ontario, Canada  M5S 1N5





>PaulB->msgCount++

>---------------------------------------------
>Paul Butcher, Harlequin Ltd, Barrington Hall,
>Barrington, Cambridgeshire, CB2 5RG, UK

>Phone: +44 223 872522  Fax: +44 223 872519