![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chris Cason wrote:
> In the real world, no programmer would ever do something
> that mean with a macro called TRUE. Right? :-)
There was an entry over at the Daily WTF in which someone posted code,
written by another person, containing this:
#define TRUE 0
#define FALSE 1
I swear that I am not making this up.
Regards,
John
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Vincent Le Chevalier wrote:
> John VanSickle a écrit :
>> Invisible wrote:
>>> Can somebody interpret this for me?
>>>
>>> while (TRUE) { cont = (*cont)(); }
>>>
>>> What on earth...?
>>
>> cont is a pointer to a function that is expected to return a pointer
>> to a function. The code here causes a series of functions to be
>> called, each one specifying another function to be called afterwards
>> by returning the address of the function to be called.
>
> I was thinking the same, but I can't seem to find the right type
> definition to make it work without casting to and from void*... Which is
> apparently illegal
> (http://www.parashift.com/c++-faq-lite/pointers-to-members.html#faq-33.8)
Casting back and forth from void* is considered exceptionally unwise in
C++, but it's considered a great way of writing tighter code in C.
Regards,
John
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Chris Cason <del### [at] deletethistoo povray org> wrote:
>> Of course, this being C, 'TRUE' could be a macro that expands to a function
>> that returns a value and thus the loop need not be infinite.
>
> Actually there are other ways for the loop to end. For instance, the
> function being called could execute an exit() call.
>
> (Another less fancy way would be to return a null pointer from the
> function, in which case the program will end with a segmentation fault.)
Or return a pointer to the exit() function, which is the same as above.
Regards,
John
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
John VanSickle <evi### [at] hotmail com> wrote:
> Casting back and forth from void* is considered exceptionally unwise in
> C++, but it's considered a great way of writing tighter code in C.
In fact, for example casting method pointers to void* and back is
undefined behavior and in no way guaranteed to work. (And, in fact,
in many compilers method pointers are as large as two regular pointers,
and thus casting to void* would drop information.)
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> wrote:
> The idea here is that we jump to one label, then jump to another, then
> jump to another, never returning to the "caller".
>
> If we implement this using C functions that never return, an unbounded
> amount of stack gets eaten.
>
> Hence, they arranged for each function to *return* the function it would
> like to jump to next, rather than actually jumping to it, and the loop I
> posted is apparently the magic incantation that implements the jumping.
Yes, indeed.
http://en.wikipedia.org/wiki/Tail_recursion#Implementation_methods
I take it that you were looking at the C output of GHC, right? Haskell relies
on tail-recursion as much as any other functional language, as Scheme. The
method it is implemented underneath is as a trampoline.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
John VanSickle wrote:
> There was an entry over at the Daily WTF in which someone posted code,
> written by another person, containing this:
>
> #define TRUE 0
> #define FALSE 1
>
> I swear that I am not making this up.
I remember it well...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 26-Jul-08 21:39, John VanSickle wrote:
> Chris Cason wrote:
>
>> In the real world, no programmer would ever do something
>> that mean with a macro called TRUE. Right? :-)
>
> There was an entry over at the Daily WTF in which someone posted code,
> written by another person, containing this:
>
> #define TRUE 0
> #define FALSE 1
>
> I swear that I am not making this up.
Probably Unix convention?
http://en.wikipedia.org/wiki/True_(Unix)
http://en.wikipedia.org/wiki/False_(Unix)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> There was an entry over at the Daily WTF in which someone posted code,
>> written by another person, containing this:
>>
>> #define TRUE 0
>> #define FALSE 1
>>
>> I swear that I am not making this up.
>
> Probably Unix convention?
Ah yes - return code 0 = OK, any other code = failure.
What have we learned here? That using integers to represent Booleans is
a Very Bad Thing. :-P
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 <voi### [at] dev null> wrote:
> >> There was an entry over at the Daily WTF in which someone posted code,
> >> written by another person, containing this:
> >>
> >> #define TRUE 0
> >> #define FALSE 1
> >>
> >> I swear that I am not making this up.
> >
> > Probably Unix convention?
> Ah yes - return code 0 = OK, any other code = failure.
C actually distinguishes between TRUE/FALSE and EXIT_SUCESS/EXIT_FAILURE.
They shouldn't be confused nor mixed.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
>
> Because "while(1)" is a common idiom, and avoids the ugly goto.
>
Either that or for(;;) { ... }
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |