Karl-Krauth/COMP6771-tests

Compiling

Closed this issue · 13 comments

Is anyone else having trouble compiling the fuzzer test or is it just me? :D

I had issues with his use of the dlfcn library with linking, since I didn't use the standard library. I recommend deleting the malloc function if that's the issue, since the only purpose is to have a malloc that sometimes fails to test strong exception handling, which I don't believe is within the scope of the assignment

How does anyone manage to run the provided test. It seems that the util.h has printEdges that takes in 2 params.

Yeah, those are my tests. Sorry, didn't put the same comment I put for printnodes. Your Graph::printedges should take in 2 arguments, the second being the stream. Just make the stream default to std::cout, and you'll have the expected behaviour when using the 1-argument form.

I believe that the spec doesnt say anything about printEdges taking 2 arguments right?

Correct. However, I couldn't work out how to actually capture the things sent to std::cout until after I saw donny's code, where he overrode the << operator, so instead I view the results sent to a stream.

Yes I actually don't mind the idea of adding that extra argument that defaults to std::cout. But my issue is with the fuzzer, I get many errors for it, but the bulk of the problem seems to be that the equality operator isn't defined for the datatype. There is also some issues with assert which is strange.

I didn't define the equality operator for Unhashable since I wrote it before Jingling mentioned that it can be assumed to exist (since previously, he said to not assume it). Just transplant the one from Hashable over.

Feel free to post the actual errors your getting so we can help debug it

I dont think that hashable and unhashable is going to be tested anyway

Out of curiosity kotarou3 how did you get the graph working without the equality operator? :D

You can use the < operator to compare values. If !(a < b) && !(b < a) then a == b. Hence, you can do equality with less than. Or you can let the STL do that for you and use a std::set

@matts1 I'll look into changing your util.h to not require methods not in the spec. Shouldn't be too hard to get std::cout to redirect to a ostream of our choosing.

If you do choose to do it that way, I'd advise against the redirecting of std::cout (I googled, couldn't work out how to do it after like 15 minutes). The easier way would be to overlead the << operator on the ostream so that it pushes to a vector or something, instead of actually going to cout.

std::cout redirection ended up being pretty easy but I haven't tested in depth yet since I don't quite have a working implementation just yet. lmk if you find issues with it.