Variable Argument Lists in .NET and Unmanaged Interoperability
Different programming technologies have struggled with providing powerful but easy-to-use formatted I/O. I/O formatting is turning various computer data types into streams of bytes that can be sent across the wire, such as across a serial port or across a TCPIP socket. It is inconvenient, tedious, and error prone to have a separate method call for each data element in a serial data transfer, so programming elements such as C's variable argument lists (like in C's printf function) were invented.
.NET has a different mechanism for variable argument lists—the params keyword. In the .NET intermediate language (IL, the assembly language of .NET), the parameters are turned into an array of value object references, and primitives like integers are "boxed" into object wrappers placed in the array.
Microsoft chose not to allow C-style variable argument lists through the params keyword for a number of reasons. The params keyword is not a good fit for C-style variable argument lists, it does not support out or ref passing of parameters, but C-style variable argument lists allow the values pointed to by the pointer arguments to change. Another reason why C-style variable argument lists are a bad fit for .NET is that because variable argument lists are type checked at runtime, there is a large risk of memory-access violations undetectable by the compiler that defeat the memory safety Microsoft tried to provide with the .NET programming technology.
That said, Microsoft did leave in some hidden keywords that allow C-style variable argument lists in .NET—the __arglist and __makeref keywords. A method declared with __arglist accepts a C-style variable argument list, and by wrapping a comma-separated list of variables in an __arglist() declaration, a variable-length argument list can be passed to such methods. If methods using __arglist are decorated with the DllImportAttribute, they can be used for calling such unmanaged DLL functions as printf or scanf. Reference parameters are passed by wrapping the variable name in a makeref() keyword, which is the equivalent of the C practice of putting an ampersand (&) in front of the variable to pass it its memory address rather than its value to the function being called.
These keywords were not used in the VISA header files in .NET for several reasons: The risks of memory access violations and the added burden of forcing you to understand the appropriate times to use keywords such as __arglist and __makeref were good reasons not to go down this route. Additionally, performance is a consideration. It has been reported that the performance of these hidden keywords is about five times worse than params, which makes it many times slower than a standard method call.
—D.G.
