.Net entry points

A deep dive into the true entry point of a .Net program. A lot of this I knew from reading too much CLR via C# (another great book btw) but I learned a few neat tricks, which hopefully I will never need to use outside of a toy context.

.Net system programming video

Good review (or first view) of how GCs, threading, etc work under the cover.

C# 7 looks like a party

Article goes over these awesome-looking features:

Part 1: Value Tuples
Part 2: Async Main
Part 3: Default Literals
Part 4: Discards
Part 5: Private Protected
Part 6: Read-only structs
Part 7: Ref Returns
Part 8: “in” Parameters
Part 9: ref structs
Part 10: (This post) Span and universal memory management

Can't wait until I get off of VS 2015 to something a little more modern.

Visual Studio has code gen now!

I've been writing perl scripts. But this looks neat.

C# 6 features

So many, so good.

Improved GC in .NET 4/4.5.1

I'm a little late to the show, but this is a good article for those who wish to review the interactions between workstation/server and concurrent/background/regular garbage collection.

The dangers of readonly fields in C#

Jon Skeet!

The importance of implementation details

Today, after years of odd threading bugs, I learned that creating a DataView and various other reads on a DataTable are actually write operations. E.g. from the first link

However, creating a DataView on a DataTable is a write operation on a DataTable. Most people don't know this, and its not very intuitive so I don't blame them for not knowing this. What happens when you create a DataView on a DataTable is the DataView will create an index on the DataTable and this index is stored in the DataTable. The reason for this is performance, for example if you create a DataView saying "F1=1" as the criteria, this creates an internal index on the DataTable to locate this information. Later on if you create another DataView with the same criteria, the index is reused, so this improves performance. However the fact that these indexes are stored inside the DataTable means that these are write operations to the DataTable and thus they are not thread safe.

Just goes to show you, when an object doesn't say it's threadsafe, don't assume that it's threadsafe, even if it's "just a read".

Decimal formatting in .Net

One day I was having problems with decimal numbers showing up as strings with lots of zeros after the decimal point. Since they were whole numbers, I had naively expected that they would always be displayed without any zeros, at least with the format string I was using.

Alas, the documentation disagreed with me.

Apparently the precision of the decimal will show up when calling ToString in the manner in which I was calling it. So my unit tests all passed because I was constructing a decimal 42, rather than a decimal 42.00000.

Microsoft 1, me 0.

Conditional answer

Ecce:

The second and third operands of the ?: operator control the type of the conditional expression. Let X and Y be the types of the second and third operands. Then,

• If X and Y are the same type, then this is the type of the conditional expression.


• Otherwise, if an implicit conversion (Section 6.1) exists from X to Y, but not from Y to X, then Y is the type of the conditional expression.


• Otherwise, if an implicit conversion (Section 6.1) exists from Y to X, but not from X to Y, then X is the type of the conditional expression.


• Otherwise, no expression type can be determined, and a compile-time error occurs.

Moral of the story: Know your language spec.

Conditional Mystery

Imagine a C# function like so:

public object Foobar(double baz_)
{
return baz_ < 12 ? new Foo(baz_) : baz_;
}

where Foo has a function as such:

public static implicit operator Foo(double d_)
{
return new Foo(d_);
}

What is the type of Foobar(2)? Foobar(15)? The shocking answer revealed whenever I get around to blogging next. Yes this was causing an outage in production.