Page 2 of 2
Posted: Wed Mar 19, 2008 7:45 am
by 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.
Posted: Wed Mar 19, 2008 7:50 am
by 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.
Posted: Wed Mar 19, 2008 8:14 am
by 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.
Posted: Wed Mar 19, 2008 8:39 am
by Solar
ACK.
Posted: Thu Mar 20, 2008 2:21 am
by 01000101
JamesM wrote:
*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?
Posted: Thu Mar 20, 2008 2:31 am
by JamesM
01000101 wrote:JamesM wrote:
*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.
Posted: Thu Mar 20, 2008 4:11 am
by 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.
Posted: Sat Mar 22, 2008 2:48 am
by 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
Posted: Sat Mar 22, 2008 7:20 am
by Brynet-Inc
Jeez, some of you probably like
http://en.wikipedia.org/wiki/Iso646.h as well
Posted: Sat Mar 22, 2008 7:02 pm
by 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.
Posted: Mon Mar 24, 2008 1:28 am
by 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...