Is C still wortlh learning nowadays?I'm studying CS but my uni's program only teaches you Python, Java and C++ so i figured I'd try to start learning C on my own over the winter break.I already have a decent grasp on Python and Java and have always heard all the real enlightened big brain neProidians learn C to understand how a computer works beter since it's "close to the metal" unlike Python and Java but even starting out with Learn C the Hard Way, Zed Shaw says that C is a fundamentally flawed language and has many errors that later languages fixed into non-issues.Should I keep going
>>107702118Yes, you should learn C because it’s very close to how a computer works.The mistakes C made are well known: null pointers and null terminated strings, but its good to get you familiar with it.
>>107702144Also other issues include arrays with no bounds checking and lack of automatically cleaning up garbage when initialising variables.
>>107702118Of course you should anon! C is a chad language. Knowing C would really set you apart from all of the Rust Trannies
>>107702118yes it's a good language that really teaches you what programming is really about.the language has like 15 important keywords and lets you build anything using these.the rest is just about combining the other language features: arrays, structs, primitives and functions.it's the scheme of imperative programming.
>>107702144>Yes, you should learn C because it’s very close to how a computer works.>Nevermind the mistake that it made that boils down to actually modelling how a computer worksnull pointers are a fundamental attribute to memory systems addressed by a numerical pointer indexed at zero. hiding this cannot simulatenously be something good and a mistake. same goes for zero-terminated strings - except it's not a hardware fundamental (though specific instructions for zero-terminated strings exist in most ISAs) but simply the least idiotic solution. what else u gon do? pascal strings?and all of your points apply to C++ anyway as well. last I checked, std::string is zero-terminated (C++11 onwards guarantees [std::string] s[s.size()] == '\0')
>>107702118It's often overstated how close it is to how the hardware works. And nowadays there are better languages for most tasks.But it's worth knowing. It's relatively easy to learn how to understand C code (much harder to learn how to write really good C code), and there's a ton of important software written in it that you might want to read the source code of. It's also ingrained in many aspects of how operating systems and other languages work.Do learn C but don't listen to people who say that it's the only masculine way to program a computer or whatever.>>107702473>null pointers are a fundamental attribute to memory systems addressed by a numerical pointer indexed at zero.It's nice to express nullability in the type system, though this would fit poorly with the rest of C.>what else u gon do? pascal strings?The vast majority of languages today use either a pointer + length pair or a start and end pointer. (Notice that pointer + length is how the mem* functions work, C just doesn't make it the default or package it up into a convenient type.)C inherited null-termination from B and B didn't support structs, that might have something to do with it. IIRC Ritchie didn't consider a length-prefix unreasonable (it's what BCPL did), he said that null-termination just seemed easier.>and all of your points apply to C++ anyway as well. last I checked, std::string is zero-terminated (C++11 onwards guarantees [std::string] s[s.size()] == '\0')C++ adds a null byte so that you can pass std::string pointers to functions that expect C strings. This costs it one byte of storage and nothing else because all C++-native operations still make use of the length field or the end pointer or however the STL implements it.That means C++ can store null bytes inline, it can do bounds checking, it can find the end of the string in O(1), it can do zero-copy no-write substrings, it doesn't risk overflow by skipped terminator, it can do aggressive SIMD, and so on.
>>107702118That really only applies if you're going to get into direct memory management, multi-threading, etc... the exact specifics of how those things are done.Definitely good to play around with to get a grasp and experience with the concepts.You can invoke direct assembler as well, which you should test out to connect with how that works.
>>107702144>>107702160How TF can you have a close to metal implementation with that bloat?Implement it as a layer within the language, noob.
>>107702647>C++ adds a null byte so that you can pass std::string pointers to functions that expect C strings. exactlywhatever else it's doing, doesnt change the fact its zero-terminated.so what are you arguing exactly? if C's string zero-termination is an issue for you, C++ wont save youand storing two additional pointers, plus the zero-terminator, is not always desireable either. in embedded or kernel space, the overhead of re-scanning for the null-terminator a few times often outweighs the cost of storing two additional pointers.
>>107702647>C++ can store null bytes inline, it can do bounds checking, it can find the end of the string in O(1), it can do zero-copy no-write substrings, it doesn't risk overflow by skipped terminator, it can do aggressive SIMD, and so onCan all be done in C, noob.
>>107702118C is a good first step if you want to get into systems programming. Whenever you want to use C++, Rust or whatever, it's best to start with C.>>107702209Rust is pretty much a superset of C. It is commonly recommend to start with C before Rust.They all know C already.
>>107702803>whatever else it's doing, doesnt change the fact its zero-terminated.>so what are you arguing exactly? if C's string zero-termination is an issue for you, C++ wont save youIf you want to be really precise about it, the problem isn't that there's a null terminator but that you have to use the null terminator to be able to tell where the string ends.C++ and most modern languages can do all those things I listed. C's standard string representation can't do it.>and storing two additional pointers, plus the zero-terminator, is not always desireable either. in embedded or kernel space, the overhead of re-scanning for the null-terminator a few times often outweighs the cost of storing two additional pointers.One additional pointer, or the size. Not two additional pointers.Null-termination is better in some niche situations (though it's not the only wacky scheme you can use to save space). It may even have been a good default on the PDP-11. Definitely a bad default now though which is why you don't see anyone else use it any more.>>107702831I know, sensible projects roll their own string type with a length field: https://github.com/git/git/blob/master/strbuf.hPoint is you can't do it with the standard strings. If you have a string "foobar" and you want to extract the "foo" part you have to copy it out or replace the 'b' by a terminator or use a length instead of a terminator, those are your options.
>>107702796>null terminated strings>null pointersThose literally are layers within the language.
>>107702960Are they? How so.
>>107702118>neProidians learn C to understand how a computer works beter>>107702144>Yes, you should learn C because it’s very close to how a computer works.C has nothing to do with how a computer works. You should learn assembly. Maybe start with a 6502 or other simple processor to learn how computers work, then work your way up to more advanced computers.>>107702473>null pointers are a fundamental attribute to memory systems addressed by a numerical pointer indexed at zero.The computer doesn't treat the address at 0 specially. Most CPUs actually have RAM at address 0. The 6502 has a "zero page" which is a convenient way to access the first 256 bytes of RAM, so zero is just another memory location. On x86, there's nothing special about it either, and in traditional segmented mode, the 0000 address is just the first byte of the segment. Actually null pointers aren't always zero either.>same goes for zero-terminated strings - except it's not a hardware fundamental (though specific instructions for zero-terminated strings exist in most ISAs)It's the other way around. Most CPUs have instructions for strings that have a length, not for zero-terminated strings. x86 has the REP MOVS, STOS, CMPS, etc. string instructions that take the length in the (E/R)CX register. If you write x86 assembly, it's the easiest way to work with strings because you just set the registers and the hardware does everything. Null-terminated strings are a pain to work with and they're slower.>>107702796>How TF can you have a close to metal implementation with that bloat?Some CPUs have instructions specifically for array bounds checking. That's as close to the metal as you can get. On x86, it's BOUND, and on 68k, it's CHK and CHK2. Languages with arrays like Pascal and BASIC used those instructions. They were put there specifically for array bounds checking in high level languages.
>>107702890KEK I'm retarded. Maybe I should learn C just to know these things
>>107702118>Should I keep going
>>107703052Null terminated strings and "null pointers" are artifacts of libc.
>>107702118Try making a project in C and form your own opinion but that opinion better be: > this language is shit
>>107703405To be clear: Not only libc, but any runtime that uses any of these two conventions. Because that's what they are. A string is just a char array, and NULL is just the memory address 0x0.
>>107702118>I'm studying CShonestly, at this point in your career you should just focus on making yourself employable. You're never gonna get a job doing C right out of school, because C jobs require a ton of knowledge that only comes with experience. I would say stay focused on Python/Java (or whatever else you think might get you a job where you live), plus whatever other tech you consider relevant (cloud, data analysis, devops, CI/CD, Kubernetes, basic Linux knowledge). You have a lot to study, stay focused until you get that first job. Once you're working in a comfy job, then yeah, go ahead and study C, it can only help your understanding of software.
>>107702118>Is C still wortlh learning nowadays?no.Not since around 2010 or 2000.Learn C++.
>>107702144>The mistakes C made are well known:>rejecting tools to make you efficient developer, for no reason what so everfixed>Yes, you should learn C++ because it’s very close to how a computer works.fixed>C is a chad language. Konly as ++
>>107702118The only languages you need to learn are Python and Rust. Everything else is dogshit.
>>107702118I love c, but if you're learning c++, you're equally close to the metal if you want to be.
>>107703978>>Yes, you should learn C++ because it’s very close to how a computer works.Lol
>>107704047C++ is as close to how a computer works as C, which is not any more than any other high level programming language.
>>107702118C is a meme don't bother
>>107703980Gigabased.
>>107704133>I can't code low level languages correctly>Therefore C is bad!Retard.
>>107704254Ctrannies:>Unix is the first OS written in a high level language (not really, but that's what Ctrannies say)>C is a low level language