---
# System prepended metadata

title: 'UKAEA RSE Team Journal Club: \[Insert date\]'

---

# UKAEA RSE Team Journal Club: 06/06/2024


:::info
- **Location:** Usual
- **Date:** 06/06/2024
- **Article Link:** https://quuxplusone.github.io/blog/2022/01/23/dont-const-all-the-things/
- **Agenda** *TODO*
  1. Brief intro `2 min`
  2. Discussion `43 min`
- **Participants:**
  - 
- **Host:** Chris

:::

## Brief Intro

Found blogpost through clang lints.

CM: A priori should use const wherever possible

Article says:

    - Pass by const reference is good
    - Pass by non-const reference is bad
        - Suggests pass by pointer to make calling code clearer that object can be modified
    

## Discussion

### General

- JN: Following consistent conventions make code easier to read
    - CM: Application across the board too restrictive
- KC: Common problem is unable to move out of const, Rust fixes this with borrow checker
- SP: Const should be on the right

### Struct member variables const

- Article discourages const member variables
- Const member variables prevents reassignment of member variables or instances of that class
- Article suggests "const" member variables should instead not have a setter
- HS: Use struct for data records and classes with getters/setters for "OOP" classes
- CM: Protecting mutability of variables via API is hard to manage for large classes
- CM: Big classes aren't assigned

### Local variables const

- JN: Too many keywords in C++ code, no performance benefit
- JP: Can prevent implicit move when return value optimization fails

### Const return value

- CM: generally no good reason to do this
- KC: exception code example: if ((a*b)=c) {}
    - if operator* returns non const value this code which should have == compiles
    - type needs to be implicitly convertable to bool
    - Should be caught by compiler/linter
    - from Scott Meyers Effective C++

### Consensus

- No real consensus
- C++ could be better