|
These are the effects of legalized pot... 
DURA LEX, SED LEX
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
Meat kettle.
Software Zen: delete this;
|
|
|
|
|
I winced so hard that I might have thrown my back out.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
We had a deal where you would make me funnier, smarter, and a better dancer... I saw the video... we need to talk.
New version: WinHeist Version 2.2.2 Beta I told my psychiatrist that I was hearing voices in my head. He said you don't have a psychiatrist!
|
|
|
|
|
That is sooooo funny... As it was 12 yeas ago
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
I was going to post an early version but it was in ancient greek and didn't think anyone would understand. 
New version: WinHeist Version 2.2.2 Beta I told my psychiatrist that I was hearing voices in my head. He said you don't have a psychiatrist!
|
|
|
|
|
Oh, I'm sure some know-it-all here on the site, speaks fluent ancient Greek.
|
|
|
|
|
... maybe if you translated it to ancient Geek... 
"It was when I found out I could make mistakes that I knew I was on to something."
-Ornette Coleman
"Philosophy is a study that lets us be unhappy more intelligently."
-Anon.
|
|
|
|
|
A few beers and I'll translate hieroglyphics for you, no problem.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
You obviously hadn't had enough to drink when you watched it.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Clause 8.2.1.C of the deal specifies that you are permitted to review recordings of your own actions while you were under the influence, only while you're under the influence.
Meaning, you're welcome to watch that video or have that chat, but not until you'll down a few pints.
|
|
|
|
|
So a coworker just called me and was "you have got to see this!"
Basically, he just invoked a method with some named parameters (of which two were unevaluated LINQ expressions) and the invoked method receives the parameters in the wrong order.
Parameter a gets expression b while parameter b gets expression a.
We tried evaluation the LINQ expressions first, but the result was the same.
Then we removed the names from the parameters and everything worked fine.
We also tried to make the parameters named and go down a .NET version (to 4.5.2), but the problem still persisted.
We checked the intermediate language and, indeed, the variables were loaded onto the stack in the wrong order.
What the... 
Moral of the story, don't use named parameters as they are bugged 
Example:
Just a regular method call, be it a bloated one.
public SomeClass SomeFunction(Input input)
{
SomeType outA;
AnotherType outB;
ThirdType outC;
return somefield.DoSomething(
name1: input.Field1,
name2: input.Field2,
name3: input.Field3,
name4: input.SomeCollection.SelectMany(...).Where(...).Select(...),
name5: input.AnotherCollection.Select(...),
name6: out outA,
name7: out outB,
name8: out outC
);
}I know that code ain't pretty, but somefield.DoSomething was code that was generated from an Oracle package, so yeah.
That's also why it's named, so the parameters won't mix up when someone changes the package.
modified 1-Dec-16 14:08pm.
|
|
|
|
|
Post an example
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Updated my post with an example, just some pseudo code.
There's not much to see anyway, .NET just mixes up two variables
|
|
|
|
|
Why are you using named parameters? They use more stack space than standard parameter passing, and therefore performance suffers. IMHO, they also have no tangible benefit with regards to code readability.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
modified 1-Dec-16 13:35pm.
|
|
|
|
|
John Simmons / outlaw programmer wrote: They use more stack space than standard parameter passing, and therefore performance suffers.
Don't think so, naming them is just some syntactic sugar.
Anyway, they were named because the method being called was some code generated from an Oracle package.
When the Oracle package changes so does the code, so by naming the parameters they're not messed up (well, apparently they are ).
|
|
|
|
|
John Simmons / outlaw programmer wrote: They use more stack space than standard parameter passing
Nope.
void Main()
{
Foo(1, 2);
Foo(x: 1, y: 2);
}
void Foo(int x, int y) { }
Decompiles to:
IL_0000: ldarg.0
IL_0001: ldc.i4.1
IL_0002: ldc.i4.2
IL_0003: call UserQuery.Foo
IL_0008: ldarg.0
IL_0009: ldc.i4.1
IL_000A: ldc.i4.2
IL_000B: call UserQuery.Foo
IL_0010: ret
Calling the method with named parameters compiles to exactly the same IL as standard parameter passing.
John Simmons / outlaw programmer wrote: they also have no tangible benefit with regards to code readability.
Depends on the method.
If you're using Office Interop, named parameters are much more readable than passing 500 ref missing parameters.
And if your method takes a bool - or worse, mulitple bools - then named parameters make it clearer which parameter each value relates to.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
However, passing them in an order that is different from the unnamed, normal, order does use more stack space!
public void Main()
{
Foo(1, 2);
Foo(x: 1, y: 2);
Foo(y: 1, x: 2);
}
void Foo(int x, int y) { }
IL:
IL_0000: ldarg.0
IL_0001: ldc.i4.1
IL_0002: ldc.i4.2
IL_0003: call instance void Foo(int32, int32)
IL_0008: ldarg.0
IL_0009: ldc.i4.1
IL_000a: ldc.i4.2
IL_000b: call instance void Foo(int32, int32)
IL_0010: ldarg.0
IL_0011: ldc.i4.1
IL_0012: stloc.0
IL_0013: ldc.i4.2
IL_0014: ldloc.0
IL_0015: call instance void Foo(int32, int32)
IL_001a: ret
It must do this because the passed arguments are evaluated in left-to-right order of the call, not the order that the called method expects.
(Section 7.5.1.2 of "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC#\Specifications\1033\CSharp Language Specification.docx" as installed with VS2013.)
"Fairy tales do not tell children the dragons exist. Children already know that dragons exist. Fairy tales tell children the dragons can be killed."
- G.K. Chesterton
|
|
|
|
|
Tell Microsoft - if they don't know about it, then they can't fix it.
Not that they do fix bugs, of course... 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Hmm, I've maybe had to use named parameters a handful of times but never had any issues. Possibly stupid question but have you ensured the ordering is correct? Named parameters are evaluated in order passed not by the ordering in the function passed-to. This may not be applicable but I never assume people's objects (Input in this case) are side-effect free.
Example:
static void Main(string[] args)
{
int num = 0;
Test(z: ++num, y: ++num, x: ++num);
Console.ReadKey();
}
public static void Test(int x, int y, int z)
{
Console.WriteLine($"X: {x}, Y: {y}, Z: {z}");
}
This is a pretty contrived example, but I can't reproduce with this, no matter how I arrange the named input:
static void Main(string[] args)
{
int x = 1, y = 2, z;
List<int> values = new List<int>() { 3, 4, 5, 6 };
IEnumerable<int> query1 = values.Where(num => num % 2 == 0);
IEnumerable<int> query2 = values.Where(num => num % 2 != 0);
Test(y: y, x: x, query2: query2, query1: query1, z: out z);
Console.WriteLine($"Z: {z}");
Console.ReadKey();
}
public static void Test(int x, int y, IEnumerable<int> query1, IEnumerable<int> query2, out int z)
{
Console.WriteLine("Inside Test:");
Console.WriteLine($"X: {x}, Y: {y}");
Console.Write("Even: ");
foreach (int val in query1)
Console.Write($"{val} ");
Console.Write("\nOdd: ");
foreach (int val in query2)
Console.Write($"{val} ");
Console.Write("\n");
z = 7;
}
|
|
|
|
|
I've always maintained that named parameters were a bad idea, and it sounds like your coworker has found a way to make my case.
Functions have signatures - I'm more than happy to rely on them; I should be able to remain completely ignorant of any and all implementation details (yes, I consider a parameter name to be an implementation detail I should not have to care about--ever).
IMO that's not a constraint - it's something I rely on.
|
|
|
|
|
dandy72 wrote: I consider a parameter name to be an implementation detail I should not have to care about--ever
File.Replace(string, string, string, bool)... Good luck figuring out what those parameters are 
Properly naming your variables (and classes, methods, parameters, etc.) is one of the first rules of clean code.
I don't name them when I call the function, but I sure as hell like to know what goes where.
|
|
|
|
|
Of course, it should have a name that makes enough sense that I can tell what I need to provide at a glance, without having to look at what the function does with the parameter (even assuming I had access to the source).
However my point was that I shouldn't need to know exactly how it's spelled out. For all I care, the documentation could say the third string is DriveLetter, whereas the actual implementation uses lpszDriveLetter or __drv0. Named parameters remove that abstraction (if you want to call it that).
|
|
|
|
|
I haven't run into this problem, and I haven't seen any reports of other people encountering it either. (Except yours, of course! )
Anything strange going on with the generated package?
Are you definitely using the same version of the package at run-time and compile-time?
Have you installed a non-standard version of Roslyn?
Can you reproduce the problem in a simple example project?
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
We even checkout out the project on my machine to try it there, but with the same results.
Haven't created a sample project yet.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
