Because *C* has a bias in that direction. I was trying to understand
that assertion because it seems like nonsense to me, and now everyone
wants to pretend it was never made. That's fine. If you guys wantto
make nonsensical assertions and then pretend you were making sense the
whole time it's no problem with me, I'll just remain unconvinced.
We've got ten employees, each with name, payroll id, and salary.
we can represent the data like this
typedef struct
{
char name[64];
int id;
float salary;
} EMPLOYEE;
EMPLOYEE employees[10];
or like this
typedef struct
{
char name[10][64];
int id[10];
float salary[10];
} EMPLOYEES;
EMPLOYEES employees;
The two methods hold the same data, and have the same access
characteristics - iterating through the list is done in O(N) time,
random access is in O(constant) time, searching for the maximum salary
takes O(N) time, etc. Theya are logically equivalent.
I thought nobody was saying that!!!!
The truth is that they are not at all logically equivalent. The
difference between the two is 100% logical.
The only
difference is the way the employees are laid out in memory.
There could be no difference in how they're laid out in memory, the
difference is in their *logical* structure--completely the opposite of
what you're saying. I can write the statements to access a field in
English and the difference is still there:
Get the N'th employee from the employee's array and access its id
field.
Get the ids field from the employees structure and access its N'th
element.
No matter what syntax I use that is specific enough for talking to a
computer, I'm still going to have to access the elements in different
manners.
The first way is better for C, but that's largely because of C's
syntax. We can imagine language x where you can declare arrays of
records, and all the fields are contiguous, and this is transparent to
the user. You'd use a syntax like field(employees, i, salary) *= 1.1; /
* increment employee's salary by 10 % */
The second method has certain advantages. For instance, if we want the
average salary, we have an array of floats ready to be passed to a
generic mean() function.
Not in language X. In language X you're using the field() syntax.
You've essentially got an array of structures in language X no matter
what you might want and you're writing your generic mean function to
use binder expressions like: mean(field(employees, _1, salary)). You
can do this in C by the way though not at quite that high level
(you'll be writing custom functions to serve as binder expressions).
With the first method, ypu've got to either
write an special mean_employee_salary() function, use a temporary
buffer, or fake up the "field" syntax using a stride, offset, and some
pointer jiggery-pokery.
Which is all "language X" is. You could write it in C as a macro and
then still access the underlying memory. It's all going to depend
upon the needs of your program.
All you're doing here is arguing for abstractions. You're not showing
that C's syntax forces you into one form of data expression or
another, you're saying that it would be nice to be able to manipulate
your data at a higher level than structures and arrays. There's
nothing stopping you from doing that in C and there's nothing that
makes it more or less difficult except perhaps a lack of utility
functions in the standard library, which is not a syntax issue.
It is true that there are many languages at higher levels than C that
support the kind of expressions you're talking about. C++ in fact
provides much of the functionality you want here, or at least better
facilities to create it. But when you get to this point you're no
longer talking about structures and arrays, you're talking about even
higher level concepts. I do agree that abstractions can be a
wonderful thing, but this is clearly not a C specific issue.
