| James Kuyper <jameskuyper@alumni.caltech.edu>: Nov 01 12:13AM -0400 On 10/31/21 12:22 PM, Anand Hariharan wrote: > On Wednesday, October 27, 2021 at 11:26:23 AM UTC-5, james...@alumni.caltech.edu wrote: ... >> of the type, rather than a proper C++ type specification. However, if >> you declare >> int b(*)[3]; ... > I may have missed a reply (either from someone else or even yourself) but the declaration of 'b' is a syntax error. Looks like you meant > int (*b)[3]; Correct - the fact that no one else brought it up implies that very few people are bothering to pay attention to this thread. I'd guess that a lot of them have him killfiled by now. |
| Juha Nieminen <nospam@thanks.invalid>: Nov 01 06:12AM >> cast, then it's non-standard-conforming [...] > I belive that statement is not correct. Can you cite a passage (or > passages) in the C++ standard that supports this assertion? No. I made an assumption. I don't know if it's a true assumption. |
| Juha Nieminen <nospam@thanks.invalid>: Nov 01 06:15AM >>> Ok, you're either just plain thick or you're trolling now. >>Btw, I would warmly recommend that you do some self reflection. > Says Mr Depressive Aspie. Irony, much? I still recommend that you think a bit about why you feel the need to insult people. When someone challenges your assertion, and you just respond with an insult, then you should think about why you are doing that. |
| Juha Nieminen <nospam@thanks.invalid>: Nov 01 06:34AM >>and it doesn't matter what's happening "under the hood". > Do you understand the different stages of compilation? Have you heard of > lexical analysis vs parsing vs code generation? I'm guessing not. No, it's you who is being confused by two alternative syntaxes to express the same thing. void foo(int a[10]) and void foo(int *a) are declaring the exact same function. There is zero difference between them, other than just two alternative syntaxes. It's no different than, for example: int i = 5; and: signed int i = 5; The characters in the two lines may differ, but they are doing the exact same thing. In the function declaration the "10" within the brackets is completely superfluous and does absolutely nothing. It has no syntactic nor semantic meaning. You could just as well write it as "/*10*/" and it would have the same effect. And the brackets themselves are just an alternative way of expressing the same thing as the asterisk. So no, in "void foo(int a[10])" the 'a' there is not declaring an array, at any level of syntax or parsing. It's declaring a pointer. You can declare a "pointer to an array of 10 elements", which is *slightly* closer to what you want. Even here there are likewise two alternative ways to specify it: void foo(int (*a)[10]); void foo(int a[][10]); void foo(int a[124567][10]); Again, all three of the above are completely identical, and the number inside the first pair of brackets has no meaning and is superfluous. One way to discern that they are identical is that in C++ those are not overloads. They all declare the same function. (If they were function definitions, you would get an error about duplicate definitions.) Also here 'a' is not an array. It's a pointer. Just because it happens to point to an array of 10 ints doesn't make it an array. It's a pointer in every possible sense, at every possible stage of parsing, at every possible level of syntax. (The difference between an "int *a" and an "int (*a)[10]" is that the "unit" for the element pointed to by that 'a' is one single 'int' in the first case, and 10 'ints' in the second case. Thus, for example, 'a+1' would give you (typically) a pointer that's increased by 4 bytes in the first case, and 40 bytes in the second case.) > Honestly, I just give up. I wish. > Its amusing how you see yourself as some kind of expert :) No, I think it's *you* who considers yourself some kind of "expert", invoking the Dunning-Kruger effect quite hard. >>what sizeof(a) is in those two cases, is telling. > I already answered it. Yes, it'll be the size of a pointer because BY THAT > POINT it'll be treated as a pointer. There's no point at which it isn't considered a pointer. |
| David Brown <david.brown@hesbynett.no>: Nov 01 08:53AM +0100 On 01/11/2021 07:12, Juha Nieminen wrote: >> I belive that statement is not correct. Can you cite a passage (or >> passages) in the C++ standard that supports this assertion? > No. I made an assumption. I don't know if it's a true assumption. Surely you mean you /didn't/ know if it was a true assumption. Now you know it is not true. If you think it should be true - that compilers should, by default, give fatal errors on this kind of thing, then you'll probably find many agree with you. A fatal error here would also have been conforming to the standards. Compiler writers always have a balance act here, especially in their default configurations without controlling flags - do they prioritise continued compilation of old code that worked with old tool versions despite flaws, or do they prioritise reducing the risk of flaws in current and future code by being stricter? There's no easy answer, and I expect for any such decision there will be people who believe they have made the wrong one. Language standards writers face similar dilemmas. All we can do is be careful about the compiler flags we choose ourselves, and encourage their use for others. And I suppose anyone who uses rextester.com could file a bug report for their site. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Nov 01 11:26AM -0400 On 11/1/21 2:12 AM, Juha Nieminen wrote: > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> Juha Nieminen <nospam@thanks.invalid> writes: ... >> I belive that statement is not correct. Can you cite a passage (or >> passages) in the C++ standard that supports this assertion? > No. I made an assumption. I don't know if it's a true assumption. The C standard says: "The implementation shall not successfully translate a preprocessing translation unit containing a #error preprocessing directive unless it is part of a group skipped by conditional inclusion." (4p4). Ironically, any undefined behavior that a translation unit might have due to problems coming up during translation phases 1-4 might relieve an implementation of it's obligation to reject it. There's no other situation where it's prohibited for an implementation to successfully translate a program, no matter how many defects it contains, no matter how severe they are. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment