“” vs. String.Empty and “a”+str+”b” vs String.Concat(“a”, str, “b”) reloaded

Despite the compiler optimizes the instructions above for a long time I suggest You not to use the firsts in the pairs.

The first pair has a lot of forum talks: which is better in terms of memory. But there is an other reason I favour String.Empty: You can much easier found all of it with FindAllReferences instead of looking for each “s in Your code 🙂

The second pair the two sides in discussions are: readability vs. performance. The left side is much readable, but because of variable content in ancient days it becomes a double memory allocation to build “a”+str and then the tempresult+”b” string. Nowadays the compiler optimizes it to the call on the right side in the pair, which is much better: Concat allocates once the memory which is enough to build the whole result string at once. That is true till four parameters. If You have more params Concat will use StringBuilder class internally which works like Concat: allocates some space at first and uses it to build the string. The difference is: Concat knows how much space required for the result from it’s params, but StringBuilder dont. So it allocates a buffer and if that is exhausted it allocates a new bigger one, etc. If you check the IEnumerable<string> overload of Concat You will see that althought it knows from its parameters it dont calculates the required buffer size for StringBuilder constructor to allocate approriate buffer at once. So if You have more than four strings to concat You may write better code than using the builtin feature of Concat 🙂

The reason for this post is very theoritical: the Think Runtime Principle

Volatile variables

If You want to exit from loop if some bool set from another thread You may be victimed by compiler’s code optimalization.

class Test
{
    private bool _loop = true;

    public static void Main()
    {
        Test test1 = new Test();

        // Set _loop to false on another thread
        new Thread(() => { test1._loop = false;}).Start();

        // Poll the _loop field until it is set to false
        while (test1._loop == true) ;

        // The loop above will never terminate!
    }
}

Found here: http://igoro.com/archive/volatile-keyword-in-c-memory-model-explained/

Enum.TryParse<> unexpected behaviour

Check code below:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
 
namespace EnumTest
{
    class Program
    {
        static void Main(string[] args)
        {
            TestEnum result;

            bool ret = Enum.TryParse<TestEnum>("Yellow", out result);
            // ret value becomes: false
 
            ret = Enum.TryParse<TestEnum>("111", out result);
            // ret value becomes: true, result becomes: 111 !!!!!
        }
    }
 
    enum TestEnum
    {
        Red = 1,
        Green = 2
    }
}

Something found in help:

“If this behavior is undesirable, call the IsDefined method to ensure that a particular string representation of an integer is actually a member of TEnum. ”

Nice.

Lazy expression evaluation

What will we find in result after this code finished?

IEnumerable<string> src = new List<string> { "ab", "ac", "bc", "abc" };
List<string> filter = new List<string> { "a", "b", "c" };

foreach (var f in filter)
{
   src = src.Where(i => i.Contains(f));
}

result = src.ToList();

You say: only one element: “abc”?
Wrong!
It contains three elements: “ac”, “bc”, “abc”
Why?
Where() is lazy!
Excerpt from help:

“This method is implemented by using deferred execution. The immediate return value is an object that stores all the information that is required to perform the action. The query represented by this method is not executed until the object is enumerated either by calling its GetEnumerator method directly or by using foreach in Visual C# or For Each in Visual Basic.”

We build a lazy evaluated expression chain there will be references to f variable. After we get out from cycle the reference to f remains in use, but it’s value will be the last one it got in the cycle.
So when we evaluate with ToList() call the src.Where(…).Where(…).Where(…) expression each lambda will look for “c”!

This behaviour changes in .NET 4.5; f will encapsulate the value and not the reference.

Task vs. CurrentThread

If You use Task and Thread.CurrentThread inside of the code tree callable from the task’s body You should know something.
The TaskScheduler may decide to run Your tasks on same Thread.
In this case Your code may not work as expected, see sample below:

private Dictionary<Thread, int> uniqueIds = new Dictionary<Thread, int>();
 
private void InitMyUniqueId(int id)
{
    // thread safety skipped to keep sample simple
    uniqueIds[Thread.CurrentThread] = id;
}
 
public void DoSomething()
{
    // thread safety skipped to keep sample simple
    var myUniqueId = uniqueIds[Thread.CurrentThread];
 
    Console.Write(myUniqueId);
}
 
public void main()
{
    var t1 = new Task(() =>
    {
        InitMyUniqueId(1);
        DoSomething();
    });
 
    var t2 = new Task(() =>
    {
        InitMyUniqueId(2);
        DoSomething();
    });
 
    t1.Start();
    t2.Start();
}

Depending on TaskScheduler the output can be “12” and “22” too!
The potential impact may be e.g. various context mismatches if You use CurrentThread
to select the local storage slot for Your data, etc. Be careful!

Possible workaround: check Task.CurrentId. If it is not null we are in a task
and using CurrentThread like above is dangerous.

BinaryFormatter and FormatterAssemblyStyle.Simple

Consider this code:

BinaryFormatter bf = new BinaryFormatter();
bf.AssemblyFormat = FormatterAssemblyStyle.Simple;
ret = bf.Deserialize(memoryStream);

Setting AssemblyFormat to FormatterAssemblyStyle.Simple should mean this:
“In simple mode, the assembly used during deserialization need not match exactly the assembly used during serialization. Specifically, the version numbers need not match as the LoadWithPartialName method is used to load the assembly.”
But this is not true if the assembly is signed!

My current solution:

using (MemoryStream ms = new MemoryStream(...))
{
    var versionMismatchAssemblyResolveHandler = new ResolveEventHandler((s,ea)=>
    {
        Assembly asm = Assembly.Load(new AssemblyName(ea.Name).Name);
        return asm;
    });
 
    try
    {
        AppDomain.CurrentDomain.AssemblyResolve += versionMismatchAssemblyResolveHandler;
 
        BinaryFormatter bf = new BinaryFormatter();
        bf.AssemblyFormat = FormatterAssemblyStyle.Simple;
        ret = bf.Deserialize(ms);
    }
    finally
    {
        AppDomain.CurrentDomain.TypeResolve -= versionMismatchAssemblyResolveHandler;
    }
}

This will workaround the situation emulate the behaviour.

Link SVN commit messages with Redmine URLs

Redmine has a module which allows to link SVN changesets to tickets so we can follow commits to given ticket on ticket’s page.
So I want to write commit message like this:

!a: some code modified (what a useful message:)
!t: #1234

When configured well this change will be shown in Redmine below ticket 1234.

This blog entry shows the opposite direction: how to link SVN log message to Redmine ticket with a handy URL?
After using some post-commit hook magic my log entry above will be visible as below:

!a: some code modified (what a useful message:)
!t: #1234 (https://my.redmine.site/issues/1234)

Which, at least in TortoiseSVN will be shown as a real, clickable link. So when we are browsing log messages we will be in one click distance from the referenced ticket!

The magic is not magic at all. Simply add/modify You post-commit hook script to contain these lines:

#!/bin/sh

REPOS="$1"
REV="$2"

tmp=`mktemp`
LC_ALL=hu_HU.ISO-8859-2 /usr/bin/svnlook log -r $REV "$REPOS" |sed 's%^!t:[^#]*#\([0-9]*\)$%!t: #\1 (https://my.redmine.site/issues/\1)%' > $tmp
LC_ALL=hu_HU.ISO-8859-2 /usr/bin/svnadmin setlog "$REPOS" -r $REV $tmp --bypass-hooks
rm $tmp

This will modify commit log message as described above.
The only thing to mention is the explicit locale setting. Without this we lost some characters from our ABC 🙂

Using * in SQL VIEW definitions

Do not use * in column list of SQL VIEW definitions!

CREATE VIEW bad_view
AS
SELECT * FROM some_table

SQL Server will introduce some problems when the underlying table structure changes.
If for example You insert some columns between pre-existing ones into some_table above
the view result will be shifted and result columns appear below bad column headers!
This may occure without any sign of error!

Read more:
http://blog.sqlauthority.com/2010/09/15/sql-server-select-and-adding-column-issue-in-view-limitation-of-the-view%C2%A04/

Thread-safe lazy init pattern

The code below is not thread-safe:

class SomethingWithLazyProperty
{
        private OtherThing otherThing = null;
        public OtherThing OtherThing
        {
            get
            {
                if (this.otherThing == null)
                {
                    this.otherThing = new OtherThing();
                }
 
                return this.otherThing;
            }
        }
}

As You may see when two threads enter the getter and the thread switching occures while
both of them are inside the if block two OtherThings will be instantiated and only
one of them will be stored in private field for later uses.

You should use some locking mechanism to avoid this race condition. The appropriate mechanism
may depend on the heaviness of instantiation. Lets choose lock to get out something more
of this example:

class SomethingWithLazyProperty
{
        private object syncRoot = new object();

        private OtherThing otherThing = null;
        public OtherThing OtherThing
        {
            get
            {
                lock(syncRoot)
                {
                    if (this.otherThing == null)
                    {
                        this.otherThing = new OtherThing();
                    }
                }
 
                return this.otherThing;
            }
        }
}

Thread-safety now in place, but the code will be really slow because of
locking every time we use this property. Thread-safety was only important
once at the begining but we slowed down the code for the whole lifecycle!
Modify a little bit the body of getter:


            get
            {
                if (this.otherThing == null)
                {
                    lock(syncRoot)
                    {
                        if (this.otherThing == null)
                        {
                            this.otherThing = new OtherThing();
                        }
                    }
                }
 
                return this.otherThing;
            }

And voilá, the code is thread-safe and as fast as at the original!

if (something.Count() == 0) { … } construct

Do not use such a construct:

if (something.Count() == 0) 
{ 
   ... 
}

We are not interested in the real count of items in something.
Only the presence of items is the point of our interest.
So write instead of above this:

if (something.Any())
{
   ...
}

This will stop at the first item which will result in better performance in
cases where something contains a lot of items.