Predict The Output

[hatman]

hatman

I don't think using Call is a bad idea.

In fact it might be a good idea.

Obviously you can run other subs just simply using there name, dependent on how their located and named/declared.

But people reading the code might be thinking - is it a variable, is it a sub, is it a function, is it an aardvark, can it fly.

Case in point is ZVI's code... naming a subroutine Y is just evil

 

[Norie]

Don't see a problem with Y.

A lot of times when posting quick and dirty code I use t for the sub name when I create a new one.

Obviously I don't include that in what I post, best to use a descripitive sub name - helps organising, identifying etc.

Mind you that pesky aardvark seems to be changing some of my sub names when I asleep.

Perhaps I should put it out before I turn in, but that might be a bit cruel - the crazy cat might find him.

Mind you who would win if they fought, perhaps we should ask Harry Hill.

 

[ZVI]

Case in point is ZVI's code... naming a subroutine Y is just evil
--------------
“Homogenized pasteurized milk from confinement animals…”

Whether Y symbol should be considered as a logo of poor confinement animals mentioned in your post Signature?

 

[ZVI]

Well, I am sorry for use of evil Y sub name.
Agree that names should be more informative.

This example illustrates that HomogenizedPasteurizedMilk () is made approx. in 1.4 times faster than RawUnpasteurizedMilk() because it's evil method.

<font face=Courier New>
Sub PastureFedVsConfinementAnimals()
  Dim t#, evil As Boolean
  t = Timer
  For i = 1 To 10000000
    ' Comment one out of two lines below
    HomogenizedPasteurizedMilk evil
    'RawUnpasteurizedMilk evil
  Next
  t = Timer - t
  MsgBox "Evil=" & evil & " " & Format(t, "0.###") & " sec"
End Sub

Sub HomogenizedPasteurizedMilk(evil As Boolean)
  evil = True
End Sub

Sub RawUnpasteurizedMilk(evil)
  evil = False
End Sub</FONT>

BTW refer to my post #17 issue, I don't know why, but
.Evaluate ("=DAY(" & CLng(x) & ")") or setting format of A1 cell to General/Numeric before .Evaluate("=DAY(" & [A1] & ")") solves issue.

Regards,
Vladimir

 

[Oorang]

OK, so here is the explanation:
When you pass a variable "By Value" (ByVal) to a procedure a new spot in memory is created and the value the procedure received is copied into that new spot. So if "foo" is created ByVal it's actually a copy of the variable it was passed.
If you pass the same variable By Reference (ByRef) the procedure will say OK, the variable is located at XYZ memory address, and while the calling procedure was referring to that address as "j", we are going to refer to it as "foo". If the procedure is altering the same memory address we were calling "j", when we get back up to where that address is referred to as "j" again... Of course the value has changed. So no mystery as to how what happened to "j". But what happened to "i" and "k"?
Well that gets a little more complicated... Let's talk about "k" first. Using a math operator is essentially calling a native function. Think about this imaginary function like this:

Sub Example()Code:
    Dim x As Long
    x = 1 + 2       'This
    x = Add(1, 2)   'Is a lot like this.
End Sub
 
Function Add(ByVal value1 As Variant, ByVal value2 As Variant) As Variant
    'Magic
End Function

Performing an operation is a lot like a function in that it still has inputs (parameters) and more importantly, output. Now about that output... Have you ever wondered where function's output goes to if you don't load it into a variable? It gets loaded into a temporary spot in memory, and that spot is thrown away when the procedure ends. So when you do "MySub k + 20" you are not passing MySub the address to k, you are passing it the temporary address where the function's output went. So MySub received 30 (the output of k + 20) alters the memory location of the output, but not k itself. So k is never changed.
So about i... Well turns out, that's just a bug that got turned into a feature. If you want to pass a variable to a ByRef parameter without worrying about your value getting changed, you surround it in parentheses. (I know, not too obscure right?)

 

[ZVI]

...
So about i... Well turns out, that's just a bug that got turned into a feature...

It is feature but not the bug. Compilation always includes the parsing of expression for further calculation. When parser have found parentheses() then expression surrounded by parentheses is expected because it is a rule of parsing. Compiler in this case always creates temporary variable for storing result of evaluated expression even if expression is the single variable.
The rule is not the bug. The bug is something that contradicts declared rules.
But sometimes the rule can be strange or even erroneous

 

[Oorang]

I suppose it's a matter of perspective. To your point, it is in parenthesis, therefore it's a expression. An unforgiving me agrees. On the other hand, a lot of effort went into making VB a forgiving language. So you could make the case that the compiler can/should detect that the expression wasn't actually doing anything. But to be honest, now that I know about it... I like it the way it is. It's nice to know I can prevent a ref parameter from changing my variables if I want too

By the way... Props to everyone for voting so honestly. I expected to see a lot of people claiming 4s

 

[Oorang]

I kinda cheated because I've seen the thread that prompted Aaron to start his one, so I had a wee heads-up on it ....

lol I just realized who you were. I feel honored and stuff