[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology

Name
Options
Comment
Verification
4chan Pass users can bypass this verification. [Learn More] [Login]
File
  • Please read the Rules and FAQ before posting.
  • You may highlight syntax and preserve whitespace by using [code] tags.

08/21/20New boards added: /vrpg/, /vmg/, /vst/ and /vm/
05/04/17New trial board added: /bant/ - International/Random
10/04/16New board for 4chan Pass users: /vip/ - Very Important Posts
[Hide] [Show All]


[Advertise on 4chan]


File: 1764381306653416.jpg (82 KB, 546x896)
82 KB
82 KB JPG
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
>>
>>107702118

Yes, 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.
>>
>>107702144

Also other issues include arrays with no bounds checking and lack of automatically cleaning up garbage when initialising variables.
>>
>>107702118
Of course you should anon! C is a chad language. Knowing C would really set you apart from all of the Rust Trannies
>>
>>107702118
yes 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 works
null 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')
>>
>>107702118
It'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.
>>
>>107702118
That 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
>>107702160
How 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.
exactly
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 you
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.
>>
>>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 on
Can all be done in C, noob.
>>
>>107702118
C 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.

>>107702209
Rust 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 you
If 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.

>>107702831
I know, sensible projects roll their own string type with a length field: https://github.com/git/git/blob/master/strbuf.h
Point 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 pointers
Those literally are layers within the language.
>>
>>107702960
Are 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.
>>
File: 1760551783160265.png (6 KB, 1920x1080)
6 KB
6 KB PNG
>>107702890
KEK I'm retarded. Maybe I should learn C just to know these things
>>
>>107702118
>Should I keep going
>>
>>107703052
Null terminated strings and "null pointers" are artifacts of libc.
>>
>>107702118
Try making a project in C and form your own opinion but that opinion better be:
> this language is shit
>>
>>107703405
To 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 CS
honestly, 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.



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.