As an engineer, we have to think about what is the best approximation and trade offs among different solutions when posed with a hard problem. While the CS field greatly informs software engineering and provides it with a fundamental basis to extend from, it doesn’t wholly prepare a junior software engineer for working in the field, especially in the parts that matter the most.

So what does this have to do with interviewing software engineers? Well it’s hard because they have little to no experience. That isn’t their fault. It is just the difficult situation that interviewers and interviewees find themselves in. What’s worse is that there are good jobs out there but the candidate ends up having a terrible interviewer.

Dynamics

As someone that has given many interviews, my worst nightmare is leading the candidate down a road I can’t pull them out of due to a bad question or guidance. For me the worst feeling is holding an interview that wastes the candidate’s time and the opportunity to accomplish their career goals. As an interviewer it is my responsibility that the problem be clear to the candidate and something that reflects actual skills needed.

Lack of Consistent Feedback

I have had interviewers go out of the room to take a bathroom break, sit on their phones, or just stare silently while I worked on the problem. An interview is just as much a chance to see how the candidate would work with you as you them. It is also an opportunity to evaluate their teamwork skills. This kind of work is not an island and having a poor team dynamic can ruin projects.

Another problem is when the interviewer lets you hang yourself with your own solution. It is important that the interviewer provide guidance and redirection. Not doing so wastes the entire time left instead of giving a candidate an opportunity to show what they can do after correction. I had an interview with a principal engineer once for their architecture interview (they break them up into categories). In it they asked me to find a way to count the number of unique exceptions in a production system. I went right into showing an architecture of designing a logging system and how the processing would work at scale. They had a line of questioning talking about the logging system itself and then at the end told me I could just hash the exceptions. I was pissed. If the interviewer had told me it would be a simple data structures question I would have answered it right away but was completely misled about the parameters of the interview. It was my fault that I made a simple solution a complex one, but the opportunity was completely missed on seeing what I could do, even if that meant I got marked down.

Toy Questions

IMO the worst kind of questions are the ones that don’t reflect real work at all. How is reversing a linked list or rotating a matrix going to show that I am a good engineer? Some people say that this just reveals how you think about things and while there is some merit to that, it can be very perilous. It requires the candidate to be well studied in these problem spaces first. A better question reflects not only how they approach something but the problem they are trying to solve. What compounds this problem is when an interviewer has a single toy question they ask all the time and evaluates performance based on their own long time familiarity with the problem. The worst is when the problem requires just one key observation to solving it.

Poor Personality

I have high anxiety and have had interviews go terribly wrong. This is also why I try really hard to improve myself in the process and be an interviewer that gives the candidate the best opportunity of proving themselves. I have co-workers and friends that I consider to be very high quality engineers that would never had the chance if someone didn’t accommodate them in terms of personality.

So what do I mean by poor personality? The interviewer has the power to make or break in these situations. Imagine some of the difficult people that you had to deal with in your life. Now have them be your interviewer. Dispassionate, judgemental, uncooperative, critical, the stuff of nightmares.

Feedback Goes Both Ways

If you have an interviewer like this don’t be afraid to call it out afterwards. Some of these kind of interviewers may score you well but they should be getting feedback that this isn’t how to handle it. Be polite but be pointed about the behavior. It may not matter but many companies want this kind of feedback. At the end of the day, any person committed to wanting great candidates cares about the process that gets them to that.

It’s Not All Bad

For the bad interviews that I have had or heard about, there are plenty of, if not more, good ones too. The interviewers were attentive, guiding and gave problems that were multi layered and faceted. Some of them I came out wanting to be on their team because the collaboration went so well.

The reason I call out the bad interviewers is because candidates tend to put the blame on themselves. There is plenty that can be done to make sure you pass an interview but it is important to know what to look for too. Who wants to work for a company whose values are reflected in their employees this way? The process is as much about you evaluating them as they you and a good interviewer should know this. Although this isn’t a blame game either. Even a bad interviewer could be the gatekeeper to a great job and you will never have to see them again after being hired.

How Should I Prepare

The bad interviewer is a caricature. An embodiment of all the things that could go wrong. Really most have a mix of qualities both positive and negative, intentional and not. You will just have to make sure you do well in spite of the circumstances given.

Become a data structures and algorithms gymnast. I call it this because it is the most rote part. It bites some candidates because they just didn’t do the work. Like a gymnast you need a bunch of practice and be able to contort yourself in different ways because every problem will be some variation.

Problem Spaces

What is the problem that is trying to be solved more generally speaking? A problem space doesn’t refer to any specific solution but rather the end goal that needs to be met. If you become familiar with these, you can also identify some of the common components that are used to solve them. Below is an approximate sample of the problem spaces out there.

Strings

Google Search - string interview questions

For example, in bio-informatic key sequencing, the problem space is in looking for specific patterns (e.g. genome sequencing). Most all sequences can be represented using a string abstraction. While the example of key sequencing is a real world example, it can be generalized to ask questions about strings. The generalized problem space would be strings. By strings I don’t mean words or text, I mean a sequence of symbols in the most abstract way.

Excerpt of a Gene Sequence

Given the string problem space, some combinatorial factors, with examples, could be length, affix, repetition, similarity, and cardinality. Combinations of those being:

• Least common subsequence.
• Largest common prefix.
• Most unique string.
• Longest repeated string.
• Number of unique characters (i.e. cardinality).
• Words that share the most characters.

This is just a small example. Least common subsequence is a popular one but why stop there? If you can do the combinations then you will have mastery. Just remember an interviewer is trying to mix it up too.

Encoding

Google Search - data compression interview questions

Claude Shannon - The OG of Information Theory

How would you represent data in memory? Combinatorial factors could be cardinality, word size, and direction. Some combinations:

• Number of unique values encountered.
• Counters of letters encountered.
• Compression for streaming data.
• Compression for bounded data.
• Record a sequence of values containing A, B and C.

Lookup & Counting

• Google Search - hashing interview questions
• Google Search - computer counting interview questions

What is the best way to lookup data with the constraints given? Combinatorial factors could be cardinality, length, and match type (whole, partial).

• Specific string of unbounded length.
• Strings that share the first 3 characters.
• Specific count of a single character in a corpus.
• Words who share the same 3 letters.

Notice how there is some overlap here with strings, that is because lookup frequently is a subset of the string problem space. We could easily apply common solutions from the string problem space to these as well as hashing and graphs (i.e. trie).

Graphs

Google Search - graph interview questions

Spotting Spammers in Social Graphs

How do you find specific relationships between entities? Combinatorial factors could be value cardinality, size, edge direction, edge weights and cycles.

• Least cost path between two points.
• Detect all cycles.
• All paths to a point from all other points.
• Paths that never leads to a cycle.
• Reverse direction to every odd numbered node and detect all cycles.
• Remove edges in a cycle that would have the most cost.

Keep in mind that a linked list and tree are just graphs with constraints. If you learn graphs, you learn trees and linked lists. It’s just with trees their is direction so it can be flipped.

Sorting

Google Search - sorting interview questions

How do you derive meaning (how is it practical?) by ordering some collections of values? Combinatorial factors could be value cardinality, stability, partiality, and comparability.

• Group cards by color.
• Sort integers by partial order where some integer k can be 4 positions away from k+1 and k-1.
• Sort a stream of natural numbers.
• Group floats by their whole number and the order they appear (stable).
• Order a deck of cards by rank, color and suit.

Dynamic Programming

Honestly I don’t study this and despise its use in interviews. Rather jadedly I would speculate that most interviewers wouldn’t even be able to come up with a DP solution from first principles. Identifying optimal sub-structure really just takes a lot of experience IMO. Much like induction proofs.

I find a better approach is to work a real world problem from several solution approaches and then use the DP method intuitively. This comes after really understanding the problem and consequently its sub-structure when applied in successive steps (either iteratively or recursively).

Space & Runtime Are Cross Cutting

Google Search - space and time complexity analysis exercises

For all of these problem spaces, it is important to factor in time and space complexity as well. For example, merge sort is best suited for space because the re-ordering happens in blocks. However quick sort is considered the most performant for in-memory on average even though quick sort has the largest worst case. For lookups a bounded set of keys could just use an array (e.g. frequency counting letters).

Bonus points for pointing out engineering ramifications for choosing a solution even if it has the same complexity. It may be just a constant multiplier difference (e.g. 4n and n) but it could mean the difference of thousands of dollars in a production system’s resource usage.

Some tips when analyzing complexity.

• How do the variables grow as you take them to infinity? If given m and n, does one become insignificant / constant. Sometimes a candidate will give something like O(m*n) when in reality it is just O(m). Another way to look at it below.
• Think of complexity on average but be explicit. Maybe you are dealing with a set of strings. Let’s say the size of the set is m and the largest length of a string is n, is the space complexity really O(m*n). Possibly in a theoretical sense but realistically m will be the overwhelming factor; it would be O(m) on average. Tell the interviewer this though, don’t just give them the answer O(m)

Think Out Loud

While going through your thought process, make sure you share it with the interviewer like you would in a job. It’s like spreading out your ideas on a table, picking each one up, investigating it, saying what the pros and cons are, and then going with the best candidate at the moment while also being open to improvement. Maybe your idea isn’t the best one but put something out there that you can execute on and refine later. This will give an opportunity for the interviewer to see how you approach problems and judge the qualities of it.

Ask A Lot Of Questions

Really ask them. The worst scenario is that you assume too much and go down a bad path. Probing the problem shows that you are thinking about all the possible aspects and applying critical thinking. I have had candidates ask questions that I didn’t even ask myself about the problem (impressive). In my experience, the better candidates were very inquisitive. Be curious and learn more.

Think Before You Type

Maybe you’re nervous, maybe you think you know the answer and you go straight to typing. Stop! Don’t do it. I have been guilty of this myself. Writing code is a matter of self expression for me, a way of speaking. Although I have learned in time that it can also be a way to code yourself into a corner or hit a dead end that requires lots of back tracking and deletion of code. It can also be a bad sign that you are a coder that doesn’t think before you act and can potentially waste large hours of time on bad paths. This is why design is highly valued in software engineering. It forces people to think about the hard problems before they run up against them in code. Same applies to an interview. I have seen candidates rush into a problem only to stop and realize they really didn’t understand it. Don’t do this. Stop and go over your design with the interviewer. Walk through the different approaches, considering each and then selecting the route you want to take. This complements the idea of thinking out loud.

Practice Coding .. A LOT

When walking through mock interviews, always write out your solutions. In this COVID world, that means typing on a keyboard but it doesn’t hurt to do both. Especially if you get called up for an in-person interview.

Pick a Language

Don’t pick a language you think they would want you to write, pick one you are good at and know how to use both syntactically and idiomatically. Unfortunately there are companies that want you to code in a specific languages. Personally I think that is a poor choice for the company since they should be looking for talent but sometimes that’s just the way it goes. For me, I would pick Python because it is the easiest to write IMO.

For the language you use, make sure you know:

• the syntax of the language,
• the idioms used, and
• the framework functions / classes involved.

For example, know how to work with sequences (e.g. lists), manipulate symbols (e.g. casing strings), and things similar. This will come up naturally as you work on solutions. Whatever language you end up picking, always code out the solution in it. It will build up that muscle so you can easily translate your ideas to code quickly.

Break Up the Problem

Start top down. Meaning start with the top level function and then break up the problem into sub functions. Deal with easy ones first and then slowly work your way towards the hardest. A divide and conquer approach shows you can compartmentalize and break out the problem into sub problems. It is something that is impressive and a lot of candidates don’t do.

def solve_problem():
  easy_values = solve_easy_subproblem()
  hard_values = solve_hard_subproblem()
  return do_trivial_thing(easy_values, hard_values)

def solve_hard_subproblem()
  easypartofhard_values = solve_easypartofhard_subproblem()
  somewhathard_values = solve_somewhathard_subproblem()
  return do_code_timeconsuming_thing(easypartofhard_values, somewhathard_values)

An additional upside to this is that if you don’t complete the solution in time, the interviewer is able to at least evaluate the parts that you wholly finished. This is especially helpful if you solved the most conceptually hard parts but just didn’t have enough time for the time consuming code part.

Manage Your Emotions

For some, interviewing is not emotionally taxing but for others it can be debilitating. Personally, this is a big problem for me. I froze up completely for an interview once. I couldn’t even answer a trivial problem. I was so panicked that I couldn’t even think straight. The interviewer was very kind about it all but there was nothing to evaluate, I failed. Some things that helped me:

• Practice until it is instinctual. Do gymnastics until you can cooly answer any interview question or at least get close to it. Interview problems are just combinations; if you learn the fundamentals and apply them in different arrangements, they aren’t so surprising.
• Mock interview a lot. Have a friend or use an online resource to constantly perform mock interviews. It will help you with anxiety if you have it and keep you accustomed to the interview format. When I have held mock interviews I have intentionally been cold but polite. It wasn’t to be mean but to prepare them. If you have different tiers of jobs you are interested in, interview with the lowest ones first. Less is on the line if you fail and it is the best thing because it is real.
• You can always try again. Most companies allow a candidate to try again after some time has passed. Just because you failed an interview doesn’t mean you are a bad candidate. It just means you were off or weren’t prepared enough. I’ll be honest, I failed my first interview with Google, and thought I wasn’t good enough. Five years later I tried again and got the job.
• You are good enough. Imposter syndrome is a big thing. Especially when you work with people that you perceive to be intelligent and/or well accomplished. Sure there are people that have an obvious raw high intelligence but in my experience that is not the majority, and even then, very incongruent. Many intelligent people who I have met are highly driven. Education is a large factor in intelligence. Also intelligence is not some monolith; people express their intelligence through different characteristics as I alluded to with the word incongruent. In other words, intelligence is fluid and if you are driven, you are good enough.

Resources To Use

Competitive Programming

Sites like TopCoder are nice and a way for you to get your chops solving different problems but it is first and foremost a competitive programming site. It is meant to present challenges that are new and novel, eliciting the tersest amount of code in the smallest amount of time. This isn’t to say if you got good at this you wouldn’t do well in an interview, the opposite, but it requires you to inuit the ability to solve based on working through a lot of problems rather than learning the underlying problem spaces.

Interview Question Databases

This pertains to sites like CareerCup where questions are posted that came from actual interviews with tech companies. Keep in mind that a lot of these get posted because they were difficult for the candidate. That means you are more likely to see harder questions and have false expectations of what is required from you. Take these sites with a grain of salt.

Online Exercises

Online IDEs and sets of exercises that you can drill on are useful (e.g. GeeksForGeeks, HackerRank). I usually pick the data structures and algorithms exercises and just grind on them several times until it becomes second nature. Experiment with different sites and see which one works best for you. The key is that you are able to get through the exercises fairly quickly. A good site should be able to build you up by difficulty so that you can get muscle strength.

Conclusion

That was a lot but I hope it helps. This is rather a brain dump for me of all the thoughts I have had on interviewing in my career. If I were to summarize in just a few points, it would be to:

• Drill and drill and drill everyday for several weeks.
• Go through all the data structures and algos.
• Go through all the problem spaces and make up combinations.
• Mock interview and challenge yourself to socially uncomfortable situations.

Lastly and most importantly is to know that you can do this. In my experience, lack of preparation has been the biggest hit on candidates not getting a job. Put in the time and it will help a lot in getting there. Good luck!

Phases

Compilation comes into five phases.

• Scanner - Breaks up text into tokens.
• Parser - Arranges the tokens into relationships that form a tree.
• Symbol Table - Attributes metadata like type and scope to identifiers (e.g. variables, functions, classes).
• Intermediate Representation (IR) - Representation of the code that is typically a series of statements / commands that can be optimized before becoming the assembly code.
• Compiled Code - The actual assembly code that gets generated at the end as a series of opcodes with their corresponding data and control bits.

Of course this description makes a lot of assumptions and doesn’t account for different approaches to compilation but serves well for the purpose of learning and demonstration. For the following phase breakdowns we will use a C like language with a simple set of constructs as a toy use case. Let’s get started…

Scanner

This is also known as the lexer or tokenizer. It’s responsibility is to take text and create indivisible units / tokens out of it. For example, the following…

int x = 123;

…would be tokenized as int, x, =, 123, and ;.

Let’s take a more complex example.

void foo(int& bar) {
  bar = 123;
}

This would be tokenized as int, foo, (, int, &, bar, ), {, bar, =, 123, ;, and }.

As a contrast, let’s look at a Python like snippet…

def foo(bar):
  bar = 123

Since these languages treat spaces as part of the language (unlike C-like ones), this would be tokenized as def, foo, (, bar, ), :, \n, \s, \s, bar, =, and 123. This approach is a bit nuanced though as any spaces after : and before newline are not tokenized since they have no meaning for the compiled language (same goes for extraneous newlines). This is why the last C-like example could be expressed as.

void foo(int&bar){bar=123;}

The only case where spaces have any meaning is to separate identifiers.

Now let’s take an example we will use going forward for all the phases.

if (x > 2) {
  y = 1;
} else {
  y = 2;
}

Parser

The parser phase transforms the tokens into relationships between them (semantical) where it takes the flat list of tokens and puts them into a tree structure (i.e. Abstract Syntax Tree (AST)). Here is what our example looks like.

Something useful to know is the difference between the scanner and parser phase.

• The scanner phase is the lexical component, it is concerned with the structure of symbols / tokens (in this case a combination of letters, numbers and punctuation).
• The parser phase is the semantic component, it is concerned with the meaning of symbols as they relate in the context of one another. For example…

void foo() { int x = (1+1) + 1; }

The parenthesis are the symbols present in the function declaration and the function body but they have completely different meaning in their relationship with the rest of the symbols.

• One is in the context of a function declaration foo and denotes the start and end of declared parameters.
• The other imposes order of operation on the expression assigned to the variable x.

This is what makes the parsing / semantic phase different than the scanner / lexical phase.

Symbol Table

The symbol table provides information about the identifiers such as type and scope. Let’s take the canonical example we have been using and encapsulate it into a function so we can give it some scope.

void foo(int x) {
  int y;
  if (x > 2) {
    y = 1;
  } else {
    y = 2;
  }
}

The code gets stored in the symbol table as…

A symbol table is defined and typically stored in each compilation unit that corresponds to an object file (e.g. *.o, *.obj). These tables are not only used for metadata but will also serve as lookups for other object files that are trying to resolve their own symbols in the linker phase.

Slight Detour to Undefined Reference

Note this is around the phase where you will get errors like undefined reference. The linker in these cases is trying to link the symbol references between the object files. An example of an undefined reference.

// This says, I promise this thing exists. Just keep compiling and 
// it will show up when the linker searches for it.
extern int foo();

int bar() {
  int x = foo();
  return x + 2;
}

The symbol table will be generated as…

If foo isn’t included anywhere either directly or indirectly through headers, an undefined reference will get reported. In these cases, the linker couldn’t resolve the symbol scope, which has an extern placemarker waiting for linkage.

Back on Track

Let’s now assume the extern int foo(); is defined in another file. The resolved symbol table becomes.

Intermediate Representation (IR)

Generated from the parser graph and symbol table is the intermediate code / representation. It is the code that gets generated before translating to assembly. The reason this exists as opposed to direct assembly translation is so that optimizations can be made before final code expression.

IR generators come in different types and take on different degrees of responsibility. Examples of IRs are LLVM, Java bytecode, and Microsoft CIL.

.NET CIL

Applying the .NET Common Intermediate Language (CIL) to our canonical example below…

void foo(int x) {
  int y;
  if (x > 2) {
    y = 1;
  } else {
    y = 2;
  }
}

…becomes…

.method private hidebysig instance void 
          foo(int32 x) cil managed
{
  .maxstack  2
  .locals init (int32 V_0, bool V_1)
  IL_0000:  nop
  IL_0001:  ldarg.1
  IL_0002:  ldc.i4.2
  IL_0003:  cgt
  IL_0005:  ldc.i4.0
  IL_0006:  ceq
  IL_0008:  stloc.1
  IL_0009:  ldloc.1
  IL_000a:  brtrue.s   IL_0012

  IL_000c:  nop
  IL_000d:  ldc.i4.1
  IL_000e:  stloc.0
  IL_000f:  nop
  IL_0010:  br.s       IL_0016

  IL_0012:  nop
  IL_0013:  ldc.i4.2
  IL_0014:  stloc.0
  IL_0015:  nop
  IL_0016:  ret
}

This is an instance of a stack based bytecode representation as opposed to a register based approach. The two approaches are not strictly one or the other, but typically a virtual machine uses one predominantly. The more popular JVM and CIL are stack based but sometimes leverage registers. For example, the CIL will store simple constants like integers or perform calculations using registers since it is faster in terms of memory access than the L1+ cache.

Compiled Code

The last and final step is the machine code itself. This is usually the assembly code that gets ran. Using our previous example for the CIL code. This bytecode gets translated into x86 code as…

C.foo(Int32)
  L0000: push ebp
  L0001: mov ebp, esp
  L0003: sub esp, 0x10
  L0006: xor eax, eax
  L0008: mov [ebp-0xc], eax
  L000b: mov [ebp-0x10], eax
  L000e: mov [ebp-4], ecx
  L0011: mov [ebp-8], edx
  L0014: cmp dword ptr [0x1adec1a8], 0
  L001b: je short L0022
  L001d: call 0x661dfc10
  L0022: nop
  L0023: cmp dword ptr [ebp-8], 2
  L0027: setg al
  L002a: movzx eax, al
  L002d: mov [ebp-0x10], eax
  L0030: cmp dword ptr [ebp-0x10], 0
  L0034: je short L0042
  L0036: nop
  L0037: mov dword ptr [ebp-0xc], 1
  L003e: nop
  L003f: nop
  L0040: jmp short L004b
  L0042: nop
  L0043: mov dword ptr [ebp-0xc], 2
  L004a: nop
  L004b: nop
  L004c: mov esp, ebp
  L004e: pop ebp
  L004f: ret

Into the Abyss

Let’s go even further now and see what the encoded values look like in the instruction register of an x86 CPU. On the left are the line numbers and the contents of the register, and on the right is the assembly equivalent. Notice how some of the hex matches value to the right.

0:  55                      push   ebp
1:  89 e5                   mov    ebp,esp
3:  83 ec 10                sub    esp,0x10
6:  31 c0                   xor    eax,eax
8:  89 45 f4                mov    DWORD PTR [ebp-0xc],eax
b:  89 45 f0                mov    DWORD PTR [ebp-0x10],eax
e:  89 4d fc                mov    DWORD PTR [ebp-0x4],ecx
11: 89 55 f8                mov    DWORD PTR [ebp-0x8],edx
14: 83 3d a8 c1 de 1a 00    cmp    DWORD PTR ds:0x1adec1a8,0x0
1b: 74 05                   je     22 <L0022>
1d: e8 0c fc 1d 66          call   661dfc2e <L004f+0x661dfbdf>
22: 90                      nop
23: 83 7d f8 02             cmp    DWORD PTR [ebp-0x8],0x2
27: 0f 9f c0                setg   al
2a: 0f b6 c0                movzx  eax,al
2d: 89 45 f0                mov    DWORD PTR [ebp-0x10],eax
30: 83 7d f0 00             cmp    DWORD PTR [ebp-0x10],0x0
34: 74 0c                   je     42 <L0042>
36: 90                      nop
37: c7 45 f4 01 00 00 00    mov    DWORD PTR [ebp-0xc],0x1
3e: 90                      nop
3f: 90                      nop
40: eb 09                   jmp    4b <L004b>
42: 90                      nop
43: c7 45 f4 02 00 00 00    mov    DWORD PTR [ebp-0xc],0x2
4a: 90                      nop
4b: 90                      nop
4c: 89 ec                   mov    esp,ebp
4e: 5d                      pop    ebp
4f: c3                      ret

The byte layout from left to right is opcode, control bits, data. Imagine being the person that had to execute all of this manually.

This was considered a step up from this.

Because they didn’t want to do this.

01010101
1000100111100101
100000111110110000010000
11000111000000
100010010100010111110100
100010010100010111110000
100010010100110111111100
100010010101010111111000
10000011001111011010100011000001110111100001101000000000
111010000000101
1110100000001100111111000001110101100110
10010000
10000011011111011111100000000010
11111001111111000000
11111011011011000000
100010010100010111110000
10000011011111011111000000000000
111010000001100
10010000
11000111010001011111010000000001000000000000000000000000
10010000
10010000
1110101100001001
10010000
11000111010001011111010000000010000000000000000000000000
10010000
10010000
1000100111101100
01011101
11000011

In fact the whole concept of an assembler was once considered by some as a wasteful endevour. It was using computational resources to create instructions to use computational resources. The whole point is that it used computational resources! In today’s world where we are pretty wasteful of computational resources by orders of magnitude, this was not taken for granted back then when the idea of computational time sharing was a thing. We have come a long way.

Closing Thoughts

So now we have come full circle from…

void foo(int x) {
  int y;
  if (x > 2) {
    y = 1;
  } else {
    y = 2;
  }
}

…to the binary seen above.

The compiler is a great thing, it allows us to use abstractions that make development much easier and express ideas in ways that humans are more able to grasp. Turning the realm of controlled electrons into that of the symbolic and philosophical, permitting us to process and interpret the world around us.

References & More Reading

• To start exploring on how to create a language for yourself, check out Antlr (lexer) and Bison (parser).
• My First Language Frontend with LLVM Tutorial - Exactly what it says.
• Lecture notes on Writing a Toy Compiler.
• ASTs - What they are and how to use them - Engaging blog post on how ASTs work and dives further into other topics also covered here.
• GodBolt: Compiler Explorer - Fantastic online IDE to view compiled assembly from high level languages.
• Let’s make a Teeny Tiny compiler, part 1 - First part of a series showing how to make a compiler using Python. Trivial but approachable and demonstrative to learning compilers.

Contributions are definitely welcome. For the lazy, here is the README.md below.

Some sample Doxygen themes using Bootstrap 5 with different approaches to CSS use. Not all of the HTML is Bootstrap though, just the header and footer with Bootstrap like coloring applied to the body elements.

Click here for the demo landing page..

Documentation

This project is a demonstration of possible approaches to theming Doxygen generated websites. Frameworks other than Bootstrap can be used, this is just an example of what is possible.

• Applied directly.
• Root variables applied.
• Simple color palette propagated.

Pre-requisites

• CMake - Build the project and create the website.
• Doxygen - Create the website documentation.

Components

All components use CDN links to keep project file overhead low.

• Bootstrap - Styles the header and footer. Also provides the primary colors for the Doxygen classes.
• Font Awesome - Header icons.
• jQuery - Required by Bootstrap and used for the custom palette picker.

Sample CSS

Below is the CSS used for the Neon Pink theme.

:root {
  --color-body: #bda9a9;
  --color-hyperlink: #ffffff;
  --color-title-background: #8a1253;
  --color-title-text: #ffffff;
  --color-footer-header-background: #c51350;
  --color-footer-header-text: #ffffff;
  --color-section-header-background: #e8751a;
  --color-section-header-text: #ffffff;
  --color-section-subheader-background: #fda403;
  --color-section-subheader-text: #ffffff;
  --color-section-text: #ffffff;
  --color-section-background: #bd9a9a;
}

Notice how there is a lot of #ffffff in there. This could probably be further simplified.

Future Ideas

There are a lot of CSS features that can be found. Some ways to simplify the palette even more.

• Filter Functions - Allows for different affects and interesting functions like brightness.
• HSL Scheme - Makes darkening and lightening easier.
• Arithmetic - Useful for modifying color values.

For this walkthrough, there will be two endpoints:

• Action repository where your created action under test lives.
• Test repository that houses the tests.

The general idea is to have your action repository publish an event that says a push has occurred, relay it to the test repository which triggers tests on the test repository. For this example I am using my own recently published action awalsh128/cache-apt-pkgs-action. Feel free to swap out this with your equivalent action.

The steps needed are to create:

• a shared secret,
• a staging (or another) branch besides master on the action repository,
• a repository to run tests on your action code,
• tests in your test repository,
• a publish action in your action repository,
• a subscriber action in your test repository.

More details on each step below.

Create Shared Secret

A Personal Access Token (PAT) will allow the publisher (action repository) to trigger the event that the subscriber (test repository) will then act on. This shared secret will be needed so they can interact.

Instructions to setup your PAT. Use the arguments below.

Profile > Settings > Developer settings > Personal Access Token > Generate New Token

Once you complete the configuration it will then show you what the value is. Note this isn’t my actual value, so don’t get any ideas. >:|

We can now share this PAT / secret with the publisher.

Publisher

Turning our attention to the publisher side (action repository) of the event that will trigger the tests on the test repository.

Store Shared Secret on Publisher

In order for the action repository to publish the event to the test repository, it will need access to it. The PAT will need to be stored in a variable so it can be used in the action without actually revealing it’s value.

To create a scecret, you can use a URL like below. Replace the cache-apt-pkgs-action-ci repository with your own test repository name.

https://github.com/awalsh128/cache-apt-pkgs-action-ci/settings/secrets/actions/new

Use the arguments below when creating the secret.

Settings > Secrets > New repository secret

Here’s an example of the PAT we generated before.

Create a staging branch in awalsh128/cache-apt-pkgs-action

This will be used as a testing branch. Broken code can live here without going to master. It doesn’t have to be called staging, call it whatever you want (e.g. dev, whatever).

git checkout -b staging
git push origin staging
git push --set-upstream origin staging

Create Publish Action

In the action repository, create .github/workflows/staging_push.yml workflow that will trigger on any push to staging.

name: Publish Staging Push Event
on:
  # Allow manual triggering for debugging.
  workflow_dispatch:
  # Publish when we see a push to staging.
  push:
    branches:
      - staging

jobs:
  publish_event:
    runs-on: ubuntu-latest
    name: Publish staging push
    steps:
      # Note the event_type and URL secrets passed so the action repository 
      # is allowed to post to the test repository.
      - run: |
          curl -i \
            -X POST \
            -H "Accept: application/vnd.github.v3+json" \
            -H "Authorization: token ${{ secrets.PUBLISH_PUSH_TOKEN }}" \
            https://api.github.com/repos/awalsh128/cache-apt-pkgs-action-ci/dispatches \
            -d '{"event_type":"staging_push"}'

Subscriber

Now on the subscriber (test repository), setup the tests and trigger to respond to the staging push.

Create Repository and Test

• Create awalsh128/cache-apt-pkgs-action-ci repository (ci = continuous integration) for testing.
• Create a workflow .github/workflows/tests.yml that subscribes to staging_push events and runs tests.

name: Staging Push Tests
on:
  # Allow for manual dispatches so we can test the workflow if needed.
  workflow_dispatch:
  repository_dispatch:
    # Name of the event that will by pubsub'd.
    types: [staging_push]

jobs:
  install:
    runs-on: ubuntu-latest
    name: Install and cache.
    steps:
      - uses: actions/checkout@v2
      # Note that the action uses the @staging version.
      # Allows testing to happen on that branch so it can get pulled into master once it passes.
      - uses: awalsh128/cache-apt-pkgs-action@staging
        with:
          packages: xdot rolldice

That’s it. Now anytime code is pushed to staging on your action repository, it will trigger tests on your test repository.

More Resources

• Github: Create Repository Dispatch Event
• Github: Create Personal Access Token
• Trigger Github Actions between Repositories

You will need to grant the application access to your repositories using their guide Integration with GitHub Apps.

You can then setup badges on your project site that show the status of your code quality.

If more customization is needed, an .lgtml.yml file can be created in the root of the repository per their instructions. You can also download their canonical template too to get started.

Here’s a search of GitHub to look at other example configuration files. For example in my project I needed a more recent version of CMake. This is what mine looks like so it is in the environment before LGTM performs its analysis.

extraction:
  cpp:
    after_prepare:
      - "mkdir custom_cmake"
      # Need later version of CMake than lgtm has.
      - "wget --quiet -O - https://cmake.org/files/v3.16/cmake-3.16.3-Linux-x86_64.tar.gz | tar --strip-components=1 -xz -C custom_cmake"
      - "export PATH=$(pwd)/custom_cmake/bin:${PATH}"
    index:
      build_command:
        - cd $LGTM_SRC
        - mkdir build; cd build
        - cmake .. -DCMAKE_BUILD_TYPE=RELWITHDEBINFO
        - make

Here’s another taken from GitHub that excludes specified directories from analysis.

path_classifiers:
  plugins:
    - plugins/

extraction:
  javascript:
    # https://lgtm.com/help/lgtm/javascript-extraction#customizing-index
    # The `index` step extracts information from the files in the codebase.
    index:
      # Specify a list of files and folders to exclude from extraction.
      exclude:
        - bower_components/
        - docs/assets/js/plugins/
        - plugins/

… or from another repository more simply.

extraction:
  javascript:
    index:
      filters:
        - exclude: "dist"

Here’s yet another repository. This one disables CMake and sets the configuration options before build.

extraction:
  cpp:
    prepare:
      packages: # to avoid confusion with libopenafs-dev which also provides a des.h
        - libssl-dev
    after_prepare: # make sure lgtm.com doesn't use CMake (which generates and runs tests)
      - rm -f CMakeLists.txt
      - ./buildconf
    configure: # enable as many optional features as possible
      command: ./configure --enable-ares --with-libssh2 --with-gssapi --with-librtmp --with-libmetalink --with-libmetalink

I think you get the point. Just give the app permission, customize as needed with the .lgtml.yml and setup your cute badges.

I had been wanting to make a library to express data transformation in a fluent way. The STL already has some functions for this. For example, if I wanted to transform a sequence and then filter based on a conditional I would do this.

std::vector<int> xs;
// Add int to xs.
std::transform(
  xs.begin(), xs.end(),
  [](auto x) { return ++x; });

std::vector<int> filtered;
filtered.reserve(xs.size());
std::copy_if(
  xs.begin(), xs.end(),
  std::back_inserter(filtered),
  [](auto x) { return x % 2 == 0; });

This is indeed a functional approach to expressing data transformations. It applies functions to data sets and without side effects (as long as you don’t cause any in the lambda). Although, there can also be a lot of boilerplate if you just wants the entire range of the container. Also, it is not always obvious from first glance what the inputs and outputs are to the function because it doesn’t follow the typical f(a,b) = c mathematical format. This doesn’t make it less functional but perhaps less readable.

The library that I put together uses a different approach that addresses some of these concerns.

#include <fluentcpp/query.h>

std::vector<int> xs;
// Add int to xs.
std::vector<int> filtered =
  fcpp::query(std::move(xs))
    .select([](auto x) { return ++x; })
    .where([](auto x) { return x % 2 == 0; });

This style is patterned after the .NET LINQ framework something I had become very accustomed to before programming in C++ full time.

Initial Release

Version 0.1 is now available on GitHub. As mentioned in the repository README.md, you can easily install the library with the instructions below.

• Go to the release you want to install.
• Download the fluentcpp-<tag>.tar.gz file.
• Decompress the file in the directory tar -xvzf fluentcpp-<tag>.tar.gz.
• Run the install command sudo ./install.sh.
• The library files are now installed on your system and can be used as in the examples.

Caveats

Since this is an initial release, there are some drawbacks to using this over the STL functional library or just older C++ constructs (e.g. for-loops).

• Memory semantics are strictly by reference and move. This is intentional to accomodate the strictest object constructor and assignment declarations (i.e. no copy and move).
• Strict memory semantics has implications for fundamental types where copy is more efficient.
• Performance has not been benchmarked yet so it is unknown how it performs against the alternatives.
• Static analysis hints can still seem obscure. While they depend on the STL concepts enforced, the wording can be confusing across the interface.

Feedback

I hope this proves useful to people and can become a wider community effort. It is primarily a proof of concept work and needs more to demonstrate it can be used in production code with similar performance to the status quo.

There are already some tutorials and examples of setting up a CMake project already but I work very much ny example and then deep dive later. It’s just how my brain works I guess. So let’s skim the waters.

Assumptions

This example uses the follow dev stack.

• CMake (obviously)
• C++ code.
• Catch2 testing framework (GitHub).

The file layout has subdirectory for source code and tests, each with their own CMake file and one at the root level.

CMakeLists.txt
tests
├── CMakeLists.txt
└── mylib_test.cpp
src
├── CMakeLists.txt
├── mylib.h
└── mylib.h

Configuration

Here is the whole configuration in its respective files.

/CMakeLists.txt

cmake_minimum_required(VERSION 3.16.3)

include(GNUInstallDirs)     # Make CMAKE_INSTALL_*DIR variables available.
set(CMAKE_CXX_STANDARD 20)  # Use standard C++20 for compilation.

project(mylib VERSION 0.1 DESCRIPTION "My library is a library that you can use as a library.")

# Make the src directory available for include lookup.
include_directories(src)

# Tell CMake to include the /src/CMakeLists.txt file in the build.
add_subdirectory(src)

# Must live in the top level file or tests won't be found.
include(CTest)  # Automatically invokes enable_testing()
# Tell CMake to include the /tests/CMakeLists.txt file in the build.
add_subdirectory(tests)

/src/CMakeLists.txt

message(STATUS "Building and installing library.")

# Add library to build.
#
# STATIC rolls all code (including related includes) into a single compiled object.
# SHARED rolls only mylib code into a single compiled object.
#
# https://stackoverflow.com/questions/2649334/difference-between-static-and-shared-libraries
#
# If you are using a different type of library than STATIC, make sure to look into how the target properties and 
# install will be different. For example https://cmake.org/cmake/help/latest/command/install.html
#
add_library(mylib STATIC mylib.h mylib.cpp)

set_target_properties(mylib PROPERTIES
  VERSION ${PROJECT_VERSION}  # Already set in the parent CMakeLists.txt via 'project'.
  PUBLIC_HEADER mylib.h       # Pulic headers you intend other projects to include.
  CXX_STANDARD_REQUIRED 20)   # Enforce the C++20 standard to compile against.

install(TARGETS mylib
  # Used for STATIC library headers.
  ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR} COMPONENT lib
  # Rolled code lives here.
  PUBLIC_HEADER DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/mylib COMPONENT dev)

/tests/CMakeLists.txt

include(FetchContent)

message(STATUS "Building tests.")

# Pull in the Catch2 framework.
FetchContent_Declare(
  Catch2
  GIT_REPOSITORY https://github.com/catchorg/Catch2.git
  GIT_TAG        v3.0.0-preview3)
FetchContent_MakeAvailable(Catch2)

# Most all test frameworks create a binary that then runs the tests.
# This is a simple expression of that and nothing special to tests themselves.
#
# In this framework, Catch2 provides a main function as executable entry point.
add_executable(query_tests mylib_test.cpp)

# Link the included libraries in for the tests.
target_link_libraries(my_tests PUBLIC Catch2 Catch2WithMain mylib)

add_test(NAME tests COMMAND query_tests)

More Resources

Here are some more examples to help you along.

• Dev Cafe: CMake Cookbook Examples
• GitHub: CMakeLists.txt Search
• CMake Documentation
  • add_library
  • add_test
  • install
  • set_target_properties

Here is an example using it to cache Doxygen dependencies.

name: Create Documentation
on: push
jobs:

  build_and_deploy_docs:
    runs-on: ubuntu-latest
    name: Build Doxygen documentation and deploy
    steps:
      - uses: actions/checkout@v2
      - uses: awalsh128/cache-apt-pkgs-action-action@v1
        with:
          packages: dia doxygen doxygen-doc doxygen-gui doxygen-latex graphviz mscgen

      - name: Build        
        run: |
          cmake -B $/build -DCMAKE_BUILD_TYPE=$      
          cmake --build $/build --config $

      - name: Deploy
        uses: JamesIves/github-pages-deploy-action@4.1.5
        with:
          branch: gh-pages
          folder: $/build/website

This action is a composition of actions/cache and the apt utility. For more information, see the repository README on GitHub.

void foo(size_t size) {
  if (size > this.current_size) {
    throw std::invalid_argument("Size cannot be greater than current size.");
  }
  ...
}

Not so bad really but I also wanted to create a dynamically created message.

void foo(size_t size)
  if (size > this.current_size) {
    std::stringstream text;
    text << "Size " << size << " cannot be greater than current size of " << this.current_size << ".";
    throw std::invalid_argument(text.str());
  }
  ...
}

We could shorten it…

void validate(bool condition) {
  if (condition) return;
  std::stringstream text;
  text << "Size " << size << " cannot be greater than current size of " << this.current_size << ".";
  throw std::invalid_argument(text.str());
}
void foo(size_t size)
  validate(size > this.current_size);
  ...
}

… but it isn’t very re-usable since the message is hardcoded.

C++20 offers the ability to use std::format.

void foo(size_t size)
  if (size > this.current_size) {
    throw std::invalid_argument(std::format("Size {} cannot be greater than current size of {}.", size, this.current_size));
  }
  ...
}

Pretty nice, although for people not on that standard they are left with the previous validation approach. There is a different way to do it however.

void foo(size_t size)
  invariant::eval(size > this.current_size) << 
    "Size " << size << " cannot be greater than current size of " << this.current_size << "."; 
  ...
}

Here is how it is implemented.

class invariant
{
 private:
  const bool condition_;
  std::stringstream message_;

  invariant(bool condition) : condition_(condition), message_() {}  
  invariant() = delete;
  invariant(const invariant &) = default;

 public:
  ~invariant() noexcept(false)
  {
    if (!condition_)
    {
      // Living dangerously, guaranteed not to live on the stack though.
      throw std::invalid_argument(message_.str());
    }
  }

  template <typename Text>
  friend invariant &&operator<<(invariant &&item, const Text &text)
  {
    item.message_ << text;
    return std::move(item);
  }

  static invariant eval(bool condition)
  {
    return invariant(condition, "");
  }
};

Not so bad maybe for pre C++20 but why have a throw in the destructor? This can be dangerous since it is called when the stack unwinds.

  ~invariant() noexcept(false)
  {
    if (!condition_)
    {
      // Living dangerously, guaranteed not to live on the stack though.
      throw std::invalid_argument(message_.str());
    }
  }

The key is to make sure it never gets on the stack in the first place. This means making it never becomes an lvalue. Herb Sutter discusses this strategy by ensuring that the object only ever can be an rvalue reference than cannot be copied or constructed. Here are the pieces that make this possible.

  invariant(bool condition) : condition_(condition), message_() {}  
  invariant() = delete;
  invariant(const invariant &) = default;

Lastly is getting the dynamic message input.

  template <typename Text>
  friend invariant &&operator<<(invariant &&item, const Text &text)
  {
    item.message_ << text;
    return std::move(item);
  }

Note how an rvalue reference is passed in and out. This ensures that it is never copied while also modifying the object’s message state.

This exercise was fun and informative for myself but can be quite dangerous if not understood well and modified without such knowledge. There is also a safer alternative (well why didn’t you say so?!) using a variadic template via parameter pack. You can find the answers to string concatenation on this StackOverflow post. An adaptation from the top answer would look like.

template< typename ...Args>
void invariant(bool condition, const Args&... args)
{
  if (condition) return;
  std::stringstream message;
  using List= int[];
  (void)List{0, ((void)(message << args), 0 ) ...};
  throw std::invalid_argument(message.str());   
}

This post is a simplified approach to helping C# and Java devs get an introductory understanding of C++ memory semantics so they can confidently create signatures correctly and use it as a stepping stone for more advances techniques. In the following post we will compare C++ against C# for simplicity so we don’t have to constantly bring up both C# and Java.

The layout of this post will follow:

• An example of a non-idiomatic approach to C++ and show why it is inefficient.
• Define the storage durations so that we can understand how C++ handles objects in memory.
• Define the types used to communicate the memory semantics involved.
• Walk through examples, styles and use of the different types described.

The Literal Approach (AKA Wrong Approach)

Let’s start with a common misconception that memory semantics are interchageable with all other languages. Memory semantics and how the language approaches it are important. We can’t just take our understanding from C# and literally apply it to C++.

For example:

class Object {
  public int x;
}
void Foo(Object o);

var o = new Object();
Foo(o);

Could literally be transformed into:

class Object {
 public:
  int x;
};

void Foo(Object* o);

void Bar() {
  auto* o = new Object();
  Foo(o);
}

This is a terrible idea, don’t do this. The main mistake is confusing C# class memory semantics with C++’s.

• You just can’t change the C# reference to a C++ pointer and be done. This go against the C++ philosophy to prefer the stack. Especially since this is an option not available in C# due to the division between value and reference types
• Object is very small (about 8 bytes) and is best allocated on the stack since it is faster (see gotw/009).
• The scope of the Object instance isn’t well defined but if we assume it is short lived there is no need for dynamic allocation.

Here is a better way to do it:

Object o;
FooReadOnly(o); // Simple and fast copy.
FooWrite(&o);   // Simple and fast copy of stack address pointer.

Storage Duration

As noted, there is a strong preference to allocate on the stack since it is much faster for small objects. In C# it is generally assumed that fundamental types are allocated on the stack and reference types on the heap. This is optional in the C++ language as the developer can decide to allocate classes on the stack or on the heap. Therefore it is helpful for the new developer to understand how storage duration / lifetime works in C++.

Going forward we will refer to allocation in terms of the storage duration. Concepts like stack and heap are implementation concerns. While useful when first learning these durations it is better to speak in terms of the traits of these durations than the lower level understanding. For example stack storage is fast but we might as well just say automatic storage is fast instead.

Automatic

The object lifetime is tied to the code block it is allocated in and is deallocated at the end of the block. We should aim to use this storage duration whenever possible. As noted previously, it is faster (see gotw/009)

void Foo() {
  int x = 1;  // Object is allocated.
  // ...
}             // Object is deallocated.

Dynamic

The object lifetime is tied to the declaration of an instance and the explicit deallocation of the instance (see examples).

void Foo(Object* o) {
  // ...
}

void Bar() {
  auto* o = new Object();
  Foo(o.get());
  delete o;
}

Thread

The object lifetime is tied to the thread allocation and deallocation. In the example below we will not consider race conditions.

#include <threads>

// Object is statically allocated. See Static section below for more information.
thread_local int x = 1;

void Foo(int y) {
  // x is allocated on the thread with original declared value for every new thread and 
  // incremented.
  x += y;
}

void Bar() {
  std::thread t1(Foo, 2);   // Thread instance of x becomes 3 inside Foo.
  std::thread t2(Foo, 3);   // Thread instance of x becomes 4 inside Foo.

  t1.join();  // Thread instance of x is deallocated once thread joins and deallocates.
  t2.join();
}

Static

The object lifetime is tied to that of the program. Note the thread_local declaration in the section above has static storage duration. Try to be sparing with the size and use of these objects since they have the largest lifetime.

static int x = 1; // x is allocated at program start and deallocated at program end.

void Foo() {
  ++x;
}

Foo();  // x is incremented; x = 2.
Foo();  // x is incremented; x = 3.

An example of static local variables.

void Foo() {
  static int y = 1;
  ++y;
}

Foo();  // y is initialized; y = 1. From now on, the declaration is skipped.
Foo();  // y declaration is skipped and incremented; y = 2;
Foo();  // y declaration is skipped and incremented; y = 3;

Types

C# has a single type taxonomy where everything is derived / inherited from Object (example Int64). This taxonomy allows a common interface of methods available to all child objects like Equals and ToString. This is not the case for C++. It uses duck typing to resolve an operations validity at compile time. If the operands have the needed operation (e.g. equals) then it is considered valid.

Fundamental Types

C++ fundamental types are the same types as found in C# value types.

Objects

Objects also encompass fundamental types as well as classes and structs. Without any additional modifiers, objects are automatically allocated.

// Make a automatic copy and use inside Foo.
void Foo(int x);

// In terms of memory it is the same as Foo(int x) since x will be passed as a copy.
// The only reason to keep as const would be to avoid modification inside the code block. 
// IMO, this is indicative of a leaky interface since it is implementation specific.
void Foo(const int x) {
  x = 2;            // ERROR: Cannot change a constant value.
  int y = x;        // Make a copy of x and assign to y; x = 1, y = 1.
  const int z = x;  // Make a copy of x and assign to z upon its initialization.
}

References & Pointers

void Foo() {
  int x = 1;
  int y = x;  // Make a copy of x and assign to y; x = 1, y = 1

  int* z = &x;
  *z = 2;     // Reference x from z; x = 2

  const int a = 1;
  int* b = &a;  // ERROR: Cannot get a reference from a const value.
}

void Foo(int& x) {
  x = 2;
}
int x = 1;
Foo(x);   // x = 2

// Equivalent function but using a pointer.
void Quux(int* x) {
  *x = 2;
}
int x = 1;
Quux(&x); // x is now 2;

Sharing a read only reference.

class LargeObject {
 public:
  explicit LargeObject(/*...*/) : /*...*/{};

  int x;
  // Lots of members of large size.
};

void Foo(const LargeObject& o) {
  // Read only and use data from o.
}

void Bar() {
  LargeObject o(...);
  Foo(o);
}

Note that LargeObject is specified for the sake of needing dynamic allocation. This can be due to: having a container with an unspecified size, lifetime is managed in threads, or is in a larger scope than the immediate function and dependent functions.

Smart Pointers

Resource Acquisition Is Initialization (RAII) is a language idiom that essentially says that object creation is undone by destruction. In C++ this means that any object construction on the stack is also destructed when the object falls out of scope. Smart pointers are simply a wrapper around a pointer. It is allocated when the smart pointer is allocated and deallocated when the smart pointer is deallocated (see Resource Acquisition Is Initialization (RAII). This gets rid of the need to explicitely call a delete and ties the resource lifetime to that of the object wrapping it.

Smart pointers have most of the common operations you would expect like *x and x->y.

A crude way to represent this, ignoring operations, would be:

template <class T>
struct simple_smart_pointer {
 public:
  simple_smart_pointer() = delete;
  // Don't allow copies or multiple assignments.
  // There should only ever be a single instance.
  simple_smart_pointer(const simple_smart_pointer&) = delete;
  simple_smart_pointer& operator=(const simple_smart_pointer&) = delete;

  template <class... TArgs>
  explicit simple_smart_pointer(...args)  // Pass variadic args.
  {
    value_ = new T(args...);
  }

  ~simple_smart_pointer()
  {
    delete value_;
  }

 private:
  T* value_;
};

Unique Pointer

An example of using a type of non-shared smart pointer called std::unique_ptr.

#include <memory>

class LargeObject {
 public:
  explicit LargeObject(/*...*/) : /* initialize members */ {};

  int x;
  // Lots of members of large size.
};

void Foo(std::unique_ptr<LargeObect> o) {
  // Take ownership and process o.
}

void Bar() {
  // Automatically allocate std::unique_ptr and dynamically allocate the wrapped value.
  auto o = std::make_unique<LargeObject>(/*...*/);
  // ...
  Foo(std::move(o));
}

The std::move function is used to transfer the resource from Bar scope to Foo. This means that ownership can be passed to other scopes and objects. Although once moved, it can no longer be used in that same scope.

#include <memory>

void Baz() {
  std::unique_ptr<LargeObject> o(/*...*/);
  Foo(std::move(o));  
  int y = o->x;   // ERROR: Undefined behavior.
}

#include <memory>

void Foo() {
  std::unique_ptr<LargeObject> o(/*...*/);
  LongLivedProcessing(std::move(o));
}

So that in context of Foo it now owns the std::unique_ptr and its underlying destructions of the dynamically allocated LargeObject. Once it falls out of scope, the object is dynamically deallocated. This data type is important when applying to the concept of std::unique_ptr because it helps transfer ownership down stack.

void Foo(std::unique_ptr<LargeObject> o) {
  // Acts on o->x;
} // o falls out of scope and it is dynamically destructed.

Shared Pointer

Think of shared pointer as the simple_smart_pointer but with the copy operation allowed and holding an internal reference count.

A crude way to represent this, ignoring operations, would be:

template <class T>
struct simple_shared_pointer {
 public:
  simple_shared_pointer() = delete;
  simple_shared_pointer(const simple_smart_pointer& p) {    
    // Increase reference count now that we have another automatically allocated instance.
    *counter_ = ++(*p.counter_);
    value_ = p.value_;
  }
  simple_shared_pointer& operator=(const simple_smart_pointer& p) {
    // Increase reference count now that we have another automatically allocated instance.
    *counter_ = ++(*p.counter_);
    value_ = p.value_;
  }

  template <class... TArgs>
  explicit simple_shared_pointer(...args) // Pass variadic args.
  {
    value_ = new T(args...);
  }

  ~simple_shared_pointer()
  {
    // Decrease reference count now that instance is automatically deallocated.
    int new_counter = --(*counter_);
    // If this is the last instance, dynamically deallocate the value.
    if (new_counter == 0) delete value_;
  }

 private:
  int* counter_;  // Reference counter.
  T* value_;      // Shared dynamically allocated value.
};

An example of using a type of shared smart pointer called std::shared_ptr.

// Construction and copy operations.
void Bar(std::unique_ptr<LargeObject> o) {
  std::shared_ptr<LargeObject> ctor_shared = std::make_unique<LargeObject>(/*...*/);
  std::shared_ptr<LargeObject> moved_shared = std::move(o);   // moved_shared takes ownership
  std::shared_ptr<LargeObject> copied_shared = moved_shared;  // shared pointer reference count is 2
}

void Bar(std::shared_ptr<LargeObject> o) {
  // Do stuff with o all in scope. No passing to objects that outlive Bar.  
} // Decrement reference count as std::shared_ptr is destructed.

void Baz() { 
  auto o = std::make_shared<LargeObject>(/*...*/); // Reference count starts at 1.
  Bar(o); // Increment reference count to 2 as std::shared_ptr is copied.
  Bar(o); // Increment reference count to 3 as std::shared_ptr is copied.
} // o falls out of scope

Weak Pointer

There is a similar concept in C# (i.e. WeakReference) that corresponds to (std::weak_ptr in C++. It is constructed from a std::shared_ptr and [de]allocated dynamically using reference count. If the std::shared_ptr is deallocated then the std::weak_ptr will return null.

void Foo() {
  std::shared_ptr<int> shared = std::make_shared<int>(1);
  std::weak_ptr<int> weak = shared;

  // Creates a std::shared_ptr pointing to std::weak_ptr with reference count 1
  std::shared_ptr<int> shared1 = weak.lock();
  std::shared_ptr<int> shared2 = weak.lock(); // std::shared_ptr reference count 2
  std::shared_ptr<int> shared3 = weak.lock(); // std::shared_ptr reference count 3

  shared3.reset();  // std::shared_ptr reference count 2
  shared2.reset();  // std::shared_ptr reference count 1

  weak.expired();   // Check that there are still std::shared_ptr's in memory.
  shared.reset();   // Only allowed if is the last std:shared_ptr
  // weak is expired and shared is null
}  

Examples

Below are some different ways to think about how to provide your signatures and what they convey.

Inputs

void Foo(int x);  // Preferred for fundamental types as noted earlier.

void Foo(const LargeObject& o); // Read-only reference to o.

void Foo(LargeObject& o); // Read and write reference to o.

void Foo(std::unique_ptr<LargeObject> o); // Transfer ownership to Foo block.

// Copy pointer and allow read and write operations.
// Could be owned by caller or being passed to caller.
void Foo(LargeObject* o);

Outputs

Outputs as Return Value

class Foo;

int Bar();  // Return a copy of the function scoped return.

const int Bar(); // Return a read-only copy of the function scoped return.

// Return a reference to LargeObject held by Foo.
// Foo must outlive caller.
LargeObject& Foo::Bar();

// Return a read-only reference to LargeObject held by Foo.
// Foo must outlive caller.
const LargeObject& Foo::Bar();

std::unique_ptr<LargeObject> Bar(); // Transfer ownership to calling block.

// Return a copy of a pointer.
// Could be owned by Foo or being passed to caller.
LargeObject* Foo::Bar();

Outputs as Arguments

void Foo(int& x); // Read and write reference to x.

void Foo(int* x); // Read and write of x from pointer.

Readability

In functional programming there is a concept of referential transparency or pure functions, which forbids side effects. This makes programs easier to reason about because you don’t need to look at the implementation to see what they do. For example consider the signature:

void DoStuff(int x, int* y);

We can see that x is an input but y may or may not be an input or an output or both. As far as we know y could point to an unpopulated object that needs to be filled, or it could just be an input that is a pointer, or it could be an input transferring control of the pointer to something else (e.g. another thread or static member). Let’s narrow this and try to eliminate the ambiguity assuming that the input is a read and write value.

void DoStuff(int x, int& y);

Okay now we narrowed down the definition to allow for a variable that can be read from and written to. If we wanted to make it just a read only reference, we could const qualify it. Although lets assume it is read and write.

void DoStuff(int x, int y);

While it accomplishes the same thing as the signature before, it is now very clear that the value is both read and written / computed. The signature now communicates this very cleanly and in a transparent way. The same idea can be applied to multiple outputs too using std::tuple.

std::tuple<int, int> DoStuff(int x, int y);

Although what do we do about LargeObject if we wanted to make a minor mutation, then return a copy of LargeObject along with the mutation?

LargeObject DoStuff(const LargeObject& o);

While this works from a functional point of view, it has horrible performance implications. How about:

LargeObject& DoStuff(const LargeObject& o) { return o; }   // Illegal

This doesn’t work because you can’t make a const qualified input and be able to return a read/write reference to it. Although this will work:

LargeObject& DoStuff(LargeObject& o);

Isn’t this the same thing as just returning a void? Yes, and maybe it is best just to do so since & without const communicates that it is possibly read and definitely written. In these cases, it is hard to express the semantics cleanly due to performance.

Dependency Injection (DI) Container

DI containers can hold all the components necessary to maintain a service. If created at the code entry point it is best to share by reference in a top don way.

class Component1 {
 public:
  explicit Component1(bool production) : production_(production) {}
  // ...
 private:
  // ...
  bool production_;
};

class Component2 {
 public:
  explicit Component2(bool production) : production_(production) {}
  // ...
 private:
  // ...
  bool production_;
};

class Container {
 public:
  // Consume only unique pointers since no other object should hold the dependencies
  explicit Container(
    std::unique_ptr<Component1> component1, 
    std::unique_ptr<Component2> component2)
    // Release ownership to the new Container.
    : component1_(std::move(component1)), 
      component2_(std::move(component2)) {}

  static Container CreateNonProd() {    
    return Container(
      std::make_unique<Component1>(/*production=*/false),
      std::make_unique<Component2>(/*production=*/false));
  }
  static Container CreateProd() {    
    return Container(
      std::make_unique<Component1>(/*production=*/true),
      std::make_unique<Component2>(/*production=*/true));
  }

  // Never expose the pointer, just the value pointed to.
  Component1& component1() { return *component1_; }
  Component2& component2() { return *component2_; }

 private:
  std::unique_ptr<Component1> component1_;
  std::unique_ptr<Component2> component2_;
};

void DoStuff(Component1& component) { /*...*/ }

void main() {
  auto prod_container = Container::CreateProd();
  DoStuff(prod_container.component1());
}

If used in a separate thread or allocation is very large, prefer std::shared_ptr instead. Below is a modification of the previous class layout.

class Container {
 public:
  // Consume only unique pointers since no other object should hold the dependencies
  explicit Container(
    std::unique_ptr<Component1> component1, 
    std::unique_ptr<Component2> component2)
    // Release ownership to the shared pointers.
    : component1_(std::move(component1)), 
      component2_(std::move(component2)) {}

  // ...

  // Never expose the pointer, just the value pointed to.
  std::shared_ptr<Component1> component1() { return component1_; }
  std::shared_ptr<Component2> component2() { return component2_; }

 private:
  std::shared_ptr<Component1> component1_;
  std::shared_ptr<Component2> component2_;
};

Rules of Thumb

• Copies can be a faster operation for small objects.
• Only use smart pointers when the object is very large or needs to be shared outside the scope it was created in.
• Avoid raw pointers whenever possible.
• Prefer references over raw or smart pointers where available.

Conclusion

Hopefully this gives you a sense now how storage works and how to communicate memory semantics in the best and most performant way possible. Please feel free to leave comments on errata or your own thoughts.