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

#120643

On 30/09/17 19:44, bartc wrote:
> 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.
> 

The attitudes of many of the C users in this group have been similar to 
each other, yes - but they have never been what you describe here.

Discussions with you would be a lot easier if you dropped the "you are 
either for me or against me" attitude.  You are neither a Sith, an 
American Republican President, nor a religious nutcase - you have no 
excuse for that habit.  A lot of people here /agree/ with you on several 
points - and I for one am a little fed up with being told what I think 
and what I have said.

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

First, much of what you think is a "problem" is /not/ a problem.  For 
example, I find it hard to see why anyone cares if you can take the 
address of a constant.  Obviously people sometimes /do/ want to take the 
address of a constant object, and that works fine with today's const 
objects.  But why would you specially want to be unable to take its 
address?  If you have something and you don't want to take its address, 
don't take its address.  You don't get a simpler solution than that.

Secondly, your lightweight solution may be fine for your own language - 
but that does not make it fine for C.

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

constexpr a good solution, and would work well in C - and it is /not/ 
just like C (or C++) "const".  It lets you make scoped named identifiers 
for constants that are constant expressions of a specific type.  It is 
also applicable to functions, which is rather useful - it means that you 
can initialise one constant from a function of other constants, and it 
lets you do a lot of compile-time calculations rather than run-time 
calculations.  (Imagine an embedded system for a motor controller, 
needing tables of pre-calculated sine values.  With C++ and constexpr, 
you can calculate the tables at compile time in C++, rather than using a 
different language to generate the tables and turn them into C code.)


I agree that it is not going to get added to C any time soon - but it 
has a much bigger chance of being added than a new and different way of 
making constants that has no precedence and adds little new to the 
language.

> 
> Meanwhile, suppose you had a task to automatically translate syntax 
> which already has that suggested feature, into readable C; how would you 
> do that? Here is what mine has to do; start with:
> 
> const a = 100             # 'const' means 'constant' or 'literal'
> const b = 200.1
> const c = a+b
> const d = 5000'000'000
> const e = d*c
> const f = 0xffff'ffff'ffff'ffff
> 

How about:

static const int a = 100;
static const double b = 200.1;
static const double c = 300.1;
static const int d = 5000000000;
static const double e = 5000000000 * 300.1;
static const unsigned long long f = 0xffffffffffffffff;

That does not look too bad to me.  I'd be happier to see the C++ 
improvements to const added here, allowing:

static const int a = 100;
static const double b = 200.1;
static const double c = a + b;
static const unsigned long long d = 5000'000'000;
static const double e = d * c;
static const unsigned long long f = 0xffff'ffff'ffff'ffff;

That would be a relatively small change to C, with no backwards 
compatibility issues (that I can think of), with easy support from 
compilers, and with a long history in C++.  I think allowing static 
const values as constant expressions is something that really should be 
added to C.  (Opinions vary on the use of ' as a digit separator.)

That is where I would like C to go.  I suspect it is something that 
people do today, when they say "I write C, but use a C++ compiler for 
better checking or features".


C++ goes further, allowing:

const auto a = 100;
const auto b = 200.1;
const auto c = a + b;
const auto d = 5000'000'000;
const auto e = d * c;
const auto f = 0xffff'ffff'ffff'ffff;

Making "const" here be "static" by default as it is in C++ would be an 
incompatible change to C.  And adding "auto" to C would cause a 
rebellion.  (gcc supports "__auto_type" in C, but seem slightly 
embarrassed about it - it is only mentioned as a footnote in the page 
about typeid.)



> With source code that merely evaluates each of these names in turn (ie. 
> a;b;c;d;e;f;), the resultant C is this:
> 
>   enum {a = 100};
>   enum {d = 5000000000ll};
>   enum {f = 18446744073709551615ull};
> 
>       a;
>       200.1;
>       300.1;
>       d;
>       1500500000000.0;
>       f;
> 
> Not that readable is it? 

That is a limitation of your translator, not of C.  See above for my 
much more readable version.

I also don't think there is any point in a translator from a different 
language making an effort to generate "readable" C code.  It might be a 
little help during your development of the translator, but it should not 
be something to worry about.  Typical generated C code is full of gotos, 
names like t1, t2, t3, ..., etc., and pre-calculated literals directly 
in the code.  It is always nicer if the code is readable, but it should 
be low down on your list of priorities here.

It is, of course, your choice how you want your generated code to look - 
but it is completely unreasonable to expect C to support prettier ways 
to express code from your translator.

> But also, the long enums are only handled 
> correctly by gcc; other compilers complain, or just give the wrong 
> values. 

The values used for an enumeration constant have to be representable as 
an int (6.7.2.2p2), so if my understanding of the standards is right, 
correct handling of longer values is to give a diagnostic.  gcc has a 
non-conforming extension here (a useful extension, perhaps, but 
non-conforming).  Compilers that complain are correct - compilers that 
just give the wrong values are non-conforming and not particularly helpful.

> So if only using enums for small ints, the C would be:
> 
>       a;
>       200.1;
>       300.1;
>       5000000000ll;
>       1500500000000.0;
>       18446744073709551615ull;
> 
> Even less readable. #define is not an option, since the original uses 
> identifiers with normal scope rules. Using C's const is not viable, 
> since I don't know what compiler will be used, whether it will be 
> optimised, or whether it will cause problems because the constant will 
> be used in a context where C demands a constant integer expression.
> 

"static const" is your best choice unless you need to use it as a 
constant expression.  If that is the case, then #define is the way.  But 
you can happily use long names to simulate scope - this is your 
generated code, after all:

#define _constant_filename_functionname_identifier 1234

Or whatever suites your fancy.  Since these have no lifetime, it does 
not matter where or when you define them, and scoping is just about 
avoiding conflicts with other identifiers.

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

#120645

On Sunday, October 1, 2017 at 12:13:17 PM UTC+1, David Brown wrote:
>
> That does not look too bad to me.  I'd be happier to see the C++ 
> improvements to const added here, allowing:
> 
> static const int a = 100;
> static const double b = 200.1;
> static const double c = a + b;
> static const unsigned long long d = 5000'000'000;
> static const double e = d * c;
> static const unsigned long long f = 0xffff'ffff'ffff'ffff;
> 
> That would be a relatively small change to C, with no backwards 
> compatibility issues (that I can think of), with easy support from 
> compilers, and with a long history in C++.  I think allowing static 
> const values as constant expressions is something that really should be 
> added to C.  (Opinions vary on the use of ' as a digit separator.)
> 
> That is where I would like C to go.  I suspect it is something that 
> people do today, when they say "I write C, but use a C++ compiler for 
> better checking or features".
> 
Problem is that people will soon demand

static const double theta = PI/4;
static const double sintheta = sin(theta);

C++ has rules for this, C doesn't.

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

#120653

On 01/10/17 14:22, Malcolm McLean wrote:
> On Sunday, October 1, 2017 at 12:13:17 PM UTC+1, David Brown wrote:
>>
>> That does not look too bad to me.  I'd be happier to see the C++
>> improvements to const added here, allowing:
>>
>> static const int a = 100;
>> static const double b = 200.1;
>> static const double c = a + b;
>> static const unsigned long long d = 5000'000'000;
>> static const double e = d * c;
>> static const unsigned long long f = 0xffff'ffff'ffff'ffff;
>>
>> That would be a relatively small change to C, with no backwards
>> compatibility issues (that I can think of), with easy support from
>> compilers, and with a long history in C++.  I think allowing static
>> const values as constant expressions is something that really should be
>> added to C.  (Opinions vary on the use of ' as a digit separator.)
>>
>> That is where I would like C to go.  I suspect it is something that
>> people do today, when they say "I write C, but use a C++ compiler for
>> better checking or features".
>>
> Problem is that people will soon demand
> 
> static const double theta = PI/4;

If you read my post, you would see that I would want C to adopt C++'s 
rule allowing const objects to be constant expressions - and therefore 
allow this initialisation of theta.


> static const double sintheta = sin(theta);
> 

This is more problematic, because it involves a function call.  That 
would mean either run-time initialisation of sintheta (as done in C++ 
before constexpr functions), or the use of constexpr functions.  I'd be 
quite happy to see constexpr functions in C (Keith said he would not, so 
clearly it is controversial - perhaps because it only works well if 
functions are defined locally or in headers, which would be 
non-idiomatic in C), but I would not want run-time initialisation of 
file-scope values in C.

I would, however, be happy with "better than what we have" rather than 
requiring something that covers all possibilities.

> C++ has rules for this, C doesn't.
> 

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

#120656

On Sunday, October 1, 2017 at 1:06:36 PM UTC-5, David Brown wrote:
> This is more problematic, because it involves a function call.  That 
> would mean either run-time initialisation of sintheta (as done in C++ 
> before constexpr functions), or the use of constexpr functions.  I'd be 
> quite happy to see constexpr functions in C (Keith said he would not, so 
> clearly it is controversial - perhaps because it only works well if 
> functions are defined locally or in headers, which would be 
> non-idiomatic in C), but I would not want run-time initialisation of 
> file-scope values in C.

On platforms that could support it, it would be useful to allow a means by
which compilation units could each specify a function that is supposed
to run before main().  Such a feature would need to be optional since it
would require linker features that some platforms may not support, but in
some cases it could be extremely helpful, especially in cases where code
generated by a freestanding implementation would have multiple entry points.
In such cases, it would be rather awkward to require that every entry
point include code to check whether initialization had been performed yet
and, if not, call the initial function of every module that has one.

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

#120658

On 01/10/2017 19:06, David Brown wrote:
> On 01/10/17 14:22, Malcolm McLean wrote:

>> Problem is that people will soon demand
>>
>> static const double theta = PI/4;
> 
> If you read my post, you would see that I would want C to adopt C++'s 
> rule allowing const objects to be constant expressions - and therefore 
> allow this initialisation of theta.
> 
> 
>> static const double sintheta = sin(theta);
>>
> 
> This is more problematic, because it involves a function call.

I tried this in my language (I can't do it easily in the C compiler 
because of how sin works):

     const pi       = 3.141592653589793238
     const theta    = pi/4
     const sintheta = sin(theta)

     println sintheta


Translated to C, the result is:

     printf("%f\n",0.70710678118654746);

Apart from the issues with named constants, this worked (sintheta 
becomes a constant expression) because 'sin' is a built-in  operator 
(actually it doesn't need the parentheses).

So it is easy to fold such expressions (although I had to add the couple 
of lines to support evaluating 'sin' as I hadn't bothered up to know).


> would mean either run-time initialisation of sintheta (as done in C++ 
> before constexpr functions), or the use of constexpr functions.  I'd be 
> quite happy to see constexpr functions in C (Keith said he would not, so 
> clearly it is controversial - perhaps because it only works well if 
> functions are defined locally or in headers, which would be 
> non-idiomatic in C), but I would not want run-time initialisation of 
> file-scope values in C.

Once again, I have quite an advanced little feature which was possible 
because I can keep things simple.

Yes it would be interesting to be able to do:

    const x = expr

where expr is any expression including arbitrary function calls, and for 
the compiler to investigate evaluating even the function calls at 
compile (even the external ones). But it gets hairy.

I know how to keep things practical (I have to because I don't have a 
team of hundreds working for 30 years on this stuff).

-- 
bartc

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

#120661

On Sunday, October 1, 2017 at 5:02:14 PM UTC-3, Bart wrote:
> On 01/10/2017 19:06, David Brown wrote:
> > On 01/10/17 14:22, Malcolm McLean wrote:
> 
> >> Problem is that people will soon demand
> >>
> >> static const double theta = PI/4;
> > 
> > If you read my post, you would see that I would want C to adopt C++'s 
> > rule allowing const objects to be constant expressions - and therefore 
> > allow this initialisation of theta.
> > 
> > 
> >> static const double sintheta = sin(theta);
> >>
> > 
> > This is more problematic, because it involves a function call.
> 
> I tried this in my language (I can't do it easily in the C compiler 
> because of how sin works):
> 
>      const pi       = 3.141592653589793238
>      const theta    = pi/4
>      const sintheta = sin(theta)
> 
>      println sintheta
> 
> 
> Translated to C, the result is:
> 
>      printf("%f\n",0.70710678118654746);
> 
> Apart from the issues with named constants, this worked (sintheta 
> becomes a constant expression) because 'sin' is a built-in  operator 
> (actually it doesn't need the parentheses).
> 
> So it is easy to fold such expressions (although I had to add the couple 
> of lines to support evaluating 'sin' as I hadn't bothered up to know).
> 
> 
> > would mean either run-time initialisation of sintheta (as done in C++ 
> > before constexpr functions), or the use of constexpr functions.  I'd be 
> > quite happy to see constexpr functions in C (Keith said he would not, so 
> > clearly it is controversial - perhaps because it only works well if 
> > functions are defined locally or in headers, which would be 
> > non-idiomatic in C), but I would not want run-time initialisation of 
> > file-scope values in C.
> 
> Once again, I have quite an advanced little feature which was possible 
> because I can keep things simple.
> 
> Yes it would be interesting to be able to do:
> 
>     const x = expr
> 
> where expr is any expression including arbitrary function calls, and for 
> the compiler to investigate evaluating even the function calls at 
> compile (even the external ones). But it gets hairy.
> 
> I know how to keep things practical (I have to because I don't have a 
> team of hundreds working for 30 years on this stuff).
> 

I think we have the same opinion here.
I like this syntax as well.

const name = expression;

The compiler internally has to change how it
deal with constant expressions.  Maybe you have
to change the meaning of constant expression 
inside the compiler.

for instance:

const C = 1;

switch()
{
 case C: break;
}

--


const C2 = "A";

switch()
{
 //case can use constant expressions except ""?
 case C2: break;
}

Also:

const I=(_Complex)(1+5*I);

 switch ()
{
 case I: break;
}

to make the switch for constant structs I think
you also have to introduce operator == for structs.

Introducing a language feature is like to solve a big
puzzle. But it´s interesting to test the ideas.
This is something I also can test in my C to C compiler.

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

#120664

On 01/10/2017 21:21, Thiago Adams wrote:
> On Sunday, October 1, 2017 at 5:02:14 PM UTC-3, Bart wrote:

> I think we have the same opinion here.
> I like this syntax as well.
> 
> const name = expression;
> 
> The compiler internally has to change how it
> deal with constant expressions.  Maybe you have
> to change the meaning of constant expression
> inside the compiler.
> 
> for instance:
> 
> const C = 1;

I preferred to use a different keyword (I used 'constant' in my test), 
because 'const' in C already has certain meanings some of which may not 
be compatible with what you want to do.

> 
> switch()
> {
>   case C: break;
> }
> 
> --
> 
> 
> const C2 = "A";

Here, the type of C2 is char*. It's a kind of constant, but not a 
compile-time one as the pointer involved is not known until runtime.

> switch()

Presumably some char* expression goes in ()?

> {
>   //case can use constant expressions except ""?
>   case C2: break;
> }

No, switch/case in C is specifically for integer values, and case labels 
must be integer labels.

You can try adapting switch by detecting the index type, but that's 
something I haven't tried. Switch to me means jump-table.

(I can handle this in my language, where switch is also for integers, by 
using a different kind of statement:

    const C2="A"
    const C3="B"
    ichar x="B"

    case x
    when C2 then println "x=C2"
    when C3 then println "x=C3"
    esac

Effectively if just compares x against C2 and C3 in turn. And compares 
only pointers (no strcmp is used). It happens to give the right answer 
here because the two "B" literals are stored at the same location. In 
general it won't work.)


> Also:
> 
> const I=(_Complex)(1+5*I);
> 
>   switch ()
> {
>   case I: break;
> }
> 
> to make the switch for constant structs I think
> you also have to introduce operator == for structs.

Yes do that first I think. But that will get short-shrift in this group 
they will think of every possible reason why it won't work, even though 
everyone just uses memcmp anyway.

-- 
bartc

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

#120687

On Sunday, October 1, 2017 at 5:50:38 PM UTC-3, Bart wrote:
> On 01/10/2017 21:21, Thiago Adams wrote:
> > On Sunday, October 1, 2017 at 5:02:14 PM UTC-3, Bart wrote:
> 
> > I think we have the same opinion here.
> > I like this syntax as well.
> > 
> > const name = expression;
> > 
> > The compiler internally has to change how it
> > deal with constant expressions.  Maybe you have
> > to change the meaning of constant expression
> > inside the compiler.
> > 
> > for instance:
> > 
> > const C = 1;
> 
> I preferred to use a different keyword (I used 'constant' in my test), 
> because 'const' in C already has certain meanings some of which may not 
> be compatible with what you want to do.

The only thing we disagree, is that I think the design is not 
simple. (maybe the implementation can be single)
The design is big puzzle. 
For instance, can we use this const inside struct?

struct X {
  constant A = 1;
};

It's not a bad idea, but then we need a way to
access it and more features are necessary
It's very hard to avoid complexity.

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

#120689

On 02/10/2017 13:35, Thiago Adams wrote:
> On Sunday, October 1, 2017 at 5:50:38 PM UTC-3, Bart wrote:

>> I preferred to use a different keyword (I used 'constant' in my test),
>> because 'const' in C already has certain meanings some of which may not
>> be compatible with what you want to do.
> 
> The only thing we disagree, is that I think the design is not
> simple. (maybe the implementation can be single)
> The design is big puzzle.
> For instance, can we use this const inside struct?
> 
> struct X {
>    constant A = 1;
> };
> 
> It's not a bad idea, but then we need a way to
> access it and more features are necessary
> It's very hard to avoid complexity.

You're trying to combine two different ideas.

My implementation of 'constant' (or as I threw it together the other 
day) introduces a new kind of declaration.

That declaration can be at file-scope, or at block-scope inside a function.

Inside the {...} of a struct declaration is different. Usually you can 
only declare things that would count as variables outside: ints, floats, 
pointers, and pointers to functions.

But not actual functions or anything else. So no typedef. No enum, 
unless also declaring variables with it. And no constant.

You can choose to extend the scope of structs so that those are included 
as inactive elements (when you create or allocate an instance of the 
struct, they take up no space). Then you're just encapsulating some 
kinds of declarations.

But that's a bigger feature than my 'constant'. And it will need a 
mechanism to access those internal elements, eg. X.A, or y.A when y is 
an instance, or z->A when z is pointer to an instance. Then it /does/ 
get complicated when trying to impose all this on an established language.

(But ironically, you can have #define inside a struct! Although it will 
be completely oblivious to that fact.)

-- 
bartc

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

#120693

On Monday, October 2, 2017 at 10:01:40 AM UTC-3, Bart wrote:
> On 02/10/2017 13:35, Thiago Adams wrote:
> > On Sunday, October 1, 2017 at 5:50:38 PM UTC-3, Bart wrote:
> 
> >> I preferred to use a different keyword (I used 'constant' in my test),
> >> because 'const' in C already has certain meanings some of which may not
> >> be compatible with what you want to do.
> > 
> > The only thing we disagree, is that I think the design is not
> > simple. (maybe the implementation can be single)
> > The design is big puzzle.
> > For instance, can we use this const inside struct?
> > 
> > struct X {
> >    constant A = 1;
> > };
> > 
> > It's not a bad idea, but then we need a way to
> > access it and more features are necessary
> > It's very hard to avoid complexity.
> 
> You're trying to combine two different ideas.
> 
> My implementation of 'constant' (or as I threw it together the other 
> day) introduces a new kind of declaration.
> 
> That declaration can be at file-scope, or at block-scope inside a function.
> 
> Inside the {...} of a struct declaration is different. Usually you can 
> only declare things that would count as variables outside: ints, floats, 
> pointers, and pointers to functions.
> 
> But not actual functions or anything else. So no typedef. No enum, 
> unless also declaring variables with it. And no constant.
> 
> You can choose to extend the scope of structs so that those are included 
> as inactive elements (when you create or allocate an instance of the 
> struct, they take up no space). Then you're just encapsulating some 
> kinds of declarations.
> 
> But that's a bigger feature than my 'constant'. And it will need a 
> mechanism to access those internal elements, eg. X.A, or y.A when y is 
> an instance, or z->A when z is pointer to an instance. Then it /does/ 
> get complicated when trying to impose all this on an established language.
> 
> (But ironically, you can have #define inside a struct! Although it will 
> be completely oblivious to that fact.)
> 
Compare with:

#include <stdio.h>
struct X {
    enum { A = 2 };
    int i;
};

int main()
{
    printf("%d", A);
    return 0;
}

One option is to put in global scope.

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

#120697

On 02/10/2017 14:29, Thiago Adams wrote:
> On Monday, October 2, 2017 at 10:01:40 AM UTC-3, Bart wrote:

>> (But ironically, you can have #define inside a struct! Although it will
>> be completely oblivious to that fact.)
>>
> Compare with:
> 
> #include <stdio.h>
> struct X {
>      enum { A = 2 };

This seems to work now; it didn't earlier.

>      int i;
> };
> 
> int main()
> {
>      printf("%d", A);
>      return 0;
> }

There is little point to doing that, as putting the enum inside the 
struct doesn't achieve anything.

More useful would be this:

  struct X{
    enum {A=2};
  }

Which co-exists with any outer A, and has to be accessed as X.A.

-- 
Bartc

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

#120669

On 01/10/17 22:01, bartc wrote:
> On 01/10/2017 19:06, David Brown wrote:
>> On 01/10/17 14:22, Malcolm McLean wrote:
> 
>>> Problem is that people will soon demand
>>>
>>> static const double theta = PI/4;
>>
>> If you read my post, you would see that I would want C to adopt C++'s 
>> rule allowing const objects to be constant expressions - and therefore 
>> allow this initialisation of theta.
>>
>>
>>> static const double sintheta = sin(theta);
>>>
>>
>> This is more problematic, because it involves a function call.
> 
> I tried this in my language (I can't do it easily in the C compiler 
> because of how sin works):
> 
>      const pi       = 3.141592653589793238
>      const theta    = pi/4
>      const sintheta = sin(theta)
> 
>      println sintheta
> 
> 
> Translated to C, the result is:
> 
>      printf("%f\n",0.70710678118654746);
> 
> Apart from the issues with named constants, this worked (sintheta 
> becomes a constant expression) because 'sin' is a built-in  operator 
> (actually it doesn't need the parentheses).
> 
> So it is easy to fold such expressions (although I had to add the couple 
> of lines to support evaluating 'sin' as I hadn't bothered up to know).

I tried this in my language :

void foo(void) {
   const double pi = 3.141592653589793238;
   const double theta = pi / 4;
   const double sintheta = sin(theta);
   printf("%f\n", sintheta);
}

The result was the same - a call to "printf" with parameters "%f\n" and 
a constant (which I presume is the same value - the assembly file gave 
it as " .long   1719614412" and ".long   1072079006").

In C++ - but not in C - the three "const" definitions can be moved to 
file-scope level, and the result is still /exactly/ the same.

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

#120670

On 01/10/2017 22:19, David Brown wrote:
> On 01/10/17 22:01, bartc wrote:
>> On 01/10/2017 19:06, David Brown wrote:
>>> On 01/10/17 14:22, Malcolm McLean wrote:
>>
>>>> Problem is that people will soon demand
>>>>
>>>> static const double theta = PI/4;
>>>
>>> If you read my post, you would see that I would want C to adopt C++'s 
>>> rule allowing const objects to be constant expressions - and 
>>> therefore allow this initialisation of theta.
>>>
>>>
>>>> static const double sintheta = sin(theta);
>>>>
>>>
>>> This is more problematic, because it involves a function call.
>>
>> I tried this in my language (I can't do it easily in the C compiler 
>> because of how sin works):
>>
>>      const pi       = 3.141592653589793238
>>      const theta    = pi/4
>>      const sintheta = sin(theta)
>>
>>      println sintheta
>>
>>
>> Translated to C, the result is:
>>
>>      printf("%f\n",0.70710678118654746);
>>
>> Apart from the issues with named constants, this worked (sintheta 
>> becomes a constant expression) because 'sin' is a built-in  operator 
>> (actually it doesn't need the parentheses).
>>
>> So it is easy to fold such expressions (although I had to add the 
>> couple of lines to support evaluating 'sin' as I hadn't bothered up to 
>> know).
> 
> I tried this in my language :
> 
> void foo(void) {
>    const double pi = 3.141592653589793238;
>    const double theta = pi / 4;
>    const double sintheta = sin(theta);
>    printf("%f\n", sintheta);
> }
>
> The result was the same

So what was problematical about it?

-- 
bartc

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

#120671

On 01/10/17 23:33, bartc wrote:
> On 01/10/2017 22:19, David Brown wrote:
>> On 01/10/17 22:01, bartc wrote:
>>> On 01/10/2017 19:06, David Brown wrote:
>>>> On 01/10/17 14:22, Malcolm McLean wrote:
>>>
>>>>> Problem is that people will soon demand
>>>>>
>>>>> static const double theta = PI/4;
>>>>
>>>> If you read my post, you would see that I would want C to adopt 
>>>> C++'s rule allowing const objects to be constant expressions - and 
>>>> therefore allow this initialisation of theta.
>>>>
>>>>
>>>>> static const double sintheta = sin(theta);
>>>>>
>>>>
>>>> This is more problematic, because it involves a function call.
>>>
>>> I tried this in my language (I can't do it easily in the C compiler 
>>> because of how sin works):
>>>
>>>      const pi       = 3.141592653589793238
>>>      const theta    = pi/4
>>>      const sintheta = sin(theta)
>>>
>>>      println sintheta
>>>
>>>
>>> Translated to C, the result is:
>>>
>>>      printf("%f\n",0.70710678118654746);
>>>
>>> Apart from the issues with named constants, this worked (sintheta 
>>> becomes a constant expression) because 'sin' is a built-in  operator 
>>> (actually it doesn't need the parentheses).
>>>
>>> So it is easy to fold such expressions (although I had to add the 
>>> couple of lines to support evaluating 'sin' as I hadn't bothered up 
>>> to know).
>>
>> I tried this in my language :
>>
>> void foo(void) {
>>    const double pi = 3.141592653589793238;
>>    const double theta = pi / 4;
>>    const double sintheta = sin(theta);
>>    printf("%f\n", sintheta);
>> }
>>
>> The result was the same
> 
> So what was problematical about it?
> 

The only problem I have is that in C, you can't put the const 
definitions at file scope in the same way - as you can in C++.  So my 
only serious issue with const in C is that I want it to copy such 
features from C++.  Then we would have what we need, and there would be 
no call for an extra "constant" keyword and feature to give a fourth 
kind of constant in C.

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

#120646

On 01/10/2017 12:13, David Brown wrote:
> On 30/09/17 19:44, bartc wrote:

>> const a = 100             # 'const' means 'constant' [...]
>> const b = 200.1
>> const c = a+b
>> const d = 5000'000'000
>> const e = d*c
>> const f = 0xffff'ffff'ffff'ffff
>>
> 
> How about:
> 
> static const int a = 100;
> static const double b = 200.1;
> static const double c = 300.1;
> static const int d = 5000000000;
> static const double e = 5000000000 * 300.1;

Why didn't you define c and e in terms of a+b and d*c? The idea is that 
if constant changes, then any dependent constant automatically does too.

And there's a bug here: d should be long long (and signed; your C++ has 
it unsigned), although no doubt /your/ compiler will point this out.

> static const unsigned long long f = 0xffffffffffffffff;

Using 5 keywords instead of one? No thanks! And static const int a still 
isn't as flexible as my 'constant a' in being a legal constant integer 
expression.

Here's how it looks in my modified C with 'constant':

  constant a = 100;
  constant b = 200.1;
  constant c = a+b;
  constant d = 5000000000;
  constant e = d*c;
  constant f = 0xffffffffffffffff;

  printf("a=%d\n",a);
  printf("b=%f\n",b);
  printf("c=%f\n",c);
  printf("d=%lld\n",d);
  printf("e=%f\n",e);
  printf("f=%llX\n",f);

(I think next might be %v format to save having to match up all the 
format codes.)

And here's the output to show it works:

  a=100
  b=200.100000
  c=300.100000
  d=5000000000
  e=1500500000000.000000
  f=FFFFFFFFFFFFFFFF

> C++ goes further, allowing:
> 
> const auto a = 100;
> const auto b = 200.1;
> const auto c = a + b;
> const auto d = 5000'000'000;
> const auto e = d * c;
> const auto f = 0xffff'ffff'ffff'ffff;

OK, it's almost up to where I got last might with my 60-line tweak to C.


> It is, of course, your choice how you want your generated code to look - 
> but it is completely unreasonable to expect C to support prettier ways 
> to express code from your translator.

The intent was to show the limited options available in the general case.

(Although it is probably true that 90% of named constants are small 
integers definable as enums.)

> #define _constant_filename_functionname_identifier 1234

If I really didn't care what generated code looked like, I would just 
use 1234 within the source. (Or even - something I tried once - write 
floating point constants as integer constants representing the bit pattern.)

-- 
bartc

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

#120663

On 01/10/17 15:13, bartc wrote:
> On 01/10/2017 12:13, David Brown wrote:
>> On 30/09/17 19:44, bartc wrote:
> 
>>> const a = 100             # 'const' means 'constant' [...]
>>> const b = 200.1
>>> const c = a+b
>>> const d = 5000'000'000
>>> const e = d*c
>>> const f = 0xffff'ffff'ffff'ffff
>>>
>>
>> How about:
>>
>> static const int a = 100;
>> static const double b = 200.1;
>> static const double c = 300.1;
>> static const int d = 5000000000;
>> static const double e = 5000000000 * 300.1;
> 
> Why didn't you define c and e in terms of a+b and d*c? 

Because it is not allowed in C?  Isn't that a good enough reason?

> The idea is that 
> if constant changes, then any dependent constant automatically does too.

You snipped my suggested code that would be allowed in C if it borrowed 
a small amount from C++ - in particular, it would allow c and e to be 
defined from a + b and d * c.

> 
> And there's a bug here: d should be long long (and signed; your C++ has 
> it unsigned), although no doubt /your/ compiler will point this out.

Yes, my compiler would point that out.  And I put in the "unsigned" for 
variety, because it seemed natural to me - but you can choose whatever 
makes sense to you.

> 
>> static const unsigned long long f = 0xffffffffffffffff;
> 
> Using 5 keywords instead of one? No thanks! And static const int a still 
> isn't as flexible as my 'constant a' in being a legal constant integer 
> expression.

For the hundred-and-oneth time - /yes/, I /know/ a static const is not a 
constant expression in C.  But the language would be better if it were - 
it should copy that feature from C++.  Then pretty much every discussion 
about constants in C would evaporate, except for your personal crusade 
to create constants whose address cannot be taken.

And in my own code, I'd write:

static const uint64_t f = 0xffffffffffffffff;

It's shorter and more explicit.

> 
> Here's how it looks in my modified C with 'constant':
> 
>   constant a = 100;
>   constant b = 200.1;
>   constant c = a+b;
>   constant d = 5000000000;
>   constant e = d*c;
>   constant f = 0xffffffffffffffff;
> 
>   printf("a=%d\n",a);
>   printf("b=%f\n",b);
>   printf("c=%f\n",c);
>   printf("d=%lld\n",d);
>   printf("e=%f\n",e);
>   printf("f=%llX\n",f);
> 
> (I think next might be %v format to save having to match up all the 
> format codes.)
> 
> And here's the output to show it works:
> 
>   a=100
>   b=200.100000
>   c=300.100000
>   d=5000000000
>   e=1500500000000.000000
>   f=FFFFFFFFFFFFFFFF
> 
>> C++ goes further, allowing:
>>
>> const auto a = 100;
>> const auto b = 200.1;
>> const auto c = a + b;
>> const auto d = 5000'000'000;
>> const auto e = d * c;
>> const auto f = 0xffff'ffff'ffff'ffff;
> 
> OK, it's almost up to where I got last might with my 60-line tweak to C.
> 

These (in C and C++) are typed objects, and can be of types other than 
simple integers and floating point values.

What you have with your "constant" is already available in C (and C++) 
with #define.  The single missing feature is that #define names don't 
follow C scoping rules.  That should hardly be a big problem for you, 
who don't like scopes anyway.

> 
>> It is, of course, your choice how you want your generated code to look 
>> - but it is completely unreasonable to expect C to support prettier 
>> ways to express code from your translator.
> 
> The intent was to show the limited options available in the general case.
> 
> (Although it is probably true that 90% of named constants are small 
> integers definable as enums.)
> 
>> #define _constant_filename_functionname_identifier 1234
> 
> If I really didn't care what generated code looked like, I would just 
> use 1234 within the source. (Or even - something I tried once - write 
> floating point constants as integer constants representing the bit 
> pattern.)
> 

Yes, that sounds a more reasonable attitude - and it would be sure to 
give efficient code even on limited compilers.  That is the way most 
compilers generate their assembly.  If "a" is the constant 123, and you 
write "x = 2 * a;", then they will generate the instruction "mov x, 246" 
regardless of whether "a" is a const (static or not, local or 
file-scope), a #define, or an enumeration constant.  The compiler might 
- for the convenience of people reading the code - put "a" in a comment, 
or perhaps "x = a;" in the comment.

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

#120665

On 01/10/2017 21:46, David Brown wrote:
> On 01/10/17 15:13, bartc wrote:
>> On 01/10/2017 12:13, David Brown wrote:
>>> On 30/09/17 19:44, bartc wrote:
>>
>>>> const a = 100             # 'const' means 'constant' [...]
>>>> const b = 200.1
>>>> const c = a+b
>>>> const d = 5000'000'000
>>>> const e = d*c
>>>> const f = 0xffff'ffff'ffff'ffff
>>>>
>>>
>>> How about:
>>>
>>> static const int a = 100;
>>> static const double b = 200.1;
>>> static const double c = 300.1;
>>> static const int d = 5000000000;
>>> static const double e = 5000000000 * 300.1;
>>
>> Why didn't you define c and e in terms of a+b and d*c? 
> 
> Because it is not allowed in C?  Isn't that a good enough reason?

Are you sure? This seemed to work fine with gcc:

  static const int a = 100;
  static const double b = 200.1;
  static const double c = a+b;
  static const long long int d = 5000000000;
  static const double e = d*c;
  static const unsigned long long f = 0xffffffffffffffff;

(And yes gcc did tell me about the overflow.)

> What you have with your "constant" is already available in C (and C++) 
> with #define.  The single missing feature is that #define names don't 
> follow C scoping rules.  That should hardly be a big problem for you, 
> who don't like scopes anyway.

I posted a number of other issues to do with #define a day or two ago.

Note that I do need function scopes. It's the billion possible block 
scopes I don't need.

-- 
bartc

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

#120667

bartc <bc@freeuk.com> writes:
> On 01/10/2017 21:46, David Brown wrote:
>> On 01/10/17 15:13, bartc wrote:
[...]
>>> Why didn't you define c and e in terms of a+b and d*c? 
>> 
>> Because it is not allowed in C? Isn't that a good enough reason?
>
> Are you sure? This seemed to work fine with gcc:
>
>   static const int a = 100;
>   static const double b = 200.1;
>   static const double c = a+b;
>   static const long long int d = 5000000000;
>   static const double e = d*c;
>   static const unsigned long long f = 0xffffffffffffffff;
>
> (And yes gcc did tell me about the overflow.)

On my system (Ubuntu 17.04, gcc 6.3.0, x86_64):

    $ cat c.c
    static const int a = 100;
    static const double b = 200.1;
    static const double c = a+b;
    static const long long int d = 5000000000;
    static const double e = d*c;
    static const unsigned long long f = 0xffffffffffffffff;
    $ gcc -c c.c
    c.c:3:25: error: initializer element is not constant
     static const double c = a+b;
                             ^
    c.c:5:25: error: initializer element is not constant
     static const double e = d*c;
                             ^
    $ 

I get the same error messages if the declarations are at block 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]

#120672

On 01/10/2017 22:09, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
>> On 01/10/2017 21:46, David Brown wrote:
>>> On 01/10/17 15:13, bartc wrote:
> [...]
>>>> Why didn't you define c and e in terms of a+b and d*c?
>>>
>>> Because it is not allowed in C? Isn't that a good enough reason?
>>
>> Are you sure? This seemed to work fine with gcc:
>>
>>    static const int a = 100;
>>    static const double b = 200.1;
>>    static const double c = a+b;
>>    static const long long int d = 5000000000;
>>    static const double e = d*c;
>>    static const unsigned long long f = 0xffffffffffffffff;
>>
>> (And yes gcc did tell me about the overflow.)
> 
> On my system (Ubuntu 17.04, gcc 6.3.0, x86_64):
> 
>      $ cat c.c
>      static const int a = 100;
>      static const double b = 200.1;
>      static const double c = a+b;
>      static const long long int d = 5000000000;
>      static const double e = d*c;
>      static const unsigned long long f = 0xffffffffffffffff;
>      $ gcc -c c.c
>      c.c:3:25: error: initializer element is not constant
>       static const double c = a+b;
>                               ^
>      c.c:5:25: error: initializer element is not constant
>       static const double e = d*c;
>                               ^
>      $
> 
> I get the same error messages if the declarations are at block scope.

OK, I understand: this is a problem at file-scope. And it's the same 
problem that stops you using such a value for a fixed array bound or for 
a case-label.

(But it demonstrates my concern that using static/const rather than a 
dedicated feature, you might not be entirely sure what is happening. 
With I tried it and it worked, I thought those names were genuinely 
constants.)

-- 
bartc

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

#120676

bartc <bc@freeuk.com> writes:
> On 01/10/2017 22:09, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>>> On 01/10/2017 21:46, David Brown wrote:
>>>> On 01/10/17 15:13, bartc wrote:
>> [...]
>>>>> Why didn't you define c and e in terms of a+b and d*c?
>>>>
>>>> Because it is not allowed in C? Isn't that a good enough reason?
>>>
>>> Are you sure? This seemed to work fine with gcc:
>>>
>>>    static const int a = 100;
>>>    static const double b = 200.1;
>>>    static const double c = a+b;
>>>    static const long long int d = 5000000000;
>>>    static const double e = d*c;
>>>    static const unsigned long long f = 0xffffffffffffffff;
>>>
>>> (And yes gcc did tell me about the overflow.)
>> 
>> On my system (Ubuntu 17.04, gcc 6.3.0, x86_64):
>> 
>>      $ cat c.c
>>      static const int a = 100;
>>      static const double b = 200.1;
>>      static const double c = a+b;
>>      static const long long int d = 5000000000;
>>      static const double e = d*c;
>>      static const unsigned long long f = 0xffffffffffffffff;
>>      $ gcc -c c.c
>>      c.c:3:25: error: initializer element is not constant
>>       static const double c = a+b;
>>                               ^
>>      c.c:5:25: error: initializer element is not constant
>>       static const double e = d*c;
>>                               ^
>>      $
>> 
>> I get the same error messages if the declarations are at block scope.
>
> OK, I understand: this is a problem at file-scope. And it's the same 
> problem that stops you using such a value for a fixed array bound or for 
> a case-label.

Do you understand that the initializer for a static object must be a
constant expression either at file scope or at block scope?  You say you
didn't get a complaint from gcc.  I'm skeptical.  Did you try that exact
code, or did you omit the "static" keyword?  Please try it again with
the exact code that you posted above.

The point is that static objects are created and initialized before
main() begins, and C has no mechanism for running code at that point.

> (But it demonstrates my concern that using static/const rather than a 
> dedicated feature, you might not be entirely sure what is happening. 
> With I tried it and it worked, I thought those names were genuinely 
> constants.)

Knowing that "const" doesn't mean "constant" might have prevented that
misunderstanding.

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

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

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

csiph-web