Is there a "new" style for casting?

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.

sierdzio

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

at present the compiler/editor will be treating your file as though it did have that line at the end.

Whoa, really? Which compiler allows that?

For me (GCC) an unterminated ifdef is a hard error, compiler does not implicitly add it.

saber

@JonB
on every file "#endif " is added from first .
all the warnings was coming up after the update of qtcreator.

see this
on the old version qt created this by it self

explicit MainWindow(QWidget *parent = 0);

after update

should i replace the 0 with nullpointer on every file??
should it be a error in older version of compiler??
in my qmake i add that must have c++ 11 support .

sierdzio

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

@JonB
on every file "#endif " is added from first .
all the warnings was coming up after the update of qtcreator.

see this
on the old version qt created this by it self
explicit MainWindow(QWidget *parent = 0);
after update

should i replace the 0 with nullpointer on every file??
should it be a error in older version of compiler??
in my qmake i add that must have c++ 11 support .

These are hints from clang on how to improve your code. You are not forced to do everything it says. You are seeing them now because the clang code model is default since Qt Creator 4.7. So previously you were using the old code model which did not offer these hints. That's all there is to it. If the code compiles fine (without warnings), you can ignore the hints.

However, it is a good idea to at least consider them, because these hints are (in 90% of cases) very good hints indeed.

In this case yes, I'd strongly recommend using nullptr rather than zero. It is an explicit, named value that makes it harder to make a mistake.

VRonin

I'm late to the party but just wanted to note Qt provides qFuzzyCompare and qFuzzyIsNull to compare double numbers for equality but you have to read the docs carefully before using them

saber

@sierdzio
i am adding all the fix that qtcreator suggesting .

as for the " #endif " i am ignoring it.

JonB

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

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

at present the compiler/editor will be treating your file as though it did have that line at the end.

Whoa, really? Which compiler allows that?
For me (GCC) an unterminated ifdef is a hard error, compiler does not implicitly add it.

The kind which generates a screenshot "Unterminated #ifdef" shown by the OP who says it's a warning but the app compiles fine.

Now that you have said

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

I knew nothing about it being "clang". I took it that the OP had perhaps failed to get the last line of whatever he was fetching/copying (stranger things have been known to happen on this forum...). The OP should ignore my suggestion and stick with yours!

jsulm

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

add that enm

Please don't there is NOTHING to add to the enum! Simply remove the "default" inside the switch. Please read the link I posted more carefully, it is explained there.

saber

@jsulm
ok.