I have following code:
Check#tab_info{login_errors = 0},
{ok, PID};
But i get warning when i try to compile it:
the result of the expression is ignored (suppress the warning by assigning the expression to the _ variable)
What's wrong? How can i fix it?
Thank you.
Well, the compiler is telling you exactly what's wrong :) You create a new #tab_info record, but never bind it to any variable. The code is therefore meaningless and the compiler is telling you so. Changing the Check variable (or more correctly, creating a new one) won't have any effect unless you return it. Check is not a global variable, like it might be in imperative languages. Also, changing a variable you receive as an argument to a function, will not result in a change in how the caller sees the variable.
You want to bind the expression to some variable and then do something meaningful with it.
NewCheck = Check#tab_info{...}
{ok, Pid, NewCheck}
As a side note, if instead you did a function call and did not bind the return value to anything, the compiler would not complain as the function might have side-effects and this might be the reason you called the function in the first place.
Related
C# discards prevent allocation of values not needed. Is there something similar in dart? I saw a lot of people use the underscore as if it were a discard, but using two at the same time (like this (_, _) => method() will say the variable _ is already defined.
Dart does allow you to use the same discard operator as C#. You can define a variable or final with a name of _. This works well with the rule avoid-ignoring-return-values (Dart Code Metrics) Importantly, if you name the variable with this, you will not encounter the warning unused-local-variable. However, there is another code rule called no_leading_underscores_for_local_identifiers. You can safely turn this off as long as you don't have someone in your team that has a habit of prefixing variable names with an underscore.
Ignoring the return value
Discarding the return variable
Unfortunately, it doesn't work the same way as C# because it involves an assignment, and you cannot assign two different types to it. You need to declare it as an Object?
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.
In Dart Editor build 27025, the following code produces a syntax error on the line declaring the getter get x:
main() {
var _x;
set x(x) => _x = x; // This is okay
get x => _x; // Syntax error here
}
Note that the setter set x doesn't produce an error. Is this a bug in Dart Editor or am I doing something wrong here?
As you said, getters are functions that are used to retrieve the values of object properties and setters are functions that are used to set the values of object properties. In you example code, _x is not an object property.
The spec shows that getterSignature and setterSignature are only allowed in classes and at the top-level of libraries.
The only thing that surprises me is that your set doesn't produce a syntax error.
That's an interesting one. I think the bug may be that it doesn't complain about the setter. If you delete the getter and just use the setter it doesn't actually run. Or even parse. Which I think means they're not allowed within a function, though it's not immediately clear to me why.
A Dart project member responded to my bug report that "it isn't valid to declare a getter or a setter inside another method or function. This can be seen by following the grammar for a statement to a localFunctionDeclaration to a functionSignature.
That said, it's a bug that there was no syntax error for the setter."
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.