dgpalmieri / aurora Goto Github PK

• Copy err_msg.h to err_msg.hpp
• Write tests for err_msg.hpp
• Convert err_msg.hpp to C++17
• Write tests for any new functionality created during the C -> C++ conversion

• Copy sp2ppm.c to sp2ppm.cpp
• Write test for sp2ppm.cpp
• Convert to C++17
• Write tests for any new functionality created during the C -> C++ conversion

• Copy stack.h to stack.hpp
• Copy stack.c to stack.cpp
• Write tests for stack.hpp
• Write test for stack.cpp
• Convert to C++17
• Write tests for any new functionality created during the C -> C++ conversion

I think we should integrate into one makefile, but I am not that experienced with makefiles and could not get them to work inside 'Makefile' so that why I created 'Makeray'. If someone can integrate that on their next push, it would be awesome.

Originally posted by @ETY-13 in #26 (comment)

• Copy noise.h to noise.hpp
• Copy noise.c to noise.cpp
• Write tests for noise.hpp
• Write test for noise.cpp
• Convert to C++17
• Write tests for any new functionality created during the C -> C++ conversion

• Copy octree.h to octree.hpp
• Copy octree.c to octree.cpp
• Write tests for octree.hpp
• Write test for octree.cpp
• Convert to C++17
• Write tests for any new functionality created during the C -> C++ conversion

• Copy view.h to view.hpp
• Copy view.c to view.cpp
• Write tests for view.hpp
• Write test for view.cpp
• Convert to C++17
• Write tests for any new functionality created during the C -> C++ conversion

It looks like we're still using typedef struct ... in rays.hpp. Should we use classes instead of structs?

Also, the typedef keyword in C++ is not necessary. Relevent StackOverflow

Update INF and TOL to 64-bit constants, as they are currently 32-bit constants.

• Copy render.h to render.hpp
• Copy render.c to render.cpp
• Write tests for render.hpp
• Write test for render.cpp
• Convert to C++17
• Write tests for any new functionality created during the C -> C++ conversion

• Copy timing.h to timing.hpp
• Copy timing.c to timing.cpp
• Write tests for timing.hpp
• Write test for timing.cpp
• Convert to C++17
• Write tests for any new functionality created during the C -> C++ conversion

I've created #4 with some changes I made to address some warnings.

user@host$ make epr
cc -O2 -DSGI32  -ILibrary -c render.c
render.c: In function ‘render_image’:
render.c:2037:5: warning: format not a string literal and no format arguments [-Wformat-security]
 2037 |     printf("\n"); printf(sharps);
      |     ^~~~~~
render.c:2043:7: warning: format not a string literal and no format arguments [-Wformat-security]
 2043 |       printf(sharps);
      |       ^~~~~~
render.c:2052:7: warning: format not a string literal and no format arguments [-Wformat-security]
 2052 |       printf(sharps);
      |       ^~~~~~
render.c:2091:7: warning: format not a string literal and no format arguments [-Wformat-security]
 2091 |       printf(dashes);
      |       ^~~~~~
render.c:2101:7: warning: format not a string literal and no format arguments [-Wformat-security]
 2101 |       printf(dashes);
      |       ^~~~~~
render.c:2446:11: warning: implicit declaration of function ‘stackdestroy’; did you mean ‘stackdestory’? [-Wimplicit-function-declaration]
 2446 |           stackdestroy(&theStack);
      |           ^~~~~~~~~~~~
      |           stackdestory
cc -O2 -DSGI32 -DDO_GREEN  -ILibrary -c epr.c
epr.c: In function ‘main’:
epr.c:801:5: warning: format not a string literal and no format arguments [-Wformat-security]
  801 |     printf("\n"); printf(asterisks);
      |     ^~~~~~
epr.c:805:5: warning: format not a string literal and no format arguments [-Wformat-security]
  805 |     printf(asterisks);
      |     ^~~~~~
cc -O2 -DSGI32  -ILibrary -LLibrary render.o epr.o -o epr \
-lepr -lm

There are several warnings remaining that I did not address, because I understand the consensus to be that they can be safely ignored.

(base) bryan@Obi-Wan:/mnt/d/usr/local/CS600/EPR$ make epr
cc -O2 -DSGI32  -ILibrary -c render.c
render.c: In function ‘get_turbulence_map’:
render.c:296:3: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
  296 |   fscanf(fp, "P5\n");
      |   ^~~~~~~~~~~~~~~~~~
render.c:332:3: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
  332 |   fscanf(fp, "P5\n");
      |   ^~~~~~~~~~~~~~~~~~
render.c:374:3: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
  374 |   fscanf(fp, "P5\n");
      |   ^~~~~~~~~~~~~~~~~~
render.c:410:3: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
  410 |   fscanf(fp, "P5\n");
      |   ^~~~~~~~~~~~~~~~~~
render.c: In function ‘render_image’:
render.c:2528:3: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
 2528 |   write(outfile, buf, raw_header);
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
render.c:2529:3: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
 2529 |   write(outfile, raw, (s.xres*s.yres)*sizeof(float));
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc -O2 -DSGI32  -ILibrary -LLibrary render.o epr.o -o epr \
-lepr -lm

The PR also addresses a warning that I seem to have forgotten to capture "in the wild". To mitigate, epr.c now includes timing.h to avoid the implicit get_time() call.

• Copy epr.c to epr.cpp
• Write test for epr.cpp
• Convert to C++17
• Write tests for any new functionality created during the C -> C++ conversion

• Copy rays.h to rays.hpp
• Copy rays.c to rays.cpp
• Write tests for rays.hpp
• Write test for rays.cpp
• Convert to C++17
• Write tests for any new functionality created during the C -> C++ conversion

This typedef is across all architectures, typedef unsigned long int uLong;
Is it important to search the codebase and replace any use of unsigned long int by uLong?
I did that, and the only other place I find unsigned long int is in raster.c.
It seems like it would be a good idea to replace this with uLong?

• Copy raster.h to raster.hpp
• Copy raster.c to raster.cpp
• Write tests for raster.hpp
• Write test for raster.cpp
• Convert to C++17
• Write tests for any new functionality created during the C -> C++ conversion

• Copy atomics.h to atomics.hpp
• #21
• Convert atomics.hpp to C++17
• Write tests for any new functionality created during the C -> C++ conversion

I need to understand how doctest works if we're going to use it for testing. I've cloned the repo and I'm looking through the examples.

It would be nice to have consistent indentation here

Originally posted by @dgpalmieri in #26 (comment)