What are the important notions in C that you did not learn from your teachers? [closed]

Answer 1

An important notion in C that I did not learn from my teachers is:

Operator * does not mean "pointer to" (on the left-hand side). It is instead the dereference operator - exactly as it is on the right-hand side (yes, I know it is disturbing to some).

Thus:

int *pInt

means that when pInt is dereferenced you get an int. Thus pInt is a pointer to int. Or put differently: *pInt is an int - dereferenced pInt is an int; pInt must then be a pointer to int (otherwise we would not get an int when it is dereferenced).

This means it is not necessary to learn more complicated declarations by heart:

const char *pChar

*pChar is of type const char. Thus pChar is a pointer to const char.

---

char *const pChar

*const pChar is of type char. Thus const pChar is a pointer to char (pChar itself is constant).

---

const char *const pChar

*const pChar is of type const char. Thus const pChar is a pointer to const char (pChar itself is constant).

Answer 2

• Non-procedural programming techniques including OOP patterns in C.
• Advanced C preprocessor techniques
• Debugging with something other than printf().
• Complier and linker features, including building shared/dynamic objects.
• Unit testing and mock objects, TDD in general.

Answer 3

Go over the whole programming life cycle, including what happens to your code after you're done with it.

• Pre-planning stages, and a bit on how to look for an existing project/existing code you can use to reduce the amount of original code
• A small (Basic) overview of licenses and how that external code affects what licenses you can and can't use (and other considerations that go into licensing)
• Concurrent version control, and versioning. I'd do SVN/Git, but to each his own. You will save them SO MUCH time if you introduce it to them now rather than learning on the job.
• Show them what avenues there are for open-sourcing code (Google Code, Github, etc.) and when/how to tell if it's appropriate or not.

None of this is C-specific, but I add it because I personally just went through the 'C for Electrical Engineers' at my university, and this is all stuff I had to find out on my own.

Answer 4

• Where the language ends and the implementation begins: e.g., stdio.h is part of the standard library, conio.h is not, stuff like that;
• The difference between undefined and implementation-defined behavior, and why things like x=x++ are undefined;
• Just because it compiles doesn't mean it's right;
• The difference between precedence and order of evaluation, and why a * b + c doesn't guarantee that a will be evaluated before b or c;
• "It works on my machine" does not trump behavior specified by the language standard: e.g., just because void main() or x = x++ is giving you the results you expect for a specific platform and compiler doesn't mean it's okay to use;
• Pretend you never heard of gets();

Answer 5

There are too many to name them all. Some of them are C specific; some of them are general best-practices kinds of things.

• Learn to use the tools available
  • Revision control system. Every time it works, check it in.
  • Diff tools: diff, rdiff, meld, kdiff3, etc. Especially in conjunction with the RCS.
  • Compiler options. -Wextra -Wall __attribute__((aligned(8))), how to pack structs.
  • make: Produce debug and production versions
  • debugger: How to get and interpret a stack trace. How to set breakpoints. How to step through/over code.
  • Editor: Compile within the editor. Open multiple windows, M-x tags-query-replace (are my emacs roots showing?) etc.
  • cscope, kscope, [ce]tags, or other source browsing tools
• Program defensively. assert(foo != NULL) in -DDEBUG; scrub user inputs.
• Halt and Catch Fire when an error is detected. Debugging is easier when you core dump 2 lines after you detect the problem.
• Maintain a 0-warning compile with -Wextra and -Wall enabled.
• Don't put everything into 1 huge honking .c file.
• Test. Test. And test some more. And check those tests in alongside your source. Because the instructor might come back and change the requirements after it's been turned in once.

Answer 6

This keyword in C: volatile ََََ