|
Programming C, bash, Python, Perl, PHP, Java, you name it. |
|
Thread Tools | Display Modes |
|
|||
What is the way old Unix users learn C?
It's been a very long time since I've been back here.
I really love BSD and decide to play with it more. I have learnt Go after a long time struggle in C and now I am going back to end my learning C journey. But I always fail to understand it, it kind like a beast. How can you guys learn C from the beginning? How can you improve it? Are there some good sources you want to recommend to me? Also, I still wonder about the C standard which one should I learn first? And I meet some people who still prefer old C standard rather new standard. What wrong with new C standard? I have made a mess in my C journey from the beginning I guess. Now I am trying to solve it. |
|
|||
Books:
K&R C, 2nd edition (updated for ANSI C!) If you're specifically interested in Unix and C: APUE, 3rd edition. I suppose they're not "easy," but they routinely come up time and again as quintessential books for Unix and C. But... when working through the books, give yourself permission to write your answers in what I'll call "C99+" (which I'll explain a little later). How: Same way you learned Go, I think. @IdOp's suggestions are good ones. I'll add one more: do you have any Go programs you wrote yourself? Try porting them to C. You can trace your own thinking and see how you solve similar problems in the two languages. It does no harm to "write C in terms of Go" when first starting out. As your C improves, it will tend towards more idiomatic C and less like someone who knows Go and is mapping their Go knowledge onto C. But until then, nothing wrong with that. C standard: If you are using a modern clang or gcc, then it will default to the C17 standard (more precisely: it defaults to the GNU17 standard, but for now just starting out that's a difference that won't make a difference). You can see what version of the standard GCC is using by compiling with the -v flag. See this, for example with a simple hello world program compiled with gcc-12.0.0 on OpenBSD/amd64: Code:
/home/brian/c $ gcc -v hello.c ... GNU C17 (GCC) version 12.0.0 20210520 (experimental) (x86_64-unknown-openbsd6.9) ... Code:
/home/brian/c $ gcc -std=c99 -v hello.c ... GNU C99 (GCC) version 12.0.0 20210520 (experimental) (x86_64-unknown-openbsd6.9) ... I would learn what I call "C99+," which is C17 but without you feeling like you need to use C11 and C17 features. Stick with a baseline of C99 and add C11 and C17 features as you want to and as make sense for your programs. Fortunately, C is a slow-moving language and cares a lot about backwards compatibility. With some important exceptions, notably gets() and variable-length arrays, you can be confident that your C99 code will compile without issue in C11 and C17, and the future C2x standard. I would say don't worry so much about "which standard does this adhere to" and more "how do I solve problems with C." If you ever get paid to code to a specific, older, C standard, knowing how to solve problems with C will make adhering to the letter of the law easy. What is wrong with newer C standards: Nothing. Some people are just curmudgeonly. I suppose to give those people the benefit of the doubt, they may be working with codebases on platforms that require the use of older standards, but that's not the same as there being something "wrong" with C11 or C17. Again, learn "C99+" and you'll be fine here: you'll be able to converse just fine with the curmudgeons and you'll enjoy the enhancements of the newer C standards. Last edited by ibara; 30th May 2021 at 10:40 PM. |
|
|||
Thanks guys. You guys have a great answers.
Also, will you use C over everything? I don't know how to say that, but will it better if I only keep my C knowledge in write kernel, drivers and low lelvel stuff instead of writing software? C is a beast some people tell me that language is a real beast if I don't want to have more troubles I shouldn't use it much. They said to me "Memory management is a thing you should worry" Last edited by HopingStar; 31st May 2021 at 03:10 PM. |
|
|||
You should use the right tool for the job. It is clear that over the 50+ year lifespan of C, it has been used for just about everything. Modern C certainly can be used to solve an extremely wide array of problems. It should be just one tool in your ever-growing toolbox.
Notably, none of the BSDs use C for everything: OpenBSD uses Perl for its package manager, FreeBSD famously used Forth for its bootloader, and NetBSD has Lua support in-kernel for rapid prototyping (though this last one is still listed as experimental). Quote:
Quote:
As @Prevet mentioned, C can be difficult to learn due to the fact that you are really learning two languages: C preprocessor and C. Not to mention the myriads of build systems (stick to good old make when starting out). This macro processing in C in the form of the C preprocessor needs to be taken in historical context: such macro preprocessing would not have been seen as so unusual back in those days, as it grew out of assembler macro preprocessors. With that said, when first starting out, with the exception of #include directives and potentially some simple #define directives to make your life easier, you can minimize your use of the C preprocessor and therefore focus on just learning C. Your early C code is highly likely to be exemplary of C's original "portable assembler" ethos anyway, which can also help limit your C preprocessor use. |
|
||||
As a general comment on "how to learn a language", the best way is usually to *use it*.
You can read all the books about carpentry or guitar playing you want, but this does not make you a good carpenter or guitarist. Indeed, some of the best carpenters and guitarists have never read a book on the topic at all and just acquired their skill through practice. That being said, of course it does help if you have a good book which teaches some fundamentals. The K&R book was mentioned; it's a classic, although there maybe are better books out there. Just start reading the book and: - Do the exercises in the book! No really, do them! - Muck about with the exercises. "Gee, I wonder what happens if [..]" or "maybe it would be nice if this example program could also do [..]". - There are also additional exercises available at e.g. https://exercism.io/tracks/c I don't usually enjoy "programming for the sake of programming" myself (some people do), but when starting out these things can be quite useful. Like it said: it's all about actually *doing it* to practice. - Think of a real-world actual program you want to write as soon as possible, perhaps even before you start any of this. And try to *write* this program as soon as possible. You don't need to finish the book first, just as soon as you think you might have a vague idea how to do it, start mucking about while also continuing to read the book. This is often the hardest part; not the writing of the program, but thinking of something useful to write! Everyone is different of course; and some other ways work better for some other people. But I found this works quite well for me personally. All of that being said: if you don't really have anything useful to write in C, then it's probably a lot harder than if you do. Personally I'd say that learning C just "for the sake of knowing C" is kinda useless, and not very motivating. |
|
|||
Could not have said it better..............................
|
|
||||
There's another thing I forgot: takes notes!
When you're working through the book just keep a ~/c.markdown file (or whatever works for you) where you explain the core concepts in your own words. Actually, I wrote Learning a programming language on my website a few years ago which mirrors most of what I said in my earlier post, which also contains a small example from back when I was learning Go. These notes aren't really intended to be referenced later *as such* (although they can be), it's just that the act of writing down stuff in your own words (don't copy/paste it) helps your brain store the knowledge better. I discovered this far too late in life; they told me this at school, but I had an easy time there and never needed it, and was a stubborn little bastard too, so I didn't believe them. But they were right! Writing down notes is a useful thing to understand stuff in general; when I'm working on some code I don't fully understand (e.g. projects I never worked on before, like an open source project I want to submit that one patch to) I will often write down extensive (temporary) comments where I try to construct how it all works. |
|
|||
Those are great tips! Thanks. By somehow I have understood some parts of C programming which I have never understood it before and it is quite clear to me. All of your advice help me to fill the gaps in my knowledge. I bet my C programming knowledge will be better and clearer in someday. Right now, I am learning hard to pass my national high school exam, I shouldn't go to Internet and try to learn C. But I will try my best to pass it to prove that I have improved myself day to day.
I will tell you guys after I have passed national high school exam and done my C programming course. Wait for me. |
|
|||
I think I have known C better than before. I know the basic enough so that I could read source code and understand it. I have started ported my first project and it is worked pretty great. I still have a lot of problems through but I will fix my project later.
I guess everything need time so that I can understand how thing work. Everyone can learn C maybe in 1 day or maybe 1 weeks but I guess they have to practice it all the rest of their life. Programming is just like other normal activities if you practice it more you will be better. Not sure how long I can master it. But I am happy that I have escaped of my learning loop and start a new journey for me. Thanks guy. |
|
|||
I am by no means an expert in C or UNIX, but absolutely love them both enough to share my personal take on the matter.
I learned C from the book The C Programming Language (2nd Edition), universally referred to as K&R. I read 1 hour each day and knocked it out in 7 days. At that point in time, though, I was already writing software in a handful of different languages, C++ being my language of choice at the time. Ever since K&R, nothing has ever beaten C for me and I'm not convinced anything ever will. Personally, I don't think there is anyone better to learn it from than the man himself who invented it. Keep it simple and keep your environment simple. Brush up on what it means to compile a program, then begin your journey with K&R. By writing it. Write a ton of small programs. Change little bits about them and see what they do, get curious. Got an idea for a program? Fire up your text editor and write it, even if the program itself never gets finished. Act on every single bit of curiosity that spawns in your mind the moment it does. Look for the answer to every question you have the moment you have it. Little by little, grow your experience and remember to enjoy every second of it. With every night of sleep you get after having grown your experience by a little that day, you improve just as much. Quote:
A rather small percentage of C is learning its grammar, the syntax rules. It must be recognized by the compiler to compile without error. The core of C merely consists of understanding what it means to program a computer. Everything beyond that is using what the kernel has to offer, unless you're writing firmware for your own embedded devices, in which case you interface with the integrated circuits themselves. Memory management is not a byproduct of C itself but of the nature of computer architecture. Processes only have so much stack memory allocated for them before being fired off by the process scheduler. At run-time every process must personally ask the kernel for more memory, if needed, and when done so are returned the memory address which points to the start of that block of dynamically allocated memory. This is the effect of a call to malloc(). For every call to malloc() there should be a call to free(). It is that simple, however it is your responsibility as the programmer writing these instructions to clean up after yourself. You don't leave the car door open after getting out, or not flush after using the toilet. Why should this be any different? If you, the programmer, are not freeing the memory you allocated, what do you think is if, for example, you are using a garbage collected language? Many more instructions embedded in those languages' run-times are doing it for you and at a rather expensive cost. A cost that I'm not convinced is worth paying. As for a standard, I would suggest adhering to POSIX and C99. Nearly every real-world C compiler should support C99, it would be rather silly if it didn't. Target the lowest common denominator, but do it well, and your program will compile and run on hundreds of systems. I can't necessarily answer that but can only refer you to what I just previously mentioned. It takes time for compilers to implement support for modern standards. I personally have no complaints about C99 and can't imagine what more I would need out of it. Though I also don't write any complex software or make use of any fancy tricks or paradigms so perhaps I am not particularly well-suited for a discussion on old vs. modern C standards. Last edited by hackexe; 22nd November 2023 at 06:07 AM. |
|
|||
TY nice post
|
|
||||
When I was at University (2004-2008) I had a dedicated classes to learn C - but the guy that was supposed to learn us C - required C knowledge from use on the day one.
He literally did not teached us anything - the first lesson was - "Write me a program that will count characters in a file." - and I was not able to do that. The next lesson was even worse - he demanded something more advanced - and I still did not knew C. So after looking for some solutions I reached for ANSI C from Kernighan and Ritchie - and that is the book I learned C the most. I really recommend this book as first 'C' book - but I am not a real practitioner - I am sysadmin - I write POSIX sh(1) scripts and configure things - not to mention that today with standards like C99 or C03 a lot of things could have changed ... My $0.02 on the topic.
__________________
religions, worst damnation of mankind "If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus Torvalds Linux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”. vermaden's: links resources deviantart spreadbsd |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Learn OpenBSD ports! | ibara | OpenBSD Packages and Ports | 6 | 8th August 2014 02:32 PM |
learn assembly | ephemera | Book reviews | 5 | 26th December 2012 06:29 PM |
How to learn to program under BSD? | Sunnz | Programming | 5 | 24th December 2008 11:45 PM |
Would BSD be right to learn networking? | php111 | Off-Topic | 17 | 25th September 2008 07:02 PM |
How did you learn to program? | TerryP | Off-Topic | 25 | 6th September 2008 04:00 PM |