|
|
How about iC instead? Apple inspired
|
|
|
|
|
Oh, I'm in love with iC[^].
Veni, vidi, vici.
|
|
|
|
|
Unfortunately, if you don't know it could never be explained to you.
"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 |
|
|
|
|
|
So what's your definition of "better" (as applied to a programming language)?
/ravi
|
|
|
|
|
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 # define s 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.)
|
|
|
|