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

Groups > comp.lang.c > #72280

Re: Spurious diagnostic messages

Show all headers | View raw

Ian Collins <ian-news@hotmail.com> writes:

> Tim Rentsch wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>>
>>> Tim Rentsch wrote:
>>>> Ian Collins <ian-news@hotmail.com> writes:
>>>>
>>>>> Tim Rentsch wrote:
>>>>>
>>>>>> And that's why it should be rejected.  Any language feature like
>>>>>> this one, that provides no capability beyond what is fairly
>>>>>> easily available otherwise, if not considered important to/by
>>>>>> the entire C development community, is not important enough
>>>>>> to add to the language.
>>>>>
>>>>> So all of the the maths stuff added to C99 was "considered important
>>>>> to/by the entire C development community"?  I've yet to meet anyone
>>>>> who would agree with that.  Look outside of your little box sometime
>>>>> and see what most C programmers are doing:  embedded code.
>>>>
>>>> I'm sorry to be so long in responding here;  having to juggle too
>>>> many items.
>>>
>>> I thought you had taken offense at to being called a plutocrat :)
>>>
>>>> An important phrase in what I said is "that provides no
>>>> capability beyond what is fairly easily available otherwise".
>>>> The math stuff doesn't fall into this category, whereas
>>>> binary constants do.
>>>
>>> As did a large part of the other additions in C99.
>>
>> Looking over the list of changes in the Foreword, I see very few
>> changes that fall into this category.  I'm not sure there are any
>> outside the ones you mention (and I'm not sure about some of
>> those, see below).
>>
>>> I would place
>>> binary constants in the same basket as stdint types and maybe bool.
>>
>> I agree <stdbool.h> is a frill.  It seems clear this was added to
>> facilitate synchronizing with C++.  I think the case for adding
>> <stdbool.h> is better than the case for binary constants, because
>> these names are likely to be used in almost all C programs (and
>> in particular header files) where there is some potential for
>> mixing with C++.  That's a wider swath than binary constants.
>>
>> For <stdint.h>, I think your analysis is off.  The various type
>> names defined in <stdint.h> cannot be supplied in C without
>> access to information that the implementation has but is not
>> available (in most cases) otherwise.  That holds fairly obviously
>> for the fast integer types and exact-width integer types;  for
>> least-width integer types, it holds because the implementation
>> may have extended integer types that ordinary C code doesn't
>> know about.
>>
>>> No they don't provide a capability beyond what is fairly easily
>>> available otherwise but they do, through standardisation, make the
>>> programmer's job easier.  If anything, as simple typedefs stdint types
>>> were much more available than binary constants are today.
>>
>> They are because what they provide cannot be supplied without
>> some sort of additional support from the implementation.  That
>> puts them in a different category relative to binary constants.
>
> Not really, every project I worked on in the 80s and 90s had their own
> definitions for fixed with types.  Probably every environment that
> needed them had them.  The more enlightened project used typedefs,
> some were stuck with #defines.

There's a subtle point that I glossed over, which I see now I
shouldn't have left out.  The fixed width types that <stdint.h>
provides have stronger semantic guarantees than what most people
think of as fixed width types.  It isn't possible to provide
types that have the same semantic guarantees as the <stdint.h>
fixed-width types without either making use of implementation
specific knowledge or resorting to extra-linguistic mechanisms.
No doubt the fixed-width types you were using sufficed for the
purposes they were being put to, but if they were done using
standard C then they aren't the same as the [u]int{N}_t types
that <stdint.h> specifies (that is, for every implementation -
they could be the same for some implementations, just not all).

> However they were defined, their use was simple which is more than can
> be said for macro versions of binary constants.

Oh?  What do you find not simple about B2( 10101111 )?
If you don't like the B2 name, it's easy enough to change
that to Base2( 10101111 ) or Binary( 10101111 ).  I'm at
a loss to understand what someone would think isn't
simple about these, so if you do can you please explain
what or why?

> I can't find your
> macros, but where they implementation neutral?

Yes.  (I assume you meant "were" in the last sentence there.)

A more complete definition would need to take into account
the difference between C90 and C99, because C99 has long long
and C90 doesn't.  I suppose in principle an implementation
could have an extremely wide integer type, and it's hard to
write a macro that allows an unboundedly large input.  Not
counting those variations though it's all the same, because
how they work uses just ordinary arithmetic.

> I guess what I'm trying to say is home grown fixed with types are
> easier to live with (more natural) than macro based binary constants.

The idea of fixed-width types is a pretty old one I think, and
probably pre-dates C99 (and even C90?) by a fair bit.  Almost
everything is more natural when you're used to it, and not as
natural when you aren't.  Suppose you try writing binary
constants using a macro form for a while, to see if or how your
impression changes?  If you normally use a compiler that allows
the suggested form of binary constants as an extension (or in
C++), such a macro could be defined thusly:

    #define Binary(n)  0b ## n

If you do try this I'd be interested to hear about your
experiences.

Back to comp.lang.c | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 07:44 -0700
  Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-09-26 15:33 -0700
    Re: Spurious diagnostic messages Gareth Owen <gwowen@gmail.com> - 2015-09-28 19:57 +0100
      Re: Spurious diagnostic messages Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-28 20:52 +0100
      Re: Spurious diagnostic messages Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-29 11:19 +0000
    Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-28 22:26 +0000
      Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-09-30 13:56 +0100
        Re: Spurious diagnostic messages Gareth Owen <gwowen@gmail.com> - 2015-09-30 19:22 +0100
          Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-09-30 19:45 +0100
    Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 09:02 -0700
      Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-10-04 18:34 +0100
        Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-05 00:23 -0700
      Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-10-04 15:56 -0700
        Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-04 20:04 -0700
        Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-09 09:13 -0700
          Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-10-09 13:40 -0700
            Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-10 22:26 +0200
              Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-10 13:49 -0700
            Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-14 07:53 -0700
  Re: Spurious diagnostic messages Ian Collins <ian-news@hotmail.com> - 2015-09-27 17:30 +1300
    Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 10:26 -0700
      Re: Spurious diagnostic messages Ian Collins <ian-news@hotmail.com> - 2015-10-05 17:02 +1300
        Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-09 10:06 -0700

csiph-web