Posts tagged with c - page 12

Calculating CRC-32 in C# and .NET

Just a few days ago I found myself needing to calculate a CRC-32 in .NET. With so many facilities available I was a little shocked that there was nothing built-in to do it so knocked up something myself.

GitHub has the latest version of Crc32

Because unsigned ints aren’t CLS compliant it won’t play well with VB.NET and implementing the HashAlgorithm might lead people to believe it’s suitable for signing – it isn’t. CRC-32’s are only any good for check-sums along the lines of WinZIP, RAR etc. and certainly shouldn’t come near a password and instead consider SHA-512 or similar.

As well as using it as a HashAlgorithm with block processing you can also access the static method Compute although there is an overhead with every call building the table with that. If neither option suits you needs cut ‘n splice it to something that does.

If using the Compute methods multiple times for the same hash you must XOR (~) the current hash when passing it in to the next subsequent call’s seed parameter.

To compute the hash for a file simply:

var crc32 = new Crc32();
var hash = String.Empty;

using (var fs = File.Open("c:\\myfile.txt", FileMode.Open))
  foreach (byte b in crc32.ComputeHash(fs)) hash += b.ToString("x2").ToLower();

Console.WriteLine("CRC-32 is {0}", hash);


Implementing a generic WeakReference in C#

Check out the replacement EquatableWeakReference class</a> </p> A [weak reference]( lets you hold a reference to an object that will not prevent it from being garbage collected. There are a few scenarios where this might be important – such as listening for events, caching, various [MVC patterns]( .NET and Java supports weak references with the aptly named [WeakReference]( class. In .NET it exposes a .Target property of type object that weakly points to whatever you like. Java also sports a generic WeakReference to give you a strongly typed version so it’s somewhat puzzling why .NET doesn’t. Here is my attempt at a WeakReference for .NET. It works fine in the scenarios I’ve used and performance is close to the non-generic version but a quick glance at the SSCLI code for WeakReference reveals that the standard version is a little more complicated and it’s possible there is a reason for that – most likely due to finalizer issues. ```csharp using System; using System.Runtime.InteropServices; public class WeakReference : IDisposable { private GCHandle handle; private bool trackResurrection; public WeakReference(T target) : this(target, false) { } public WeakReference(T target, bool trackResurrection) { this.trackResurrection = trackResurrection; this.Target = target; } ~WeakReference() { Dispose(); } public void Dispose() { handle.Free(); GC.SuppressFinalize(this); } public virtual bool IsAlive { get { return (handle.Target != null); } } public virtual bool TrackResurrection { get { return this.trackResurrection; } } public virtual T Target { get { object o = handle.Target; if ((o == null) || (!(o is T))) return default(T); else return (T)o; } set { handle = GCHandle.Alloc(value, this.trackResurrection ? GCHandleType.WeakTrackResurrection : GCHandleType.Weak); } } } ```

I’ve allowed Target to be settable against my better judgment to bring it more in like with WeakReference. It’s still not serializable though unlike WeakReference.


Observing changes to a List by adding events

In an attempt to get more C# and .NET content up I’m putting up some snippets I’ve put together in response to questions on some C# user support groups. Many of them are not particularly advanced but they are quite useful.

GitHub has the latest version of ObservableList</a> </p> This sample shows how to observe events on an generic IList. It does this by way of implementing the IList interface over the top of something that already supports IList to do the actual work and highlights how useful publishing the interface, IList, separate from the actual concrete class List can be for reuse. ```csharp using System; using System.Collections; using System.Collections.Generic; public class ObservableList : IList { private IList internalList; public class ListChangedEventArgs : EventArgs { public int index; public T item; public ListChangedEventArgs(int index, T item) { this.index = index; this.item = item; } } public delegate void ListChangedEventHandler(object source, ListChangedEventArgs e); public delegate void ListClearedEventHandler(object source, EventArgs e); public event ListChangedEventHandler ListChanged; public event ListClearedEventHandler ListCleared; public ObservableList() { internalList = new List(); } public ObservableList(IList list) { internalList = list; } public ObservableList(IEnumerable collection) { internalList = new List(collection); } protected virtual void OnListChanged(ListChangedEventArgs e) { if (ListChanged != null) ListChanged(this, e); } protected virtual void OnListCleared(EventArgs e) { if (ListCleared != null) ListCleared(this, e); } public int IndexOf(T item) { return internalList.IndexOf(item); } public void Insert(int index, T item) { internalList.Insert(index, item); OnListChanged(new ListChangedEventArgs(index, item)); } public void RemoveAt(int index) { T item = internalList[index]; internalList.Remove(item); OnListChanged(new ListChangedEventArgs(index, item)); } public T this[int index] { get { return internalList[index]; } set { internalList[index] = value; OnListChanged(new ListChangedEventArgs(index, value)); } } public void Add(T item) { internalList.Add(item); OnListChanged(new ListChangedEventArgs(internalList.IndexOf(item), item)); } public void Clear() { internalList.Clear(); OnListCleared(new EventArgs()); } public bool Contains(T item) { return internalList.Contains(item); } public void CopyTo(T[] array, int arrayIndex) { internalList.CopyTo(array, arrayIndex); } public int Count { get { return internalList.Count; } } public bool IsReadOnly { get { return internalList.IsReadOnly; } } public bool Remove(T item) { lock(this) { int index = internalList.IndexOf(item); if (internalList.Remove(item)) { OnListChanged(new ListChangedEventArgs(index, item)); return true; } else return false; } } public IEnumerator GetEnumerator() { return internalList.GetEnumerator(); } IEnumerator IEnumerable.GetEnumerator() { return ((IEnumerable) internalList).GetEnumerator(); } } ``` _[)amien_

First look: Applying Domain-Driven Designs and Patterns

In an attempt to quench my thirst for all things C# and having already torn through the great .NET Framework Design Guidelines and less-great Effective C# I grabbed a copy of Applying Domain-Driven Design and Patterns (With Examples in C# and .NET) by Jimmy Nilsson.

The book is obviously based around domain models but also gives some coverage to test-driven development, NHibernate, design patterns, refactoring, code-smells etc.

This is only a first-look as I’m only up to page 130 of the 500+ the tome weighs in at but here are a few observations so far.

The Impedance Mismatch Between Domain Model and Relational Database

One annoyance with the book is that is identifies and discusses problems and then offers no discussion or ideas for a solution before moving onto another topic.

A good example is this section which touches on the mismatch between the primitive types of .NET and SQL without the consideration of how/where to check this, the fact that SQL types can be null with no regard to .NET 2’s INullable, bit flags or ‘magic values’.

How to Recognize If an Application Will Be Long Lasting

Another perfect example of the previous problem. The heading asks the question but the short anecdote about how a hacked together app became mission critical fails to answer it.

Use public fields

Jimmy proposes a number of techniques that fly in the face of .NET Framework Guidelines and other solid material. This is highlighted by the phrase;

As long as the fields are both readable and write-able and no interception is needed … public fields are at least as good as properties.

Perhaps Jimmy doesn’t know that converting a field to a property later will break binary compatibility with anything using your assembly.

Expose internals for testing

…expose sub-results so they are testable

flies in the face of hiding the implementation and Jimmy does at least refer to this balance but the whole idea of exposing unnecessary details for the sake of being able to test them gives me a shudder.

Throwing aside the whole question of whether you should write unit tests that test implementation rather than interface a better solution would be to add a


block to classes that really need to expose their internals to your test tools and compile with that switch set in your testing environment.

Use static factory classes!

Jimmy extracts the factory methods into a new class and but then leaves them static. A static class throws away substitutability, extension and indeed everything that makes OO great for the sake of being able to access it like a global variable.

Expose IList as read-only

On page 102 Jimmy refactors a “public IList Children” field firstly making it a read-only property and then creates a AddChild method which is fine but then how will he stop people modifying his IList? With ArrayList.ReadOnly(children) of course bemoaning how clients still see .Add etc.

Hello Jimmy, let me introduce you to IEnumerable.

Use reflection to set internal properties from Factory & Repository!

Jimmy describes how some properties should be read-only but then the Factory and Repository need to set the values. He proposes reflection.

Maybe Jimmy missed the memento pattern and dislikes the internal keyword.

Coding standards

All the code samples use _ for internal members – something that Microsoft guidelines and their FxCop tools are keen to stamp out. Besides being ugly it also reeks of the obsolete Hungarian naming prefixes.

Storybook format

The whole book is written in “I still remember”, “I worked on an application”, “After that, I tried Domain Models”… It makes for slow reading at times.

Well that about wraps it up so far.