By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,898 Members | 2,012 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,898 IT Pros & Developers. It's quick & easy.

NULL used in arithmetic

P: n/a
I got a warning from gcc for the following code

if (nextIs_.size() == NULL)

warning: NULL used in arithmetic

how can I fix this problem? It seems that I can install a patch for
gcc, but I don't have permission to do that, I can only change my code.

Thanks all.

Jul 1 '06 #1
Share this Question
Share on Google+
20 Replies


P: n/a
asdf posted:
I got a warning from gcc for the following code

if (nextIs_.size() == NULL)

NULL is intended to be used exclusively as a null pointer constant.

You're using it as a simple integer zero.

how can I fix this problem? It seems that I can install a patch for
gcc, but I don't have permission to do that, I can only change my code.

if ( !nextIs_.size() )
Or even:
if ( 0 == nextIs_.size() )

--

Frederick Gotham
Jul 1 '06 #2

P: n/a
asdf wrote:
I got a warning from gcc for the following code

if (nextIs_.size() == NULL)

warning: NULL used in arithmetic

how can I fix this problem? It seems that I can install a patch for
gcc, but I don't have permission to do that, I can only change my code.


NULL is a macro evaluating to a legal null pointer constant. A null
pointer constant is an integral expression with value zero. While
tecnhically, you can use it as an integer zero for other purposes,
the general intent is to use NULL when you are testing for null pointer
and 0 otherwise.

Further, if nextIs_ is some standard container, size() == 0 is an
potentially inefficient idiom. empty() evaluates in constant time
where as size() may take longer (it may actually have to count the
objects).
Jul 1 '06 #3

P: n/a
asdf wrote:
I got a warning from gcc for the following code

if (nextIs_.size() == NULL)

warning: NULL used in arithmetic

how can I fix this problem? It seems that I can install a patch for
gcc, but I don't have permission to do that, I can only change my code.


Gcc uses a non-Standard extension that makes NULL a keyword. It behaves like
a proper NULL, which is just 0, but it emits warnings when used as an
integer.

Get around it by not abusing NULL. You should never write it where you
actually mean an integer 0, such as to compare with the return value of
..size().

Replace the NULL with a zero!

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Jul 1 '06 #4

P: n/a
asdf wrote:
I got a warning from gcc for the following code

if (nextIs_.size() == NULL)

warning: NULL used in arithmetic

how can I fix this problem?
Well, stop using NULL in arithmetic. The above comparison should normally be
expressed as

if (nextIs_.size() == 0)

What on earth made you to use NULL there in the first place?

--
Best regards,
Andrey Tarasevich
Jul 2 '06 #5

P: n/a
Phlip wrote:
asdf wrote:
>>I got a warning from gcc for the following code

if (nextIs_.size() == NULL)

warning: NULL used in arithmetic

how can I fix this problem? It seems that I can install a patch for
gcc, but I don't have permission to do that, I can only change my code.

Gcc uses a non-Standard extension that makes NULL a keyword.
NULL is still a macro, as the standard requires, but it resolves to __null,
which is a compiler-specific keyword. This isn't required by the standard,
but it doesn't violate it either.

Jul 2 '06 #6

P: n/a
Andrey Tarasevich posted:
The above comparison should normally be expressed as

if (nextIs_.size() == 0)

I find that to be redundant, and instead write:
if ( !nextIs_.size() )
But nonetheless, A LOT of people seem to like the comparison to zero.

--

Frederick Gotham
Jul 2 '06 #7

P: n/a
Frederick Gotham wrote:
if ( !nextIs_.size() )

But nonetheless, A LOT of people seem to like the comparison to zero.
if (0 == nextIs_.size())

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Jul 2 '06 #8

P: n/a
Frederick Gotham wrote:
Andrey Tarasevich posted:
>The above comparison should normally be expressed as

if (nextIs_.size() == 0)


I find that to be redundant, and instead write:
if ( !nextIs_.size() )
But nonetheless, A LOT of people seem to like the comparison to zero.
A lot of people (me included) believe that "comparison-less" form should only be
used with values that have pronounced boolean semantics. With non-boolean values
the explicit comparison operator is always required, even if it is a comparison
with 0.

And many of those who still use the "short" form with non-boolean values still
consider the above use of '!' to be completely unacceptable, since it doesn't
convey the actual meaning of the comparison very well. (Another popular example
of such terrible ridiculous use of '!' is its use with 'strcmp' in cases when
one watches for _equality_ of the strings).

--
Best regards,
Andrey Tarasevich
Jul 2 '06 #9

P: n/a
if (0 == nextIs_.size())

Note that .empty() is of course more generically efficient.

What I mean is that the expected value of a comparison should be on the
left, for various trivial reasons.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Jul 2 '06 #10

P: n/a
Andrey Tarasevich posted:

A lot of people (me included) believe that "comparison-less" form
should only be used with values that have pronounced boolean
semantics. With non-boolean values the explicit comparison operator is
always required, even if it is a comparison with 0.

Incorrect.
void DoSomething(void) {}
double Func(void)
{
return 56.34;
}
int main()
{
if ( !Func() ) DoSomething();
}
(Another popular example of such terrible
ridiculous use of '!' is its use with 'strcmp' in cases when one
watches for _equality_ of the strings).

Different strokes for different folks.

I myself would write:

if ( !strcmp( /* args */ ) ) DoSomething();
--

Frederick Gotham
Jul 2 '06 #11

P: n/a
Frederick Gotham wrote:
Andrey Tarasevich posted:
>A lot of people (me included) believe that "comparison-less" form
should only be used with values that have pronounced boolean
semantics. With non-boolean values the explicit comparison operator is
always required, even if it is a comparison with 0.
Incorrect.
double Func(void)
if ( !Func() ) DoSomething();
I see no "secretly compare doubles to zero" in Andrey's paragraph. It seems
to me that "comparison with" can involve, say, 0.0 double.
Different strokes for different folks.

I myself would write:

if ( !strcmp( /* args */ ) ) DoSomething();
One good style rule is to pronounce code out loud and hear if it makes
sense. So "if not string compare" is bad style, not just "different
strokes".

if (0 == strcmp(...))

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Jul 2 '06 #12

P: n/a
Rolf Magnus wrote:
Phlip wrote:
>asdf wrote:
>>I got a warning from gcc for the following code

if (nextIs_.size() == NULL)

warning: NULL used in arithmetic

how can I fix this problem? It seems that I can install a patch for
gcc, but I don't have permission to do that, I can only change my code.
Gcc uses a non-Standard extension that makes NULL a keyword.

NULL is still a macro, as the standard requires, but it resolves to __null,
which is a compiler-specific keyword. This isn't required by the standard,
but it doesn't violate it either.
As far as I know, the only value of null that is specifically banned
(18.1/4 footnote 180) is ((void*)0)
Jul 2 '06 #13

P: n/a
Frederick Gotham wrote:
>A lot of people (me included) believe that "comparison-less" form
should only be used with values that have pronounced boolean
semantics. With non-boolean values the explicit comparison operator is
always required, even if it is a comparison with 0.


Incorrect.
Huh? What's "incorrect"? And what is the purpose of that code sample?

I'm not claiming that this is prohibited by the language. I'm just saying that
by many people the comparison-less condition with non-boolean types is
considered _bad_ _coding_ _practice_, even though it is allowed by the language.
>
>(Another popular example of such terrible
ridiculous use of '!' is its use with 'strcmp' in cases when one
watches for _equality_ of the strings).


Different strokes for different folks.

I myself would write:

if ( !strcmp( /* args */ ) ) DoSomething();
...
And I would consider this completely unacceptable.

--
Best regards,
Andrey Tarasevich
Jul 3 '06 #14

P: n/a
Andrey Tarasevich posted:
Frederick Gotham wrote:
>>A lot of people (me included) believe that "comparison-less" form
should only be used with values that have pronounced boolean
semantics. With non-boolean values the explicit comparison operator
is always required, even if it is a comparison with 0.


Incorrect.

Huh? What's "incorrect"? And what is the purpose of that code sample?

You stated:

"With non-boolean values the explicit comparison operator is always
required, even if it is a comparison with 0."

Choosing a "double" as a non-boolean value, I demonstrated that the
explicit comparison operator was not required.

I'm not claiming that this is prohibited by the language. I'm just
saying that by many people the comparison-less condition with
non-boolean types is considered _bad_ _coding_ _practice_, even though
it is allowed by the language.

Labeling something as "bad coding practise" doesn't bear much gravity in
C++ -- consider the amount of expert programmers who still use "i++"
when the simpler alternative of "++i" would be viable -- Bjarne
Stroustrup himself does it.

>Different strokes for different folks.

I myself would write:

if ( !strcmp( /* args */ ) ) DoSomething();
...

And I would consider this completely unacceptable.

There are more ways to program in C++ than there are ways to skin a cat!
Consider:

if(!p) Vs if(p == NULL) Vs if(NULL==p) Vs if(p == 0) Vs if(0==p)
for(int i=0;i<len;i++) Vs for(unsigned i = 0; i != len; ++i)
You have your own way of doing things, and I have my own way of doing
things. Until the day that you're my boss, I'll program the way I like
to.
--

Frederick Gotham
Jul 3 '06 #15

P: n/a
Frederick Gotham wrote:
>>>A lot of people (me included) believe that "comparison-less" form
should only be used with values that have pronounced boolean
semantics. With non-boolean values the explicit comparison operator
is always required, even if it is a comparison with 0.

Incorrect.

Huh? What's "incorrect"? And what is the purpose of that code sample?

You stated:

"With non-boolean values the explicit comparison operator is always
required, even if it is a comparison with 0."

Choosing a "double" as a non-boolean value, I demonstrated that the
explicit comparison operator was not required.
You took that "required" out of context. By "required" I meant that it is
"always required" in certain coding standards/practices (either "official" or
self-imposed).
>I'm not claiming that this is prohibited by the language. I'm just
saying that by many people the comparison-less condition with
non-boolean types is considered _bad_ _coding_ _practice_, even though
it is allowed by the language.


Labeling something as "bad coding practise" doesn't bear much gravity in
C++ -- consider the amount of expert programmers who still use "i++"
when the simpler alternative of "++i" would be viable -- Bjarne
Stroustrup himself does it.
Firstly, I haven't seen too many "expert programmers" (whatever your criteria of
"expert programmer" is) who would do that. The same applies to the above
comparison practices.

Secondly, the argument based on "the amount of [expert] programmers" doesn't
bear much gravity either.
You have your own way of doing things, and I have my own way of doing
things. Until the day that you're my boss, I'll program the way I like
to.
Yes, and? That's, BTW, what I was saying from the very beginning. As for the
"boss" part, I don't understand how this has anything to do with what I said so far.

--
Best regards,
Andrey Tarasevich
Jul 3 '06 #16

P: n/a
red floyd wrote:
Rolf Magnus wrote:
>Phlip wrote:
>>asdf wrote:

I got a warning from gcc for the following code

if (nextIs_.size() == NULL)

warning: NULL used in arithmetic

how can I fix this problem? It seems that I can install a patch for
gcc, but I don't have permission to do that, I can only change my code.
Gcc uses a non-Standard extension that makes NULL a keyword.

NULL is still a macro, as the standard requires, but it resolves to
__null, which is a compiler-specific keyword. This isn't required by the
standard, but it doesn't violate it either.

As far as I know, the only value of null that is specifically banned
(18.1/4 footnote 180) is ((void*)0)
NULL must be a macro that resolves to a zero value of any integral type. The
g++ built-in __null is such an integral zero value.

Jul 3 '06 #17

P: n/a
Andrey Tarasevich wrote:
Frederick Gotham wrote:
>Andrey Tarasevich posted:
>>The above comparison should normally be expressed as

if (nextIs_.size() == 0)


I find that to be redundant, and instead write:
if ( !nextIs_.size() )
But nonetheless, A LOT of people seem to like the comparison to zero.

A lot of people (me included) believe that "comparison-less" form should
only be used with values that have pronounced boolean semantics. With
non-boolean values the explicit comparison operator is always required,
even if it is a comparison with 0.

And many of those who still use the "short" form with non-boolean values
still consider the above use of '!' to be completely unacceptable, since
it doesn't convey the actual meaning of the comparison very well.
I go with that. In the above case, I would also explicitly write down the
comparison with 0. However, when checking for null pointers, I think the
short form expresses the meaning quite well, like:

MyClass* p = somefunc();
if (!p)
{
// error
}

The !p here means to me "p does not point to an object", which expresses the
intent more clearly than p == NULL ("p is equal to a null pointer value").
(Another popular example of such terrible ridiculous use of '!' is its use
with 'strcmp' in cases when one watches for _equality_ of the strings).
How is the long form better here?

Jul 3 '06 #18

P: n/a
Andrey Tarasevich posted:

>Choosing a "double" as a non-boolean value, I demonstrated that the
explicit comparison operator was not required.

You took that "required" out of context. By "required" I meant that it
is "always required" in certain coding standards/practices (either
"official" or self-imposed).

Required by coding standards/practices.

Not required by the language.

Understood.
>Labeling something as "bad coding practise" doesn't bear much gravity
in C++ -- consider the amount of expert programmers who still use
"i++" when the simpler alternative of "++i" would be viable -- Bjarne
Stroustrup himself does it.

Firstly, I haven't seen too many "expert programmers" (whatever your
criteria of "expert programmer" is) who would do that. The same
applies to the above comparison practices.

The C++ Programming Language 3rd Edition by Bjarne Stroustrup contains
many instances of "i++".
>You have your own way of doing things, and I have my own way of doing
things. Until the day that you're my boss, I'll program the way I
like to.

Yes, and? That's, BTW, what I was saying from the very beginning. As
for the "boss" part, I don't understand how this has anything to do
with what I said so far.

What I was getting it is that you were decreeing my code to be
"unacceptable", and my response is that I'll program the way I like to
program, unless of course an employer explicitly instructs me to do
otherwise.

Thankfully though, I have no intention of every working as a computer
programmer.
--

Frederick Gotham
Jul 3 '06 #19

P: n/a
Frederick Gotham wrote:
The C++ Programming Language 3rd Edition by Bjarne Stroustrup contains
many instances of "i++".
If Bjarne just ... jumped off a cliff, would you?
Thankfully though, I have no intention of every working as a computer
programmer.
Apparently not. ;-)

Please don't debate style with those of us who must support colleagues,
okay?

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Jul 3 '06 #20

P: n/a
Phlip posted:
Frederick Gotham wrote:
>The C++ Programming Language 3rd Edition by Bjarne Stroustrup contains
many instances of "i++".

If Bjarne just ... jumped off a cliff, would you?

I use Bjarne as an example of an expert programmer, nothing more.

>Thankfully though, I have no intention of every working as a computer
programmer.

Apparently not. ;-)

Please don't debate style with those of us who must support colleagues,
okay?

Forgive, I'll keep my eliteness to myself.

--

Frederick Gotham
Jul 3 '06 #21

This discussion thread is closed

Replies have been disabled for this discussion.