Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #3980 > unrolled thread

boolean usage

Back to article view | Back to comp.lang.c

Contents

  boolean usage "dr.oktopus" <blindwilly@freeonline.zzn.com> - 2011-05-14 14:05 -0700
    Re: boolean usage Keith Thompson <kst-u@mib.org> - 2011-05-14 16:41 -0700
      Re: boolean usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-15 04:18 +0100
    Re: boolean usage "dr.oktopus" <blindwilly@freeonline.zzn.com> - 2011-05-14 23:12 -0700
    Re: boolean usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-14 23:39 -0700
      Re: boolean usage "Bill Cunningham" <nospam@nspam.invalid> - 2011-05-19 21:29 -0400
        Re: boolean usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-19 22:49 -0700
          Re: boolean usage Keith Thompson <kst-u@mib.org> - 2011-05-20 09:17 -0700
            Re: boolean usage gazelle@shell.xmission.com (Kenny McCormack) - 2011-05-20 17:14 +0000
    Re: boolean usage Datesfat Chicks <datesfat.chicks@gmail.com> - 2011-05-15 10:58 -0400
      Re: boolean usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-15 08:12 -0700
      Re: boolean usage Keith Thompson <kst-u@mib.org> - 2011-05-16 08:09 -0700
        Re: boolean usage Datesfat Chicks <datesfat.chicks@gmail.com> - 2011-05-16 19:44 -0400
          Re: boolean usage Keith Thompson <kst-u@mib.org> - 2011-05-16 17:46 -0700
            Re: boolean usage Datesfat Chicks <datesfat.chicks@gmail.com> - 2011-05-16 22:45 -0400
    Re: boolean usage Peter Nilsson <airia@acay.com.au> - 2011-05-16 18:23 -0700
      Re: boolean usage Jens <jens.gustedt@gmail.com> - 2011-05-16 23:37 -0700
        Re: boolean usage James Kuyper <jameskuyper@verizon.net> - 2011-05-17 06:39 -0400
          Re: boolean usage "Morris Keesan" <mkeesan@post.harvard.edu> - 2011-05-17 09:55 -0400
            Re: boolean usage James Kuyper <jameskuyper@verizon.net> - 2011-05-17 21:17 -0400
        Re: boolean usage Peter Nilsson <airia@acay.com.au> - 2011-05-17 16:50 -0700
          Re: boolean usage Jens <jens.gustedt@gmail.com> - 2011-05-18 09:21 -0700
            Re: boolean usage Peter Nilsson <airia@acay.com.au> - 2011-05-18 15:36 -0700
              Re: boolean usage Jens <jens.gustedt@gmail.com> - 2011-05-19 00:20 -0700
                Re: boolean usage Ralf Damaschke <rwspam@gmx.de> - 2011-05-19 09:04 +0000
              Re: boolean usage Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-19 01:13 -0700
                Re: boolean usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-19 03:29 -0700
                Re: boolean usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 11:41 +0100
                  Re: boolean usage Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-19 11:24 -0700
                    Re: boolean usage Keith Thompson <kst-u@mib.org> - 2011-05-19 11:55 -0700
                      Re: boolean usage Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-19 14:40 -0700
                        Re: boolean usage Keith Thompson <kst-u@mib.org> - 2011-05-19 15:48 -0700
                          Re: boolean usage Peter Nilsson <airia@acay.com.au> - 2011-05-23 18:26 -0700
                            Re: boolean usage Peter Nilsson <airia@acay.com.au> - 2011-05-23 18:29 -0700
                          Re: boolean usage Peter Nilsson <airia@acay.com.au> - 2011-05-23 18:27 -0700
                            Re: boolean usage Keith Thompson <kst-u@mib.org> - 2011-05-24 00:11 -0700
                            Re: boolean usage Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-24 00:48 -0700
                              Re: boolean usage Keith Thompson <kst-u@mib.org> - 2011-05-24 09:16 -0700
                                Re: boolean usage Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-24 10:10 -0700
                                  Re: boolean usage Keith Thompson <kst-u@mib.org> - 2011-05-24 10:48 -0700
                                    Re: boolean usage Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-25 10:18 -0700
                      Re: boolean usage gazelle@shell.xmission.com (Kenny McCormack) - 2011-05-19 21:53 +0000
                        Re: boolean usage Michael Press <rubrum@pacbell.net> - 2011-05-25 11:22 -0700
                          Re: boolean usage Kenneth Brody <kenbrody@spamcop.net> - 2011-05-25 16:10 -0400
                            Re: boolean usage Michael Press <rubrum@pacbell.net> - 2011-05-26 12:32 -0700
                    Re: boolean usage Peter Nilsson <airia@acay.com.au> - 2011-05-19 22:39 -0700
                      Re: boolean usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-20 12:57 +0100
                        Re: boolean usage Peter Nilsson <airia@acay.com.au> - 2011-05-22 17:52 -0700
                          Re: boolean usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-23 13:15 +0100
                          Re: boolean usage Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-24 00:57 -0700
                      Re: boolean usage Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-24 01:38 -0700
                        Re: boolean usage Keith Thompson <kst-u@mib.org> - 2011-05-24 09:20 -0700
                          Re: boolean usage Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-24 11:00 -0700

Page 1 of 3  [1] 2 3  Next page →

#3980 — boolean usage

Hi,
I am developing a little library and I would like to develop it so
that it will be conforming both to the old and the new (c99) standard.
I have a function returning a boolean value, so I think that something
like:

file.h:

#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
#define bool int
#endif

/* rest of the header */

bool my_func (void);

file.c:

#if __STDC_VERSION__ >= 199901L
#define false 0
#define true (!false)
#endif

should be. But bool could be defined even in user code.
What's the proper way to handle this kind of things?

[toc] | [next] | [standalone]

#3989

"dr.oktopus" <blindwilly@freeonline.zzn.com> writes:
> I am developing a little library and I would like to develop it so
> that it will be conforming both to the old and the new (c99) standard.
> I have a function returning a boolean value, so I think that something
> like:
>
> file.h:
>
> #if __STDC_VERSION__ >= 199901L
> #include <stdbool.h>
> #else
> #define bool int
> #endif
>
> /* rest of the header */
>
> bool my_func (void);
>
> file.c:
>
> #if __STDC_VERSION__ >= 199901L
> #define false 0
> #define true (!false)
> #endif
>
> should be. But bool could be defined even in user code.
> What's the proper way to handle this kind of things?

Well, code that doesn't use _Bool or <stdbool.h> can still conform to
both C90 and C99 (the C committee carefully designed it that way).  But
if you want to use <stdbool.h> if it's available, perhaps with the goal
of dropping pre-C99 support eventually, there are several ways to do it.

The first thing I recommend reading is section 9 of the comp.lang.c FAQ,
<http://c-faq.com/>.

I'd probably use typedef rather than #define for the bool type, but
that's a fairly minor point.

I'm not sure why you define "bool" in file.h and "true" and "false" in
file.c.  And there's no point in defining true as (!false); 1 and 0 are
clear enough.

Here's how I might do it:

#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif

The enum isn't *exactly* equivalent to C99's _Bool/bool, but it's not
hard to restrict your usage to cases where it's close enough.

On the other hand, as you say, the names "bool", "false", and "true"
might be defined in some other header and your own names could conflict
with them.  In that case, you can pick a unique prefix and do something
like:

#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#define FOO_bool bool
#define FOO_false false
#define FOO_true true
#else
typedef enum { FOO_false, FOO_true } FOO_bool;
#endif

That's quite ugly; you'll have to decide whether it's worth it.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#3995

Keith Thompson <kst-u@mib.org> writes:

> "dr.oktopus" <blindwilly@freeonline.zzn.com> writes:
>> I am developing a little library and I would like to develop it so
>> that it will be conforming both to the old and the new (c99) standard.
>> I have a function returning a boolean value, so I think that something
>> like:
>>
>> file.h:
>>
>> #if __STDC_VERSION__ >= 199901L
>> #include <stdbool.h>
>> #else
>> #define bool int
>> #endif
<snip>
> I'd probably use typedef rather than #define for the bool type, but
> that's a fairly minor point.

I think a typedef is neater (in some vague aesthetic way) but a macro
has the advantage that a program that uses the library and also defines
its own bool can suppress it's own definition if need be.  You might
even be lucky and not have to do anything if the definitions are the
same.  That option won't be available with a typedef in the library's
header file.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#3998

errata corrige

>
> file.c:
>
> #if __STDC_VERSION__ < 199901L
> #define false 0
> #define true (!false)
> #endif
>

[toc] | [prev] | [next] | [standalone]

#3999

On May 15, 12:05 am, "dr.oktopus" <blindwi...@freeonline.zzn.com>
wrote:
>  But bool could be defined even in user code.
> What's the proper way to handle this kind of things?
>
Bool breaks libraries. Just return an int, to be on the safe side.

[toc] | [prev] | [next] | [standalone]

#4405

Malcolm McLean wrote:

> Bool breaks libraries. Just return an int, to be on the safe side.

    Do you mean not even use this header or don't use true just 1 and not 
false just 0?

Bill

[toc] | [prev] | [next] | [standalone]

#4422

On May 20, 4:29 am, "Bill Cunningham" <nos...@nspam.invalid> wrote:
> Malcolm McLean wrote:
> > Bool breaks libraries. Just return an int, to be on the safe side.
>
>     Do you mean not even use this header or don't use true just 1 and not
> false just 0?
>
Yes, don't even include stdbool.h.

If you want to return a boolean, return an int, if you want to pass
one, pass as an int. If you need to pass or return several booleans,
pack them into an int.

Compare explictly to zero or non-zero.

It's not ideal, but it's the best you can do with the language as it
is. The alternative is that you get bools and Bools and bool_ts, and
that becomes confusing.

[toc] | [prev] | [next] | [standalone]

#4435

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On May 20, 4:29 am, "Bill Cunningham" <nos...@nspam.invalid> wrote:
>> Malcolm McLean wrote:
>> > Bool breaks libraries. Just return an int, to be on the safe side.
>>
>>     Do you mean not even use this header or don't use true just 1 and not
>> false just 0?
>>
> Yes, don't even include stdbool.h.
>
> If you want to return a boolean, return an int, if you want to pass
> one, pass as an int. If you need to pass or return several booleans,
> pack them into an int.
>
> Compare explictly to zero or non-zero.
>
> It's not ideal, but it's the best you can do with the language as it
> is. The alternative is that you get bools and Bools and bool_ts, and
> that becomes confusing.

You should be aware that Malcolm's advice is, to say, the least,
controversial

Another approach is this: If you know your code will only be used
with C99 compilers, go ahead and use <stdbool.h>, bool, false,
and true whenever they're appropriate.

There is some risk to this approach.  Since the identifiers
"bool", "false", and "true were not reserved in C90, there could
be libraries that use them, and you could run into conflicts if
you use <stdbool.h> and such a library in the same source file.
(Note that such libraries are already incompatible with C++, in
which bool, false, and true are keywords.)

Another issue is that many libraries define their own Boolean-like
types, with various names such as BOOL, Boolean, TBool, and so forth.
Interoperability between libraries that define their own potentially
incompatible Boolean-like types can be a problem, but I don't think
it's an argument for int over _Bool/bool.  C99 introduced _Bool
and bool specifically to clean up this mess.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#4439

In article <ln7h9l1h3j.fsf@nuthaus.mib.org>,
Keith Thompson  <kst-u@mib.org> wrote:
...
>(Note that such libraries are already incompatible with C++, in
>which bool, false, and true are keywords.)

But of course, as you and your friends like to point out at every possible
opportunity, that is, in this newsgroup, as irrelevant as would be any
incompatibility with COBOL.

-- 
One of the best lines I've heard lately:

    Obama could cure cancer tomorrow, and the Republicans would be
    complaining that he had ruined the pharmaceutical business.

(Heard on Stephanie Miller = but the sad thing is that there is an awful lot
of direct truth in it.  We've constructed an economy in which eliminating
cancer would be a horrible disaster.  There are many other such examples.)

[toc] | [prev] | [next] | [standalone]

#4019

On Sat, 14 May 2011 14:05:43 -0700 (PDT), "dr.oktopus"
<blindwilly@freeonline.zzn.com> wrote:

>Hi,
>I am developing a little library and I would like to develop it so
>that it will be conforming both to the old and the new (c99) standard.
>I have a function returning a boolean value, so I think that something
>like:
>
>file.h:
>
>#if __STDC_VERSION__ >= 199901L
>#include <stdbool.h>
>#else
>#define bool int
>#endif
>
>/* rest of the header */
>
>bool my_func (void);
>
>file.c:
>
>#if __STDC_VERSION__ >= 199901L
>#define false 0
>#define true (!false)
>#endif
>
>should be. But bool could be defined even in user code.
>What's the proper way to handle this kind of things?

I do embedded work with small micros (2K of RAM is a high-end part for
me), so every bit has to count.

I typically use _Bool_ or _Boolean_ (forget what the right keyword
is).  Anyway, that does a few neat things in the development tools:

a)It causes the linker to manage RAM at the bit level (rather than the
byte level).  So you can link a bunch of modules together each with
_Bool_'s, and variables from different modules are actually often in
the same byte.  No RAM wasted!  The tools pack the bits.

b)The little microcontrollers typically have instructions to set,
clear, and test bits of RAM economically, so it is pretty efficient.
It is rare to find a micro where something like this is requied:

   ld  a, whatever
   or a, #64
   ld whatever, a

Most little micros can do that in one instruction--a RMW sequence such
as I demonstrated above is rare.

All that being said ...

I really don't see a compelling need for Boolean variables in most
programs written for larger machines, except in the cases where there
are arrays of them and it would be a huge RAM waste (and then you'd
want to have an array of integers and mask bits in and out).

In most cases with larger machines, an "int" is just fine as a
Boolean.  Wasting 31 or 63 bits is a non-issue.

The only thing I'd caution you to do is that if you're going to agree
that a variable is Boolean, it has two equivalence classes:

a)0 = FALSE

b)Everything else is TRUE.

So, don't do this in the code:

  if (variable == TRUE)

If you do that, then there are a large number of values that are
neither TRUE nor FALSE.

Use "(variable)" and "(!variable)" instead.

And of course use || and &&.

I just don't see a need for _Bool_ in most large programs.

"int" is just fine.

DFC

[toc] | [prev] | [next] | [standalone]

#4020

On May 15, 5:58 pm, Datesfat Chicks <datesfat.chi...@gmail.com> wrote:
>
> I just don't see a need for _Bool_ in most large programs.
>
> "int" is just fine.
>
It documents what the variable is.

void circle(int x, int y, int r, bool fill)

is obvious how to use, int fill might be passing an option from a menu
of fill patterns.

[toc] | [prev] | [next] | [standalone]

#4074

Datesfat Chicks <datesfat.chicks@gmail.com> writes:
[...]
> I do embedded work with small micros (2K of RAM is a high-end part for
> me), so every bit has to count.
>
> I typically use _Bool_ or _Boolean_ (forget what the right keyword
> is).  Anyway, that does a few neat things in the development tools:
>
> a)It causes the linker to manage RAM at the bit level (rather than the
> byte level).  So you can link a bunch of modules together each with
> _Bool_'s, and variables from different modules are actually often in
> the same byte.  No RAM wasted!  The tools pack the bits.
[...]

Either your tools are generating C code that emulates 1-bit objects
using either bit fields or bitwise operations, or your C compiler
is non-conforming.  In standard C, if you apply sizeof to an object,
type, or expression of any type, the result is at least 1 byte,
which is at least 8 bits.  (sizeof can't be applied to bit fields.)

This is just an observation; I don't suggest that there's anything
wrong with a non-conforming implementation.  But I don't think your
situation is an argument for or against using _Bool in standard C.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#4134

On Mon, 16 May 2011 08:09:39 -0700, Keith Thompson <kst-u@mib.org>
wrote:

>Datesfat Chicks <datesfat.chicks@gmail.com> writes:
>[...]
>> I do embedded work with small micros (2K of RAM is a high-end part for
>> me), so every bit has to count.
>>
>> I typically use _Bool_ or _Boolean_ (forget what the right keyword
>> is).  Anyway, that does a few neat things in the development tools:
>>
>> a)It causes the linker to manage RAM at the bit level (rather than the
>> byte level).  So you can link a bunch of modules together each with
>> _Bool_'s, and variables from different modules are actually often in
>> the same byte.  No RAM wasted!  The tools pack the bits.
>[...]
>
>Either your tools are generating C code that emulates 1-bit objects
>using either bit fields or bitwise operations, or your C compiler
>is non-conforming.  In standard C, if you apply sizeof to an object,
>type, or expression of any type, the result is at least 1 byte,
>which is at least 8 bits.  (sizeof can't be applied to bit fields.)

Interesting discussion.  I wasn't aware it was non-comforming.

I consider it a gift from The Heavens.  Every one of those variables
saves 7 bits of RAM!

>This is just an observation; I don't suggest that there's anything
>wrong with a non-conforming implementation.  But I don't think your
>situation is an argument for or against using _Bool in standard C.

DFC

[toc] | [prev] | [next] | [standalone]

#4136

Datesfat Chicks <datesfat.chicks@gmail.com> writes:
> On Mon, 16 May 2011 08:09:39 -0700, Keith Thompson <kst-u@mib.org>
> wrote:
[...]
>>Either your tools are generating C code that emulates 1-bit objects
>>using either bit fields or bitwise operations, or your C compiler
>>is non-conforming.  In standard C, if you apply sizeof to an object,
>>type, or expression of any type, the result is at least 1 byte,
>>which is at least 8 bits.  (sizeof can't be applied to bit fields.)
>
> Interesting discussion.  I wasn't aware it was non-comforming.
>
> I consider it a gift from The Heavens.  Every one of those variables
> saves 7 bits of RAM!
[...]

In some environments, the 7 bits of RAM saved for each Boolean
stored in 1 bit rather than 8 would be more than wiped out by the
increase in the size of the code needed to access it.

The tradeoff could well be different in your environment, either if
no extra machine code is needed to access single bits (depends on
the CPU, or if space for variables is in much shorter supply than
code space (ROM?).

For large arrays of booleans, of course, it's a different story.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#4146

On Mon, 16 May 2011 17:46:48 -0700, Keith Thompson <kst-u@mib.org>
wrote:
>>
>> I consider it a gift from The Heavens.  Every one of those variables
>> saves 7 bits of RAM!
>[...]
>
>In some environments, the 7 bits of RAM saved for each Boolean
>stored in 1 bit rather than 8 would be more than wiped out by the
>increase in the size of the code needed to access it.
>
>The tradeoff could well be different in your environment, either if
>no extra machine code is needed to access single bits (depends on
>the CPU, or if space for variables is in much shorter supply than
>code space (ROM?).
>
>For large arrays of booleans, of course, it's a different story.

Speaking in terms of general tendencies, most little microcontrollers
have RAM from address 0 up through some maximum.

Many originally had CPUs that would address RAM up through location
255 only, and no part had more than maybe 128 bytes of RAM.

As it became possible to make parts with more than 255 bytes of RAM,
instruction sets were expanded.  Many microcontrollers (because they
tried to ensure backward compatibility) ended up with lots of
instructions that will access memory locations up through 255 and far
fewer instructions that will access memory locations beyond 255.

So, a "typical" microcontroller has instructions that will set, clear,
and test single bits in RAM (in a single instruction) so long as the
RAM is in location 255 or below.

However, manipulating bits in RAM locations beyond 255 is typically
three instructions rather than one.  It usually ends up to be a "new"
instruction to fetch the data from an address >255 into the
accumulator, an "old" instruction to manipulate the accumulator, and a
"new" instruction to store the data back into and address >255.

The history of the instruction sets in many cases leads directly to a
RMW series of instructions when RAM with addresses >255 are involved.

So it usually works out well so long as linker is instructed to try to
locate these bitfields in "low" memory locations, which can usually be
done.

However, microcontroller CPU cores without legacy products to support
tend to have far better instruction sets.  These tend to have
instructions to manipulate bits in addresses >255 and also to deal
well with stack-relative addressing (i.e. storage class automatic).
These CPUs were designed from the ground up to support C compilers,
and they are far superior to the "expanded" instruction sets.

DFC

[toc] | [prev] | [next] | [standalone]

#4141

"dr.oktopus" <blindwi...@freeonline.zzn.com> wrote:
> Hi,
> I am developing a little library and I would like to develop
> it so that it will be conforming both to the old and the new
> (c99) standard. I have a function returning a boolean value,
> so I think that something like:
>
> file.h:
>
> #if __STDC_VERSION__ >= 199901L
> #include <stdbool.h>
> #else
> #define bool int

I prefer...

  typedef unsigned bool;

...since _Bool is an unsigned integer type and should work
as expected in a bitfield of width 1.

--
Peter

[toc] | [prev] | [next] | [standalone]

#4155

On 17 Mai, 03:23, Peter Nilsson <ai...@acay.com.au> wrote:
> I prefer...
>
>   typedef unsigned bool;

I think typedef is not a good idea, simply because in C99 it is a
macro and nothing else. I'd just use

#define bool int
#define false 1
#define true 0

Use int as a replacement type for _Bool, since any expression where
you use _Bool that expects an integer type will promote _Bool to int,
anyhow.

Jens

[toc] | [prev] | [next] | [standalone]

#4157

On 05/17/2011 02:37 AM, Jens wrote:
...
> I think typedef is not a good idea, simply because in C99 it is a
> macro and nothing else. ...

#define PINT int *
typedef int *pint;

const PINT a;
PINT const b;
const pint c;
pint const d;

Tell me which of the above variables have the same type? If you think
that typedef is "a macro and nothing else", you'll probably get one of
them wrong.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#4159

On Tue, 17 May 2011 06:39:57 -0400, James Kuyper <jameskuyper@verizon.net>  
wrote:

> On 05/17/2011 02:37 AM, Jens wrote:
> ...
>> I think typedef is not a good idea, simply because in C99 it is a
>> macro and nothing else. ...
>
> #define PINT int *
> typedef int *pint;
>
> const PINT a;
> PINT const b;
> const pint c;
> pint const d;
>
> Tell me which of the above variables have the same type? If you think
> that typedef is "a macro and nothing else", you'll probably get one of
> them wrong.

You deleted too much of Jens's post.  I think his point (which took a  
second
reading, for me) is not that typedef is a macro, but that typedef'ing
bool is a bad idea, because in C99 it (bool) is a macro.

-- 
Morris Keesan -- mkeesan@post.harvard.edu

[toc] | [prev] | [next] | [standalone]

#4204

On 05/17/2011 09:55 AM, Morris Keesan wrote:
> On Tue, 17 May 2011 06:39:57 -0400, James Kuyper <jameskuyper@verizon.net>  
> wrote:
> 
>> On 05/17/2011 02:37 AM, Jens wrote:
>> ...
>>> I think typedef is not a good idea, simply because in C99 it is a
>>> macro and nothing else. ...
>>
>> #define PINT int *
>> typedef int *pint;
>>
>> const PINT a;
>> PINT const b;
>> const pint c;
>> pint const d;
>>
>> Tell me which of the above variables have the same type? If you think
>> that typedef is "a macro and nothing else", you'll probably get one of
>> them wrong.
> 
> You deleted too much of Jens's post.  I think his point (which took a  
> second
> reading, for me) is not that typedef is a macro, but that typedef'ing
> bool is a bad idea, because in C99 it (bool) is a macro.

Yes, that was his point, and I had nothing to say about his point.

I did have something to say about a side-issue he raised. That's
precisely why I deleted everything except the side-issue.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web