When (x==0) do_something();

[Solar]

Yes I know, there should be a { } while ( 0 ) wrapper around it and probably some other things, and macros are evil, but I'm in a hurry and it achieves the goal without having to reform the language.

[JamesM]

To be fair, I don't think any amount of while(0) or curly braces can prettify that solution - It's just not a problem with a viable C solution.

[zaleschiemilgabriel]

Whatever you guys come up with (macro, function, whatever), the output of compiling such code would be the same as if the "if" directive was used everywhere and would probably also be cluttered with extra function calls...

Basically if C had something like this it would've brought nothing but more problems for the beginners.

[Solar]

ACK.

[01000101]

*COUGH* Atomicity! *COUGH!*

I have only heard that word referring to locking mechanisms to prevent things like process hijacking and such. How does that apply to my code?

[JamesM]

*COUGH* Atomicity! *COUGH!*

I have only heard that word referring to locking mechanisms to prevent things like process hijacking and such. How does that apply to my code?

Atomicity is required in your code because the operation of changing 'x' is not guaranteed to be atomic, i.e. it is not guaranteed to execute in one processor cycle, so your interrupt routine could actually fire while X is being changed.

For example, a 32 bit load immediate macro-operation in MIPS is expanded by the assembler into two instructions, a "load upper immediate" which sets the top 16 bits of the register, and an "or immediate" which sets the bottom 16 bits of the register. Consider:

Code: Select all

Currently, X = 0x10000. If X = 0, and the timer fires, panic will ensue. Forget for the moment that this is taking place fully in registers - mips' addressing modes are somewhat limited.

lui $x, 0x0000    ; set the upper 16 bits of register 'x' to 0
ori $x, 0x0001  ; set the bottom 16 bits of register 'x' to 1

Notice the if the interrupt fired between these two instructions, $x would actually contain zero and not 0x10000 or 0x1.

Now this is a bit of a weak example, I know, but there are certainly other examples out there more relevant to the x86, and atomicity is not something you want to forget about.

[01000101]

ohh ok. I get it (for the most part) now.

Thanks for clearing that up. And I will deffinately not forget about that as it could imply serious issues if not dealt with.

[AndrewAPrice]

My extensions:

Code: Select all

#define until(a) while(!(a))
#define does(a) if(a)
#define doesnot(a) if(!(a))
#define be ==
#define notbe !=
#define number int
#define decimal float

Alternatives to does/doesnot and be/notbe are:

Code: Select all

#define is(a) if(a)
#define isnot(a) if(!(a))
#define thesameas ==
#define differentto !=

or possibly

Code: Select all

screwup(a) delete &a

[Brynet-Inc]

Jeez, some of you probably like http://en.wikipedia.org/wiki/Iso646.h as well

[iammisc]

Actually, I was going to implement something like this in my toy distributed programming language which is based on the concept of actors. You can basically have a piece of code executed when an actor reaches a certain state. However, it would be more like an event system that's integrated into the language unlike the proposed 'when' keyword which was only local to a function.

[zaleschiemilgabriel]

I think they did this in Visual Basic, with object properties, but they weren't very useful or popular. If I understood correctly, properties are better than the actors you describe, in that every state causes an update, not only certain states. That puts more of the load on the programmer (to synchronize states). But I hope that works out well for you. If I'm not mistaken, event-based systems are most useful in game programming...