tags:

views:

141

answers:

9

source http://technet.microsoft.com/en-us/library/ms162234%28SQL.100%29.aspx

code

//Connect to the local, default instance of SQL Server. 

  { 

     Server srv = default(Server);
     srv = new Server(); 
     //Create a linked server. 
     LinkedServer lsrv = default(LinkedServer); 
     lsrv = new LinkedServer(srv, "OLEDBSRV"); 
     //When the product name is SQL Server the remaining properties are 
     //not required to be set. 
     lsrv.ProductName = "SQL Server"; 
     lsrv.Create(); 

  } 

why to use default(Server),? -even if its like server asd = new asd(); it will still connect to the default instance!

why to use default(linkedserver) -whats the point? we still specify the srv and provider and product!

+10  A: 

default(...) is the default value operator. It evaluates to null for reference types, or the "zero" value for value types.

There's absolutely no point to it here... the variable is assigned a different value immediately. Here's the equivalent, tidier code:

Server srv = new Server(); 
//Create a linked server. 
LinkedServer lsrv = new LinkedServer(srv, "OLEDBSRV"); 
//When the product name is SQL Server the remaining properties are 
//not required to be set. 
lsrv.ProductName = "SQL Server"; 
lsrv.Create(); 
Jon Skeet
+2  A: 

The default keyword was added in .NET 2.0 to satisfy generics. It just represents the default (meaning uninitialized) value of whatever type is passed to it. For reference types, this is null; for value types, it's the "zero" value. There's really no reason to use this operator unless you're writing a generic function.

Adam Robinson
@Adam: I like using it for code contracts, when specifying the contract for an interface. You have to implement the interface, so anything returning a value has to return *something*. By explicitly using `default` I'm hoping it acts as reinforcement that we're not returning a value we particularly expect to be useful.
Jon Skeet
+1  A: 

The default(Server) will return null. Syntactically it's the equivalent of

Server srv = null;

It's convenience code which allows for uniform handling of value types and reference types, it's especially convenient when you are dealing with generics.

Check out the following reference: http://msdn.microsoft.com/en-us/library/xwth0h0d.aspx

code4life
thanks for link
+2  A: 

In your example it's not doing anything. It could be removed and the first two lines could be combined.

Server srv = new Server();

Same thing with the linked server.

LinkedServer lsrv = new LinkedServer(srv, "OLEDBSRV");
Jerod Houghtelling
A: 

By using default keyword you can assign a default value to a variable. It comes in handy when you're using generic types.

Hamid Nazari
+2  A: 

there doesnt appear to be a point, considering it is assigned immediately after. the statement in this situation is useless. You might as well put

Server srv = new Server();
Scott M.
A: 

default provides the default value of the given type (used heavily with generics). For reference types this is null and value types is the zero value.

In your situation, there is no point - you could instantiate the instance inline or specify null as you know the type...

Adam
A: 

default always zeros out a field. For reference types that means the reference is null (as null is really pointing to address zero), and for value types it means all the fields in it are zero'd in memory, effectively making numeric types zero, DateTime be DateTime.MinValue, etc.

In this case, I am assuming both Server and LinkedServer are reference types, so using default is the same as setting them to null. I assume whoever wrote this code doesn't really understand what default does.

Matt Greer
+1  A: 

The default can be useful for assigning typed null references. I have a preference for using the var keyword when declaring variables like this:

var value = default(Class);

The only way I can do this is by using default because the compiler needs type information to infer value. In your specific example it simply adds pointless verbosity.

ChaosPandion
+1 for example ..
I would *definitely* find that less readable than `Class value = null;` - I'm not one of these people who pathologically dislikes `var`, but I see no benefit in using it here.
Jon Skeet
@Jon - It is about consistency. I also find it more readable so there is opinion involved as well.
ChaosPandion
@Chaos: Consistency of what? Do you use `var` to declare *every* local variable?
Jon Skeet
@Jon - Indeed. Can I assume the *emphasis* on **every** means you are surprised?
ChaosPandion
@Chaos: Absolutely. In many cases the return type of a method isn't blindingly obvious from the method name, and in such cases I would almost never use `var`. Do you use it for integer literals as well? What's the type of `var x = 300000000;`? If you have to count the digits in a literal to work out the type of a variable, there's something wrong IMO :)
Jon Skeet
@Jon - Point 1: It forces me to write detailed method names and I don't use notepad to write my code. :) Point 2: I use literal notation `var x = 300000000L` or explicit casting `var x = (byte)1`.
ChaosPandion
@Chaos: Detailed method names don't always mean including the return type though... and it doesn't help if you're implementing an interface, for example. Basically I would find it hard going reading a codebase which used `var` *everywhere*. In moderation, yes - but I wouldn't do it everywhere.
Jon Skeet
@All - I'm with skeet on that one. There's a good section on CLR Via C# (3rd edition) stating that vars should be kept to a minimum and I generally end up only using them based on some sort of linq expression being returned. If you need to use vars for ints / decimals / strings there's something wrong
JonH
@Jon Skeet, @JonH - F# seems to pull it off quite well. It isn't for everyone though. It isn't like I am trying to convince you to use it.
ChaosPandion