======Part 2====== =====Entries===== ====Entry 5: March , 2012==== * On this day, I learned about unions and how they are used in programming. * Unions use the ability to hold multiple variables of different data types in the same memory location and allow the program to call from the union when the variables are necessary. * The downside to the use of unions is that when the program uses the first variable and stores something for use in the second variable, the union scraps the old value and inputs the new one in the union. Basically, the union uses "one space" of memory for all the variables in the union. * When the program calls these variables, the variable is represented by the name of the union, a period, and then the name of the variable. * EXAMPLE: If the union is named value, and the variables are [float f, int x], then when called, the variables will be value.f for the float variable, and value.x for the int variable. ====Entry 6: March 6, 2012==== * On this day, I learned about the declaration **//typedef//** and what it's function is. * The purpose of **//typedef//** is to allow the programmer to create new data type names for the program's variables. * This allows the programmer to change data type names for organization purposes or to possibly shorten some data types. * And example of this would be: **//typedef//** int length; This would cause the //int length// to shortened to just //length//: length max, min; ====Entry 7: March 22 (I think), 2012==== * On this date, I coded one of the most important things in programming: AND, OR, and NOT logic gates in C++.\\ * By doing this, I learned more about what they do, how they are used, and how to combine them and create other logic gates.\\ * This helped me become better acquainted with C++ programming, which is another thing that I learned recently.\\ * It was difficult to comprehend at first, but once I sat down and went through what I had typed up to begin with, everything started to make sense.\\ ====Entry 8: March 13, 2012==== * On this day, we began learning about C++ programming. * C++ programming is seen as an addition to C programming. It is used for Object-Oriented coding. * I learned about C++ in the C for Engineers class that I took in the fall, but what I am being taught now is much different, and I like it more. * So far, C++ is fairly easy to understand and use. I think I will get the hang of the new stuff soon. =====Keywords===== {{page>cprogpart2&nofooter}} =====Experiments===== ====Experiment 4==== ===Question=== What is the difference between using the **fgetc()** function and the **fscanf()** function? ===Resources=== According to a wiki on the website http://www.cplusplus.com/reference/clibrary/cstdio/fscanf/, **fscanf**'s purpose is: "Reads data from the stream and stores them according to the parameter format into the locations pointed by the additional arguments." This means that fscanf takes a stream that is input and stores that stream into a variable with a specified data type. According to a similar wiki on the same website, the function **fgetc**'s purpose is: "Returns the character currently pointed by the internal file position indicator of the specified stream. The internal file position indicator is then advanced by one character to point to the next character." In other words, **fgetc** takes a string and returns whatever it is being pointed to, character by character, until the string ends. One can take a variable and assign it these values. ===Hypothesis=== I think that these two do very similar things, but the main difference is that a programmer can determine a variable data type with **fscanf**, while **fgetc** will always return a character. I that they will do the same thing when the data type of the value in the **fscanf** function is char, but other than that, you will get different results. ===Experiment=== I will create a program that accepts the same value through both **fgetc** and **fscanf** and assigns them to different variables of the same data type. Then, I will use some fprintf functions to print these values, once as a char, and once as an int. ===Data=== Experiment: #include #include int main() { int scanvalue; int fgetcvalue; fprintf(stdout, "Input one number twice: "); fscanf(stdin, "%d", &scanvalue); fgetcvalue = fgetc(stdin); fprintf(stdout, "FSCANFVALUE being printed as an integer: %d\n", scanvalue); fprintf(stdout, "FGETCVALUE being printed as an integer: %d\n", fgetcvalue); fprintf(stdout, "FSCANFVALUE being printed as a character: %d\n", scanvalue); fprintf(stdout, "FGETCVALUE being printed as a character: %d\n", fgetcvalue); return(0); } Result: lab46:~/src/cprog/Opus/Opus2$ ./experiment4 Input one number twice: 10 FSCANFVALUE being printed as an integer: 10 FGETCVALUE being printed as an integer: 10 FSCANFVALUE being printed as a character: 10 FGETCVALUE being printed as a character: 10 lab46:~/src/cprog/Opus/Opus2$ ./experiment4 Input one number twice: 10 10 FSCANFVALUE being printed as an integer: 10 FGETCVALUE being printed as an integer: 32 FSCANFVALUE being printed as a character: 10 FGETCVALUE being printed as a character: 32 lab46:~/src/cprog/Opus/Opus2$ ./experiment4 Input one number twice: 4 FSCANFVALUE being printed as an integer: 4 FGETCVALUE being printed as an integer: 32 FSCANFVALUE being printed as a character: 4 FGETCVALUE being printed as a character: 32 lab46:~/src/cprog/Opus/Opus2$ ===Analysis=== Based on the data collected: * My hypothesis was not correct, it seems that the data type of the variable that the **fgetc** function is storing the input is what matters. * My hypothesis was relevant, but the trouble that comes is when **fgetc** accounts for the spaces, which **fscanf** does not account for. * There is more than I thought going on, the function accounts for the data type of the value that the input is being stored into, which I didn't think happened. * Like I stated, all input is taken when running **fgetc**, which could cause a problem with the output. * There don't seem to be any shortcomings in my data. ===Conclusions=== What this experiment helped me understand is that **fgetc** and **fscanf** are applicable when accepting input, but I should watch out for any extra input, like enter, space, backspace, etc. ====Experiment 5==== ===Question=== When given two different arrays with different values in them, what would happen if you set one equal to the other? ===Resources=== According to what I have learned, an array, when set equal to another array, as a pointer, will only have the array point to the address of the other. ===Hypothesis=== I think that the array that will be set equal to another array will point to the address of the other, changing what memory it holds to the same memory as the other array. I have used this method a lot, and, so far, all I have seen is this result. Testing it now! ===Experiment=== I will create code that will take two arrays, with different values stored in them, and set one equal to the other, and then reverse them and set them equal to each other. I will print each of the arrays before and after this switch of values. ===Data=== **DA CODE:** #include #include int main() { char *array1, *array2; int i; array1 = (char *) malloc (sizeof(char) * 4 ); array2 = (char *) malloc (sizeof(char) * 4 ); printf("Input a 4 letter word: "); for( i = 0; i <= 3; i++ ) { *( array1 + i ) = fgetc( stdin ); } for( i = 0; i <= 3; i++ ) { printf("%c", *( array1 + i ) ); } getchar(); printf("\nInput a 4 letter word: "); for( i = 0; i <= 3; i++ ) { *( array2 + i ) = fgetc( stdin ); } for( i = 0; i <= 3; i++ ) { printf("%c", *( array2 + i ) ); } array1 = array2; array2 = array1; printf("\nArray1: "); for( i = 0; i <= 3; i++ ) { printf("%c", *( array1 + i ) ); } printf("\nArray2: "); for( i = 0; i <= 3; i++ ) { printf("%c", *( array2 + i ) ); } printf("\n"); return 0; } The result: lab46:~/src/cprog/Opus/Opus2$ ./experiment5 Input a 4 letter word: Cavo Cavo Input a 4 letter word: Josh Josh Array1: Josh Array2: Josh lab46:~/src/cprog/Opus/Opus2$ ./experiment5 Input a 4 letter word: Josh Josh Input a 4 letter word: Cavo Cavo Array1: Cavo Array2: Cavo lab46:~/src/cprog/Opus/Opus2$ ===Analysis=== Based on the data collected: * Was your hypothesis correct? -- My hypothesis was correct, the first time one was assigned to the other, it dropped it's previous memory assignment and pointed to the new one. * Was your hypothesis not applicable? -- I believe my hypothesis was applicable. * Is there more going on than you originally thought? (shortcomings in hypothesis) -- There doesn't seem to be more than I thought going on. * What shortcomings might there be in your experiment? -- There weren't any shortcomings, FOR THE FIRST TIME, I MADE CODE AND IT RAN JUST AS I WANTED IT TO! NO PROBLEMS! * What shortcomings might there be in your data? -- My data was correct and accounted for! ===Conclusions=== I can conclude that my knowledge of arrays has increased, and is pretty good, now. Probably due to the great amount of arrays and array passing in projects 2 and 3. ====Retest 2==== Perform the following steps: ===State Experiment=== Whose existing experiment are you going to retest? Provide the URL, note the author, and restate their question.] -- I will be retesting Robert Matsch's third experiment, asking what happens if one accidentally puts **'** in instead of **"**. -- **URL**: http://lab46.corning-cc.edu/opus/spring2012/rmatsch/start#experiment_3 ===Resources=== Evaluate their resources and commentary. Answer the following questions: * Do you feel the given resources are adequate in providing sufficient background information? -- He stated one resource, the C ANSI book that was purchased for the class. I believe that this would give enough information about the experiment. * Are there additional resources you've found that you can add to the resources list? -- The interwebs! * Does the original experimenter appear to have obtained a necessary fundamental understanding of the concepts leading up to their stated experiment? -- I believe he has, it gave him many errors, so I believe that he could understand that it isn't a good thing to do. (I hope) * If you find a deviation in opinion, state why you think this might exist. -- I have no objections. Everything seems to be in order! ===Hypothesis=== State their experiment's hypothesis. Answer the following questions: * Do you feel their hypothesis is adequate in capturing the essence of what they're trying to discover? -- Yeah, I believe that it covers anything they may see. * What improvements could you make to their hypothesis, if any? -- I think that he could have added more explanation, but mainly a spellcheck! :x ===Experiment=== Follow the steps given to recreate the original experiment. Answer the following questions: * Are the instructions correct in successfully achieving the results? -- They are correct, there isn't much more one can do when testing to see if it works or not. * Is there room for improvement in the experiment instructions/description? What suggestions would you make? -- I have no suggestions. * Would you make any alterations to the structure of the experiment to yield better results? What, and why? -- I would have added the result of the working code as well, and I would have just attempted to run the incorrect code, just to show the reader what happens. That could give the reader more piece of mind on the matter. ===Data=== Publish the data you have gained from your performing of the experiment here. The code of the correctly done program: #include int main() { printf("Hello, World!\n"); return 0; } the code of the incorrectly done program: #include int main() { printf('Hello, World!'); return 0; } The result of the correctly done program, followed by the result of the incorrectly done program: lab46:~/src/cprog/Opus/Opus2$ gcc -o retest retest.c lab46:~/src/cprog/Opus/Opus2$ gcc -o retestwrong retestwrong.c retestwrong.c:5:9: warning: character constant too long for its type retestwrong.c: In function 'main': retestwrong.c:5: warning: passing argument 1 of 'printf' makes pointer from integer without a cast /usr/include/stdio.h:339: note: expected 'const char * __restrict__' but argument is of type 'int' lab46:~/src/cprog/Opus/Opus2$ ./retest Hello, World! lab46:~/src/cprog/Opus/Opus2$ ./retestwrong Segmentation fault lab46:~/src/cprog/Opus/Opus2$ ===Analysis=== Answer the following: * Does the data seem in-line with the published data from the original author? -- The data that I have seems nearly identical to the data that Rob had. * Can you explain any deviations? -- There were no deviations. * How about any sources of error? -- The only errors were the expected ones that came with only putting **'** instead of **"**. * Is the stated hypothesis adequate? -- The stated hypothesis was adequate, he seemed to know what the result would be. ===Conclusions=== Answer the following: * What conclusions can you make based on performing the experiment? -- I concluded that when putting a **'** symbol in for a **"** symbol in printf statements, an error occurs. I wasn't sure if something else would happen, which is why I chose this experiment. * Do you feel the experiment was adequate in obtaining a further understanding of a concept? -- Absolutely, this experiment helped me to determine the result of my curiosity of a different, but slightly similar, symbol replacing the quotations. * Does the original author appear to have gotten some value out of performing the experiment? --I believe he has gotten some value out of this experiment. * Any suggestions or observations that could improve this particular process (in general, or specifically you, or specifically for the original author). -- I don't think there are any suggestions, seems pretty straight forward.