This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
haas:fall2020:discrete:projects:bdt2 [2020/09/29 21:48] – [Basic functionality] wedge | haas:fall2020:discrete:projects:bdt2 [2020/09/30 16:35] (current) – [Implementation Restrictions] wedge | ||
---|---|---|---|
Line 63: | Line 63: | ||
* **justification** implies some thoughtful why/how style comments explaining how a particular use of one of these statements is effective and efficient (not: "I couldn' | * **justification** implies some thoughtful why/how style comments explaining how a particular use of one of these statements is effective and efficient (not: "I couldn' | ||
* absolutely **NO** infinite loops (**while(1)** or the like). | * absolutely **NO** infinite loops (**while(1)** or the like). | ||
+ | * ALL variables must be well and pertinently named, and be no fewer than 4 symbols in length | ||
* no forced redirection of the flow of the process (no seeking to the end of the file to grab a max size only to zip back somewhere else: deal with the data in as you are naturally encountering it; no telling; no " | * no forced redirection of the flow of the process (no seeking to the end of the file to grab a max size only to zip back somewhere else: deal with the data in as you are naturally encountering it; no telling; no " | ||
* All " | * All " | ||
Line 85: | Line 86: | ||
In bdt1, the focus is the FIRST byte of difference. Here in bdt2, we are looking at supporting multiple bytes of difference, perhaps even occurring on the same line. | In bdt1, the focus is the FIRST byte of difference. Here in bdt2, we are looking at supporting multiple bytes of difference, perhaps even occurring on the same line. | ||
+ | =====Access variables in your C program===== | ||
+ | Setting a variable in your terminal (or even on the command-line prefixing the execution of your bdt2 tool) allows you to communicate information to your program, enabling it to change or alter its default behaviour (just as command-line arguments do) | ||
+ | |||
+ | For this project, you can make use of the **getenv(3)** function, provided in the C standard library (symbols included via the **stdlib.h** file). | ||
+ | |||
+ | Excerpted from the **getenv(3)** manual page: | ||
+ | |||
+ | <cli> | ||
+ | NAME | ||
+ | | ||
+ | |||
+ | SYNOPSIS | ||
+ | # | ||
+ | |||
+ | char *getenv (const char *name); | ||
+ | |||
+ | DESCRIPTION | ||
+ | The getenv() function searches the environment list to find | ||
+ | the environment variable name, and returns a pointer to the | ||
+ | | ||
+ | |||
+ | RETURN VALUE | ||
+ | The getenv() function returns a pointer to the value in the | ||
+ | | ||
+ | </ | ||
+ | |||
+ | Your "const char *name" is the name of the variable set (for the purposes of this project, call it **THROTTLE**). Check the example execution to see it in use. | ||
+ | |||
+ | You may notice similarity in parameter usage to that of other standard library functions that you've utilized, like **atoi(3)**. | ||
+ | |||
+ | **NOTE:** You may **not** want to nest your **getenv(3)** call as a parameter to **atoi(3)**; | ||
=====Reference Implementations===== | =====Reference Implementations===== | ||
To assist you in your off-system development efforts, the **bin/** directory in the bdt2 project (available on lab46 via grabit) has 2 compiled binaries: | To assist you in your off-system development efforts, the **bin/** directory in the bdt2 project (available on lab46 via grabit) has 2 compiled binaries: | ||
Line 127: | Line 159: | ||
<cli> | <cli> | ||
- | $ submit discrete | + | lab46: |
- | Submitting discrete project "bdt1": | + | Submitting discrete project "bdt2": |
- | -> bdt1.c(OK) | + | -> bdt2.c(OK) |
SUCCESSFULLY SUBMITTED | SUCCESSFULLY SUBMITTED | ||
Line 135: | Line 167: | ||
You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches. | You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches. | ||
+ | |||
+ | What I will be looking for: | ||
< | < | ||
- | 156:bdt1:final tally of results (156/156) | + | 195:bdt2:final tally of results (195/195) |
- | *:bdt1:bdt1.c compiles cleanly, no compiler messages [13/13] | + | *:bdt2:bdt2.c compiles cleanly, no compiler messages [13/13] |
- | *:bdt1:bdt1.c implements only specified algorithm [26/26] | + | *:bdt2:bdt2.c implements only specified algorithm [26/26] |
- | *:bdt1:bdt1.c code conforms to project specifications [26/26] | + | *:bdt2:bdt2.c code conforms to project specifications [26/26] |
- | *:bdt1:bdt1.c implementation free from restrictions [26/26] | + | *:bdt2:bdt2.c implementation free from restrictions [26/26] |
- | *:bdt1:bdt1 runtime output conforms to specifications | + | *:bdt2:bdt2.c implements and utilizes THROTTLE usage [13/13] |
- | *:bdt1:bdt1 eval check tests succeed | + | *: |
- | *:bdt1:bdt1 committed, pushed to lab46 repository [13/13] | + | *: |
+ | *:bdt2:bdt2 runtime output matches reference | ||
+ | *:bdt2:bdt2 committed, pushed to lab46 repository [26/26] | ||
</ | </ | ||
+ | |||
+ | Additionally: | ||
+ | * Solutions not abiding by spirit of project will be subject to a 25% overall deduction | ||
+ | * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction | ||
+ | * Solutions not utilizing indentation to promote scope and clarity will be subject to a 25% overall deduction | ||
+ | * Solutions not organized and easy to read are subject to a 25% overall deduction |