Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #112176 > unrolled thread
| Started by | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| First post | 2017-06-14 06:14 -0700 |
| Last post | 2017-06-14 14:28 -0700 |
| Articles | 20 on this page of 106 — 19 participants |
Back to article view | Back to comp.lang.c
Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-14 06:14 -0700
Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-14 06:18 -0700
Re: Type system protocols rest atop fundamental data mark.bluemel@gmail.com - 2017-06-14 08:00 -0700
Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-14 08:06 -0700
Re: Type system protocols rest atop fundamental data bartc <bc@freeuk.com> - 2017-06-14 20:39 +0100
Re: Type system protocols rest atop fundamental data Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-14 21:51 +0100
Re: Type system protocols rest atop fundamental data bartc <bc@freeuk.com> - 2017-06-14 22:25 +0100
Re: Type system protocols rest atop fundamental data Keith Thompson <kst-u@mib.org> - 2017-06-14 14:37 -0700
Re: Type system protocols rest atop fundamental data bartc <bc@freeuk.com> - 2017-06-15 00:32 +0100
Re: Type system protocols rest atop fundamental data Keith Thompson <kst-u@mib.org> - 2017-06-14 17:02 -0700
Re: Type system protocols rest atop fundamental data bartc <bc@freeuk.com> - 2017-06-15 01:34 +0100
Re: Type system protocols rest atop fundamental data Robert Wessel <robertwessel2@yahoo.com> - 2017-06-14 20:28 -0500
Re: Type system protocols rest atop fundamental data raltbos@xs4all.nl (Richard Bos) - 2017-06-18 10:49 +0000
Re: Type system protocols rest atop fundamental data Keith Thompson <kst-u@mib.org> - 2017-06-14 20:02 -0700
Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-15 10:29 +0200
Re: Type system protocols rest atop fundamental data bartc <bc@freeuk.com> - 2017-06-15 10:54 +0100
Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-15 13:15 +0200
Re: Type system protocols rest atop fundamental data bartc <bc@freeuk.com> - 2017-06-15 13:51 +0100
Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-15 16:13 +0200
Re: Type system protocols rest atop fundamental data Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-15 16:01 +0100
Re: Type system protocols rest atop fundamental data Keith Thompson <kst-u@mib.org> - 2017-06-15 09:27 -0700
Re: Type system protocols rest atop fundamental data raltbos@xs4all.nl (Richard Bos) - 2017-06-18 10:49 +0000
Re: Type system protocols rest atop fundamental data Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-16 23:35 -0700
Re: Type system protocols rest atop fundamental data Keith Thompson <kst-u@mib.org> - 2017-06-17 16:10 -0700
Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-17 19:23 -0700
Re: Type system protocols rest atop fundamental data Ian Collins <ian-news@hotmail.com> - 2017-06-16 13:13 +1200
Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-15 18:44 -0700
Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-16 13:42 +0200
Re: Type system protocols rest atop fundamental data Gareth Owen <gwowen@gmail.com> - 2017-06-16 20:20 +0100
Re: Type system protocols rest atop fundamental data Robert Wessel <robertwessel2@yahoo.com> - 2017-06-18 00:32 -0500
Re: Type system protocols rest atop fundamental data raltbos@xs4all.nl (Richard Bos) - 2017-06-18 11:06 +0000
Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-18 15:26 +0200
Re: Type system protocols rest atop fundamental data bartc <bc@freeuk.com> - 2017-06-18 14:58 +0100
Re: Type system protocols rest atop fundamental data Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-15 01:42 +0100
Re: Type system protocols rest atop fundamental data bartc <bc@freeuk.com> - 2017-06-15 11:52 +0100
Re: Type system protocols rest atop fundamental data Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-15 16:07 +0100
Re: Type system protocols rest atop fundamental data Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-16 23:37 -0700
Re: Type system protocols rest atop fundamental data Keith Thompson <kst-u@mib.org> - 2017-06-15 09:52 -0700
Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-15 10:36 -0700
Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-15 17:58 +0000
Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-15 11:48 -0700
Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-15 19:01 +0000
Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-15 12:29 -0700
Re: Type system protocols rest atop fundamental data Ian Collins <ian-news@hotmail.com> - 2017-06-16 13:47 +1200
Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-15 19:33 -0700
Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-15 13:02 -0700
Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-15 13:09 -0700
Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-15 22:25 +0200
Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-15 14:23 -0700
Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-15 23:53 +0200
Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-15 15:39 -0700
Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-16 13:50 +0200
Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-16 08:40 -0700
Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-18 16:49 +0200
Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-19 10:33 -0700
Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-19 17:50 +0000
Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-19 12:12 -0700
Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-19 19:27 +0000
Re: Type system protocols rest atop fundamental data Ike Naar <ike@iceland.freeshell.org> - 2017-06-20 15:18 +0000
Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-20 09:30 -0700
Re: Type system protocols rest atop fundamental data David Kleinecke <dkleinecke@gmail.com> - 2017-06-16 12:05 -0700
Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-16 12:30 -0700
Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-18 16:54 +0200
Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-19 13:25 -0700
Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-20 09:27 +0200
Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-20 08:53 -0700
Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-20 22:12 +0200
Re: Type system protocols rest atop fundamental data "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-06-20 13:14 -0700
Re: Type system protocols rest atop fundamental data "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-06-20 13:16 -0700
Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-20 14:04 -0700
Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-21 15:33 +0200
Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-20 13:25 +0000
Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-16 19:42 +0000
Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-18 16:58 +0200
Re: Type system protocols rest atop fundamental data raltbos@xs4all.nl (Richard Bos) - 2017-06-17 19:18 +0000
Re: Type system protocols rest atop fundamental data Robert Wessel <robertwessel2@yahoo.com> - 2017-06-15 23:40 -0500
Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-16 13:51 +0200
Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-16 12:55 +0000
Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-14 14:23 -0700
Re: Type system protocols rest atop fundamental data Ian Collins <ian-news@hotmail.com> - 2017-06-16 13:48 +1200
Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-15 19:03 -0700
Re: Type system protocols rest atop fundamental data Ian Collins <ian-news@hotmail.com> - 2017-06-16 15:12 +1200
Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-15 20:20 -0700
Re: Type system protocols rest atop fundamental data Richard Heathfield <rjh@cpax.org.uk> - 2017-06-16 07:03 +0100
Re: Type system protocols rest atop fundamental data Ian Collins <ian-news@hotmail.com> - 2017-06-16 20:01 +1200
Re: Type system protocols rest atop fundamental data Richard Heathfield <rjh@cpax.org.uk> - 2017-06-16 19:21 +0100
Re: Type system protocols rest atop fundamental data "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-06-16 12:07 -0700
Re: Type system protocols rest atop fundamental data Ian Collins <ian-news@hotmail.com> - 2017-06-17 16:18 +1200
Re: Type system protocols rest atop fundamental data Richard Heathfield <rjh@cpax.org.uk> - 2017-06-17 07:19 +0100
Re: Type system protocols rest atop fundamental data raltbos@xs4all.nl (Richard Bos) - 2017-06-17 19:19 +0000
Re: Type system protocols rest atop fundamental data Ian Collins <ian-news@hotmail.com> - 2017-06-18 08:29 +1200
Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-17 18:49 -0700
Re: Type system protocols rest atop fundamental data Ian Collins <ian-news@hotmail.com> - 2017-06-18 16:18 +1200
Re: Type system protocols rest atop fundamental data Öö Tiib <ootiib@hot.ee> - 2017-06-18 06:28 -0700
Re: Type system protocols rest atop fundamental data Keith Thompson <kst-u@mib.org> - 2017-06-16 09:11 -0700
Re: Type system protocols rest atop fundamental data Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-16 23:37 -0700
Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-18 17:04 +0200
Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-16 12:56 +0000
Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-16 07:10 -0700
Re: Type system protocols rest atop fundamental data GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-16 16:38 +0200
Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-16 15:02 +0000
Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-16 08:11 -0700
Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-18 17:13 +0200
Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-14 14:42 -0700
Re: Type system protocols rest atop fundamental data Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-14 21:32 +0100
Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-14 14:28 -0700
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-06-15 09:27 -0700 |
| Message-ID | <lnmv99b4ih.fsf@kst-u.example.com> |
| In reply to | #112263 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> bartc <bc@freeuk.com> writes:
> <snip>
>> Give me an example of a freely available C compiler (other than DMC
>> which is the only line that notices the mismatched arguments), which
>> out of the box and with default options, diagnoses:
>>
>> randommadeupfunction(1,2,3,"blah");
>> randommadeupfunction(1e37);
>>
>> as an error.
>
> You need to say a bit more for that even to be an error. In C90 and up
> a declaration can make those lines correct (though not necessarily very
> useful) and in K&R C they are OK without one. Only in C90 code with no
> declaration in scope is this definitely an error.
Given this complete translation unit:
int main(void) {
randommadeupfunction(1,2,3,"blah");
randommadeupfunction(1e37);
}
In C90, it violates no constraint or syntax rule, and no diagnostic is
required, but the behavior is undefined. Both calls implicitly create
the same declaration in the enclosing block:
int randommadeupfunction();
which is consistent with both calls, but there is no possible
*definition* of the function that would give both calls defined
behavior.
(Yes, this is an ugly and error-prone language feature, which is why
it's no longer in the language.)
You can even add a prototype that makes the entire translation unit
valid, and without undefined behavior if the function is defined
appropriately elsewhere:
int main(void) {
void randommadeupfunction(double, ...);
randommadeupfunction(1,2,3,"blah");
randommadeupfunction(1e37);
}
On the first call, the initial argument is implicitly converted from int
to double. A more apt example might have passed a string literal as the
first argument in the first call, and a floating constant in the second;
then no variadic prototype could make both calls valid.
[...]
--
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]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-06-18 10:49 +0000 |
| Message-ID | <59465ab7.9354187@news.xs4all.nl> |
| In reply to | #112244 |
David Brown <david.brown@hesbynett.no> wrote: > But really, you know all this already. Why you continue to run > compilers in default modes and use the results as though they explain > the C standards is a mystery to me. It's because you guys keep rising to his bait. Richard
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-06-16 23:35 -0700 |
| Message-ID | <kfn37az6s10.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #112230 |
Keith Thompson <kst-u@mib.org> writes:
> bartc <bc@freeuk.com> writes:
>
>> On 14/06/2017 22:37, Keith Thompson wrote:
>>
>>> bartc <bc@freeuk.com> writes:
>>> [...]
>>>
>>>> Enums are not a type.
>>>
>>> Incorrect. For example, given:
>>> enum foo { zero, one };
>>> `enum foo` is a type. Perhaps you meant something else.
>>
>> I considered enum to be just an int.
>
> You were wrong. Enumerated types are integer types. `enum foo`
> is a distinct type.
>
>> Given these enums:
>>
>> typedef enum colours {red,green,blue} Colour;
>> typedef enum days {mon, tue, wed} Day;
>>
>> Then only 2 of those 5 reject assigning a Day* to a Colour*.
>
> Each enum type is compatible with some integer type. gcc treats Colour
> and Day as compatible with unsigned int, but not with each other (which
> is valid, type compatibility is not necessarily transitive).
>
> My understanding is that Colour and Day are *not* compatible, even
> if they're both compatible with the same integer type, and that
> any conforming compiler must diagnose the assignment. (gcc does
> in conforming mode.) I'm not 100% confident in that conclusion.
The Standard doesn't say this explicitly, but presumably the
rules in the Standard for type compatibility are meant to be
exhaustive. If that is the case (and IMCO that intended
meaning is much more likely than not), then Colour and Day
cannot be compatible: distinct enumerations are distinct
types, and since nothing else is saying that they /are/
compatible, they aren't.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-06-17 16:10 -0700 |
| Message-ID | <ln8tkqjjmb.fsf@kst-u.example.com> |
| In reply to | #112389 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> Each enum type is compatible with some integer type. gcc treats Colour
>> and Day as compatible with unsigned int, but not with each other (which
>> is valid, type compatibility is not necessarily transitive).
>>
>> My understanding is that Colour and Day are *not* compatible, even
>> if they're both compatible with the same integer type, and that
>> any conforming compiler must diagnose the assignment. (gcc does
>> in conforming mode.) I'm not 100% confident in that conclusion.
>
> The Standard doesn't say this explicitly, but presumably the
> rules in the Standard for type compatibility are meant to be
> exhaustive. If that is the case (and IMCO that intended
> meaning is much more likely than not), then Colour and Day
> cannot be compatible: distinct enumerations are distinct
> types, and since nothing else is saying that they /are/
> compatible, they aren't.
I believe you're right. I think there's a tendency to assume that
type compatibility is transitive; it seems odd (at least to me)
for type A to be compatible with types B and C, but B and C not to
be compatible with each other. But the standard never says it's
a transitive relationship, and it isn't.
--
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]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-06-17 19:23 -0700 |
| Message-ID | <6717af33-96dc-4e98-be0e-edf7edc975bb@googlegroups.com> |
| In reply to | #112416 |
On Saturday, June 17, 2017 at 6:10:43 PM UTC-5, Keith Thompson wrote: > I believe you're right. I think there's a tendency to assume that > type compatibility is transitive; it seems odd (at least to me) > for type A to be compatible with types B and C, but B and C not to > be compatible with each other. But the standard never says it's > a transitive relationship, and it isn't. There's nothing wrong with type compatibility being non-transitive in cases where that would make sense. It would be much more logical to say, for example, that int64_t would be compatible with any all 64-bit integer types, whether or not they're compatible with each other, than to say that it must be compatible with at most one, and must be incompatible with all the rest.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-06-16 13:13 +1200 |
| Message-ID | <eqgpljFe853U1@mid.individual.net> |
| In reply to | #112229 |
On 06/15/17 11:32 AM, bartc wrote:
> On 14/06/2017 22:37, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>> [...]
>>> Enums are not a type.
>>
>> Incorrect. For example, given:
>> enum foo { zero, one };
>> `enum foo` is a type. Perhaps you meant something else.
>
> I considered enum to be just an int. But out of 5 compilers, 3 flag an
> error when assigning an enum foo* to a float*.
>
> Given these enums:
>
> typedef enum colours {red,green,blue} Colour;
> typedef enum days {mon, tue, wed} Day;
>
> Then only 2 of those 5 reject assigning a Day* to a Colour*.
>
> And when calling:
>
> void fn(Colour x){}
>
> then none of those compilers say anything when passing a Day type to
> such a function:
>
> Day d;
> fn(d);
>
> Of course, none of them /can/ say anything when fn(wed) is used, as I
> don't think 'wed' has anything but int type.
>
> So the effort to make enums a type is rather half-hearted, and doesn't
> go very far.
If you want C++.......
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-06-15 18:44 -0700 |
| Message-ID | <a666c1f9-9110-482e-9bf1-d65e39d782bf@googlegroups.com> |
| In reply to | #112313 |
On Thursday, June 15, 2017 at 9:13:32 PM UTC-4, Ian Collins wrote: > If you want C++....... Nobody wants C++, Ian. Nobody. Not even Bjarne. Thank you, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-16 13:42 +0200 |
| Message-ID | <oi0g09$6h8$1@dont-email.me> |
| In reply to | #112314 |
On 16/06/17 03:44, Rick C. Hodgin wrote: > On Thursday, June 15, 2017 at 9:13:32 PM UTC-4, Ian Collins wrote: >> If you want C++....... > > Nobody wants C++, Ian. Nobody. Not even Bjarne. > The more I see posts here from you and Bart with your bizarre, inconsistent and complex ways to try to re-invent the bits of C++ that you think are useful while desperately trying to avoid the bits that you think are bad, the more I am encouraged to use /real/ C++. You make your own choice, of course, and have your own preferences - but C++ is a massively popular language (and Bjarne /does/ want it), and a great many people seem to manage to use it quite happily. It is different from C despite some overlap, it has its pros and cons, its uses and its abuses - just like any other language. And in this particular case, it has /exactly/ the feature Bart is missing from C here. But it also has its own newsgroup, so I don't want to go into detail here.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-06-16 20:20 +0100 |
| Message-ID | <87tw3fspsp.fsf@gmail.com> |
| In reply to | #112334 |
David Brown <david.brown@hesbynett.no> writes: > You make your own choice, of course, and have your own preferences - but > C++ is a massively popular language (and Bjarne /does/ want it), I get the feeling the only bits that Bjarne doesn't like are C-compatibility warts (C-style casts, some of the more broken bits of the C standard library - i.e. various str*() functions, C-style arrays)
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-06-18 00:32 -0500 |
| Message-ID | <po3ckchlhrlf0rmj25gl8tb5g947nnspf5@4ax.com> |
| In reply to | #112334 |
On Fri, 16 Jun 2017 13:42:27 +0200, David Brown <david.brown@hesbynett.no> wrote: >On 16/06/17 03:44, Rick C. Hodgin wrote: >> On Thursday, June 15, 2017 at 9:13:32 PM UTC-4, Ian Collins wrote: >>> If you want C++....... >> >> Nobody wants C++, Ian. Nobody. Not even Bjarne. >> > >The more I see posts here from you and Bart with your bizarre, >inconsistent and complex ways to try to re-invent the bits of C++ that >you think are useful while desperately trying to avoid the bits that you >think are bad, the more I am encouraged to use /real/ C++. > >You make your own choice, of course, and have your own preferences - but >C++ is a massively popular language (and Bjarne /does/ want it), and a >great many people seem to manage to use it quite happily. It is >different from C despite some overlap, it has its pros and cons, its >uses and its abuses - just like any other language. > >And in this particular case, it has /exactly/ the feature Bart is >missing from C here. > >But it also has its own newsgroup, so I don't want to go into detail here. To paraphrase Stalin, popularity is a quality all its own. "Better" languages than C and C++ are a dime-a-dozen. They're almost all dismal failures (in the sense of getting any meaningful use), since they miss C (and C++'s) most important attribute: To a greater extent than almost any other choices, they'll be there for me on the platform I want to support next month, next year, and next decade. And all the toolchains, libraries and programmers I might possibly need will be available.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-06-18 11:06 +0000 |
| Message-ID | <59465acc.9374984@news.xs4all.nl> |
| In reply to | #112443 |
Robert Wessel <robertwessel2@yahoo.com> wrote: > "Better" languages than C and C++ are a dime-a-dozen. They're almost > all dismal failures (in the sense of getting any meaningful use), > since they miss C (and C++'s) most important attribute: To a greater > extent than almost any other choices, they'll be there for me on the > platform I want to support next month, next year, and next decade. And > all the toolchains, libraries and programmers I might possibly need > will be available. I think that, partly, has it backwards. Yes, C is omnipresent; but so are other languages. C is not popular because it is everywhere, C is everywhere at least partly because it was once extremely popular. The difference between C and, say, Fortran, which was also once popular and is still available on a very large variety of systems, is that C remains popular in general, while Fortran is nowadays popular mostly with its core demographic. That's enough to keep Fortran omnipresent as well, but not to make it popular with general programmers. No, IMAO C is popular because it's _simple_. There isn't a massive library to get confused by. There isn't a whole new paradigm to learn. Sure, it has edge cases, but I don't know a single language which doesn't. Even languages specifically written to be elegant have odd cases - no, _especially_ them, because my elegance is not your elegance, and after all, _the world_ isn't elegant and any programming language has to deal with the real world. Another reason is that C is a superior example of a general programming language. It is not a specialised language such as Prolog or Snobol; nor is it a language with a more deeply built-in philosophy such as Python, C++ or Lisp; or a language with a specific audience in mind, such as Pascal or Cobol. Actually, C does have a specific audience, but that audience is _general programmers_ trying to do their job, day in day out. Well, there are a lot more small programmers out there trying to get the job done than there are big corporate teams working on the latest replacement for the Space Shuttle, or academics solving the theory behind tomorrow's problems. C is better at dealing with the roughness of the real world, in a general way, to get today's job done, than any other language I know. That makes it useful just about everywhere. And that's why it _is_ everywhere, not the other way around. Richard
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-18 15:26 +0200 |
| Message-ID | <oi5uri$a17$1@dont-email.me> |
| In reply to | #112443 |
On 18/06/17 07:32, Robert Wessel wrote: > On Fri, 16 Jun 2017 13:42:27 +0200, David Brown > <david.brown@hesbynett.no> wrote: > >> On 16/06/17 03:44, Rick C. Hodgin wrote: >>> On Thursday, June 15, 2017 at 9:13:32 PM UTC-4, Ian Collins wrote: >>>> If you want C++....... >>> >>> Nobody wants C++, Ian. Nobody. Not even Bjarne. >>> >> >> The more I see posts here from you and Bart with your bizarre, >> inconsistent and complex ways to try to re-invent the bits of C++ that >> you think are useful while desperately trying to avoid the bits that you >> think are bad, the more I am encouraged to use /real/ C++. >> >> You make your own choice, of course, and have your own preferences - but >> C++ is a massively popular language (and Bjarne /does/ want it), and a >> great many people seem to manage to use it quite happily. It is >> different from C despite some overlap, it has its pros and cons, its >> uses and its abuses - just like any other language. >> >> And in this particular case, it has /exactly/ the feature Bart is >> missing from C here. >> >> But it also has its own newsgroup, so I don't want to go into detail here. > > > To paraphrase Stalin, popularity is a quality all its own. > > "Better" languages than C and C++ are a dime-a-dozen. They're almost > all dismal failures (in the sense of getting any meaningful use), > since they miss C (and C++'s) most important attribute: To a greater > extent than almost any other choices, they'll be there for me on the > platform I want to support next month, next year, and next decade. And > all the toolchains, libraries and programmers I might possibly need > will be available. > Certainly for many popular things, an important reason they are popular is that they are popular. Sometimes that is good (such as C and C++), sometimes it is bad (such as MS Windows). And yes, expected future availability is definitely something you want to consider before picking a programming language, and something most programming languages cannot promise. (There are a good many more than C and C++ that /can/ provide a solid expectation of future availability, including Lua, Python, Perl, Java, Fortran, Haskell, Lisp, etc.) If you are picking a programming language for a professional project, you want to be confident that the tools will be around in the future, that they will be updated with features needed in the future, and that developers familiar with the language will be available in the future.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-06-18 14:58 +0100 |
| Message-ID | <JFv1B.81556$yk1.31719@fx17.am4> |
| In reply to | #112334 |
On 16/06/2017 12:42, David Brown wrote: > On 16/06/17 03:44, Rick C. Hodgin wrote: >> Nobody wants C++, Ian. Nobody. Not even Bjarne. >> > > The more I see posts here from you and Bart with your bizarre, > inconsistent and complex ways to try to re-invent the bits of C++ that > you think are useful while desperately trying to avoid the bits that you > think are bad, the more I am encouraged to use /real/ C++. C++ is a mess. So is a lot of C, but C++ is a much bigger one, given that it incorporates much of C. You yourself said that the way language extensions are handled makes it challenging to compile efficiently. > You make your own choice, of course, and have your own preferences - but > C++ is a massively popular language (and Bjarne /does/ want it), and a > great many people seem to manage to use it quite happily. It is > different from C despite some overlap, it has its pros and cons, its > uses and its abuses - just like any other language. > > And in this particular case, it has /exactly/ the feature Bart is > missing from C here. It's not something I'm missing, so don't really want it. I was just checking how much effort I'm exported to go to to produce a C implementation, and my tests showed that a lot of other compilers can't be too bothered with it either. (There's another issue badly supported that I've found, I'll post about that later on.) I think at least one language should be kept lightweight, which precludes dealing with enums properly, as you would need a language as large as Ada for that. And C++ isn't lightweight either. (And neither is C that lightweight now thanks to assorted, hard-to-implement extensions, huge amounts of useless baggage, and enough variability in implementations that most application seem to be plastered with #if and #ifdef blocks.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-06-15 01:42 +0100 |
| Message-ID | <87a85a84k3.fsf@bsb.me.uk> |
| In reply to | #112224 |
bartc <bc@freeuk.com> writes:
> On 14/06/2017 21:51, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>> <snip>
>>> But C's type system is minimal: integers, floats and pointers. You can
>>> hardly get lower than that.
>>
>> C also has function types, array types, structure types, union types and
>> _Bool. Enums hardly qualify but they might get though on a
>> technicality. In addition there are type qualifiers that make new,
>> different types from the unqualified versions.
>
> A function type isn't really tangible, except as a function
> pointer. And that's already covered. Arrays, structs and unions are
> just collections of the basic types, and are limited in what can be
> done with them without indexing or selecting an element or subelement
> that /is/ a basic type.
None the less, they are all part of C's type system. And what about the
qualifiers; surely a minimal type system would not have type qualifiers?
> Enums are not a type.
How, then, do you explain that this:
enum B {x} b;
enum A {y} *ap = &b;
requires a diagnostic?
<snip>
>> And some people (some even who post here) would consider it disingenuous
>> to say that C has "integers" while at the same time describing the type
>> system as "minimal" given the proliferation of integer types and the
>> number of rules that have grown up around them.
>
> Current machines seem to have a need for 8 integer types: 8, 16, 32
> and 64 bits, signed and unsigned, and C supplies that need.
That's absolutely my point. If C's type system were indeed minimal then
it would not have any more distinct integer types than that.
> Sort of, as it generously (but not very usefully) provides 10 integer
> types instead! (There are five types without explicit widths has
> 'long' is usually the same as 'int', or the same as 'long long'.) Or
> possibly 11, if 'plain char' is considered different from unsigned or
> signed char.
_Bool, char, signed char, unsigned char, short, unsigned short, int,
unsigned int, long, unsigned long, long long, and unsigned long long are
all distinct types. Then there are all the integer types like size_t,
wchar_t and so on, and there may even be extended integer types.
And your "floats" comprises no less than six distinct floating types.
It that minimal?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-06-15 11:52 +0100 |
| Message-ID | <aFt0B.92765$D15.32016@fx39.am4> |
| In reply to | #112232 |
On 15/06/2017 01:42, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:
>> Enums are not a type.
>
> How, then, do you explain that this:
>
> enum B {x} b;
> enum A {y} *ap = &b;
>
> requires a diagnostic?
I wasn't aware of that. But I don't really take enums as types seriously.
Neither do most C compilers I've tried (lccwin, DMC, Tiny C and
MSVC-2017 don't report any warning or error; only gcc and Pelles C).
>> Current machines seem to have a need for 8 integer types: 8, 16, 32
>> and 64 bits, signed and unsigned, and C supplies that need.
>
> That's absolutely my point. If C's type system were indeed minimal then
> it would not have any more distinct integer types than that.
If it had one integer type, then it would be more of an abstract
language. The OP wants to bypass whatever type system C has, to get at
the underlying data more easily. For that, C would need to have types
representing that data, which it usually has.
>> Sort of, as it generously (but not very usefully) provides 10 integer
>> types instead! (There are five types without explicit widths has
>> 'long' is usually the same as 'int', or the same as 'long long'.) Or
>> possibly 11, if 'plain char' is considered different from unsigned or
>> signed char.
>
> _Bool, char, signed char, unsigned char, short, unsigned short, int,
> unsigned int, long, unsigned long, long long, and unsigned long long are
> all distinct types. Then there are all the integer types like size_t,
> wchar_t and so on, and there may even be extended integer types.
No, it'd just a godawful mess. Out of the 8 integer machine types, C
provides 11, which don't even correspond to specific types. It needs
stdint.h to provide that mapping.
My own language provides exactly those 8. And my C implementation also
provides those 8 (there is no plain char, and long is a synonym for one
of the others).
_Bool and enums seem to be just half-hearted, bolted-on extensions to
the type system. size_t and wchar_t are just aliases for existing types,
and have no significance for a compiler.
I don't know what the point of plain char is, unless it's to atone in
some way for the common use of a signed type to represent chars and
bytes. By calling it 'plain', you don't have the admit that it's signed!
> And your "floats" comprises no less than six distinct floating types.
I'm aware of float, double and long double; what are the other three?
Anyway, if you cut through all this unnecessary complexity that C adds,
then the machine types are there.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-06-15 16:07 +0100 |
| Message-ID | <87mv9970is.fsf@bsb.me.uk> |
| In reply to | #112247 |
bartc <bc@freeuk.com> writes:
> On 15/06/2017 01:42, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>
>>> Enums are not a type.
>>
>> How, then, do you explain that this:
>>
>> enum B {x} b;
>> enum A {y} *ap = &b;
>>
>> requires a diagnostic?
>
> I wasn't aware of that. But I don't really take enums as types seriously.
>
> Neither do most C compilers I've tried (lccwin, DMC, Tiny C and
> MSVC-2017 don't report any warning or error; only gcc and Pelles C).
But were they compiling C at the time? In the past you have
deliberately reported the behaviour of compilers when they are being
asked to compile an unknown language.
>>> Current machines seem to have a need for 8 integer types: 8, 16, 32
>>> and 64 bits, signed and unsigned, and C supplies that need.
>>
>> That's absolutely my point. If C's type system were indeed minimal then
>> it would not have any more distinct integer types than that.
>
> If it had one integer type, then it would be more of an abstract
> language.
Who said anything about one integer type? You said it's type system was
minimal. I'm just pointing out that it isn't. I might be minimal if it
had only the 8 types you say it needs, but has more.
<snip>
>> And your "floats" comprises no less than six distinct floating types.
>
> I'm aware of float, double and long double; what are the other three?
The three complex floating types.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-06-16 23:37 -0700 |
| Message-ID | <kfny3sr5dcd.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #112265 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > bartc <bc@freeuk.com> writes: > >> On 15/06/2017 01:42, Ben Bacarisse wrote: >> >>> bartc <bc@freeuk.com> writes: >>> [...] >>> And your "floats" comprises no less than six distinct floating types. >> >> I'm aware of float, double and long double; what are the other three? > > The three complex floating types. And don't forget the three optional imaginary types. :)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-06-15 09:52 -0700 |
| Message-ID | <lninjxb3bo.fsf@kst-u.example.com> |
| In reply to | #112247 |
bartc <bc@freeuk.com> writes:
> On 15/06/2017 01:42, Ben Bacarisse wrote:
[...]
>> _Bool, char, signed char, unsigned char, short, unsigned short, int,
>> unsigned int, long, unsigned long, long long, and unsigned long long are
>> all distinct types. Then there are all the integer types like size_t,
>> wchar_t and so on, and there may even be extended integer types.
>
> No, it'd just a godawful mess. Out of the 8 integer machine types, C
> provides 11, which don't even correspond to specific types. It needs
> stdint.h to provide that mapping.
If you assume that the purpose of C's predefined integer types is to
provide a way to use the 8 different integer representations provided by
typical hardware (8, 16, 32, and 64 bits, signed and unsigned), then
yes, C's integer type system is a mess, and the [u]intN_t types in
<stdint.h> make more sense.
It's your assumption that's the problem. That, and your unwillingness
to learn. I expect that your reply will ask something about why C's
integer types are the way they are, but I also expect that you won't be
interested in any answers I might offer, other than as an excuse to
complain, so I probably won't bother answering.
> My own language provides exactly those 8. And my C implementation also
> provides those 8 (there is no plain char, and long is a synonym for one
> of the others).
Then you don't have a C implementation. (That's OK, neither do I --
but I don't claim to.) Perhaps what you're doing is implementing
a language that's what you wish C were. That's just fine if that's
what you want to do, but if you call it a "C implementation" you're
going to cause confusion.
> _Bool and enums seem to be just half-hearted, bolted-on extensions to
> the type system. size_t and wchar_t are just aliases for existing types,
> and have no significance for a compiler.
They're significant for programmers. (And of course the compiler knows
the type of the result of sizeof; for a given implementation, <stddef.h>
has to define size_t to match that result.)
[...]
--
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]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-06-15 10:36 -0700 |
| Message-ID | <6500a643-18ac-458d-949f-acae30d41cd9@googlegroups.com> |
| In reply to | #112275 |
On Thursday, June 15, 2017 at 11:53:09 AM UTC-5, Keith Thompson wrote: > If you assume that the purpose of C's predefined integer types is to > provide a way to use the 8 different integer representations provided by > typical hardware (8, 16, 32, and 64 bits, signed and unsigned), then > yes, C's integer type system is a mess, and the [u]intN_t types in > <stdint.h> make more sense. If I were asked in the 1990s to describe the purpose of C's built-in types, I would have described short as the shortest practical type with at least 16 bits, long as the most efficient type with at least 32 bits, and int as the longest type between those whose computation cost is not significantly greater than that of any shorter type in that range [in cases where operations on 32-bit values would cost *slightly* more than those on 16-bit values, int could be 16 bits, 32 bits, or configurable.] Can you offer examples of historic platforms which treated those types in a fashion inconsistent with the above? For what fraction of programs would an ability to run on non-octet-based architectures add any value whatsoever?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-06-15 17:58 +0000 |
| Message-ID | <fVz0B.7223$_N3.880@fx04.iad> |
| In reply to | #112277 |
supercat@casperkitty.com writes: >On Thursday, June 15, 2017 at 11:53:09 AM UTC-5, Keith Thompson wrote: >> If you assume that the purpose of C's predefined integer types is to >> provide a way to use the 8 different integer representations provided by >> typical hardware (8, 16, 32, and 64 bits, signed and unsigned), then >> yes, C's integer type system is a mess, and the [u]intN_t types in >> <stdint.h> make more sense. > >If I were asked in the 1990s to describe the purpose of C's built-in types, >I would have described short as the shortest practical type with at least >16 bits, long as the most efficient type with at least 32 bits, and int as >the longest type between those whose computation cost is not significantly >greater than that of any shorter type in that range [in cases where >operations on 32-bit values would cost *slightly* more than those on 16-bit >values, int could be 16 bits, 32 bits, or configurable.] It should be obvious that the original types were designed specifically to support PDP-11 hardware. Nothing more, nothing less. By the 1990's, C was in widespread use by SGI (64-bit and 32-bit MIPS), SUN (64-bit SPARC), Motorola (680x0, 88100), Convergent (68k, i386), HP (PA-Risc), IBM (PowerPC, others) and several other smaller system houses. Microsoft operating systems were pretty much irrelevent then. Amongst those vendors, there were variations on ILP64, LP64 and other mappings of the C type system to architectural fundamental types. And of course, Microsoft had to be different from everyone else, when they finally got around to supporting 64-bit CPU's.
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web