I'm trying to check if input arguments to a CallExpr is null/nil in Objective C using Clang's AST
I saw that there is a method isNullPointerConstant() that seems like it will do what I want http://clang.llvm.org/doxygen/classclang_1_1Expr.html#ab56d6fd074c831a3e63b45f4f226b35a
However, I'm not really sure how to invoke this method. Specifically, what is NullPointerConstantValueDependence that it is taking in and what is NullPointerConstantKind of the return?
What I need to do is just evaluate whether an argument is null or not, a boolean return value would work fine. Is there any other way that I should be looking at?
This worked for me in the end
Expr::NullPointerConstantKind kind = expr->isNullPointerConstant(*Context, Expr::NullPointerConstantValueDependence());
If kind is > 0, means there are some form of null pointer and one can retrieve it to see the cause of it.
Related
Given a List, is it possible to test whether the list is growable?
Trying to set the length and catching an UnsupportedError seems like a solution (though it isn't clear what would happen if you just set the length to the same value). Any better solution?
There is no way to detect if a list is growable (short of using reflection to find the implementation type, which is brittle, won't work the same way in dart2js, and increases code size).
The only valid use-case we encountered was to have checks/asserts when a library returns a list. In all other cases a function/library tried to modify an argument without knowing if it was allowed to do that.
If a function/library can work destructively it should require a boolean (or similar) so that the callers can decide if their argument can be changed. The callee should never silently modify its inputs unless it is obvious (for example fillFoo(list)) or an argument tells it so (for instance computeSquares(list, inPlace: true)).
http://dartbug.com/13926 is still open, but I expect it to be closed tomorrow with status "NotPlanned".
It is possible using reflection (not straight-forward either).
I guess this isn't any better than catching the exception.
print(MirrorSystem.getName(reflect(new List.from([0,1,2], growable: true))
.type.simpleName) == ('_GrowableList'));
EDIT
It is discouraged to use the name of a symbol - see Converting a Symbol into a String
I have some code that wants to do grab some extra return values from a function and pass them forward latter on:
local ok, ... = coroutine.resume(co)
do_stuff(ok)
return ...
However, this won't run since the ... on the variable assignment is a syntax error.
I could work around this limitation by using the old "functions arguments and variables are equivalent" trick and an immediately-invoked function
return (function(ok, ...)
do_stuff(ok)
return ...
)(coroutine.resume(co))
but I imagine doing so wouldn't be very idiomatic or efficient. Are there more reasonable ways to solve this problem of handling the remaining values returned from the resume call?
EDIT: By the way, this needs to work with nil values in the extra arguments
EDIT2: Looks like using the immediately invoked function was the best way all along.
IMHO, the best way is passing vararg as parameter to helper function as you have done in your question.
The alternative way is "pack-unpack":
-- Lua 5.2 only
local t = table.pack(coroutine.resume(co))
do_stuff(t[1])
return table.unpack(t, 2, t.n)
The idiomatic way to do this with an unknown number of return values is to wrap the function call in a table constructor:
local t = { coroutine.resume(co) }
do_stuff(table.remove(t, 1))
return unpack(t) -- table.unpack(t) in lua 5.2
While this also involves creating a temporary object, it should be a lot quicker than using a closure, and it's certainly a lot neater.
I've noticed that luasocket doesn't seem to provide a way to know if a value is a luasocket object or not.
The usual approach of comparing metatables doesn't work, as different socket object types have different metatables.
There don't seem to be any consistent values in the metatable to check either (eg, same __tosting metamethods)
So: how can one know if a value they have is a luasocket object?
Since you only want to know if it's a LuaSocket object so you can get the fd, why not just look to see if the object has a getfd() method? As a bonus this will work with current and future libraries that provide this method on objects, not just LuaSocket.
This technique is known as 'duck typing'.
You don't. Generally, you're expected to keep track of that sort of thing yourself. You trust that objects you are passed are what you expect them to be. And if you're not sure, you can always use pcall to call functions on them and catch any errors.
Just discovered something rather funny:
var
Queue : TQueue <TProc>;
MyProc : TProc;
...
MyProc := Queue.Dequeue;
I think you see what is intendend here. However, the compiler thinks I want to store the Queue.Dequeue method (type "procedure of object") in MyProc and reports an error
E2010 Incompatible Types: 'TProc' und 'Procedure of object'
The workaround I came up with goes like this
MyProc := TProc (Pointer (Queue.Dequeue));
Is there a more elegant solution?
There's a bit of syntactical ambiguity there about whether the name "Dequeue" refers to the function itself, or the function's return value. And since you're dealing with an anonymous method pointer which you can assign a normal function to, it's trying to interpret that as a function assignment, not a function result assignment. Casting it to a pointer is the wrong solution, as that would force the function assignment to go through, which would then cause all sorts of fun errors when you attempt to invoke MyProc.
The correct way to fix it is by removing the syntactical ambiguity. Put an empty parenthesis after Dequeue, so that the compiler is sure that you're calling the function and not simply referencing it by name, and then it'll work.
MyProc := Queue.Dequeue();
As Mason said, there's an ambiguity in the Delphi syntax. Where TFoo.Bar is a method, it's not clear that FooValue.Bar means to refer to the result of calling TFoo.Bar, or a method pointer (or reference) TFoo.Bar itself (with implied Self argument of FooValue).
In the comments of Mason's answer, Rob Kennedy seems to suggest that the compiler simply figure this out based on the types of everything involved. This isn't simple; the compiler already does a lot of work to figure out whether you mean to refer to a method pointer value or a method call. It actually parses expressions in a different way when the expected receiver is a method pointer (or reference, or function pointer) type. The effort is especially involved when overloads are brought into the picture: the compiler scans through every overload candidate and checks for method pointer types in every parameter position, and then parses arguments differently depending on whether or not that parameter position contains a function pointer in one of the overloads. Then, if an overload that expects a function pointer isn't matched, the compiler changes the parse tree from function pointer to method call. The overloading mechanism itself needs to figure out which to use when its doing value to parameter comparisons. It's pretty messy, and it would be great if we didn't make it messier.
A prefix-style operator like # or Addr() isn't much help in resolving this ambiguity, not least because functions may return function pointers, and so on; how many # do you need to inhibit implicit (no () necessary) calling to grab the right value out? So when anonymous methods were introduced, a change in the expression parsing was made: I introduced the possibility of using () to force an invocation.
You can read more about it here:
http://blog.barrkel.com/2008/03/odd-corner-of-delphi-procedural.html
and here:
http://blog.barrkel.com/2008/03/procedurally-typed-expressions-redux.html
In Groovy types are optional so you can use either:
String foo = "foo"
foo.noSuchMethod()
or
def foo = "foo"
foo.noSuchMethod()
I assumed that the first example would generate a compile-time error, whereas the second would only fail at runtime. However, this doesn't appear to be the case. In my experience, a compile-time error is generated in neither case.
Am I right in assuming then that the only benefit of declaring the type of a reference is as a form of documentation, i.e. to communicate intentions to other programmers. For example, if I write a method such as:
def capitalize(String arg) {
return arg.toUpperCase()
}
This communicates the type of arguments that should be passed to the function much more effectively than:
def capitalize(def arg) {
return arg.toUpperCase()
}
Does the Groovy compiler perform any type-checking when types are specified?
Thanks,
Don
[Edit] Newer versions of Groovy do allow for compile-time static type checking. Code that uses this annotation IS faster than regular run-time Groovy, as many of the dynamic checks are skipped.
As Cesar said, type checking is a run-time process, one of the major reasons that Groovy is slower than Java (not that that's really bad).
You can see why this is, right? Given the dynamic nature of Groovy, it's near-impossible to tell if String has been extended somewhere else in your code to contain a method noSuchMethod(). The same goes for member type-checking, as it's entirely possible to remove a member of one type, and add a member of another type with the same name later in code. It's probably not common, but very possible.
The question is, how much type checking do you really need? You're calling the method, you really should know what arguments it takes, or if the method actually exists. Using compile-time checking to save you the time of looking it up isn't a core usefulness of the compiler.
In Groovy, type checking is done dynamically at runtime. The benefits of variables with type is that you can be sure that it contains the value you expect them to have, otherwise you get a runtime exception that you can catch and do whatever you need to do to handle the exception.
Compile time-checking in Groovy is close to impossible for types. Your example of
String foo = "foo"
foo.noSuchMethod()
Would work beautifully given that previously an instruction was executed along the lines of
String.metaClass.noSuchMethod { -> println "Yes there is such a method"}
One reason you might specify a type is to allow an IDE to help you.
def foo
foo.[ctrl-space]
... won't help you very much
List foo
foo.[ctrl-space]
... might (depending on the IDE) give you a choice of List's methods. Of course, a method that's not one of the choices might be a valid one to use, for the reasons given in other answers.
There are other automated software maintenance operations that benefit from clues about types. For example, refactoring.