macOS C++ Compiles at school+home; only runs at school?

[Josh]

Hi,

For my CS course, we have a C++ program that we must alter to add additional functionality.

During lab, we work on Linux and Sun systems (compiling the program on each, as needed).

I downloaded my source files from the Sun machine to my Mac, running OS X 10.4.7, with all developer tools installed.

I don't have any executables or object files from the Sun machine, only .cpp and .h source files (and 1 .txt data file).

I can compile everything without error, but when running the program, the main function (plot) gets thrown into what seems to be an infinite loop.

I cannot understand why it would compile and run on the Linux and Sun machines, but not on OS X

There are 4 files being used:
- project1A.cpp: the main routine
- signal.cpp: additional functions (such as plot)
- signal.h
- data1.txt: text file with the data being processed.

Could anyone try compiling the code and/or looking at it to see what's up?

Once the program is running, type 'read data1.txt' to read the data, then run the command 'plot' to see the plot (this is where the error happens).

I've attached a zip file with all the souce and data files.

Any help offered is MUCH appreciated!

Thanks in advance.

 

[iMeowbot]

There seems to be a basic logic problem in there. I added a simple cout thingy to plotPoint() and found these values for the first two lines (it's on the second value that it goes nuts):

                       amp  ncells  min   max    Position 
       0       0.000  0.000 50      0.000 0.000  -2147483648*
       1       1.000  1.000 50      0.000 0.000  2147483647

Those huge numbers in Position are your problem. You're dividing by zero because of min and max. track down where those are supposed to be set and passed, and you'll be closer to an answer.

You may want to kill the plotting for now and print only the numbers while you debug.

 

[cazlar]

I haven't had a chance to look at your source yet, but if it is a divide by zero bug as iMeowbot suggests, that might mean it could be a PPC vs Intel difference (unless you are on an Intel Mac?), as I believe they handle that case differently?

 

[Josh]

I haven't had a chance to look at your source yet, but if it is a divide by zero bug as iMeowbot suggests, that might mean it could be a PPC vs Intel difference (unless you are on an Intel Mac?), as I believe they handle that case differently?

That's a possibility, never thought of that.

So far, I know the program runs properly on Sparc and Intel processors. Could very well be a PPC thing.

Thanks for the replies so far - I'll have to fix any logic errors and see what happens (though I believe the plot() function was supposed to be provided in functioning condition )

Thanks again, I appreciate it!

 

[Sayer]

FYI: you don't need to put the whole path to your header file in source files. Just using "<name>.h" is a shortcut for the same folder as the source files.

Here is the output I got on an Intel iMac:

-.-.-.-.-.--.-.-.-.-.--.-.-.-.-.--.-.-.-.-.--.-.-.-.-.--.-.-.-.-.--.-.-.-.-.--.-.-.-.-.-
PLOT OF SIGNAL: 10 amplitudes.

         x      y=s(x) 

         0       0.000  *
         1       1.000  *
         2       2.000  *
         3       3.000  *
         4       3.000  *
         5       2.000  *
         6       2.000  *
         7       1.000  *
         8       1.000  *
         9       0.000  *
-.-.-.-.-.--.-.-.-.-.--.-.-.-.-.--.-.-.-.-.--.-.-.-.-.--.-.-.-.-.--.-.-.-.-.--.-.-.-.-.-

Is this what it is supposed to do?

 

[MongoTheGeek]

That's a possibility, never thought of that.

So far, I know the program runs properly on Sparc and Intel processors. Could very well be a PPC thing.

Thanks for the replies so far - I'll have to fix any logic errors and see what happens (though I believe the plot() function was supposed to be provided in functioning condition )

Thanks again, I appreciate it!

I thought that sparcs are RISC chips and are big-endian, like the PPC.

It could be that you have a different compiler flag that automatically initializes variables on one platform that is protecting you.

 

[Josh]

FYI: you don't need to put the whole path to your header file in source files. Just using "<name>.h" is a shortcut for the same folder as the source files.

Here is the output I got on an Intel iMac:

-.-.-.-.-.--.-.-.-.-.--.-.-.-.-.--.-.-.-.-.--.-.-.-.-.--.-.-.-.-.--.-.-.-.-.--.-.-.-.-.-
PLOT OF SIGNAL: 10 amplitudes.

         x      y=s(x) 

         0       0.000  *
         1       1.000  *
         2       2.000  *
         3       3.000  *
         4       3.000  *
         5       2.000  *
         6       2.000  *
         7       1.000  *
         8       1.000  *
         9       0.000  *
-.-.-.-.-.--.-.-.-.-.--.-.-.-.-.--.-.-.-.-.--.-.-.-.-.--.-.-.-.-.--.-.-.-.-.--.-.-.-.-.-

Is this what it is supposed to do?

I put the path in as a "second guess" just to make sure (as I had no idea what would be causing the trouble, and didn't want it to be something remote like that lol)

That output is 40% correct. On my other runs, the '*' was spaced out from the readings proportionate to their values.

This has me scratching my head for sure.

 

[Gruffalo]

I put the path in as a "second guess" just to make sure (as I had no idea what would be causing the trouble, and didn't want it to be something remote like that lol)

That output is 40% correct. On my other runs, the '*' was spaced out from the readings proportionate to their values.

This has me scratching my head for sure.

As a hint, why not look at the function getStats() and fill in some of the missing logic, as per the instructions in signal.cpp. The choice of the name signal.h is particularly poor practice, but I guess this is your teacher/professors fault. On Unix based platforms at least, there will always be confusion as to whether your version or the system signal.h will be picked first. This is why you needed to specify a full path in order to get it to compile on OsX.