I wonder what is the best way to call those API with optional location. For example:
CUresult cuStreamGetCaptureInfo_v2 ( CUstream hStream, CUstreamCaptureStatus* captureStatus_out, cuuint64_t* id_out, CUgraph* graph_out, const CUgraphNode** dependencies_out, size_t* numDependencies_out )
The document says id_out, graph_out are optional location. In python, if it is optional, we don't need to specify it. If i wanted to pass in only id_out, how can I achieve that without getting the "too few arguments" error?
In C or C++, for a function with a prototype like that, all arguments must be specified in order to get anything to compile. This doesn't have anything to do with CUDA.
For that particular function, all optional arguments are pointer arguments. It should be safe to pass a null pointer for any "optional" argument that you don't wish to specify.
Related
Is there a way in a where clause in Rust to check if a function passed as a parameter takes specified arguments?
If you're defining a function that takes a function argument, that argument has a very specific type associated with it that dictates the arguments. You cannot call that function with something that doesn't match, it just won't compile.
If you're thinking in terms of dynamic languages where the arguments are somewhat subjective, you're assuming you can make a mistake here and call it incorrectly. You can't. It's strictly disallowed.
Here is a simplified code
func MyHandler(a int) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
w.WriteCode(a)
})
}
Whenever a http request comes MyHandler will be called, and it will return a function which will be used to handle the request. So whenever a http request comes a new function object will be created. Function is taken as the first class in Go. I'm trying to understand what actually happened when you return a function from memory's perspective. When you return a value, for example an integer, it will occupy 4 bytes in stack. So how about return a function and lots of things inside the function body? Is it an efficient way to do so? What's shortcomings?
If you're not used to closures, they may seem a bit magic. They are, however, easy to implement in compilers:
The compiler finds any variables that must be captured by the closure. It puts them into a working area that will be allocated and remain allocated as long as the closure itself exists.
The compiler then generates the inner function with a secret extra parameter, or some other runtime trickery,1 such that calling the function activates the closure.
Because the returned function accesses its closure variables through the compile-time arrangement, there's nothing special needed. And since Go is a garbage-collected language, there's nothing else needed either: the pointer to the closure keeps the closure data alive until the pointer is gone because the function cannot be called any more, at which point the closure data evaporates (well, at the next GC).
1GCC sometimes uses trampolines to do this for C, where trampolines are executable code generated at runtime. The executable code may set a register or pass an extra parameter or some such. This can be expensive since something treated as data at runtime (generated code) must be turned into executable code at runtime (possibly requiring a system call and potentially requiring that some supervisory code "vet" the resulting runtime code).
Go does not need any of this because the language was defined with closures in mind, so implementors don't, er, "close off" any easy ways to make this all work. Some runtime ABIs are defined with closures in mind as well, e.g., register r1 is reserved as the closure-variables pointer in all pointer-to-function types, or some such.
Actual function size is irrelevant. When you return a function like this, memory will be allocated for the closure, that is, any variables in the scope that the function uses. In this case, a pointer will be returned containing the address of the function and a pointer to the closure, which will contain a reference to the variable a.
Is there a way to pass a function(which can be generic) to another function?
I know that with known input types and return types we can pass a function but a generic approach is needed
When reading the Go2 proposal on generic: "Type Parameters - Draft Design", I am not sure you would be able to pass as parameter a generic function without explicitly specify the type used by said function
See "Instantiating a function"
Go normally permits you to refer to a function without passing any arguments, producing a value of function type.
You may not do this with a function that has type parameters; all type arguments must be known at compile time.
That said, you can instantiate the function, by passing type arguments, but you don't have to call the instantiation. This will produce a function value with no type parameters.
// PrintInts is type func([]int).
var PrintInts = Print[int]
In systemverilog, it allows passing parameter array to lower module. Currently I have two .sv modules with parameters that use such feature. Below, lowMod is being instantiated in uppMod.
module lowMod #(parameter logic row [0:2], parameter logic col [0:1])
(output logic a, input logic b);
// main body of codes...
endmodule
and here's the uppMod.
module uppMod #(parameter logic row [0:4], parameter logic col [0:3])
(output logic a, input logic b);
lowMod #(row[1:3], col[0:1]) unit01 (.);
lowMod #(row[1:3], col[2:3]) unit02 (.);
// rest of codes...
endmodule
Constant values are assigned as parameters to the uppMod in testbench, and it works perfectly for behavioural simulation on Modelsim. But when I read it on DC Compiler, complaint pops up
Syntax error at or near token ','. (VER-294)
It complains about the comma when declaring the parameter array. Presumably, I think DC uses VCS-like Verilog simulator (is that right?), and it seems, in contrast to Modelsim, DC doesn't like this syntax.
So is there anyway to make it work? I am actually doing something like this, where these arrays are initialised to some values...
module uppMod #(parameter logic row [0:4] = '{1,1,1}, parameter logic col [0:3] = '{1,1})
(output logic a, input logic b);
lowMod #(row[1:3], col[0:1]) unit01 (.);
lowMod #(row[1:3], col[2:3]) unit02 (.);
// rest of codes...
endmodule
so that when I elaborate the design on DC, my hope is to tune the parameters to the values I want, by
elaborate -library WORK -parameters "row[0:4]=>'{1,2,3,4,5}, col[0:3]=>'{1,2,3,4}"
But that doesn't work either.
Error: Syntax error in parameter value list at or near token '[0:4]' (string position 7). (VER-279)
Any thoughts?
Thanks for your time in advance.
Tidus
DC probably does not support an unpacked array as a parameter. Try making it an packed array of bits. As a packed array, you lose the strict type checking, but it should pass the values
After a few attempts, it seems declaring the parameter logic internally within the module would do the job - simply declare them and initialise them with some values in the lowMod. In uppMod, we also do the same. But because we need to instantiate the lowMod with parametrized values, overriding is required in uppMod, and it works perfectly. In this way, we can avoid the said syntax error for both modules.
Hope this helps. Thanks.
I am working on some simple object-oriented code in MATLAB. I am trying to call one of my class methods with no input or output arguments in its definition.
Function definition:
function roll_dice
Function call:
obj.roll_dice;
When this is executed, MATLAB says:
??? Error using ==> roll_dice
Too many input arguments.
Error in ==> DiceSet>Diceset.Diceset at 11
obj.roll_dice;
(etc...)
Anyone have any ideas what could be causing it? Are there secret automatic arguments I'm unaware that I'm passing?
When you make the call:
obj.roll_dice;
It is actually equivalent to:
roll_dice(obj);
So obj is the "secret" automatic argument being passed to roll_dice. If you rewrite the method roll_dice to accept a single input argument (even if you don't use it), things should work correctly.
Alternatively, if you know for sure that your method roll_dice is not going to perform any operations on the class object, you can declare it to be a static method as Dan suggests.
For more information on object-oriented programming in MATLAB, here's a link to the online documentation.
I believe you can also get around this by declaring roll_dice to be a static method.