Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #163209
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: on the order of the const-keyword |
| Date | 2021-10-28 15:13 -0700 |
| Organization | None to speak of |
| Message-ID | <87a6is23xa.fsf@nosuchdomain.example.com> (permalink) |
| References | <86mtmtm9m1.fsf@levado.to> <sleiul$8m0$1@dont-email.me> <a25df1f0-687b-4489-8f2f-6daa35593040n@googlegroups.com> <994066a9-5940-4d1c-8df4-517905174930n@googlegroups.com> |
Thiago Adams <thiago.adams@gmail.com> writes:
> On Thursday, October 28, 2021 at 4:56:18 PM UTC-3, Thiago Adams wrote:
> ...
>> > 'const' (as well as short, int, long, float, double, even static and
>> > typedef) can occur anywhere, in any combination, in the declaration of a
>> > base type (what goes on the left before the first variable).
>
> I also have a new definition for typedef considering how it works.
>
> We use to say typedef is a alias for a type name.
>
> But here ,
>
> typedef int Int;
> typedef unsigned Int T; //error
>
> Int does not work as a alias for int.
Yes, it absolutely does. Given your first declaration, `Int` is an
alias for the *type* `int`, not for the *keyword* `int`. It's not a
macro, and it doesn't act like one.
The `unsigned` keyword can only be used as the syntax allows, and the
syntax doesn't allow it to be used with a typedef name. The `unsigned`
keyword can be used by itself as a type name, or along with the `char`,
`short`, `int`, and/or `long` keywords, as defined in N1570 6.7.2.
> So my definition is:
> when we put typedef in a declaration we declare a variable that has no
> storage.
No, that's not what it does. It doesn't declare a variable at all, with
or without storage, unless you stretch the meaning of "variable" almost
beyond recognition. (Note that the C standard doesn't use the term
"variable".). Rather, the `typedef` keyword is treated as a storage
class specifier for syntactic convenience.
> When we use this variable is the same of using typeof(variable) but
> we write just the variable name.
> Int x;
> So typedef is more like "use the same type of that variable here".
>
> considering this.... I was also considering to use typedef to define constants
>
> typedef double pi = 3.14;
> or
> valuedef double pi = 3.14;
>
> pi is a non-storage variable, but instead of copying its type
> we copy its initialization value.
>
> double x = pi;
That's more or less what `constexpr` does in C++, and what `const`
*almost* does in C. Using `typedef` for this would not in my opinion
make sense.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
on the order of the const-keyword Meredith Montgomery <mmontgomery@levado.to> - 2021-10-28 12:50 -0300
Re: on the order of the const-keyword Bart <bc@freeuk.com> - 2021-10-28 17:25 +0100
Re: on the order of the const-keyword "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-10-28 10:10 -0700
Re: on the order of the const-keyword Guillaume <message@bottle.org> - 2021-10-28 20:40 +0200
Re: on the order of the const-keyword Meredith Montgomery <mmontgomery@levado.to> - 2021-10-29 00:07 -0300
Re: on the order of the const-keyword James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-29 00:48 -0400
Re: on the order of the const-keyword Thiago Adams <thiago.adams@gmail.com> - 2021-10-28 12:56 -0700
Re: on the order of the const-keyword Thiago Adams <thiago.adams@gmail.com> - 2021-10-28 13:18 -0700
Re: on the order of the const-keyword Bart <bc@freeuk.com> - 2021-10-28 21:35 +0100
Re: on the order of the const-keyword Thiago Adams <thiago.adams@gmail.com> - 2021-10-28 13:57 -0700
Re: on the order of the const-keyword Thiago Adams <thiago.adams@gmail.com> - 2021-10-28 14:07 -0700
Re: on the order of the const-keyword Bart <bc@freeuk.com> - 2021-10-28 22:54 +0100
Re: on the order of the const-keyword Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-28 15:37 -0700
Re: on the order of the const-keyword Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-10-29 00:02 +0100
Re: on the order of the const-keyword Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-10-28 22:10 +0100
Re: on the order of the const-keyword Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-28 15:13 -0700
Re: on the order of the const-keyword Meredith Montgomery <mmontgomery@levado.to> - 2021-10-29 00:40 -0300
Re: on the order of the const-keyword Meredith Montgomery <mmontgomery@levado.to> - 2021-10-28 23:48 -0300
Re: on the order of the const-keyword James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-28 13:04 -0400
Re: on the order of the const-keyword Meredith Montgomery <mmontgomery@levado.to> - 2021-10-29 00:34 -0300
Re: on the order of the const-keyword David Brown <david.brown@hesbynett.no> - 2021-10-29 10:03 +0200
Re: on the order of the const-keyword Bart <bc@freeuk.com> - 2021-10-29 11:30 +0100
Re: on the order of the const-keyword David Brown <david.brown@hesbynett.no> - 2021-10-29 16:31 +0200
Re: on the order of the const-keyword Bart <bc@freeuk.com> - 2021-10-29 16:45 +0100
Re: on the order of the const-keyword David Brown <david.brown@hesbynett.no> - 2021-10-29 18:30 +0200
Re: on the order of the const-keyword Manfred <noname@add.invalid> - 2021-10-30 00:32 +0200
Re: on the order of the const-keyword Meredith Montgomery <mmontgomery@levado.to> - 2021-10-29 20:03 -0300
Re: on the order of the const-keyword Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-10-30 01:10 +0100
Re: on the order of the const-keyword Bart <bc@freeuk.com> - 2021-10-29 23:51 +0100
Re: on the order of the const-keyword Meredith Montgomery <mmontgomery@levado.to> - 2021-10-29 12:22 -0300
Re: on the order of the const-keyword David Brown <david.brown@hesbynett.no> - 2021-10-29 18:34 +0200
Re: on the order of the const-keyword Meredith Montgomery <mmontgomery@levado.to> - 2021-10-29 17:04 -0300
csiph-web