Re: Deleting and checking pointers
Ulrich Eckhardt wrote:
kanze wrote:
Seungbeom Kim wrote:
I'm surprised, for I've thought such expressions are quite
common; only in the case of such implicit conversions does
C++ allow constructs like "if (C* p = ...)".
All of the coding guidelines I've seen for C++ expressedly
forbid them.
Many of the coding guidelines I know implicitly recommend
these: They say that one should a) declare a variable as close
to where it is used as possible and that b) one should
restrict the lifetime of a variable to the code where it is
used.
If there's a real difference in the lifetime of p between:
C* p = ...
if ( p != NULL ) ...
and
if ( C* p = ... ) ...
then the function which contains the statements is to
complicated, and needs to be factored out. Every coding
guidelines I've seen has forbidden using the implicit
conversions to bool. They also say, yes, to limit the lifetime
of variables as much as possible, and above all, don't declare
variables before they can be correctly initialized. But the
first is a relative thing, which can't outweigh an absolute
prohibition, and the second, more important part, is met in both
cases.
There are, of course, a few major exceptions, generally based on
idioms so common they stick out, and won't be overlooked --
things like:
while ( std::getline( ... ) ) ...
(In practice, the presence of a << in the conditional works
almost like a red flag -- you expect multiple side effects.)
Perhaps the cases involving dynamic_cast to initialize a pointer
will become one of these exceptions -- to date, dynamic_cast
isn't used enough in my code for anything involving it to be
considered an "established idiom".
The C++ I learned didn't allow definitions in a conditional,
either. I'm still somewhat open on that one -- I think that
there may be some special cases where the disadvantages of
putting the definition outside the conditional outweigh the
loss of readability, even if I've yet to encounter one.
// This doesn't work with standard containers, unfortunately.
if( Element* fou = container.find(barre))
frobnicate(fou);
But what's the difference between that and:
Element* fou = container.find( barre ) ;
if ( fou != NULL ) ...
Except that the latter is considerably more readable.
The same more or less applies to declaring the loopcounter in
the loop header, when using a for loop.
The keyword for says that there are three things taking place;
in all but the most trivial cases, the for will be written on
three lines. And the first thing which takes place normally
does change program state in some way -- there's no problem
using an assignment, and anytime an assignment can appear, so
can a declaration.
I don't think many people advise not doing that and if they do
so, I guess in most cases it is to cater for broken compilers
(for which there is still '#define for if(false){}else for').
I've never used a C++ compiler where declaring the variable in
the for statement didn't work. Throughout most of my C++
experience, of course, the scope of the variable didn't end with
the for loop, but I've yet to see where this really changed
anything.
On the other hand, you also said you preferred pointer to
boolean conversions spelled out, which would then require an
additional set of brackets and make the above really
unreadable.
A statement normally does one thing, and only one thing. If you
are testing a condition, you shouldn't be modifying state.
There are exceptions, where the alternatives are worse, but they
are just that, exceptions.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]