06 Jun, 2007, Luriel wrote in the 1st comment:
This is the discussion thread for C_Pointers:_The_Basics
24 Apr, 2008, exeter wrote in the 2nd comment:
Here's an interesting bit of trivia that will help you understand C pointers:

If a is the name of an array, then ais exactly the same as *(a+i). Since addition is commutative, *(a+i) is the same as *(i+a), which is the same as i[a]. Thus, assuming a is an array of, say, 4 elements, it is legal to refer to the fourth element as 3[a].

Other than reading obfuscated code, the reason I consider this a useful piece of knowledge is that it says something about the design philosophy of C. The C language is quite simple, orthogonal, and elegant, even to the point that ais syntactic sugar for *(a+i).
24 Apr, 2008, David Haley wrote in the 3rd comment:
What does it mean for a language to be "orthogonal"?

Incidentally, I'm not sure I really agree that the notation 3[a] is particularly elegant or simple; it's obscure and misleading, and frankly anybody who uses it should be shot. :wink:
25 Apr, 2008, quixadhal wrote in the 4th comment:
Heh.

Quote
In computer terminology, something - such as a programming language or a data object - is orthogonal if it can be used without consideration as to how its use will affect something else.

In itself, a programming language is orthogonal if its features can be used without thinking about how that usage will affect other features. Pascal is sometimes considered to be an orthogonal language, while C++ is considered to be a non-orthogonal language.

So, provided you don't use pointers, C is orthogonal. :)

Oh, and if you don't like: *(a + i) = x++;
you really won't like things like: (unsigned char *)(53281) = 15; (unsigned char *)(53280) = *(unsigned char *)(53281);

Which, on the C compiler I had for my venerable Commodore 64, would set the screen background color to light grey, and then set the border color to match the background color.

Yes, that C for poke and peek, which you really can't do in protected memory environments (unless you're writing device drivers or code for the kernel itself).
25 Apr, 2008, David Haley wrote in the 5th comment:
See, that's the definition of orthogonal that I knew about, but he couldn't possibly have been referring to that one because he used it in the same breath as talking about pointers. :wink: So I was (and still am) confused about what was meant by stating that C is orthogonal…

you really won't like things like: (unsigned char *)(53281) = 15; (unsigned char *)(53280) = *(unsigned char *)(53281);

I don't like it, but not because it's writing to strange memory locations, but because it doesn't use constants to refer to those memory locations. :wink: There's nothing wrong with using pointers to do things like that; what bugs me is when a feature is used in a way that is correct but needlessly complicated. I don't really see the point in having the notation 3[a] do anything useful at all. But I do see at least one reason for it to not exist: if somebody typed that, they might not have meant to type that (maybe '3' should be 'e'), so it should be worth a warning.
25 Apr, 2008, Guest wrote in the 6th comment:
you really won't like things like: (unsigned char *)(53281) = 15; (unsigned char *)(53280) = *(unsigned char *)(53281);

Which, on the C compiler I had for my venerable Commodore 64, would set the screen background color to light grey, and then set the border color to match the background color.

Yes, that C for poke and peek, which you really can't do in protected memory environments (unless you're writing device drivers or code for the kernel itself).

Wow. How bizarre is it that when I first read 53281 and 53280 the first thing that lept from the dark corners of my mind was "hmm… peek and poke" and then you mention it the next line down :)

I loved my C64.
06 May, 2008, exeter wrote in the 7th comment:
DavidHaley said:
See, that's the definition of orthogonal that I knew about, but he couldn't possibly have been referring to that one because he used it in the same breath as talking about pointers. :wink: So I was (and still am) confused about what was meant by stating that C is orthogonal…

Heh. I meant that in the sense that addition means the same in any context, whether the operands are integers or pointers.

Also, just because I called the C language "simple," doesn't mean I think pointer notation is simple for humans to parse. It's not. It's simple for computers, but, conveniently, the language provides the array notation as syntactic sugar for us mere mortals.
09 Jul, 2008, Fizban wrote in the 8th comment:
C isn't simple for computers, C is a high-level language, low-level languages are simple for computers, high-level languages are (relatively) simple for humans.
09 Jul, 2008, The_Fury wrote in the 9th comment:
Fizban said:
C isn't simple for computers, C is a high-level language, low-level languages are simple for computers, high-level languages are (relatively) simple for humans.

C is a low level language, high level languages include the likes of Lua, Pearl and Python.
09 Jul, 2008, David Haley wrote in the 10th comment:
I'm not sure it really makes sense to be speaking of languages as more or less simple for computers… All the computer understands in the end of the day is assembly. :shrug: As for C's status, well, you're both right. C actually is a high-level language when compared to assembly; it is a low-level language compared to many of the more recently created/popular languages.
09 Jul, 2008, The_Fury wrote in the 11th comment:
DavidHaley said:
I'm not sure it really makes sense to be speaking of languages as more or less simple for computers… All the computer understands in the end of the day is assembly. :shrug: As for C's status, well, you're both right. C actually is a high-level language when compared to assembly; it is a low-level language compared to many of the more recently created/popular languages.

Yes sorry your right, historically all 3Gen languages are considered high level, while assembler and co are considered low level. While 4Gen onwards are considered very high level languages. Well thats how it was taught when i studied IT in the late 80's and early 90's. I take a more liberal approach, as some do, and consider C to be low level as it retains the ability to manipulate memory directly by address and has has the ability to directly access the assembler level of processors.
09 Jul, 2008, David Haley wrote in the 12th comment:
I've not heard of "3gen" vs. "4gen", but sure, I agree, C is definitely one of the lowest-level high-level languages out there. :wink:
10 Jul, 2008, The_Fury wrote in the 13th comment:
Sorry for being cryptic, Third and Fourth generation languages.
10 Jul, 2008, David Haley wrote in the 14th comment:
No, I know, I just meant that I'd not heard of a categorization like that before. :wink: The categorizations I know of are in terms of language features, e.g. dynamic vs. static scope, typing systems, imperative vs. functional, etc.
10 Jul, 2008, Caius wrote in the 15th comment:
I seem to remember such classifications myself back in the early 90's. I also think C was called a high-level language back then because assembler coding was much more common. Lots of hobby assembler coders poking around with their Amigas and Ataris. Who remembers the old demo scenes?
11 Jul, 2008, Conner wrote in the 16th comment:
*raises his hand before realizing that he might be showing his age again*
05 Jun, 2009, Runter wrote in the 17th comment:
Quote
–Here's an interesting bit of trivia that will help you understand C pointers:

If a is the name of an array, then ais exactly the same as *(a+i). Since addition is commutative, *(a+i) is the same as *(i+a), which is the same as i. Thus, assuming a is an array of, say, 4 elements, it is legal to refer to the fourth element as 3.

Other than reading obfuscated code, the reason I consider this a useful piece of knowledge is that it says something about the design philosophy of C. The C language is quite simple, orthogonal, and elegant, even to the point that a is syntactic sugar for *(a+i).

I'm not sure I call this elegance.

It's about as elegant as this gem:
`int *ptr, i[2], z[2], p[2];// initialize all to elements in i, z, p to 1 … 6.for(ptr = i;ptr < &p[1];++p)    i[(int)ptr - (int)i] = (int)ptr-(int)i+1;// swap the contents of z[0] and i[0]z[0] ^= i[0]i[0] ^= z[0]z[0] ^= i[0]// elegance ftw`
05 Jun, 2009, elanthis wrote in the 18th comment:
He was saying that the design of C was elegant, not that every stupid C trick you can pull off is elegant. I can write an ugly loop like that in pretty much any language. His point about elegance was that C has a small handful of very simple concepts which can be put together to build much higher-level concepts, all without requiring those high-level features built into the language itself.

Some languages are limited in their expressiveness, unlike C, because they take the approach of building in a ton of (admittedly easier to use) high-level facilities, but do not give the user enough flexibility to easily create his own high-level facilities… especially if he wants them to behave like the built-in ones. C was very elegant and noteworthy for its time, hence its enduring popularity.
05 Jun, 2009, David Haley wrote in the 19th comment:
I don't think "expressiveness" is the right word here. Many languages that don't let you do pointer math are in many ways far more "expressive" than C because you can say much more things much more easily at a much higher level of abstraction. I guess it depends on how you're defining "expressiveness". If we're just talking about the quasi-mathematical language-theory meaning of how many things you can say in a language (where e.g. first-order logic is strictly more expressive than propositional logic), then assembler can do at least whatever C can and so is at least as expressive. But that's clearly not what you meant, since you were implicitly contrasting C with other programming languages available at the time. So what do you mean by "expressiveness" here?
05 Jun, 2009, Runter wrote in the 20th comment:
elanthis said:
He was saying that the design of C was elegant, not that every stupid C trick you can pull off is elegant. I can write an ugly loop like that in pretty much any language. His point about elegance was that C has a small handful of very simple concepts which can be put together to build much higher-level concepts, all without requiring those high-level features built into the language itself.

Some languages are limited in their expressiveness, unlike C, because they take the approach of building in a ton of (admittedly easier to use) high-level facilities, but do not give the user enough flexibility to easily create his own high-level facilities… especially if he wants them to behave like the built-in one.

I'm turning over a new leaf. Avoiding confrontation.
That being said, I was being a little facetious earlier. I have developed with C for over 10 years, myself.
I know the many benefits and the many draw backs.
Quote
since you were implicitly contrasting C with other programming languages available at the time.

Circa 1970's. I'm not sure it's still considered elegant by many people.

Quote
C was very elegant and noteworthy for its time, hence its enduring popularity.

I think the enduring popularity in the mudding community is the unduly representation in the codebases and the friendly support from the community on those languages.
Nobody can argue it is the best choice without those factors. Even with all of it's expressive elegance.
Random Picks

0.0/34