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

#120518 — const and the C type system

I think the concept of const is a little broken because
the compiler can use the const keyword as a tip for immutability.
Am I Right? I don't have idea when it's safe to remove the const
because of this immutability problem. [1]

How do I allocate X on heap?

struct X {
  const int i;
};

how can I make dynamic array of const struct X on heap
and add more elements after malloc?

const struct X *pXs = ...


I think the correct design should have been that
const is never a tip for immutability and you can
change with cast if you like. 

If I put volatile can I change the const object? See [2]

typedef volatile const char * const String;

I want to remove the const only in my String_Set function
and the compiler must not think it's immutable.

The other situation is that compiler can remove const from storage.

I think we need a specific storage modifier  for this.
for instance:

inline int C = 1;

&C //error you cannot take the address of inline variable
C = 1; //error inline variables are immutable.

inline variables would be similar of defines but with namespaces



[2]

"132) The implementation may place a const object that is not volatile in a read-only region of
storage. Moreover, the implementation need not allocate storage for such an object if its address is
never used."

[1]" If an attempt is made to modify an object defined with a const-qualified type through use
of an lvalue with non-const-qualified type, the behavior is undefined. If an attempt is
made to refer to an object defined with a volatile-qualified type through use of an lvalue
with non-volatile-qualified type, the behavior is undefined.133)"

[toc] | [next] | [standalone]

#120521

Thiago Adams <thiago.adams@gmail.com> writes:

> I think the concept of const is a little broken because
> the compiler can use the const keyword as a tip for immutability.
> Am I Right? I don't have idea when it's safe to remove the const
> because of this immutability problem. [1]

Isn't that the whole point of const?

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

#120531

On Friday, September 29, 2017 at 12:33:36 AM UTC-3, Joe Pfeiffer wrote:
> Thiago Adams writes:
> 
> > I think the concept of const is a little broken because
> > the compiler can use the const keyword as a tip for immutability.
> > Am I Right? I don't have idea when it's safe to remove the const
> > because of this immutability problem. [1]
> 
> Isn't that the whole point of const?

But see the motivation samples:

"
 How do I allocate X on heap? 
 
 struct X { 
   const int i; 
 }; 
 
 how can I make dynamic array of const struct X on heap 
 and add more elements after malloc? 
 
 const struct X *pXs = ... 
 
" 
Someone could write this code not to make 'i' immutable,
it needs to be written at least once at initialization
after malloc for instance.

struct X { 
   const int i; 
 }; 

In this context the idea of const is "don't change 'i' by mistake"

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

#120532

On 29/09/2017 13:45, Thiago Adams wrote:
> On Friday, September 29, 2017 at 12:33:36 AM UTC-3, Joe Pfeiffer wrote:
>> Thiago Adams writes:
>>
>>> I think the concept of const is a little broken because
>>> the compiler can use the const keyword as a tip for immutability.
>>> Am I Right? I don't have idea when it's safe to remove the const
>>> because of this immutability problem. [1]
>>
>> Isn't that the whole point of const?
> 
> But see the motivation samples:
> 
> "
>   How do I allocate X on heap?
>   
>   struct X {
>     const int i;
>   };
>   
>   how can I make dynamic array of const struct X on heap
>   and add more elements after malloc?
>   
>   const struct X *pXs = ...
>   
> "
> Someone could write this code not to make 'i' immutable,
> it needs to be written at least once at initialization
> after malloc for instance.
> 
> struct X {
>     const int i;
>   };
> 
> In this context the idea of const is "don't change 'i' by mistake"
> 

I used the following. That utilises a shadow struct where the members 
are writeable. That is used to set up a struct, then a pointer to a the 
protected versioned everywhere else. (No doubt breaking half a dozen 
rules in C.)

Comment out the // line, the compiler should complain. (Mine doesn't; 
I'll have to find out why, when I have time. I assume I haven't disabled 
'const' completely!)

(However, I would find it difficult to work with effectively immutable 
structs where everything is initialised in one go. Think of a node of a 
linked list, where the ->next field starts at NULL but can't be updated 
to point to the next node because that info is not yet available. But 
once it is, it will not change. Such a field has two values over its 
lifetime, not one.)


------------------------------------------

#include <stdio.h>
#include <stdlib.h>

struct X {const int i;};
struct X_init {int i;};

struct X* NewX(int value){
     struct X_init *p;

     p=malloc(sizeof(struct X));
     if (p)
         p->i = value;
     return (struct X*)p;
}


int main(void){
     struct X *p;

     p = NewX (12234);

     printf("P->i = %d\n",p->i);

//  p->i = 88888;
}

-- 
bartc

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

#120534

On Friday, September 29, 2017 at 10:05:47 AM UTC-3, Bart wrote:
...
> I used the following. That utilises a shadow struct where the members 
> are writeable. That is used to set up a struct, then a pointer to a the 
> protected versioned everywhere else. (No doubt breaking half a dozen 
> rules in C.)

Yes, I also had this idea. In this case we will probably just
remove const. The felling is something like:
"ok, well, I will remove the const for now instead 
of creating duplicated structs and also I am not sure if it is safe"
"Someone may think this is to clever"

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

#120679

The point of "const" it is not useful for me

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

#120528

On 29/09/17 04:51, Thiago Adams wrote:
> 
> I think the concept of const is a little broken because
> the compiler can use the const keyword as a tip for immutability.
> Am I Right? I don't have idea when it's safe to remove the const
> because of this immutability problem. [1]
> 
> How do I allocate X on heap?
> 
> struct X {
>   const int i;
> };
> 
> how can I make dynamic array of const struct X on heap
> and add more elements after malloc?
> 
> const struct X *pXs = ...
> 
> 
> I think the correct design should have been that
> const is never a tip for immutability and you can
> change with cast if you like. 

You can cast away the const qualifier if you like.  Writing to an object
that was /defined/ as a const is undefined behaviour - but casting away
the const and then writing to something that was not originally defined
as const, is fine.

This matches the obvious implementation.  If you define an object as
"const", the compiler/linker/OS can put it in read-only memory and
assume it never changes.  Bad things will happen if you try.  But if the
object was not const in definition, it has to be in ram - and writing to
it works.  "const" on a pointer is then a promise to the compiler and to
other programmers that you won't change the object via that pointer -
/not/ a promise that the object won't change.  And you can use a cast to
cheat on that promise.

> 
> If I put volatile can I change the const object? See [2]

If and only if the original definition was not const.  ("volatile const"
is used to declare objects that are read only, but may change without
the compiler's knowledge.  They turn up in embedded systems sometimes.)

> 
> typedef volatile const char * const String;
> 
> I want to remove the const only in my String_Set function
> and the compiler must not think it's immutable.
> 
> The other situation is that compiler can remove const from storage.
> 
> I think we need a specific storage modifier  for this.
> for instance:
> 
> inline int C = 1;

There is already "static const int C = 1;".  The compiler will usually
avoid giving this storage space, unless you take its address.  (C++17
added "inline variables" for a somewhat different reason.  It would IMHO
be a bad idea to add inline variables to C that are incompatible with
the C++ versions.)

> 
> &C //error you cannot take the address of inline variable
> C = 1; //error inline variables are immutable.
> 
> inline variables would be similar of defines but with namespaces
> 
> 
> 
> [2]
> 
> "132) The implementation may place a const object that is not volatile in a read-only region of
> storage. Moreover, the implementation need not allocate storage for such an object if its address is
> never used."
> 
> [1]" If an attempt is made to modify an object defined with a const-qualified type through use
> of an lvalue with non-const-qualified type, the behavior is undefined. If an attempt is
> made to refer to an object defined with a volatile-qualified type through use of an lvalue
> with non-volatile-qualified type, the behavior is undefined.133)"
> 
> 
> 

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

#120533

On Friday, September 29, 2017 at 5:59:53 AM UTC-3, David Brown wrote:
...
> If and only if the original definition was not const.  ("volatile const"
> is used to declare objects that are read only, but may change without
> the compiler's knowledge.  They turn up in embedded systems sometimes.)
> 
> > 
> > typedef volatile const char * const String;
> > 
> > I want to remove the const only in my String_Set function
> > and the compiler must not think it's immutable.
> > 

The motivation for this String const is to avoid mistakes.
I would remove const 'officially' when it's appropriated.
This creates a kind of encapsulation.

The variable would have at same time const and volatile at its 
declaration.

volatile const char * const mystring;
String_Set(&mystring, "hi"); //official way to change
mystring = "hi2" ;//error

The other motivation is also create const objects on heap.
struct Object {
  const int MyId;
};

> > 
> > I think we need a specific storage modifier  for this.
> > for instance:
> > 
> > inline int C = 1;
> 
> There is already "static const int C = 1;".  The compiler will usually
> avoid giving this storage space, unless you take its address.  (C++17
> added "inline variables" for a somewhat different reason.  It would IMHO
> be a bad idea to add inline variables to C that are incompatible with
> the C++ versions.)

Did you notice everyone use #define for constants?
C programmers could also use enuns but they use enum only 
when the values are enumerated.
enum {CONST1 = 1};

For all other cases they use #define (in general)
I think the reason (I can ask for those are reading this) 
is because we don't feel comfortable using const int i = 1;
and hopping that his will not be placed at storage.

#define CONST1 1

give us what we want.

And I think they don't use enuns because they are an special case
for ints and they don't want to have two styles then they 
use #define for ints also.


I agree 'inline' variables would conflict with C++. 
But this is matter of syntax.

readonly int i;
immutable int i;

I am not suggesting changing the const meaning at this moment 
and broke existing code.
Just showing the cases and motivation, and asking what can we do 
today or how C could be improved.

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

#120535

On 29/09/2017 14:06, Thiago Adams wrote:
> On Friday, September 29, 2017 at 5:59:53 AM UTC-3, David Brown wrote:

>> There is already "static const int C = 1;".  The compiler will usually
>> avoid giving this storage space, unless you take its address.  (C++17
>> added "inline variables" for a somewhat different reason.  It would IMHO
>> be a bad idea to add inline variables to C that are incompatible with
>> the C++ versions.)
> 
> Did you notice everyone use #define for constants?
> C programmers could also use enuns but they use enum only
> when the values are enumerated.
> enum {CONST1 = 1};
> 
> For all other cases they use #define (in general)
> I think the reason (I can ask for those are reading this)
> is because we don't feel comfortable using const int i = 1;
> and hopping that his will not be placed at storage.
> 
> #define CONST1 1
> 
> give us what we want.
> 
> And I think they don't use enuns because they are an special case
> for ints and they don't want to have two styles then they
> use #define for ints also.

I think you're the only person ever to have voiced the same misgivings 
about C's failings in this area as I have.

The language solution for this, at least for numeric types, is very, 
very simple; it is to have named constants, eg:

constant const1 1;    // defaults to type of the expression, here int

So that 'const1' will subsequently work EXACTLY the same as writing a 
literal '1' in the code.

As for the current workarounds used with C, here's an extract from an 
updating listing I have of all the problems I perceive with C (not
online):

------------------------------
Named Constants

There is no simple way to attach a name to a numeric constant. Not so that:

• The name obeys normal scope rules

• A specific type is associated with the name

• The name can be used just like a numeric constant, and (for int types)
   be used for fixed array bounds, or for case levels, or can be used in
   constant expression folding

• You can't take the address of it

• It is impossible to modify the value,  even maliciously

C normally uses a combination of #define, enum and 'const' applied to 
variables.
------------------------------

(I'm not sure how those bullet points were retained; hopefully they will 
still be there after posting. If not, that's what those funny characters 
are meant to be.)

-- 
bartc

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

#120537

On Friday, September 29, 2017 at 10:24:13 AM UTC-3, Bart wrote:
> On 29/09/2017 14:06, Thiago Adams wrote:
> > On Friday, September 29, 2017 at 5:59:53 AM UTC-3, David Brown wrote:
> 
> >> There is already "static const int C = 1;".  The compiler will usually
> >> avoid giving this storage space, unless you take its address.  (C++17
> >> added "inline variables" for a somewhat different reason.  It would IMHO
> >> be a bad idea to add inline variables to C that are incompatible with
> >> the C++ versions.)
> > 
> > Did you notice everyone use #define for constants?
> > C programmers could also use enuns but they use enum only
> > when the values are enumerated.
> > enum {CONST1 = 1};
> > 
> > For all other cases they use #define (in general)
> > I think the reason (I can ask for those are reading this)
> > is because we don't feel comfortable using const int i = 1;
> > and hopping that his will not be placed at storage.
> > 
> > #define CONST1 1
> > 
> > give us what we want.
> > 
> > And I think they don't use enuns because they are an special case
> > for ints and they don't want to have two styles then they
> > use #define for ints also.
> 
> I think you're the only person ever to have voiced the same misgivings 
> about C's failings in this area as I have.
> 
> The language solution for this, at least for numeric types, is very, 
> very simple; it is to have named constants, eg:
> 
> constant const1 1;    // defaults to type of the expression, here int

The other keyword could be literal and no type: 
(just imagining some usages that would help me remove macros)

literal const1 = 1;
literal const2 = 2LL;
literal text = "hello";
literal X_Default = (struct X) {0};


Do C have complex literal?
hum... complex arithmetic inside the compiler?
literal complex1 = 1 + 2*I;

Then definition would be the equivalent literal
that represents the result of some constant expression.

Sample:
literal other = 1 + 2;
same of literal 3

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

#120552

On Friday, September 29, 2017 at 9:52:51 AM UTC-4, Thiago Adams wrote:
...
> Do C have complex literal?

Yes, but not in precisely as convenient a form as you'd probably like. C only
uses the term "literal" to describe string literals and compound literals. You
may be thinking in terms of the C++ standard, which uses "literal" in many
contexts where C uses the term "constant"; every type of "constant" described in
6.4.4 is called a "literal" in the C++ standard. Unfortunately, none of those
constants has complex type.

You can create a compound literal of complex type:
(_Complex double){1.2+3.4I}. However, the expression (1.2+3.4*I) qualifies as a
constant expression, even though it doesn't count as a constant, and is simpler
than the compound literal. I haven't been able to identify any context where
either of those would be less useful than a true complex constant - but that
might be a lack of imagination on my part. Except when it's involved in multiplication or division, you can drop the parentheses around that expression.

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

#120557

On Friday, September 29, 2017 at 1:18:23 PM UTC-3, james...@verizon.net wrote:
...
> You can create a compound literal of complex type:
> (_Complex double){1.2+3.4I}. However, the expression (1.2+3.4*I) qualifies as a
> constant expression, even though it doesn't count as a constant, and is simpler
> than the compound literal. 

Interesting.

The reason I ask about the literal Complex was to support the 'literal' declaration suggestion.

literal ComplexConstant = (_Complex double){1.2+3.4I};

If the compiler does the const expression then this idea is fine.

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

#120560

On Friday, September 29, 2017 at 1:51:00 PM UTC-4, Thiago Adams wrote:
> On Friday, September 29, 2017 at 1:18:23 PM UTC-3, james...@verizon.net wrote:
> ...
> > You can create a compound literal of complex type:
> > (_Complex double){1.2+3.4I}. However, the expression (1.2+3.4*I) qualifies as a
> > constant expression, even though it doesn't count as a constant, and is simpler
> > than the compound literal. 
> 
> Interesting.
> 
> The reason I ask about the literal Complex was to support the 'literal' declaration suggestion.
> 
> literal ComplexConstant = (_Complex double){1.2+3.4I};
> 
> If the compiler does the const expression then this idea is fine.

That's a "constant expression", not a "const expression". It's important to keep "const" and "constant" distinct in C. They refer to very different things.

A "constant" in C is one of the things defined in section 6.4.4. A "constant expression" is an expression that meets the requirements specified in section 6.6. A constant is one form that a "constant expression" can take, but there's a wide variety of other forms that also qualify.

"const" is a keyword that has a meaning which is partially described in 6.7.3, with the rest of the meaning being implicit in what the standard says in a wide variety of other places about qualifiers and qualified types. It's completely distinct from either of those concepts.

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

#120567

On Friday, September 29, 2017 at 3:06:43 PM UTC-3, james...@verizon.net wrote:
...
> > The reason I ask about the literal Complex was to support the 'literal' declaration suggestion.
> > 
> > literal ComplexConstant = (_Complex double){1.2+3.4I};
> > 
> > If the compiler does the const expression then this idea is fine.
> 
> That's a "constant expression", not a "const expression". It's important to keep "const" and "constant" distinct in C. They refer to very different things.

I mean: 

If the compiler does the constant expression then this idea is fine.

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

#120619

On Friday, September 29, 2017 at 10:52:51 AM UTC-3, Thiago Adams wrote:
...
> The other keyword could be literal and no type: 
> (just imagining some usages that would help me remove macros)
> 
> literal const1 = 1;
> literal const2 = 2LL;
> literal text = "hello";
> literal X_Default = (struct X) {0};
> 
> 
> Do C have complex literal?
> hum... complex arithmetic inside the compiler?
> literal complex1 = 1 + 2*I;
> 
> Then definition would be the equivalent literal
> that represents the result of some constant expression.
> 
> Sample:
> literal other = 1 + 2;
> same of literal 3

I change my mind and literal is a bad keyword because
expression are useful and expressions are not literals.

Sample:

enum E {A = 1};
keyword  name = 1 + A;  //constant expression
keyword name2 = "string";  //string
keyword X_Default = (X){1, 2}; //compound literal
keyword V = (_Complex )(1 * 1*I);

const expression is also bad because compound literal are not
constant expressions.

maybe just 'const' keyword is fine.

const name = 1 + 2;
const s = "a";

the expression is evaluated 1 + 2, and the compiler 
does exactly like enuns but the type is not int, the type
is typeof(expression).

const name = expression;

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

#120620

On Saturday, September 30, 2017 at 5:13:32 PM UTC-3, Thiago Adams wrote:
> On Friday, September 29, 2017 at 10:52:51 AM UTC-3, Thiago Adams wrote:
> ...
> > The other keyword could be literal and no type: 
..
...
> I change my mind and literal is a bad keyword because

The point where this is similar of compound literal is
that the rules are the same.

//this is NOT at any storage location
//like enun
const X_Default = (X){1, 2}; 

void F(X x);
int main()
{
   //same rules of compound literal
   //for instance, were the variable is created
   F(X_Default); 
}

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

#120549

bartc <bc@freeuk.com> writes:
> On 29/09/2017 14:06, Thiago Adams wrote:
>> On Friday, September 29, 2017 at 5:59:53 AM UTC-3, David Brown wrote:
>
>>> There is already "static const int C = 1;".  The compiler will usually
>>> avoid giving this storage space, unless you take its address.  (C++17
>>> added "inline variables" for a somewhat different reason.  It would IMHO
>>> be a bad idea to add inline variables to C that are incompatible with
>>> the C++ versions.)
>> 
>> Did you notice everyone use #define for constants?
>> C programmers could also use enuns but they use enum only
>> when the values are enumerated.
>> enum {CONST1 = 1};
>> 
>> For all other cases they use #define (in general)
>> I think the reason (I can ask for those are reading this)
>> is because we don't feel comfortable using const int i = 1;
>> and hopping that his will not be placed at storage.

It's not about hoping that it isn't placed in storage.  The storage for
a single int object is trivial in almost all contexts, and we already
rely on compilers to optimize away storage when it's not needed.

The problem is that given
    const int foo = 1;
the expression foo is not a constant expression.

>> #define CONST1 1
>> 
>> give us what we want.

And given that macro definition, CONST1 is a constant expression.

>> And I think they don't use enuns because they are an special case
>> for ints and they don't want to have two styles then they
>> use #define for ints also.

Using enums to define constants of type int is a fairly common
technique, but not everyone uses it.  And the fact that it's limited to
type int is annoying.

Another advantage of #define is that CONST1 can be used in a
preprocessor expression; an enumeration constant cannot.

> I think you're the only person ever to have voiced the same misgivings 
> about C's failings in this area as I have.

No, a lot of people have discussed it at great length, myself included.
I've advocated adopting something similar to what C++ does, so that
defining a const object initialized with a constant expression causes
the name of the object to be a constant expression.

> The language solution for this, at least for numeric types, is very, 
> very simple; it is to have named constants, eg:
>
> constant const1 1;    // defaults to type of the expression, here int
>
> So that 'const1' will subsequently work EXACTLY the same as writing a 
> literal '1' in the code.

Apart from scoping, #define already does that.

[...]

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

#120556

On 29/09/2017 17:10, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
>> On 29/09/2017 14:06, Thiago Adams wrote:
>>> On Friday, September 29, 2017 at 5:59:53 AM UTC-3, David Brown wrote:
>>
>>>> There is already "static const int C = 1;".  The compiler will usually
>>>> avoid giving this storage space, unless you take its address.  (C++17
>>>> added "inline variables" for a somewhat different reason.  It would IMHO
>>>> be a bad idea to add inline variables to C that are incompatible with
>>>> the C++ versions.)
>>>
>>> Did you notice everyone use #define for constants?
>>> C programmers could also use enuns but they use enum only
>>> when the values are enumerated.
>>> enum {CONST1 = 1};
>>>
>>> For all other cases they use #define (in general)
>>> I think the reason (I can ask for those are reading this)
>>> is because we don't feel comfortable using const int i = 1;
>>> and hopping that his will not be placed at storage.
> 
> It's not about hoping that it isn't placed in storage.  The storage for
> a single int object is trivial in almost all contexts, and we already
> rely on compilers to optimize away storage when it's not needed.
> 
> The problem is that given
>      const int foo = 1;
> the expression foo is not a constant expression.
> 
>>> #define CONST1 1
>>>
>>> give us what we want.
> 
> And given that macro definition, CONST1 is a constant expression.
> 
>>> And I think they don't use enuns because they are an special case
>>> for ints and they don't want to have two styles then they
>>> use #define for ints also.
> 
> Using enums to define constants of type int is a fairly common
> technique, but not everyone uses it.  And the fact that it's limited to
> type int is annoying.
> 
> Another advantage of #define is that CONST1 can be used in a
> preprocessor expression; an enumeration constant cannot.
> 
>> I think you're the only person ever to have voiced the same misgivings
>> about C's failings in this area as I have.
> 
> No, a lot of people have discussed it at great length, myself included.
> I've advocated adopting something similar to what C++ does, so that
> defining a const object initialized with a constant expression causes
> the name of the object to be a constant expression.
> 
>> The language solution for this, at least for numeric types, is very,
>> very simple; it is to have named constants, eg:
>>
>> constant const1 1;    // defaults to type of the expression, here int
>>
>> So that 'const1' will subsequently work EXACTLY the same as writing a
>> literal '1' in the code.
> 
> Apart from scoping, #define already does that.

Well, scoping is quite a big deal. So you can't use '#define N ...' in 
successive functions, as the different Ns can clash.

Unless you start messing with '#undef N' just before every #define, but 
you'd have to know that '#undef' has already been used before every 
#define, otherwise introducing a new #define can cause problems later 
with subsequent #defines. Or you'd have to have #undef at the end of 
every scope that intends to use a local #define.

So, using #define has problems. (It would be ironic to gloss over the 
inconvenience of a single file-wide (translation-unit-wide actually) 
scope of a #define, but then every insist that nested multi-block scopes 
even within the confines of a function for everything else are a must.)

Other issues with #define for naming constants:

• There is no type associated with it. You have to ensure the expression
   used has the desired type (checking the overall type of the
   expressionor forcing it with a cast)

• The associated expression may not be constant. Sometimes this is
   detected, for example trying to use it as a case label, sometimes it's
   not, so you end up with a VLA that you don't want, or an expression
   that is not constant-folded as expected.

• Continuing from there, the expression may not only not be a
   compile-time constant, but it could be assigned to:

    int abc=100;
    #define N abc
    abc=200;      // now N has value 200

• Being mere text substitution, this means a complex expression
   associated with a #define is expanded, parsed, type-checked
   and constant-folded multiple times within the source code, hitting
   compiler efficiency and likely requiring more resources.

• I don't think that #define can appear in macro expansions, but a new
   feature such as 'constant' or 'literal' that exists outside the pre-
   processor can do

-- 
bartc

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

#120561

On Friday, September 29, 2017 at 1:11:09 PM UTC-3, Keith Thompson wrote:
...
> Using enums to define constants of type int is a fairly common
> technique, but not everyone uses it.  And the fact that it's limited to
> type int is annoying.

I don't think that type int is a problem if enum were reserved
for enumerated values only. The problem is not to have an alternative
for constants.

This would be very boring to write
enum : int { Constant1 = 1 }; 
compared with:
literal Constant1 = 1;

Another keyword could be 'let'.

let x =  1 + 3;
         -----
         ^must be constant expression
         x has the typeof (1 + 3)


&x //error
x = 1; //error

let x = 1;
let y = 2;
let z = x + y;

printf("%d", x + y); //same of printf("%d", 3);


Sometimes I use enuns for flags.

enum FontStyle
{
   FontStyleNormal    = 1 << 0,
   FontStyleBold      = 1 << 1,
   FontStyleItalic    = 1 << 2,
   FontStyleUnderline = 1 << 3
};

for this use, I think a new type could help.

union enum FontStyle
{
   FontStyleNormal,
   FontStyleBold,
   FontStyleItalic,
   FontStyleUnderline
};

The advantage over #define in this case, is that the 
compiler could check if you are using related flags
for the type FontStyle.

(In C++ this is possible overriding operators for type enum)

This kind of facility, like enun itself, is something to help
developers. (generally C is focused to help developers write
code that is generated, but in this case this help is more
about productivity in C) 

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

#120582

On 09/30/17 02:24 AM, bartc wrote:
> On 29/09/2017 14:06, Thiago Adams wrote:
>>
>> And I think they don't use enuns because they are an special case
>> for ints and they don't want to have two styles then they
>> use #define for ints also.
>
> I think you're the only person ever to have voiced the same misgivings
> about C's failings in this area as I have.

You haven't been reading my posts....

-- 
Ian

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

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

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

csiph-web