Commit c9df9b7f authored by Alexander Hirsch's avatar Alexander Hirsch
Browse files

Minor changes

parent 64b54f22
......@@ -18,7 +18,7 @@
- Statically typed
- Compiled
- Low-level
- No inheritance, no generics, …
- No garbage collection, no inheritance, no generics, …
# Language
......@@ -31,13 +31,12 @@ int i2;
long i3;
unsigned char i4;
// …
float f0;
double f1;
int arr1[10];
int arr2[2][3][4];
int array1D[10];
int array3D[2][3][4];
int *ptr;
void (*fun_ptr)(int);
......@@ -118,11 +117,11 @@ struct expression {
struct literal *literal;
// EXPRESSION_TYPE_BINARY_OP
struct binop {
struct {
enum binary_op op;
struct expression *lhs;
struct expression *rhs;
};
} binop;
};
};
```
......@@ -229,9 +228,9 @@ default:
- Your bread 'n' butter in C
- Should be short and sweet, and do only **one** thing
- The signature should tell the function's purpose
- The signature should fully describe the function
- Functions need to be declared before they can be used
- Definition also declares a function
- Functions are also declared on definition
---
......@@ -252,7 +251,8 @@ double xfb(int a, int b, double pre); // 🤔
- Functions should touch as little global state as possible
- Ideally functions should be *pure*
- Always use `const` if pointers are used for input
- Pointers are also commonly used for output parameters (no `const`)
- Pointers are commonly used for output parameters (no `const`)
- Alternative: return a struct
## Pointers
......@@ -285,13 +285,14 @@ double xfb(int a, int b, double pre); // 🤔
- Underlying building block for arrays
- Enable the use of output parameters
- Enable efficient implementation of algorithms and data structures
- Pointer to children vs. adjacency list
- `NULL` often used to indicate absence or error
## Arrays
- Multiple values of the same type consecutive in memory
- Multiple values of the same type, consecutive in memory
- Need to keep track of the size
- No bounds checking
- No automatic bounds checking
- Commonly used for buffers and strings
---
......@@ -328,9 +329,9 @@ void fun(int arr[10])
- String literals (e.g. `"foo"`) are immutable
- Typically handled as `const char *`
- Strings are NULL-terminated!
- Be careful when using string related functions!
- Be careful when using string related functions!
- Consider using `asprintf` for any kind of string interpolation
- Alternative use `snprintf`
- Alternatively use `snprintf`
- Always prefer bounds checking functions (e.g. `strncpy`) over their naïve variants (e.g. `strcpy`)
## Assertions
......@@ -406,13 +407,13 @@ return OOPS;
## Multiple Source Files
- Header-files define types and declare functions
- Contain most of the documentation
- Serve as interfaces
- Source-files contain the implementation
- Prefix internal functions with `static`
- Mark internal functions as `static`
- Prevents symbol conflicts between translation units
- Communicates that the function is an implementation detail
More about this later…
## Miscellaneous
- Bitfields
......@@ -501,7 +502,7 @@ More about this later in C++…
## Overview
- Essential part of the C language
- Essential tool when using C
- Can be used to build obscure mechanisms (black magic)
- Techniques for minimising code duplication
......
......@@ -152,9 +152,6 @@ Checkout
Staging
~ Files / changes that are to be committed.
`HEAD`
~ Reference to the last commit in the currently check-out branch.
## Branches
![Src: Bitbucket Documentation](images/git_branch.svg)
......@@ -254,10 +251,10 @@ Fetch / Pull
$ cd /tmp/foo
$ git log --graph --oneline
* c754a65 (HEAD -> master) Our third commit
* 4a3252c Another commit
* 90d9457 First commit
$ git log --oneline
c754a65 (HEAD -> master) Our third commit
4a3252c Another commit
90d9457 First commit
# Rebase
......@@ -303,7 +300,7 @@ Fetch / Pull
---
- Use dedicated branches for implementing new features
- Locally rebase feature branch until ready for final merge
- Rebase feature branch until ready for final merge
## Release Branches
......
......@@ -97,8 +97,8 @@ Don't — it's a mess!
- Statically typed, but fast compile times
- Useful standard library, good ecosystem
- Good performance
- No decent package manager (yet)
- Easier to parallelise
- No decent package manager (yet)
---
......@@ -320,7 +320,7 @@ Compare this to your average Windows / Mac install experience:
- Learn the basics of Bash scripting
- Critically think about its limitations
- criteria to deciding between Shell / scripting language
- Criteria to deciding when to use Shell / scripting language
## Using a Package Manager
......
......@@ -59,7 +59,7 @@
- Needs to communicate the big picture
- Consider it a guide for implementing
## Manging Time
## Managing Time
- Split the implementation work into small, manageable tasks
- Critically think about relation ships between tasks
......@@ -219,11 +219,11 @@ int main(void)
int secret = rand() % 100;
while (true) {
int guess1 = get_guess();
int guess2 = get_guess();
int guess3 = get_guess();
int guess1 = get_guess();
int guess2 = get_guess();
int guess3 = get_guess();
// …
// …
}
}
```
......@@ -291,13 +291,13 @@ Bad
void foo(void)
{
if (!first())
return;
return;
if (!second())
return;
return;
if (!third())
return;
return;
// …
}
......@@ -408,7 +408,7 @@ Consider test driven development (TDD).
- Use a testing framework
- Integrate it into the build system
- Make it easy to write and run tests!
- See Go for instance
- See Go or Rust for instance
---
......@@ -426,7 +426,7 @@ scripts/run_integration_tests
## Continuous Integration
- Let services (Jenkins, GitLab CI) build and test your code
- Let services (Jenkins, GitLab CI, …) build and test your code
- Reject merge-requests which break tests
- View this as a form of quality assurance
......@@ -456,6 +456,7 @@ scripts/run_integration_tests
- Not that important right now
- Always measure!
- What to measure, what to optimise?
- Are the values you measure meaningful?!
- Related multiple measurements over time
- Can be applied to multiple layers
......@@ -516,14 +517,14 @@ scripts/run_integration_tests
- Solve the issue
- Test should now be successful
- Did I break anything?
- Commit your fix
- Commit your fix (+ test)
# Collaborating
## Working in Teams
- Select a *project officer*
- A developer not a manager
- A developer, not a manager
- Someone with authority
- Maintains the big picture
- Can make decisions
......@@ -537,7 +538,7 @@ Imagine an orchestra without its conductor.
- Be respectful of other people's code
- Ensure your code is working fine and is well tested
- Ensure your code is well documented
- Put assertions in place (defensive programming)
- Add assertions (defensive programming)
---
......
......@@ -79,7 +79,7 @@
# Build System
## Advanced (Build System Generators)
## Advanced Build System (Generators)
- CMake (covered later)
- Autotools
......@@ -165,7 +165,9 @@ rm -f example example.o other.o
---
```
```make
# …
%.html: %.md
$(PAN) $(PANFLAGS) $(PANFLAGS_DOC) -o $@ $^
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment