Fortsätt till huvudinnehåll

Inlägg

Visar inlägg från juli, 2018

C# Deconstruct and Discards

 Deconstruct and Discards In the last post I mentioned the Deconstruct method and how it should not be mixed up with a Destructor . In this post I will show some examples and how you can use Deconstruct and especially in combination with something called Discards . The Deconstruct method can be defined within a class to provide a way to retrieve a Tuple of the data that makes up the type and Discards can be used by the caller to effectively ignore the members of the Tuple that aren't of interest. Sounds complicated? Hopefully the examples below will clear things out. Implementing the Deconstruct method Let's start with a simple container class holding attributes of a file in the filesystem. public class FileInfo {   public string Name { get; }   public int SizeInBytes { get; }   public bool ReadOnly { get; }   public FileInfo(string name, int sizeInBytes, bool readOnly)   {     Name = name;     SizeInBytes = sizeInBytes;     ReadOnly = readOnly;   }

C# Finalize, Dispose, and Deconstruct

Introducing the Concepts It is easy to get a bit confused when trying to figure out what resources you need to free explicitly and how to release the resources that your class has created or is holding references to. You will find that there is something called Finalizer , a clean-up pattern called The Dispose Pattern, and a special Deconstruct method that you can declare. In most cases though, you don't have to do anything and just let the Garbage Collector (GC) do its thing. However, if your class allocates unmanaged memory, open file handles, network sockets, database connections or similar, you need to ensure that these are properly closed and freed before the references are removed. I will go through the different concepts and hopefully clear out how to ensure that all resources are properly freed in your application. The Deconstruct method You might say that it is incorrect to even mention the Deconstruct keyword/method in this post, since it actually have nothing

When to use out parameters in C#

The out keyword In C# you can use the out keyword to define output parameters in your method signature. For example, the Int32.TryParse method in the System namespace has the following signature: public static bool Int32.TryParse(string s, out int result) From this you can read out that the TryParse method returns a boolean but also provides a result as an out parameter . The boolean will indicate whether it was possible to parse an integer value from the string s and store it in the result variable. You can call the TryParse method like this: if (Int32.TryParse(str, out var result)) {     Console.WriteLine($"The result is: {result}"); } else {     Console.WriteLine("Parsing failed"); } When is it a good idea to use out parameters ? Most of the time the use of out parameters adds complexity to your program. It will make the source code harder to follow since anyone reading the code will have to juggle several return values instead of just

C# Delegates, Action, Func, or Predicate

Introduction As a previous C developer I am used to working with function pointers and I found the C# Delegates quite easy to work with in comparison. One thing that made me a bit confused initially however were the Delegate types defined in the .NET framework. Why would I want to bother with Actions , Funcs , and Predicates ? After reading up on them I almost never define custom Delegates anymore. I will try to explain their use cases below. Delegates A Delegate in C# is similar to a function pointer in C or C++. You can always define a custom Delegate that matches any method signature you want. However, the .NET Framework defines a number of Delegates you can use so that you don't have to define your own. These Delegates are grouped into three different Delegate groups, Actions , Funcs , and Predicates . Actions An Action is, as the name implies, a Delegate that encapsulates a method that performs an operation and where you expect no result to be returned. The Ac

Override the Object.GetHashCode method, why you should bother

When you design a class you sometimes want to override the Equals method in order to use some internal fields to determine if two instances of the class are equal. For example let's assume that you have implemented a class Money that has two fields, one named _amount of type decimal and another one called _currency of type string . You decide that two objects of type Money are equal if and only if the amount and currency fields have the same values. The implementation of Equals looks like this: public override bool Equals(object obj) { if (obj is Money other) { return _currency.Equals(other._currency, StringComparison.Ordinal) && _amount.Equals(other._amount); } return false; } You then notice that you get a warning during compilation, Warning CS0659 'Money' overrides Object.Equals(object o) but does not override Object.GetHashCode() . So what is this all about? If you look into it a bit you will find that there is a rule sayin

String comparison in C#

In C#, a string is a sequential read-only collection of Char objects. A Char object is an instance of a Char struct, which represents a character as a UTF-16 code unit. Most programs, and programmers, do not care much about the internal representation of a string and a Char . As long as you know that strings are immutable and there is a big efficiency penalty involved in building up strings in loops without involving a mutable object, such as a StringBuilder , you are mostly fine. However, there are some things that are good to know when working with strings. One of these things is comparison using methods such as S tring.CompareTo and String.Compare . By default the Compare and CompareTo methods are Culture sensitive. This means, that depending on the language and culture setting of the machine running the application , comparison and sorting of strings might be different than on your development machine. This might be exactly what you want, or it might come as a complete surp

When to use float, double, and decimal in C#

If your dealing with numbers that have fractions you need a number type that can handle that case. When you define a variable in C# and assign it a fractional value, for example var myValue = 2.5; the default type is double . In many cases double works fine. But sometimes you want to use float or decimal instead. The major difference between float and double is that float uses 32 bits while double uses 64 bits. This makes double able to represent a much larger range of values with higher precision. So if memory space is not an issue you can safely ignore float and use double instead. One major drawback with float and double is that they use binary representation for the fractional part of the value. This becomes an issue when you need to have exact values for the fractional part. Not all fractional values, that looks really exact in the code, can be represented in binary. One example is 0.2 which gets rounded off when stored as a float or double. What this means is that y

Indexers in C#

A feature in the C# language that I have noticed that many developers, even some with years of C# experience, have missed is that it is possible to create Indexers. With Indexers you are able to use square brackets to access specific elements of a class, just like you would in an Array or a List: items =  new   List < int > { 1, 2, 3, 4 }; var  first = items[0]; Assume that you define an interface for a certain ability that a class can have. That ability being that it should be possible to set and get elements of the class using square brackets. You may define the interface like this: namespace  Indexer {      public   interface   IIndexable < T >     {         T   this [ int  index] {  get ;  set ; }     } } And a class can implement the interface like this: using  System.Collections.Generic; namespace  Indexer {      internal   class   Indexable  :  IIndexable < int >     {          private   readonly   IList < int > items;          public  Ind