Mark Gordon wrote:

> And then there are the Unix shells...
> 
> $ true
> $ echo $?
> 0
> $ false
> $ echo $?
> 1
> 
> Just to keep everyone confused. ;-)

They teach you that at Siggraph 2000 ?

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Peter Popov <pet### [at] usanet> wrote:
: Why am I thinking that this issue has not been standardised yet?

  What do you mean?
  It is clearly stated in the C and C++ standards.

  If you mean that there's no common standard for all programming languages,
that's only good. If in a specific programming language it's a lot more
natural to state that 'false' is -1 (for example for speed reasons), then
there's no reason to force it to be anything else.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Dick Balaska <dic### [at] buckosoftcom> wrote:
: I have also seen #define TRUE ~FALSE

  This is horrible. It doesn't work!

  Suppose we have:

#define FALSE 0
#define TRUE ~FALSE

  Then TRUE will be -1 (ie. all bits set).

  Now suppose we want to add a "boolean" type:

typedef int BOOL;

  This will NOT work as it should:

int x=2, y=2;
BOOL b;

b = (x==y);

if(b == TRUE)
  puts("Equal");
else
  puts("Different");


  This will print "Different" although x and y are equal.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

pk <thi### [at] videotronca> wrote:
: What do you mean? Isosurfaces are booleans for me: at location <x, y,
: z>, there's a point(true, or 1), or there isn't any(false or 0)... So,
: you have a function that draw a plane, and another one that draws a
: sphere...
: You AND them... the result? a circle... You & them... the result? a
: circle...

  Well, here you are thinking about the set theory union. This has little to
do with the logical and-operator.

  And besides, the logical and-operator in programming languages has lower
precedence than + and - anyways. So in either way you want to think about it,
the current implementation is wrong.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Warp wrote:
> 
> Dick Balaska <dic### [at] buckosoftcom> wrote:
> : I have also seen #define TRUE ~FALSE
> 
>   This is horrible. It doesn't work!
> 
>   Suppose we have:
> 
> #define FALSE 0
> #define TRUE ~FALSE
> 
>   Then TRUE will be -1 (ie. all bits set).
> 
>   Now suppose we want to add a "boolean" type:
> 
> typedef int BOOL;
> 
>   This will NOT work as it should:
> 
> int x=2, y=2;
> BOOL b;
> 
> b = (x==y);
> 
> if(b == TRUE)
>   puts("Equal");
> else
>   puts("Different");
> 
>   This will print "Different" although x and y are equal.
> 
It is generally not good idea to compare against #define-d TRUE anyhow.
Better is to use != FALSE (although it is not very readable with its
double negative. Fortunately with C++ bool type this shouldn't be issue
any more.

Post a reply to this message

Warp wrote:
> 
> Dick Balaska <dic### [at] buckosoftcom> wrote:
> : I have also seen #define TRUE ~FALSE
> 
>   This is horrible. It doesn't work!
> 
>   Suppose we have:
> 
> #define FALSE 0
> #define TRUE ~FALSE
> 
>   Then TRUE will be -1 (ie. all bits set).
> 
>   Now suppose we want to add a "boolean" type:
> 
> typedef int BOOL;
> 
>   This will NOT work as it should:
> 
> int x=2, y=2;
> BOOL b;
> 
> b = (x==y);
> 
> if(b == TRUE)
>   puts("Equal");
> else
>   puts("Different");
> 
>   This will print "Different" although x and y are equal.

You are a young pup.
And you are correct that this doesn't work on 2000 C compilers
because the (user) definition of TRUE doesn't match the system
definition.

But suppose you are working on a 6502 :) or a PDP-11, which can
deal with a -1 much easier than a 1; then it makes sense.
The PDP-11 is big-endian, so when you truncate a 1, you get 0
like down casting from int to word to char.  The -1 always stayed
consistent across casts.

dik

Post a reply to this message

Dick Balaska <dic### [at] buckosoftcom> wrote:
: But suppose you are working on a 6502 :) or a PDP-11, which can
: deal with a -1 much easier than a 1; then it makes sense.
: The PDP-11 is big-endian, so when you truncate a 1, you get 0
: like down casting from int to word to char.  The -1 always stayed
: consistent across casts.

  This can't work this way. If it did, then if you make this:

char c = 1;

the variable 'c' will have the value 0.

  '1' is of type int.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <398d7a88@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   This can't work this way. If it did, then if you make this:
>
> char c = 1;
>
> the variable 'c' will have the value 0.
>
>   '1' is of type int.

Sorry, but you are misunderstanding the concepts here:  You have to view the
problem on a lower level than the C programming language.  You have to look
at the hardware:  In case of a memory based CPU architecture, an access to a
int casted to a char will have certain side effects that are usually
"hidden" by a compiler, however, especially in the early days of C it was
common to use the knowledge about the CPU the code would run on to increase
speed.

Even today you can use this trick of CPU dependency, i.e. when you want to
determine the endianess on the fly - simply cast an pointer to an int to a
char and look at the result on different architectures.  After all, C
explicitly allows low level programming; this makes it such an popular
language for implementing operating systems and embedded applications.

A good textbook explaining such issues is "Computer Organization and Design:
The Hardware/Software Interface" (ISBN 1558604286).  It uses the original
(32 bit) MIPS architecture as example for the assembler code (and there is a
software emulator of a simple MIPS system available - even one that runs on
Solaris).  It also explains how high-level language constructs are actually
implemented on the assembly level.  This is in particular useful if you want
to write efficient C/C++ code.
The only negative point is the US$80 price tag.  Anyway, it is available
even in a lot of European university libraries.  Alternatively, there will
surely be a lot of similar, but older books (usually covering the 68000 CPU
architecture) available in next to any library.


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Warp wrote:
> 
>   This can't work this way. If it did, then if you make this:

It works.  It wasn't pretty.

On x86, if you lay out 0x01020304 in memory, it becomes
04 03 02 01  which is what you are used to.
if you read this as a (32 bit) int then you get back your 0x01020304.
Reading it as a char you get 0x04. 
So using TRUE=1 flows naturally with this scheme.
01 00 00 00  is 1 whether read as 8 or 32 bits.

But on a big endian machine, i=0x01020304 is laid out
01 02 03 04.  So if you read (char)i you get 01.

So if (int)i = TRUE=1 or 00 00 00 01, then reading (char)i gives you 0.
So (int)i = TRUE = -1 or FF FF FF FF, gives you non-zero in any size.

Like i said, these were the old days.  Now i believe on Sparcs and 680x0 
there is an implied offset, such that (char)i is read as *((char)i)+3).
Hmm, that seems even weirder; what would ((char)i)+1) give you.
Beats me.  So i took a jaunt through my old K&R and there is no mention
anywhere of TRUE, FALSE, BOOL or boolean.  It does mention that UNIX 
is 16000 lines of C :) and that the assignment
int i 1; /* is legal but deprecated */
Also, the equivilant of += and -= , which is =+ and =- is now frowned upon
for obvious reasons. x =-1;

Old book.

dik

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: Sorry, but you are misunderstanding the concepts here:  You have to view the
: problem on a lower level than the C programming language.  You have to look
: at the hardware:  In case of a memory based CPU architecture, an access to a
: int casted to a char will have certain side effects that are usually
: "hidden" by a compiler, however, especially in the early days of C it was
: common to use the knowledge about the CPU the code would run on to increase
: speed.

  I think that a C compiler making this kind of thing (ie. when '1' is casted
to a char, the value '0' results) breaks the ANSI C standard, and thus the
compiler is not an ANSI C one.
  Of course you can use low-level tricks to, for example, get the endianess
of the system, but you can't do many of these tricks without breaking the
standard (usually the standard says about these things that they are undefined
and the compiler can do whatever it wants about them).
  But as you said, specially in embedded systems this kind of freedom makes
C a very versatile language. Not many other languages allow you to, for
example, write directly to a memory location some value.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message