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

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

const and the C type system

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

Contents

  const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-28 19:51 -0700
    Re: const and the C type system Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-09-28 21:32 -0600
      Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-29 05:45 -0700
        Re: const and the C type system bartc <bc@freeuk.com> - 2017-09-29 14:05 +0100
          Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-29 06:17 -0700
      Re: const and the C type system asetofsymbols@gmail.com - 2017-10-01 22:35 -0700
    Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-09-29 10:59 +0200
      Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-29 06:06 -0700
        Re: const and the C type system bartc <bc@freeuk.com> - 2017-09-29 14:24 +0100
          Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-29 06:52 -0700
            Re: const and the C type system jameskuyper@verizon.net - 2017-09-29 09:17 -0700
              Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-29 10:50 -0700
                Re: const and the C type system jameskuyper@verizon.net - 2017-09-29 11:06 -0700
                  Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-29 11:27 -0700
            Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-30 13:13 -0700
              Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-30 13:31 -0700
          Re: const and the C type system Keith Thompson <kst-u@mib.org> - 2017-09-29 09:10 -0700
            Re: const and the C type system bartc <bc@freeuk.com> - 2017-09-29 18:33 +0100
            Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-29 11:10 -0700
          Re: const and the C type system Ian Collins <ian-news@hotmail.com> - 2017-09-30 08:29 +1300
          Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-09-30 18:48 +0200
            Re: const and the C type system bartc <bc@freeuk.com> - 2017-09-30 18:44 +0100
              Re: const and the C type system Ian Collins <ian-news@hotmail.com> - 2017-10-01 09:12 +1300
                Re: const and the C type system bartc <bc@freeuk.com> - 2017-09-30 21:50 +0100
                  Re: const and the C type system Ian Collins <ian-news@hotmail.com> - 2017-10-01 10:10 +1300
                    Re: const and the C type system bartc <bc@freeuk.com> - 2017-09-30 23:17 +0100
                      Re: const and the C type system Ian Collins <ian-news@hotmail.com> - 2017-10-01 11:38 +1300
                        Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-01 00:44 +0100
                          Re: const and the C type system Ian Collins <ian-news@hotmail.com> - 2017-10-01 14:33 +1300
                            Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-01 10:42 +0100
                              Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-01 19:58 +0200
                                Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-01 21:30 +0100
                                  Re: const and the C type system Ian Collins <ian-news@hotmail.com> - 2017-10-02 17:48 +1300
                                    Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-02 11:14 +0100
                                      Re: const and the C type system Ian Collins <ian-news@hotmail.com> - 2017-10-02 23:22 +1300
                              Re: const and the C type system Richard Damon <Richard@Damon-Family.org> - 2017-10-01 13:58 -0400
                      Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-01 18:20 +0200
                        Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-01 18:41 +0100
                          Re: const and the C type system supercat@casperkitty.com - 2017-10-01 12:03 -0700
                          Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-01 23:05 +0200
                            Re: const and the C type system supercat@casperkitty.com - 2017-10-01 15:58 -0700
                              Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-02 09:56 +0200
                            Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-02 00:24 +0100
                              Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-02 12:20 +0200
                                Re: const and the C type system Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-10-02 06:03 -0700
                                  Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-10-02 06:34 -0700
                                Re: const and the C type system supercat@casperkitty.com - 2017-10-02 23:38 -0700
                        Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-10-01 13:03 -0700
                          Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-01 23:12 +0200
                    Re: const and the C type system supercat@casperkitty.com - 2017-10-01 11:12 -0700
                  Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-01 13:48 +0200
                    Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-01 14:13 +0100
                    Re: const and the C type system supercat <flatfinger@casperkitty.com> - 2017-10-01 10:32 -0700
                Re: const and the C type system supercat@casperkitty.com - 2017-09-30 13:52 -0700
              Re: const and the C type system Keith Thompson <kst-u@mib.org> - 2017-09-30 13:35 -0700
                Re: const and the C type system bartc <bc@freeuk.com> - 2017-09-30 21:58 +0100
                  Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-01 12:03 +0100
                Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-30 14:00 -0700
                  Re: const and the C type system Keith Thompson <kst-u@mib.org> - 2017-09-30 15:33 -0700
                  Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-10-01 12:45 -0700
              Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-01 13:13 +0200
                Re: const and the C type system Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-10-01 05:22 -0700
                  Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-01 20:06 +0200
                    Re: const and the C type system supercat@casperkitty.com - 2017-10-01 12:16 -0700
                    Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-01 21:01 +0100
                      Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-10-01 13:21 -0700
                        Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-01 21:50 +0100
                          Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-10-02 05:35 -0700
                            Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-02 14:01 +0100
                              Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-10-02 06:29 -0700
                                Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-02 15:19 +0100
                      Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-01 23:19 +0200
                        Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-01 22:33 +0100
                          Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-02 00:10 +0200
                Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-01 14:13 +0100
                  Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-01 22:46 +0200
                    Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-01 21:57 +0100
                      Re: const and the C type system Keith Thompson <kst-u@mib.org> - 2017-10-01 14:09 -0700
                        Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-01 23:54 +0100
                          Re: const and the C type system Keith Thompson <kst-u@mib.org> - 2017-10-01 19:12 -0700
                            Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-02 11:36 +0100
                              Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-02 12:45 +0200
                              Re: const and the C type system Keith Thompson <kst-u@mib.org> - 2017-10-02 09:40 -0700
                                Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-02 19:33 +0100
                                  Re: const and the C type system scott@slp53.sl.home (Scott Lurndal) - 2017-10-02 19:09 +0000
                                  Re: const and the C type system Ian Collins <ian-news@hotmail.com> - 2017-10-03 08:12 +1300
                                    Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-02 20:30 +0100
                                    Re: const and the C type system Keith Thompson <kst-u@mib.org> - 2017-10-02 12:37 -0700
                                  Re: const and the C type system jadill33@gmail.com - 2017-10-02 12:49 -0700
                                Re: const and the C type system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-10-06 20:47 +0000
                                  Re: const and the C type system Keith Thompson <kst-u@mib.org> - 2017-10-06 15:41 -0700
                            Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-02 12:42 +0200
                Re: const and the C type system Gareth Owen <gwowen@gmail.com> - 2017-10-01 21:18 +0100
            Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-30 12:22 -0700
        Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-09-30 18:44 +0200
      Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-29 07:01 -0700
        Re: const and the C type system Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-29 20:18 +0100
          Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-29 12:40 -0700
            Re: const and the C type system Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-29 21:28 +0100
    Re: const and the C type system fir <profesor.fir@gmail.com> - 2017-09-29 08:21 -0700
      Re: const and the C type system fir <profesor.fir@gmail.com> - 2017-09-29 08:38 -0700
    Re: const and the C type system John Bode <jfbode1029@gmail.com> - 2017-10-02 09:20 -0700
      Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-10-02 09:53 -0700
      Re: const and the C type system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-10-09 13:27 +0000

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

#120673

On Sunday, October 1, 2017 at 4:06:03 PM UTC-5, David Brown wrote:
> No - again, you intentionally misinterpret me.  I said that the code 
> efficiency of limited compilers is irrelevant.  If you want fast object 
> code, you don't use tcc, or Bart's own compiler, or whatever - you use 
> gcc, clang, MSVC, icc, or a similar serious mainstream compiler.

It's interesting you mention MSVC.  While fans of gcc and clang may look down
upon it, it can efficiently process a much wider range of programs than clang
and gcc.  From what I can tell, icc seems pretty good as well in that regard.
Both clang and gcc seem to use an abstract machine model that does not match
the Effective Type model given in the Standard, but would instead matches a
proposed weakened model--one where effectives types are "permanent" once they
are set--that was proposed in a DR and shot down.  Since the compilers aren't
interested in efficiently supporting the requirements of existing code, nor
the existing standard, I'm not sure why people treat them with such reverence.

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

#120680

On 02/10/17 00:58, supercat@casperkitty.com wrote:
> On Sunday, October 1, 2017 at 4:06:03 PM UTC-5, David Brown wrote:
>> No - again, you intentionally misinterpret me.  I said that the code 
>> efficiency of limited compilers is irrelevant.  If you want fast object 
>> code, you don't use tcc, or Bart's own compiler, or whatever - you use 
>> gcc, clang, MSVC, icc, or a similar serious mainstream compiler.
> 
> It's interesting you mention MSVC.  While fans of gcc and clang may look down
> upon it, it can efficiently process a much wider range of programs than clang
> and gcc.

No, it cannot.  gcc can efficiently process programs in C, C++,
Objective C, Fortran, Ada and Go, for some 30 or 40 different target
processors and something like a dozen different target OS's, plus bare
metal.

I don't know off-hand how many source languages or target cpus clang
currently supports, but I believe it is a fair number (though not close
to gcc's).

MSVC can efficiently process programs in C (with outdated standards),
C++, and some MS-specific languages like C# and VB, targeting one cpu
architecture and one OS.  The main reason I don't use it is that it does
not support the programs I write, and the cpus I target.

MSVC is undoubtedly a fine compiler for C++, generates efficient code
and has a good range of static analysis and other tools.  Some of the
people involved in it are top minds in the C++ world - the three big C++
compilers (gcc, clang and MSVC) all contribute to moving that language
forward.  But MSVC is a millstone for C, and its out-of-date and limited
support is part of why some people still program in C90 today.


>  From what I can tell, icc seems pretty good as well in that regard.

icc is also very limited, AFAIK - it supports C, C++ and perhaps
Fortran, targeting only the x86 and i64 worlds, but with support for a
few different target OS's.  My understanding is that it does a very good
job of optimising code, especially for use of SIMD instructions.

> Both clang and gcc seem to use an abstract machine model that does not match
> the Effective Type model given in the Standard, but would instead matches a
> proposed weakened model--one where effectives types are "permanent" once they
> are set--that was proposed in a DR and shot down.  Since the compilers aren't
> interested in efficiently supporting the requirements of existing code, nor
> the existing standard, I'm not sure why people treat them with such reverence.
> 

gcc is the compiler that is most used for compiling old code - probably
by several orders of magnitude compared to any other compiler.  The
biggest source of old code that gets compiled with modern tools is in
software for Linux, BSD, and more general *nix systems - look through
the source repositories for Debian and I'm sure you'll find plenty of
code written in K&R C, and certainly lots of code whose history
stretches back 20 years, and it all compiles on modern gcc.

Your problem is that you have never understood what C is and how it
works, you have only guessed how you think it should work.  That
happened to be good enough for some compilers 20 or 30 years ago, and
this has led you to think that is how C /actually/ works - and therefore
all tools since then are bad.

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

#120675

On 01/10/2017 22:05, David Brown wrote:
> On 01/10/17 19:41, bartc wrote:

>> You seem to be very disparaging of compilers that are not gcc or that 
>> don't have as many features as gcc has crammed into it.
> 
> No - again, you intentionally misinterpret me.  I said that the code 
> efficiency of limited compilers is irrelevant.  If you want fast object 
> code, you don't use tcc, or Bart's own compiler, or whatever - you use 
> gcc, clang, MSVC, icc, or a similar serious mainstream compiler.  tcc is 
> great if you want a compiler for a minimal OS - maybe you are trying to 
> use a Raspberry Pi as a development system.  And a small compiler is 
> marvellous if you want to learn about compiler technology, or if you 
> want to make your own dialect of C by changing a compiler.  But if you 
> want efficient object code, you use a sophisticated compiler and enable 
> optimisation options.
> 
> So since no one will use a small compiler when they want efficient code, 
> the efficiency of the code generated by small compilers is irrelevant. 
> Simple logic.

Some people will like small, simple compilers because they are easier to 
manage (mine is just one file), nippy to run and informal to use. If 
they could also generate faster code, why would they want anything else?

And of course you usually want code to run as fast as is reasonable no 
matter what compiler is in use. But this can take the form of using a 
small compiler for development, and something like gcc for a production 
program. In which case the small compiler plays a significant role.

It also helps portability by spreading the development across two 
implementations as extra things can come to light. (Try keeping six 
compilers happy...)

>  For me, there is much more to a compiler than the 
> ability to turn an outdated form of C into object code on a particular 
> OS.

When compiling C used as intermediate code, that's pretty much all 
that's needed.

> It's called "C++".  It's been around for a while.

I think I'm starting to see where you're coming from.

You're looking at the C language from the comfortable, complacent point 
of view of a large, feature-rich compiler (gcc), which has dozens of 
extras to help take the edge off many of the shortcomings of the language.

And when that isn't quite enough, you just switch over to C++. (And I 
guess you have the usual smart editors and whatever to deal with things 
even C++ can't help with, such as detecting mismatched braces and so on.)

So that I can see that you would have no interest whatsoever to fix any 
of those shortcomings, to introduce anything that is already in C++, to 
introduce anything that /isn't/ already in C++ (because if it was that 
good an idea, C++ would have it!), nor to introduce anything that makes 
life easier for lesser compilers, or for those using or implementing 
those lesser compilers.

>> After all it can't take long to download the gcc sources (only 45,000 
>> source files) and tweak them.
> 
> I don't write compilers, I just use them.

I didn't mean that you would do this. But I thought it was open source 
for a reason. My point really was that on a small system you can do 
this; on a massive system it's somewhat harder.

-- 
bartc

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

#120682

On 02/10/17 01:24, bartc wrote:
> On 01/10/2017 22:05, David Brown wrote:
>> On 01/10/17 19:41, bartc wrote:
> 
>>> You seem to be very disparaging of compilers that are not gcc or that
>>> don't have as many features as gcc has crammed into it.
>>
>> No - again, you intentionally misinterpret me.  I said that the code
>> efficiency of limited compilers is irrelevant.  If you want fast
>> object code, you don't use tcc, or Bart's own compiler, or whatever -
>> you use gcc, clang, MSVC, icc, or a similar serious mainstream
>> compiler.  tcc is great if you want a compiler for a minimal OS -
>> maybe you are trying to use a Raspberry Pi as a development system. 
>> And a small compiler is marvellous if you want to learn about compiler
>> technology, or if you want to make your own dialect of C by changing a
>> compiler.  But if you want efficient object code, you use a
>> sophisticated compiler and enable optimisation options.
>>
>> So since no one will use a small compiler when they want efficient
>> code, the efficiency of the code generated by small compilers is
>> irrelevant. Simple logic.
> 
> Some people will like small, simple compilers because they are easier to
> manage (mine is just one file), nippy to run and informal to use. 

Again, that's fine.

> If
> they could also generate faster code, why would they want anything else?

No one (except Supercat) is going to complain about better optimised
code.  But that is not the be-all and end-all of a compiler.  However,
we've been through this before, and you have never been able to
understand that anyone would want a compiler feature set other than your
own priorities.

> 
> And of course you usually want code to run as fast as is reasonable no
> matter what compiler is in use. But this can take the form of using a
> small compiler for development, and something like gcc for a production
> program. In which case the small compiler plays a significant role.
> 
> It also helps portability by spreading the development across two
> implementations as extra things can come to light. (Try keeping six
> compilers happy...)

Write standard C (or at least, limiting implementation-specific
requirements to things that are defined by the target and ABI rather
than the compiler), give the compilers the appropriate options to fit
the standard, and stop using any compiler that can't follow that standard.

The alternative is to stop worrying about compilers that almost no one
uses.  If you want people to use your language and compile the generated
code, then you have two sensible choices.  Either insist that people use
a mainstream compiler, or bundle a specific compiler and insist they use
that.

> 
>>   For me, there is much more to a compiler than the ability to turn an
>> outdated form of C into object code on a particular OS.
> 
> When compiling C used as intermediate code, that's pretty much all
> that's needed.

Yes, I agree - but that is not what I do with compilers.  Your needs do
not match my needs.

> 
>> It's called "C++".  It's been around for a while.
> 
> I think I'm starting to see where you're coming from.

OK, I'll listen.

> 
> You're looking at the C language from the comfortable, complacent point
> of view of a large, feature-rich compiler (gcc), which has dozens of
> extras to help take the edge off many of the shortcomings of the language.

You will find that in most of my discussions here, I try to stick to
standard C - and if I refer to gcc'isms, I make it clear.

In this newsgroup, I look at C from the viewpoint of a good quality
compiler with solid optimisations, static warning flags, and options to
fine-tune things like language conformity.  That compiler does not have
to be gcc - it's merely the example I use because it is the compiler
with which I am most familiar, and the one that is easiest to test with
online tools like godbolt.org.  Alternatives like clang, icc, MSVC,
Borland, Sun's cc, etc., are fine.  I also expect people to know how to
use their tools.

If you don't use such a compiler, it is /your/ fault.  People using 8051
or Z80 microcontrollers have an excuse - people targeting Windows or
Linux do not.

I also take the viewpoint that when writing new code, people should do
so using modern C standards unless they have an overwhelming reason not
to.  And they should take advantage of the features the language
provides in order to write clearer and safer code.

You might also want your code to run with more limited compilers, which
is fine - but use suitable tools when you are doing development.  Use
gcc or clang when checking your code, with warning levels turned up.
When you know your code is good, then you can try it on tcc and friends,
and it does not matter that these tools are feature-poor.


Yes, C has its warts and limitations - I have never denied that, and I
have agreed with you about a number of them (while disagreeing about
others).  But in my mind, it does not matter, for example, that the C
language allows you to declare functions without giving them a prototype
- something we all agree is a bad thing.  I don't write code with
non-prototype function declarations - it is highly unlikely that anyone
would do so by accident.  And my compiler would spot it and give an
error.  The same applies to many of the issues I have with C, and many
of the issues /you/ have with it.


In addition, /I/ choose to use gcc and to use some of its extensions and
extra features to make the language better.  But that is my choice -
other people may or may not do that.  Again, I always try to make the
distinction between "C lets you write this" and "I write this in gcc".


C /does/ have its faults as a language.  Most of them can be mitigated
by good coding practice, and good use of good tools.  Those faults in C
thus become academic - they are of no practical concern.  It would be
/nice/ if they were fixed, but it is unlikely ever to happen, and it is
pointless to be concerned about it.

> 
> And when that isn't quite enough, you just switch over to C++. (And I
> guess you have the usual smart editors and whatever to deal with things
> even C++ can't help with, such as detecting mismatched braces and so on.)

Of course I use good tools.  Why would anyone choose bad tools?  You
might sometimes choose limited tools for particular purposes - when I am
working remotely and making small changes, I might use a command-line
editor (such as nano).  But for normal work, I use a big, smart IDE.  I
choose Eclipse - other people prefer NetBeans, MSVC, JEdit, etc.  If
your editor does not detect missing braces and provide other help, it is
/your/ choice to use limited tools.

> 
> So that I can see that you would have no interest whatsoever to fix any
> of those shortcomings,

I can't fix shortcomings in C - I am not on the C standards committee.
I can't add support for new features to a compiler - I don't write C
compilers.  I can discuss about what I think would be nice to have in C,
and what I think might be realistic to change, but that's my limit.  And
I have little interest in discussing something that I am confident will
/never/ be in the C standards, and will /never/ be in mainstream C
compilers - especially when these new features offer little of use that
is not already supported, and when there are far more realistic
alternatives (like copying features from C++).

> to introduce anything that is already in C++,

How many times in this thread have I said I'd like the behaviour of
"const" in C to copy that of C++ ?  How many times have other people
said the same thing?  Surely that counts as introducing to C something
that is already in C++ ?

> to
> introduce anything that /isn't/ already in C++ (because if it was that
> good an idea, C++ would have it!),

If C++ has a feature, there is a better chance of it being adopted in C
than if C does not have the feature - the feature has been documented,
implemented and tested.  And there is no chance of C adopting a feature
that is in direct contradiction or competition to a corresponding
feature in C++.  It will simply not happen.  There will /never/ be a
"constant" keyword added to C - either the standards or any mainstream
implementation - because there are /better/ and /existing/ ways to get a
similar effect, using "const" and possibly "constexpr" from C++.

> nor to introduce anything that makes
> life easier for lesser compilers,

I have no interest or concern there, no.  Nor does the C standards
committee - so that is not something that is likely to become part of
standard C.

>  or for those using or implementing
> those lesser compilers.

I have no interest or concern for people implementing lesser compilers.
 As for users - they should be able to use at least approximately
standard C on these lesser compilers, or the compilers are worthless.
And if users of lesser compilers want extra features, then that is a
matter between the users and the implementers - just as it is for
"greater" compilers.  Compilers can add whatever extensions they like to
make life easier for their users - I see no problems with that.  But I
don't use these "lesser" compilers that you use (I have used a number of
"lesser" compilers for embedded systems), and I have very little
interest in special features that might be implemented in a tool I will
never use.  (Sometimes it is fun to hear about them - I have enjoyed
hearing about some of Jacob's extensions, which had a lot of thought
behind them.)

> 
>>> After all it can't take long to download the gcc sources (only 45,000
>>> source files) and tweak them.
>>
>> I don't write compilers, I just use them.
> 
> I didn't mean that you would do this. But I thought it was open source
> for a reason. My point really was that on a small system you can do
> this; on a massive system it's somewhat harder.
> 

Yes, gcc is open source for a reason.  Open source software does not
mean you expect /users/ to download the source and make changes themselves.

And I fully agree that it is easier to make changes to a small compiler
than a big one.  I think I mentioned that in one of my posts - the ease
of fiddling with the compiler and playing with new features is one
reason for preferring small compilers like tcc.

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

#120690

On Monday, October 2, 2017 at 11:20:24 AM UTC+1, David Brown wrote:
> 
> Of course I use good tools.  Why would anyone choose bad tools? 
>
I've been playing about with an idea for a language which used functions
written in C, embedded in a larger structure. Now obviously if the project
ever becomes serious I'll have to leverage something like gcc. But for the
moment, a C interpreter is just fine. I've downloaded one from the web
(Pico C). It doesn't support function pointers. I can live with that for now.

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

#120694

On Monday, October 2, 2017 at 10:03:52 AM UTC-3, Malcolm McLean wrote:
> On Monday, October 2, 2017 at 11:20:24 AM UTC+1, David Brown wrote:
> > 
> > Of course I use good tools.  Why would anyone choose bad tools? 
> >
> I've been playing about with an idea for a language which used functions
> written in C, embedded in a larger structure. Now obviously if the project
> ever becomes serious I'll have to leverage something like gcc. But for the
> moment, a C interpreter is just fine. I've downloaded one from the web
> (Pico C). It doesn't support function pointers. I can live with that for now.

A C interpreter is useful inside a C compiler.

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

#120713

On Monday, October 2, 2017 at 5:20:24 AM UTC-5, David Brown wrote:
> No one (except Supercat) is going to complain about better optimised
> code.  But that is not the be-all and end-all of a compiler.  However,
> we've been through this before, and you have never been able to
> understand that anyone would want a compiler feature set other than your
> own priorities.

I like compilers that can optimize code *in a fashion reliably consistent
with its requirements*.  An optimization which is predicated on the idea
that a programmer won't do action X will be worse than useless in cases
where the programmer in fact needs to do action X.

> Write standard C (or at least, limiting implementation-specific
> requirements to things that are defined by the target and ABI rather
> than the compiler), give the compilers the appropriate options to fit
> the standard, and stop using any compiler that can't follow that standard.

Many compatibility problems stem from things that are defined by the ABI,
but which compilers decide to treat as Undefined because the Standard does
not explicitly state that a platform suitable for low-level programming on
a platform should support all of the semantics implied by its ABI.  It's
will generally not be necessary to have the actual machine state slavishly
follow the Abstract Machine state at every step, provided that they match
in places where it matters.  While it would be hard to determine with 100%
accuracy whether the ABI state and Abstract Machine state need to match at
each point, a conservative test that separates places where they don't
need to match from places where they *might*, and which identifies the vast
majority of places they don't need to match, will be almost as good as a
perfect test (while being a lot cheaper).

> I also take the viewpoint that when writing new code, people should do
> so using modern C standards unless they have an overwhelming reason not
> to.  And they should take advantage of the features the language
> provides in order to write clearer and safer code.

The C Standards don't recognize the concept of an ABI, nor any way of
ensuring it's synchronized with the Abstract Machine state at places where
that's required.

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

#120659

On Sunday, October 1, 2017 at 1:21:01 PM UTC-3, David Brown wrote:
...
> >> Why be so restrictive?  If I write
> >>
> >> const int abc = 100;
> >>
> >> and don't take the address of abc, there won't be any storage 
> >> associated with abc.
> > 
> 
> As always - you need "static" here in C.  (Ian perhaps writes too much 
> C++, and has forgotten this.)

This is new for me as well. 
Do you define constants static in headers?

--MyLib1.h--

static const int c1 = 1;

In C++, in my mind, this is bad because it was going
to create more instances of c1.
 
Is it the same in C?
If you take the address of c1 in two different
translations units then you end up with two storages?

I think there is nothing better in C (considering existing
features) than #define.

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

#120668

On 01/10/17 22:03, Thiago Adams wrote:
> On Sunday, October 1, 2017 at 1:21:01 PM UTC-3, David Brown wrote:
> ...
>>>> Why be so restrictive?  If I write
>>>>
>>>> const int abc = 100;
>>>>
>>>> and don't take the address of abc, there won't be any storage
>>>> associated with abc.
>>>
>>
>> As always - you need "static" here in C.  (Ian perhaps writes too much
>> C++, and has forgotten this.)
> 
> This is new for me as well.
> Do you define constants static in headers?
> 
> --MyLib1.h--
> 
> static const int c1 = 1;

Yes, that is exactly what I do - just like in C++ you would write "const 
int c1 = 1;" in a header.

> 
> In C++, in my mind, this is bad because it was going
> to create more instances of c1.

The compiler - assuming it is a good compiler - will not create /any/ 
instances of c1 at all, unless you use c1 in a way that forces it to be 
created (by taking its address and using it in a way that the compiler 
cannot optimise away).

If there is no "static" in C, or there is an "extern" in C++, then the 
compiler will have to create an instance of the object in the code image 
somewhere (typically a "rodata" or "const" section).  Like all objects, 
there should only be one definition in the program.

>   
> Is it the same in C?

You can pretend that in C++, all file-scope (and namespace scope) const 
definitions without an "extern" declaration have "static" in front of them.


> If you take the address of c1 in two different
> translations units then you end up with two storages?
> 

Yes, that is the way "static" works.

> I think there is nothing better in C (considering existing
> features) than #define.
> 

#define has some advantages that "static const" does not have. 
Efficiency here is not one of them - since you can't take the address of 
a #define'd literal, you can't compare its behaviour here.

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

#120654

On Saturday, September 30, 2017 at 4:11:06 PM UTC-5, Ian Collins wrote:
> On 10/ 1/17 09:50 AM, bartc wrote:
> > /That/ makes it more complicated. Being less versatile is better!
> 
> Not if you want versatility...

In general, versatility in some areas adds cost in others.  Adding in the
notion of functions that can return values that behave as compile-time
constants will have some definite benefits, but any such feature will
either be severely limited, turn compilation into the Halting Problem, or
require adding complicated rules to support advanced usages while still
ensuring that compilation remains Decidable.

If the authors of the Standard were more accepting of the idea that some
program texts may have more than one interpretation, or may be supportable
on some implementations but not others, then it would be practical and
useful to specify that a compiler should process a function as a constant
if convenient, but leaving the question of whether it does as a Quality of
Implementation issue.  On implementations that support VLAs it may be
necessary to have a syntax for "must not be variable" arrays, since
replacing an array whose size is a constant with an array whose size is
always computed as the same value can sometimes be a breaking change.

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

#120644

On 30/09/17 22:50, bartc wrote:
> On 30/09/2017 21:12, Ian Collins wrote:
>> On 10/ 1/17 06:44 AM, bartc wrote:
> 
>> There's nothing complicated about C++'s constexpr, it's just a more 
>> versatile const.
> 
> /That/ makes it more complicated. Being less versatile is better!

Let's understand this correctly.  You don't want C++'s version of 
"const", and certainly not its "constexpr", because that would be too 
complicated due to its versatility.

You want to make your own new idea of constants that is more versatile 
than C's "const", because that would be simple.

Is that right?

> 
>> C++'s const rules would work perfectly well in C, solving  all of your 
>> gripes.
> 
> My proposal could easily have been implemented in the 1970s, and no one 
> would have needed to switch to a heavyweight, cumbersome language ten 
> times the size just to avail themselves of that one feature.
> 
>> I for one have been moaning about the weakness of C's const for as 
>> long as I have been using C!  It's absurd that a language designed for 
>> low level and embedded programming lacks such a basic feature as "I 
>> want to put this stuff in read only memory please".
> 
> We're talking about different things then. My idea of a constant has no 
> notion of storage associated with it. It's the equivalent of an 
> immediate value in assembly.
> 
> This C fragment:
> 
>     const int abc=100;
>     abc;
> 
> in Nasm would naturally be expressed as:
> 
>          segment .data
>     abc: dd 100

(You mean a ".rodata" or ".const" section, not ".data".)

> 
>          segment .text
>          mov eax,[abc]
> 
> My idea of a named constant:
> 
>     constant def=200;
> 
> would be:
> 
>          segment .text
>          mov eax,200
> 
> See the difference? There is no data set aside, and there is no extra 
> memory access. constexpr would be the same as C's const variables.

One of the great joys of using a C compiler rather than assembly, is 
that the compiler does /not/ translate things directly into assembly in 
such a simplistic manner.  When you have "const int abc = 100;", the 
compiler knows the value of "abc".  It does not need to load it from the 
rodata section - it can use the value directly just like a #define. 
Good C programmers would usually declare such objects as "static", 
unless they were being exported, and then no space would be needed at 
all in memory.

Perhaps your C compiler is just a mindless translator, but mainstream 
compilers all do a fair amount of optimisation.  In my opinion, it is 
totally pointless discussing optimisation, efficiency, or code 
generation except in the context of a "reasonable" modern optimising 
compiler.  Yes, people will sometimes use simpler compilers, or good 
compilers with optimisations disabled - but no one expects top-quality 
code size or code speed from such compilations.  It does not matter if 
you get extra code when you use such tools - you don't use those tools 
for speed anyway.


> 
> However the attitude in this group is, forget this difference, just 
> write everything as variables with a readonly attribute, and asssume the 
> compiler can tidy things up and make use of an immediate if it can 
> figure out that it can.

I can't speak for this group, but /I/ let the compiler do its job.

However, part of that is that I know how to write C correctly, and I 
know how to write C in a way that will lead to more efficient code.  In 
particular, I know how to use the "static" keyword here.  You seem to 
have missed it, despite my using it repeatedly in posts in this thread. 
If you don't know what "static" means in this context, just ask - but if 
you /do/ know, then please stop omitting it and then complaining that 
the generated code is less efficient than you wanted.


> 
> But why rely on a compiler when one simple feature can spell it out 
> directly both for the machine and the reader?

Perhaps because the compiler already exists, the language already 
exists, and together they do a perfectly good job?  There is no need for 
an extra feature here - it is a waste to effort.

(Before you misunderstand me yet again, let me /again/ note that there 
are things I would want to change about "const".  But code efficiency is 
not the reason - that problem is already solved.)


> 
> (Note that for floating point, instruction sets tend not to have 
> floating point immediate values, or may not always have 64-bit integer 
> immediate values, so they also might need to go into memory anyway, 
> although that can /always/ be readonly memory.

Alternatively, you could use a good compiler that can handle floating 
point constants in a more sophisticated manner, such as pre-computing 
results in a target-accurate manner.

> 
> But the notion of a named constant value is always useful, and you 
> /know/ it must be treated as the equivalent of an immediate constant 
> value in the source code.)
> 

I agree that named constant values are often useful.  I disagree that 
knowing they will be treated like an immediate literal is particularly 
useful.  I think it is far more useful to know that the compiler will 
treat anything it knows at compile time in the same way for code 
generation, regardless of how that value is expressed in source code.

But I /do/ think C's "const" would be greatly improved by being viewed 
as constant expressions, like in C++.

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

#120647

On 01/10/2017 12:48, David Brown wrote:
> On 30/09/17 22:50, bartc wrote:
>> On 30/09/2017 21:12, Ian Collins wrote:
>>> On 10/ 1/17 06:44 AM, bartc wrote:
>>
>>> There's nothing complicated about C++'s constexpr, it's just a more 
>>> versatile const.
>>
>> /That/ makes it more complicated. Being less versatile is better!
> 
> Let's understand this correctly.  You don't want C++'s version of 
> "const", and certainly not its "constexpr", because that would be too 
> complicated due to its versatility.
> 
> You want to make your own new idea of constants that is more versatile 
> than C's "const", because that would be simple.
> 
> Is that right?

Yes. I said yesterday it took under an hour to get a version working. 
One hour to have a feature that does everything that static const can 
do, plus be usable as a constant expression for array bounds and case 
labels. Plus it is impossible to take the address of it.

Plus it is something everyone can understand.

-- 
bartc

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

#120649

On Sunday, October 1, 2017 at 6:48:33 AM UTC-5, David Brown wrote:
> One of the great joys of using a C compiler rather than assembly, is 
> that the compiler does /not/ translate things directly into assembly in 
> such a simplistic manner.  When you have "const int abc = 100;", the 
> compiler knows the value of "abc".  It does not need to load it from the 
> rodata section - it can use the value directly just like a #define. 
> Good C programmers would usually declare such objects as "static", 
> unless they were being exported, and then no space would be needed at 
> all in memory.

It is a joy in cases where the compiler's idea of reality matches with
the execution environment's idea of reality.  It is not so joyful at
other times.

Many platforms define an ABI which, if rigidly followed by a compiler at
every step of processing, would define behaviors in many cases where the
Standard imposes no requirements, a concept recognized by the Standard
as behaving in [iirc] "a documented fashion characteristic of the
environment".

Allowing a compiler to deviate from the ABI during stretches of code where
it *genuinely* doesn't matter can lead to much more efficient code.  What
is frustrating is some compiler writer's belief that the authors of the
Standard intended to fully define all the cases where such deviations *do*
matter, despite the fact that such cases will vary among different target platforms and application fields.

A compiler that assumed that adhered to the ABI precisely with all objects
whose address was taken, but not for static or automatic variables whose
address isn't, could generate much better code than gcc does at -o0, while
being compatible with code that would otherwise break at -o1.  Extending
optimizations to things whose address is taken, but where the compiler can
see everything that is done with the pointers, would allow code generation
to be improved further, again without breaking compatibility.

If a compiler writer were to make a bonafide effort to identify those parts
of the program which, considering upon the target platform and application
field, where rigid adherence to the ABI would be *extremely unlikely* to
matter, but followed the ABI rigidly in cases where there was even a slight
hind that it would matter, it wouldn't be able to perform 100% of all the
potential useful optimizations but it would be capable of correctly
processing the vast majority of existing code which needs to make use of
ABI features much more efficiently than gcc of clang can presently do.

Fundamentally, C programming is joyous in cases where compilers are eager
to accept that they don't know everything, but not so much when compilers
become more and more resistant to hints that they should simply follow the
platform ABI.

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

#120624

On Saturday, September 30, 2017 at 3:12:57 PM UTC-5, Ian Collins wrote:
> I for one have been moaning about the weakness of C's const for as long 
> as I have been using C!  It's absurd that a language designed for low 
> level and embedded programming lacks such a basic feature as "I want to 
> put this stuff in read only memory please".

Even though C was designed for low-level and embedded programming, the
authors of the Standard didn't want to require that all implementations
be suitable for such purposes.  As a result, even though many embedded
applications need common features, and many embedded platforms could
easily provide them in consistent fashion, there is no standard way to
request them.

If the Standard was really doing its job, it should be possible to write
low-level code for most platforms that could be expected to work on all
quality compilers suitable for use low-level programming on those platforms.
Some platforms require weird features that are sufficiently weird or obscure
that it would be impractical to put them in the Standard, but most platforms
have very a lot of features in common.  Concepts like "place a function or
an object at a certain address" aren't supportable on every platform, but
that doesn't mean the Standard shouldn't define a consistent means of
requesting them on platforms where they are supportable.

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

#120621

bartc <bc@freeuk.com> writes:
> On 30/09/2017 17:48, David Brown wrote:
>> On 29/09/17 15:24, bartc wrote:
>>> I think you're the only person ever to have voiced the same misgivings 
>>> about C's failings in this area as I have.
>> 
>> Why would you think that?
>
> The topic has been discussed many times, and the attitudes have always 
> been the same.

Wrong.

>> The methods available in C for defining constants are not as good as 
>> they could be - I have never seem anyone deny that. But they are also 
>> not nearly as bad as some people (such as yourself and Thiago) seem to 
>> think.
>
> As I said, there is a very simple, lightweight solution to the problem, 
> and they have been plenty of opportunities to introduce it, but no one 
> is interested in that.

You proposed:

    constant const1 1;

That's a new keyword and a new syntax that I've never seen anyone
else propose.  You expect the committee to adopt it without ever
having heard of it.  Meanwhile, C++ has an existing solution (`const
int n = 42;` making n a constant expression) that could be adopted
by C.  As it happens, clang appears to implement it as an extension;
gcc does not.

> They would rather look towards a heavyweight answer like C++'s 
> constexpr, which is like C's const variable but even more complicated. 
> That's not going to happen anytime time soon, so C's is stuck with what 
> it has.

I don't recall anyone mentioning constexpr.  But now that you
mention it, a simpler version of C++'s constexpr might be an even
better solution.  I don't think I'd suggest supporting constexpr
functions, but constexpr "variables" might be something to consider.
For example, in C++

    constexpr int n = 42;

makes `n` a constant expression and requires the initializer to be a
constant expression.  (I'm a bit surprised to find that `&n` is legal;
perhaps C needn't permit that.)  I find it cleaner than the C++
treatment of

    const int n = 42;

because (a) the compiler enforces making the initializer a constant
expression and (b) it doesn't blur the distinction between "constant"
(meaning evaluable at compile time) and "const" (meaning read-only).

[...]
> Meanwhile, suppose you had a task to automatically translate syntax 
> which already has that suggested feature, into readable C; how would you 
> do that?

Readability of intermediate code is not usually a requirement, but ok.
[...]
>                     #define is not an option, since the original uses 
> identifiers with normal scope rules.

Your translator could generate #undef directives at the end of the scope.

[...]

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

#120625

On 30/09/2017 21:35, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:

>> Meanwhile, suppose you had a task to automatically translate syntax
>> which already has that suggested feature, into readable C; how would you
>> do that?
> 
> Readability of intermediate code is not usually a requirement, but ok.

The people who sometimes looked at the C distributions of my project may 
disagree, if they had to look at what the code /could/ have looked like.


> [...]
>>                      #define is not an option, since the original uses
>> identifiers with normal scope rules.
> 
> Your translator could generate #undef directives at the end of the scope.

Notice that I said 'into readable C'.

If no one's going to read it, then forget it; just write the numbers 
directly in the source.

The point was there is no single solution in C that ticks all the boxes, 
but such a solution would have been trivially possible. (I believe a 
similar scheme was used in Algol68, which predated C.)

-- 
bartc

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

#120642

On 30/09/2017 21:58, bartc wrote:

> The point was there is no single solution in C that ticks all the boxes, 
> but such a solution would have been trivially possible. (I believe a 
> similar scheme was used in Algol68, which predated C.)

Not quite correct, the A68 version didn't use a special keyword, that 
was Pascal.

 From Algol 68 Genie docs:

"Suppose you want to use the integer 10000 in various parts of your 
program. Algol 68 provides a construct, an identity-declaration, that 
declares a synonym for a value (in this case, an integer-denotation). 
Similar constructions in other languages are CONST declarations in 
Pascal, PARAMETER statements in FORTRAN, or #define directives in the C 
preprocessor. Here is an identity-declaration for the above mentioned 
integer:"

The example was something like this:

   int A = 10000;

whereas declaring a variable with that initial value needs:

   int B := 10000;

One uses "=", the other ":=".

(My syntax would use "const" /and/ "=" for A, and ":=" like the above 
for B. "=" without "const" would declare a static variable with a value 
that is set at compile/load time, so is never assigned to.)

Notice however how the two concepts are clear: a synonym for a fixed 
value on the one hand, and a variable on the other. C's attempt to 
replace the limited #define and enum with 'const' mixes everything up.

-- 
bartc

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

#120626

On Saturday, September 30, 2017 at 5:35:27 PM UTC-3, Keith Thompson wrote:
...
> I don't recall anyone mentioning constexpr.  But now that you
> mention it, a simpler version of C++'s constexpr might be an even
> better solution.  I don't think I'd suggest supporting constexpr
> functions, but constexpr "variables" might be something to consider.
> For example, in C++

constexpr  does everything I suggest, except compound literal.
(I think they are trying to put compound literal on C++)

enum E {A = 1};
constexpr auto a = 1 + A;
constexpr auto s = "a";

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

#120632

Thiago Adams <thiago.adams@gmail.com> writes:
> On Saturday, September 30, 2017 at 5:35:27 PM UTC-3, Keith Thompson wrote:
> ...
>> I don't recall anyone mentioning constexpr.  But now that you
>> mention it, a simpler version of C++'s constexpr might be an even
>> better solution.  I don't think I'd suggest supporting constexpr
>> functions, but constexpr "variables" might be something to consider.
>> For example, in C++
>
> constexpr  does everything I suggest, except compound literal.
> (I think they are trying to put compound literal on C++)
>
> enum E {A = 1};

If the only purpose is to make A a constant expression with the value 1,
you don't need the tag:

    enum {A = 1};

> constexpr auto a = 1 + A;
> constexpr auto s = "a";

C++-style "auto" is a separate feature.  I wouldn't object if C adopted
it, but for C I'd say it's pretty much orthogonal to "constexpr".

    constexpr int a = 1 + A;
    constexpr char *s = "a";

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

#120657

On Saturday, September 30, 2017 at 6:00:23 PM UTC-3, Thiago Adams wrote:
... 
> constexpr  does everything I suggest, except compound literal.
> (I think they are trying to put compound literal on C++)
> 
> enum E {A = 1};
> constexpr auto a = 1 + A;
> constexpr auto s = "a";

Correction:
 
 - I am with Bart, I don´t want take address of constant.
   C++ allows that. 
 - I don´t want to use storage
 

#include <iostream>
constexpr auto i = 1;
int main() {
  const int *p = &i;
  std::cout << "Hello World!\n"<< *p;
}

--

In C++ it's possible to create constexpr structs 
like point'origin';

struct Point {int x, y; };
constexpr Point origin  {0,0};

This is similar of compound literal constant.

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

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

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

csiph-web