mdelvalle / cs371p-darwin Goto Github PK

View Code? Open in Web Editor NEW

1.0 1.0 1.0 2.55 MB

C++ 47.12% C 3.42% CSS 21.31% Perl 2.67% JavaScript 25.48%

cs371p-darwin's People

Contributors

Stargazers

Watchers

Forkers

apathetics

cs371p-darwin's Issues

Submission

Rename "makefile.c++" to "makefile".
Fill out the Google Form and submit the ZIP file to Turnin.

Seg fault in grid.place_at(food1, 0, 0)

    int main() {
            World grid(10, 10);
            grid.print_world();

        Species f('f');
            f.add_instruction("left");
            f.add_instruction("go 0");
            Creature food1(f, 2);
            grid.place_at(food1, 0, 0);
            grid.print_world();

            return 0;
    }

    void World::place_at(Creature creature, int r, int c) {
            grid[r][c]->species = creature.species;
    }

Had to re-write implementation

We were unsatisfied with our previous implementation so we re-wrote the entire program

Random Seg faults

Unable to locate where seg faults are occuring in our program

Use assert to check pre-conditions, post-conditions, argument validity, return-value validity, and invariants. Worry about this last, but your program should run as fast as possible and use as little memory as possible.

Species at column cols

Getting a seg fault for species trying to infect a creature to its left when its located in the last column

Acceptance tests

The grader's GitHub account will have a public Git repository for unit tests and acceptance tests.
It is critical that you clone the grader's public repo into a different directory than the one you're using for your private repo.
Write acceptance tests before your write the code. When you encounter a bug, write an acceptance test that fails, fix the bug, and confirm that the acceptance test passes. Write an auxiliary program to randomly generate acceptance tests. Create at least 200 lines of acceptance tests. Tests corner cases and failure cases. In your acceptance tests include five other students' acceptance tests. Push and pull only your acceptance tests to and from the grader's repository. Prepend - to the file names at GitHub (i.e. foo-RunDarwin.in and foo-RunDarwin.out). Reach consensus on the acceptance tests.
You must use Valgrind.

Species at row rows

Getting seg fault when creature is trying to infect another creature above it and it is located at the last row

Error because of no operator[] for World class with respect to the grid vector

When calling: cout << grid[0][0]->species.species_name << endl;

Darwin.c++:70:16: error: no match for ‘operator[]’ in ‘grid[0]’

Species at column 0

Getting a seg fault when our species was at column 0 and trying to infect something to its left

Design

The UML diagram.

Species at row 0

Getting seg fault when creature is trying to infect another creature located below it

Git repository

Set up a private Git repository at GitHub, named cs371p-darwin.
Invite the grader to your repository. Commit at least 5 times. Commit once for each bug or feature. If you cannot describe your changes in a sentence, you are not committing often enough. Write meaningful commit messages and identify the corresponding issue in the issue tracker (below). Create a tag for important milestones (e.g. without a cache, with a lazy cache, etc.). Create a log of the commits. Push frequently. It is your responsibility to protect your code from the rest of the students in the class. If your code gets out, you are as guilty as the recipient of academic dishonesty.

Didnt check if grid spot was null

When there is no creature present in the location we forgot to check if that location was NULL in our if statements

Documentation

Use Doxygen to document the interfaces.
The above documentation only needs to be generated for Darwin.h. Comment each function meaningfully. Use comments only if you need to explain the why of a particular implementation. Choose a coding convention and be consistent. Use good variable names. Write readable code with good indentation, blank lines, and blank spaces.

Unit Tests

The grader's GitHub account will have a public Git repository for unit tests and acceptance tests.
It is critical that you clone the grader's public repo into a different directory than the one you're using for your private repo.
Write unit tests before you write the code. When you encounter a bug, write a unit test that fails, fix the bug, and confirm that the unit test passes. Write at least an average of 3 unit tests for each function. Tests corner cases and failure cases. Name tests logically. Push and pull the unit tests to and from the grader's repository. Prepend - to the file names at GitHub (i.e. foo-TestDarwin.c++ and foo-TestDarwin.out). Reach consensus on the unit tests.
You must use Valgrind.

Issue Tracker

The GitHub repository comes with an issue tracker.
Create an issue for each of the requirements in this table. Create an issue for each bug or feature, both open and closed. Describe and label each issue adequately. Create at least 10 more issues in addition to the requirements in this table.

Not sure how to test our methods

We are not sure exactly how to implement the testing for our methods