I'm using VS2008 to write a program. There's one specific line in my code that causes a numerical error. It is:
Qp[j] = (Cp - Cm)/(Bp + Bm);
Qp is a std::vector. When I comment this line out, the numerical error disappears. I am going through my code line by line to find all the places that access Qp[j]. I was wondering if there was a feature in VS2008 or a linux program that wraps around the executable that can identify every line of code that reads from that section of memory (the specific element in the vector)?
I tried searching online but the keywords I used brought up results relating to global variables.
--- EDIT
Hi all. To those have responded, thank you. Just to clarify my question:
Imagine I have a vector with 5 elements. I'd like to know all the places in my code that use the value stored in element 3 at any point in time during execution. Is there an easy way to do this?
I am not sure if I understand you correctly, but if you comment out that line and the code works then maybe the problem is that line, and you don't need to check others lines.
Maybe in your case you get in the situation where Bp+Bm = 0 (division by zero error).
Qp may not have as many elements as the index j, check the size of Qp.
Related
I need to understand the other people's code by debugging through all the code, in the meantime, I can't change or add any code. The one major problem comes up. That is When I want to see the all the value in a dynamic array by adding it to Watch, it would not give me what I expect to. I am only able to see first value of the them. Such as:
In addition, when I add it to Watch, it would show no operator "[]" matches these operands.
How can i address this problem?
you can follow this link, it shows you how to use feature called the “size specifier”to display the array elements:
https://blogs.msdn.microsoft.com/habibh/2009/06/05/size-specifier-how-to-display-a-cc-pointer-as-an-array-in-the-visual-studio-debugger/
I have inherited a 10K-lines Fortran code that uses fpx3 for pre-processing. At this point I should say that I don't have much Fortran experience, and this is my first time dealing with a code that has a pre-processor.
The code works fine, except that when the pre-processing runs, it creates secondary Fortran files (e.g., main.f90 creates t.main.f90) that do not preserve the total amount of lines. The reason, of course, is that some code is lost when pre-processing (IF-ELSE clauses, pre-proc. directives, etc.).
This would be fine, except that when I get a bug in the code, the line number I get from the bug refers to the pre-compiled code (e.g., t.main.90) instead of the original code.
This isn't a major problem, but for nearly every bug I have to check the line (say, line 80 of t.main.f90) and manually try to find this line in the original (let's say it ends up being line 92 of main.f90). I've tried to find a way around this by telling fpx3 to comment the unused lines instead of throwing them out, but I couldn't find much info on fpx3 online.
What's the best way around this?
P.S.: I don't know if it matters, but I'm using ifort to compile.
Try -fixed as a .f90 file is assumed to be -free (free form), and fixed preserves the 1st few columns and the continuation in column 6.
If the number at on the right hand side, then NOT -132, but -72 or -80. To not include the numbers as "compilable" code. I use -132, so you have to look up the right switch.
This might seem a bit far fetched and possible off-topic (sorry if it is), but I'd like to know for sure if it is possible or not.
I am working on a Q and A program.
The text file is laid out in a Question tab Answer newline style.
My question is this: Is it possible to read an answer as a function.
Example:
Question - What time is it? / Answer - getCurrentTime()
Question - What is today's date? / Answer - getCurrentDate()
Then the program, though string parsing, knows that this is a function without an argument and calls the function getCurrentTime() or getCurrentDate() which prints the time or date respectively.
This is possible using an array of function pointers. You just load all the functions into the array. How you obtain the correct index is up to you. The only useful way I can come up with is maintain a second array containing the function names in the same positions as the functions in the function array. Then search the function name array and use the index in that array to access the correct function in the function array. If you need a better explanation leave a message. It is very late at night here and I need to work in the morning.
Barmar's solution will work to and is the better way to go about it but use function pointers.
Hope this helps
dannyhut
I am aware that there already exist related threads like how do I loop through file names in stata
I follow those instructions but however receive the invalid syntax r(198) error in Stata.
My code looks as follows:
foreach var of "*/ABC.dta" ABC{
infix observation 1-2 date 3 using "*/CC_ABC`var'.txt"
save "*/CC_ABC`var'.dta" ,replace
}
Where ABC.dta is a list of pretty random numbers which all occur in file names. Do you have an idea why I get errors here?
Thanks a lot!
Is this real code?
Stata wouldn't get past the lack of a listtype following of. This is the very first thing explained in the help for foreach.
If this isn't real code, please show us a real example of something that doesn't work, ideally one that we can reproduce.
(If you don't understand something, imposing your own abstraction or generalization is just likely to muddy your question for those who do.)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I want to add documentation in my code by means of comment lines.
Is there any standard format for this?
For example, consider the code below:
class Arithmetic
{
// This method adds two numbers, and returns the result.
// dbNum1 is the first number to add, and dbNum2 is second.
// The returning value is dbNum1+dbNum2.
static double AddTwoNumbers(double dbNum1, double dbNum2);
}
For this example code, is there any better way of writing the comment lines?
For c++ there isn't a standard, like javadoc, but certain documentation tools are popular and common to use. Off the top of my head, I can mention doxygen.
Doxygen also supports the familiar javadoc style, ie:
/**
This method adds two numbers, and returns the result.
#param dbNum1 is the first number to add
#param dbNum2 is second.
#return The returning value is dbNum1+dbNum2.
*/
static double AddTwoNumbers(double dbNum1, double dbNum2);
you can format your comments so later you can generate documentation. the most popular tool for this is DoxyGen
You don't want to write too much. Suppose you write comments for a function that, in the future, saves you ten minutes of time understanding your code. Great. But suppose your comments are so verbose that it takes five minutes to write them and then, later, five minutes to read them. Then you've saved yourself zero time. Not so good.
You don't want to write too little, either. If code goes on for a page or two without something breaking down what's going on, well, I hope that code is clear as crystal, because otherwise you're wasting future time.
And you don't want to comment in stupid ways. When people first start writing comments, they often get hyper and write things like:
// Now we increase Number_aliens_on_screen by one.
Number_aliens_on_screen = Number_aliens_on_screen + 1;
Uhmmm, duh. If something is so obvious, it doesn't need a comment. And if your code is such a tangle that you need a comment for every single line of it, you'd probably profit from making it simpler in other ways first. Comments don't just save time, they cost it. They take time to read, and they spread out the actual code on the screen, so you can have less of it on your monitor to inspect at one time.
And, while we're at it, don't ever do this:
Short get_current_score()
{
[insert a whole bunch of code here.]
return [some value];
// Now we're done.
}
Oh? We're done? Thanks for letting me know. That big right bracket and the infinite expanse of empty space beyond really didn't tip me off to that. And you don't need a comment before the return statement saying, "Now we return a value," either.
So, if you are writing code, in the absence of a boss or a company policy telling you what to do, how do you comment it? Well, what I do for code I am stuck with maintaining myself is write an introduction. When I return to a procedure I forgot that I wrote, I want to see an explanation for what is going on. Once I understand what the machinery is doing, it becomes infinitely easier to understand the actual coding. This generally involves:
A few sentences before the procedure/function saying what it does.
A description of the values being passed into it.
If a function, a description of what it returns.
Inside the procedure/function, comments that split the code up into shorter tasks.
For chunks of code that seem thorny, a quick explanation of what is happening.
So we need a description at the beginning and a few signposts inside explaining the road taken. Doing this is very quick, and it saves a ton of time in the long run.
Here is an example from the theoretical Kill Bad Aliens. Consider the object representing the bullet the player fires. You will frequently have to call a function to move it upwards and see if it hits anything. I would probably code it something like this:
// This procedure moves the bullet upwards. It's called
//NUM_BULLET_MOVES_PER_SECOND times per second. It returns TRUE if the
//bullet is to be erased (because it hit a target or the top of the screen) and FALSE
//otherwise.
Boolean player_bullet::move_it()
{
Boolean is_destroyed = FALSE;
// Calculate the bullet's new position.
[Small chunk of code.]
// See if an enemy is in the new position. If so, call enemy destruction call and
// set is_destroyed to TRUE
[small chunk of code]
// See if bullet hits top of screen. If so, set is_destroyed to TRUE
[Small chunk of code.]
// Change bullet's position.
[Small chunk of code.]
Return is_destroyed;
}
If the code is clean enough, this sort of commenting should be sufficient. And it will save plenty of time the dozen times I return to this function to fix a dumb mistake I made.
Refered from: here
Doxygen and other similar tools can help with this. Basically you write comments according to some pre-defined style and from that HTML/PDF/etc. documentation is extracted.