Programming Lesson of the Day
-
Just to expand on Richard's point... I'm more of a C guy than C#, but like with C/C++ I can only assume that in this case, the compiler is doing a binary operation of AND, and 1 (or any non-zero) AND 0 is always going to be zero, which is expressed as false in this case. It's the difference between a bitwise operator and a logical one.
Jeremy Falcon
Precisely, since I'm using both in the same code (hw management) I made my Dumb Mistake Of The Day :D
CALL APOGEE, SAY AARDWOLF GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver "Go ahead, make my day"
-
Jeremy Falcon wrote:
I reckon the difference being the compiler knows that's an assignment operator.
Nope, it's because both C# and Java are more type safe (strong typed) than C is. In this case they define a boolean type, C just interprets an integer to have similar "meaning" to a boolean. And the if statement (in C#/Java) requires a boolean input argument. It's the same sort of situation as sending a string into a function which expected a float - compiler error - wrong type. This is an example of where C uses a weak typing system. It generally just uses the raw data as if it's in the expected type. Effectively turning it into a raw type-cast. The more strongly typed languages disallow most of these, probably because they tend to be the reason behind lots of bugs (if not most).
At the same time C# is too rigid, especially with data which may have to be taken as raw (like a read from another process' memory) and read differently depending on other circumstances. I had to develop a C# plugin for VS that allowed me to visualize 8 bits or 16 bits grayscale images taken from the memory of a debugged process, either completely raw with parameters (height, width, bitsperpixel) inserted manually or taken from a standard structure we use in our codebase, which was stored in memory. Doing the necessary casts was freaking tough and required craptons of code and workarounds, while with C it would have been immediate. I prefer the need of more attention of C towards the need of knowing a stupid framework as with .NET languages - a poorly documented framework BTW since while every method and object is documented there isn't single piece of documentation explaining WEHN to use a particular namespace/object instead of a similarly named one, which are the related structures/objects/methods... compare that to Win32 APIs documentation.
CALL APOGEE, SAY AARDWOLF GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver "Go ahead, make my day"
-
At the same time C# is too rigid, especially with data which may have to be taken as raw (like a read from another process' memory) and read differently depending on other circumstances. I had to develop a C# plugin for VS that allowed me to visualize 8 bits or 16 bits grayscale images taken from the memory of a debugged process, either completely raw with parameters (height, width, bitsperpixel) inserted manually or taken from a standard structure we use in our codebase, which was stored in memory. Doing the necessary casts was freaking tough and required craptons of code and workarounds, while with C it would have been immediate. I prefer the need of more attention of C towards the need of knowing a stupid framework as with .NET languages - a poorly documented framework BTW since while every method and object is documented there isn't single piece of documentation explaining WEHN to use a particular namespace/object instead of a similarly named one, which are the related structures/objects/methods... compare that to Win32 APIs documentation.
CALL APOGEE, SAY AARDWOLF GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver "Go ahead, make my day"
I find the strong typing of C# is more of a help than a hindrance. Back in my C days I would get into horrible tangles doing precisely what you are trying to do. An int is not a bool even though many programmers of the era would treat them alike. I still encounter data tables that have integers or even strings used as boolean values and it makes my skin crawl.
We're philosophical about power outages here. A.C. come, A.C. go.
-
X & Y
is not the same as
X && Y
Twenty minutes wasted on a condition who refused to yield the correct result.
CALL APOGEE, SAY AARDWOLF GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver "Go ahead, make my day"
Don't feel bad. I once had a bug based on this very thing that took weeks to find.
Software Zen:
delete this; -
At the same time C# is too rigid, especially with data which may have to be taken as raw (like a read from another process' memory) and read differently depending on other circumstances. I had to develop a C# plugin for VS that allowed me to visualize 8 bits or 16 bits grayscale images taken from the memory of a debugged process, either completely raw with parameters (height, width, bitsperpixel) inserted manually or taken from a standard structure we use in our codebase, which was stored in memory. Doing the necessary casts was freaking tough and required craptons of code and workarounds, while with C it would have been immediate. I prefer the need of more attention of C towards the need of knowing a stupid framework as with .NET languages - a poorly documented framework BTW since while every method and object is documented there isn't single piece of documentation explaining WEHN to use a particular namespace/object instead of a similarly named one, which are the related structures/objects/methods... compare that to Win32 APIs documentation.
CALL APOGEE, SAY AARDWOLF GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver "Go ahead, make my day"
Don't get me wrong ... I'm not dissing on C and saying C# is all that great. I was simply pointing out why the if statement would fail to even compile in this particular case when trying this in C#. You make a point where C#'s strong typing does make a programmer's life more cumbersome - you'd need to convert a byte array into specific types to do what you want, though there is readily available built-in libraries for that, or you could use an unsafe code block and use pointers to cast one into the other (just like you'd have done in C). Point is it would make for more coding to achieve the same thing. Though it's only in special circumstances (like your example) where this is beneficial. Nearly everywhere else it means there's less to think about (and guard against) due to the compiler checking types for you. If you find you constantly run into situations where you need to cast between types - then perhaps C# isn't the correct tool for the job and you'd be better off with C instead.
-
"If I put in wrong data, will the result be correct?"
CALL APOGEE, SAY AARDWOLF GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver "Go ahead, make my day"
Yes, but unexpected.
-
I find the strong typing of C# is more of a help than a hindrance. Back in my C days I would get into horrible tangles doing precisely what you are trying to do. An int is not a bool even though many programmers of the era would treat them alike. I still encounter data tables that have integers or even strings used as boolean values and it makes my skin crawl.
We're philosophical about power outages here. A.C. come, A.C. go.
Remember that C was designed to replace assembly. Common assembly directives are things like "Branch if equal to 0", "Branch if not equal to 0", etc. No Booleans in assembly. In C, a string "abc" is really just the address of the letter 'a' in memory. So it is not really a "boolean", You are just asking the compiler is the address NULL (0) or not. char * str1 = "abc"; char * str2 = NULL; // #define NULL 0 if (str1) { /* will execute */ } if (str2) { /* will NOT execute */ }
-
Programming Lesson of the Day #3: Check your assumptions before posting them as a lesson! ;P
bool x = true;
bool y = false;
(x & y).Dump(); // Output: FalseIt's not commonly used, but for booleans,
&is the non-short-circuiting version of&&. It's the C# equivalent of VB.NET'sAnd, whereas&&equates toAndAlso.Binary & operators are predefined for the integral types and bool. ... For bool operands, & computes the logical AND of its operands; that is, the result is true if and only if both its operands are true. The & operator evaluates both operators regardless of the first one's value.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
At the same time C# is too rigid, especially with data which may have to be taken as raw (like a read from another process' memory) and read differently depending on other circumstances. I had to develop a C# plugin for VS that allowed me to visualize 8 bits or 16 bits grayscale images taken from the memory of a debugged process, either completely raw with parameters (height, width, bitsperpixel) inserted manually or taken from a standard structure we use in our codebase, which was stored in memory. Doing the necessary casts was freaking tough and required craptons of code and workarounds, while with C it would have been immediate. I prefer the need of more attention of C towards the need of knowing a stupid framework as with .NET languages - a poorly documented framework BTW since while every method and object is documented there isn't single piece of documentation explaining WEHN to use a particular namespace/object instead of a similarly named one, which are the related structures/objects/methods... compare that to Win32 APIs documentation.
CALL APOGEE, SAY AARDWOLF GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver "Go ahead, make my day"
Processing OSC packets (for example) is a doddle in C/C++ but somewhat cumbersome in C#
-
Programming Lesson of the Day #3: Check your assumptions before posting them as a lesson! ;P
bool x = true;
bool y = false;
(x & y).Dump(); // Output: FalseIt's not commonly used, but for booleans,
&is the non-short-circuiting version of&&. It's the C# equivalent of VB.NET'sAnd, whereas&&equates toAndAlso.Binary & operators are predefined for the integral types and bool. ... For bool operands, & computes the logical AND of its operands; that is, the result is true if and only if both its operands are true. The & operator evaluates both operators regardless of the first one's value.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Great tip and explanation. I am currently teaching myself C# and this is extremely helpful.
A giraffe is a horse designed by a committee... ... or an Agile methodology...
-
`Dump()` is an extension method added to all objects within LinqPad. LinqPad is a tool which allows writing & compiling simple C# code snippets (plus a bunch of other things). (And the basic version is free: www.linqpad.com )
Truth, James
-
Oh I hear ya man. I reckon the difference being the compiler knows that's an assignment operator. My understanding of the way C# and Java does things is to create an object where needed from literals / constants / expressions. So, it would be more like this...
"Hello, world!".ToUpper()
...just instead of a string it's a false... which gets treated like a boolean.
Jeremy Falcon
No, it's the use of an int as a boolean that C# complains about. The assignment in the if() is fine, provided it's a boolean:
bool x = false;
if (x = true)
"It's True".Dump();Truth, James
-
Programming Lesson of the Day #2: If you'd used C# it wouldn't have compiled ... :laugh:
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
Jeremy Falcon wrote:
I reckon the difference being the compiler knows that's an assignment operator.
Nope, it's because both C# and Java are more type safe (strong typed) than C is. In this case they define a boolean type, C just interprets an integer to have similar "meaning" to a boolean. And the if statement (in C#/Java) requires a boolean input argument. It's the same sort of situation as sending a string into a function which expected a float - compiler error - wrong type. This is an example of where C uses a weak typing system. It generally just uses the raw data as if it's in the expected type. Effectively turning it into a raw type-cast. The more strongly typed languages disallow most of these, probably because they tend to be the reason behind lots of bugs (if not most).
Makes sense.
Jeremy Falcon
-
`Dump()` is an extension method added to all objects within LinqPad. LinqPad is a tool which allows writing & compiling simple C# code snippets (plus a bunch of other things). (And the basic version is free: www.linqpad.com )
Truth, James
-
And I've learned something today! Thank you - I didn't know that. :thumbsup:
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
>
I'm sure James' response wasn't there when I posted this!
Well, at least you got the URL right....
Truth, James
-
X & Y
is not the same as
X && Y
Twenty minutes wasted on a condition who refused to yield the correct result.
CALL APOGEE, SAY AARDWOLF GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver "Go ahead, make my day"
How this difference can hurt. m is length of string = 3; *b is first character in string say "xyz" while( *b & m-- ) { b++; } is not the same as while( *b && m-- ) {b++;} because while( *b & m-- ) { b++; } fails when *b is null tested AND m is decremented at the same time ergo m is off by 1 while( *b && m-- ) { b++; } fails when *b is null tested. m is not decremented because of the short circuit test of *b stops the evaluation ergo m has the correct character count so yes & and && are not the same so be careful of the logic when using C
-
Don't get me wrong ... I'm not dissing on C and saying C# is all that great. I was simply pointing out why the if statement would fail to even compile in this particular case when trying this in C#. You make a point where C#'s strong typing does make a programmer's life more cumbersome - you'd need to convert a byte array into specific types to do what you want, though there is readily available built-in libraries for that, or you could use an unsafe code block and use pointers to cast one into the other (just like you'd have done in C). Point is it would make for more coding to achieve the same thing. Though it's only in special circumstances (like your example) where this is beneficial. Nearly everywhere else it means there's less to think about (and guard against) due to the compiler checking types for you. If you find you constantly run into situations where you need to cast between types - then perhaps C# isn't the correct tool for the job and you'd be better off with C instead.
I didn't get you wrong, neither I was dissing C# - each task has its tool for the job. For a graphical interface I would most definetely use C# (now I'm stuck to VB6 due to company decisions), and for almost any program. My job involves both hardware control and computation/memory heavy algorithms so C/C++ is the tool of excellence as of now.
CALL APOGEE, SAY AARDWOLF GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver "Go ahead, make my day"
