C declarations are half backward
-
What has bothered me more is the fact that: int* pa; int *pa; are the same. Had I been Bjorn, I wouldn't have allowed the latter.
I can see why but on the other hand I don't like the idea of significant whitespace between tokens in language. It's one of the reasons I don't like Python.
Real programmers use butterflies
-
Does it bother anyone else that you declare a pointer like:
char* sz; // pointer type, pointer declared *with* type
But an array is declared like this:
char sz[1024];// array type, array declared *after* var name
I think it's inconsistent, and I think the array specifier should have been declared with the type since it's essentially a type modifier like * and & Maybe it's just me?
Real programmers use butterflies
They are literally half backward. In order to understand a C type definition, you ping-pong between the part before the name and the part after, until all tokens have been processed. X| If there is one single thing for K&R ought to have been taken out and shot, this is it! :|
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
Does it bother anyone else that you declare a pointer like:
char* sz; // pointer type, pointer declared *with* type
But an array is declared like this:
char sz[1024];// array type, array declared *after* var name
I think it's inconsistent, and I think the array specifier should have been declared with the type since it's essentially a type modifier like * and & Maybe it's just me?
Real programmers use butterflies
Let it Rust! :-\
-
Does it bother anyone else that you declare a pointer like:
char* sz; // pointer type, pointer declared *with* type
But an array is declared like this:
char sz[1024];// array type, array declared *after* var name
I think it's inconsistent, and I think the array specifier should have been declared with the type since it's essentially a type modifier like * and & Maybe it's just me?
Real programmers use butterflies
The usage is odd as well:
char* p = ...
*p = 'x';Vs
foo f;
foo *pf = &f;
f.x = '?';
pf->x = '!';Why invent two access operators "." and "->", when you could just use "*pf.x" and be more consistent? Or use "->" to dereference all pointers? I get the feeling bits of the C spec were thrown in just before the submission deadline ... :laugh:
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
The usage is odd as well:
char* p = ...
*p = 'x';Vs
foo f;
foo *pf = &f;
f.x = '?';
pf->x = '!';Why invent two access operators "." and "->", when you could just use "*pf.x" and be more consistent? Or use "->" to dereference all pointers? I get the feeling bits of the C spec were thrown in just before the submission deadline ... :laugh:
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
Quote:
Why do we do this? I'll tell you... I don't know. But because of this, every one of us knows what a pointer is, how to dereference it, and what K&R expect of him.
With apologies to Sholem Aleichem and to the producers of Fiddler on the Roof :)
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
Does it bother anyone else that you declare a pointer like:
char* sz; // pointer type, pointer declared *with* type
But an array is declared like this:
char sz[1024];// array type, array declared *after* var name
I think it's inconsistent, and I think the array specifier should have been declared with the type since it's essentially a type modifier like * and & Maybe it's just me?
Real programmers use butterflies
-
What has bothered me more is the fact that: int* pa; int *pa; are the same. Had I been Bjorn, I wouldn't have allowed the latter.
-
Does it bother anyone else that you declare a pointer like:
char* sz; // pointer type, pointer declared *with* type
But an array is declared like this:
char sz[1024];// array type, array declared *after* var name
I think it's inconsistent, and I think the array specifier should have been declared with the type since it's essentially a type modifier like * and & Maybe it's just me?
Real programmers use butterflies
char* means you should read the footnote. * array declarations in C may or may not be consistent.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
If you read it in reverse it can make more sense:
// extra space before asterisk for readability (I never use it)
char * sz; // sz is a pointer to a character variablechar sz[1024]; // sz is an array of character types
The floating asterisk looks lonely!
Real programmers use butterflies
-
Does it bother anyone else that you declare a pointer like:
char* sz; // pointer type, pointer declared *with* type
But an array is declared like this:
char sz[1024];// array type, array declared *after* var name
I think it's inconsistent, and I think the array specifier should have been declared with the type since it's essentially a type modifier like * and & Maybe it's just me?
Real programmers use butterflies
I wrote this in a previous life: [How to interpret complex C/C++ declarations](https://www.codeproject.com/Articles/7042/How-to-interpret-complex-C-C-declarations)
Cheers, विक्रम "We have already been through this, I am not going to repeat myself." - fat_boy, in a global warming thread :doh:
-
If you read it in reverse it can make more sense:
// extra space before asterisk for readability (I never use it)
char * sz; // sz is a pointer to a character variablechar sz[1024]; // sz is an array of character types
There's a stricter formal rule, called the Right-Left rule. I wrote my only technical article on CP more than 15 years back on just this: [How to interpret complex C/C++ declarations](https://www.codeproject.com/Articles/7042/How-to-interpret-complex-C-C-declarations)
Cheers, विक्रम "We have already been through this, I am not going to repeat myself." - fat_boy, in a global warming thread :doh:
-
There's a stricter formal rule, called the Right-Left rule. I wrote my only technical article on CP more than 15 years back on just this: [How to interpret complex C/C++ declarations](https://www.codeproject.com/Articles/7042/How-to-interpret-complex-C-C-declarations)
Cheers, विक्रम "We have already been through this, I am not going to repeat myself." - fat_boy, in a global warming thread :doh:
-
What has bothered me more is the fact that: int* pa; int *pa; are the same. Had I been Bjorn, I wouldn't have allowed the latter.
Agree, the later makes no sense.
I'm not sure how many cookies it makes to be happy, but so far it's not 27. JaxCoder.com
-
Does it bother anyone else that you declare a pointer like:
char* sz; // pointer type, pointer declared *with* type
But an array is declared like this:
char sz[1024];// array type, array declared *after* var name
I think it's inconsistent, and I think the array specifier should have been declared with the type since it's essentially a type modifier like * and & Maybe it's just me?
Real programmers use butterflies
And?
-
Does it bother anyone else that you declare a pointer like:
char* sz; // pointer type, pointer declared *with* type
But an array is declared like this:
char sz[1024];// array type, array declared *after* var name
I think it's inconsistent, and I think the array specifier should have been declared with the type since it's essentially a type modifier like * and & Maybe it's just me?
Real programmers use butterflies
Stop whining. :) Declarations made easy. Computer Language Magazine, May, 1991.
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
-
Does it bother anyone else that you declare a pointer like:
char* sz; // pointer type, pointer declared *with* type
But an array is declared like this:
char sz[1024];// array type, array declared *after* var name
I think it's inconsistent, and I think the array specifier should have been declared with the type since it's essentially a type modifier like * and & Maybe it's just me?
Real programmers use butterflies
Without wishing to start a major language debate, I think its important to understand that C was designed to be efficient at using the underlying hardware of the machine, and the way things are declared reflects this: char *sz declares a single variable that points to a place in memory, supposedly holding a char value. This pointer (and here's where dragons lie!) can be made to point to anywhere and to anything regardless of its declaration, you are just telling the compiler that at the place where that pointer points, YOU consider there to be a char value (whether it is or not in reality). char sz[1024] says that at the address represented by sz is a reserved block of memory that holds (in theory) 1024 char items. In your code you can (with some severe caveats!) use both variables in the same way and it's up to you to remember and manage whatever you think you are looking at in that location - this is both the beauty and danger of a language like C - it allows you to manipulate things in much the same way as in assembler and with as few restrictions, but it provides no protection against you doing something stupid. However, even the early compilers would detect if you attempted to treat these two variables as exactly equivalent, but would often only warn rather than prevent it, allowing you to create absolute havoc. Much code rot is caused by the developer incorrectly assuming that, by default, either of these variables is initialised (which is why most compilers these days will attempt to put something sensible in newly declared variables to protect the innocent). Before initialisation char *sz may contain a random address and even attempting to look at it might cause a total system crash if it accidentally points into hardware protected memory. With char sz[1024] though you can be sure that doing char x = *sz is safe because sz already holds a valid address and points into memory allocated to your program, what you don't know is what value you will actually get back from that place before the array is initialised. Why have I bored you all with this stuff? Because so many developers these days seem to know absolutely nothing at all about how the hardware they are driving works - that's fine if you are writing in a high-level domain specific language where everything like that is hidden - no help at all if you are writing a device driver for some complex piece of hardware that is integrated into an operating system of some sort.
-
Does it bother anyone else that you declare a pointer like:
char* sz; // pointer type, pointer declared *with* type
But an array is declared like this:
char sz[1024];// array type, array declared *after* var name
I think it's inconsistent, and I think the array specifier should have been declared with the type since it's essentially a type modifier like * and & Maybe it's just me?
Real programmers use butterflies
Java's stupid (=political) C compatibility C started as a simple language on top of assembly language. Lingual considerations of abstractional consistency had no priority. As error awareness. Everything is an int, boolean, pointer, array, functions. In fact declarations have a weird kind of syntax requiring a large parsing. Or for a human a bit of back-and-forth reading. As java was launched, it intended to improve some parts of C++/C. So in java the entire type info becomes separate from the variable.
char[] jarr; // Normal java.
But as novice java kept the C style for accustomed C/C++ programmmers:
char jarr[]; // Obsolete C style java.
If one looks at java's:
char[] jarr = new char[1024];
one get's an idea why C chose:
char str[1024];
The 1024 is not part of the `char*` data structure as field, but some compile time allocation. In general one should accept C as it is: a compiler strong, thin layered, fun language. For language features it is pedagogical unsuited w.r.t. type systems, actual data, error prevention and so on. Taking any language, like a simple Pascal, might give less confusion with pointer versus array like in parameter passing. Then going back to C one sees that arrays are passed as pointers i.o. the pointed-to data as in Pascal.
-
Does it bother anyone else that you declare a pointer like:
char* sz; // pointer type, pointer declared *with* type
But an array is declared like this:
char sz[1024];// array type, array declared *after* var name
I think it's inconsistent, and I think the array specifier should have been declared with the type since it's essentially a type modifier like * and & Maybe it's just me?
Real programmers use butterflies
When I was learning C, it bothered and confused me. Now, I recognized it as the type and it doesn't bother me. Is that age, tolerance, or just exposure to too many languages???
-
When I was learning C, it bothered and confused me. Now, I recognized it as the type and it doesn't bother me. Is that age, tolerance, or just exposure to too many languages???
Yeah I've coded in C and C++ for a long time, to the point where it doesn't confuse me. I just don't like the inconsistency. I understand why it is from a syntax perspective. In c#
int[] array = new int[10];
But in C it doesn't make sense to use new, and
int[10] array;is ugly. Still, it just bugs me, because they're both type modifiers.Real programmers use butterflies
-
Without wishing to start a major language debate, I think its important to understand that C was designed to be efficient at using the underlying hardware of the machine, and the way things are declared reflects this: char *sz declares a single variable that points to a place in memory, supposedly holding a char value. This pointer (and here's where dragons lie!) can be made to point to anywhere and to anything regardless of its declaration, you are just telling the compiler that at the place where that pointer points, YOU consider there to be a char value (whether it is or not in reality). char sz[1024] says that at the address represented by sz is a reserved block of memory that holds (in theory) 1024 char items. In your code you can (with some severe caveats!) use both variables in the same way and it's up to you to remember and manage whatever you think you are looking at in that location - this is both the beauty and danger of a language like C - it allows you to manipulate things in much the same way as in assembler and with as few restrictions, but it provides no protection against you doing something stupid. However, even the early compilers would detect if you attempted to treat these two variables as exactly equivalent, but would often only warn rather than prevent it, allowing you to create absolute havoc. Much code rot is caused by the developer incorrectly assuming that, by default, either of these variables is initialised (which is why most compilers these days will attempt to put something sensible in newly declared variables to protect the innocent). Before initialisation char *sz may contain a random address and even attempting to look at it might cause a total system crash if it accidentally points into hardware protected memory. With char sz[1024] though you can be sure that doing char x = *sz is safe because sz already holds a valid address and points into memory allocated to your program, what you don't know is what value you will actually get back from that place before the array is initialised. Why have I bored you all with this stuff? Because so many developers these days seem to know absolutely nothing at all about how the hardware they are driving works - that's fine if you are writing in a high-level domain specific language where everything like that is hidden - no help at all if you are writing a device driver for some complex piece of hardware that is integrated into an operating system of some sort.
I think you may have misunderstood me
char[] sz = char[100];
would be more consistent even if it requires extra typing. I'm not complaining about the way accessed either, just how it's declared. I don't mind that either way sz can be accessed via pointer or array index. In this case you could dereference it with a * like you can otherwise. I'm not arguing you shouldn't be able to. It's not a huge deal for me either. I've coded in the C and C++ for years so I'm used to it. It's just a syntax wrinkle i don't like.
Real programmers use butterflies
