C# 7.0 Pocket Reference: Instant Help for C# 7.0 Programmers

Imagine moving into a house where the walls like literally shift and reorganize themselves depending on what kind of furniture you decide to bring inside.

Right, just totally dynamic yea yeah, Like.

You bring in a tiny chair in the room shrinks to hold it perfectly. You bring in a massive sofa, the floor plan just completely rewires itself to accommodate it.

And a team of invisible workers just stands by to haul it away the second you stop using it.

Exactly that dynamic, invisible architecture is basically the reality of modern software. And today we are jumping into a deep dive on the c sharp seven point zero pocket reference by Joseph Albahari and Ben Albahari.

It's a fantastic resource, it really is.

We're going to figure out exactly how this language pulls off this impossible high wire act. I mean, giving developers raw, bare metal computational power without making them manage the messy, unforgiving physics of computer memory.

It is a really delicate balance. Sea sharp is well. It's a language built from the ground up to offer the performance of older low level languages while simultaneously providing an incredible safety net for your productivity. It's platform neutral, so it runs practically anywhere, but it was really engineered to sing when paired with the dot net framework. And the text we're looking at today is this dense, insightful roadmap of how that safety net actually functions under the hood.

And our mission for this deep dive isn't to just read off syntax or build a glossar. No, that would be boring totally. We want to understand the underlying DNA of this system. How does it physically store your data, what happens when that data.

Misbehaves or when it doesn't even exist right?

And how does it let developers express dizzyingly complex logic without losing their minds. And I want to emphasize right up front, even if you listening right now have never written a single line of code in your life. Understanding how a system like this organizes information, it can fundamentally change how you approach problem solving. It just trains you to think about structure.

And structure is exactly where we have to start, because before you can manipulate data or build an application, you have to understand how the system physically stores its foundation.

Okay, let's unpack this. We're talking about types.

Right, Yes, types. You can think of a type as a blueprint for a value. The language comes with pre defined types like an integer, which is just a whole number, or a booleon which is a simple true or false switch.

But you can build your own too, Exactly, you.

Can build custom types like a unit converter or a panda class, which basically bundle related data and behaviors together into one neat package.

So we have our blueprints. But the authors highlight this massive architectural divide and how c sharp actually builds those blueprints in memory.

The value types versus reference types divide.

Yeah, and this basically dictates the entire physical reality of the program.

It is arguably the single most critical distinction in the language, and it comes down to two very different physical locations in your computer's memory, the stack and the heap.

The stack in the heap.

Right, value types live on the stack. Reference types live on the heap. The text uses a custom type called point, representing an X and y coordinate on a graph to demonstrate this.

Okay, so how does that work.

Well, if you define your point blueprint as a struct the language treats it as a value type. When you create a variable called P one. The actual X and Y numbers are physically stuffed right inside P one on the stack.

Oh wow.

And if you then write a line of code that says P two equals P one, the system physically duplicates those numbers. It carves out a brand new independent chunk of memory for P two.

Right, So I've then changed P one's ex coordinate to be the number nine. P two's ex coordinate stays exactly.

What it was precisely.

They're completely isolated. It's like, okay, It's like having a super secret chocolate chip cookie recipe written on a piece of paper and I hand you a photocopy of it.

I like that analogy.

You can take a sharpie, cross out the chocolate chips and write in raisins, which, by the way, would be a total crime against baking. But my original recipe is totally safe. You're Edits don't affect my paper.

What's fascinating here is that the beauty of that photocopy approach is the system doesn't have to manage it long term. Once the function you're running finishes, your photocopy is just thrown in.

The trash, just tossed out.

Yeah, that is the nature of the stack. It operates like a literal stack of cafeteria trays. Variables are piled on top of each other as they are needed, and as soon as a task is done, the top crazer just popped off and instantly destroyed. So fast, lightning fast. But it is strictly scoped and small. You can't put everything on the stack, which.

Brings us to the other side of the divide, the heap. What if we take that exact same point code, but we change the blueprint from a struct to a class.

A class creates a reference type. Now when you create P one, the actual heavy data that X and y coordinates is created over in the heat, and the heap is like it's like a sprawling, unstructured warehouse for complex objects that need to live for a long time. The variable P one sitting on the doesn't hold the numbers anymore. It just holds a pointer, like a reference, telling the computer where to find the data in the warehouse.

So, following my analogy, a reference type isn't a photocopy. It's like I shared the link to a live Google doc with you. We are both looking at the exact same document.

Yes, and if you say P two equals P one. Now the system doesn't copy the data, it just copies the link. Oh wow, both variables point to the exact same object in the warehouse. If you change P one's ex coordinate to nine and then ask the computer what P two's ex coordinate is, it will also be nine. They are intrinsically linked.

But wait, if the stack just throws away its trays when it's done, what happens to all the heavy data sitting out in the heap warehouse? Doesn't it just pile up?

That is where c Sharp's invisible workers come in. The heap requires a cleanup crew known as the garbage collector.

The famous garbage collector.

Exactly, It constantly runs in the background tracing all the active links from the stack into the keep. The moment it realizes that a piece of data in the warehouse has absolutely no links pointing to it anymore, meaning no part of your program can even reach it, the garbage

So we've mapped out how C sharp physically stores its foundation, balancing the fast stack with the garbage collected heap. But a pile of data isn't always perfectly well behaved.

It's not at all.

Let's look at what happens when the actual information inside these structures gets weird. I was reading the section on numeric types, and the text gives this mathematical example that completely broke my brain for a second. Floating point math.

Ah, Yes, the infamous divide between the double type and the decimal type. It traps developers constantly.

It's wild. The authors show this specific equation. You take zero point one multiplied by ten, which is exactly one track that result from one one mius one. The answer universally should.

Be zero, right basic math.

But in C sharp, if you use the standard double type for this, the answer it spits out is negative one point four to nine, followed by an e in andh eight. It's this microscopic, weird negative fraction. Why does a basic subtraction equation completely fail to equal zero?

It's entirely about how the physical processor of your computer understands fractions. The double type represents numbers in base two, it uses binary. Now think about our human base ten system. You cannot perfectly represent the fraction one third in base ten. It becomes zero point three to three to three, repeating into infinity. You have to chop it off eventually. Right, The exact same thing happens to the computer in base two binary when it tries to represent the fraction zero

Oh so it's chopping off the end of the binary decimal, and when you do math with it, those microscopic chopped off in precisions compound, leaving you with that weird negative exponential instead of a clean zero.

Precisely, the double type sacrifices absolute precision to fit into a base two.

Format, which means if I am writing, say, banking software, and I use double to calculate dally interest rates, over a few years, I'm going to be losing or inventing fractions of panties everywhere.

The accounting department would audit you into oblivion exactly. So how do we fix it for financial calculations? The text emphasizes you must use the decimal type. The decimal type operates in base ten. It stores the number as a massive integer and just remembers exactly where the decimal point goes. So it's super precise.

Very it has twenty eight to twenty nine significant figures of absolute precision. Zero point one is stored perfectly a zero point one.

Wait a second. If decimal gives us perfect human math without the compounding rounding errors, why do we even keep double around. Aren't we just asking for accounting bugs by leaving an imprecise math type in the language. Why not just use decimal for absolutely everything?

If we connect this to the bigger picture, it's because of the raw hardware physics. Your computer's processor has a dedicated floating point unit physically wired to crunch base two numbers at blinding speed.

Oh so with the speed thing exactly.

The double type runs natively on that hardware. That decimal type is non native. It's a software construct. The processor has to do a massive amount of extra simulated work to process base ten math. Because of that physical reality, double is roughly ten times faster to compute than decimal. Okay, that makes perfect sense. If I'm programming a three D physics engine and calculating the spatial coordinates of fifty thousand

Double is for science graphics, and raw speed decimal is for human made values like currency, where precision is non negotiable.

So that's the quirk of imprecise data. But what about when data just doesn't exist at all? The concept of.

Null, that's a huge one.

The book explains that value types the photocopies on the sack can't ordinarily be null. They have to hold a value, even if it's just a zero. But reference types, those links to the Google doc can absolutely be null, meaning the pointer is pointing at empty.

Space, and this leads to the infamous null reference exception. To a developer, those three words are terrifying. It is arguably the most common way software crashes.

Let's visualize the mechanism of that crash for a second. To a non programmer, why does a pointer pointing to nothing cause the whole system to explode? It's like if you tell the computer to go read the Google doc and it follows the link only to find an empty void. It just panics, right.

It doesn't know what to do next, so.

The program simply drops dead.

That panic is exactly what happens. This system attempts an operation on memory that doesn't exist, and the only safe response is to halt execution entirely. But to combat this, c Sharp introduced incredibly elegant syntax to safely check for that void with without crashing.

The null conditional operator, or, as it's affectionately known, the Elvis operator.

Yes because the question mark and the dot next to each other looks slightly like Elvis Presley's swooping hair in an eye.

I know, you literally can't unsee it once you notice it, But functionally, how does elvis save the program from panicking.

Let's say you want to extract a text string from a variable, so you write the command to get that string. If the variable is null, boom, the program crashes. But if you insert the Elvis operator the question mark and the dot right before the command, it short circuits the panic. It essentially whispers to the compiler, hey, if this variable happens to be a void, just stop right here. Don't even try to read the text, just hand me back a null and let's quietly move.

On, no crash, and you can seamlessly pair it with another tool. Right. Yeah, the null coalescing operator, which is just two question marks in a row exactly.

It acts like a backup generator.

So you try to read the text with Elvis and then use the two question marks to say if you hit a void, just substance too the word unknown instead. It condenses what used to be a clunky multiline error checking routine into one sleek, panic free line of code.

It removes the friction of defensive programming, and C sharp seven took that friction removal further with tuples, which solved the opposite problem returning too much data.

Oh tuples right. Historically, if a single function needed to calculate and hand back two distinct things, say a person's name and their age, you had to jump through ridiculous hoops.

It was a meth You either had to.

Build a completely separate, dummy blueprint class just to hold those two variables together, or you had to use these clunky out parameters that made the code super difficult to read.

Tuples bypass all of that. Backed by a lightweight value type called value tuple. They let you elegantly bundle values together on the fly. You literally just put the name Bob and his age twenty three in parentheses and assign it to a variable. The compiler handles the underlying structure automatically, and.

The deconstruction syntax is even better. You can call that function instantly split the tupple back into individual usable variable. Yes, the deconstructor you just write parentheses the word string and the variable name, followed by the word end in the variable age. Boom, you have two local variables ready to go without ever defining a custom class. It keeps the works based incredibly clean.

So we have our structural foundation. We've navigated the mathematical quirks, and we've tamed the voids with graceful operators. But a program isn't just a static warehouse of data. We need action.

We need logic which moves us right into how c sharp passes behaviors around. We know how to put the number five into a variable, but how do we put an actual action like a math calculation into a variable.

That is the domain of delegates. A delegate is fundamentally a type that represents a reference to a method. Think of it as a pluggable protocol.

Yeah, a protocol, right.

It defines exactly what a method's inputs and outputs should look like. The authors use a transformer delegate as an example. If you define a protocol that takes an integer, all alters it, and returns an integer, you can assign any actual method that matches that fingerprint to a delegate variable.

So what does this all mean? The immediate question for anyone looking at this is why not just call the method directly? Why bother creating a middleman?

Because the middleman allows for brilliant decoupling. If you write a generic engine that loops through a massive list of numbers and applies some transformation to each one, that engine shouldn't need to know what the transformation actually is. Oh, it just does the work, right, It just needs a delegate at runtime. You can plug in a method that squares the numbers, or a completely different method that has them. The delegate makes your architecture modular.

And the language evolved a wonderfully concise way to write those plug in methods lambda expressions.

They are everywhere now.

Instead of writing out a whole separate named method just to square number, you write it in line. You literally just write the variable say x an arrow and then x times x.

The compiler reads the arrow as goes.

To baraily minimalist. But this minimalism hides what I found to be the most fascinating trap in the entire book, the closure trap.

Oh yes, this is a spectacular aha moment for understanding compiler architecture.

Let's lay out the scenario from the text. We build a simple four loop. The loop uses an integer variable eye that starts at zero, goes to one, then goes to two, and finishes a standard loop right and inside that loop, we create a tiny lamba expression that just prints the value of ee. We stash those three lambdas in a array to be executed later on. Common sense dictates that the first lamb to capture the zero, the second capture of the one, and the third capture of

Because of the physical reality of what a lamba actually captures. It doesn't take a snapshot of the value of the variable at the exact millisecond. The lambda is created.

Wait it doesn't.

No, it captures a reference to the variable itself. It locks onto the memory location. By the time the four loop finishes spinning, that single shared variable Eye has been incremented up to three.

Oh wow.

So later, when those three lamb does finally wake up and execute, they all look at that single shared memory location and they all see the number three.

The book points out, the fix is to create a brand new local variable inside the loops brackets, copy the value of eye into it, and have the lamb to capture that new inner variable exactly.

Since a brand new physical variable is created on the stack, for every single spin of the loop, each lambda gets its own isolated box to look at. That establishes true isolation for each closure.

Well, wait, I have to puzzle through the physics of this. If a lambda captures an outer variable and we stash that lambda away to be run ten minutes later, doesn't that artificially extend the life of that variable.

Yes, it does.

Like our loop variable was a value type on the stack, it was supposed to be thrown in the trash the millisecond the loop finished. If the lamb is still referencing it ten minutes later, how does it survive? Isn't this just a massive memory leak waiting to happen?

This raises an important question, and your intuition is pointing directly at the compiler's most complex magic trick. How does a short lived stack variable survive? It survives because the compiler secretly rewrites your code behind your back. Wait, really, yes, When it detects that a lambda is capturing a local variable, it intercepts that variable. It takes it off the fast temporary stack and hoists it into a hidden auto generated class over in the heap warehouse.

That is wild. It quietly transforms a temporary value type into a long lived reference type just to keep it alive for the lambda.

It forcibly extends the variable's lifetime to match the life span of the delegate. It will eventually be cleaned up by the garbage collector. But it perfectly illustrates the hitting cost of syntactic.

Sugar because it looks so simple.

Lambdas look wonderfully simple, just an arrow and some math, but they can trigger complex heap allocations and garbage collection pressure. This is precisely why c sharp seven introduce local methods. The ability to define a fully named method and nested inside another method.

So that's the alternative.

Right. Local methods can access those outer variables without forcing the compiler to generate hidden heap classes, giving you a highly efficient alternative when you don't actually need the pluggable nature of a delegate.

The languid is literally reorganizing your memory management to accommodate your logic, but you have to understand the trick so you don't abuse it, which brings us to the ultimate synthesis of everything we've discussed today, taking these floating behaviors and applying them to massive data sets. Section four iterators and LANQ.

This is where c Sharp's design philosophy achieves its greatest leverage. It begins with iterators. If you need to generate a massive sequence of numbers, say the Fibonacci sequence, you don't have to calculate a million numbers, load them all into a giant array in memory, and hand the heavier ray back. You can write an iterator method using the yield return statement.

And the yield return statement is like another compiler magic trick. The book explains that it transforms your method into a state machine.

Exactly a state machine.

The code doesn't just run top to bottom and finish. It runs until it hits yield, return hands the calculated value back to the caller, and then it just freezes. It pauses its entire state in memory. It doesn't wake up or calculate the next number until the caller specifically sends a command.

Called move next, and that precise, paused state machine is the foundation of LANQ language Integrated Query. L and Q allows you to query collections of data in memory using a syntax that reads very much like database SQL.

Use standard operators, right yeah.

Like where to filter out bad data, select to transform what's left, and order by to sort the final results.

Here's where it gets really interesting, though. The absolute superpower of l and Q is deferred execution or lazy evaluations.

It's brilliant.

The authors provide this amazing example. You have a list of numbers. You write a complex LNQ query to filter and sort that list, but you haven't actually asked to see the results yet. You just define the instructions. Then you sneak an extra element into the original list. You add the number two. After that you run a forged loop to actually look at the results of your query, and that brand new number two is fully processed and included in the output.

Because writing the query and executing the query are two fundamentally disconnected events, the query is just a blueprint of intent. It refuses to actually touch the data until the absolute last possible millisecond when you force it to enumerate.

I love visualizing deferred execution like a conveyor belt at a highly efficient custom sandwich shop.

Oh I like this.

Yeah. You walk in and you tell the first worker, I only want the wheat bread. That's your wear filter. You tell the next worker toast it. That's your select transformation. You tell the last worker put the biggest sandwiches first. That's your order buy. You have built this intricate logic pipeline, but the workers haven't sliced a single piece of bread yet.

The efficiency of that decoupling is staggering. If you construct an l in Q query to process a database of ten million records, but your user interface only ever asks to display the first three results. The system only processes three records.

It doesn't do the rest.

No, it doesn't waste precious CPU cycles and heap memory, rendering a massive ten million item list that you will never look at. It pulls data through the pipeline purely on demand.

It is incredibly elegant, and it really brings this entire exploration full circle. I mean, we started at the bedrock physical reality of memory, the strict cafeteria trays of the stack, and the sprawling warehouse of the heat.

We covered a lot of ground.

We really did. We saw how the physics of base two processors create math quirks that we have to actively manage with types like decimal. We untangled the logic traps of closures, revealing how the compiler secretly hoists variables to keep our lambdas alive. And finally we arrived at the lazy, highly efficient conveyor belts of LNQ, which let us express massive data operations with just a few intuitive lines of code, completely abstracted away from the raw memory underneath.

It is a profound journey from the bare metal to the high level abstract and to.

You listening right now, Whether you spend your day's writing code or you're just deeply curious about the digital infrastructure of our world. Mastering these concepts is powerful. Knowing exactly why a simple subtraction equation fails to equal zero, or knowing the mechanism of how a system can freeze its state and delay doing work until the exact second it's needed.

I want to leave you with one final, slightly provocative thought to chew on. We have spent this entire deep dive examining how s sharp goes to extraordinary lengths to protect you right. It offers strict type safety, It manages your memory with the garbage collector, It diffuses null reference panics with elvis operators, and it saves resources with lazy execution. But tucked away in the text is a brief mention of an advanced topic unsafe code and pointer.

Oh yeah, the unsafe zone, yes.

Se sharp actually allows you, if you explicitly choose to do so, to write a block of code marked is unsafe. Inside that block, the safety nets are ripped away, the garbage collector steps back. You are permitted to use raw direct memory pointers exactly as you would in an unforgiving lower level language like C plus plus. So the question is if language architects spend decades designing these brilliant safeguards to maximize our productivity, what happens when you actively choose

That is a phenomenal question. The shifting walls of the house we talked about at the beginning, they only protect you as long as you stay inside them. The second you step out into the unsafe zone, the blueprints are entirely yours, and you better hope your math is perfect. Thank you all for taking this GEEP dive with us today. Keep asking questions, keep looking under the hood, and we will see you next time,