Output parameters in Visual C#

Maker Code39 in Visual C# Output parameters

As Book 1 discusses, Output parameters are parameters in the method signature that actually change the value of the variable that is passed into them by the user The parameter references the location of the original variable, rather than creating a working copy Output parameters are declared in a method signature with the out keyword You can have as many as you like (well, within reason), although if you use more than a few, you probably should use something else (a generic list, maybe )

An Output parameter might look like this in a method declaration:

public static void Schedule(int courseId, out string name, out DateTime scheduledTime) { name = something ; scheduledTime = DateTimeNow; }

Following the rules, we should be able to make one of these parameters optional by presetting a value But, sigh, it doesn t work, as shown in Figure 2-1

Unlike reference parameters, it makes sense that Output parameters don t support default values The Output parameter is exactly that output, and setting the value should happen inside the method body Keep in mind the purpose of optional parameters resolving the need for heavily overloaded methods Because Output parameters aren t expecting a value coming in any way, it doesn t benefit the programmer to have default values

Hand in hand with the concept of optional parameters are named parameters If you have more than one default parameter, you need a way to tell the compiler which parameter you are supplying! For example, look at the additall method earlier in this chapter, after optional parameters are implemented:

public static int addit(int z, int y, int x = 0, int w = 0, int v = 0) { return z + y + x + w + v; }

Clearly the order of the parameters doesn t matter in this implementation, but if this were in a class library you might not know that the order of the parameters is a non-issue! How would you tell the compiler to skip x and w if you want to supply v In the old days, you would do this:

int answer = additall(3,7, , ,4);

Fortunately, we don t have to do that anymore Now, with named parameters, we can say:

int answer = additall(z:3, y:7, v:4);

The nonoptional parameters don t have to be named, because the position is assumed since they are required anyway Nonetheless, it is good practice to name them If you skip naming them, you have this instead: int answer = additall(3, 7, v:4); You have to admit that this is a little harder to read One would have to go back to the method signature to figure out what is happening

Problems begin when you have optional arguments and overloaded methods in the same method signature Because C# allows for differently named parameters in overloads, things can get sort of hairy Take for example:

class Course { public void New(object course) { } public void New(int courseId) { } }

Try calling the New method with something like this:

Course course = new Course(); courseNew(10);

Here, the runtime picks the second overload because 10 better matches an int than an object The same is true when dealing with overloaded method signatures with optional parameters The tiebreaker goes to the overload with the fewest casts required to make it work

Book VIII: New Features in C# 40

he Component Object Model, usually called COM, is a standard for the interface of software bits at the binary level Because it is binary, it is language-neutral, which was Microsoft s goal when the company introduced COM in 1993 COM is a language-neutral way to implement objects in a lot of different environments COM is as an umbrella term for a lot of different technologies in the Microsoft world OLE, OLE2, ActiveX, COM+, and DCOM are all versions of the same idea just implemented in different ways The problem with COM is networking Although a thorough explanation is outside the scope of this book, it is important to understand that Microsoft s answer to broadly distributed applications in the 1990s was less than good DCOM, or Distributed COM, was fraught with problems When XML Web services entered the scene in the late 1990s with SOAP, Microsoft just put a wrapper around COM that translated to and from SOAP In the background, however, they were planning a much more sophisticated messaging system for Windows That system eventually became ASPNET Web services, and then WCF in its latest iteration Applications that are sewn to the desktop don t really use DCOM, though, so they have been slow to move to services, and therefore slow to move to NET These applications still live in COM, so we still need to interact with COM even in this service-oriented, NET world we live in What applications could be so Neanderthal How about Microsoft Office Yup Microsoft Office is the biggie, and it is why C# 40 includes a bunch of COM interoperability features, collectively called Interop Improvements