Is C just a meme language or is it really the best lightweight language?
Fuck you anon, made me spit water all over the desk.
>No serious programmer will ever use C
>I'll show that guy!
>posts a dated rant from Linus from 1993 where C++ compilers were shitty as fuck
Notice only neckbeards on /g/ claim "C IS THE BEST!!" and they have zero software to show for it.
And Linus is a big baby. Just because C++ is definitely not the right language for Linux, doesn't mean you make some autistic rant about how bad C++ is, so that other autistics copy and paste your words like you're some god.
>Software is open to expolits if the programmer makes a modest mistake (common in large projects)
>Easily buffer overflowed like nothing
>/g/ always use scanf() so I can buffer overflow their insecure piece of shit
C++ has RAII/smart pointers, so programmers can effcientely handle memory management without worrying about freeing shit. It's also strongly typed. Don't believe the neckbeards here trying to turn programming into a dick measuring contest.
>No serious programmer will ever use C
>Prove there are serious programmers, far better than you'll ever be that use C for serious work
>hurr just because it's used doesn't mean it's good!!!!111one
>C++ is strongly typed
You got me to bite, I'll give you that.
I liked it when I did a semester of it, it's not the best I've ever used but it's a good all-rounder without being bloated like many C++ projects, nor impossible to understand like Perl.
C++ might be a step further in many things, but it has a created a generation of lazy fucks and incredibly messy shit... but that's not a fault of the language, just the people.
Careful now, that neckbeard won't be able to understand those words you've just uttered. When the C neckbeard encounters words his simple mind cannot understand, he may shout "MUH SPEEDD!!!" and act as if he won this debate.
>general purpose container class that grows to fit data.
I don't understand any of those filthy OOP buzzword crap you just spouted.
Maye you can reformulate it into a language any rational being can understand.
>go to, ever in your life
go to is something I abhor to see in someone's code. It usually means "I did something wrong, this fixes it for the moment and I never bothered to get to it. I also got fired and left zero documentation."
>Well, take it from an old hand: the only reason it would be easier to program in C is that you can't easily express complex problems in C, so you don't.
Qt's model system has a lot of object data stored as pointer to void.
I can almost hear you saying.
> but that's wrong you shoudn't do that in C++
And this is my answer to >>46832044
You don't do that in C.
Just to name a few:
>Structs with functions
That's just off the top of my head, someone here can post a full feature list from wikipedia or some shit.
Sorry that you couldn't understand no more than half of what I just listed, you'll learn once you actually write software that people actually use. Not jizzbuzz.
Just riced out structs
>Structs with functions
This is quite common in C, just somewhat of a hack.
Genuine advantage although any proper garbage collected language is still miles ahead.
Not hard to do in C either.
>goto = spaghetti code
Such a dated myth. goto's are best avoided for a code's structure, but that doesn't mean they should never be used.
Exiting from a series of nested loops given a condition is usually best done using gotos for example.
I know, I don't feel like defending it. I find it somewhat inane this threaded turned in to C++ vs C, C++ has all the undesirable points of C when compared to a modern language and then some. I don't get why people see C++ as a valid option for applications where you don't need all speed you can get but not C.
If you are going to commit a ton of time to a language like C++ I guess it makes sense you develop some tunnel vision.
We have had this 80s discussion far too often.
Structures and functions are plenty sufficient.
>>Structs with functions
>What is void *
Also come with an handful of disadvantages.
Probably useful when you aren't smart enough to deal with them yourself.
Is it really that difficult to write a free each time you write a malloc?
More bullshit on top of all the previous bullshit.
You're right about one thing: C can't do any of this useless stuff, and it's better this way.
At my uni they taught the basic programming concepts and data structures in C.
OOP concepts were demonstrated in Java.
As we moved on to more advanced topics and applications of algorithms it was usually recommended to do it in Java, C++ C# or Python.
Functional programming languages were extra classes.
>Gotos aren't damnable to begin with. If you aren't smart enough to distinguish what's bad about some gotos from all gotos, goto hell.
C stopped being nearly as useful as before since most cheap ass toasters have GB of ram instead of MB of ram. At this point you'll only use C as portable assembly, as in whenever you have to interact directly with hardware or whenever you have some strict hardware limitations (like 8MB of ram and less strict)
Classes aren't useless. Do you really enjoy polluting the global namespace with tons of inconsistently named functions?
pointers to void make C a dynamically typed language. Have fun with your shit performance. In fact, it will be a shitty dynamic language because all type information is lost.
What is the disadvantage of being strongly typed? I think babby doesn't know how to write templates.
Smart pointers and RAII are great. The point of programming is not writing and maintaining text and making sure you didn't mess up, it's creating programs. The more problems are dealt with at compile time, the better.
Have fun with your fizzbuzz.
>Careful now, that neckbeard won't be able to understand.
>Sorry that you couldn't understand
>HURR C PROGRAMMERS ARE NARROW-MINDED NECKBEARDS DON'T UNDERSTAND ABSTRACTION OR SOFTWARE ENGINEERING
Nice memes, friends. void-pointer polymorphism is actually an abstraction far closer to the machine, where rather than pretending your function is polymorphic with something like STL that generates a mangled function for everything you need to pass, the data is passed to a type-agnostic function that, if higher-order with a comparison function pointer as a parameter, or something similar, the type resolution is left to the comparison function you point to. What you have right there is literally machine-level polymorphism.
As for polymorphic containers, that's similarly easy to do. You can even implement an STL-style generic constructor in a macro that can pass a size parameter via an automatically-expanded sizeof passed to a "real" polymorphic function that operates on pure void pointers.
In C, it's painfully easy to implement your own abstractions from the ground up, intimately understand their workings, and reuse them (see glib and similar) just as easily as in any "object-oriented" language (And don't even get me started on how bullshit it is that languages like C++ or Java attempt to call themselves that. CLOS, Smalltalk, and perhaps ObjC are almost the only languages that are legitimately object-oriented. Perhaps there are legitimate C neckbeards in this thread, but believe it or not, even after exposing themselves to other languages, there are some people who keep coming back to C seeing its orthogonality and expressive power.)
Yes, the tool are there in C++ do lots of abstractions easily, and I'll let Stroustrup be the bible salesman for all that ease of use, but there are real reasons that people build high-level structures in C in the open-source world and in enterprise, and they have little to do with compatibility, I assure you.
Nobody returns to C after understanding C++. C is a subset of C++, the shittiest subset of C++ there is. It's much less expressive.
Great work suggesting pointers to void when the task was to create a container without them to show that C is type safe.
I actually need to familarize myself with C again to read the source for some firmware.
Which C standard should I read and where can I find it? I don't believe any of the function definitions are 'old style'.
>Then you either didn't understand it properly or you found a C job that paid better.
I simply prefer C over C++ for systems programming.
C++ occupies a terrible master-of-none spot, not high level enough to be nice and convenient, too bloated for constrained environments.
In a sense Windows since it is the only successful general purpose operating system that avoided the temptation of a Unix clone that added nothing to the field. It's sad there is so little development in operating systems. Unix and more specifically Linux fits the bill of a cancer quite closely.
Another C programmer here who knows C++,
Not really. The world is very simple. If you want to go fast you take C and mix in platform specific code when you need to. If you are writing a general purpose program you write it in an actual high level language such as Java/C#/Go.
C++ is targeting a market barely anybody sits in. Seriously, why would somebody writing a general application want a non garbage collected language in this day and age?
I'm not sure why C++ people are even in this thread.
This thread is a testament to how /g/ knows literally, metaphorically and figuratively nothing about C or C++ or scripting in general. All the retards in here tooting about how C is \better\ because 1337 or whatever. I've been on 4chan.com 27 years this April, and /g/ for 22 of those and I have NEVER seen this level -or perhaps, sub-level - of retardery in all my years. Oh look! I'll post a deprecated Linus quote from when he was in Narnia, what next? The made-up Strauss Soup or whatever his Scandanavian fucking name is quote? Huh? You people make me vomit in terror.
Even though C++ makes it easier for mediocre programmers to write really bloated software, the real reason C users hate it so much is that they're secretly ultra-jelly.
Learning all the C secret design patterns that are necessary to write somewhat secure and complex programs feels horrible when C++ idiomizes them into standard language/library features.
99+% of the time, something equivalent to RAII plus smart pointers is the correct was to write large performant systems, which is trivial in C++11/14 now but still takes a fair amount of conscious effort in C.
C++ haters are probably right about exceptions not being a very good system though, but they're easily avoided. Multiple or optional return types can be better approximated with Alexandrescu's Expected<T>, but that's still fairly hacky.
All in all though, C++ does a pretty good job of not making you pay for what you don't use, so people shouldn't bitch about intrinsic bloat. If you don't like something like the multiple indirection of vtables, you can always go back to replicated fptr values, etc.
>general purpose operating system that avoided the temptation of a Unix clone that added nothing to the field.
By making a shittier clone of PC/M that added nothing to the field
No it's not a meme.
The whole mentality of C is that the programmer is smart and knows what he's doing – the language just gets out of your way and lets you do anything you want. This is great for someone that actually knows what they're doing or a nightmare for someone who doesn't.
C is all about speed.
>Seriously, why would somebody writing a general application want a non garbage collected language in this day and age?
Because GC stutter is unacceptable on anything on the client side, it tends to nearly double memory use, and it really ruins a lot of spatial and temporal locality.
Besides OS kernels, there are not many C projects that come close to the complexity of large systems written in C++/C#/Java, but only one of those languages can readily make deterministic and performant binaries.
C++ is basically C with standard idioms. There is literally nothing you can write in C that can't be done with at least equal safety and efficiency in C++, you just need to know the costs of the readily available extra abstractions if you want to use them. Also, RAII is King, and you can at best only make ad hoc approximations of it in C.
How about C with no array decay?
Or C with hygenic macros?
Or C with a fixed compilation model?
There are lots of fundamentally shitty or outright broken things in C that have nothing to do with muh bare metal.
mandatory independent compilation and linking is cancerous, and every new language goes to great lengths to avoid the hacks that C almost necessitates like precompiled headers etc.
I suppose you think writing makefiles or meta-make configuration files is therapeutic or something.
Newer, high-level languages try to gloss over the technical reasons that the preprocessor, the compiler, the assembler, and the linker are totally separate programs. In the process of trying to cover it up they break all the things that make C strong.
>Newer, high-level languages try to gloss over the technical reasons that the preprocessor, the compiler, the assembler, and the linker are totally separate programs
yeah, like phased building was necessary because a PDP-11 with 1/4 MB of RAM was the initial platform, and peoples' time was a lot less valuable than the computer's, so only incrementally redoing the smallest possible piece made sense.
claiming the model has any real benefit now is a joke though, especially the preprocessor grammar and the fact that it's essentially impossible to do optimistic pre-parsing of files because of it.
Why C, a bug-prone, extremely fragile and filled with undefined/unspecified behavior is still used to write OSes,Drivers and programs?
This question is always asked, people using other languages complain that C shouldn't be used at all,yet it continued to be used.
People choose C not because its fast or actually "the fastest"(assembler is):its the "Freedom to tinker"
C can be optimized/hacked to arbitrary limit, without the low-level assembler code(using intrinsics,bit hacks,pointer arithmetic and various "speed hacks" which other languages don't allow). C doesn't have to be the fastest, but it allow you to tinker with algorithms on more fundamental level. There are no guards or restrictions, everything is coded in,patched in without breaking syntax or type model. C code is extremely malleable.
Writing a lot of code that works is hard, but that code is direct mapping of concepts to what they compile to in higher-level languages, which won't allow you to tinker with the "terse and powerful" code inside, because this would be anathema to using the languages, instead such high-level languages have a convoluted "unsafe escape mechanism" which allows you to drop to level of C and occasionally assembler/raw memory editing but using it nullifies any advantages of the language because its purpose was to prevent the "unsafeness",so most safe languages restrict and limit "escapes" from the language prison, requiring effort comparable to interpreting C(a nice rebuttal to "half-implemented ,buggy common lisp" meme) if the programmer wants to tinker&optimize but be "safe".
C is easy to learn, hard to master. It means languages need to have a smooth learning curve, and not annoy beginners with every little thing.
C doesn't hide detail of its implementation, its simple abstraction over underlying assembler or system libraries. The abstraction builds gradually and isn't presented as basic,(i.e. integers are actually hardware integers and not 31-bit objects with a flag bit). Interfaces to C are also extremely simple and standardized.
C abstraction maps to real-world expressions, not making a joke out of programmer by forcing him to alter syntax trees like (func(d) a(funb(func)))).
C preprocessor doesn't have much features but it can create abstraction levels comparable to higher-level languages without thew abstraction cost.
C features are not built-in, they are separated into libraries; that means the language doesn't force a specific model but allows multiple choices.
Example:threads inside the languages, this makes writing parallel code easy but doesn't allow you to use external, more efficient or manually optimized code which interfaces to your program natively. If there is mandatory feature X in some language, it can be assured that programmer trying to customize X for their needs will spend much in vain trying to override the limits imposed by the language, as if the languages has the idea that "there is only ONE WAY to do it and that means you need to use X like everyone else or leave"
High-levels of abstraction which are common in academia translate poorly to real-world applications and don't have much benefit beyond being terse. C is used because there is no hidden cost to write something, no background garbage collection, dynamic dispatch processing and invisible counters and checks that alter the program flow(typically lowering performance without a real benefit, which would be "writing bad code and dynamically executing it with hope the runtime system fixes everything").