I remember it. I don't think there is anything similar, unfortunately.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
:rose:
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
That is hilarious! I haven't laughed that hard in ages!
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
You can selectively enable/disable most of the rules but there isn't a way to edit a rule. Putting using statements inside the namespace is recommended for the following reasons:
From http://www.thewayithink.co.uk/stylecop/sa1200.htm[^] There are subtle differences between placing using directives within a namespace element, rather than outside of the namespace, including: 1. Placing using-alias directives within the namespace eliminates compiler confusion between conflicting types. 2. When multiple namespaces are defined within a single file, placing using directives within the namespace elements scopes references and aliases.
The spacing reccomendations are most likely due to screen space concerns. Anyway, the code you show would look like this to meet the StyleCop settings:
if (value < maximumValue)
{
}
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
Take a look at the document here[^]. In a nutshell: There are subtle differences between placing using directives within a namespace element, rather than outside of the namespace, including: 1. Placing using-alias directives within the namespace eliminates compiler confusion between conflicting types. 2. When multiple namespaces are defined within a single file, placing using directives within the namespace elements scopes references and aliases.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
Currently everything I have heard points to an "official" relase date as "Holiday Season 2010", which realistically means sometime between late October and early January.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
The second case is not boxing because you are assigning a literal value to the object. A literal value essentially takes on the type of the object to which it is assigned (not the real implementation details, but it should get the idea across). That would mean that a literal integer value is only a value type if it is assigned to a value type. In the second example, the literal values are assigned to object variables, so no boxing occurs. Any time a boxing operation occurs, the value of the value type being boxed is copied into the reference type. As for what the second case is called, there isn't a name since there is no boxing or unboxing operations. It is simply variable assignment. In your func example, you have a function with two out object parameters. In the body of the function, you are essentially doing two things:
int value type and then assign it to an object argument. This is a boxing operation.2 to an object argument. Since you are assigning a literal value, this is not a boxing operation.Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
Yes, that's pretty much correct.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
If you had value types to start with, you are correct. Here is the difference...
int iOne = 1;
int iTwo = 2;
object one = iOne;
object two = iTwo;
In this case, you have created two value types (iOne and iTwo, which you then assign to object variables. At the point of the assignment, the runtime is boxing the value types to reference types. However, in your case you have
object one = 1;
object two = 2;
Which is not the same. Here you are assigning the literal values to the object variables, which don't create any value types.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
I agree, it does seem like a bad design choice. That being said, this is actually a bug (at least in my opinion) in the project template used for an empty project. If you look at the template for a Windows Forms project, it includes the following:
<ItemGroup>
<Reference Include="System"/>
$if$ ($targetframeworkversion$ >= 3.5)
<Reference Include="System.Core"/>
<Reference Include="System.Xml.Linq"/>
<Reference Include="System.Data.DataSetExtensions"/>
$endif$
$if$ ($targetframeworkversion$ >= 4.0)
<Reference Include="Microsoft.CSharp"/>
$endif$
<Reference Include="System.Data"/>
<Reference Include="System.Deployment"/>
<Reference Include="System.Drawing"/>
<Reference Include="System.Windows.Forms"/>
<Reference Include="System.Xml"/>
</ItemGroup>
Looking at the project template for an empty project, there is no such ItemGroup. You could modify the template to include one, but I'm not sure it's worth the trouble.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
Very nice. Los Angeles to Washington, DC in 64 minutes! Normal flights take around 5 hours at the shortest.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
ahmed zahmed wrote:
One would expect that the comparators of the boxed values would be used. so, the result would be true, as I initially expected.
Why do you think these are being boxed? You are clearly assigning values to an object instance. This doesn't result in any boxing operations.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
I would expect it to be false. You are comparing two object instances for reference equality, and clearly one is not in the same memory location as two.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
I did say that. Of course, it was after I asked why she opened it. :doh:
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
Is this the one? http://nplus1.org/[^]
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
:)
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
John Simmons / outlaw programmer wrote:
Amazon is notorious for delivering stuff a little faster than they promise, especially if the order is fulfilled by Amazon.
Definately. Will keep that in mind next time.
John Simmons / outlaw programmer wrote:
Damage is done, but you should have just rolled with it. So what, she got it a bit early...
She hasn't gotten anything really nice in a while (money has been too tight) so this would have been a nice surprise.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
fat_boy wrote:
Just why cant they keep themselves to themselves? Always meddling. Always suspicious.
Yep...
fat_boy wrote:
Probably thought it was a blow up doll!
Nope...box was way too small.
fat_boy wrote:
Anyway, just what is a Kindle?
It is an electronic reading device from Amazon. http://amazon.com/kindle[^]
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
Long day, lack of food, any number of reasons for not thinking about it...
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
Maybe so...but it's worth it. :-D
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai