3 ms·

These refer to variables that exist in memory when the program is running: const int a; extern int b; static int c; volatile int d; And this refers to

by eps 5y ago

These refer to variables that exist in memory when the program is running: const int a; extern int b; static int c; volatile int d; And this refers to something that exists only at compile time: constexpr int z = 1; This ain't right. Not that C doesn't need compile-time elements, it'd be better off not copying them from C++ verbatim and implementing in a way that doesn't introduce confusion into basic language concepts such as variables and functions.

moonchild 5y ago
typedef int w; This also refers to something that exists only at compile time. Where's the inconsistency? constexpr makes a lot more sense as a storage class than typedef.
elteto 5y ago
I’m really not seeing what the issue is here. Could you expand on it? As a programmer why do I have to reason or care whether something is compile time only or not? I don’t worry about constant folding but it is a similar thing.
- eps 5y ago
  Proposed constexpr syntax mimics that of a conventional variable, yet it doesn't create one and comes with distinctly different usage semantics. It's a different language element, I see no reason why it should be bundled up with another one.
  - elteto 5y ago
    Conventional variable syntax may not create a variable either. The compiler elides as it can or sees fit. This is my point, you don’t reason about these details today, why should constexpr be different?
    - huhtenberg 5y ago
      Because constexpr and variables are not the same thing? E.g. with a variable you can still always take its address. With constexpr you can't. Plus 'constexpr' is a patently ugly keyword. Also an important metric to consider :)
      - elteto 5y ago
        My point is that arguing about what is a variable is moot in the presence of compiler optimizations. You might think that taking and address makes a difference but if the compiler decides that it can elide it will (for example if the taken address never leaves the local scope and the variable is purely local then the compiler might be able to optimize it away). Regarding ugliness… Idk beauty is in the eye of the beholder. I happen to like constexpr ;)
Someone 5y ago
If you refer to that z somewhere, depending on its value and use it might exist as a separate value in the executable, as part of one or more instructions, or not at all (e.g. if you use that z only in if(z) phrases) > This ain't right. That’s an opinion that’s not universally shared. One could similarly write These refer to variables that can be changed in memory when the program is running: int a; extern int b; static int c; volatile int d; And this refers to something that cannot be changed at runtime: const int z = 1; This ain't right. or variations on that theme with unsigned, values vs pointers, int vs long, etc. In all cases, that “this ain’t right” doesn’t logically follow. Why would yours?

by eps 5y ago

moonchild 5y ago

typedef int w; This also refers to something that exists only at compile time. Where's the inconsistency? constexpr makes a lot more sense as a storage class than typedef.

elteto 5y ago

I’m really not seeing what the issue is here. Could you expand on it? As a programmer why do I have to reason or care whether something is compile time only or not? I don’t worry about constant folding but it is a similar thing.

eps 5y ago
Proposed constexpr syntax mimics that of a conventional variable, yet it doesn't create one and comes with distinctly different usage semantics. It's a different language element, I see no reason why it should be bundled up with another one.
- elteto 5y ago
  Conventional variable syntax may not create a variable either. The compiler elides as it can or sees fit. This is my point, you don’t reason about these details today, why should constexpr be different?
  - huhtenberg 5y ago
    Because constexpr and variables are not the same thing? E.g. with a variable you can still always take its address. With constexpr you can't. Plus 'constexpr' is a patently ugly keyword. Also an important metric to consider :)
    - elteto 5y ago
      My point is that arguing about what is a variable is moot in the presence of compiler optimizations. You might think that taking and address makes a difference but if the compiler decides that it can elide it will (for example if the taken address never leaves the local scope and the variable is purely local then the compiler might be able to optimize it away). Regarding ugliness… Idk beauty is in the eye of the beholder. I happen to like constexpr ;)

Someone 5y ago

If you refer to that z somewhere, depending on its value and use it might exist as a separate value in the executable, as part of one or more instructions, or not at all (e.g. if you use that z only in if(z) phrases) > This ain't right. That’s an opinion that’s not universally shared. One could similarly write These refer to variables that can be changed in memory when the program is running: int a; extern int b; static int c; volatile int d; And this refers to something that cannot be changed at runtime: const int z = 1; This ain't right. or variations on that theme with unsigned, values vs pointers, int vs long, etc. In all cases, that “this ain’t right” doesn’t logically follow. Why would yours?