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 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#93587

On 15/09/16 21:35, luser droog wrote:
> On Thursday, September 15, 2016 at 12:25:16 PM UTC-5, Bart wrote:
>> On 15/09/2016 11:37, David Brown wrote:
>>> On 15/09/16 02:06, supercat@casperkitty.com wrote:
>>>> On Wednesday, September 14, 2016 at 4:34:30 PM UTC-5, Keith Thompson wrote:
>>>>> Programmers should use _Bool or bool because it's substantially clearer
>>>>> than using unsigned char to represent a true/false condition.
>>>>
>>>> What's the advantage of using a less-efficient type versus a user-defined
>>>> "flag" type could allow more efficient code generation?
>>>>
>>>
>>> As Keith says, bool is clearer and therefore better.  Clarity is not
>>> necessarily the overriding factor, but it is usually very important.
>>>
>>> Remember also that bool has another useful property - any assignment to
>>> a bool variable will give it the value 0 or 1, unless you /really/ go
>>> out of your way to mess things up for yourself (with pointer casts and
>>> the like).  This is a useful feature you can rely on - and the compiler
>>> can rely on it too.
>>
>> But that would have been useful with *any* int types that are expected
>> to occupy only a small range of legal values. Such as 1..7, or the enums
>> (red, green, blue).
>>
>> Just like Pascal. But nothing of the sort is done. Any int values seems
>> to be completely interchangeable. The language hardly even cares if you
>> assign a 32-bit int to an 8-bit one, or signed to unsigned.
>>
>> So why bother with one tiny aspect of that with _Bool?
>>
>> Whatever _Bool does can be achieved with explicit conversion (eg. using
>> the !! operators)
>>
>
> This is pretty much what I do. If I need a bool, I use int.
> Mostly I want bools as flags in my structures. And structs
> are always in the headers. So every other C file would have to
> include stdbool first, just to read the headers.
>
> It's doable. But I find using int to be a smaller headache.
>

What is wrong with having #include <stdbool.h> at the top of your 
headers, if they use its features?

As a general rule, I like my headers to include anything else that they 
need, to be safe from multiple inclusions, and to be includeable in any 
order.

And I'd only put a struct in an include file if it were part of the 
exported interface for the matching module.

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

#93675

On Thursday, September 15, 2016 at 5:51:36 PM UTC-5, David Brown wrote:
> On 15/09/16 21:35, luser droog wrote:
> > On Thursday, September 15, 2016 at 12:25:16 PM UTC-5, Bart wrote:
> >> On 15/09/2016 11:37, David Brown wrote:
> >>> On 15/09/16 02:06, supercat@casperkitty.com wrote:
> >>>> On Wednesday, September 14, 2016 at 4:34:30 PM UTC-5, Keith Thompson wrote:
> >>>>> Programmers should use _Bool or bool because it's substantially clearer
> >>>>> than using unsigned char to represent a true/false condition.
> >>>>
> >>>> What's the advantage of using a less-efficient type versus a user-defined
> >>>> "flag" type could allow more efficient code generation?
> >>>>
> >>>
> >>> As Keith says, bool is clearer and therefore better.  Clarity is not
> >>> necessarily the overriding factor, but it is usually very important.
> >>>
> >>> Remember also that bool has another useful property - any assignment to
> >>> a bool variable will give it the value 0 or 1, unless you /really/ go
> >>> out of your way to mess things up for yourself (with pointer casts and
> >>> the like).  This is a useful feature you can rely on - and the compiler
> >>> can rely on it too.
> >>
> >> But that would have been useful with *any* int types that are expected
> >> to occupy only a small range of legal values. Such as 1..7, or the enums
> >> (red, green, blue).
> >>
> >> Just like Pascal. But nothing of the sort is done. Any int values seems
> >> to be completely interchangeable. The language hardly even cares if you
> >> assign a 32-bit int to an 8-bit one, or signed to unsigned.
> >>
> >> So why bother with one tiny aspect of that with _Bool?
> >>
> >> Whatever _Bool does can be achieved with explicit conversion (eg. using
> >> the !! operators)
> >>
> >
> > This is pretty much what I do. If I need a bool, I use int.
> > Mostly I want bools as flags in my structures. And structs
> > are always in the headers. So every other C file would have to
> > include stdbool first, just to read the headers.
> >
> > It's doable. But I find using int to be a smaller headache.
> >
> 
> What is wrong with having #include <stdbool.h> at the top of your 
> headers, if they use its features?
> 
> As a general rule, I like my headers to include anything else that they 
> need, to be safe from multiple inclusions, and to be includeable in any 
> order.

At the time I was operating under the rule that headers should not
call other headers. I then had occasion to change my postscript
implementation from C99 to C90 (or 91, more precisely), so stdbool
had to go (for that project). 

Ultimately it appeared to me to be an equivalent set of rules:
viz. using stdbool and the header discipline it imposes, using
int and explicitly !! every value to bool range. For my own 
code, this has been easier than continuing to try to use stdbool.
I try to choose variable names with 'flag' or sthg to indicate its
Boolean nature. 

> And I'd only put a struct in an include file if it were part of the 
> exported interface for the matching module.

That is another issue I'm coming to terms with. I understand what
you're saying, but I'm not there yet.

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

#93676

luser droog <luser.droog@gmail.com> writes:
[...]
> At the time I was operating under the rule that headers should not
> call other headers. I then had occasion to change my postscript
> implementation from C99 to C90 (or 91, more precisely), so stdbool
> had to go (for that project). 
[...]

What is C91?

-- 
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]

#93696

On 17/09/16 02:02, luser droog wrote:
> On Thursday, September 15, 2016 at 5:51:36 PM UTC-5, David Brown wrote:
>> On 15/09/16 21:35, luser droog wrote:
>>> On Thursday, September 15, 2016 at 12:25:16 PM UTC-5, Bart wrote:
>>>> On 15/09/2016 11:37, David Brown wrote:
>>>>> On 15/09/16 02:06, supercat@casperkitty.com wrote:
>>>>>> On Wednesday, September 14, 2016 at 4:34:30 PM UTC-5, Keith Thompson wrote:
>>>>>>> Programmers should use _Bool or bool because it's substantially clearer
>>>>>>> than using unsigned char to represent a true/false condition.
>>>>>>
>>>>>> What's the advantage of using a less-efficient type versus a user-defined
>>>>>> "flag" type could allow more efficient code generation?
>>>>>>
>>>>>
>>>>> As Keith says, bool is clearer and therefore better.  Clarity is not
>>>>> necessarily the overriding factor, but it is usually very important.
>>>>>
>>>>> Remember also that bool has another useful property - any assignment to
>>>>> a bool variable will give it the value 0 or 1, unless you /really/ go
>>>>> out of your way to mess things up for yourself (with pointer casts and
>>>>> the like).  This is a useful feature you can rely on - and the compiler
>>>>> can rely on it too.
>>>>
>>>> But that would have been useful with *any* int types that are expected
>>>> to occupy only a small range of legal values. Such as 1..7, or the enums
>>>> (red, green, blue).
>>>>
>>>> Just like Pascal. But nothing of the sort is done. Any int values seems
>>>> to be completely interchangeable. The language hardly even cares if you
>>>> assign a 32-bit int to an 8-bit one, or signed to unsigned.
>>>>
>>>> So why bother with one tiny aspect of that with _Bool?
>>>>
>>>> Whatever _Bool does can be achieved with explicit conversion (eg. using
>>>> the !! operators)
>>>>
>>>
>>> This is pretty much what I do. If I need a bool, I use int.
>>> Mostly I want bools as flags in my structures. And structs
>>> are always in the headers. So every other C file would have to
>>> include stdbool first, just to read the headers.
>>>
>>> It's doable. But I find using int to be a smaller headache.
>>>
>>
>> What is wrong with having #include <stdbool.h> at the top of your
>> headers, if they use its features?
>>
>> As a general rule, I like my headers to include anything else that they
>> need, to be safe from multiple inclusions, and to be includeable in any
>> order.
>
> At the time I was operating under the rule that headers should not
> call other headers. I then had occasion to change my postscript
> implementation from C99 to C90 (or 91, more precisely), so stdbool
> had to go (for that project).
>
> Ultimately it appeared to me to be an equivalent set of rules:
> viz. using stdbool and the header discipline it imposes, using
> int and explicitly !! every value to bool range. For my own
> code, this has been easier than continuing to try to use stdbool.
> I try to choose variable names with 'flag' or sthg to indicate its
> Boolean nature.
>
>> And I'd only put a struct in an include file if it were part of the
>> exported interface for the matching module.
>
> That is another issue I'm coming to terms with. I understand what
> you're saying, but I'm not there yet.
>

OK.

When you are ready, if you want to discuss what should go into headers, 
or include files, and whether headers should include other headers, then 
that could be a useful thread.  But I think it should be an independent 
thread - and it could get rough!

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

#93463

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>.

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.)

>                              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.

-- 
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]

#93467

I think the C standard needs to be simple and very compatible with old code and C++. 

So, what we can do is to use static analyzers and to use a more restrictive type checking.

For instance, who wants this?

_Bool b = 3;
enum {A, B} e = 4;
bool b2 = 1 + 2;
int val = true * false;

if (a = 2)
{
}

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

#93468

On Wednesday, September 14, 2016 at 12:01:13 PM UTC-5, Thiago Adams wrote:
> I think the C standard needs to be simple and very compatible with old code and C++. 

Although it is not uncommon for projects to need to integrate code written
in both C and C++, and while such integration would be facilitated by code
that would have the same meaning in C or C++, neither language's standards
committee seems interested in compatibility with the other language, so the
practicality of code which can operate interchangeably in both languages is
if anything diminishing.

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

#93518

On 9/14/2016 2:35 PM, supercat@casperkitty.com wrote:
> On Wednesday, September 14, 2016 at 12:01:13 PM UTC-5, Thiago Adams wrote:
>> I think the C standard needs to be simple and very compatible with old code and C++. 
> 
> Although it is not uncommon for projects to need to integrate code written
> in both C and C++, and while such integration would be facilitated by code
> that would have the same meaning in C or C++, neither language's standards
> committee seems interested in compatibility with the other language, so the
> practicality of code which can operate interchangeably in both languages is
> if anything diminishing.
> 

Why should they?  I've integrated PASCAL, assembler and other languages
with C before.  None of them are concerned with interchangeable code.
Each compiler is responsible for its own code.

When I'm writing C code I use a C compiler.  When writing C++ code, I
use a C++ compiler.  The same with other languages.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#93524

On Wednesday, September 14, 2016 at 9:15:23 PM UTC-5, Jerry Stuckle wrote:
> Why should they?  I've integrated PASCAL, assembler and other languages
> with C before.  None of them are concerned with interchangeable code.
> Each compiler is responsible for its own code.

When interfacing with Pascal, declarations for shared functions or objects
will need to be written in both languages.  While it might be possible to
write one set of header functions for use with C and another for use with
C++, being able to use the same code for both can be helpful.  Further, in
many cases the performance of a library can be improved by making some of
the functions available for in-lining, but that requires that the functions
be visible within the same compilation unit as the surrounding code.

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

#93564

On 9/15/2016 2:51 AM, supercat@casperkitty.com wrote:
> On Wednesday, September 14, 2016 at 9:15:23 PM UTC-5, Jerry Stuckle wrote:
>> Why should they?  I've integrated PASCAL, assembler and other languages
>> with C before.  None of them are concerned with interchangeable code.
>> Each compiler is responsible for its own code.
> 
> When interfacing with Pascal, declarations for shared functions or objects
> will need to be written in both languages.  While it might be possible to
> write one set of header functions for use with C and another for use with
> C++, being able to use the same code for both can be helpful.  Further, in
> many cases the performance of a library can be improved by making some of
> the functions available for in-lining, but that requires that the functions
> be visible within the same compilation unit as the surrounding code.
> 

You can use #ifdef __cplusplus for language specific code.  I do it
quite regularly - although I find very little need for it.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#93521

On 09/15/16 06:35 AM, supercat@casperkitty.com wrote:
> On Wednesday, September 14, 2016 at 12:01:13 PM UTC-5, Thiago Adams wrote:
>> I think the C standard needs to be simple and very compatible with old code and C++.
>
> Although it is not uncommon for projects to need to integrate code written
> in both C and C++, and while such integration would be facilitated by code
> that would have the same meaning in C or C++, neither language's standards
> committee seems interested in compatibility with the other language, so the
> practicality of code which can operate interchangeably in both languages is
> if anything diminishing.

If anything, they care more than they used to.  A good example is atomics.

-- 
Ian

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

#93529

On 15/09/16 06:08, Ian Collins wrote:
> On 09/15/16 06:35 AM, supercat@casperkitty.com wrote:
>> On Wednesday, September 14, 2016 at 12:01:13 PM UTC-5, Thiago Adams
>> wrote:
>>> I think the C standard needs to be simple and very compatible with
>>> old code and C++.
>>
>> Although it is not uncommon for projects to need to integrate code
>> written
>> in both C and C++, and while such integration would be facilitated by
>> code
>> that would have the same meaning in C or C++, neither language's
>> standards
>> committee seems interested in compatibility with the other language,
>> so the
>> practicality of code which can operate interchangeably in both
>> languages is
>> if anything diminishing.
> 
> If anything, they care more than they used to.  A good example is atomics.
> 

Indeed.

And it is usually not hard to write code that is valid C, and valid C++,
and not /too/ strange for either language.  Clearly you can't use
features that only exist in one of the languages.  But it's very common
practice that headers for C modules are made "C++ compatible" by simply
wrapping them in:

#ifdef __cplusplus
extern "C" {
#endif

...

#ifdef __cplusplus
}
#endif



It is less common for the actual implementation code to need to be
compiled as either C or C++, but it happens - projects that mix C and
C++ are certainly not unusual in embedded systems.  There are only a few
rules to follow, while some readers might ask "why are you casting that
void* pointer?" or "why are you declaring that function as int
foo(void)?", the resulting code is not particularly strange.

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

#93549

On Thursday, September 15, 2016 at 5:46:08 AM UTC-5, David Brown wrote:
> It is less common for the actual implementation code to need to be
> compiled as either C or C++, but it happens - projects that mix C and
> C++ are certainly not unusual in embedded systems.  There are only a few
> rules to follow, while some readers might ask "why are you casting that
> void* pointer?" or "why are you declaring that function as int
> foo(void)?", the resulting code is not particularly strange.

Yeah, but are people who cast the result of "malloc()" or apply a unary
"+" operator to a volatile variable allowed to show their faces among C
programmers?

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

#93588

On 15/09/16 18:37, supercat@casperkitty.com wrote:
> On Thursday, September 15, 2016 at 5:46:08 AM UTC-5, David Brown wrote:
>> It is less common for the actual implementation code to need to be
>> compiled as either C or C++, but it happens - projects that mix C and
>> C++ are certainly not unusual in embedded systems.  There are only a few
>> rules to follow, while some readers might ask "why are you casting that
>> void* pointer?" or "why are you declaring that function as int
>> foo(void)?", the resulting code is not particularly strange.
>
> Yeah, but are people who cast the result of "malloc()" or apply a unary
> "+" operator to a volatile variable allowed to show their faces among C
> programmers?
>

I still don't understand why you think using a unary plus operator on a 
volatile is a useful thing to do, but okay.

And casting malloc() will not get you thrown out of c.l.c.  You might be 
questioned on it, but nothing more than that.

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

#93596

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.

> And casting malloc() will not get you thrown out of c.l.c.  You might be 
> questioned on it, but nothing more than that.

I was being a little facetious, but it does seem to be a rather hot religious
topic.

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

#93600

On 16/09/16 05: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.
>
>> And casting malloc() will not get you thrown out of c.l.c.  You might be
>> questioned on it, but nothing more than that.
>
> I was being a little facetious, but it does seem to be a rather hot religious
> topic.


Not exactly religious. But if you sense a certain amount of frustration, 
you're right. Given the choice between an easy, simple, robust, 
effective way of using malloc and a complicated, twisted, easy-to-break, 
non-intuitive way of using it, why is it that people got for B every time?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#93604

On 16/09/16 07:32, Richard Heathfield wrote:
> On 16/09/16 05: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.
>>
>>> And casting malloc() will not get you thrown out of c.l.c.  You might be
>>> questioned on it, but nothing more than that.
>>
>> I was being a little facetious, but it does seem to be a rather hot
>> religious
>> topic.
> 
> 
> Not exactly religious. But if you sense a certain amount of frustration,
> you're right. Given the choice between an easy, simple, robust,
> effective way of using malloc and a complicated, twisted, easy-to-break,
> non-intuitive way of using it, why is it that people got for B every time?
> 

That's why C++ was invented - didn't you know that?

<http://www.snopes.com/computer/program/stroustrup.asp>

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

#93610

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 16/09/16 05:45, supercat@casperkitty.com wrote:
>> On Thursday, September 15, 2016 at 5:53:51 PM UTC-5, David Brown wrote:
<snip>
>>> And casting malloc() will not get you thrown out of c.l.c.  You might be
>>> questioned on it, but nothing more than that.
>>
>> I was being a little facetious, but it does seem to be a rather hot religious
>> topic.
>
> Not exactly religious. But if you sense a certain amount of
> frustration, you're right. Given the choice between an easy, simple,
> robust, effective way of using malloc and a complicated, twisted,
> easy-to-break, non-intuitive way of using it, why is it that people
> got for B every time?

For some it's just habit -- you had to cast the value from malloc() back
in the day and it's not easy to stop your fingers typing what they want
to type, especially when the result is not actually wrong.  For others,
they are just copying what they've seen, either in live code or in
tutorials, both of which may well have been written by people who
learned C back in the day when you had to cast malloc().  And now there
is a new generation of programmers who are writing live code and
tutorials that cast malloc()...

But it's also a small problem.  Of all the things that make C hard to
get right or maintain or debug, this is one of the least significant.
If a simple source-code pattern could banish memory leaks, it would be
taken up immediately, but the problems solved by not casting malloc()
are rare and cause serious problems even more rarely.

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.)

-- 
Ben.

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

#93612

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"

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

#93613

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).

-- 
Ben.

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

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

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

csiph-web