We are still actively working on the spam issue.
C Help and Discussion
C Help and Discussion - or /chad/, is an ongoing general. In it people discuss C/C++ programming, projects that they and others are working on. Show what your working on, and go mess around someones else's code.
I was reading a thread on Lain Chan and I thought /g/ might like it, they did.
Tools
Building and Build systems
Autotools
GNU Autotools is a build system that generates Makefiles which comply to GNU Coding Standards, which makes it easier for users of your software to adjust the build process for their needs. The ability to do out-of-tree builds, cross-compilation and staged installs comes out of the box, so you don't have to implement it yourself.
Video guide by David A. Wheeler
Makefile
"A Makefile a day keeps the doctor away." - me
Makefiles provide a very useful basis and if you fully grasp them, you can do most anything with enough investment. Though in most cases it's better to use Makefiles for small and simple projects.
CMake
CMake is a multi-platform build system that is a modern alternative to Autotools. It's generally considered to have bad syntax.
Meson
CMake with better syntax.
Debugging tools
Valgrind
Splint
gdb
lldb
Recommended Build Options
Warnings
For GCC, it is generally recommended to use `-Werror -Wall -Wextra -Wpedantic`; and for Clang it's recommended to use `-Werror -Weverything`.
Release options
`-O2 -DNDEBUG` Provides good optimizations, and `-Os` is generally discouraged due to some bad trade offs that may occur reducing optimization greatly.
Debug options
`-Og -g -fsanitize=address,undefined`, use `-ggdb` instead of `-g` if you intend to use GNU Debugger.
Tools like Valgrind, Splint will help you debug and improve your code.
Diagnostic options
Consider `-fno-diagnostics-show-caret` for GCC or `-fno-caret-diagnostics` for Clang to reduce the number of lines per actual error in the compiler output.
C Misconceptions
C is a small language!
C is often called a small language but this is simply not true. Its small RELATIVE to other languages. The set of information that is C is quite large on its own and takes a long time to master completely ("Master" could be defined as the ability to write a working standards-compliant compiler).
C has no package manager!
C has many, many package managers, one for every GNU/Linux Distribution.
C's lack of memory safety leads to buggy programs!
Good coding habits will prevent many such bugs. There are also tools like ASan and UBSan which help find memory bugs during testing.
Useful Links
Getting started
Challenge
Books
Standards
Notable Projects Summited
Advice
How to be an Above-Average Programmer starting from University
From >>92426366 In >>92422644, slightly edited:
If you are in University, I think it's a good idea to supplement the classes with your own extra learning in the niches you see yourself in in the future. There's also no harm in learning things earlier than planned in your syllabus (see also: https://sive.rs/kimo). If anything, it will make it easier to get good grades and also solidify the material in your mind by going over it twice. However, it shouldn't be taken to an extreme where you're spending every waking hour in front of the computer and neglect your health or social life. Balance is important too.
University teaches you a lot of things, but there is often not enough time to cover everything in as much detail as needed to actually get good at programming. For example, I learned enough C to write a simple game but didn't know about arena allocators, struct padding, aliasing and restrict, cache locality, CMake. They taught me how to write one-file Python scripts but not how to organize larger projects with modules, virtualenv, requirements.txt, etc.
Above all, it's worth the effort to practice "professional" development early. In a lot of universities you can get by writing many small programs (<1000 lines) so you never get practice with larger ones. Start some multi-month and multi-thousand-line-of-code projects - either personal or a university project that might use in multiple classes. Use all the standard practices: host it on GitHub/GitLab/Codeburg/etc - It can be private if you're shy. Write good commit messages; write a nice README.md; use Make/CMake/Meson and write down build instructions; use a readable coding style and refactor from time to time; write some tests with CMocka for the tricky algorithmic parts. After you get some practice, try contributing to open source projects! They often have a bunch of bugs in their issue tracker that aren't a priority but they'll still happily take fixes for.
Here's why I advise to do larger, more "professional" projects early and contribute to open source: I've found that working on non-trivial programs is like a muscle that you can train, and largely independent of the language. When I was a teenager, I used to think that a 600 line program is large and A* is a complex algorithm to implement. These notions seem laughable to me now, and the change happened after I wrote a couple of 3-10 thousand line personal projects and implemented some 500+ line algorithms at university.
It is valuable to be able to come up with an idea for a program, write 5000 lines of code at a steady pace, and end up with something similar to the higher-quality projects you can find on GitHub: a nice commit history, a README.md that clearly explains how to build and use the software, an issue tracker with all the bugs that haven't been fixed yet, and code that's easy for people to find their way around. It's also valuable to be able to jump into someone else's codebase, quickly orient yourself, and add good code that matches the conventions of the project. These skills will give you a leg up but you don't always get them from attending university.
Editor note: These ideas apply to even if you're not a University student, though you must define your own syllabus and you'll have to do the grading yourself. Start somewhere, and start writting code and try to follow anons advice.
