Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: C Programming Tutorial on Youtube Date: Sat, 15 Oct 2016 14:55:58 -0700 Organization: None to speak of Lines: 83 Message-ID: References: <8be0cdbe-c2f4-42ec-b6a7-e9a154981718@googlegroups.com> <878ttp5vph.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="d0721e8dde95c3bcc5de2a1c92f543fd"; logging-data="2955"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+v2eXfG5T6bvKbaWDQ6fnh" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:O4ikBYPOkAnPnkLw71XXbpVvquw= sha1:CjEPE1/SrLgRpZpU2e9Bxq4qToY= Xref: csiph.com comp.lang.c:94883 BartC writes: > On 15/10/2016 19:11, Ben Bacarisse wrote: [...] >> Do you promise to complain, from now on, every time someone writes >> >> int x; >> >> and refers to x as an int by saying "no, it is set up as the address of >> a location that /contains/ an int"? If so, then your dogged consistency >> should be applauded. > > That's not the same. > > You understand that in RD's example, and disregarding type, there is an > extra level of indirection between the value of 'pointer' and the value > of &buffer? That is before implementations apply optimisations: the > language will have the extra indirection, the implementation may choose > to by-pass it. I don't know what "extra level of indirection" you're talking about. Given: int buffer[1024]; int * const pointer = buffer; both `&buffer` and `pointer` are expressions of pointer type. They point to the same memory location, but they're of different types; `int (*)[1000]` (pointer to array of 1000 ints) and `int*`. I can't tell what point you're making. > This is similar to someone saying that use of the x in this declaration: > > const int x = 5848; > > is exactly the same as using an immediate integer value (eg. 5848). There are of course differences. `5848` is a constant and a constant expression; `x` is neither, and is an lvalue. But when used in an expression in a context that doesn't require an lvalue, both yield the same value of the same type. > There is also an extra level of indirection, although compilers find it > much easier to eliminate that in generated code. That doesn't change the > fact that the two are treated differently in the language: > > int A[x]; // not allowed at filescope > int B[5848]; // allowed > > &x; // allowed > &5848; // not allowed > > case x: // not allowed > case 5848: // allowed > > Compare the behaviour of the above with, say, one of my languages (but > I'll illustrate it using C syntax): > > const int x = 5848; // does not result in extra indirection > > int A[x]; // allowed at file scope > int B[5848]; // allowed > > &x; // not allowed > &5858; // not allowed > > case x: // allowed > case 5848: // allowed > > Notice the symmetry? C can get this behaviour using: > > enum (x = 5848}; > > but it just shows there is something fundamentally different between x > as an enum, and x as a const int. Yes, we know that. The name of a const-qualified object is not a constant expression. -- Keith Thompson (The_Other_Keith) kst-u@mib.org 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"