Is this article a sign that C has fallen out of mainstream use?
I knew this already 30 years ago. While I am happy to not ever use C again it is still useful as a low level language.
A convenient untruth: Array notation in C is a lie
31–40 of 176 posts
Re: A convenient untruth: Array notation in C is a lie
#32Earlier quoted context omitted.
No, C (and C++) is used as much as ever Is this really true, especially for C? Lots of things that used to be done in C is today done in C++ and lots of things that used to be done in C++ is today done in Java or C#.
In the embedded world, the default language is still C by a wide margin. You have to argue hard to have C++ considered and languages like Rust&Go just aren't on the radar. Only in HN world is C considered legacy. For the rest of the world, its the well-known workhorse of the software world.
For the rest of the world, its the well-known workhorse of the software world.
But it's a workhorse that's continually being replaced. I'm not talking about Rust&Go. I'm talking about C++/Java/C#. Thinking about C projects I saw 15-20 years ago, hardly any of them would be written in C if they where started today. And even in the embedded world C++ is becoming more and more of a thing.
Is C used, of course. Is C going away, of course not. Is C "used as much as ever", I just don't see it.
Re: A convenient untruth: Array notation in C is a lie
#33Is this article a sign that C has fallen out of mainstream use?
What is "mainstream" these days?
React (a javascript library, sometimes referred to as reactJS or react.js) and more specifically its most popular module, Reagent, which is a full, lazily-loaded preemptive operating system that can run concurrent Java, Pythonjs, Rubyjs programs all from your browser while allowing cooperative suspend, load and save to network or local storage, intertab cooperative process management, etc.
Basically, if you're not working in an add-on to a framework library written in javascript running in a web browser, you might as well be using punch cards. /s
I made the part about Reagent up, but you know you believed it.
We're so far from the metal we might as well be sending a telegram with our requirements.
In the five seconds it takes this crap to load and show you a still loading page, your CPU cores have done 40,000,000,000 sixty-four bit operations.
Re: A convenient untruth: Array notation in C is a lie
#34The equivalent in C# always made more sense to me (not comparing memory or allocation model between the languages, but simply syntax in relation to a person reading it): int[] arr = new int[5]; // C# int arr[5]; // C The fact that the brackets go on the datatype always made more sense to me, after all, I want to refer to memory of a certain cell size (as indicated by int). I realize that there is a lot of stuff going…
"The Design and Evolution of C++" by Bjarne Stroustrup has a section on alternate declaration syntax that he considered. Compatibility won out but you might find the suggestions interesting.
Re: A convenient untruth: Array notation in C is a lie
#35Brings back fond memories of the first time I learned C, when I really had to dig into what the difference was between storage durations (auto/stack, dynamic/heap, static, thread local). It makes it increasingly important to think about when an object is going to be stored, and for how long. To me this is still a really useful concept that most high-level languages seem to have all disregarded in favor of extremely e…
the twist with gc or refcounting is that you actually still need to think about memory management.. in many ways, unfortunately, it becomes harder to control. An advantage of user managed memory is that you always need to think about it, with every line you write so if there is an issue, it will become apparent rather quickly. Buffer overruns, however, are never much fun.. and largely avoided with auto memory management so it's clearly useful in most cases. At least with most of boring software that I write.
Re: A convenient untruth: Array notation in C is a lie
#36Brings back fond memories of the first time I learned C, when I really had to dig into what the difference was between storage durations (auto/stack, dynamic/heap, static, thread local). It makes it increasingly important to think about when an object is going to be stored, and for how long. To me this is still a really useful concept that most high-level languages seem to have all disregarded in favor of extremely e…
most high-level languages seem to have all disregarded in
favor of extremely eager GC or refcounting, with the
exception of Rust.
Sure you have ML type checking, pointer safety rules, multiple returns. But if you can see past the syntax sugar you realize it is just C (with guardrails).
Re: A convenient untruth: Array notation in C is a lie
#37The equivalent in C# always made more sense to me (not comparing memory or allocation model between the languages, but simply syntax in relation to a person reading it): int[] arr = new int[5]; // C# int arr[5]; // C The fact that the brackets go on the datatype always made more sense to me, after all, I want to refer to memory of a certain cell size (as indicated by int). I realize that there is a lot of stuff going…
I don't agree with:
int[5] arr;
int[7] arr2;
On the other hand I agree that:
int* arr;
int *arr;
int* a, b, c, d;
Re: A convenient untruth: Array notation in C is a lie
#38The equivalent in C# always made more sense to me (not comparing memory or allocation model between the languages, but simply syntax in relation to a person reading it): int[] arr = new int[5]; // C# int arr[5]; // C The fact that the brackets go on the datatype always made more sense to me, after all, I want to refer to memory of a certain cell size (as indicated by int). I realize that there is a lot of stuff going…
> I will now duck and get far away from the internet, in fear of all the hateful comments explaining to me how I am wrong, and apparently just don't understand the superior beauty of complicated C syntax. I am going to be that person :-) One phrase – "declarations mirror use". In a declaration, you use the same set of operators around the declared object that you would use in a normal expression. All of these operato…
I don't know if "declarations mirror use" gets you all the way there. You can use:
*some_index[arr]
char *5[arr];
Re: A convenient untruth: Array notation in C is a lie
#39This gets weird when you compare it to how structs work in C. Both are complex data types, so I sometimes forget that array semantics are totally different to struct/union semantics. Unlike arrays, in ANSI C, structs are real value types. You can pass them by-value to functions, return them by-value from functions and assign them by-value to variables of the same type. Also, structs never work like pointers to themselves. You have to dereference the pointer or use the -> syntactic sugar to access a member of a pointer to a struct.
Value type semantics enable some neat things, for example, you can zero all the members of a struct by assigning a compound literal to it. You can also make simple structs, like three uint8_ts for an RGB colour, and use them just like they were primitive types. In comparison, it seems almost archaic that you have to break out memset() and memcpy() to zero and move arrays.
Re: A convenient untruth: Array notation in C is a lie
#40Earlier quoted context omitted.
Four answers: No, C (and C++) is used as much as ever. HN echo chamber aside, Rust and/or Go haven't made much of a dent. No, we had such articles for decades. No, it's just an article that points some issues with C, like exist for every language and environment (e.g. tons of articles on JS shortcomings). No correlation whatsoever with such an article and the language falling out of mainstream use. No, this is a biza…
No, C (and C++) is used as much as ever Is this really true, especially for C? Lots of things that used to be done in C is today done in C++ and lots of things that used to be done in C++ is today done in Java or C#.
Well, it's second after Java in TIOBE, which, while not perfect, it checks multiple data points, so it's better than most attempts at guesstimation:
http://www.tiobe.com/tiobe-index/
It's #8 on GitHub in projects per language: http://githut.info/
And #18 on Stack Overflow: http://stackoverflow.com/tags
(and I'd say most C projects are not as likely to go to GitHub compared to JS or Javascript ones. And C programmers are not exactly the type to ask questions on SO, compared e.g. to some language where one can be an "eternal newbie".
>Lots of things that used to be done in C is today done in C++ and lots of things that used to be done in C++ is today done in Java or C#.
Lots of things that are done by Java or C# where done by other languages back in the day too. Visual Basic for enterprise apps that are now a web Java/C# frontend, Delphi, 4GL platforms, Clipper, Visual FoxPro, etc. Even games were written in assembler for most of the eighties too.