macOS ! Logical operator !

[Mactrillionaire]

It's key to learn the difference between unary operators, binary operators and ternary operators. A unary operator such as ! only takes one operand (i.e., !a). A binary operator such as / takes two operands (i.e., a / b). A ternary operator such as ?: takes three operands (i.e., a ? b : c). In order to force the condition to be evaluated as you expect it to be you need the expression to be parenthesized (!(i < j) or i >= j, but not !i < j because that is the same as ((i ? 0 : 1) < j)).

 

[jiminaus]

The second one may be less "efficient" in terms of source code size and maybe even memory use, but it is inherently easier to debug and also easier to port or re-use later. This is related to mydogisbox's comment earlier in the thread as you can use the debugger to separate out if condition is really 0 or if something is misbehaving in the printf. That's harder to do if you write it as a single statement.

This has proven itself to me time and time again. After repeatedly spending time re-writing complex expressions into a series of smaller expressions using temporary variables so I could step through the expression, I now write out the series of smaller expressions to start with. I used to write the complex expression to be efficient. But I've satisfied myself, by both profiling and looking at generated assembly, that the two are equivalent when compiling with optimisations, both in performance and space.

 

[cybrscot]

Google for "n1256.pdf" - that is the latest free draft of the C language standard. When in doubt, that document says how it is. Then look up the syntax for the "!" operator and you'll see how to read it.

I just spent about 20 minutes looking through that document, Yes everything is there I'm sure, but it's way too technical for a beginner. Also difficult to find what I'm looking for, I don't understand 9.5/10 of the document! But I have it on my desktop, and it's another tool should the need arise. Thanks!

 

[jiminaus]

Yes everything is there I'm sure, but it's way too technical for a beginner. Also difficult to find what I'm looking for, I don't understand 9.5/10 of the document!

Langauge specs are written more for compiler writers than compiler readers. But they are authoritative sources.

Google "C operator precedence" to get C operator precedence tables. Just be sure to read if the table is from highest to lowest precedence, or vice-versa. If your not sure, look for the comma operator, it has the lowest precedence.

 

[Sydde]

This has proven itself to me time and time again. After repeatedly spending time re-writing complex expressions into a series of smaller expressions using temporary variables so I could step through the expression, I now write out the series of smaller expressions to start with. I used to write the complex expression to be efficient. But I've satisfied myself, by both profiling and looking at generated assembly, that the two are equivalent when compiling with optimisations, both in performance and space.

And even if it is not optimized out, what is the cost? The vast majority of the code you write is performance-trivial and will not suffer from verbose object code. You should probably not have optimizations turned on until you have a final product: being able to observe intermediate values while debugging is very helpful, and the real time cost of them is vanishingly small on today's hardware.

 

[balamw]

And even if it is not optimized out, what is the cost? The vast majority of the code you write is performance-trivial and will not suffer from verbose object code.

I'm with you, but...

I guess you may have to be "of a certain age", but some of us really miss the unbloated heavily hand-optimized assembly code that powered the 8 bit machines and even the original 128K Macs.

It can be a hard change to make, mentally.

B

 

[notjustjay]

I'm with you, but...

I guess you may have to be "of a certain age", but some of us really miss the unbloated heavily hand-optimized assembly code that powered the 8 bit machines and even the original 128K Macs.

It can be a hard change to make, mentally.

B

Haha. I hope I'm not in the "of a certain age" category (I'm 32) but I do remember being very proud of how elegant my x86 assembly code programs were in my programming classes in university, especially compared to the compiler-produced assembly equivalents. There's something beautiful about clean, easy to read code.

I also remember the days of the 40 megabyte hard drives, when I was able to point to EVERY SINGLE file on the drive and account for its purpose (or delete it). Remember when the minimal Mac OS bootable system consisted of exactly two files?