• C++ Programming for Financial Engineering
    Highly recommended by thousands of MFE students. Covers essential C++ topics with applications to financial engineering. Learn more Join!
    Python for Finance with Intro to Data Science
    Gain practical understanding of Python to read, understand, and write professional Python code for your first day on the job. Learn more Join!
    An Intuition-Based Options Primer for FE
    Ideal for entry level positions interviews and graduate studies, specializing in options trading arbitrage and options valuation models. Learn more Join!

Compile Errors != Linker Errors, BTW why do I get Linker errors?

I enjoyed the typing and clicking sound. It seemed you were using typewriter instead of keyboard for typing :P
 
Hi Daniel,

After I include Array.cpp in the main program, it works. But why? I don't remember in the previous exercise I have to do this.

It's magic, not allowed to say :D Just kidding.

Seriously, Array is a template (remember my videos?) and must #include "Array.cpp" otherwise compiler cannot find source code. Somewhere <T> needs to be replaced by <double> it does need Array.cpp the compiler phase (linker phase is too late).

Here's a great example :)

http://www.datasim.nl/Education/Videos/MyFirstProject/

Small exercise: explain what went wrong, why it went wrong and why the 'magic' works. Everyone I met in the last 25 years experienced this problem :)
 
Last edited:
tips for arrays, and maybe more :)

1. Are vars initialised?
2. What's the default size?
3. Array index out of bounds?
4. Did you take on my recommendations in previous post?
BTW VS has debug F5 (and then step via F10, F11)
 
The 13 Golden Rules of Debugging
1. Understand the requirements
2. Make it fail
3. Simplify the test case
4. Read the right error message
5. Check the plug
6. Separate facts from interpretation
7. Divide and conquer
8. Match the tool to the bug
9. One change at a time
10. Keep an audit trail
11. Get a fresh view
12. If you didn’t fix it, it ain’t fixed
13. Cover your bugfix with a regression test
 
This is a good one, i.e. can we reproduce the error at will? If not, get ready for sleepness nights

Occasionally hardware itself goes bad. The floating-point flaw in the 1994 Pentium processor that caused certain computations to produce wrong answers was a highly publicized and costly bug in the design of the hardware, but once it had been identified, it was of course reproducible. One of the strangest bugs we ever saw involved a calculator program, long ago on a two-processor system. Sometimes the expression 1/2 would print 0.5 and sometimes it would print some consistent but utterly wrong value like 0.7432; there was no pattern as to whether one got the right answer or the wrong one. The problem was eventually traced to a failure of the floating-point unit in one of the processors. As the calculator program was randomly executed on one processor or the other, answers were either correct or nonsense.
 
Back
Top