Is there a "new" style for casting?

[jsulm]

@Abrar said in Is there a "new" style for casting?:

static_cast<int>(screensize().width() * .8)

Yes, this is C++ type cast.

(int)(someVariabl);

Old C style cast which should not be used in C++.
See https://stackoverflow.com/questions/332030/when-should-static-cast-dynamic-cast-const-cast-and-reinterpret-cast-be-used

[J.Hilk]

@jsulm
technically,

int(someVariabl);

is a valid "conversion", as it's a functional notation

[Abrar]

@jsulm ok now understand the difference.
Thanks...

[jsulm]

@J.Hilk Both are C-style casts

[saber]

guys what a
@saber = static_cast<learn>( @jsulm and @J-Hilk ; (i think)

thanks.learned alot.

[Abrar]

@saber you wrote the clever statement ever.
!!!!

[J.Hilk]

@jsulm thats not what @aha_1980 said earlier, and what I read from my trusted source
(http://www.cplusplus.com/doc/tutorial/typecasting/) :-)

the new (qtcreator)clang code model seems to agree as well, as int(xy) is not flaged as old style casting.

[jsulm]

@J.Hilk Yeah, I think I was wrong on function style cast you mentioned

[saber]

i got more warnings to fix.

    switch( m_model->state() ) {
        case Battery::FullyCharged:
            ui->statusEdit->setText( tr( "Full Charged" ) );
            ui->timerLblEdit->setText( tr( "Full Charged" ) );
            break;
        case Battery::Discharging:
            addSeconds = static_cast<int>(m_model->toEmpty());
            addSeconds = rate != 0 && addSeconds == 0 ? ( energy - energyEmpty ) * 4 / rate: addSeconds;
            ui->statusEdit->setText( tr( "Discharging" ) );
            ui->timerLblEdit->setText( tr( "Discharged in : " ) );
            break;
        case Battery::Charging:
            addSeconds = static_cast<int>(m_model->toFull());
            addSeconds = rate != 0 && addSeconds == 0 ? ( energyFull - energy ) * 4 / rate : addSeconds;
            ui->statusEdit->setText( tr( "Charging" ) );
            ui->timerLblEdit->setText( tr( "Charged in : " ) );
            break;
        default:
            ui->statusEdit->setText( tr( "No Battery" ) );
            ui->timerLblEdit->setText( tr( "No Battery" ) );
            break;
    }

[sierdzio]

@jsulm said in Is there a "new" style for casting?:

@J.Hilk Both are C-style casts

Yep but clang does not complain about int(something) while it does complain about (int) something. Just sayin' :-)

[jsulm]

@saber said in Is there a "new" style for casting?:

i got more warnings to fix.

So, fix them

[saber]

@jsulm
sorry .
i don't think those are casting.and i am not understanding what is the fix.

[jsulm]

@saber The first warning says already what the problem is: comparing floating point numbers with == and != isn't save because of inaccuracy of such numbers represented in a computer. Depending on what you really want you should cast to int or use <, > for comparisions.
For the second warning take a look at https://softwareengineering.stackexchange.com/questions/179269/why-does-clang-llvm-warn-me-about-using-default-in-a-switch-statement-where-all
In general, you should try to find out what the problem is by yourself first before going to a forum and asking. Or do you want to ask for each and every warning you get? I mean, I'm happy to help, but sometimes I have the impression that people don't even try to find an answer by themselves.

[saber]

@jsulm
i understand all the warnings but problem is i don't know how to fix those .

i know this issues are small and silly to ask to help.but i have no other way. my app's co-developer is in off-line. i am a ui designer and newbie c++ developer .

thanks.

[jsulm]

@saber I already suggested what to change and provided a link. And you can round the floating point numbers to int to get rid of this message. And you can use Google.
Also you should think about whether you need floating point numbers at all...

[saber]

@jsulm
yes , it seems fixed.

    switch( m_model->state() ) {
        case Battery::FullyCharged:
            ui->statusEdit->setText( tr( "Full Charged" ) );
            ui->timerLblEdit->setText( tr( "Full Charged" ) );
            break;
        case Battery::Discharging:
            addSeconds = static_cast<int>(m_model->toEmpty());
            addSeconds = static_cast<int>(rate) != 0 && addSeconds == 0 ? static_cast<int>(( energy - energyEmpty ) * 4 / rate) : addSeconds;
            ui->statusEdit->setText( tr( "Discharging" ) );
            ui->timerLblEdit->setText( tr( "Discharged in : " ) );
            break;
        case Battery::Charging:
            addSeconds = static_cast<int>(m_model->toFull());
            addSeconds = static_cast<int>(rate) != 0 && addSeconds == 0 ? static_cast<int>(( energyFull - energy ) * 4 / rate) : addSeconds;
            ui->statusEdit->setText( tr( "Charging" ) );
            ui->timerLblEdit->setText( tr( "Charged in : " ) );
            break;
        default:
            ui->statusEdit->setText( tr( "No Battery" ) );
            ui->timerLblEdit->setText( tr( "No Battery" ) );
            break;
    }

as for the default , i read the post and understand that i can't do anything as the library i am using there is no eum like "no battery" . so it needs the default case.

[jsulm]

@saber You can: remove the default. If then a new value is added to the enum you will get a warning from compiler that this new value is not handled.

[saber]

for now i will leave as it is and inform the library author to add that enm.

i got more warning to fix.

i am getting this in all my ui based header file .
but the app compiles fine.

[sierdzio]

@saber said in Is there a "new" style for casting?:

for now i will leave as it is and inform the library author to add that enm.

i got more warning to fix.

i am getting this in all my ui based header file .
but the app compiles fine.

Ignore it, then. The code model sometimes gets bogged down in ifdefs without reason.

[JonB]

@saber
Although we cannot be sure, chances are that the last line of that header file should be:

#endif

to match the #ifndef started at line #17. (This is a common pattern to allow a header to be included more than once without it doing any harm.) Have a look at other header files (maybe from the same library?) and you should see this. You should fix this by adding the line --- at present the compiler/editor will be treating your file as though it did have that line at the end.