Fun with variable names

Something odd here. I have 2 StringBuilder variables, one called sbConsoleCommand and one called sbConsoleCommandNONE. I declare them like this:

private static StringBuilder sbConsoleCommand = new StringBuilder(32);
private static StringBuilder consoleCommandNONE = new StringBuilder("NONE");

According to the debugger, when I do a sbConsoleCommand.Clear() both variables get cleared. i.e. their length get sets to 0. I get the same behavior when I rename sbConsoleCommandNONE to consoleCommandNONE. I’ve been googling and can’t find anything that says there is a maximum variable name length. Any ideas?

Of course I thought of this just after I posted my message but is it possible that

sbConsoleCommand = consoleCommandNone;

does not in fact set the value of the left hand side equal to the value of the right hand side but somehow links the 2 variables for ever after? If so, why?

That would only make sense to me if you equate those two variables somewhere in the code. For example like this:

Dim a, b As New StringBuilder

a.Append("test")
b = a
Debug.Print("Before: " & a.ToString() & ":" & b.ToString)
a.Clear()
Debug.Print("After: " & a.ToString() & ":" & b.ToString)

Because both variables are references to a StringBuilder object that you assigned through a new operator, yes, making one equal to another copies the object reference to the variable on the left side of the assignment. Yes, they both now point to the same object, and the other object has been released to the garbage collector.

I hope that helps.

If you wanted to copy the value, you’d have to do something like this since MicroFramework doesn’t have a Clone object method.


private static StringBuilder sbConsoleCommand = new StringBuilder("some random string");
private static StringBuilder consoleCommandNONE = new StringBuilder(sbConsoleCommand.ToString());

OK, I think I understand what I’m doing wrong but could use some help understanding the fundamental issue. I wrote this little test program to demonstrate to myself what might be happening.

namespace refTest
{
    public class Program
    {
        private static int a = 0;
        private static int b = 1;
        private static StringBuilder sbSomething = new StringBuilder("Something");
        private static StringBuilder sbNothing = new StringBuilder("Nothing");

        public static void Main()
        {
            Debug.Print("Program Started");
            Debug.Print("");

            Debug.Print("Before int assignment and =0 statement: a = " + a.ToString() + "   b = " + b.ToString());
            a = b;
            a = 2;
            Debug.Print("After int assignment =0 statement:  a = " + a.ToString() + "   b = " + b.ToString());

            Debug.Print("Before StringBuilder assignment statement: sbSomething = " + sbSomething.ToString() +
                                                                   "   sbNothing = " + sbNothing.ToString());
            sbSomething = sbNothing;
            sbSomething.Clear();
            Debug.Print("After StringBuilder assignment and clear statement:  sbSomething = " + sbSomething.ToString() +
                                                                             "   sbNothing = " + sbNothing.ToString());
            Debug.Print("");
        }
    }
}

Here’s the output:

Before int assignment and =0 statement: a = 0 b = 1
After int assignment =0 statement: a = 2 b = 1
Before StringBuilder assignment statement: sbSomething = Something sbNothing = Nothing
After StringBuilder assignment and clear statement: sbSomething = sbNothing =

b stays the same after a = b and a = 2 but the sbNothing doesn’t.

It’s pretty clear that a Stringbuilder object is different than an int object. Is that why Stringbuilder variables need the “new” to instantiate? If Stringbuilder variables are references what are int variables? Is a byte[] array a reference also and that is why they need the “new” to instantiate?

Thanks for the help

Try reading this:

You need ‘new’ because it is a class and you initialize it.

1 Like

Well that makes it crystal clear. Thanks for the help.