What exactly do in, out and inout - 'directional' operators mean in CORBA IDL function parameters?
From Ciaran McHale's free online book, CORBA Explained Simply:
The parameters of an operation have a
specified direction, which can be in
(meaning that the parameter is passed
from the client to the server), out
(the parameter is passed from the
server back to the client) or inout
(the parameter is passed in both
directions).
So an in parameter is very similar to "traditional" function parameters in that the caller must pass a value for them and that value is used by the server to do its work.
An out parameter is just like a return value, so the caller never populates it with a value. It just magically has a value when the function returns (assuming an exception wasn't thrown) because the server is responsible for putting a value inside it as part of its execution rules. You can have as many out parameters as you want, allowing you to return multiple distinct objects or values without having to first combine them into a struct.
An inout parameter combines the two concepts above. The caller must populate all inout parameters with valid data but those values may be different after the function returns because the server is free to put new data in there.
Related
I am using OCMock as a mocking framework in my iOS project. When I try to use OCVerify functionality to test that a certain method is invoked, I came across a problem of passing primitive types as parameters.
Here is an example to show problem:
1-) Cases successfully verify invocation when no parameter or an object parameter.
OCMVerify([mockedClass methodToCall])
OCMVerify([mockedClass methodWithObjectParameter:[OCMArg any]);
2-) When I want to verify a method that takes an int as a parameter:
OCMVerify([mockedClass methodWithIntParameter:[OCMArg any]);
In this case [OCMArg any] doesn't act like as expected. It returns an actual integer and that causes a mismatch of parameter values. In reality I do not care if that integer value is correct or not. My only consideration is if the method is called with any integer regardless of its value.
I want to know that is there a way to have exact same effect of [OCMArg any] has on objects when using primitive types as parameters?
Please see section 4 in the documentation.
Is there a way to return a struct from an imported function in MQL4, without having to pass it as a parameter and making a memcpy?
Be cautious with any kind of DLL-interfacing, MQL4 Documentation states:
Passing ParametersAll parameters of simple types are passed by values unless it is explicitly indicated that they are passed by reference. When a string is passed, the address of the buffer of the copied string is passed; if a string is passed by reference, the address of the buffer of this string without copying it is passed to the function imported from DLL.Structures that contain dynamic arrays[], strings, classes, other complex structures, as well as static or dynamic arrays[] of the enumerated objects, can't be passed as a parameter to an imported function.When passing an array to DLL, the address of the beginning of the data buffer is always passed (irrespective of the AS_SERIES flag). A function inside a DLL knows nothing about the AS_SERIES flag, the passed array is a static array of an undefined length; an additional parameter should be used for specifying the array size.
More glitches apply... Then how to make it work?
Maybe a straight, heterogeneous multi-party distributed processing, which communicates rather results than function calls, independent of all nightmares of maintaining just DLL-imported functions API changes, is a way safer way to go. Using this approach for the last few years and since than have no problems with New-MQL4.56789 string-s that seized to remain string-s and silently started to become struct-s etc.
Worth to know about.
Anyway, welcome and enjoy the Wild Worlds of MQL4 -- may enjoy to click and read other posts on issues in MQL4/DLL integration and/or signalling/messaging in MQL4 domains. Feel free to ask more
I am looking for a way to enumerate swift method parameters, without explicitly naming them.
To be specific, I want to log all parameters in an arbitrary closure - preferably with both name and value. It would also be nice to have access to other meta-information about the current closure: name of method if any, return type, ...
Are there any ways to access this information?
Thanks!
I'm trying to setup a mock function that will return a value which is based on the input. The only way to access the input parameter that I know of is via the WillExecute method. However, you have to specify a When clause, and that When clause expects me to define an input value along with the method, in the following fashion:
aMock.Setup.WillExecute(function ...).When.myFunc(1);
I'm kinda forced to say: call that anonymous function, whenever myFunc(1) is called. I'd like to be able to do the same, but on every possible parameter to myFunc, with a kind of wildcard marker in the parameter to myFunc (conceptually):
aMock.Setup.WillExecute(function ...).When.myFunc(*);
Is something like this possible? Basically a When clause that will match any value passed as parameter.
Someone might be tempted to point out the WillReturnDefault value, but method does not have access to the actual parameters of the call, as WillExecute does, so I won't be able to setup anything but a constant value.
Thanks.
Ok, I missed the fact that there was an overloaded version of WillExecute that will do exactly that:
//Will exedute the func when called with the specified parameters
function WillExecute(const func : TExecuteFunc) : IWhen<T>;overload;
//will always execute the func no matter what parameters are specified.
procedure WillExecute(const AMethodName : string; const func : TExecuteFunc);overload;
This way I can tell the mock to execute the passed anon whenever the method is called, regardless of its parameters, while still providing access to them. Exactly what I was looking for. Closing question. Thanks.
This can also be solved by using parameter matching:
aMock.Setup.WillExecute(function ...).When.myFunc(It0.IsAny<Integer>);
In one of the Delphi demo applications, I've stumbled upon some syntax that I didn't know the Delphi compiler accepted:
// ......\Demos\DelphiWin32\VCLWin32\ActiveX\OleAuto\SrvComp\Word\
// Main.pas, line 109
Docs.Add(NewTemplate := True); // note the assignment
I can't seem to reproduce this type of parameter passing in my own code, and I never see anyone use it. So these are my questions:
Can i use this in "normal" methods and is it part of "the Delphi Language", or is this some compiler hack for automation objects?
What's needed in order to be able to use this?
Is this anything like C#4's named and optional parameters?
Additional information: I usually pass
records or simple classes when there
are many optional parameters to
methods, but it looks like I wouldn't
need that with this syntax. I'm aware
of default parameter values, but their
usefulness is limited because you
cannot provide any parameters to the
right of an omitted one. In JavaScript
I'm using this named parameter style
all the time (be it with different
syntax), and it's powerful.
Clearly the Delphi language supports named parameters since they appear right there in sample Delphi code. Delphi supports named parameters on automation objects, which are objects that implement the IDispatch interface. There are restrictions on the types the parameters and return types can have; in particular, they can't be Delphi classes.
I don't think the convenience you seek from named parameters would outweigh the performance hit you'd take by having every method call routed through the IDispatch.Invoke method. A call may also need to use GetIDsOfNames first. You don't see this in more code because late binding is usually something people try to avoid. Use early binding whenever possible to avoid the cost of looking up dispatch IDs and indirect method invocations.
Delphi supports optional parameters in non-automation code by allowing default values. You can omit the actual parameters for any parameter with a default value as long as you also omit the actual parameters of all subsequent parameters — the compiler ensures that a function's declaration allows for that.
I think optional parameters are overrated. They save time for the (one) person writing the code, but not for the (many) people reading the code. Whoever's reading it needs to know what the default values will be of any unspecified parameters, so you may as well just provide all the values explicitly anyway.
If you declare your procedure like so:
procedure DoSomething(AParam : integer = 0);
... it will assume a value of 0 for the parameter if it isn't given. As I recall, parameters with default values have to be at the end of the call, so like this:
procedure DoSomething(AFirstParam : string; AParam : integer = 0);
not like this:
procedure DoSomething(AParam : integer = 0; ASecondParam : string);
It is basically "some compiler hack for automation objects". I sometimes have to use it for Excel and Word automation.
e.g.
MSExcel.Application.Cells.Replace(What:='', Replacement:='', LookAt:=xlPart,
SearchOrder:=xlByRows, MatchCase:=False, SearchFormat:=True, ReplaceFormat:=True);
Is equivalent to VBA
Application.Cells.Replace(What='', Replacement='', LookAt=xlPart, _
SearchOrder=xlByRows, MatchCase=False, SearchFormat=True, ReplaceFormat=True)