Looks to me that the caller of GetValue() made an error (when declaring his local variable), not that var assumed the wrong type returned from GetValue().

My point was that error (incorrect assumption) doesn't show up as a compile error in this case, where if the developer used an explicit type instead of var, there would be either a compile error or, in this case, no problem at all.

The interface approach does not work, and in fact your code does not even compile. I think it would help you understand what I am getting at if you try to compile and run your proposed solution using the test program I painstakingly provided. If the output matches what is expected that would be a very interesting result. If not, you can think about alternate approaches. This will help you verify whether your ideas work without having to post proposals to this forum. I don't think this will take very much additional effort, and additionally I think it will bring clarity to the discussion.

Sorry about the compiler errors, but those are easily fixed:

		public static void Func2(ABOnly value)
		{
			value.A = 13;
			value.B = 14;
		}

		public static void Func3(MyStruct[] array)
		{
			ABOnly local = array[3];

			local.A = 13;
			local.B = 14;
		}

		public interface ABOnly
		{
			int A { get; set; }
			int B { get; set; }
		}

		public struct MyStruct : ABOnly
		{
			public int A { get; set; }
			public int B { get; set; }
			public int C { get; set; }
		}

It's better encapsulation to use properties instead of fields, anyway.

More importantly, does this solve the problem?

I'm sorry I don't have the time to retrofit my example into yours. I'm posting from work and they expect me to get stuff done, sometimes.

I think by changing 'struct' to 'class' you have redefined the question and sidestepped the whole point. You won't be able to get your code to work with 'struct'.

If it helps, here is a self-contained program. The goal is to set the values A and B of array[3] in-place

• without disturbing the value of C
• without copying a whole new struct
• only referring to array[3] inside Func2() once
• without making any function calls from Func2

I'm still not sure I understand what you're getting at. Using an interface will satisfy the requirements you listed, I think, but the structs will be boxed. If protecting the value of C is what's important, than either interfaces or better encapsulation looks like a good solution.

		public static void Func2(ABOnly value)
		{
			value.A = 13;
			value.B = 14;
		}

		public static void Func3(MyStruct[] array)
		{
			ABOnly local = array[3];

			local.A = 13;
			local.B = 14;
		}

		public interface ABOnly
		{
			int A;
			int B;
		}

		public struct MyStruct : ABOnly
		{
			public int A;
			public int B;
			public int C;
		}

If you mean accessing the struct without boxing (for performance reasons), I can see your point, but the performance hit from boxing is negligible compared to many other things you find in managed programming and algorithms in general. Unless this is a thought exercise, you should keep in mind that performance tuning is best when surgically applied to specific problem areas.

Found a reference to overflow checking in the full Framework. http://www.codeproje...w_checking.aspx

That's not true.
The problem usually arises because none activates the checking options on numerical operations.
By default, you implicitly accept that operations on numbers could roll-over, overflows, etc.

Yes, turning on overflow checking would help find the problem. Is this available on Compact Framework projects? I can't find it.

Also, in at least some implementations (if not all), this is still not a compile-time check, but a runtime check, IIRC.

It does not matter to implement that function, but it would solve the problem I have posted above.
On a PC you won't care about it, but on a small device where the performance is important, the ability to access the field of a structure as fast as possible I think it's important.
Actually there's no way in C#, unless you create a custom function just to do it.
Upon this point (that I raised), I'd agree with Eric Lippert of MS, that often explains us the ratio of benefits/costs of some feature.

I'm not sure what you're getting at. The code example you gave does work (with a few fixes).

	class SA
	{
		public int A { get; set; }
		public int B { get; set; }

		public static void Method()
		{
			SA[] sa = new SA[10];
			sa[3] = new SA();
			sa[3].A = 123;
			var s = sa[3];
			s.B = 456;    //won't work!
		}
	}

If you mean accessing an object without the "unboxing" you get with a reference, you can make the declaration using struct instead of class (DateTime is an example).

EDIT: Corrected the spelling of "struct"

Can you post an example?

	public class Program
	{
		public static void Main()
		{
			var count = GetValue();

			count += 200;
		}

		public static byte GetValue()
		{
			return 100;
		}
	}

Let's assume that GetValue is actually buried somewhere in another file. If the developer is expecting that GetValue returns an int, he won't expect to see count = 44 after that second line.

If count is explicitly defined as an int, it will behave as the developer expects (implicit cast to a larger type).

Also, if the types were reversed (GetValue returns an int, but count is defined as a byte), you'll see the compiler error "Cannot implicitly convert type 'int' to 'byte'. An explicit conversion exists (are you missing a cast?)". (Yes, I know that declaring count as var here won't make a difference to the compiler, as it already knows to use int.)

Your comment about structs is interesting. I believe the feature you want is a limitation of the C# language and not the CLR. That is, I believe if there was a compiler for the following C#-like code, it would pass the code verifier and the CLR would run it:

void Main()
{
  S[] sa = new SA[10];
  sa[3].A = 123;
  ref S s = sa[3]; //hypothetical syntax -- doesn't work in C#
  s.B = 456;
}

Sometime soon I will try to confirm this hypothesis by generating the MSIL code corresponding to this and see if I can get the system to assemble it (and more importantly, for it to pass peverify.exe)

Use of ref and out is more meaningful when talking about method arguments. Declaring a local variable as ref or out doesn't mean anything, as far as I know.

void Main()
{
   int count = 0;

   CopyOf( count );
   RefTo( ref count );

   Console.WriteLine( "count = " + count.ToString() );
}

void CopyOf( int count )
{
   count ++;
}

void RefTo( ref int count )
{
   count ++;
}

The TryParse example mentioned above is a good use of out.

var is not resolved at runtime.

You're correct, but it can introduce problems you won't see until runtime. For example, if the compiler decides the type is byte, but you expect int32, there will be no compiler error, just an overflow when you hit the bigger values.

This is a mythical entity which can only be found with unicorns. When two or more programmers get togther they will always disagree on the correct coding style.

I agree that developers will disagree on correct coding styles, but there are practices that are easier to read than others. I'm not talking about people who are learning the C# language so much as the developer who is trying to understand what your code is doing. The easier it is to glance at a single line of code and see exactly what it does, the less time a developer will spend going over the entire class to understand it. Again, these kinds of things are generally more important when the project in question is very large. Even when the code is small, though, it can help developers of varying skill levels if the code is easier to read, especially when the code is intended to be shared, such as the libraries and examples we see here.

I must admit, I personally have no problem with ref or out but I do have a problem with var,

All three are useful in some places. I think the danger that they can easily be overused, which makes for sloppy code. Especially in the case of ref and out, this means more interrelationships (i.e. a change in one place of code is more likely to affect or even break code somewhere else).

... it allows the compiler to make decisions for me and those decisions may not be correct (such as making a variable an int when I wanted an unsigned short).

I agree. It is much easier to find bugs if they show up as compile errors (type mismatch) than if they show up as runtime errors (var not defined as the type you expect).

... The most common use I have seen is for the results variable definition in a LINQ query. I'd like to think that my team understand the type of the result sets being returned but I suspect that many new programmers do not and that to me is a bad thing.

I agree that understanding the type is important, but using structures like anonymous types becomes much more difficult without having var available.

Most programming languages have elements that provide significant power to the developer, like macros in C++ or anonymous types in C#. These tools should be used carefully because tracking down the problems they sometimes cause can be extremely difficult, even for an experienced developer.

...
what is the benefit in THIS example to use
'var leftByte=byte0<<shift;'
than:
'byte leftByte=byte0<<shift;'
isn't it really clear that we will get a byte as return value? Or is the 'real' result of leftByte=0x0E<<1 == 000111000, so one bit too much for byte and we have to sign it as var instead of converting it?

It is clear that the values are bytes, but the use of "var" is harder to read (i.e. not as obvious to someone who didn't write the code as reading the more specific "byte"). The compiler may or may not see the overflow in your last example. My guess is that it wouldn't, but I've been surprised before.

So, in THIS example, it's not a good use of var. In fact, there may not be a good reason for using var in the Compact Framework. If you get involved with the full-blown .Net Framework, however, there are cases where the use of var can save some significant typing. (If you're curious, look up LINQ and anonymous types.)

I have a schematic of the Netduino Mini on Eagle. No board, and it's the simplest to draw, but it's a start. Hopefully, you can export any components that aren't in your library. I'm a newcomer to the hardware side, so there's no guarantees this schematic is completely accurate, either.

What firmware version are you using? v4.1.0.5 or one of the alpha/beta releases?

I'm using v4.1.0.5.

I haven't tried to use SPI with anything else, only I2C (which works with the 24LC256 EEPROM).

I'm struggling to get the Netduino talking with the RFM12B radio (http://www.sparkfun.com/products/9582) over SPI, and I'm running out of ideas. I based the code on the Arduino libraries (http://jeelabs.org/2...9/new-rf12demo/). Attached is my demo code. I'm getting intermittent problems with the nIRQ line. It either never goes down or it never goes up. If the interrupt handler fires (sometimes even before the radio setup is done), the data coming back is much larger than the buffer, and doesn't look right at all (something like 128, 128, 0, 0, 64, 8, 0, 4, 4, etc.) Also, if I attach the interrupt handler, I get garbage reads before the radio is even initialized. It looks like port.DisableInterrupts doesn't actually disable the interrupts. I've tried a bunch of variations on the SPI configuration, and I haven't gotten the radio to respond well at all. Does anyone have any ideas?  RF12BTest.zip   1.99KB   31 downloads

I'm very interested to see how you do interfacing the Netduino to the RFM12B, as I'm trying to do the same thing. The documentation (http://www.hoperf.co..._fsk/rfm12b.htm) is a little sparse, but it looks like it might use 15 or 16-bit SPI, which is only available in the latest alpha release of the firmware.

I just installed Visual Studio 2010 C# Express, installed the Micro Framework Porting Kit 4.1, and the 32-bit Netduino sdk as linked at http://www.netduino.com/downloads/. I'm getting the same error when either creating a new Netduino project or when opening an existing project.

Fixed. The Micro Framework Porting Kit is not what you want. You want the Micro Framework (http://www.netduino....rameworkSDK.msi). The link on the get started PDF seems to be incorrect.

I just installed Visual Studio 2010 C# Express, installed the Micro Framework Porting Kit 4.1, and the 32-bit Netduino sdk as linked at http://www.netduino.com/downloads/. I'm getting the same error when either creating a new Netduino project or when opening an existing project. Please note that I do not (yet) have actual Netduino hardware to plug in. Is this required, or can I start developing against the emulator?