I'm getting (fairly reguarly) an "Error 16: Expression too complex" runtime error on a simple assigment to a property from a class.
public property PropertyName() as double
PropertyName = mvarPropertyName
end property
The debug window points to the crash being on the assignment line in the above code.
Some inital reading here and elsewhere suggested that it was related to the line calling the property. However, that now looks like this:
variableName = ObjectName.PropertyName
And all arithmetic is done with variableName.
Even more oddly, if I just hit debug, then resume/F5 immediatley, everything is fine.
Trying to use the error handling code to do this doesn't seem to have worked however.
Any ideas what is causing this error?
Stop using Not (Not MyArray) to test for uninitialized arrays. This uses a bug in the compiler that has a known side effect of destabilizing the run-time leading to "Expression too complex" on random places.
VB6 - Returning/Detecting Empty Arrays is fairly complete thread on different ways to test for empty and uninitialized arrays.
A string expression is too complicated. Strings not assigned to variables (such as those returned by functions) are assigned to temporary locations during string expression evaluation. Having a large number of these strings can cause this error. Try assigning these strings to variables and use the variables in the expression instead.
Related
I am trying to implement a PID controller using Verilog, but I faced some problems in the coding.
I try to set the position as a parameter like shown in the screens shot:
but, I faced an error which I am not aware of:
Error1:-
Error (10170): Verilog HDL syntax error at Verilog1.v(16) near text: "["; expecting an operand. Check for and fix any syntax errors that appear immediately before or at the specified keyword. The Intel FPGA Knowledge Database contains many articles with specific details on how to resolve this error. Visit the Knowledge Database at https://www.altera.com/support/support-resources/knowledge-base/search.html and search for this specific error message number.
Error2:-
Error (10170): Verilog HDL syntax error at Verilog1.v(34) near text: "["; expecting "#", or an operand. Check for and fix any syntax errors that appear immediately before or at the specified keyword. The Intel FPGA Knowledge Database contains many articles with specific details on how to resolve this error. Visit the Knowledge Database at https://www.altera.com/support/support-resources/knowledge-base/search.html and search for this specific error message number.
I also tried the like integer position= [0*IRL+1000*CIR+2000*IRR];, but still, I face the same problem. How do I fix this syntax error?
After compiling, parameter values can only be read; not modified. They are runtime constants. An integer type can only be assigned within an procedural block. You can give it an initial value at declarations, but it will not auto update. So you want a procedure assignment or a net type with continuous assignment.
Square brackets ([]) are used for indexing an array or slice of a vector. They cannot be used like parentheses (()) or curly brackets ({}). In your case non are needed.
Change:
integer position= [0*IRL+1000*CIR+2000*IRR];
To:
wire [31:0] position= 0*IRL+1000*CIR+2000*IRR;
Or:
wire [31:0] position;
assign position= 0*IRL+1000*CIR+2000*IRR;
Or:
integer position;
always #* begin
position= 0*IRL+1000*CIR+2000*IRR;
end
Also change:
Proportional<= [position/IRL+CIR+IRR]-1000;
To:
Proportional<= (position/IRL+CIR+IRR)-1000;
Assuming IRL, CIR and IRR are declared as constant type (like parameter), then you should remove the square brackets:
parameter position = 0*IRL+1000*CIR+2000*IRR;
I am learning OCaml and I'm a complete beginner at this point. I'm trying to get used to the syntax and I just spent 15 minutes debugging a stupid syntax error.
let foo a b = "bar";;
let biz = foo 2. -1.;;
I was getting an error This expression has type 'a -> string but an expression was expected of type int. I resolved the error, but it prompted me to learn what is the best way to handle this syntax peculiarity.
Basically OCaml treats what I intended as the numeric constant -1. as two separate tokens: - and 1. and I end up passing just 1 argument to foo. In other languages I'm familiar with this doesn't happen because arguments are separated with a comma (or in Scheme there are parentheses).
What is the usual way to handle this syntax peculiarity in OCaml? Is it surrounding the number with parentheses (foo 2. (-1.)) or there is some other way?
There is an unary minus operator ~-. that can be used to avoid this issue: foo ~-.1. (and its integer counterpart ~-) but it is generally simpler to add parentheses around the problematic expression.
I accidentally typed the following code but my code successfully built and even ran properly.
std::string myString = "This is my string ";
std::shared_ptr<std::string> s = std::make_shared<std::string>(myString);
p->pushString(s);”accidental typo”;
It just showed a warning Expression result unused.
Why it is not a compiler or run time error?
I am using Xcode editor
Thanks
Why it is not a compiler [...] error?
Because it does not violate any rule of the C++ standard. If a program conforms to the standard then the compiler should allow its compilation. However, it was friendly enough to warn you that the expression is useless.
or run time error?
The expression doesn't result in any executed code, so it would be quite surprising if it resulted in a run time error.
You know that you can have arbitrary expressions as statements? That's how simple functions calls works, or assignments. In fact the statement
p->pushString(s);
is actually such an expression-statement. The p->pushString(s) part is an expression, it's the context (with the terminating semi-colon) that turns it into a statement.
That also means you can do something like
5;
Or in your case
"some string here";
Those are valid statements. They do however produce a result, which is (legally) discarded or ignored, but might cause the compiler to emit a warning about the ignored result.
It's really no different than e.g.
some_function_which_returns_a_result(); // Result ignored
When creating a tracepoint in Visual Studio (right-click the breakpoint and choose "When Hit..."), the dialog has this text, emphasis mine:
You can include the value of a variable or other expression in the message by placing it in curly braces...
What expressions are allowed?
Microsoft's documentation is rather sparse on the exact details of what is and is not allowed. Most of the below was found by trial and error in the Immediate window. Note that this list is for C++, as that's what I code in. I believe in C#, some of the prohibited items below are actually allowed.
Most basic expressions can be evaluated, including casting, setting variables, and calling functions.
General Restrictions
Only C-style casts supported; no static_cast, dynamic_cast, reinterpret_cast, const_cast
Can't declare new variables or create objects
Can't use overloaded operators
Ternary operator doesn't work
Can't use the comma operator because Visual Studio uses it to format the result of the expression; use multiple sets of braces for multiple expressions
Function Calls
Prohibited calls:
Lambdas (can't define or call them)
Functions in an anonymous namespace
Functions that take objects by value (because you can't create objects)
Permitted calls:
Member functions, both regular and virtual
Functions taking references or pointers, to either fundamental or class types
Passing in-scope variables
Using "&" to pass pointers to in-scope variables
Passing the literals "true", "false", numbers
Passing string literals, as long you don't run afoul of the "can't create objects" rule
Calling multiple functions with one tracepoint by using multiple sets of braces
Variable Assignment
Prohibited:
Objects
String literals
Permitted:
Variables with fundamental types, value either from literals or other variables
Memory addresses, after casting: { *(bool*)(0x1234) = true }
Registers: { #eip = 0x1234 }
Use Cases
Calling functions from tracepoints can be quite powerful. You can get around most of the restrictions listed above with a carefully set up function and the right call. Here are some more specific ideas.
Force an if
Pretty straightforward: set up a tracepoint to set a variable and force an if-condition to true or false, depending on what you need to test. All without adding code or leaving the debug session.
Breakpoint "toggling"
I've seen the question a few times, "I need to break in a spot that gets hit a lot. I'd like to simply enable that breakpoint from another breakpoint, so the one I care about only gets breaks from a certain code path. How can I do that?" With our knowledge above, it's easy, although you do need a helper variable.
Create a global boolean, set to false.
Create a breakpoint at your final destination, with a condition to break only when the global flag is true.
Set tracepoints in the critical spots that assign the global flag to true.
The nice thing is that you can move the tracepoints around without leaving the debugging session. Use the Immediate window or the Watch window to reset your global flag, if you need to make another run at it. When you're done, all you need to clean up is that global boolean. No other code to remove.
Automatically skip code
The EIP register (at least on x86) is the instruction pointer. If you assign to it, you can change your program flow.
Find the address of the line you want to skip to by breaking on it once and looking at the value of EIP, either in the Registers window or the Watch window with "#eip,x". (Note that the value in the Registers window is hex, but without the leading "0x".)
Add a tracepoint on the line you want to skip from, with an expression like {#eip = address}, using the address from step 1.
EIP assignment will happen before anything on the line is executed.
Although this can be handy, be careful because skipping code like this can cause weird behavior.
As Kurt Hutchinson says, string assignment is not allowed in a tracepoint. You can get around this by creating a method that assigns the string variable, and call that.
public static class Helper
{
public static void AssignTo(this string value, out string variable)
{
variable = value;
}
}
Then in your tracepoint message:
{"new string value".AssignTo(out stringVariable)}
I have some function which performs addition operation on to variant data types
Public Function Sum(value1, value2)
Sum = value1 + value2
End Function
Does this addition operation performed by late binding or not?
Or late binding performed only when I invoke some method on variant data type but not with binary operations?
I'm also wondering is late binding used when I add Object data types in VB .NET (Option Strict is turned off), dynamic data types in C#.
Thank you.
This is not related to early /late binding. I think you are referring to the data types for value1 and value2? The question is confusing however as it is tagged VB6 but you use Return which is not a valid keyword in VB6
In the case of VB6 both value1 and value2 will be variants so they could be numeric or strings (or even objects). The function will also return a Variant
If you call the function with two strings - the sum result will be the concatenated string: value1value2
If you pass in two numeric values then the sum will be the arithmetic sum of the values: value1 + value2
Is is always best to avoid this type of programming and define the types that you require to prevent unexpected result
EDIT:
From MS VB.NET documentation but this is very similar for VB6:
The + Operator (Visual Basic) has the primary purpose of adding two numbers. However, it can also concatenate numeric operands with string operands. The + operator has a complex set of rules that determine whether to add, concatenate, signal a compiler error, or throw a run-time InvalidCastException exception.
This is nothing to do with early or late binding because that is to do with the compiler knowing which methods, properties and events an object has at compile time (early binding) and not knowing these at compile time (late binding)
The latter can result in runtime errors because you may have mistyped a method name and the compiler can't pick that up until it tries to execute the line and cannot find the method you typed. Have a look at the following for more information: Early vs Late Binding
The only case when a late-bound call is made in your function is when one of the Variant arguments is an object reference. When evaluating the + operator (or any other expression) on a reference argument, first its DISPID_VALUE (0) member is called late-bound (through IDispatch::Invoke) and the retval is used in the expression. If the retval is an IDispatch reference it's DISPID_VALUE is called recursively. That's why you can use recordset("ID") instead of recordset.Fields.Item("ID").Value in expressions (kind of).
If explicit object references of known types (interfaces) are used in an expression (e.g. + operator), the compiler emits code that calls default property early-bound which results in much simpler evaluation at run-time.