Sign in to follow this  

Whats True -1?

This topic is 828 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

A bug in my code which i found was due to missed brackets has led to some other questions: what is "True -1"?

 

for clarity I will oversimplify the code

 

My code shoud have been like this:                                                  if(  q == (hh - 1.0f)   ){ ... }

 

But i missed some brackets so i had typed  this                                if(  q ==  hh - 1.0f   ){ ... }
 
So i guess the compiler (i'm using Android Java on eclipse)...
                             ...would treat the missed brackets code as          if(  (q == hh) - 1.0f ){ ... }      except if i'm mistaken about the precedence 
 

                                                                      in other words           if(  (true) - 1.0f  ) { .... }        or   if(  (false) - 1.0f  ){ .... } 

 

  to find out what the consequence of my mistake was  i was asking whats TRUE - 1? But i don't know ,  does anyone know?

Share this post


Link to post
Share on other sites
So i guess the compiler (i'm using Android Java on eclipse)...
...would treat the missed brackets code as if( (q == hh) - 1.0f ){ ... }

No. See: https://docs.oracle.com/javase/tutorial/java/nutsandbolts/operators.html

 

Equality is 3 places after additive ops, so even without parenthese it parses as q == (hh - 1.0f). But of course you should still use parentheses for human readability and to catch the ambiguous cases where you think you know the rules and really don't. Precedence can be tricky, and although as you gain experience you will inevitably think that you know precedence, that isn't the case. Nobody really does (if someone tells you he does, he is almost certainly lying!), and neither do the people around you who might read your code. Therefore, even if precedence has it that you don't need them, always use parentheses to make 100% clear what you mean.

 

Java, like C++, does not define the value of true. It merely states that a boolean encodes 1 bit of information with the two possible values true and false (without saying what they are) and explicitly says that the storage size is not defined. true may therefore be 1 or -1, or in principle any other value (you do not need to know, only the compiler must know).

 

C++ goes further defining conversions to and from integer (and between integers and floats), but I am not aware that Java even officially allows these conversions (they are marked "-" in the casting conversion table in 5.5, so actually the compiler shouldn't accept any such thing as true - 1.0f).

Edited by samoth

Share this post


Link to post
Share on other sites


WTF C++. Y U LET false IMPLICIT TO 0.0f?

Because it's compatible with C.

 

C didn't have a bool type, it used int instead, with false defined as 0 and true as not 0 (well, really, the Z bit being set in the PDP SR register was defined as false, and clear being defined as true..  also, not 0 is ~0 which represents -1 in 2's complement arithmetic, so true usually ended up as -1, tant pis).  It would be unexpected to not have an implicit conversion between 0 and 0.0, false is just 0, therefore there is an implicit conversion from false in C++ to 0.0f, because that will let old C code compile in C++.

 

But you knew that.

Share this post


Link to post
Share on other sites

WTF C++. Y U LET false IMPLICIT TO 0.0f?

Because it's compatible with C.
 
C didn't have a [font='courier new', courier, monospace]bool[/font] type, it used [font='courier new', courier, monospace]int[/font] instead, with false defined as 0 and true as not 0 (well, really, the Z bit being set in the PDP SR register was defined as false, and clear being defined as true..  also, not 0 is ~0 which represents -1 in 2's complement arithmetic, so true usually ended up as -1, tant pis).  It would be unexpected to not have an implicit conversion between 0 and 0.0, false is just 0, therefore there is an implicit conversion from false in C++ to 0.0f, because that will let old C code compile in C++.
 
But you knew that.
That doesn't hold water :P
C++ isn't compatible with C, anf C only has bool/true/false as standard library concepts (optional macros in stdbool.h), and these macros were added well after then standardisation of C++.

[tt]true==-1[/tt] makes sense to be as an implementation defined detail, so [tt](true-1)[/tt] could well be expected to be -2 :lol:
I don't get why bools should implicly cast to integers, let alone to floats, which are a whole 'nother kettle of fish!

Share this post


Link to post
Share on other sites

The world is full with code like   x = y + (x == y);  // Add 1 extra if x and y are equal before the assignment.

This is the shortest way in C to have these conditionals, and thus people use it. :)

 

When C++ was started, the true -> 1 implicit conversion was copied from C. Later, "true" and "false" were added, but at that time the above code was already in C++ programs too, of course. As a result, it's impossible to drop the implicit conversion, or you'd break a lot of old C++ code.

 

Conversion to float is logical, just as "1 - 1.0f" works by converting the integer to a float.

Share this post


Link to post
Share on other sites

true==-1 makes sense to be as an implementation defined detail, so (true-1) could well be expected to be -2

Keep in mind that regardless of the bitpattern representation of [tt]true[/tt] (which could be literally any integer bitpattern), it will always be converted to the integer value [tt]1[/tt] (and hence, floating point [tt]1.0f[/tt]).

The fact that booleans promote to integers (rather than the other way round), leads to a very interesting gotcha:
#include <iostream>

int main() {
    int i = 9;

    if (i) {
        std::cout << "this prints, because i is true" << std::endl;
    }

    if (i == true) {
        std::cout << "this won't print, because i != true" << std::endl;
    }
}
Which is why most veteran C programmers write their comparison expressions as [tt]i != false[/tt], instead.

Share this post


Link to post
Share on other sites

 

 

WTF C++. Y U LET false IMPLICIT TO 0.0f?

Because it's compatible with C.
 
C didn't have a bool type, it used int instead, with false defined as 0 and true as not 0 (well, really, the Z bit being set in the PDP SR register was defined as false, and clear being defined as true..  also, not 0 is ~0 which represents -1 in 2's complement arithmetic, so true usually ended up as -1, tant pis).  It would be unexpected to not have an implicit conversion between 0 and 0.0, false is just 0, therefore there is an implicit conversion from false in C++ to 0.0f, because that will let old C code compile in C++.
 
But you knew that.

[tt]true==-1[/tt] makes sense to be as an implementation defined detail, so [tt](true-1)[/tt] could well be expected to be -2 laugh.png
I don't get why bools should implicly cast to integers, let alone to floats, which are a whole 'nother kettle of fish!

 

All implicit casts that don't lose precision are handled automatically in C++ because they are safe, as no information in the cast is lost. That is why this stuff works safely, upcasting from bool > int > float is safe the other way round is not because you lose precision, this is also when the compiler will spit out warnings.

Edited by NightCreature83

Share this post


Link to post
Share on other sites

All implicit casts that don't lose precision are handled automatically in C++ because they are safe, as no information in the cast is lost. That is why this stuff works safely, upcasting from bool > int > float is safe the other way round is not because you lose precision, this is also when the compiler will spit out warnings.


int (32-bit) to float (32-bit) is not safe and can lose information, even though it will be automatically promoted in C++. Edited by Nypyren

Share this post


Link to post
Share on other sites


All implicit casts that don't lose precision are handled automatically in C++ because they are safe, as no information in the cast is lost.

I think a more strict definition would be that implicit casts of basic types that do not risk [i]truncation[/i] are handled automatically.

 

And 'safety' is a very relative term. Clearly such promotions can cause logic bugs, which doesn't equate to 'safe' in my book...

Share this post


Link to post
Share on other sites

This topic is 828 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this