Here's something I know is probably possible but I've never managed to do
In VS2005(C++), While debugging, to be able to invoke a function from the code which I'm debugging.
This feature is sometimes essential when debugging complex data structures which can't be explored easily using just the normal capabilities of the watch window.
The watch window seem to allow writing function calls but every time I try it it gives me one error or another.
Error: symbol "func" not found
Error: argument list does not match function
Error: member function not present
Did anyone ever succeed in making this work properly?
What am I missing here?
Edit: clearly, the function called should be a symbol that exists in the current scope the debugger is in.
Ok, Here's what I found
CXX0040 means that "The C expression evaluator does not support implicit conversions involving constructor calls."
CXX0047 means that "Overloaded functions can be called only if there is an exact parameter match or a match that does not require the construction of an object."
So combined it means that If I want to call a function none of the arguments should have an implicit conversion and none of the arguments should need a construction.
"implicit conversion" in this context seem to include trivial things like converting 'String' to 'const String&'.
"construction" seem to include trivial copy-construction. so passing by value anything that is not a primitive type will result in an error.
So this basically leaves functions that take only primitive types or pointers.
I have just tested this theory successfully.
So if you want to be able to call a method from the watch window, add an overload which takes only pointers and primitives and in the watch window pass the arguments appropriately. To pass an object that is not a primitive pass its address.
The watch window is limited by the context wherein your current code is, e.g., when your code enters a function and you try to access another function that is hidden from the scope of your current function, it won't work.
If you invoke a function in the watch window, make sure that it is visible and accessible from the current scope.
To my knowledge, you can't execute code from the Watch window while debugging unmanaged C++. This does work for C# (and probably VB.NET and managed C++, but I'm not positive on that). So likely it allows it because it works for some languages, but not others.
We find this works in a very hit and miss manner. Some very simple functions (incl. member functions) work, typically simple property getters. Other more complex functions don't work and give an error.
I've never been able to discern the precise rules ...
I haven't tested this, but I always thought that was what the immediate window was for (executing code)
Cameron
It's the "Immediate" window that you want. And you're limited to what's visible from where your current breakpoint is. Local variables, and functions on that class (or globals)
In my experience, there are some shortcomings with the immediate window. You can't call your classes' member functions if the classes come from a different DLL, but get misleading error messages. If anything is in the same DLL (e.g. by statically linking in all other stuff), calling members is fairly reliable. But complex stuff may or may not work, as mentioned by others.
Related
Right now, I am trying to call a function in C++ through a Json object. The Json object would provide me with the name of the callee function and all the parameters. I will be able to extract the parameters using a for loop, but I am not sure how I can pass them in. For loop only allows me to pass arguments one by one, and I did not find a way to call a function besides passing in all the arguments at once.
I've made a temporary solution of:
if (parameter_count == 1)
func(param_1);
if (parameter_count == 2)
func(param_1, param_2);
...
This solution seems would not work for all cases since it can only work for functions with a limited number of arguments (depending on how many ifs I write). Is there a better way for this? Thanks!
EDIT: Sorry if I was being unclear. I do not know anything about func. I will be reading func from DLL based on its string name. Since I can't really change the function itself, I wouldn't be able to pass in a vector or struct directly.
Or perhaps did I have the wrong understanding? Are we allowed to pass in a single vector in place of a lot of parameters?
Sorry for making a mess through so many edits on this question. Brandon's solution with libffi works. Thanks!
So the problem as I understand it is that you have a void * pointer (which would come from your platform's DLL loading code) which "secretly" is a pointer to a function with a signature which is only known at runtime. You'd like to call this function at runtime with specified arguments.
Unfortunately, this is not possible to do cleanly with standard C++ alone. C++ cannot work with types that are not present in the program at compile-time, and since there is an infinite number of potential function signatures involved here there is no way to compile them all in.
What you'll want to do instead is manually set up the stack frame on your call stack and then jump to it, either via inline assembly or via some library or compiler extension that accomplishes this for your platform.
Here is a simple example of doing this via inline assembly. (To do this in general you will need to learn your platform's calling convention in detail, and needless to say this will constrain your program to the platform(s) you've implemented this for.)
I haven't actually tried it, but gcc has a compiler extension __builtin_apply that is apparently just meant to forward the arguments from one method wholesale to another but which could perhaps be used to accomplish something like this if you learned the (apparently opaque) description of the method.
[Update: Apparently I missed this in the comments, but Brandon mentioned libffi, a library which implements a bunch of platforms' calling conventions. This sounds like it might be the best option if you want to take this sort of approach.]
A final option would be to constrain the allowed signatures of your functions to a specified list, e.g. something like
switch(mySignature)
{
case VOID_VOID:
dynamic_cast<std::function<void(void)> *>(myPtr)();
break;
case VOID_INT:
dynamic_cast<std::function<void(int)> *>(myPtr)(my_int_arg_1);
break;
// ...
}
(Syntax of the above may not be 100% correct; I haven't tested it yet.) Whether this approach is sensible for your purposes depends on what you're doing.
TL;DR
Is there a way to detect using macros/templates/magic if a function was called from a member function or from a free/static function?
Some context
For debugging purposes, I implemented a macro called TRACE(fmt, ...) which writes to file a message with formatted output, with extra information for context (e.g. timestamp, file, function). For an example, calling TRACE("Hello %s", "world!"); will write (2/10/2019 22:32:58 func#file.cpp:27) Hello world!.
Recently, I noticed that in member functions I usually print the address of the object (this) to have some extra context and differentiate between calls to members of different objects.
As this need is very common, I'd want to improve my TRACE macro to output this if invoked from a member function. Unfortunately, I have no idea how to implement this check - "is invoked from a context of a member?"
To clarify, I want to implement a macro TRACE that acts as before in non-member functions, but in member functions the output message will be different and more similar to (2/10/2019 20:32:58 func#file.cpp:27 0x80808080) Hello world!.
To do that, I think I need to differentiate between "macro is invoked from a member function" and "macro is invoked from a non-member function".
My Questions
Can I somehow check if my macro was called from a member function or not?
If not, can I somehow implement the TRACE macro I want to have?
Note that I use GCC, but I'd prefer to have a cross-platform solution.
Things I tried
At first, I tried to check if this is defined, but as it is a keyword it is always "not defined" (defined(this) is false). Moreover, if I try to use this outside of a member function, I get a compilation error. In GCC it is invalid use of 'this' in non-member function. Therefore, it seems that the solution will need to get this information in a more hack-y way, but I'm not sure what it should be.
As an example to how my TRACE macro looks like, you can see this link. I wish that using TRACE in a member function (e.g. in the ctor of A) will "automatically" print the value of this, without needing to pass it explicitly to the macro
In C++ it is possible to declare that a function is const, which means, as far as I understand, that the compiler ensures the function does not modify the object. Is there something analogous in C++ where I can require that a function is pure? If not in C++, is there a language where one can make this requirement?
If this is not possible, why is it possible to require functions to be const but not require them to be pure? What makes these requirements different?
For clarity, by pure I want there to be no side effects and no use of variables other than those passed into the function. As a result there should be no file reading or system calls etc.
Here is a clearer definition of side effects:
No modification to files on the computer that the program is run on and no modification to variables with scope outside the function. No information is used to compute the function other than variables passed into it. Running the function should return the same thing every time it is run.
NOTE: I did some more research and encountered pure script
(Thanks for jarod42's comment)
Based on a quick read of the wikipedia article I am under the impression you can require functions be pure in pure script, however I am not completely sure.
Short answer: No. There is no equivalent keyword called pure that constrains a function like const does.
However, if you have a specific global variable you'd like to remain untouched, you do have the option of static type myVar. This will require that only functions in that file will be able to use it, and nothing outside of that file. That means any function outside that file will be constrained to leave it alone.
As to "side effects", I will break each of them down so you know what options you have:
No modification to files on the computer that the program is run on.
You can't constrain a function to do this that I'm aware. C++ just doesn't offer a way to constrain a function like this. You can, however, design a function to not modify any files, if you like.
No modification to variables with scope outside the function.
Globals are the only variables you can modify outside a function's scope that I'm aware of, besides anything passed by pointer or reference as a parameter. Globals have the option of being constant or static, which will keep you from modifying them, but, beyond that, there's really nothing you can do that I'm aware.
No information is used to compute the function other than variables passed into it.
Again, you can't constrain it to do so that I'm aware. However, you can design the function to work like this if you want.
Running the function should return the same thing every time it is run.
I'm not sure I understand why you want to constrain a function like this, but no. Not that I'm aware. Again, you can design it like this if you like, though.
As to why C++ doesn't offer an option like this? I'm guessing reusability. It appears that you have a specific list of things you don't want your function to do. However, the likelihood that a lot of other C++ users as a whole will need this particular set of constraints often is very small. Maybe they need one or two at a time, but not all at once. It doesn't seem like it would be worth the trouble to add it.
The same, however, cannot be said about const. const is used all the time, especially in parameter lists. This is to keep data from getting modified if it's passed by reference, or something. Thus, the compiler needs to know what functions modify the object. It uses const in the function declaration to keep track of this. Otherwise, it would have no way of knowing. However, with using const, it's quite simple. It can just constrain the object to only use functions that guarantee that it remains constant, or uses the const keyword in the declaration if the function.
Thus, const get's a lot of reuse.
Currently, C++ does not have a mechanism to ensure that a function has "no side effects and no use of variables other than those passed into the function." You can only force yourself to write pure functions, as mentioned by Jack Bashford. The compiler can't check this for you.
There is a proposal (N3744 Proposing [[pure]]). Here you can see that GCC and Clang already support __attribute__((pure)). Maybe it will be standardized in some form in the future revisions of C++.
In C++ it is possible to declare that a function is const, which means, as far as I understand, that the compiler ensures the function does not modify the object.
Not quite. The compiler will allow the object to be modified by (potentially ill-advised) use of const_cast. So the compiler only ensures that the function does not accidentally modify the object.
What makes these requirements [constant and pure] different?
They are different because one affects correct functionality while the other does not.
Suppose C is a container and you are iterating over its contents. At some point within the loop, perhaps you need to call a function that takes C as a parameter. If that function were to clear() the container, your loop will likely crash. Sure, you could build a loop that can handle that, but the point is that there are times when a caller needs assurance that the rug will not be pulled out from under it. Hence the ability to mark things const. If you pass C as a constant reference to a function, that function is promising to not modify C. This promise provides the needed assurance (even though, as I mentioned above, the promise can be broken).
I am not aware of a case where use of a non-pure function could similarly cause a program to crash. If there is no use for something, why complicate the language with it? If you can come up with a good use-case, maybe it is something to consider for a future revision of the language.
(Knowing that a function is pure could help a compiler optimize code. As far as I know, it's been left up to each compiler to define how to flag that, as it does not affect functionality.)
I have to maintain an old piece of code which does not work correctly anymore when compiled on 64k machines.
I have a function "solve" calling another function "funct" passed as a pointer:
int solve(double*x,double xA,double xB,double zeps,double funct(double x,double*),...)
Therefore, "solve" can be used with different possible functions as for example :
double isDgood(double D,double*Y);
From within the function "solve", it was possible to call the function "funct" and access its arguments using:
fA=funct(xA,(double*)(&funct+1));"
Although I am not familiar with this syntax, I guess that the developer was assuming that the unspecified arguments were just pushed in the stack. However, this code does not work anymore on 64k platforms. How can I correct this code? Should I specifically use Va_list?
Thanks you very much for your help.
That's horrifically undefined behaviour. If you want to access the argument, you will have to pass them around.
Is there a way to determine how many parameters a Lua function takes just before calling it from C/C++ code?
I looked at lua_Debug and lua_getinfo but they don't appear to provide what I need.
It may seem a bit like I am going against the spirit of Lua but I really want to bullet proof the interface that I have between Lua and C++. When a C++ function is called from Lua code the interface verifies that Lua has supplied the correct number of arguments and the type of each argument is correct. If a problem is found with the arguments a lua_error is issued.
I'd like to have similar error checking the other way around. When C++ calls a Lua function it should at least check that the Lua function doesn't declare more parameters than are necessary.
What you're asking for isn't possible in Lua.
You can define a Lua function with a set of arguments like this:
function f(a, b, c)
body
end
However, Lua imposes no restrictions on the number of arguments you pass to this function.
This is valid:
f(1,2,3,4,5)
The extra parameters are ignored.
This is also valid:
f(1)
The remaining arguments are assigned 'nil'.
Finally, you can defined a function that takes a variable number of arguments:
function f(a, ...)
At which point you can pass any number of arguments to the function.
See section 2.5.9 of the Lua reference manual.
The best you can do here is to add checks to your Lua functions to verify you receive the arguments you expect.
You can determine the number of parameters, upvalues and whether the function accepts variable number of arguments in Lua 5.2, by using the 'u' type to fill nups, nparams, isvararg fields by get_info(). This feature is not available in Lua 5.1.
I wouldn't do this on the Lua side unless you're in full control of Lua code you're validating. It is rather common for Lua functions to ignore extra arguments simply by omitting them.
One example is when we do not want to implement some methods, and use a stub function:
function do_nothing() end
full_api = {}
function full_api:callback(a1, a2) print(a1, a2) end
lazy_impl = {}
lazy_impl.callback = do_nothing
This allows to save typing (and a bit of performance) by reusing available functions.
If you still want to do function argument validation, you have to statically analyze the code. One tool to do this is Metalua.
No, not within standard Lua. And is Aaron Saarela is saying, it is somewhat outside the spirit of Lua as I understand it. The Lua way would be to make sure that the function itself treats nil as a sensible default (or converts it to a sensible default with something like name = name or "Bruce" before its first use) or if there is no sensible default the function should either throw an error or return a failure (if not name then error"Name required" end is a common idiom for the former, and if not name then return nil, "name required" end is a common idiom for the latter). By making the Lua side responsible for its own argument checks, you get that benefit regardless of whether the function is called from Lua or C.
That said, it is possible that your modules could maintain an attribute table indexed by function that contains the info you need to know. It would require maintenance, of course. It is also possible that MetaLua could be used to add some syntax sugar to create the table directly from function declarations at compile time. Before calling the Lua function, you would use it directly to look up any available attributes and use them to validate the call.
If you are concerned about bullet-proofing, you might want to control the function environment to use some care with what (if any) globals are available to the Lua side, and use lua_pcall() rather than lua_call() so that you catch any thrown errors.
The information you ask for is not available in all cases. For example, a Lua function might actually be implemented in C as a lua_CFunction. From Lua code there is no way to distinguish a pure Lua function from a lua_CFunction. And in the case of a lua_CFunction, the number of parameters is not exposed at all, since it's entirely dependent on the way the function is implemented.
On the other hand, what you can do is provide a system for functions writers (be it in pure Lua or in C) to advertise how many parameters their functions expect. After creating the function (function f(a, b, c) end) they would simply pass it to a global function (register(f, 3)). You would then be able to retrieve that information from your C++ code, and if the function didn't advertise its parameters then fallback to what you have now. With such a system you could even advertise the type expected by the parameters.