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

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

Is enum a suitable way to implement a "local define?"

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

Contents

  Is enum a suitable way to implement a "local define?" partremmaps@gmail.com - 2014-04-05 13:07 -0700
    Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-05 13:55 -0700
    Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-05 14:14 -0700
      Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-06 22:18 +0200
        Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-06 13:28 -0700
        Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-06 16:35 -0400
        Re: Is enum a suitable way to implement a "local define?" Ian Collins <ian-news@hotmail.com> - 2014-04-07 08:55 +1200
          Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-06 23:30 +0200
            Re: Is enum a suitable way to implement a "local define?" Ian Collins <ian-news@hotmail.com> - 2014-04-07 10:12 +1200
            Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-06 18:22 -0400
    Re: Is enum a suitable way to implement a "local define?" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-05 14:30 -0700
    Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-05 22:39 +0100
      Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-06 22:27 +0200
        Re: Is enum a suitable way to implement a "local define?" Ian Collins <ian-news@hotmail.com> - 2014-04-07 08:52 +1200
        Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-06 23:20 +0100
          Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-07 02:17 +0200
            Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-06 19:00 -0700
              Re: Is enum a suitable way to implement a "local define?" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-07 04:44 +0000
                Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-07 10:15 +0100
                  Re: Is enum a suitable way to implement a "local define?" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-07 18:32 +0000
                  Re: Is enum a suitable way to implement a "local define?" Kaz Kylheku <kaz@kylheku.com> - 2014-04-07 18:47 +0000
                Re: Is enum a suitable way to implement a "local define?" Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-04-07 11:39 +0200
              Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-07 08:58 +0200
                Re: Is enum a suitable way to implement a "local define?" Ian Collins <ian-news@hotmail.com> - 2014-04-07 19:34 +1200
                  Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-07 09:41 +0100
                    Re: Is enum a suitable way to implement a "local define?" Ian Collins <ian-news@hotmail.com> - 2014-04-07 21:45 +1200
                      Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-07 11:03 +0100
                        Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-07 12:54 +0200
                          Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-07 13:48 +0100
                            Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-07 15:27 +0200
                        Re: Is enum a suitable way to implement a "local define?" Ian Collins <ian-news@hotmail.com> - 2014-04-07 23:00 +1200
                  Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-07 11:31 +0200
                    Re: Is enum a suitable way to implement a "local define?" Les Cargill <lcargill99@comcast.com> - 2014-04-07 07:24 -0500
                      Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-07 15:02 +0200
            Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-07 10:19 +0100
              Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-07 12:43 +0200
                Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-07 13:27 +0100
                  Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-07 15:16 +0200
                    Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-07 14:43 +0100
                      Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-07 16:44 +0200
                        Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-07 16:52 +0100
                          Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-07 12:53 -0400
                            Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-07 12:59 -0400
                            Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-07 18:12 +0100
                            Re: Is enum a suitable way to implement a "local define?" Richard <rgrdev_@gmail.com> - 2014-04-07 18:27 +0100
                            Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-08 23:22 +0100
                              Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-08 18:44 -0400
                                Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-09 00:22 +0100
                          Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-08 09:39 +0200
                            Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-08 23:27 +0100
                              Re: Is enum a suitable way to implement a "local define?" Ian Collins <ian-news@hotmail.com> - 2014-04-09 10:52 +1200
                                Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-09 00:24 +0100
                                  Re: Is enum a suitable way to implement a "local define?" Ian Collins <ian-news@hotmail.com> - 2014-04-09 11:32 +1200
                                    Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-09 08:58 +0200
                                  Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-08 19:54 -0400
                                    Re: Is enum a suitable way to implement a "local define?" Kaz Kylheku <kaz@kylheku.com> - 2014-04-09 00:41 +0000
                              Re: Is enum a suitable way to implement a "local define?" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-08 23:05 +0000
                              Re: Is enum a suitable way to implement a "local define?" Stephen Sprunk <stephen@sprunk.org> - 2014-04-08 18:24 -0500
                              Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-08 19:39 -0400
                                Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-08 22:41 -0700
                                Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-09 09:16 +0200
                                  Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-09 07:27 -0400
                                    Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-09 15:32 +0200
                                      Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-09 08:32 -0700
                                        Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-10 11:03 +0200
                                          Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-10 07:27 -0400
                                            Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-10 14:02 +0200
                                          Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-10 08:34 -0700
                                            Re: Is enum a suitable way to implement a "local define?" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-10 16:36 +0000
                                              Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-10 12:58 -0400
                                      Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-09 11:36 -0400
                                  Re: Is enum a suitable way to implement a "local define?" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-09 18:36 +0000
                                    Re: Is enum a suitable way to implement a "local define?" Stephen Sprunk <stephen@sprunk.org> - 2014-04-09 14:11 -0500
                                      Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-10 13:55 +0200
                              Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-09 02:35 +0200
                                Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-08 23:05 -0700
                                  Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-09 09:45 +0200
                                    Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-09 08:19 -0700
                                      Re: Is enum a suitable way to implement a "local define?" Richard <rgrdev_@gmail.com> - 2014-04-10 09:08 +0100
                                        Re: Is enum a suitable way to implement a "local define?" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-10 02:57 -0700
                                          Re: Is enum a suitable way to implement a "local define?" Richard <rgrdev_@gmail.com> - 2014-04-10 11:50 +0100
                                  Re: Is enum a suitable way to implement a "local define?" Seungbeom Kim <musiphil@bawi.org> - 2014-04-10 11:37 -0700
                                    Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-10 14:52 -0400
                                    Re: Is enum a suitable way to implement a "local define?" Kaz Kylheku <kaz@kylheku.com> - 2014-04-10 18:53 +0000
                                      Re: Is enum a suitable way to implement a "local define?" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-10 19:36 +0000
                                        Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-10 15:59 -0400
                                          Re: Is enum a suitable way to implement a "local define?" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-10 20:12 +0000
                                            Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-10 16:18 -0400
                                        Re: Is enum a suitable way to implement a "local define?" Martin Shobe <martin.shobe@yahoo.com> - 2014-04-11 10:24 -0500
                                          Re: Is enum a suitable way to implement a "local define?" Martin Shobe <martin.shobe@yahoo.com> - 2014-04-11 14:36 -0500
                                        Re: Is enum a suitable way to implement a "local define?" David Thompson <dave.thompson2@verizon.net> - 2014-05-25 16:44 -0400
                                    Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-10 12:47 -0700
                                      Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-10 16:05 -0400
                                        Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-10 13:34 -0700
                                          Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-10 16:59 -0400
                                            Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-10 16:01 -0700
                                      Re: Is enum a suitable way to implement a "local define?" Tim Rentsch <txr@alumni.caltech.edu> - 2014-04-14 21:24 -0700
                                  Re: Is enum a suitable way to implement a "local define?" Tim Rentsch <txr@alumni.caltech.edu> - 2014-04-14 21:36 -0700
                                    Re: Is enum a suitable way to implement a "local define?" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-15 05:26 +0000
                                      Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-15 07:18 -0400
                                        Re: Is enum a suitable way to implement a "local define?" Tim Rentsch <txr@alumni.caltech.edu> - 2014-04-18 09:01 -0700
                                Please ignore trolls Noob <root@127.0.0.1> - 2014-04-09 15:26 +0200
                                  Re: Please ignore trolls David Brown <david.brown@hesbynett.no> - 2014-04-09 15:38 +0200
                                    Re: Please ignore trolls James Kuyper <jameskuyper@verizon.net> - 2014-04-09 12:02 -0400
                                    Re: Please ignore trolls Kaz Kylheku <kaz@kylheku.com> - 2014-04-09 19:18 +0000
                                      Re: Please ignore trolls "BartC" <bc@freeuk.com> - 2014-04-10 20:18 +0100
                                        Re: Please ignore trolls James Kuyper <jameskuyper@verizon.net> - 2014-04-10 15:49 -0400
                                          Re: Please ignore trolls gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-10 20:14 +0000
                                            Re: Please ignore trolls "BartC" <bc@freeuk.com> - 2014-04-11 14:35 +0100
                                              Re: Please ignore trolls Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-11 07:35 -0700
                                                Re: Please ignore trolls "BartC" <bc@freeuk.com> - 2014-04-11 15:51 +0100
                                                  Re: Please ignore trolls Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-04-12 15:48 +0000
                                        Re: Please ignore trolls Kaz Kylheku <kaz@kylheku.com> - 2014-04-10 21:16 +0000
                                          Re: Please ignore trolls "BartC" <bc@freeuk.com> - 2014-04-12 15:35 +0100
                                  Re: Please ignore trolls Keith Thompson <kst-u@mib.org> - 2014-04-09 08:03 -0700
                                    Re: Please ignore trolls gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-09 15:25 +0000
                                Re: Is enum a suitable way to implement a "local define?" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-09 21:28 +0100
                                  Re: Is enum a suitable way to implement a "local define?" Ian Collins <ian-news@hotmail.com> - 2014-04-10 08:39 +1200
                                    Re: Is enum a suitable way to implement a "local define?" Kaz Kylheku <kaz@kylheku.com> - 2014-04-09 23:38 +0000
                                      Re: Is enum a suitable way to implement a "local define?" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-10 02:07 +0100
                              Re: Is enum a suitable way to implement a "local define?" Ike Naar <ike@iceland.freeshell.org> - 2014-04-09 05:18 +0000
                                Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-09 08:05 -0700
              Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-07 08:33 -0700
                Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-07 17:16 +0100
                  Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-07 11:07 -0700
                    Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-08 09:49 +0200
                      Re: Is enum a suitable way to implement a "local define?" Ian Collins <ian-news@hotmail.com> - 2014-04-08 20:33 +1200
                        Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-08 12:31 +0200
                          Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-08 21:59 -0400
                      Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-08 07:37 -0700
                Re: Is enum a suitable way to implement a "local define?" Stephen Sprunk <stephen@sprunk.org> - 2014-04-08 08:35 -0500
                  Re: Is enum a suitable way to implement a "local define?" Seungbeom Kim <musiphil@bawi.org> - 2014-04-08 11:30 -0700
                    Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-08 23:46 +0100
                    Re: Is enum a suitable way to implement a "local define?" Stephen Sprunk <stephen@sprunk.org> - 2014-04-08 18:28 -0500
                      Re: Is enum a suitable way to implement a "local define?" Seungbeom Kim <musiphil@bawi.org> - 2014-04-08 17:21 -0700
                      Re: Is enum a suitable way to implement a "local define?" "BartC" <bc@freeuk.com> - 2014-04-09 09:07 +0100
                        Re: Is enum a suitable way to implement a "local define?" James Kuyper <jameskuyper@verizon.net> - 2014-04-09 07:22 -0400
        Re: Is enum a suitable way to implement a "local define?" Keith Thompson <kst-u@mib.org> - 2014-04-06 16:25 -0700
          Re: Is enum a suitable way to implement a "local define?" David Brown <david.brown@hesbynett.no> - 2014-04-07 02:22 +0200
    Re: Is enum a suitable way to implement a "local define?" Ike Naar <ike@iceland.freeshell.org> - 2014-04-06 06:08 +0000
    Re: Is enum a suitable way to implement a "local define?" jacob navia <jacob@spamsink.net> - 2014-04-06 08:54 +0200
    Re: Is enum a suitable way to implement a "local define?" partremmaps@gmail.com - 2014-04-07 23:48 -0700

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

#42662

On 2014-04-07, BartC <bc@freeuk.com> wrote:
> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
>> In case anyone is interested, Java does it with "static final".
>
> What is it with language designers and the need to beat around the bush with 
> these things and not call things what they actually are?

The curious, new vocabulary that appears in new computing projects is
the simple consequence of ignorance of prior art.

If, say, electrical engineering were like computing, the new crop of EE's would
be calling resistors "opposers".

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

#42637

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> Keith Thompson <kst-u@mib.org> wrote:
>
> (snip)
>
>> I can imagine "const sizeMax = 1024" being perfectly reasonable in some
>> other language, where the type of sizeMax is inferred from the type of
>> the initializer.  C++'s relatively new reuse of the "auto" keyword
>> allows something similar:
>  
>>    auto sizeMax = 1024;
>  
>> If I were to suggest a new feature for C, and if I didn't feel like
>> accounting for C++ compatibility, I might add a new "constant" keyword,
>> where
>  
>>    constant identifier = constant-expression;
>
> In case anyone is interested, Java does it with "static final".

For primitive types only. For class-like types (i.e., a reference to an
object), "final" only guarantees that the variable will not be rebound,
but the value of the bound object can be modified.

BTW, C++ now also has "constexpr", which goes way beyond "const",
because complete expressions (including function calls) may be evaluated
at compile time.

-- Alain.

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

#42627

On 07/04/14 04:00, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 07/04/14 00:20, BartC wrote:
> [...]
>>> (It's a little crazy really; I have now several language projects where I
>>> translate source code that has 'proper' named constants, into actual C. Did
>>> I use #defines, or enums? Both have limitations to do with scope and type.
>>> But I've just checked and the solution I came up with was the following; if
>>> the source uses this (made C-like so as not to frighten anyone):
>>>
>>> const sizeMax = 1024      /* 'int' is optional */
>>
>> "int" is not optional in well-written code, IMHO.
> 
> "int" is not optional in C, and it hasn't been since 1999.  But I think
> BartC meant that to be some C-like language, not C itself.
> 
> I can imagine "const sizeMax = 1024" being perfectly reasonable in some
> other language, where the type of sizeMax is inferred from the type of
> the initializer.  C++'s relatively new reuse of the "auto" keyword
> allows something similar:
> 
>     auto sizeMax = 1024;
> 
> If I were to suggest a new feature for C, and if I didn't feel like
> accounting for C++ compatibility, I might add a new "constant" keyword,
> where
> 
>     constant identifier = constant-expression;
> 
> would make "identifier" an alias for the given constant expression.
> For example:
> 
>     constant maxSize = 1024;
> 
> would be equivalent to
> 
>     enum { maxSize = 1024 };

If this were a democracy, I'd vote for such a keyword.  I guess the type
of the constant would be determined much like with "auto" in C++.

However, I think you could come far by just allowing C to use const
values as compile-time constants (and thus as array sizes, switch
labels, etc.).  It works in C++ - there is no reason why it should not
work the same in C.  The differences between C++ const and C const
should not affect things here.

> 
> and it would also permit expressions of other types.
> 
> It would also require programmers to understand the difference between
> "const" (which means read-only) and "constant" (which refers to
> expressions that are evaluated at compile time).  If I didn't care about
> backward compatibility, I'd re-spell "const" as "readonly", but that's a
> non-starter.
> 

I believe "const" started out as "readonly" in the early days of C++, or
"C with objects".  Keeping it as "readonly" would have avoiding the
somewhat awkward keyword "constexpr" to mean /really/ constant.

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

#42629

David Brown wrote:
>
> I believe "const" started out as "readonly" in the early days of C++, or
> "C with objects".  Keeping it as "readonly" would have avoiding the
> somewhat awkward keyword "constexpr" to mean /really/ constant.

C++'s "constexpr" goes beyond constant values and includes constant 
expressions.  It also forces expressions to be evaluated at compiles 
time, which is useful for embedded work where compile time constants can 
be stored in non-volatile memory.

Like C=='s const,  "constexpr" would be another worthwhile addition to C.

-- 
Ian Collins

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

#42633

"Ian Collins" <ian-news@hotmail.com> wrote in message 
news:bqf2nbFtpsdU2@mid.individual.net...
> David Brown wrote:
>>
>> I believe "const" started out as "readonly" in the early days of C++, or
>> "C with objects".  Keeping it as "readonly" would have avoiding the
>> somewhat awkward keyword "constexpr" to mean /really/ constant.
>
> C++'s "constexpr" goes beyond constant values and includes constant 
> expressions.  It also forces expressions to be evaluated at compiles time, 
> which is useful for embedded work where compile time constants can be 
> stored in non-volatile memory.

I thought it would go without saying that in a feature such as:

 constant name = value;

that 'value' would have to be an expression. Otherwise it would have bigger 
limitations than any of #define, enum or const.

Obviously the expression can only includes terms that are actual constants, 
or previous named constants.

-- 
BartC

 

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

#42638

BartC wrote:
> "Ian Collins" <ian-news@hotmail.com> wrote in message
> news:bqf2nbFtpsdU2@mid.individual.net...
>> David Brown wrote:
>>>
>>> I believe "const" started out as "readonly" in the early days of C++, or
>>> "C with objects".  Keeping it as "readonly" would have avoiding the
>>> somewhat awkward keyword "constexpr" to mean /really/ constant.
>>
>> C++'s "constexpr" goes beyond constant values and includes constant
>> expressions.  It also forces expressions to be evaluated at compiles time,
>> which is useful for embedded work where compile time constants can be
>> stored in non-volatile memory.
>
> I thought it would go without saying that in a feature such as:
>
>   constant name = value;
>
> that 'value' would have to be an expression. Otherwise it would have bigger
> limitations than any of #define, enum or const.
>
> Obviously the expression can only includes terms that are actual constants,
> or previous named constants.

Too restrictive, the constexpr may also be a function, the only 
restriction is it has to be able to be evaluated at compile time.

-- 
Ian Collins

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

#42639

"Ian Collins" <ian-news@hotmail.com> wrote in message 
news:bqfadrF4crdU1@mid.individual.net...
> BartC wrote:

>> I thought it would go without saying that in a feature such as:
>>
>>   constant name = value;
>>
>> that 'value' would have to be an expression. Otherwise it would have 
>> bigger
>> limitations than any of #define, enum or const.
>>
>> Obviously the expression can only includes terms that are actual 
>> constants,
>> or previous named constants.
>
> Too restrictive, the constexpr may also be a function, the only 
> restriction is it has to be able to be evaluated at compile time.

Too restrictive? Until now, we haven't even been able to define "constant 
a=1;"!

Being able to evaluate absolutely anything at compile-time is far too 
open-ended a feature, but then that is to be expected if coming from a C++.

So if you had:

 constexpr b = f(3,7,8);

and f() was some 1000-line pure function with no other inputs, you would 
expect the compiler to 'execute' the function to get the result? With f() 
perhaps having its own constexpr defines that make use of f's parameters.

This would now go from a suggested feature that is ludicrously simple to 
implement, to ludicrously complex!

-- 
Bartc 

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

#42641

On 07/04/14 12:03, BartC wrote:
> "Ian Collins" <ian-news@hotmail.com> wrote in message
> news:bqfadrF4crdU1@mid.individual.net...
>> BartC wrote:
> 
>>> I thought it would go without saying that in a feature such as:
>>>
>>>   constant name = value;
>>>
>>> that 'value' would have to be an expression. Otherwise it would have
>>> bigger
>>> limitations than any of #define, enum or const.
>>>
>>> Obviously the expression can only includes terms that are actual
>>> constants,
>>> or previous named constants.
>>
>> Too restrictive, the constexpr may also be a function, the only
>> restriction is it has to be able to be evaluated at compile time.
> 
> Too restrictive? Until now, we haven't even been able to define
> "constant a=1;"!
> 
> Being able to evaluate absolutely anything at compile-time is far too
> open-ended a feature, but then that is to be expected if coming from a C++.
> 
> So if you had:
> 
> constexpr b = f(3,7,8);
> 
> and f() was some 1000-line pure function with no other inputs, you would
> expect the compiler to 'execute' the function to get the result? With
> f() perhaps having its own constexpr defines that make use of f's
> parameters.
> 

Yes, that is /exactly/ what is expected.  If f is constexpr (and pure
functions certainly can be constexpr), then it should be evaluated at
compile time.

The norm for most programs is that they are compiled a few times, but
run many times - it makes sense to have longer compile times to say run
time.

And of course you are free not to use the feature.

> This would now go from a suggested feature that is ludicrously simple to
> implement, to ludicrously complex!
> 

And yet, the people who implement C++ compilers have already implemented
it.  In fact, people who implement /C/ compilers, or pre-C++11 C++
compilers, have already implemented much of it - compilers already do a
lot of compile-time evaluation to save run times.  gcc goes out of its
way to make sure functions give exactly the same results when calculated
at compile time as they would at run time, regardless of the host/target
combination.  C++11 "constexpr" functions is just an extension and
formalisation of the concept.

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

#42646

"David Brown" <david.brown@hesbynett.no> wrote in message 
news:lhu05l$63b$1@dont-email.me...
> On 07/04/14 12:03, BartC wrote:

>> Being able to evaluate absolutely anything at compile-time is far too
>> open-ended a feature, but then that is to be expected if coming from a 
>> C++.
>>
>> So if you had:
>>
>> constexpr b = f(3,7,8);
>>
>> and f() was some 1000-line pure function with no other inputs, you would
>> expect the compiler to 'execute' the function to get the result? With
>> f() perhaps having its own constexpr defines that make use of f's
>> parameters.
>>
>
> Yes, that is /exactly/ what is expected.  If f is constexpr (and pure
> functions certainly can be constexpr), then it should be evaluated at
> compile time.
>
> The norm for most programs is that they are compiled a few times, but
> run many times - it makes sense to have longer compile times to say run
> time.

I don't think I'm that comfortable with the idea.

If you did need something such as a set of pre-calculated tables, then you 
might just use a script language to generate C code in an include file:

- You keep both languages simple

- You don't have to re-run the calculations on every compilation (which can 
include running the user's possibly slow, buggy code with the likelihood of 
hanging the compiler is something is not right)

- You use a tool (the script language) which can be more appropriate for the 
job, especially if the output will be a string.

- It easier to generate multiple values (ie. a table) rather than the 
single-value constant definer we've been talking about

>> This would now go from a suggested feature that is ludicrously simple to
>> implement, to ludicrously complex!
>>
>
> And yet, the people who implement C++ compilers have already implemented
> it.  In fact, people who implement /C/ compilers, or pre-C++11 C++
> compilers, have already implemented much of it - compilers already do a
> lot of compile-time evaluation to save run times.  gcc goes out of its
> way to make sure functions give exactly the same results when calculated
> at compile time as they would at run time, regardless of the host/target
> combination.  C++11 "constexpr" functions is just an extension and
> formalisation of the concept.

This is the same language where we won't even have official binary constants 
until 2017?

And the same one where you already /can/ define 'static const int 
sizemax=1024', but it's not possible to use that to dimension an array?

I think maybe it ought to learn to walk before it can run!

-- 
Bartc
 

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

#42649

On 07/04/14 14:48, BartC wrote:
> "David Brown" <david.brown@hesbynett.no> wrote in message
> news:lhu05l$63b$1@dont-email.me...
>> On 07/04/14 12:03, BartC wrote:
> 
>>> Being able to evaluate absolutely anything at compile-time is far too
>>> open-ended a feature, but then that is to be expected if coming from
>>> a C++.
>>>
>>> So if you had:
>>>
>>> constexpr b = f(3,7,8);
>>>
>>> and f() was some 1000-line pure function with no other inputs, you would
>>> expect the compiler to 'execute' the function to get the result? With
>>> f() perhaps having its own constexpr defines that make use of f's
>>> parameters.
>>>
>>
>> Yes, that is /exactly/ what is expected.  If f is constexpr (and pure
>> functions certainly can be constexpr), then it should be evaluated at
>> compile time.
>>
>> The norm for most programs is that they are compiled a few times, but
>> run many times - it makes sense to have longer compile times to say run
>> time.
> 
> I don't think I'm that comfortable with the idea.
> 
> If you did need something such as a set of pre-calculated tables, then
> you might just use a script language to generate C code in an include file:
> 

That can certainly be done - and it is a method I often use.

> - You keep both languages simple

constexpr doesn't really make C++ any more complex - it just makes the
existing compile-time calculations more explicit.

> 
> - You don't have to re-run the calculations on every compilation (which
> can include running the user's possibly slow, buggy code with the
> likelihood of hanging the compiler is something is not right)

If the user's code is buggy, it is buggy no matter where it is executed.

And "make" will let you avoid re-generating your tables if they have not
changed.

> 
> - You use a tool (the script language) which can be more appropriate for
> the job, especially if the output will be a string.

Sometimes that's true.  But in cases where the pre-calculated data could
be generated within C++, keeping everything within the same language can
be a better choice.

> 
> - It easier to generate multiple values (ie. a table) rather than the
> single-value constant definer we've been talking about
> 
>>> This would now go from a suggested feature that is ludicrously simple to
>>> implement, to ludicrously complex!
>>>
>>
>> And yet, the people who implement C++ compilers have already implemented
>> it.  In fact, people who implement /C/ compilers, or pre-C++11 C++
>> compilers, have already implemented much of it - compilers already do a
>> lot of compile-time evaluation to save run times.  gcc goes out of its
>> way to make sure functions give exactly the same results when calculated
>> at compile time as they would at run time, regardless of the host/target
>> combination.  C++11 "constexpr" functions is just an extension and
>> formalisation of the concept.
> 
> This is the same language where we won't even have official binary
> constants until 2017?

Yes, though I don't quite see the connection.  I don't claim that
constexpr makes C++ a "complete" or "perfect" language - it has plenty
of flaws.  The same applies to C.

(gcc, and some other compilers for embedded targets, have had binary
constants for a good while now.  It's an extension rather than a
standard feature.)

> 
> And the same one where you already /can/ define 'static const int
> sizemax=1024', but it's not possible to use that to dimension an array?
> 

C++ allows you to use static const ints as the dimension of an array.

> I think maybe it ought to learn to walk before it can run!
> 

I would like C to enhance its existing "const" (which was originally
copied from C++) to allow its use in array dimensions, just like in C++.
 I cannot think of any reason why this is not in the C standards, and it
is a feature that would improve many C programs.

Copying "constexpr" from C++ into C would be less useful, but still have
its place - and it would be possible without "corrupting" C with too
much C++ style.  Of course, in C it would be called "_Constexpr", but we
are used to that.

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

#42642

BartC wrote:
> "Ian Collins" <ian-news@hotmail.com> wrote in message
> news:bqfadrF4crdU1@mid.individual.net...
>> BartC wrote:
>
>>> I thought it would go without saying that in a feature such as:
>>>
>>>    constant name = value;
>>>
>>> that 'value' would have to be an expression. Otherwise it would have
>>> bigger
>>> limitations than any of #define, enum or const.
>>>
>>> Obviously the expression can only includes terms that are actual
>>> constants,
>>> or previous named constants.
>>
>> Too restrictive, the constexpr may also be a function, the only
>> restriction is it has to be able to be evaluated at compile time.
>
> Too restrictive? Until now, we haven't even been able to define "constant
> a=1;"!
>
> Being able to evaluate absolutely anything at compile-time is far too
> open-ended a feature, but then that is to be expected if coming from a C++.

There is only so much that can be evaluated at compile time and C++ 
already had rules for this.  The advantage of constexpr is you can use 
it to force evaluation at compile time (to use read only memory), rather 
than relying on optimisation (which probably won't use read only 
memory). In the embedded world, that certainty is important.

For example, something like:

constexpr int f( int a, int b, int c ) { return (a+b)/c; }

int main()
{
   constexpr int n = f( 2,3,4 );
}

Will guarantee n is a compile time constant.

If you want to do more open ended things at compile time, you have to 
become a master of the black art of template meta-programming!

-- 
Ian Collins

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

#42636

On 07/04/14 09:34, Ian Collins wrote:
> David Brown wrote:
>>
>> I believe "const" started out as "readonly" in the early days of C++, or
>> "C with objects".  Keeping it as "readonly" would have avoiding the
>> somewhat awkward keyword "constexpr" to mean /really/ constant.
> 
> C++'s "constexpr" goes beyond constant values and includes constant
> expressions.  It also forces expressions to be evaluated at compiles
> time, which is useful for embedded work where compile time constants can
> be stored in non-volatile memory.
> 
> Like C=='s const,  "constexpr" would be another worthwhile addition to C.
> 

I agree here - as an embedded developer, the more that can be done at
compile-time and stored in non-volatile memory, the better.  constexpr
opens up many new possibilities, such as compile-time generated tables
for approximate maths functions, CRC tables, etc.  It is one of the
reasons I think C++11 is much more appealing for embedded development
than C++98 was.  (I don't mean to say that C++98 was unsuitable for
embedded development, just that C++11 has many nice new features making
it better.)

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

#42644

David Brown wrote:
> On 07/04/14 09:34, Ian Collins wrote:
>> David Brown wrote:
>>>
>>> I believe "const" started out as "readonly" in the early days of C++, or
>>> "C with objects".  Keeping it as "readonly" would have avoiding the
>>> somewhat awkward keyword "constexpr" to mean /really/ constant.
>>
>> C++'s "constexpr" goes beyond constant values and includes constant
>> expressions.  It also forces expressions to be evaluated at compiles
>> time, which is useful for embedded work where compile time constants can
>> be stored in non-volatile memory.
>>
>> Like C=='s const,  "constexpr" would be another worthwhile addition to C.
>>
>
> I agree here - as an embedded developer, the more that can be done at
> compile-time and stored in non-volatile memory, the better.

But you can do this now with pragmas and using the linker/locater. Some
embedded toolchains have their own suites of heresies (and even 
keywords) for this.

> constexpr
> opens up many new possibilities, such as compile-time generated tables
> for approximate maths functions, CRC tables, etc.  It is one of the
> reasons I think C++11 is much more appealing for embedded development
> than C++98 was.  (I don't mean to say that C++98 was unsuitable for
> embedded development, just that C++11 has many nice new features making
> it better.)
>

-- 
Les Cargill

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

#42647

On 07/04/14 14:24, Les Cargill wrote:
> David Brown wrote:
>> On 07/04/14 09:34, Ian Collins wrote:
>>> David Brown wrote:
>>>>
>>>> I believe "const" started out as "readonly" in the early days of
>>>> C++, or
>>>> "C with objects".  Keeping it as "readonly" would have avoiding the
>>>> somewhat awkward keyword "constexpr" to mean /really/ constant.
>>>
>>> C++'s "constexpr" goes beyond constant values and includes constant
>>> expressions.  It also forces expressions to be evaluated at compiles
>>> time, which is useful for embedded work where compile time constants can
>>> be stored in non-volatile memory.
>>>
>>> Like C=='s const,  "constexpr" would be another worthwhile addition
>>> to C.
>>>
>>
>> I agree here - as an embedded developer, the more that can be done at
>> compile-time and stored in non-volatile memory, the better.
> 
> But you can do this now with pragmas and using the linker/locater. Some
> embedded toolchains have their own suites of heresies (and even
> keywords) for this.
> 

Of course you can get your compiler/linker to store compile-time known
data in read-only memory.  "constexpr" lets you get more calculations
done at compile time, so it is easier to get more data into read-only
memory or even handled directly in code.  I don't think it actually
changes what can be generated in this way - template magic can be used
to calculate a lot of stuff - but it makes it easier and neater.  The
restrictions on constexpr functions make some limitations and mean you
use a somewhat different style from "normal" C++ coding, but I think it
can help avoid some table-generating scripts that I use at the moment.




>> constexpr
>> opens up many new possibilities, such as compile-time generated tables
>> for approximate maths functions, CRC tables, etc.  It is one of the
>> reasons I think C++11 is much more appealing for embedded development
>> than C++98 was.  (I don't mean to say that C++98 was unsuitable for
>> embedded development, just that C++11 has many nice new features making
>> it better.)
>>
> 

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

#42635

"David Brown" <david.brown@hesbynett.no> wrote in message
news:lhsqq9$3l7$1@dont-email.me...
> On 07/04/14 00:20, BartC wrote:

>> Sorry, but anything that involves doing X, Y or Z to make type specs
>> 'easy'
>> isn't a solution!

> Why should it be so easy to write a complex type definition as a single
> statement?

Typedefs are fine when you want typedefs. But it's a failing to have to use
them to decipher a fairly ordinary type-spec; to declare:

'a as const pointer to array of pointer to char' I would need:

char *(* const a)[];

while to declare 'a as pointer to array of const pointer to char' I'd need:

char * const (*a)[];

Maybe /you/ can figure out which const means what, but I can't! (And don't
want to.) Look at the English description of each however, and it's
perfectly clear to which part each const pertains to.

So you want the type-spec on one line, and ideally you want it to be
obvious.

But another thing about  const: which bit exactly of that last spec, could I
write to? I think (looking at the English!) you can modify the top pointer,
but not an array element, but *can* modify what the const array element
points to. All a bit meaningless really! More sensible would be just to have
a const qualifier at the top level.

As it is, if I really wanted this whole thing readonly, I'd have to write:

const char * const (* const a)[];

Is this really making the code better?

>> const sizeMax = 1024      /* 'int' is optional */
>
> "int" is not optional in well-written code, IMHO.

Why not? You don't have 'int' in a '#define constant, you don't have 'int'
in an enum constant, and you don't need 'int' in a const pseudo-constant!
This would make it just about the only place where it would be mandatory.

But the vast majority of named constants /will/ have int types.

> "static const" objects typically don't require storage - the compiler
> knows they will never be exported or visible outside the compilation
> unit (unless you take their address, of course),

The compiler /might/ know (certainly one I'd write wouldn't!). Why rely on
whether a compiler may or may not treat the pseudo-constant the way you
want; why not just make it explicit:

readonly int abc=100;
constant int xyz=200;

   .rodata
abc:
   dd 100

xyz equ 200

That way there are no arguments!

(This works fine for scalar values such as ints and floats; but I also use
'constant' for large data such a strings. In this case storage /is/ needed,
and you start to get some overlap between constant and readonly.)

-- 
Bartc 

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

#42640

On 07/04/14 11:19, BartC wrote:
> "David Brown" <david.brown@hesbynett.no> wrote in message
> news:lhsqq9$3l7$1@dont-email.me...
>> On 07/04/14 00:20, BartC wrote:
> 
>>> Sorry, but anything that involves doing X, Y or Z to make type specs
>>> 'easy'
>>> isn't a solution!
> 
>> Why should it be so easy to write a complex type definition as a single
>> statement?
> 
> Typedefs are fine when you want typedefs. But it's a failing to have to use
> them to decipher a fairly ordinary type-spec; to declare:
> 
> 'a as const pointer to array of pointer to char' I would need:
> 
> char *(* const a)[];

typedef char * pChar;
typedef pChar arrayPChar[];
typedef arrayPChar * pArrayPChar;
typedef const pArrayPChar cpArrayPChar;

Each step is clear and unambiguous, and it's about as close to English
as you get in C.  (You might not want to have so many steps here, and it
is likely that your "final" type will have a name reflecting its use in
the program  - I am just illustrating a point, not advocating using
these typedefs verbatim.)

I don't dispute your point that C makes writing complex types directly
unnecessarily unclear - I merely offer typedef as a way of making C clearer.

> 
> while to declare 'a as pointer to array of const pointer to char' I'd need:
> 
> char * const (*a)[];
> 
> Maybe /you/ can figure out which const means what, but I can't! (And don't
> want to.) Look at the English description of each however, and it's
> perfectly clear to which part each const pertains to.
> 
> So you want the type-spec on one line, and ideally you want it to be
> obvious.

I agree on the obvious, but I don't agree that the type-spec has to be
on one line.

> 
> But another thing about  const: which bit exactly of that last spec,
> could I
> write to? I think (looking at the English!) you can modify the top pointer,
> but not an array element, but *can* modify what the const array element
> points to. All a bit meaningless really! More sensible would be just to
> have
> a const qualifier at the top level.

There are /many/ occasions when you want a non-constant pointer to
constant data, or a constant pointer to non-constant data.  This applies
to "real" constant data that will never change - it applies doubly to
"readonly" pointers to read-write data.

> 
> As it is, if I really wanted this whole thing readonly, I'd have to write:
> 
> const char * const (* const a)[];

It is not better than using typedefs to making things clear.

> 
> Is this really making the code better?
> 
>>> const sizeMax = 1024      /* 'int' is optional */
>>
>> "int" is not optional in well-written code, IMHO.
> 
> Why not? You don't have 'int' in a '#define constant, you don't have 'int'
> in an enum constant, and you don't need 'int' in a const pseudo-constant!
> This would make it just about the only place where it would be mandatory.
> 
> But the vast majority of named constants /will/ have int types.

Perhaps your programming is different, but I make a lot of use of
constants - and it is far from just being integers.

#define does not provide any type information - it's just textual
substitution.  So it works perfectly well (baring the lack of checking
and safety) regardless of the type - people use #define with integral
types of all sorts, floating point constants, strings, etc.

"const" data is used for tables, strings, lists, etc., as well as just
integers.  In embedded programming, it is common for resources such as
bitmaps to be encoded as const data arrays.

We have managed to get rid of several of the "default int" legacy of
older C standards, and compiler warnings can often be used to trap other
cases where it is still legal C.  Introducing a new concept to C and
making it "default int" would be a solid leap backwards.

> 
>> "static const" objects typically don't require storage - the compiler
>> knows they will never be exported or visible outside the compilation
>> unit (unless you take their address, of course),
> 
> The compiler /might/ know (certainly one I'd write wouldn't!). Why rely on
> whether a compiler may or may not treat the pseudo-constant the way you
> want; why not just make it explicit:
> 
> readonly int abc=100;
> constant int xyz=200;
> 
>   .rodata
> abc:
>   dd 100
> 
> xyz equ 200
> 
> That way there are no arguments!
> 

You are /always/ relying on the compiler to generate good object code
that has the same visible result as the source code you give it - but
the compiler is not a translator.  You cannot assume the compiler will
force the "readonly" data into addressable memory without limiting the
compiler's optimiser - conversely, you cannot assume that it will /not/
do so for "constant" data without limiting it.  Programming is about
being accurate in describing what you want in a language common to you
and the compiler, and then letting the compiler do its job.

So back to reality of compilers as they exist today - "static const"
objects normally do not require storage unless you take their addresses.
 /Big/ static const objects, such as strings or arrays, are typically
given read-only storage space, but they can also be optimised away by
the compiler.  "const" data with external linkage is also usually given
storage space, especially if it is used in a compile unit where it is
declared but not defined.  But even that is not guaranteed.

> (This works fine for scalar values such as ints and floats; but I also use
> 'constant' for large data such a strings. In this case storage /is/ needed,
> and you start to get some overlap between constant and readonly.)
> 

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

#42645

>>>> const sizeMax = 1024      /* 'int' is optional */

>> But the vast majority of named constants /will/ have int types.
>
> Perhaps your programming is different, but I make a lot of use of
> constants - and it is far from just being integers.

Maybe you're thinking about other uses you make of 'const' in your code.

Because apart from replacing numeric literals such as 32767 and 453.592 in 
source code, what else would named constants be used for? I can't imagine 
that literal pointer values are going to be used that often! (And the most 
common, 0, is already taken care of.)

And between integers and floating point, the former do dominant most of my 
programs.

>>>
>>> "int" is not optional in well-written code, IMHO.
>>
>> Why not?

> We have managed to get rid of several of the "default int" legacy of
> older C standards, and compiler warnings can often be used to trap other
> cases where it is still legal C.  Introducing a new concept to C and
> making it "default int" would be a solid leap backwards.

OK, I'll give you that. But perhaps then we should write most integer 
constants as:

  123i    (or 123s)

to get rid of the default int type here, and make it explicit?

-- 
Bartc  

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

#42648

On 07/04/14 14:27, BartC wrote:
> 
>>>>> const sizeMax = 1024      /* 'int' is optional */
> 
>>> But the vast majority of named constants /will/ have int types.
>>
>> Perhaps your programming is different, but I make a lot of use of
>> constants - and it is far from just being integers.
> 
> Maybe you're thinking about other uses you make of 'const' in your code.
> 
> Because apart from replacing numeric literals such as 32767 and 453.592
> in source code, what else would named constants be used for? I can't
> imagine that literal pointer values are going to be used that often!
> (And the most common, 0, is already taken care of.)

First, note that 453.592 is a floating point constant, not an integer -
thus you need to be able to write "const double sizeMax = 453.592".
Stick a "static" on the front, or use C++ (where "static" is implied for
initialised const declarations unless you explicitly add an "extern"
declaration), and you are already almost at the current C
implementation.  The only missing point is for things like array sizes
and switch cases, which can legally use "const int" values in C++ but
not in C.

Second, I regularly use const tables, structs, strings, and combinations
thereof in my code.  In embedded programming, you often have a lot of
fixed values and you need the efficiency and compactness of putting the
data in read-only parts of the code rather than reading in external
files or initialising at run-time.  So if I have a program with a
hierarchic menu, I am going to have structs of arrays of structs with
lists of pointers to const char* for menu texts, pointers to functions
to call, flags for options, etc.  And if the program is multi-lingual
there might be another layer of indirection to handle different
translations of the menu texts.  And it is all declared "const" because
it will not change in the program, and should be in read-only flash memory.


> 
> And between integers and floating point, the former do dominant most of
> my programs.
> 
>>>>
>>>> "int" is not optional in well-written code, IMHO.
>>>
>>> Why not?
> 
>> We have managed to get rid of several of the "default int" legacy of
>> older C standards, and compiler warnings can often be used to trap other
>> cases where it is still legal C.  Introducing a new concept to C and
>> making it "default int" would be a solid leap backwards.
> 
> OK, I'll give you that. But perhaps then we should write most integer
> constants as:
> 
>  123i    (or 123s)
> 
> to get rid of the default int type here, and make it explicit?
> 

Why?  What possible justification do you have for introducing an
inconsistent and arbitrary extra syntax when there is a perfectly good,
clear and simple existing syntax?  If - like the original C designers' -
your keyboard is so awful that writing an extra "int" is a pain, then I
recommend buying a new keyboard.

There are lots of things that could be done to improve C - many of which
are simple because they could be "stolen" from existing C++
implementations.  Weird syntax to avoid writing "int" on constants is
certainly not one of these possible improvements.

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

#42650

"David Brown" <david.brown@hesbynett.no> wrote in message
news:lhu8fv$53m$1@dont-email.me...
> On 07/04/14 14:27, BartC wrote:
<snip>
> .... And it is all declared "const" because
> it will not change in the program, and should be in read-only flash
> memory.

This is exactly why there needs to be a clear distinction between const used
for readonly data, and const to name magic numbers, which is what I was
talking about.

[David Brown]
>>> We have managed to get rid of several of the "default int" legacy of
>>> older C standards,

>> OK, I'll give you that. But perhaps then we should write most integer
>> constants as:
>>
>>  123i    (or 123s)
>>
>> to get rid of the default int type here, and make it explicit?

> Why?  What possible justification do you have for introducing an
> inconsistent and arbitrary extra syntax when there is a perfectly good,
> clear and simple existing syntax?

Oh? I thought you wanted to move away from 'default int' in C, which is
exactly what you have with a constant such as 200 in source code. (BTW my
suggestion wasn't serious.)

My original suggestion for:

constant name = 123;

without the int, matches:

#define name 123

and:

enum {name=123};

and even:

123

used directly in source code, none of which need extra cues. But probably 
the 'int' should be put in where it's not obvious:

constant int m = n*(n+1)/2;

Since n could be floating point, long int, etc.

-- 
Bartc 

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

#42651

On 07/04/14 15:43, BartC wrote:
> "David Brown" <david.brown@hesbynett.no> wrote in message
> news:lhu8fv$53m$1@dont-email.me...
>> On 07/04/14 14:27, BartC wrote:
> <snip>
>> .... And it is all declared "const" because
>> it will not change in the program, and should be in read-only flash
>> memory.
> 
> This is exactly why there needs to be a clear distinction between const
> used
> for readonly data, and const to name magic numbers, which is what I was
> talking about.
> 

No, there is /no/ need for such a distinction.

When the data involved is some sort of structure, or you have pointers,
it is going to end up (mostly) in readonly memory.  But I want the
compiler to be able to take advantage of any compile-time-known values
to generate better code - I don't want to force the compiler to read
from flash (or rom, or whatever) if it doesn't have to.

And for data that is short and simple - such as "int" - I want the
compiler to use the shortest and fastest method of handling the data,
and I want it to be able to accept the number as a fixed
compile-time-known value for things like array sizes.  I want the
compiler to find the best place to put the data depending on the
circumstances, and I want it to be able to put it in flash /and/ use it
directly, if that's the best choice.

> [David Brown]
>>>> We have managed to get rid of several of the "default int" legacy of
>>>> older C standards,
> 
>>> OK, I'll give you that. But perhaps then we should write most integer
>>> constants as:
>>>
>>>  123i    (or 123s)
>>>
>>> to get rid of the default int type here, and make it explicit?
> 
>> Why?  What possible justification do you have for introducing an
>> inconsistent and arbitrary extra syntax when there is a perfectly good,
>> clear and simple existing syntax?
> 
> Oh? I thought you wanted to move away from 'default int' in C, which is
> exactly what you have with a constant such as 200 in source code. (BTW my
> suggestion wasn't serious.)

Yes, I want to move away from "default int" towards "explicit int" - not
towards "I think perhaps we'll use an "i" suffix here to say int.
Somewhere else we'll use "int", and perhaps somewhere else I'll pick a
different inconsistent convention".

> 
> My original suggestion for:
> 
> constant name = 123;
> 
> without the int, matches:
> 
> #define name 123

That is not part of C itself, it is part of the macro pre-processor
language which has no concept of "int" or any other type.  So it is not
a "default int" - it is not even necessarily an int literal (you could
token-paste it to make a function name "foo123" if you want).

You can also use #define for floats, strings, and anything else you like.

But since we are doing away with the pre-processor defines, we should
not put too high an emphasis on them.

> 
> and:
> 
> enum {name=123};

Yes, but enum constants are completely and unchangeably integers.  And
using enum in this way is an abuse of the enum keyword to get around the
limitations of const and static const values - so we should not copy
them either.

> 
> and even:
> 
> 123

That's an integer literal.

> 
> used directly in source code, none of which need extra cues. But
> probably the 'int' should be put in where it's not obvious:
> 
> constant int m = n*(n+1)/2;
> 
> Since n could be floating point, long int, etc.
> 

The only existing concept that is worth copying here is the existing
"const", since that is what we are trying to improve upon.  And that
requires an explicit type "const int name = 123".

And since "const" already does most of what we want, and in C++ it does
everything we want, then the C world would be better off by just
allowing "const" (or at least "static const") values to be used in the
same way as they can in C++.


One possible way to omit the type name, as suggested by another poster,
would be to make a new "constant" keyword that is of "auto" type, or at
least "auto" by default, based on C11 "auto".  This is completely
different from "default int" - it would make the constant object of a
type that matches the initialiser.  Thus "constant m = 1.23;" would make
"m" of type "const double" - unlike your default int idea in which
"constant m = 1.23;" would be an undiagnosed mistake in the code.

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

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

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

csiph-web