|
You are making a big assumption that the -- operator will execute before the |= operation.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
|
Yes, I have tested it fine. 
- NS -
|
|
|
|
|
your code have one failure : negative numbers :
signed char oddNumber = -128;
--oddNumber;
oddNulber |= 1;
|
|
|
|
|
Yes, it's a fact that signed numbers do wrap, eventually.
The original question (and the answer to that specific question) said nothing about negative numbers.
If I remember it right, the question said that 14 should give 13 as output.
There was no rule for handling negative numbers.
Or do I remember it wrong?
If negative numbers doesn't matter, why waste code?
|
|
|
|
|
he didn't talk about negative numbers, but he never exlude them 
using int implies that negative values are allowed (otherwise, i think he would have used unsigned), and odd values can be also either positive or negative... 
moreover, writting --oddNumber |= 1; can confuse the reader... that's why i keep militate for the if test solution...
|
|
|
|
|
As long it doesn't confuse the compiler... 
|
|
|
|
|
you shouldn't think like that, simply because in your life, not only you won't always be the only one to maintain the code you wrote, but you can also badly understand what you thought beeing obvious when wrote it ; worse when it happens with someone else...
|
|
|
|
|
OK, I agree, such coding requires a good comment line to it, since the function might not be obvious to everyone.
|
|
|
|
|
I know that this code needs good documentation. But I like simple and less processor consuming codes. Further more, in my case there will not be negetive values. So I don't care about the behaviour of this logic with negetive values 
- NS -
|
|
|
|
|
if (a%2==0) // number is even
a--; // make it odd
We Believe in Excellence
www.aqueelmirza.cjb.net
|
|
|
|
|
U can use like this also.
using conditional operator....
(num%2 == 0)? num : num - 1;
|
|
|
|
|
I think simplest is the one that kakan said. --num |= 1;
- NS -
|
|
|
|
|
|
Maximilien wrote: yeah, but it's unreadable.
Unreadble for whom? 
|
|
|
|
|
I swear that there will be a good explanation for this in my cpp!
- NS -
|
|
|
|
|
|
First I thought about this one. But there is constraint in my requirement the new odd number should be less than the actual one if it is even.
So #define makeOdd(x) ((--(x)) |= 1) is required.
- NS -
|
|
|
|
|
I also think that -- =1 is the best solution, from many points of view, from performance to simplicity. That code will easily compile even on small microcontroller implementations without great effort, even those that do not have division capabilities (I've seen % posted on some replies, and that is surely a waste of resources).
I've also seen the question of operator precedence. Actually, that should not be a problem, since, generally speaking, --x means that x will be decremented *before* the value is used. That is the diference between --x and x--.
If anyone has doubts about the precedence then (--(x))|=1 will guarantee adequate precedence, as proposed by NS17. I would sugest to force the precedence to make reading easier, meaning that, in this way, it is not necessary to know the exact meaning of --x by heart, and that the correct evaluation will be explicit instead of implicit.
I would also sugest an improvement that allows for the macro proposed by NS17 to be used even when x is not an l-value. That would be:
#define makeOdd(x) ( ((x)-1) | 1)
This macro could then be used in all cases below:
x=makeOdd(x);
x=makeOdd(14);
z=makeOdd(x)+makeOdd(y);
Rilhas
|
|
|
|
|
Rilhas wrote: I would also sugest an improvement that allows for the macro proposed by NS17 to be used even when x is not an l-value. That would be:
#define makeOdd(x) ( ((x)-1) | 1)
Exactly... actually i was ignoring that thing, beacuse in my case the variable itself should be changed...
Anyway thank you for your replay...
- NS -
|
|
|
|
|
hi all,
i have to create a Transparent Edit Control in my dialog please tell me your advice.
thanks,
uday.
uday kiran
|
|
|
|
|
|
Compiling...
StdAfx.cpp
Compiling...
Read_XVI_Scan.cpp
Linking...
LIBC.lib(wincrt0.obj) : error LNK2001: unresolved external symbol _WinMain@16
Release/Read_XVI_Scan.exe : fatal error LNK1120: 1 unresolved externals
Error executing link.exe.
A colleague is getting the above error when compiling here at work with VC, but at home on his VC-Express edition it works OK.
I'm sure this is a simple setting not right somewhere, but am not sure where to start looking - I guess once you've fixed this kind of glitch a few times, you get used to knowing where to look?
thanks in advance for any help..
-- modified at 7:07 Wednesday 19th April, 2006
|
|
|
|
|
I thought I'd fixed it by making it a console app, but now I get the other error
Linking...
LIBC.lib(crt0.obj) : error LNK2001: unresolved external symbol _main
Release/XVI_Read_Scan.exe : fatal error LNK1120: 1 unresolved externals
Error executing link.exe.
searching codeproject I found this suggestion but don't know which tab/group this is in and couldn't find it by looking through them
"Usually this is caused by leaving the _ATL_MIN_CRT definition in your project settings when your code uses the C runtime libary startup code, either directly or indirectly. Remove the _ATL_MIN_CRT definition and rebuild all."
|
|
|
|
|
Ack, I couldn't find a "main" function in his code - added it and now it works of course!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
