|
HERE^
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
<sigh> We're all very impressed.
/ravi
|
|
|
|
|
D language[^] is better.
It combines the simplicity of C and avoids all the kludginess of C++ for the same elegance you see in C#.
Plus...no *.H files or #defines !!!! 
Plus garbage collection!
|
|
|
|
|
DaveX86 wrote: Plus garbage collection!
As Is Well Understood and Universally Accepted: "You don't need garbage collection if your code is not garbage!"
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
W∴ Balboos wrote: You don't need garbage collection if your code is not garbage!
Awesome!
Jeremy Falcon
|
|
|
|
|
Garbage collection is a flaw, not a feature. It not only sucks resources, it creates a huge unknown. Some of the most difficult problems I've dealt with were with garbage collection (in one recent case, we never did solve the problem--some the most brilliant engineers I know also failed to solve it. Around the same time, we tracked things back to a lesser known bug in the .NET 4.0 garbage collector.)
|
|
|
|
|
Ah well, so much for my conversational gambit...
|
|
|
|
|
Well no, it's a feature. GCd environments eliminate a large group of common bugs, free the developer to think about higher level stuff and not litter their code with memory management cruft, and are in general a Good Thing. It's just that it's a feature that, in certain particular circumstances (particularly when resource usage is tight), isn't helpful.
|
|
|
|
|
DaveX86 wrote: Plus...no *.H files or #defines
The can have my # defines when they pry them from my cold, dead hands.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
|
Golden Days!^
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I agree. C is like a great macro assembler. These days, I prefer C with classes. In other words, mostly C, but using the C++ compiler and RAII and very light weight, thin classes. Above all, it's deterministic. This is the one thing I really dislike about C# and other garbage collected languages. I think it's often abused in C++, where being fancy all too often overrides elegant simplicity.
|
|
|
|
|
|
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".
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
