 |
.. (לתיקייה המכילה) | |
Dry part - question 2: Can we choose any declaration for the requested function? | |
| No. The function should receive a single parameter only (a node in the cyclic list). |
Dry part - question 1: Can I change the structure of "struct temp" (add fields, replace fields, etc.) | |
| No. |
If an apartment is split by a column, how should the price be calculated? | |
| (Old price) x (#columns in new apartment + 1) / (#columns in original apartment) |
In apartmentCreate - how long can I assume that squares points a valid object? | |
|
You can assume that squares points to a valid location only during the call to create. It means that immediately after create returns, accessing squares[i][j] will results in an undefined behavior. However, the square board of the apartment you're creating must still point to a valid location even after create returns. |
After creating a copy of an apartment, should actions performed on one of the two apartmnets affect the other? | |
|
No, The apartments should be identical immeidately after the call to copy, but any action (e.g changing the value of a square) on the original apartmnet shouldn't affect the copy and vice versa. It means that after performing a single change to one of the two apartmnets, they will no longer be identical. |
Dry part - question 1: Do we need to mention missing headers (stdlib.h, stdbool.h, etc.)? | |
| No |
Dry part - question 1: Can we add an integer to the signature of the functions, to pass the size of the array? | |
| Yes, but you cannot add any additional parameters other than that. |
Dry part - question 1: Should the result array contain the same number of elements as the original array, or only the elements that were swapped? | |
| The same number of elements as the original array |
Are we allowed to change the enums in the header files? | |
| No. |
In apartmentRoomArea, should the given square be counted as part of the room area? | |
| Yes |
Dry part - both questions: Do we need to check for nullness? | |
| You may use an assert to verify that the pointers are not NULL. |
What should the functions that return an integer do if they receive a NULL pointer? | |
| You may use an assert to verify that this never happens. |
Dry part (both questions): are we allowed to use helper functions? | |
| Yes |
Dry part (both questions): | |
| void |
Are we allowed to assume any upper bound for the prices or areas of the apartment? | |
| No. |
In apartmentSetSquare: can we assume that "value" is either WALL or EMPTY? | |
| Yes. |
In the wet part: Where should we define helper function? | |
| In the *.c files, and you should declare them as static. |
Is an apartment in which all squares are walls legal? | |
| Yes. |
In areaMedian: How exactly should the area be calculated? | |
| The area is the number of empty squares in the apartment, as calculated in the first part of the exercise. |
There are some typos in the exercise. Should we fix them? | |
| Please use the signatures exactly as they appear in the .h file you received. If there is a typo in the header, please leave it as it is. |
Do we need to make sure that our program doesn't have memory leaks? | |
|
Yes. Points will be reduced for memory leaks. You can use "Valgrind" to search for memory leaks and general bad memory handling in your program. Instructions for using Valgrind cab be found under: Course Matrial -> Auxiliary Tutorials -> Debugging |
I get a "bad version" error when I run final_check. What can I do? | |
|
In order to use gcc/g++/gfortran 4.7.1, you should run first: source /usr/local/gcc4.7/setup.csh # for CSH and TCSH or: . /usr/local/gcc4.7/setup.sh # for BASH and SH verify version by: gcc --version gcc (GCC) 4.7.1 You can check which shell you're using by typing echo $0 You can switch to bash by typing bash |
It is written that we need to submit our own tests. | |
|
Thes test files you received contain a main function which calls RUN_TEST for a single test. Below, there is a comment: "add more tests". You should add several additional calls to RUN_TEST, one call for each test. You should write a test for each interface function, which tests its different behaviors. It is recommended to try and think of complicated cases in your tests. |
Can test functions have more than 50 lines? | |
| Yes |
If a function receives an output parameter, but the function fails - what should be the value of that parameter? | |
| If the function doesn't return SUCCESS, you may assume its illegal to dereference the output pointer. |
Can we add a new struct to apartment_service.h? | |
| Yes. |