|
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.
|
|
|
|
|
Can you not see the bovines, because of their cowmooflage?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
cowmooflage: Moove on, nothing to see here
Sin tack ear lol
Pressing the "Any" key may be continuate
|
|
|
|
|
That's an udderly ridiculous suggestion!
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Cud chew repeat that?
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Where's the beef?
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
This is bull***t!
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
|
|
|
|
|
Is there a joke hidden in there?
|
|
|
|
|
no I think that's a yoke
Sin tack ear lol
Pressing the "Any" key may be continuate
|
|
|
|
|
|
Now you're just milking it!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
