Better late than never: something that proves true in most things, so long as they do not pertain to medicine or birth control…

Let us begin with data types and their importance. Data types are crucial to the language of C as a concept and in application. As both Mr. Haas and Mr. Oppenheim have pointed out, controlling the flow of memory is really at the center of what makes C apparently great. With memory flow being so crucial to C's functionality, we can use data type declarations to call a very specific amount of memory to store our values. This is also apparently a great asset. I say “apparently”, not to be sarcastic, but because i have no basis for which to form my own opinion on a subject that i am so thoroughly unversed in. C is also powerful due to the low level nature of its syntax, C makes few assumptions and it is up to the programmer to use functions and declarations to control most aspects of the program's functionality and memory management. This verbose nature of C, while frightening in appearance, can lead to very efficient and controlled programming - so they tell me.

Today in Mr. Oppenheim's lecture we defined a C declaration. A declaration in C is nothing more than a data type coupled with an identifier. The data type determines how much memory will be allocated for this declaration and the identifier is the name in which we will use to identify it. Essentially, a declaration is saying that something exists (identifier) and this is how much memory it needs (data type).

 int var; 

In this example of a declaration we can see that the data type is that of an int, which is typically 4 bytes. We can also see that the identifier is var, this does not need to be var, it could be anything, but in this case var is used as the identifier to this declaration. In a nut shell we are declaring that var is a thing that exists and that it will have the memory size of int.

We also discussed the concept of an array. An array differs from a list in that a list of values do not necessarilly all exist within the same data type. In an array, all elements to be indexed will exist as the same data type. Unless I am mistaken, an array will also store all elements of the array into contiguous memory. for example let us create an array

 int var3[3];

we have declared an array with the identifier of var3 with three elements and all of these elements are of the int data type. These 3 elements of the array will be indexed as element 0,1, and 2. This allows us to keep multiple (possibly related) values of the same data type associated with the same identifier.

Mr. Oppenheim also declared vigorously that in C there is no such thing as “the equal sign”, in C the '=' is a reference of assignment. Though the notion of equivalence does exist in C, referring to '=' as equaling anything is technically incorrect.

In Summary

I felt like I learned some perspective in this lecture. Arrays and declarations are something that I was previously aware of, but more insight into concept and context is never a bad thing.

I wonder though, what happens when you work with an array and later realize that you should have created your array with more elements? I would assume that you simply cannot tack an extra element onto an array that has already been declared. For example, if you had int smallarray[10] but later into your programming you wish you would have made int largerarray[20] instead. Can you simply create the larger array and import the contents from the smaller into the first 10 elements of the larger? I fear that would either not be possible, or not possible easily.

Today in lab we discussed loops in concept and in practice.

At its core a loop is nothing more than a body of code that repeats itself until a specific condition is met. In C there are three types of loop. A task that may be elegantly completed by using a loop can generally be accomplished through any of the three loop forms, though the execution will differ.

For

Do

Do While

– There is also the notion 'pretest' or 'post test' in reference to loops.

A pretest loop checks the condition against the variable initialization before the loop body runs, if the condition is agreeable to the variable initialization, then the body of the loop will run. What this means is that a pretest loop may not ever run, depending on the conditions. For and Do loops are pretest loops.

Pretest loop that will run:

 
int main ()
{
int a; 
   for(a=1 ; a <= 100 ; a++)
   {
   fprintf(stdout, "SUFFER THE CHILDREN \n");
   }
return(0);
}

Pretest loop that will NOT run:

 
int main ()
{
int a; 
   for(a=101 ; a <= 100 ; a++)
   {
   fprintf(stdout, "SUFFER THE CHILDREN \n");
   }
return(0);
}

We can see that in the first example that the variable intialization is a=1, and the condition is a⇐100. since a=1 is certainly less than or equal to 100, the loop body will run. Each time the loop runs 'a' will be incremented by 1. Once 'a' is greater than 100, the loop body will not run.

A post test loop will always run at least once. The condition will be evaluated after the loop body has ran.

It is worth noting that loops will not yield the only successful way to accomplish a task; loops simply allow us to elegantly accomplish a task.

Today in lecture we covered the idea of a switch and a case, what happens within those cases, and the scope of the cases. A case is similar to an if/then condition with a handful of differences. In an if..then..else condition a value is compared to a condition and based on how that value is interpreted a select body of code will run or not run. This same concept applies to cases, generally. One key thing to note is that when dealing with cases, which ever case gets initialized, all the of the subsequent cases within the scope of the switch will run as well. The keyword break; is useful because it prevents subsequent cases from running. Here is a meaningless example of case usage.

 #include <stdio.h>
main()
{
        srand(time(NULL));
        int x = rand()%14+1;
        int age;
        int dead;
        dead = 80;
        switch (x)
                {
                case 1 :        fprintf(stdout, "Someday I will melt coins down and turn them into a sword and use it to slay the homeless\n");
                break;
                case 2 :        fprintf(stdout, "The Dinosaurs went extinct because they eliminated minimum wage and over consumed resources, also - METEOR\n");
                break;
                case 3 :        fprintf(stdout, "Why on earth did I decide to test this with 15 possible cases?\n");
                break;
                case 4 :        fprintf(stdout, "THE PHONECALLS HAVE BEEN COMING FROM YOUR HOUSE THE WHOLE TIME! GET OUT NOW!\n");
                break;
                case 5 :        fprintf(stdout, "Bah Weep Grannah Weep Mini Bon\n");
                break;
                case 6 :        fprintf(stdout, "GET TO THAA CHOPPA'\n");
                break;
                case 7 :        fprintf(stdout, "How old are you ?\n");
                                scanf("%d", &age);
                                fprintf(stdout, "I bet you will be dead in ""%d"" years.\n",dead-age);
                break;
                case 8 :        fprintf(stdout, "Natural peanut butter is completely superior to the processed stuff!\n");
                break;
                case 9 :        fprintf(stdout, "If I could be any sort of dragon I would be a dragon that can shoot wolves out of his mouth; wolves that are on fire$
                break;
                default:        fprintf(stdout, "I ran out of ideas, the random number was:""%d\n", x);
                }
return (0);
}

I used a (pseudo)random number to select the case and a 'break;', between the cases to prevent all subsequent cases from running. Nothing fancy. There is also the case label of 'default' - this case will execute any time none of the cases are initialized by the evaluation of the condition. In my example the default case ran any time x was 10 or higher.

Today in Joe's lecture we discussed the differences between having a function utilize fprintf to display output and assigning the return to value of the output. Obviously, when using return as the output source we cannot use fprintf to check the efficacy of the function. Additionally we also went over the concept of feeding input into a function as it is called instead of using fscanf to ask for it.

Pardon my pseudo code:

 
int add(int a, int b)
{
int sum;
sum=a+b;
return sum;
}

This varies slightly in that we are not using fscanf or fprintf to handle input or output feeds. Not revolutionary, but interesting. Although I do forget how to check the return value, I believe it has something to do with 'echo'

We also discussed the functions memmove and strcopy and how they both relate directly with the manipulation of memory and the data contained within. They are different though, strcopy uses a string pointer to take the string up to the terminator '/0' and moves the string into an array. Memmove takes an exact number of bytes designated by a pointer and then relocates those bytes into another location, also designated by a point.

We briefly discussed atoi,atol, and atoll but I am not able to extrapolate their usefulness.

Joe tasked us today with turning our previous workload from Structured and Object Oriented Problem Solving into the C equivalent. The functions will reamin the same in function but implementation will vary from vbs.

As a simple demonstration of turning something from vbs into a C equivalent: VBS: Or logic

function andd( bier1, bier2 )
	if bier1 = This then 
	if bier2 = This then andd = This
	end if
	if bier1 = This then 
	if bier2 = That then andd = That
	end if
	if bier1 = That then
	if bier2 = That then andd = That
	end if
	if bier1 = That then
	if bier2 = This then andd = That
	end if
End function

C: And logic:

char andd(char bier1, char bier2){
	if (bier1 == this);
	{
		if (bier2 == this) add = this;
		else andd = that;
	}
	if (bier1 == that);
	{
		if (bier2 == that) andd = this;
		else andd = that;
	}
return(andd);
}

Conceptually they are the same, but their literal implementation is different.

On Friday we looked at the implementation and purpose of a struct as it relates to C. struct allows us to create a sort of relationship between variables of different data types. This is important because while an array requires all elements to be of the same data type, a struct does not. Thankfully, a struct does not require consistent data types between the variables that it is relationing. (I feel that relationing should be a word)

Arrays can be stored into struct, structs can even be stored in structs. A function may not be stored in a struct, though a function pointer is valid. The scope of a structure is limited, two separate structures can even contain the same variable name without causing a compiler error.

The structure exampled in class is as follow:

struct person{
   char name[80];
   int age;
   float height;
};

We can see that this structure is combining an array of chars, an int, and a float. These three data types will be joined together under the structure name 'person'. While the data organic to this structure will not be manipulated by the structure, it does allow for easy referencing of data. Interestingly, unlike a function definition, the structure requires a ; after the concluded code block.

In Mr. Oppenheim's lecture we discussed the list of keywords native to C. Out of 37 keywords we have been exposed to a large number of them.

Keywords

The keywords we have been exposed to have been slashed. Also, I am never making a table again.

Mr. Oppenheim said that for most uses today the keywords auto, register, restrict, and volatile are of low priority and don't see very much usage.

Continued work on the hex editor in Mr. Oppenheim's lecture. This is what I'm working with currently.

#include <stdio.h>

int main(){
int i;
int n = 0;
int m = 256;
int col;
unsigned char buffer [256];


printf("Offset ");

for(i=0 ;i<16; i++){
	printf("%2.2X ", i);
	}

printf("\n       ");

while(m>0){
	buffer[n]=m;
	m--;
	n++;
	printf("%2.2X ", m);
	}
return(0);

}

Interestingly, I downloaded a number of free open source hex editors written in C to get an idea of how code gets combined with an interface. Unfortunately, the code looks baffling. I guess you never really know how little you know until you see how little you know.

I have made some progress on the hex editor for Mr. Oppenheim's lecture. The code is as follows:

#include <stdio.h>

int main(){
int i;
int n = 0;
int m = 256;
int column = 0;
int spacing;
unsigned char buffer [256];


printf("Offset ");

for(i=0 ;i<16; i++){
	printf("%2.2X ", i);
	}
printf("\n       ");

while(m>0){
	for(column=0;column < 16 ; column++){
	printf("\n  %2.2X | ", column);

		for(spacing=0 ; spacing < 16 ; spacing++){
			buffer[n]=m;
			m--;
			n++;
			printf("%2.2X ", m);
		}
	}
}

return(0);

}

I had some trouble coming up with a way to implement correct spacing and increasing the values of the rows and columns. Harry Longwell mentioned utilizing nested loops. I played around with it and got to this point currently. It is still a work in progress obviously, this is currently demonstrating a concept and is not functional in purpose.

I have no idea how to functionally open a file into it, or to step the buffer to view the next sequence of data. I'm also not sure how to set a specific list of available commands to affect the program, while ignoring non-predetermined commands. On top of all of that, I'm sure the bulk of my code thus far can be reduced to be more efficient. For the column I'm sure I could have used an array, and I would be willing to guess that I will need to make it into an array before the end of this project.. I will say that this project is interesting.

Project0x0 of the End of Course Experience is a Fibonacci sequence. Or rather, the output is a Fibonacci sequence. Recreating the output is an interesting exercise in that you are free to reach the conclusion in a number of ways. I used a pair of nested loops, as this seemed to be the most straight forward approach. I had trouble keeping my variable assignments correct. The output would fail to meet expected results after the first four segments. Eventually I wrote out the first eight segments of the sequence on paper. Using this approach I was able to better utilize my aging brain. This proved successful. My output is as follows.

Interestingly, the concept detailed by a fibonacci sequence is visible in nature in several structures in plants and animals.

Wwwweeeeee!

In Mr. Oppenheim's lecture we discussed some important distinctions. While these are not revolutionary, I always find minor but fundamental differences important to keep track of.

int a;
a =3;
a=3.0;

The second assignment is invalid because even though 3.0 certainly looks like a integer to the user, the compiler will consider this a float. Since a has been declared an integer, a float won't work here.

Memory allocated for an int is different than a char or a float. So, naturally my first assumption was that an int pointer was different than a char pointer or a float pointer. int * a; float * b; char * c; All three of these are the same size. Initially I didn't think this made any sense. When I thought about it though, it makes perfect sense. An int is a specific sized portion of memory. An int pointer identified as 'a' is simply pointing to the beginning address. Anything beyond that address, sequentially, is not handled upon the declaration. I thought this was really interesting.

we also looked at

char * s; 

and

*s = 5;

Where s now points to an address, *s = 5 is changing the value stored at that address. Again, this isn't a magnificent discovery, but it is important.

We also distinguished between functions and function pointers. Function pointers can point to any other function that's been declared. int d( ); is not the same thing as int *d( );. The difference being that where as the first declares a function named d that returns an int; the second points to a function named d that returns an int. Function pointers do still confuse me unfortunately.

We also looked at a way to manipulate the address that a pointer is referencing.

char * s;
char * dstart;
     dstart = s;
*s=d;
*s++=o;
*s++=g;
*s++=\0;
s=dstart;

This is simple but it is demonstrative. The address that s is referring to is being incremented and storing a new character. At the end of the code s is no longer representing the original address. By creating a second char pointer named dstart in the beginning and assigning s to it we have easily made a way for us to revert to the original address, without having to keep track of how many times s was modified beyond the beginning.

Obviously, my tree needs some work.