Please explain the following piece of C++ to me
void cSkymax::SetMode(char newmode)
{
m.lock();
if (mode && newmode != mode)
ups_status_changed = true;
mode = newmode;
// printf("%s %d %s %s\n", __FILE__, __LINE__, mode, newmode);
m.unlock();
}
both mode and newmode are defined as char but I am failing to see how mode && newmode can be compared to a char. Surely && returns TRUE or FALSE not a char.
I am also assuming that m.lock and m.unlock are stopping memory swopping.

The reason for my question is that I require to do this function in C not C++ and I know very little about C++

char is an 8 bit integer. char can be used to handle characters or to handle 8 bit integer opearations. Note that char can be signed or not depending on the compiler.
bool is also an 8 bit integer, where 0 is false and ther values are considered true.
The result of the && operator has type bool. The comparison is then between two 8 bit integers.

Thank you but surely there is a better way of doing this? Preferably more understandable.

By the way GCC 8.3.0 on Debian tells me

pointing to the !=

This is legal C code, too.

An if statement, without any specific comparison, decides if its fulfilled if the expression inside its parenthesis resolve to true/not zero.

So 'mode' on its own is simply a check like mode != 0.
This is then followed by && which, of course, is kind of an if test on its own, if the thing before it is true.

So, if mode is not zero, then the && goes forward to the next check, which tests if the new mode has a different value than mode.

Rewritten (in a C like manner) it would be:
Of course, if you make sure that every skymax object gets initialized with mode as zero, and if every new mode is nonzero, then you could simply test against the new mode being different than the old one.

Then cSkymax::mode is probably a pointer, and not a simple character, making this ...not a good idea since mode would be replaced by 'newmode' if mode is nonzero and different to newmode.

Either change the mode field of cSkymax to a character, as well, or change the new mode to a pointer, a pointer that would point to a new/different mode, I suppose.
Anyway, this seems like a troublesome setup.

1 members found this post helpful.

It's likely that m is a std::mutex. You can look to pthreads for this in C (man pthread_mutex_lock).

2 members found this post helpful.

Geist, thank you for your explanation however neither mode nor newmode are pointers. Both are defined as char.

Well, then...uh...then I guess the compiler is a liar, or something equally strange.

I think you're misunderstanding operator precedence and how && is evaluated.

First, operator precedence. It's:

Not:

Second, short-circuit evaluation:

First, "mode" is evaluated. If it evaluates to true, then "newMode != mode" is evaluated. If that also evaluates to true, then the expression evaluates to true. Otherwise, it evaluates to false.

1 members found this post helpful.

Dugan please tell me how
is different to

If newmode is not equal to mode.


Can be expanded to:

Not really sure what else I can say, but I'll try...

is equivalent to:

Geist's explanation above mine is also correct.

I think that
if (mode && newmode != mode)
is better than
if ((mode != 0) && (newmode != mode))

on the x86 platform. There is a special instruction that is used when you do if(mode).
Anyway, perhaps performance is not important in your case.

What makes you think the compiler won't optimize both to the exact same object code?

I think the best and most performant code is the code that the programmers can the most easily read, understand and work with.
Computers are quite beastly these days, and if you're writing for a platform that is like...from the past 20 years or so then you should be fine just writing legible stuff, even if you're using old versions of compilers and whatnot from back then.

No need to write brain wracking crypto obfuscated hackariffic guruesque code unless you're one of the elites that do it for important purposes or if you're that much of an enthusiast that you want to be elite like that.

...but I wager to say that the people who make it on that journey tend to have an easy time with the easy stuff, too.

So, yeah, don't make it harder on yourself than you have to, even if you're writing for some microcontroller for your own project.
You can always optimize later, don't set up your project like an entry to the IOCCC from the get go.

Edit: While IOCCC is a bit of an extreme example, I really mean all needlessly brain time eating code.
Name your variables descriptively, even if they get a bit longer (of course having a 80 character long variable name would be a tad silly but if it worked for you? Do that too.)
Break your code up into smaller pieces, don't go completely crazy to just avoid some code duplication, but the more you can encapsulate and reuse, the better.

Another great type of code is the code you can remove from the codebase, after all.
The less code, the less places to screw up :P