Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Position of test values in conditional expressions

Reply
Thread Tools

Position of test values in conditional expressions

 
 
Programmer Dude
Guest
Posts: n/a
 
      06-22-2004
writes:

> How can the tests not reveal the problem?


Inept compiler or no use of a lint tool?

> (I saw a problem like this in a graphics
> routine - sped up quite a bit once the problem was fixed. Had the
> original programmer applied a trick or two it would have been
> flagged and fixed months earlier.) -Wm


Just as another data point, I've never experienced the error in
over two decades of experience. Of course, my compilers always
whined about it and I never use assignment in a test expression.
(So any compiler warnings about this sort of thing ARE errors.)

--
Somewhere in the Midwest...
Chris Sonnack <(E-Mail Removed)> in Training...
http://www.Sonnack.com/
 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      06-23-2004
Darrell Grainger wrote:
>

.... snip ...
>
> By the way, my company uses a lint application that always
> catches when programmers use an assignment in a conditional
> expression. No need for the programmers to learn a trick to
> make the compiler catch it MOST of the time when I can get
> an application that catches it ALL of the time.


But I often *want* to embed an assignement in a conditional, and
your gang of hackers should also:

void foo(int count, char *fn)
{
FILE *fp = NULL;
bar *buf;

if (!(buf = malloc(count * sizeof *buf))) err("No mem");
else if (!(fp = fopen(fn, "r")) err("can't open");
else {
/* do my thing with fp and buf */
}
if (fp) fclose(fp);
free(buf);
}

and I can concentrate on doing my thing. The wrappers are solid,
clean, and automatic. I haven't checked fclose.

--
Chuck F ((E-Mail Removed)) ((E-Mail Removed))
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!


 
Reply With Quote
 
 
 
 
Gerry Quinn
Guest
Posts: n/a
 
      06-24-2004
In article <(E-Mail Removed)>,
http://www.velocityreviews.com/forums/(E-Mail Removed) says...
> Andre Kostur wrote:
> <snip>
> > IMHO: I prefer to use the (foobar() == -1) form because I know my compiler
> > will issue a warning if I try to "if (foobar() = 1)". (Um, one of my two
> > compilers.... so, yeah, I know it's not a diagnostic that the compiler is
> > _required_ to issue, I just know that my tool _does_).

>
> If foobar() returns a reference to a non-const object then your compiler
> likely /won't/ return a diagnostic unless you tell it to be /really/
> anal. For example:


They WILL complain - that is the point.

"if ( x = y )" is perfectly legitimate syntax, but it's a pattern that
most programmers rarely if ever use.

Some people probably love it for its compactness, and they should turn
the warning off. I would consider it to fall into the category of
obfuscated code, and its use would require very special circumstances
(can't think of any offhand).

- Gerry Quinn

 
Reply With Quote
 
Richard Herring
Guest
Posts: n/a
 
      06-24-2004
In message <(E-Mail Removed)>, CBFalconer
<(E-Mail Removed)> writes
>Darrell Grainger wrote:
>>

>... snip ...
>>
>> By the way, my company uses a lint application that always
>> catches when programmers use an assignment in a conditional
>> expression. No need for the programmers to learn a trick to
>> make the compiler catch it MOST of the time when I can get
>> an application that catches it ALL of the time.

>
>But I often *want* to embed an assignement in a conditional, and
>your gang of hackers should also:
>
>void foo(int count, char *fn)
>{
> FILE *fp = NULL;
> bar *buf;
>
> if (!(buf = malloc(count * sizeof *buf))) err("No mem");


> else if (!(fp = fopen(fn, "r")) err("can't open");
> else {
> /* do my thing with fp and buf */
> }
> if (fp) fclose(fp);
> free(buf);
>}


This thread is crossposted to c.l.c++ :

void foo(int count, char const * fn)
{
std::vector<bar> buf(count);
std::ifstream is(fn);
if (!is) throw std::runtime_error("can't open");
/* do my thing with is and buf */
// no cleanup required!
}
>
>and I can concentrate on doing my thing. The wrappers are solid,
>clean, and automatic. I haven't checked fclose.
>


--
Richard Herring
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      06-24-2004
Gerry Quinn wrote:
>

.... snip ...
>
> "if ( x = y )" is perfectly legitimate syntax, but it's a pattern
> that most programmers rarely if ever use.
>
> Some people probably love it for its compactness, and they should
> turn the warning off. I would consider it to fall into the
> category of obfuscated code, and its use would require very
> special circumstances (can't think of any offhand).


I gave at least one in <(E-Mail Removed)> a couple of
days ago.

--
Chuck F ((E-Mail Removed)) ((E-Mail Removed))
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!


 
Reply With Quote
 
Karl Heinz Buchegger
Guest
Posts: n/a
 
      06-24-2004
Gerry Quinn wrote:
>
> In article <(E-Mail Removed)>,
> (E-Mail Removed) says...
> > Andre Kostur wrote:
> > <snip>
> > > IMHO: I prefer to use the (foobar() == -1) form because I know my compiler
> > > will issue a warning if I try to "if (foobar() = 1)". (Um, one of my two
> > > compilers.... so, yeah, I know it's not a diagnostic that the compiler is
> > > _required_ to issue, I just know that my tool _does_).

> >
> > If foobar() returns a reference to a non-const object then your compiler
> > likely /won't/ return a diagnostic unless you tell it to be /really/
> > anal. For example:

>
> They WILL complain - that is the point.
>
> "if ( x = y )" is perfectly legitimate syntax, but it's a pattern that
> most programmers rarely if ever use.
>
> Some people probably love it for its compactness, and they should turn
> the warning off. I would consider it to fall into the category of
> obfuscated code, and its use would require very special circumstances
> (can't think of any offhand).


It's easy to 'turn that warning off'.
Just use the result of the assignment in a conditional.
All compilers I used up to know that warn about the assignment shut up
immediatly.

if( x = y )
turns to
if( ( x = y ) != 0 )
or
if( !(x = y ) )

Personally I consider this as a service to the programmer following
me to indicate: "Don't worry. I really ment assignment"

--
Karl Heinz Buchegger
(E-Mail Removed)
 
Reply With Quote
 
Gerry Quinn
Guest
Posts: n/a
 
      06-24-2004
In article <(E-Mail Removed)>, (E-Mail Removed) says...
> Gerry Quinn wrote:
> >

> ... snip ...
> >
> > "if ( x = y )" is perfectly legitimate syntax, but it's a pattern
> > that most programmers rarely if ever use.
> >
> > Some people probably love it for its compactness, and they should
> > turn the warning off. I would consider it to fall into the
> > category of obfuscated code, and its use would require very
> > special circumstances (can't think of any offhand).

>
> I gave at least one in <(E-Mail Removed)> a couple of
> days ago.


I would consider your example to be obfuscated code.

Your example:
<QUOTE>
void foo(int count, char *fn)
{
FILE *fp = NULL;
bar *buf;

if (!(buf = malloc(count * sizeof *buf))) err("No mem");
else if (!(fp = fopen(fn, "r")) err("can't open");
else {
/* do my thing with fp and buf */
}
if (fp) fclose(fp);
free(buf);
}
<END-QUOTE>

I don't use C anyway but if I were writing that it would look something
like the following:

void foo(int count, char* fn )
{
FILE* fp = NULL;
bar* buf;

buf = malloc( count * sizeof( *buf ) );
if ( buf == 0 )
{
err( "No mem" );
}
else
{
fp = fopen( fn, "r" );
if ( ! fp )
{
err( "can't open" );
}
else
{
/* do stuff */
fclose( fp );
}
}
free( buf );
}

I might lose the if-elses by creating a do-loop or tracking successes
with a flag, but that's another issue.

Why do you think the above is a problem? Is it just that it's too long
for cut-and-paste? Of course one virtue of C++ is that you can usually
create a class to embody such things compactly.


- Gerry Quinn

 
Reply With Quote
 
Programmer Dude
Guest
Posts: n/a
 
      06-24-2004
Gerry Quinn writes:

> I would consider your example to be obfuscated code.


I would agree if we insert the word, "mildly". (-:

>Your example:
>> if (!(buf = malloc(count * sizeof *buf))) err("No mem");

>
>...if I were writing that it [...]:
>
> buf = malloc( count * sizeof( *buf ) );
> if ( buf == 0 )


Ditto!

--
Somewhere in the Midwest...
Chris Sonnack <(E-Mail Removed)> in Training...
http://www.Sonnack.com/
 
Reply With Quote
 
Nick Landsberg
Guest
Posts: n/a
 
      06-24-2004
Gerry Quinn wrote:

[my comments at the bottom]

> In article <(E-Mail Removed)>, (E-Mail Removed) says...
>
>>Gerry Quinn wrote:
>>
>>... snip ...
>>
>>>"if ( x = y )" is perfectly legitimate syntax, but it's a pattern
>>>that most programmers rarely if ever use.
>>>
>>>Some people probably love it for its compactness, and they should
>>>turn the warning off. I would consider it to fall into the
>>>category of obfuscated code, and its use would require very
>>>special circumstances (can't think of any offhand).

>>
>>I gave at least one in <(E-Mail Removed)> a couple of
>>days ago.

>
>
> I would consider your example to be obfuscated code.
>
> Your example:
> <QUOTE>
> void foo(int count, char *fn)
> {
> FILE *fp = NULL;
> bar *buf;
>
> if (!(buf = malloc(count * sizeof *buf))) err("No mem");
> else if (!(fp = fopen(fn, "r")) err("can't open");
> else {
> /* do my thing with fp and buf */
> }
> if (fp) fclose(fp);
> free(buf);
> }
> <END-QUOTE>
>
> I don't use C anyway but if I were writing that it would look something
> like the following:
>
> void foo(int count, char* fn )
> {
> FILE* fp = NULL;
> bar* buf;
>
> buf = malloc( count * sizeof( *buf ) );
> if ( buf == 0 )
> {
> err( "No mem" );
> }
> else
> {
> fp = fopen( fn, "r" );
> if ( ! fp )
> {
> err( "can't open" );
> }
> else
> {
> /* do stuff */
> fclose( fp );
> }
> }
> free( buf );
> }
>
> I might lose the if-elses by creating a do-loop or tracking successes
> with a flag, but that's another issue.
>
> Why do you think the above is a problem? Is it just that it's too long
> for cut-and-paste? Of course one virtue of C++ is that you can usually
> create a class to embody such things compactly.
>
>
> - Gerry Quinn
>


Actually, you're both right as far as I am concerned.

When first learning a language like C, I would prefer
that newbies did it much like Gerry's example.

At this stage of the game, it is much more important to
get it right than to get it compact.

As one progresses up the ladder and becomes more expert,
then one may use what I will call the "shorthand" notation
(for want of a better term) that CBFalconer does.

Experienced programmers can read/write both without difficulty.
*Inexperienced* programmers who try to use the "shorthand"
notation (just because it's "kewl"?), usually wind up with
logic errors.

Just my opinion.

NPL


--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
 
Reply With Quote
 
Andre Kostur
Guest
Posts: n/a
 
      06-24-2004
> I don't use C anyway but if I were writing that it would look something
> like the following:
>
> void foo(int count, char* fn )
> {
> FILE* fp = NULL;
> bar* buf;
>
> buf = malloc( count * sizeof( *buf ) );
> if ( buf == 0 )
> {
> err( "No mem" );
> }
> else
> {
> fp = fopen( fn, "r" );
> if ( ! fp )
> {
> err( "can't open" );
> }
> else
> {
> /* do stuff */
> fclose( fp );
> }
> }
> free( buf );
> }
>
> I might lose the if-elses by creating a do-loop or tracking successes
> with a flag, but that's another issue.
>
> Why do you think the above is a problem? Is it just that it's too long
> for cut-and-paste? Of course one virtue of C++ is that you can usually
> create a class to embody such things compactly.


As a code reviewer, I'd accuse you of inconsistent style. Why do you
explicitly check buf against 0, but implicitly check fp? (Personally I
prefer to _always_ explicitly check, and I prefer using the NULL macro to
help reinforce that I'm dealing with a pointer and not an int).
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Conditional Expressions in Python 2.4 A.M Python 5 06-02-2006 11:38 PM
[Info] PEP 308 accepted - new conditional expressions Reinhold Birkenfeld Python 62 10-16-2005 06:27 PM
? ELSE Conditional Comment / Using Conditional Comments Inside Other Tags To Comment Out Attributes Alec S. HTML 10 04-16-2005 02:21 AM
Alternative suggestion for conditional expressions (see PEP 308) neblackcat Python 8 07-20-2004 03:24 PM
test test test test test test test Computer Support 2 07-02-2003 06:02 PM



Advertisments