|
|
What else would they do?
As the article essentially points out, this is known. It's documented. There is no mystery.
|
|
|
|
|
Written by Walter Bright, who invented D and is still tilting at windmills over it.
He's wrong. Arrays are pointers. Period. That's how they really are and to pretend they are something special or different is absurd. What's even more absurd is his claim that they "...and lose the information which gives the extent of the array - the array dimension." THEY NEVER HAD IT (unless a developer decided to make the array that way.) It's the very definition of a strawman argument.
If you don't understand pointers, just say so and use a language "without" them (ha! all computer languages end up using pointers, they just hide them.)
|
|
|
|
|
Joe Woodbury wrote: He's wrong. Arrays are pointers. Period. That's how they really are and to pretend they are something special or different is absurd. What's even more absurd is his claim that they "...and lose the information which gives the extent of the array - the array dimension." THEY NEVER HAD IT (unless a developer decided to make the array that way.) It's the very definition of a strawman argument.
Agreed! 
Jeremy Falcon
|
|
|
|
|
Joe Woodbury wrote: Arrays are pointers
Joe Woodbury wrote: the information which gives the extent of the array - the array dimension." THEY NEVER HAD IT
char *p = "hello";
char q[] = "hello";
printf("%zu\n", sizeof(p));
printf("%zu\n", sizeof(q));
|
|
|
|
|
Nemanja Trifunovic wrote: char *p = "hello"; //pointer - no information about the dimension
char q[] = "hello"; // array - contains information about the dimension
No the ARRAY does not. The declaration does and thus the precompiler) and sizeof(), but not the array itself.
To illustrate, the function:
void _function(const char r[])
{
printf("%u\n", sizeof(r));
}Will print 4 or 8, depending on the size of a pointer, when you call _function(q);.
Added: Moreover, an optimizing compiler will likely pool both strings and use the same pointer for both operations (especially since it's clear they are both const.) Again, the sizeof() is handled by the precompiler, not at runtime.
modified 29-May-14 19:06pm.
|
|
|
|
|
Joe Woodbury wrote: The declaration does and thus the precompiler) and sizeof(), but not the array itself.
Rather certain that the precompiler is in fact part of the language since it is in fact part of the specification for the language. If you wish to another definition for "language" than the specification then you would need to provide one.
And if one wants to be specific then at least in my edition of "C Programming Language 2nd Edition" the preprocessor is part of the main language definition (not an appendix) and the section specifically starts off with "C provides certain language facilities by mean of a processor". So if K&R thinks it is part of the language I am going to take their word for it.
Or perhaps to put in in another perspective, limiting oneself to just the "language" then C is in fact useless, since one cannot in any practical way do anything useful with the "language". Thus it can't, again in a practical, real world way, be "better" than anything else.
|
|
|
|
|
You are arguing against something I never said. Specifically, nowhere did I say that the precompiler isn't part of the language.
More generally, my point is that the information about the size of the array is known only by the scope of the array declaration at compile time; it is not contained in the array itself and available at runtime. In C, an array and a pointer are, for all intents and purposes, synonymous (with the exception of this very narrow edge case.) So, the [partial] function declarations a(const char* p) and b(const char d[]) mean the same thing. Doing a sizeof(d) for the latter doesn't tell you anything meaningful about the original array.
This also means that you can take an arbitrary pointer and use array syntax on it. i.e. p[3]. This gives C an enormous power and flexibility found in few other languages. Attaching any other information to a pointer (or array) changes the very nature of what a pointer is and adds overhead that is often not desired nor wanted (and if desired, you can easily create a struct (or class in C++) with that information contained in it. This very flexibility means that arguing that arrays are problematic in C is a strawman argument.)
|
|
|
|
|
Joe Woodbury wrote: You are arguing against something I never said.
My bad - you are correct.
|
|
|
|
|
jschell wrote: Rather certain that the precompiler is in fact part of the language
Yes, and as he said in his response, he didn't say otherwise. Some points I'd like to make are:
A language is defined by its compiler (not the other way around).
DMR probably could have made C without a pre-processor; I see no reason that C has to have a pre-processor other than that it does have a pre-processor. The existence of D and C# may support this view.
I have seen (I don't remember where) at least one argument that the C pre-processor acts on a different language than the C compiler does; and I am in about 90% agreement with that point of view.
I like the C pre-processor; it's really just a text processing utility -- it can be used for purposes other than its primary usage. (I even use it with C# -- Implanting Common Code in Unrelated Classes[^]) Unfortunately, it also has some functions (e.g. sizeof) that are tightly bound to C. 
jschell wrote: limiting oneself to just the "language" then C is in fact useless, since one cannot in any practical way do anything useful with the "language"
You may be arguing that the language is pretty limited without libraries, and that is quite true, very little can be accomplished without at least printf -- I have written a simple program that calculates a value and returns it from main, simply to demonstrate that something, no matter how pointless, can be done without linking in any libraries. However, I think the article was also pointing out the ease with which a developer can leverage a multitude of libraries with C. Just the other week I was playing with ODBC, and linking in only the ODBC libraries and not the "standard C libraries".
Of course, doing so still requires the pre-processor, as the Creator intended.
jschell wrote: I am going to take their word for it
Soooo... if Microsoft says that VB is the World's Greatest Language.... ? 
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
PIEBALDconsult wrote: A language is defined by its compiler (not the other way around).
No. Compiler theory is a very complete area of study in computer science and most perhaps all successful languages build upon that. And within compiler theory the compiler is an implementation, nothing more.
And in terms of C, although perhaps not specifically this discussion, there are many ambiguities which the compiler is allowed to define but others which it is not.
PIEBALDconsult wrote: I like the C pre-processor; it's really just a text processing utility -- it can be used for purposes other than its primary usage
With something like 20 years of C/C++ experience I am pretty comfortable with what the language is and isn't.
PIEBALDconsult wrote: and that is quite true,
As I said.
PIEBALDconsult wrote: Soooo... if Microsoft says that VB is the World's Greatest Language....
Well first I was noting a technical point not a subjective one.
Second K&R when it was written was written in a different style than VB, so even if the author(s) of VB made a technical point then I would be less inclined to accept it (which is true of C# and Java as well.)
|
|
|
|
|
Bushwa! That is one of its greatest strengths! There were only three mistakes in C, and one was fixed in C89 (if I recall correctly). The other two continue to plague us.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
No such discussion would be meaningful without first defining "better".
|
|
|
|
|
Ahh yes c and paradox. mmmmhmmmm good.
|
|
|
|
|
Perhaps.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
It may be fast, but not as fast as MASM. Just look at some of the created code in the .cod listing. Many, many, pipeline stalls in code initialization where a push and pop of ebx would free that reg to share loading eax, then ebx, then saving eax, then saving ebx, and this was in optimized code in a high use function in JKDEFRAG.
I'll stick with MASM.
Dave.
|
|
|
|
|
Ahm, how about this language[^]? 
Don't mind those people who say you're not HOT. At least you know you're COOL.
I'm not afraid of falling, I'm afraid of the sudden stop at the end of the fall! - Richard Andrew x64
|
|
|
|
|
'C' was its grade as a a programming language.
C++ got a grade of C-- 
|
|
|
|
|
I agree. Granted that may be because I don't care to name any others.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Chris, I am afraid you have the wrong information.
C is not a language, it's an alphabet.
|
|
|
|
|
Rutvik Dave wrote: C is not a language, it's an alphabet.
Actually, it is just one element in a set called an "alphabet." We also have a 'D' and 24 other members in the set.
Will Rogers never met me.
|
|
|
|
|
... and the English language has killed my joke, again! 
|
|
|
|
|
The vast majority of the software out there is written in C. The vast majority of software out there has crippling flaws, are out of budget and abandoned after tried to use. QED
|
|
|
|
|
OK, I'll "bite".
"C" is quite the most disastrous so-called "language"[1] ever to become popular.
Why? It's total lack of marshalling over record boundaries in memory have cost the globe at least several 100 trillion dollars in viruses, damages, fornicate-ups, interminable repairs/patches, Trojans, injuries, deaths, et cetera.
That alone is enough to relegate this incurable abortion of a syntactical nightmare to the bit-bucket, if not Spandau prison.
Have at it, you "C" devils.
___________________________
[1] Designed for punch-card use, brevity & conservation of card-space were essential.
It thereby became an impenetrably terse & line-break free mess. All calculated to save IBM punched cards.
And the syntax is dangerously ambiguous, all over the shop.
Don't get me started on the monumentally bone-headed notion that CASE statements should cascade through without a BREAK clause!
I mean. What total idiot "thought" that this would be a great idea?
|
|
|
|
|
Michael Kingsford Gray wrote: the monumentally bone-headed notion that CASE statements should cascade through without a BREAK
 Hear! Hear! That is (in my opinion) the very worst mistake in C.
You'll never get very far if all you do is follow instructions.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
