How do I track what line of code is causing a syntax error and/or other compilation errors?

Categories:
Solution Number:
S20784
Last Modified:
2013-08-20
Issue

How do I track what line of code is causing a syntax error and/or other compilation errors?

Solution

Process: (1) Typically, just open the process model and click the Compile toolbar button. This will open up the results of the compilation with any error messages. You can click on the resulting dialog box to take you to the line of code that is being reported as causing the compilation error.(2) Most often, a compiler will report the actual line of code that is causing the compilation error. Sometimes, however, the actual errors are several lines above the line reported by the compiler. Please take a look at the code block right before the line where the compilation error is reported.(3) Open up the <process_name>.pr.c file either using an external editor (ex: the MSVC++ editor) or the Compile->List Code option from the process model editor, and go to the line where the first compilation error is reported. Check for a syntax error there. If it is in the middle of OPNET generated code, make sure the user code in the code block above the lines is not missing a ;, ) or }.(4) Check to see of you have any temporary variables declared in the TV block or states that are using the same name as a state variable in the SV block. Some people prevent this by using the prefix sv_ with all state variable names. You can search using the Compile->List Code listing and look for any declarations of the state variables. If you use the built-in OPNET editor for opening the process model code, you will see the state variables being highlighted in a different color. This is very useful for distinguishing state variables from other identifiers.(5) If you are not sure what a particular error message means, you may want to search for the exact error string (or a likely sub-string) in the Help for your compiler. Searching on the Internet (ex: www.google.com) can also be very effective. You should also search in the FAQs available at www.opnet.com/support. (6) If the above techniques do not help, try locating the error by partial-compilation using preprocessors. For example, if you have your code in one of the executive blocks, try commenting the whole block out by placing #if 0 at the beginning of the block and #endif at the end. I would do this to all the code blocks including the function block and the temp variable block or even the header block, one by one, until the error message goes away. You can use a divide and conquer process of elimination to hone in on the problematic line of code.(7) Also be aware that a header file that is included in the process model may be to blame. (You should be especially suspicious of any headers that you have recently modified, or any headers that you recently added or removed from the process model).(8) Most of the OPNET Standard Models should compile without significant warnings. If you are seeing warnings (especially in code that you have written), you may want to investigate them as well using the techniques above, because sometimes a compilation error will be caused by something that is first reported as a warning. Be aware that some warnings are harmless, though in general it is a best practice to avoid all warnings in your own code. Also, you might want to increase the warning level of your compiler (see FAQ 281 -- How can I make OPNET generate more warnings during compilation?). ---------------------FAQ keywords: compile, compiler, compilation, warning, warnings, warn, error, errors, MSVC, Visual Studio, Visual C++, syntax

Environment

Compiling/Linking,DES Kernel->Process Modeling/Coding

Attachments
NOTICE: Riverbed® product names have changed. Please refer to the Product List for a complete list of product names.
Can't find an answer? Create a case