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

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

Why _Bool was not defined as enum in C99?

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

Contents

  Why _Bool was not defined as enum in C99? thiago.adams@gmail.com - 2016-09-12 13:24 -0700
    Re: Why _Bool was not defined as enum in C99? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-12 21:56 +0100
      Re: Why _Bool was not defined as enum in C99? Keith Thompson <kst-u@mib.org> - 2016-09-12 15:59 -0700
      Re: Why _Bool was not defined as enum in C99? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-13 16:05 -0700
        Re: Why _Bool was not defined as enum in C99? Keith Thompson <kst-u@mib.org> - 2016-09-13 18:17 -0700
          Re: Why _Bool was not defined as enum in C99? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-14 01:20 +0100
          Re: Why _Bool was not defined as enum in C99? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-14 03:59 -0700
          Re: Why _Bool was not defined as enum in C99? Nobody <nobody@nowhere.invalid> - 2016-09-14 17:31 +0100
            Re: Why _Bool was not defined as enum in C99? Thiago Adams <thiago.adams@gmail.com> - 2016-09-14 09:49 -0700
              Re: Why _Bool was not defined as enum in C99? Keith Thompson <kst-u@mib.org> - 2016-09-14 11:45 -0700
          Re: Why _Bool was not defined as enum in C99? <william@wilbur.25thandClement.com> - 2016-09-14 14:13 -0700
            Re: Why _Bool was not defined as enum in C99? Keith Thompson <kst-u@mib.org> - 2016-09-14 16:26 -0700
    Re: Why _Bool was not defined as enum in C99? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-12 17:11 -0400
    Re: Why _Bool was not defined as enum in C99? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-13 15:55 -0700
      Re: Why _Bool was not defined as enum in C99? Keith Thompson <kst-u@mib.org> - 2016-09-13 18:08 -0700
        Re: Why _Bool was not defined as enum in C99? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-14 03:56 -0700
          Re: Why _Bool was not defined as enum in C99? supercat@casperkitty.com - 2016-09-14 07:58 -0700
            Re: Why _Bool was not defined as enum in C99? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-14 19:39 +0100
              Re: Why _Bool was not defined as enum in C99? Keith Thompson <kst-u@mib.org> - 2016-09-14 13:52 -0700
                Re: Why _Bool was not defined as enum in C99? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-15 00:53 +0100
                  Re: Why _Bool was not defined as enum in C99? supercat@casperkitty.com - 2016-09-14 17:04 -0700
                    Re: Why _Bool was not defined as enum in C99? Keith Thompson <kst-u@mib.org> - 2016-09-14 20:52 -0700
                      Re: Why _Bool was not defined as enum in C99? supercat@casperkitty.com - 2016-09-14 19:26 -0700
                  Re: Why _Bool was not defined as enum in C99? Keith Thompson <kst-u@mib.org> - 2016-09-14 19:04 -0700
              Re: Why _Bool was not defined as enum in C99? supercat@casperkitty.com - 2016-09-14 14:21 -0700
                Re: Why _Bool was not defined as enum in C99? Keith Thompson <kst-u@mib.org> - 2016-09-14 16:23 -0700
                  Re: Why _Bool was not defined as enum in C99? supercat@casperkitty.com - 2016-09-14 17:06 -0700
                    Re: Why _Bool was not defined as enum in C99? Keith Thompson <kst-u@mib.org> - 2016-09-14 20:45 -0700
                    Re: Why _Bool was not defined as enum in C99? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-14 22:12 -0400
                    Re: Why _Bool was not defined as enum in C99? David Brown <david.brown@hesbynett.no> - 2016-09-15 12:37 +0200
                      Re: Why _Bool was not defined as enum in C99? supercat@casperkitty.com - 2016-09-15 09:35 -0700
                        Re: Why _Bool was not defined as enum in C99? David Brown <david.brown@hesbynett.no> - 2016-09-16 00:47 +0200
                          Re: Why _Bool was not defined as enum in C99? supercat@casperkitty.com - 2016-09-15 22:02 -0700
                            Re: Why _Bool was not defined as enum in C99? David Brown <david.brown@hesbynett.no> - 2016-09-16 09:56 +0200
                              Re: Why _Bool was not defined as enum in C99? supercat@casperkitty.com - 2016-09-16 07:34 -0700
                                Re: Why _Bool was not defined as enum in C99? David Brown <david.brown@hesbynett.no> - 2016-09-16 20:31 +0200
                                  Re: Why _Bool was not defined as enum in C99? supercat@casperkitty.com - 2016-09-16 12:32 -0700
                                    Re: Why _Bool was not defined as enum in C99? David Brown <david.brown@hesbynett.no> - 2016-09-17 23:30 +0200
                      Re: Why _Bool was not defined as enum in C99? BartC <bc@freeuk.com> - 2016-09-15 18:25 +0100
                        Re: Why _Bool was not defined as enum in C99? luser droog <luser.droog@gmail.com> - 2016-09-15 12:35 -0700
                          Re: Why _Bool was not defined as enum in C99? David Brown <david.brown@hesbynett.no> - 2016-09-16 00:51 +0200
                            Re: Why _Bool was not defined as enum in C99? luser droog <luser.droog@gmail.com> - 2016-09-16 17:02 -0700
                              Re: Why _Bool was not defined as enum in C99? Keith Thompson <kst-u@mib.org> - 2016-09-16 19:23 -0700
                              Re: Why _Bool was not defined as enum in C99? David Brown <david.brown@hesbynett.no> - 2016-09-17 23:35 +0200
          Re: Why _Bool was not defined as enum in C99? Keith Thompson <kst-u@mib.org> - 2016-09-14 10:40 -0700
            Re: Why _Bool was not defined as enum in C99? Thiago Adams <thiago.adams@gmail.com> - 2016-09-14 10:01 -0700
              Re: Why _Bool was not defined as enum in C99? supercat@casperkitty.com - 2016-09-14 11:35 -0700
                Re: Why _Bool was not defined as enum in C99? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-14 22:15 -0400
                  Re: Why _Bool was not defined as enum in C99? supercat@casperkitty.com - 2016-09-14 23:51 -0700
                    Re: Why _Bool was not defined as enum in C99? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-15 15:14 -0400
                Re: Why _Bool was not defined as enum in C99? Ian Collins <ian-news@hotmail.com> - 2016-09-15 16:08 +1200
                  Re: Why _Bool was not defined as enum in C99? David Brown <david.brown@hesbynett.no> - 2016-09-15 12:46 +0200
                    Re: Why _Bool was not defined as enum in C99? supercat@casperkitty.com - 2016-09-15 09:37 -0700
                      Re: Why _Bool was not defined as enum in C99? David Brown <david.brown@hesbynett.no> - 2016-09-16 00:53 +0200
                        Re: Why _Bool was not defined as enum in C99? supercat@casperkitty.com - 2016-09-15 21:45 -0700
                          Re: Why _Bool was not defined as enum in C99? Richard Heathfield <rjh@cpax.org.uk> - 2016-09-16 06:32 +0100
                            Re: Why _Bool was not defined as enum in C99? David Brown <david.brown@hesbynett.no> - 2016-09-16 09:59 +0200
                            Re: Why _Bool was not defined as enum in C99? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-16 11:00 +0100
                              Re: Why _Bool was not defined as enum in C99? Thiago Adams <thiago.adams@gmail.com> - 2016-09-16 04:46 -0700
                                Re: Why _Bool was not defined as enum in C99? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-16 12:58 +0100
                                  Re: Why _Bool was not defined as enum in C99? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-09-16 12:06 +0000
                                    Re: Why _Bool was not defined as enum in C99? Thiago Adams <thiago.adams@gmail.com> - 2016-09-16 05:13 -0700
                                    Re: Why _Bool was not defined as enum in C99? Keith Thompson <kst-u@mib.org> - 2016-09-16 10:47 -0700
                              Re: Why _Bool was not defined as enum in C99? Keith Thompson <kst-u@mib.org> - 2016-09-16 10:46 -0700
                          Re: Why _Bool was not defined as enum in C99? David Brown <david.brown@hesbynett.no> - 2016-09-16 10:02 +0200
                    Re: Why _Bool was not defined as enum in C99? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-15 11:42 -0700
                      Re: Why _Bool was not defined as enum in C99? David Brown <david.brown@hesbynett.no> - 2016-09-16 10:19 +0200
                        Re: Why _Bool was not defined as enum in C99? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-16 08:06 -0700
                          Re: Why _Bool was not defined as enum in C99? David Brown <david.brown@hesbynett.no> - 2016-09-16 20:51 +0200
                            Re: Why _Bool was not defined as enum in C99? Thiago Adams <thiago.adams@gmail.com> - 2016-09-16 11:56 -0700
                            Re: Why _Bool was not defined as enum in C99? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-22 22:38 -0700
            Re: Why _Bool was not defined as enum in C99? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-14 11:42 -0700
              Re: Why _Bool was not defined as enum in C99? Keith Thompson <kst-u@mib.org> - 2016-09-14 14:02 -0700
                Re: Why _Bool was not defined as enum in C99? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-15 10:51 -0700
                  Re: Why _Bool was not defined as enum in C99? supercat@casperkitty.com - 2016-09-15 11:18 -0700
                    Re: Why _Bool was not defined as enum in C99? Keith Thompson <kst-u@mib.org> - 2016-09-15 13:46 -0700
                      Re: Why _Bool was not defined as enum in C99? supercat@casperkitty.com - 2016-09-15 13:10 -0700
                        Re: Why _Bool was not defined as enum in C99? Keith Thompson <kst-u@mib.org> - 2016-09-15 16:01 -0700
                  Re: Why _Bool was not defined as enum in C99? Keith Thompson <kst-u@mib.org> - 2016-09-15 13:40 -0700
                    Re: Why _Bool was not defined as enum in C99? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-16 07:21 -0700
                      Re: Why _Bool was not defined as enum in C99? Thiago Adams <thiago.adams@gmail.com> - 2016-09-16 07:37 -0700
                        Re: Why _Bool was not defined as enum in C99? David Brown <david.brown@hesbynett.no> - 2016-09-16 20:55 +0200
                          Re: Why _Bool was not defined as enum in C99? Keith Thompson <kst-u@mib.org> - 2016-09-16 14:43 -0700
                            Re: Why _Bool was not defined as enum in C99? supercat@casperkitty.com - 2016-09-16 15:36 -0700
                            Re: Why _Bool was not defined as enum in C99? David Brown <david.brown@hesbynett.no> - 2016-09-17 23:45 +0200
                              Re: Why _Bool was not defined as enum in C99? Keith Thompson <kst-u@mib.org> - 2016-09-17 17:14 -0700

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#93615

On 2016-09-16, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
>
>> I found some explanation about bool in C++.
>> The book, "The design and evolution of C++", pag 254-255.
>>
>> "Naturally, the first idea was to define an enum. However, and
>> examination of hundreds of thousand of lines ..reveled that most
>> boolean types were used in ways that require free conversion from and
>> to int"
>
> Thanks for that, but it can't be the main reason C chose not to use an
> enum since, as I am sure you know, C has always permitted those
> conversions, whist C++ decided to forbid them (without a cast -- that's
> the "free conversion" part).
>

Hm, I am pretty sure that one can convert bool from/to int without cast in
C++...

-- 
press any key to continue or any other to quit

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

#93617

On Friday, September 16, 2016 at 9:06:24 AM UTC-3, Melzzzzz wrote:
> On 2016-09-16, Ben Bacarisse  wrote:
> > Thiago Adams writes:
> >
> >> I found some explanation about bool in C++.
> >> The book, "The design and evolution of C++", pag 254-255.
> >>
> >> "Naturally, the first idea was to define an enum. However, and
> >> examination of hundreds of thousand of lines ..reveled that most
> >> boolean types were used in ways that require free conversion from and
> >> to int"
> >
> > Thanks for that, but it can't be the main reason C chose not to use an
> > enum since, as I am sure you know, C has always permitted those
> > conversions, whist C++ decided to forbid them (without a cast -- that's
> > the "free conversion" part).
> >
> 
> Hm, I am pretty sure that one can convert bool from/to int without cast in
> C++...
> 
> -- 
> press any key to continue or any other to quit

C++ code:

enum BOOL { FALSE, TRUE } ;

int main()
{
   BOOL b2 = 0;  //error
   bool b3 = 0;  //ok
    
    int i = TRUE; //ok
    bool b4 = 2;  //ok
    
   return 0;
}

So, int to enum is not valid.

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

#93630

Melzzzzz <Melzzzzz@zzzzz.com> writes:
> On 2016-09-16, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Thiago Adams <thiago.adams@gmail.com> writes:
>>
>>> I found some explanation about bool in C++.
>>> The book, "The design and evolution of C++", pag 254-255.
>>>
>>> "Naturally, the first idea was to define an enum. However, and
>>> examination of hundreds of thousand of lines ..reveled that most
>>> boolean types were used in ways that require free conversion from and
>>> to int"
>>
>> Thanks for that, but it can't be the main reason C chose not to use an
>> enum since, as I am sure you know, C has always permitted those
>> conversions, whist C++ decided to forbid them (without a cast -- that's
>> the "free conversion" part).
>
> Hm, I am pretty sure that one can convert bool from/to int without cast in
> C++...

Of course -- because C++'s bool is not an enum.  That's exactly *why*
C++'s bool is not an enum.

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

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

#93629

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> A few, a very few, programmers like to use lots of casts because it
> looks all technical.  They may also removespacesbecauseCisafastlanguage
> and use vry shrt nms for the same rsn.  Ye shall know them by this sign:
>
>   #define ever (;;)
>
> (I was that programmer once.)

I defined something very similar myself when I was first learning C.

At the time, I thought it was very clever.

I still think it was very clever.  I just no longer think that's
a good thing.

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

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

#93605

On 16/09/16 06:45, supercat@casperkitty.com wrote:
> On Thursday, September 15, 2016 at 5:53:51 PM UTC-5, David Brown wrote:
>> On 15/09/16 18:37, supercat wrote:
>> I still don't understand why you think using a unary plus operator on a 
>> volatile is a useful thing to do, but okay.
> 
> In C++, from what I've read, the statement "+variableName;" [without quotes]
> is required to perform an rvalue conversion, but "variableName;" by itself
> has historically been forbidding from doing so.
> 

The common idiom is "(void) variableName;".  If you want to be /really/
careful, you might write "auto v = variableName; (void) v;".

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

#93557

David Brown <david.brown@hesbynett.no> writes:

> [...]
>
> And it is usually not hard to write code that is valid C, and valid C++,
> and not /too/ strange for either language.  [...]

I disagree.  This can be true for small examples or certain
limited contexts, but it is not true for any significant
body of code.

(I note that the original message went on to some particular
details, and those comments refine the general statement
above.  I'm not offering any comments on the details, and
may agree (or not) on some of those.  But as a general
blanket statement IMO the statement above is just wrong.)

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

#93606

On 15/09/16 20:42, Tim Rentsch wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
>> [...]
>>
>> And it is usually not hard to write code that is valid C, and valid C++,
>> and not /too/ strange for either language.  [...]
> 
> I disagree.  This can be true for small examples or certain
> limited contexts, but it is not true for any significant
> body of code.

Code like this will often look strange for C++ code, but that is
primarily because you are not using common features of C++ code
(classes, namespaces, templates, etc.), rather than because you are
using the common C/C++ subset in a strange way.  But IME it will seldom
look very strange when viewed as C code.

However, you don't normally have to write a lot of code that can be
compiled as C and C++ - usually it is restricted to headers.

I have had occasion to write code for customers which they wanted to be
both C and C++ compatible - it was not a difficult requirement, and it
did not lead to unusual or idiosyncratic code.

To be fair, when I have written such code, it has been in small (or
"resource constrained") embedded systems.  For example, casting void*
pointers before assignment was not an issue - they are very rare in such
code.  malloc() and friends are typically banned anyway.

> 
> (I note that the original message went on to some particular
> details, and those comments refine the general statement
> above.  I'm not offering any comments on the details, and
> may agree (or not) on some of those.  But as a general
> blanket statement IMO the statement above is just wrong.)
> 

Can you give an example (obviously a short one) of code written in
"C/C++" that you think would be particularly strange or unusual when
viewed as C code?

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

#93625

David Brown <david.brown@hesbynett.no> writes:

> On 15/09/16 20:42, Tim Rentsch wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> [...]
>>>
>>> And it is usually not hard to write code that is valid C, and valid C++,
>>> and not /too/ strange for either language.  [...]
>>
>> I disagree.  This can be true for small examples or certain
>> limited contexts, but it is not true for any significant
>> body of code.
>
> Code like this will often look strange for C++ code, but that is
> primarily because you are not using common features of C++ code
> (classes, namespaces, templates, etc.), rather than because you are
> using the common C/C++ subset in a strange way.  But IME it will seldom
> look very strange when viewed as C code.
>
> However, you don't normally have to write a lot of code that can be
> compiled as C and C++ - usually it is restricted to headers.

My comment was meant in the context of writing .c files, not only
function headers.  If all one is writing is function prototypes
then it is pretty easy to write code in the intersection of C and
C++.  My comment though was meant more generally, since what the
OP is asking about encompasses source code at the .c level, not
only headers.

> I have had occasion to write code for customers which they wanted to be
> both C and C++ compatible - it was not a difficult requirement, and it
> did not lead to unusual or idiosyncratic code.

It is possible to write C code that is also C++ code in much the
same way that it is possible to write English prose that doesn't
have any "j"'s in it.  It may even look perfectly ordinary -
consider as an example my last paragraph.  However it is extra
effort to do so:  while writing this paragraph I had to go back
and change two occurrences of "just" to "only" so there wouldn't
be any "j"'s.  And the result of that change is that it reads
(IMO) a little worse than the original.  There is an analogous
effect with code in the C/C++ intersection, except there I think
it's worse than simply leaving out "j"'s in English.

> To be fair, when I have written such code, it has been in small (or
> "resource constrained") embedded systems.  For example, casting void*
> pointers before assignment was not an issue - they are very rare in such
> code.  malloc() and friends are typically banned anyway.

I imagine there were other consequences as well, but I won't
ask about those since it's tangential to the area I mean
to address.

>> (I note that the original message went on to some particular
>> details, and those comments refine the general statement
>> above.  I'm not offering any comments on the details, and
>> may agree (or not) on some of those.  But as a general
>> blanket statement IMO the statement above is just wrong.)
>
> Can you give an example (obviously a short one) of code written in
> "C/C++" that you think would be particularly strange or unusual when
> viewed as C code?

I wrote a short example (which I will describe but not post) of a
way to do runtime polymorphism for this very thread.  After I had
written it I realized it wasn't suitable for the OP's needs (or
at least what were thought to be needs) because my C code would
not compile as C++.  The .h file, that was no problem.  The .c
file, blammo!  Roughly 30% of the lines had incompatibilities.
These fell into three categories:  void *, compound literals, and
designated initializers.  (It's possible there were other
problems but those are the ones I remember.)  Now of course it
is possible to work around all of these, but it's a big pain in
the you-know-where.  For me it is simply above threshold, like
trying to write in C90 again - it isn't that I can't do it, but
it's not natural, and certainly isn't merely a minor adjustment.

By the way, I tried to write the text new in this posting
without any "j"'s, but one crept in there right at the end
in "adjustment" (and after I had already changed a "just" to
"merely"... oh well).  :)

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

#93652

On 16/09/16 17:06, Tim Rentsch wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 15/09/16 20:42, Tim Rentsch wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> [...]
>>>>
>>>> And it is usually not hard to write code that is valid C, and valid C++,
>>>> and not /too/ strange for either language.  [...]
>>>
>>> I disagree.  This can be true for small examples or certain
>>> limited contexts, but it is not true for any significant
>>> body of code.
>>
>> Code like this will often look strange for C++ code, but that is
>> primarily because you are not using common features of C++ code
>> (classes, namespaces, templates, etc.), rather than because you are
>> using the common C/C++ subset in a strange way.  But IME it will seldom
>> look very strange when viewed as C code.
>>
>> However, you don't normally have to write a lot of code that can be
>> compiled as C and C++ - usually it is restricted to headers.
>
> My comment was meant in the context of writing .c files, not only
> function headers.  If all one is writing is function prototypes
> then it is pretty easy to write code in the intersection of C and
> C++.  My comment though was meant more generally, since what the
> OP is asking about encompasses source code at the .c level, not
> only headers.
>
>> I have had occasion to write code for customers which they wanted to be
>> both C and C++ compatible - it was not a difficult requirement, and it
>> did not lead to unusual or idiosyncratic code.
>
> It is possible to write C code that is also C++ code in much the
> same way that it is possible to write English prose that doesn't
> have any "j"'s in it.  It may even look perfectly ordinary -
> consider as an example my last paragraph.  However it is extra
> effort to do so:  while writing this paragraph I had to go back
> and change two occurrences of "just" to "only" so there wouldn't
> be any "j"'s.  And the result of that change is that it reads
> (IMO) a little worse than the original.  There is an analogous
> effect with code in the C/C++ intersection, except there I think
> it's worse than simply leaving out "j"'s in English.
>
>> To be fair, when I have written such code, it has been in small (or
>> "resource constrained") embedded systems.  For example, casting void*
>> pointers before assignment was not an issue - they are very rare in such
>> code.  malloc() and friends are typically banned anyway.
>
> I imagine there were other consequences as well, but I won't
> ask about those since it's tangential to the area I mean
> to address.
>
>>> (I note that the original message went on to some particular
>>> details, and those comments refine the general statement
>>> above.  I'm not offering any comments on the details, and
>>> may agree (or not) on some of those.  But as a general
>>> blanket statement IMO the statement above is just wrong.)
>>
>> Can you give an example (obviously a short one) of code written in
>> "C/C++" that you think would be particularly strange or unusual when
>> viewed as C code?
>
> I wrote a short example (which I will describe but not post) of a
> way to do runtime polymorphism for this very thread.  After I had
> written it I realized it wasn't suitable for the OP's needs (or
> at least what were thought to be needs) because my C code would
> not compile as C++.  The .h file, that was no problem.  The .c
> file, blammo!  Roughly 30% of the lines had incompatibilities.
> These fell into three categories:  void *, compound literals, and
> designated initializers.  (It's possible there were other
> problems but those are the ones I remember.)  Now of course it
> is possible to work around all of these, but it's a big pain in
> the you-know-where.  For me it is simply above threshold, like
> trying to write in C90 again - it isn't that I can't do it, but
> it's not natural, and certainly isn't merely a minor adjustment.
>

I think it is a shame that compound literals and designated initializers 
are not valid in C++.  However, I think it must be highly unusual to 
have such a large proportion of your C code using those features - it is 
perhaps just the luck of this particular programming task.  For my own 
part, I used these features occasionally - but not nearly so much that 
it would be a noticeable issue.  (Also, I might cheat a little in this 
case - the C++ compilers I use would accept compound literals as an 
extension.)

I know that the way you and I write our C code is noticeably different - 
there are a number of features that we use in different proportions. 
Perhaps I can simply say that when /I/ write C code, there is little 
difference if it is written to be C++ compatible, but that this may not 
apply to everyone's C code, and it may not apply to equally to all types 
of C code or all programming tasks.

As another point, however, for people programming C on Windows it is 
quite popular to use MSVC in C++ mode to compiler their C.  Such 
developers seem to manage fine, and don't find the compatibility issues 
limiting.

> By the way, I tried to write the text new in this posting
> without any "j"'s, but one crept in there right at the end
> in "adjustment" (and after I had already changed a "just" to
> "merely"... oh well).  :)
>

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

#93654

On Friday, September 16, 2016 at 3:51:11 PM UTC-3, David Brown wrote:

> As another point, however, for people programming C on Windows it is 
> quite popular to use MSVC in C++ mode to compiler their C.  Such 
> developers seem to manage fine, and don't find the compatibility issues 
> limiting.
> 

That's my case. Today I discover that VS also can run clang for desktop.
Just select "Platform ToolSet"= "Visual Studio 2015 - Clang with Microsoft CodeGen (v140_clang_c2)"
The debugger works.

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

#93925

David Brown <david.brown@hesbynett.no> writes:

> [...] Perhaps I can simply say that when /I/ write C code,
> there is little difference if it is written to be C++ compatible,

That may very well be true.

> but
> that this may not apply to everyone's C code, and it may not apply to
> equally to all types of C code or all programming tasks.

And this is in essence what I was saying in response.

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

#93470

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

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>> thiago.adams@gmail.com writes:
>>>>
>>>>> Does anyone knows if an enumeration was considered to implement _Bool?
>>>>
>>>> It wouldn't make sense to implement _Bool as an enumeration,
>>>> because by there aren't any enumeration constants that go
>>>> with it.
>>>
>>> Surely if _Bool were an enumerated type, false and true would be
>>> enumeration constants.
>>
>> The point is that isn't a good fit for the existing semantics
>> of _Bool.  Part of the reason that _Bool is an integer type is
>> that it is important that "false" be 0 and "not false" be 1
>> (ie, important in the sense that it is an essential aspect of
>> the semantics of _Bool).  Normally enumeration constants are
>> used when one wants to decouple the name of a constant and its
>> value.  A key element of _Bool, as it is defined in C, and in
>> contrast to some other languages where a boolean type is more
>> like an enumerated type, is that it must behave like an integer
>> with certain known values.  It doesn't make sense to pretend
>> the particular values don't matter, which having enumeration
>> constants usually suggests.
>
> I disagree.  C's enumerated types are integer types.  In fact each
> enumerated type is compatible with char, with an unsigned integer
> type, or with a signed integer type.  (Type compatibility isn't
> quite identity, but it's close.)
>
> Some enumerated types define a set of constants where we only care
> that they're distinct, but we can also specify the value of each
> enumerator.  For example, we could have:
>
>     typedef enum { false = 0, true = 1 } bool;
>
> but the "= 0" and "= 1" are superfluous, since 0 and 1 are the
> defined values anyway.
>
> And of course false and true are of type int -- which they are
> in <stdbool.h>.

In terms of C's formal semantics what you're saying is right.

In terms of how programmers generally conceptualize and use
enumerated types, I think it isn't.  My comments are not meant to
be about C's formal semantics.  They are meant to be about how
people think about enumerated types and how they use them.  It is
relatively rare, for example, to see an enumerated type take part
in ordinary arithmetic, eg, addition.  That sort of dichotomy
reflects a significant underlying conceptual difference between
enumerated types and ordinary (arithmetic) integer types.

> I'm not arguing that C *should* have made bool/_Bool an enumerated
> type, but it *could* have done so, and I don't think it would have
> caused any problems.  (A handful of special-case rules would have
> been needed.)

I have no doubt that _Bool could have been made an enumerated
type.  My point is that there are sensible reasons that it wasn't
(and should not have been) made an enumerated type, because doing
so would not be a good fit to C's conceptual model of how
"boolean" operators like '<', etc, work.  Note that this model is
deeply embedded in C, certainly going back past K&R 1.  (I'm a
bit fuzzy on the history pre-K&R, so I won't go back past that,
but surely the basic 0/1-ness of "boolean" operators is firmly
entrenched by the time of K&R 1.).

>>                              Some languages choose to neuter
>> their boolean types in the sense that they may be used only in
>> a boolean context (and not, eg, an arithmetic context).
>> Personally I think that's a poor decision, and am glad C chose
>> to adopt a more Iverson-like semantics for _Bool.  Considering
>> that choice, it follows that _Bool is better suited to a
>> regular (arithmetic) integer type than an enumerated type.
>
> Personally I prefer the "neutered" approach, but that's a bit
> off-topic.

IMO that question is relevant to the current discussion.  At some
level I think it is because C "boolean" expressions are available
for use (and also used) in arithmetic contexts that _Bool was
made one of the standard integer types and not an enumerated
type.  The choice was not arbitrary but made to be in step with a
significant facet of C's history and conceptual philosophy.
Having _Bool be an enumerated type, and/or be usable only in a
"boolean" context, would go against the philosophical grain of,
at that time, 20 or 30 years of history.

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

#93477

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> Personally I prefer the "neutered" approach, but that's a bit
>> off-topic.
>
> IMO that question is relevant to the current discussion.  At some
> level I think it is because C "boolean" expressions are available
> for use (and also used) in arithmetic contexts that _Bool was
> made one of the standard integer types and not an enumerated
> type.  The choice was not arbitrary but made to be in step with a
> significant facet of C's history and conceptual philosophy.
> Having _Bool be an enumerated type, and/or be usable only in a
> "boolean" context, would go against the philosophical grain of,
> at that time, 20 or 30 years of history.

I think you're conflating two different things.  Making _Bool usable
only in a boolean context would certainly break a lot of code.
I personally would advocate "neutered" Booleans for any new language,
but I wouldn't dream of suggesting making such a change to C.

But again, enumerated types *are* integer types.  The language
provides the ability to specify the values of enumeration constants
for a good reason, and that by itself demonstrates that they
aren't *just* uniquely named constants whose actual values we
don't care about.  In my opinion you're overstating the "purity"
of enumerated types.

In fact, if C99 had specified _Bool as a predefined enumerated
type, with some added requirements on its representation, its
conversion rank, and how it behaves, I'm not sure you could tell
the difference between that and _Bool as it's actually defined.
There are no operations that distinguish between enumerated types
and integer types (please correct me if I'm mistaken).  Of course
the fact that false and true would no longer be macros would be
visible -- but I'm not entirely happy about them being macros in
the first place (but again, I'm not suggesting a change).

(Our disagreement is a minor one about a design decision that
was made 17 years ago, and that neither of us suggests changing,
so there's that.)

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

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

#93552

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

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>
> [...]
>
>>> Personally I prefer the "neutered" approach, but that's a bit
>>> off-topic.
>>
>> IMO that question is relevant to the current discussion.  At some
>> level I think it is because C "boolean" expressions are available
>> for use (and also used) in arithmetic contexts that _Bool was
>> made one of the standard integer types and not an enumerated
>> type.  The choice was not arbitrary but made to be in step with a
>> significant facet of C's history and conceptual philosophy.
>> Having _Bool be an enumerated type, and/or be usable only in a
>> "boolean" context, would go against the philosophical grain of,
>> at that time, 20 or 30 years of history.
>
> I think you're conflating two different things.  [...]

I'm not conflating.  I mentioned the two aspects because I
believe they are both related to the discussion.  I understand
they aren't the same thing.

> But again, enumerated types *are* integer types.  The language
> provides the ability to specify the values of enumeration constants
> for a good reason, and that by itself demonstrates that they
> aren't *just* uniquely named constants whose actual values we
> don't care about.  In my opinion you're overstating the "purity"
> of enumerated types.
>
> In fact, if C99 had specified _Bool as a predefined enumerated
> type, with some added requirements on its representation, its
> conversion rank, and how it behaves, I'm not sure you could tell
> the difference between that and _Bool as it's actually defined.
> There are no operations that distinguish between enumerated types
> and integer types (please correct me if I'm mistaken).  Of course
> the fact that false and true would no longer be macros would be
> visible -- but I'm not entirely happy about them being macros in
> the first place (but again, I'm not suggesting a change).

(I'm leaving the above intact so as not to have to decide how to
excerpt it.)  I think we are talking at cross purposes.  What I
am saying has almost nothing to do with what C's formal semantics
are or how they are defined.  The question I am interested in is
what makes sense given a historical conceptual model for C (ie,
that fits with C as described in K&R).  How the Standard chooses
to phrase the statements of formal semantics is, for me, a
secondary issue here.

(Incidentally, I think your statement about enumerated types
and integer types is not exactly right, because enumerated
types may not be used as the type specifier for a bitfield,
even when the compatible integer type could be used instead.
Of course an enumerated type _Bool could be given a special
exception for that, as was done for the integer type _Bool in
C99, but the observation about bitfields does point out a
difference in the general question.)


> (Our disagreement is a minor one about a design decision that
> was made 17 years ago, and that neither of us suggests changing,
> so there's that.)

I'm not sure we have a disagreement.  (To be fair I guess I
should add that I'm not sure we don't either.)  Do you think
that _Bool /should/ have been made an enumerated type?  If not
then AFAIAC we are in agreement on the salient question here,
and there is no need to inquire further.

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

#93555

On Thursday, September 15, 2016 at 12:52:06 PM UTC-5, Tim Rentsch wrote:
> (Incidentally, I think your statement about enumerated types
> and integer types is not exactly right, because enumerated
> types may not be used as the type specifier for a bitfield,
> even when the compatible integer type could be used instead.
> Of course an enumerated type _Bool could be given a special
> exception for that, as was done for the integer type _Bool in
> C99, but the observation about bitfields does point out a
> difference in the general question.)

I consider it unfortunate that the authors of the Standard seem averse to
the idea of giving implementations the freedom to accept or reject certain
syntactic forms at their leisure.  That would seem to me the best way to
handle constructs that may or may not have enough value to justify making
compiler writers support them.  Whether or not the ability to use an
enum bitfield would be sufficiently valuable as to mandate that
implementations must support it, I see nothing to be gained by suggesting
that implementers who want to support it, shouldn't.

> I'm not sure we have a disagreement.  (To be fair I guess I
> should add that I'm not sure we don't either.)  Do you think
> that _Bool /should/ have been made an enumerated type?  If not
> then AFAIAC we are in agreement on the salient question here,
> and there is no need to inquire further.

Given the body of existing practice using other integral types for the
purpose, having code use a mixture of _Bool and other integral types
doesn't really seem like an improvement over simply using other integral
types.  I could see usefulness for a bool_least_t, especially if
implementations were free to treat them as normal variables or as
non-addressable bits, at their leisure, but otherwise given that even
the very first implementations of C had built-in concepts of zero and
non-zero, I don't see the need to define new types for such things.

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

#93560

supercat@casperkitty.com writes:
> On Thursday, September 15, 2016 at 12:52:06 PM UTC-5, Tim Rentsch wrote:
>> (Incidentally, I think your statement about enumerated types
>> and integer types is not exactly right, because enumerated
>> types may not be used as the type specifier for a bitfield,
>> even when the compatible integer type could be used instead.
>> Of course an enumerated type _Bool could be given a special
>> exception for that, as was done for the integer type _Bool in
>> C99, but the observation about bitfields does point out a
>> difference in the general question.)
>
> I consider it unfortunate that the authors of the Standard seem averse to
> the idea of giving implementations the freedom to accept or reject certain
> syntactic forms at their leisure.  That would seem to me the best way to
> handle constructs that may or may not have enough value to justify making
> compiler writers support them.  Whether or not the ability to use an
> enum bitfield would be sufficiently valuable as to mandate that
> implementations must support it, I see nothing to be gained by suggesting
> that implementers who want to support it, shouldn't.

Congratulations, you have your wish.

N1570 6.7.2.1p5:

    A bit-field shall have a type that is a qualified or unqualified
    version of _Bool, signed int, unsigned int, or some other
    implementation-defined type.

Implementations are free to accept bit-fields of enumerated types, and
are not required to diagnose them.  (One example: gcc 6.2.0 accepts an
enumerated bit field and doesn't warn about it even with "-std=c11
-pedantic -Wall -Wextra".)

Please check the standard before complaining about it.

[...]

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

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

#93573

On Thursday, September 15, 2016 at 1:49:56 PM UTC-5, Keith Thompson wrote:
> supercat writes:
> > I consider it unfortunate that the authors of the Standard seem averse to
> > the idea of giving implementations the freedom to accept or reject certain
> > syntactic forms at their leisure.  That would seem to me the best way to
> > handle constructs that may or may not have enough value to justify making
> > compiler writers support them.  Whether or not the ability to use an
> > enum bitfield would be sufficiently valuable as to mandate that
> > implementations must support it, I see nothing to be gained by suggesting
> > that implementers who want to support it, shouldn't.
> 
> Congratulations, you have your wish.
> 
> N1570 6.7.2.1p5:
> 
>     A bit-field shall have a type that is a qualified or unqualified
>     version of _Bool, signed int, unsigned int, or some other
>     implementation-defined type.
> 
> Implementations are free to accept bit-fields of enumerated types, and
> are not required to diagnose them.  (One example: gcc 6.2.0 accepts an
> enumerated bit field and doesn't warn about it even with "-std=c11
> -pedantic -Wall -Wextra".)

Given:

   enum foo { boz,baz; };

is the type "foo" defined by the implementation or by user code?  Does
anything in the Standard specify that the phrase "Implementation-Defined
type" would be applicable to such an enum?

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

#93578

supercat@casperkitty.com writes:
> On Thursday, September 15, 2016 at 1:49:56 PM UTC-5, Keith Thompson wrote:
>> supercat writes:
>> > I consider it unfortunate that the authors of the Standard seem averse to
>> > the idea of giving implementations the freedom to accept or reject certain
>> > syntactic forms at their leisure.  That would seem to me the best way to
>> > handle constructs that may or may not have enough value to justify making
>> > compiler writers support them.  Whether or not the ability to use an
>> > enum bitfield would be sufficiently valuable as to mandate that
>> > implementations must support it, I see nothing to be gained by suggesting
>> > that implementers who want to support it, shouldn't.
>> 
>> Congratulations, you have your wish.
>> 
>> N1570 6.7.2.1p5:
>> 
>>     A bit-field shall have a type that is a qualified or unqualified
>>     version of _Bool, signed int, unsigned int, or some other
>>     implementation-defined type.
>> 
>> Implementations are free to accept bit-fields of enumerated types, and
>> are not required to diagnose them.  (One example: gcc 6.2.0 accepts an
>> enumerated bit field and doesn't warn about it even with "-std=c11
>> -pedantic -Wall -Wextra".)
>
> Given:
>
>    enum foo { boz,baz; };
>
> is the type "foo" defined by the implementation or by user code?  Does
> anything in the Standard specify that the phrase "Implementation-Defined
> type" would be applicable to such an enum?

My interpretation (and apparently that of the authors of gcc)
is that the implementation is free to specify that bit-fields may
be of enumerated types.  The phrase "implementation-defined type"
doesn't mean that the type itself is necessarily defined by the
implementation.  It means that the implementation defines which
types are permitted.

(Of course an implementation is also free to reject enumerated
bit-fields.)

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

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

#93558

Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
> I'm not sure we have a disagreement.  (To be fair I guess I
> should add that I'm not sure we don't either.)  Do you think
> that _Bool /should/ have been made an enumerated type?  If not
> then AFAIAC we are in agreement on the salient question here,
> and there is no need to inquire further.

If we have a disagreement, it's a trivial one.  I think that defining
_Bool as an enumerated type would have been reasonably sensible,
but I have no particular problem with the choice the committee made
here in the real world.  You, as I understand it, think that defining
_Bool as an enumerated type would have been a bad idea conceptually.
And of course neither of us thinks it should be changed now.

But as I write this, I've actually changed my mind.

The approach I had in mind was to do the equivalent of

    typedef enum { false, true } _Bool;

but making it predefined.  <stdbool.h> would still define the
identifier "bool" as an alias (macro, typedef, whatever) for _Bool.
But I just realized that would make the identifiers "false" and
"true" universally visible, causing problems for existing pre-C99
code that defines those identifiers.  I suppose that could be solved
by predefining

    typedef enum { _False, _True } _Bool;

and then defining, false, true, and bool as macros in <stdbool.h>.
That's ugly enough IMHO to tip the balance in favor of the actual
C99 approach.

The point of making _Bool an enumeration type was to have a clean
(IMHO) way to define false and true -- but there was no good way
to do that without breaking existing code.

I don't know whether the committee thought about that particular
issue.

<emily_litella>Never mind.</emily_litella>

(If I were designing a new language with no concern for backward
compatibility, I'd likely make `bool`, `false`, and `true` all
keywords, as C++ has done.  There might have been an opportunity
to do that in C89, but I'd say C99 was too late.)

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

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

#93620

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

> Tim Rentsch <txr@alumni.caltech.edu> writes:
> [...]
>> I'm not sure we have a disagreement.  (To be fair I guess I
>> should add that I'm not sure we don't either.)  Do you think
>> that _Bool /should/ have been made an enumerated type?  If not
>> then AFAIAC we are in agreement on the salient question here,
>> and there is no need to inquire further.
>
> If we have a disagreement, it's a trivial one.  I think that defining
> _Bool as an enumerated type would have been reasonably sensible,
> but I have no particular problem with the choice the committee made
> here in the real world.  You, as I understand it, think that defining
> _Bool as an enumerated type would have been a bad idea conceptually.

I don't know that I would say bad idea, but in C I think it
would stick out like a sore thumb, if that's what you're
meaning to get at.

> And of course neither of us thinks it should be changed now.

Yes, that would be worse than pointless.

> But as I write this, I've actually changed my mind.
> [snip elaboration]

Sound reasoning.  (And of course I like that you reached the
same final conclusion that I did, even though our reasons
are different.)

> The point of making _Bool an enumeration type was to have a clean
> (IMHO) way to define false and true [....]

In my view there is no reason (in C) to define false and
true at all - the constants 0 and 1 do just fine.  I find it
puzzling that lots of people seem to have the opposite
reaction.  But I'm not out to change anyone's mind, so maybe
it's better to leave that conversation for another day.

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

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

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

csiph-web