Casting a logical boolean as an int?

Pages: 12
> integers where 255 + 1 == 0 are defined in mathematics, anyone with math background will understand how they works.

while C++ has int where x + 1 is undefined for some value (std::numberic_limits<int>::max()). Anyone with minimal familiarity with C++ will understand what that implies.

> 2s complement was created and widely used because it allows operations with it to behave like algebraic ones.

You are completely mistaken; operations on C++ integral types do not behave like their algebraic counterparts in mathematics.


> Isn't this implies that bools in C++ are not safe?

No it doesn't. It implies that bools in C++ can be used in an unsafe manner. An explicit conversion via a compile-time cast can be used in an even more unsafe manner. ints, doubles, user-defined types, inheritance .... can all be used in an unsafe manner.


> And on top of that it is slower than native types (creating pointer to non-static member function is not fastest operation)

It actually isn't any slower. To realize that, you need to understand fast how optimizers work, how &Java_boolean::not_integral is evaluated, if at all going it is going to be evaluated, and so on. That is how it is, and I'm just going to state it. I don't want to spend more time explaining all that.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
// compiled on gcc 4.8 i686 with -fomit-frame-pointer -O3  

struct Java_boolean
{
    explicit constexpr Java_boolean( bool b = false ) : value(b) {}

    using Java_bool_t = void (Java_boolean::*)() const ;
    operator Java_bool_t() const { return value ? &Java_boolean::not_integral : nullptr ; }

    private:
        bool value ;
        void not_integral() const {}
};

int foo( Java_boolean jb )
{
    if(jb) return 100 ;
    else return 200 ;

    /*//////////////////////
    __Z3foo12Java_boolean:
    LFB5:
        .cfi_startproc
        cmpb	$1, 4(%esp)
        sbbl	%eax, %eax
        andl	$100, %eax
        addl	$100, %eax
        ret
        .cfi_endproc
    /////////////////////////*/	    
}

int bar( bool b )
{
    if(b) return 100 ;
    else return 200 ;
    
    /*//////////////////////
    __Z3barb:
    LFB6:
        .cfi_startproc
        cmpb	$1, 4(%esp)
        sbbl	%eax, %eax
        andl	$100, %eax
        addl	$100, %eax
        ret
        .cfi_endproc
    /////////////////////////*/	    
}


I've no interest in continuing with this discussion any further; I'm out of this thread.
Last edited on
OK. lets not continue this discussion, because it looks like we cannot come to agreement. And thanks for pointing that compiler will optimise pointer returns.


I just want to note that although signed integer overflow is undefined per standard, literally all machines using 2s complement will behave like math counterpart. Probably reason for undefined behavior in standard is to allow optimisation for machines using another representation. (I do not implying that this behavior should be used)
There is also limited range numbers in math, so saying that you cannot map programming integer behavior to abstract math is kinda ignorant.
Topic archived. No new replies allowed.
Pages: 12