
When deploying this blog I wanted a quick way to monitor that specific versions of the blog had rolled to the public.
The eventual solution is outlined below.

### Versioning package.json

Using the [pre-commit](https://www.npmjs.com/package/pre-commit) package a hook can be setup that runs prior to any commit.
This looks like:

```json
"scripts": {
  "patch": "npm version --no-commit-hooks --no-git-tag-version patch && git add package*.json",
},
```

- `commit-hooks`: Disable any default node hooks which could interfere
- `git-tag-version`: Creates a version commit and tag - I wanted the version change to be part of the existing commit
- `git add package*.json`: Add the updated versioning files to the commit

### Going Meta

To then display this version as part of the `<meta>` required some small tweaks.

```js title="next.config.js"
const { version } = require('./package.json');

module.exports = {
  ...mdx,
  publicRuntimeConfig: {
    version,
  }
}
```

```tsx title="Layout.tsx"
import Head from 'next/head';
import getConfig from 'next/config'; 

const { publicRuntimeConfig } = getConfig();

const Layout = ({ children }) => {
  return (
    <Head>
      <meta name='version' content={publicRuntimeConfig?.version} />
    </Head>
  );
};
```

And voilà - the version now appears in the header:

```html
<head>
  <meta name="version" content="0.1.65">
</head>
```


The Best Version


Coming from Java the concept of ownership was alien - so to solidify this knowledge I'm going to attempt a brief summary 
in ~5 minutes.

### Ownership

Each variable in Rust has an owner. Once ownership is declared, there is exactly one binding to any given resource[*](#reference-counting).

Once ownership is moved, the previous owner no longer has access.

```rust
let x = vec![1];
let y = x;

println!("{}", x[0])

//: # (error[E0382]: borrow of moved value: `x`)
```

### Copies

Ownership rules do not apply to **primitive** types, or anything that implements the `Copy{:rust}` trait (which gives
a type **copy semantics** instead of **move semantics**).

```rust
let a = 5 as i32;
let _y = a as i64;

println!("{}", a);

//: Finished [] target(s) in 0.65s
```

### Functions

A function can also take ownership of a variable via its parameters.

```rust
fn new_owner(_x: Vec<i32>) {
  // my_vec is now owned by the new_owner function
}

let my_vec: Vec<i32> = vec![1]; // vector containing a single element, 1
new_owner(my_vec);

print!("{}", my_vec[0]);
// error[E0382]: borrow of moved value: `my_vec`
```

Whenever you see `f(value){:rust}` you can know that **f** has received ownership of **value**.

### Borrowing

Instead of taking ownership, a resource can be **borrowed**. Rather than passing by value, we can pass by reference.
The reference borrows ownership of the variable, until the period where it is released again, at
which point the prior owner can manipulate the data.

```rust
fn new_owner(_x: &Vec<i32>) {
  // my_vec is now borrowed by the new_owner function
  print!("{}", _x[0]);
}

let my_vec: Vec<i32> = vec![1]; // vector containing a single element, 1
new_owner(&my_vec);

print!("{}", my_vec[0]);
// Compiles and prints: 11
```

The references are immutable, so changes to internal state are forbidden.

You can take a reference (pointer) to an item, but you have to give it back. In particular, you have to give it back 
before the lifetime of the underlying item expires, as tracked by the compiler.

```rust
fn new_owner(_x: &Vec<i32>) {
  _x.insert(0, 1);
}
// error[E0596]: cannot borrow `*_x` as mutable, as it is behind a `&` reference
```

### Mutable References

A mutable reference allows the mutation of borrowed resources.

```rust /mut/
fn new_owner(_x: &mut Vec<i32>) {
  _x.insert(0, 5);
  print("{}", _x[0]);
}
 
let mut my_vec: Vec<i32> = vec![1]; // vector containing a single element, 1
new_owner(&mut my_vec);
// Compiles and prints: 5
```

#### Key Points

- If you have a mutable reference to a value, you can have no other references to that value.


```rust /mut/1-3
let mut s = String::from("Test");

let r1 = &mut s;
let r2 = &mut s;

println!("{}, {}", r1, r2);
error[E0499]: cannot borrow `s` as mutable more than once at a time
```

- At any given time, you can have either one mutable reference **or** any number of immutable references.

```rust /mut/5-6
let mut s = String::from("Test");

let r1 = &s;
let r2 = &mut s;

println!("{}, {}, and {}", r1, r2);
error[E0502]: cannot borrow `s` as mutable because it is also borrowed as immutable
```

### Lifetimes

Borrowing references to objects and then passing them around can be dangerous. If a resource that has been borrowed
is deallocated by its owner we must ensure that other users can no longer access the value. In Rust this is done using 
lifetimes, which describe the scope of how long a particular reference is valid for.

Lifetimes are defined using the `'a` syntax, which means '*the lifetime a*'. 

```rust
fn hello_world<'a>(x: &'a i32) { ... }
```

The functions seen before have implicit lifetimes provided through a process known as *lifetime elision*.

```rust
fn print(s: &str); // elided (implicit)

fn print<'a>(s: &'a str); // expanded (explicit)
```

#### Structs

`struct{:rust}`s must define explicit lifetimes when containing a reference. This ensures that any reference to internal 
reference data within an object does not live longer than the owner.

```rust
struct Point {
  x: &'a i32,
  y: &'b i32,
}

fn main() {
  let tmp; 

  {
    let x: &i32 = &1;
    let y: &i32 = &2;
    let p1 = Point { x, y }; 
    tmp = &p1.x;
  } // p1 has exited its scope here
  
  println!("{}", tmp); // `p1.x` does not live long enough
}
```

### Smart Pointers

Smart pointer types act similarly to standard pointers, but allow further fine-grained control over behaviour.
When a developer uses memory that contains dynamically allocated data with smart pointers, they are automatically 
de-allocated.

#### Reference Cell

A reference cell is a smart pointer type that executes the borrowing rules at runtime rather than at compile time. 

`RefCell<T>{:rust}` has the following rules:
- If there is no reference to `T{:rust}`, you may get either a mutable or immutable reference.
- If there is already a mutable reference to `T{:rust}`, you must wait until this reference is dropped.
- If there are one or more immutable references to `T{:rust}`, you may get an immutable reference.

```rust
use std::cell::RefCell;
let container = RefCell::new(11);

{
    let _c = container.borrow();
    // You may borrow immutably multiple times
    assert!(container.try_borrow().is_ok());
    // Cannot borrow as mutable because it is already borrowed as immutable.
    assert!(container.try_borrow_mut().is_err());
}
```

#### Reference Counting

Reference counts (`Rc<T>{:rust}`) sum up the number of references made to an object, and where no references exist, the data can be
de-allocated. A reference-counted pointer to an item allows shared ownership of the data, breaking one of the initial rules outlined
earlier, and allowing data leakage within Rust, so must be used with care. 

Graph data structures use `Rc<T>{:rust}`, as multiple edges might point to the same node, and that node is conceptually 
owned by all the edges that point to it.
a
```rust
use std::rc::Rc;
use std::cell::RefCell;

struct Node {
    next: RefCell<Option<Rc<Node>>>,
    val: i32
}

fn main() {
    let foo1 = Rc::new(Node { next: RefCell::new(None), val: 5 });
    let foo2 = Rc::new(Node { next: RefCell::new(Some(foo1.clone())), val: 10 });
    *foo1.next.borrow_mut() = Some(foo2.clone());
    // Node with value 10 <-> Node with value 5
}
```



Rust Borrow Checker in Five


After recently working on some k8's deployments we came across this obscure error when attempting to delete
multiple unneeded `Secret`s generated by `Helm`.

```yaml
Error: trouble configuring builtin PatchTransformer with config: `
path: my_patch.yaml
target:
  kind: ServiceAccount
...
`: unable to parse SM or JSON patch from [my_patch.yaml]
```

Doing some investigation it was discovered that the pretty innocuous patch in question:

```yaml
- patch: |
    \$patch: delete
    kind: ServiceAccount
    metadata:
      namespace: my-namespace
  target:
    kind: Secret
```

was missing a **mandatory** `name{:yaml}` field. I mean, why would you need a `name{:yaml}`? It's just a patch, right? 
Well, apparently not. And turns out the value can be anything you want, so long as it's there...

```yaml
- patch: |
    \$patch: delete
    kind: ServiceAccount
    metadata:
      name: this-can-be-anything
      namespace: my-namespace
  target:
    kind: Secret
```


The Joys of Kustomize Patches


## Starting Point

Don't laugh, the blog started out pretty rough.

![Picture of the Original Blog](/articles/images/original-blog.png)

Moving in to 2023 I felt that I'd reached my mid-blog-life crisis and a refresh was required.

### Migrating to NextJS

NextJS provides a number of advantages over vanilla React:
- Static site generation
- MDX support
- File based routing
- Image optimisation

### Converting to MDX

I've been using MDX for a couple of separate sites I've been building, - and it's made writing
technical prose a breeze. Previewing blog content within the IDE, with images, prior to switching to the browser
reduces time-to-production massively as well.

I decided to combine this with [next-mdx-remote](https://github.com/hashicorp/next-mdx-remote) enabling static processing of
MDX, with numerous plugins applied at compile time (discussed later). The docs themselves do declare:

> if you are trying to build a blog for personal or small business use, consider just using normal html and css.
> You definitely do not need to be using a heavy full-stack javascript framework to make a simple blog.

but where's the fun in being a conformist...


Also, the [Lighthouse](https://developer.chrome.com/docs/lighthouse/overview/) scores speak for themselves, especially
for First Meaningful Paint times.

![Blog Lighthouse Score](/articles/images/blog-lighthouse-score.png)

#### Article Metadata

Another benefit to `nest-mdx-remote` is the metadata being accessible from the markdown file itself, reducing the need
for manual intervention at compile times for display generation, and easy inclusion of article metadata in the HTML headers for SEO purposes.

Mine takes the format below:

```mdxjs {1-6}
---
title: Improving the Blog
description: It wasn't even public
date: '2023-03-03'
category: Technology
---
```

Thanks to `mdx`, alongside these changes I added some flavour for the article summary cards including the [reading time](https://www.npmjs.com/package/reading-time)
for each article (estimates based on markdown text-length), simple date sorting for recent article highlights utilising [DayJS](https://day.js.org/) from the date
metadata, and categories which will be used in future tag filtering.

### Tailwind

`styled-components` is a great library, but with some recent projects I've found it's a bit slower to prototype features,
with each element templated outside the primary render.

```tsx
// styled-component
const Button = styled.button`
    margin: 1rem;
    padding: 1rem;
    @media (min-width: 768px) {
        padding: 2rem;
    }
    border-radius: 0.25rem;
    border: 2px solid blue;
    background-color: blue;
    color: white;
`;

const TestComponent = () => <Button>Hello world!</Button>;
```

Tailwind allows you to quickly prototype inline styling and easily group styling across multiple components.
It's also pretty intuitive, so guessing commands becomes second nature (also has mature IDE auto-completion support).

```tsx
// tailwind
const TestComponent = () => (
    <div className="text-base mg-1 p-1 md:p-2 rounded border-solid border-2
                    border-light-blue-500 bg-blue-500 text-white-500">
        Hello World!
    </div>
);
```

As you can imagine this becomes unreadable when you start to get multiple elements in the tree.

### Plug-wins

I'm implementing both `rehype` and `remark` plugins as part of the site generation:

- `remark-gfm`: Support for advanced Markdown features such as tables and footnotes
- `rehype-slug`: Appends `id` attributes to each heading element
- `rehype-autolink-headings`: Utilises the `id` attribute above, generating direct page section links.
- `rehype-pretty-code`: Code highlighting using the `shiki` library. Not just syntax highlights but line numbers,
grouped highlights, css themes, and markdown metadata.
- `rehype-img-size`: Discussed [below](#image-lazy-loading).

This is all implemented with a config variable:
```tsx
const mdxSource = await serialize(content, {
    ...,
    mdxOptions: {
      format: 'mdx',
      remarkPlugins: [
        remarkGfm,
      ],
      rehypePlugins: [
        rehypeSlug,
        [rehypeAutolinkHeadings, { behavior: 'wrap', properties: { className: ['anchor'] } }],
        [rehypePrettyCode, {
          theme: {
            dark: 'monokai',
            light: 'one-dark-pro',
          },
          keepBackground: true,
          onVisitHighlightedLine(node) {
            // Each line node by default has `class="line"`.
            node.properties.className?.push('highlighted');
          },
        }],
        [rehypeImgSize, { dir: 'public' }],
      ],
    },
  });
```

### Image Lazy Loading

As the website is statically generated, default lazy-loading for `next/image` elements is unsupported.

I've used the `next-image-export-optimizer` package to generate the images at build time, alongside the `rehype-img-size`
plugin. The plugin ensures that the image size can be extracted from the embedded markdown images, whilst the export provides images
in a number of sizes in the *WebP* format. This allows the image to be lazy-loaded by the browser, which can then be replaced
by the high-quality image for the correct page size once fully rendered.

```tsx
const mdxConfig = {
  ...,
  transpilePackages: ['react-icons', "next-image-export-optimizer"],
  images: {
    loader: "custom",
    imageSizes: [16, 64, 128, 256, 384],
    deviceSizes: [320, 640, 1080, 1920, 2048],
  },
  env: {
    nextImageExportOptimizer_imageFolderPath: "public",
    nextImageExportOptimizer_exportFolderPath: "out",
    nextImageExportOptimizer_quality: 75,
    nextImageExportOptimizer_storePicturesInWEBP: true,
    nextImageExportOptimizer_exportFolderName: "nextImageExportOptimizer",
    nextImageExportOptimizer_generateAndUseBlurImages: true,
  },
}
```

```tsx
const components = {
  img: (props) => <ExportedImage {...props} priority={true} placeholder='blur' loading='eager' role='img' />,
};

...
<MDXRemote {...source} components={components} />
```

### Dark Mode

I thought this would be a relatively simple task, but it turned out to be more complicated than I'd anticipated.

The `next-themes` package provides a simple way to switch between light and dark mode, using the `prefers-color-scheme` media query,
and integrates nicely with `tailwind`.

```tsx {1-10}
import { useTheme } from 'next-themes';
import { useEffect,useState } from 'react';
import { RiMoonClearLine, RiSunLine } from 'react-icons/ri';

const ThemeToggle = () => {
  const [mounted, setMounted] = useState(false);
  const { theme, setTheme } = useTheme();

  // Show only when mounted on client, alleviating hydration issues
  useEffect(() => setMounted(true), []);

  if (!mounted) return <></>;

  return (
    <HeaderIcon onClick={() => setTheme(theme === 'light' ? 'dark' : 'light')}>
      {theme === 'light' ? <RiMoonClearLine size={25} /> : <RiSunLine size={25} />}
    </HeaderIcon>
  );
};
```

However, due to the fact that each page is generated from `mdx`, switching the styling is slightly more complicated.

To get around this I added `scss` ensuring that when the `data-theme` is switched, the correct code blocks are
displayed.

```scss {1-12}
html.dark {
  pre[data-theme="light"],
  code[data-theme="light"] {
    display: none;
  }
}

html.light {
  pre[data-theme="dark"],
  code[data-theme="dark"] {
    display: none;
  }
}
```

### Animation

To enter my final form:

![Even Further Beyond](/articles/images/dbz-goku.gif)

I decided to add some eye-candy with [framer](https://www.framer.com/motion/introduction/).

Using the component below I'm able to introduce all 5 readers (generous) of the blog to the near imperceptible movement of a hand.

```tsx
const HandWave = () => (
  <motion.div
    className='inline-block pl-1'
    animate={{ rotate: 20 }}
    transition={{
      from: 0,
      duration: 0.75,
      repeat: Infinity,
      repeatType: 'reverse',
      ease: 'easeInOut',
      type: 'tween',
    }}>
    👋
  </motion.div>
);
```

N.B. to get a slightly more noticeable effect it's also been added to the theme switcher:

```tsx
<motion.div whileTap={{ rotate: 360 }}>
  <HeaderIcon onClick={() => setTheme(theme === 'light' ? 'dark' : 'light')}>
    {theme === 'light' ? <RiMoonClearLine size={25} /> : <RiSunLine size={25} />}
  </HeaderIcon>
</motion.div>
```

Give it a spin. Pardon the pun.

### Fin

This can all be viewed [on my repository](https://github.com/chrismphilp/philp.io) if you're interested.


Improving the Blog


Git as a version control system has usage across the world, but many developers still limit themselves, staying
within mainstay commands. This article will investigate these litany of commands, and hopefully increase your
understanding and productivity.

### Merge

For example, take a common development team example. A team member has created a branch from **master**, and
added new functionality to print their name when the application runs. While the developer has been doing this,
the master branch has been advanced with 5 more features, leaving the new feature branch out-of-sync. A common
practice is to therefore run **git merge**, creating a new single commit in the feature branch, which
collects all the commits made since the feature branch was diverged from **master**.

This does have its pitfalls though. Given a large team where changes are consistently being pushed to the
**master** branch, the feature branch will have a high number of merge commits polluting its history. This
can be filtered away with an advanced **git log**, but without it, it may be confusing for other developers looking
at your code to quickly understand where changes were made.

![Git Merge Example](/articles/images/git-merge.svg)

### Rebase

Rebasing is the process of moving or combining a sequence of commits to a new base commit. Similar to merge,
**rebase** can be used to integrate changes from one branch, into another. However, unlike merge (which is a
non-destructive operation), rebase is used to move the entire **feature** branch, to the tip of the **master** branch,
incorporating all the previous commits from the **master** branch. This removes the need for unnecessary
commits from a merge, leaving a linear project history.

![Git Rebase Example](/articles/images/git-rebase.svg)

#### Pushing

However, any complex operations that squash commits, or reset/rebase your branch require a force push to the remote
branch.

Therefore, you can run:

```bash
git push --force origin my-feature-branch
```

However, when working on shared branches this can potentially overwrite changes made by other contributors.

A safer alternative that does not overwrite any work on the remote branch is:

```bash
git push --force-with-lease origin my-feature-branch
```

### Squashing Commits

There are times when you realise after you've committed a new feature, you still need to make some changes.
Commonly, a developer will make the change, and commit it to the branch, like so:

```bash
$ git log
commit d84b3e1f899d48c49e8f513302293ff36d1b0421 (HEAD -> master)
Author: Christopher Philp <email>
Date:   Wed Dec 16 14:46:45 2020 +0000

    [master] | Removing unused line

commit 6a4e34b35dd3d5cd6e3fe34df9e04b3f80be0b85
Author: Christopher Philp <email>
Date:   Wed Dec 16 14:46:06 2020 +0000

    [master] | Furthering altering Git instruction

commit bd0a16d1ffbaba26aa2a3e3715eba19503b4c190
Author: Christopher Philp <email>
Date:   Wed Dec 16 14:45:46 2020 +0000

    [master] | Altering Git instruction

commit 0db3d898d87770b47a85c56c61a46bc46343e30a
Author: Christopher Philp <email>
Date:   Wed Dec 16 14:38:59 2020 +0000

    [master] | Adding initial Git article
```

This has needlessly increased the size of the git history, with lots of commits adding nothing. In this case
it is preferable to combine commits `d84b3e`,`6a4e34b`, and `bd0a16d`. A commit
squash or fix can therefore be performed. This involves moving the commit/s into their parent node in the commit
tree. A **squash** will aggregate the commit messages of the combined commits, whilst a fix will
ignore them completely.

As a side-note, rebasing does not actually alter the already made commits (as this is not possible in **git**
through common commands), it creates new ones whilst removing any references to the old ones.

```bash
$ git rebase -i 0db3d898d87770b47a85c56c61a46bc46343e30a
pick bd0a16d [master] | Altering Git instruction
f 6a4e34b [master] | Furthering altering Git instruction
f d84b3e1 [master] | Removing unused line

$ git log
commit dc08bbe95d71a0079f080d326376e2029f11ce3f (HEAD -> master)
Author: Christopher Philp <email>
Date:   Wed Dec 16 14:45:46 2020 +0000

    [master] | Altering Git instruction

commit 0db3d898d87770b47a85c56c61a46bc46343e30a
Author: Christopher Philp <email>
Date:   Wed Dec 16 14:38:59 2020 +0000

    [master] | Adding initial Git article
```

Here we can see from the **git log** that `d84b3e` and `6a4e34b` have been now moved inside `d84b3e`.


What a Git


## Optional Chaining

Optional chaining allows expressions to only run until the point one of the accessed fields is equal to `null{:js}` or `undefined{:js}`.
This is through the use of the `?.{:js}` operator - *optional property access* -
allowing anything expressed on the right of the question mark to continue executing, until `undefined{:js}` or `null{:js}` is encountered.

```js
let y = null;

// x === undefined
let x = y?.z.execute();

// Identical to the above
x = (y === null || y === undefined) ? undefined : y.z.execute();

y = {
  z: {
    execute: () => 5
  }
}
// x === 5
x = y?.z.execute();
```

The new operator is less verbose and more readable. Optional chaining can also be
used in two further areas – optional element access and optional calls.

### Optional Element Access

The optional chaining operator can be used when accessing to non-identifier properties. For instance if
accessing an index of an array.

```js
// New operator usage
return arr?.[0];
// Previous approach
return (arr === null || arr === undefined) ? undefined : arr[0];
```

### Optional Calls

These allow us to conditionally call expressions if they’re not returning `undefined{:js}` or `null{:js}`.

```js
let y = {
  z: {
    execute: undefined
  }
}

// x === undefined
let x = y.z?.execute?.();

y.z.execute = () => 5;

// x === 5
x = y.z?.execute?.();

y.z.execute = 5;

// This will still result in a type error
x = y.z?.execute?.();
```

## Nullish Coalescing

Nullish coalescing requires the use of the `??{:js}` operator and is used to fall back to a default value
when similarly dealing with `undefined{:js}` or `null{:js}`. The operator states that the value on the left of `??{:js}`
will be used if not equal to `undefined{:js}` or `null{:js}`, else use the expression to the right. See the example below:

```js
let y = null;
let z = 5;

// x === z === 5
let x = y ?? z;

y = 55;

// x === y === 55
x = y ?? z;
```

The `??{:js}` operator can replace uses of `||{:js}` when trying to use a default value, which gives better behaviour for falsy values.

```js
// ?? is better than using || as it avoids falsy behaviours
let x = 0;
let y = 0.5;

// total === y === 0.5 -> unlikely to be intended
let total = x || y;

// total === x === 0
total = x ?? y;
```

## Combining the two operators

Finally, the two operators can be combined to set a default value when `undefined{:js}` or `null{:js}` are encountered.

```js
let person = {
  name: 'Chris',
  details: undefined
};
let x = 5;

// personsAge === x === 5;
let personsAge = person.details?.age ?? x;
```

*Hopefully* you've learnt something new, or if not confirmed your understanding of operators that you use in
your daily development.


A quick look at some of the new features in TypeScript 3.7

TypeScript - Let's Learn


## Introduction

C and C++ unlike a lot of other languages provide the ability to directly interact with hardware memory -
normally described as a middle-level or systems language - through the use of
*pointers*. Every variable declared in any language has a memory location, and every memory location has an
address used to locate it. C++ gives you the power to directly modify this memory.

### Accessing Memory

In C++, the *memory address* (where a value lives) of a variable can be accessed through the
`&{:cpp}` operator - see the example below.

```cpp {1-3}
std::string food = "Pizza";
cout << food;  // outputs the value of food (Pizza)
cout << &food; // outputs the memory address of food (0x6dfed4)
```

### Pointers

A pointer on the other hand, is a variable that *stores the memory address of a variable as its value*, and
is created using the `*` operator. A pointer can exist for *any data type*, as it merely points to a memory address of the variable.

```cpp {1-9}
int x = 5;
int* y = &x;
// Equivalent to
int *y = &x;

cout << x; // outputs the value of x (5)
cout << y; // outputs the memory address of x (0x6dfed4)
cout << &y; // outputs the memory address of y (0x6ffd4)
cout << *y; // outputs the value of x (5)
```

### Arrow Operator

The arrow operator is a shorthand method for accessing the contents of a
`struct` or `class` *pointer* - normally the `.{:cpp}` operator would be used for non-pointer
access. The example below shows the equivalences.

```cpp {1-15}
class Rectangle {
  int width, height;
  public:
  void set_values (int,int);
  int area (void);
} rect;

Rectangle* p_rect = &rect; // creates a pointer to the rect declared above
p_rect->area;
// This is equivalent to
(*p_rect).area;
```

### References and Pointers

By default, arguments to a function in C++ are passed by value, and the changes made to any arguments inside the
function will not affect the original value, and instead are made to a copy. The 3 primary ways to pass arguments
are shown below.

#### Call by **value**

```cpp {1-7}
int square1(int n)
{
  cout << &n; // outputs the memory address of n (0x6dfed4)
  n *= n;
  // original n is unchanged - a copy of n has been created,
  // only the n inside the function is altered
  return n;
}
```

#### Call by *reference with a pointer argument*:

```cpp {1-12}
int x = 5;
int *p_x = &x;
square(p_x);

void square(int *n)
{
  cout << n; // outputs the memory address of n, which is the same as x (0x6dfed4)
  *n *= *n; // deferences to get the value at the memory address of p_x,

  // updating the value stored there
  cout << *n; // outputs the squared value of x (25)
  cout << x; // outputs the altered value of x (25)
}
```

#### Call by *reference with reference argument*:

```cpp {1-15}
int x = 5;
square(x);

void square(int &n)
{
  // inside the function, the reference is used to access the
  // actual argument used in the call
  cout << &n; // outputs the memory address of x (0x6dfed4)
  cout << n; // outputs the value of x (5)

  // Implicit de-referencing (without '*')
  n *= n;
  cout << n; // outputs the altered value of n, which is equal to x (25)
  cout << nx; // outputs the altered value of x (25)
}
```

### Benefits of Pointers

There are a number of benefits to using pointers:
- Values that are passed in to a function do not have to be copied, especially useful with large objects.
- They allow more than one value to be returned from a function.
- Memory access through pointers is stated to be more efficient than through an array.

```cpp {1-15}
int x = 5;
int y = 55;
int *p_x, *p_y = &x;
edit_two(*x, *y);

void edit_two(int *x, int *y)
{
  *x += 5;
  *y += 5;

  cout << *x; // edits the value at the memory address of x (10)
  cout << y*; // edits the value at the memory address of x (60)
}
```

Hopefully this has cleared up any confusion surrounding pointers, and you can begin to understand those
insufferable `nullptr` exceptions.
