Computer Science Canada Records, Part I: Declaration and other Introductory Concepts |
Author: | AsianSensation [ Fri Aug 19, 2005 12:21 am ] | ||||||||||||||||||||||||
Post subject: | Records, Part I: Declaration and other Introductory Concepts | ||||||||||||||||||||||||
Wrecked Cords? Records, incredibly useful thingies they are. Well, thingie isn't really the right definition for it. Here, why not begin with a description: A record is like a composite data type. A record can consists of many fields, and each field may consist of different types of data of varying length. An example being:
While C users may be familiar with records as structures (or struct for short), some of us have never seen this type of declaration before. Why bother to gathering together a bunch of data types that we already know how to use and put them into one big lump? Jean Pockets Don't Make Good Pencil Cases. While there are other reasons for it, records are incredibly useful as an organization tool. Why do you carry binders around in school? Why do you put your pens, pencils, erasers, rulers and straight edges all in a pencil case? You don't do it because your friends will laugh at you because you are not "cool" enough to have a pencil case (well, at least I hope that isn't the case). You do it because it's rather hard to keep track of all your writing utensils if you stick one in your jeans today and the other in your shirt pocket tomorrow. As programmers, we like to keep things clean and efficient. Concise coding can reduce runtime errors and debugging time, especially if multiple people were to look over the same code. As codes that only one person can understand are quite useless to other people, we try to code according to a "good" standard. Using this knowledge, let's find a situation in which records can be well used. Maybe an Example Will Help? Suppose I opened an online dating service called "Love Bytes" (with plenty of financial backings from Mr. Mckenzie). This little online database system allows me to keep track of personal information from various clients. People especially seems to want to know about these details from potential suitors:
2. Last name 3. Gender 4. Age 5. Height 6. Hair colour 7. Love rating Now I want to keep track of these information, so I prompt the user to input their personal data. Assuming I have no knowledge whatsoever of records, here is what I would have done:
Now this would get pretty tedious if there are let's say, 100 people's data to input. You would have to at least create a bunch of different arrays with 100 elements inside to hold the information.
If you are still unfamiliar about arrays, I suggest you read up on the tutorial here at compsci.ca, since it is a very important part of programming. So with an array of 100 elements, termed FirstName, I stored all the first names of the clients, and when I need to use these information, I will have to recall these names by finding the correct array and accessing the correct element. I don't know about you, but it gets really hard to keep track of everything when I have to code a large database program. I don't want to have to spend time looking back once so often to see if I missed Hcolour or forgot which element the index of the array refers to. That wasn't a very efficient (or pretty) way of dealing with the coding. I wanted something more compact, so I learned about records. You will too, provide you look down for a couple of lines. The Way of the Wrecking Cords Like I say before, records are like You-Design-It data types. Tired of classifying variables as string or int? Well, you can now name a type after yourself (if you REALLY wanted to, why not?). The syntax for records looks like this:
Now this may not be that useful to you, so let's put it into an example. We'll use our Love Bytes program from here. Woot! Real Code!
Don't worry if something here doesn't make sense yet, we'll explain it all in due time. What? Why Would I Want to Type the Word Client?
First we'll name our new data type, since we are dealing with clients, we can just name the type Client. You can name it PrezBush if you want (Republican pride? If you REALLY wanted, why not?). The compiler doesn't care about the name; it only helps the person reading the code to become less confused. That's Alot of Stuff...
We want everything we listed above to be included in our new data type, so the syntax dictates that we begin with record, and end with a end record, with every attributes sandwiched in between. Notice that when we are declaring the fields, we are not using var, this is because these aren't variables, rather they are predefined data type fields. The field could be of any type. int, real, boolean, string, char, or even another self defined data type (we'll deal with this specific situation on the next tutorial). Recording with Records
Now we have defined our data type, time to declare some variables. Obviously we want to use what we've just created. In this instance, we create a variable called customers, of the type Client. Remember that Client is a custom data type that we created ourselves, at this point, it is just like int or string, and has its own properties defined by us.
We want to be able to use this variable right? So how do we store values into customers? Customers is accessed just like how normally declared variable are accessed. That is, with one exception: you have to identify the field you wish to access when you call the variable. Trying to operate directly on customers will only result in an illegal action error. You can however, access the fields specified by our custom data type, just by typing the variable name plus a period plus the field. So to gain access to age, we use customers.Age, to gain access to the love rating, use customers.LRating. So far, so good. And that's it. No, seriously, that's all there is to it for the basic use of records. Oh, you want something more complicated? Well, first, answer these questions first, if you got these questions right, then by all means, go on to the next section. Compsci Quiz of Doom!!! Questions #1: Since Client is just another data type, that means I can create an array of Client. So I modified my program above just a little bit, this way, I can keep track of about 100 different clients at the same time.
Running it, the turing compiler tells me that 'customers' cannot be followed by a '.' What? But I just told you that's how we access fields inside a record! Did I lie to you? What's wrong with this program? Highlight to see the answer Quote: if you played around with the position of the index, you should have been able to figure it out. Since we declared an array from 1 to 100 of customers, the index should go after customers, not after FirstName. We should replace the erroneous part with customers (1).FirstName. Placing the index after FirstName has a totally different meaning.
Question #2 So you got the first question solved. What? You didn't? Well, hurry up and go back to it before looking at this one. All solved? Good, now that wasn't all that bad wasn't it? The second question involves the same scenario. Let's go back to the customers.FirstName (1) for a minute. I told you that placing the index of the array behind the field has a different meaning, basically it means now there is an array of FirstName. If we created our records to be like this:
then it would work. The next question involves this: I don't know how many first names a person can have. He or she may have a English name, plus a name in his or her native language, plus some other shortened name that he or she wishes to use at all times. So I want to ask at the beginning how many names they wish to enter. I modified my program to look like the one below:
So I run this program, but of course an error pops up (it wouldn't be a question otherwise 8) ). "Compile time expression expected". Now what does that mean? What did I do wrong? Think about it for a couple of minutes. Once you think you got it, highlight below to see the answer. Quote: Straight out of Turing's help files on records: Any array contained in a record must have bounds that are known at compile time. So that's something we can't do. Whoa you mean to tell me we can't do something with a programming language? Well, technically, no, I'm not. Because there are ways to achieve what we wanted to do initially, you just don't know them yet. I suggest trying for yourself for a bit, and once you are confident in your handling of records, we can move on to the next section of this tutorial: Records Part II: enum, pointer, and other advanced concepts.
Hope this helped. See you next tutorial! |
Author: | AFlea [ Sat Mar 19, 2011 12:30 pm ] |
Post subject: | RE:Records, Part I: Declaration and other Introductory Concepts |
yay! |
Author: | copthesaint [ Mon Mar 21, 2011 11:07 am ] |
Post subject: | RE:Records, Part I: Declaration and other Introductory Concepts |
First post and you resurrect this post from 2005? with a comment that has no significant value? not even a word, just a sound? -_- |
Author: | evildaddy911 [ Wed Nov 09, 2011 8:41 am ] | ||
Post subject: | Re: Records, Part I: Declaration and other Introductory Concepts | ||
im trying to make a record with a flexible array:
it also says that all the other fields of the record "has not been declared" whats wrong? |
Author: | Tony [ Wed Nov 09, 2011 1:56 pm ] |
Post subject: | RE:Records, Part I: Declaration and other Introductory Concepts |
You can't have flexible arrays inside of a record, because the size is not know (can change). |
Author: | DemonWasp [ Wed Nov 09, 2011 3:05 pm ] | ||
Post subject: | RE:Records, Part I: Declaration and other Introductory Concepts | ||
Tony is correct. However, there's an additional point: Turing is a little buggy / inconsistent in the way it handles "flexible" types. For example:
It looks like Turing handles the "flexible" part separately from the actual typeSpec (http://compsci.ca/holtsoft/doc/typespec.html), which prevents it from being used this way. In my opinion, this is wrong, but the chances of getting this fixed are infinitesimal. In short, there's no easy way to use, refer to, or access a flexible array from a record (at least, not without abusing some of Turing's more dangerous / unreliable / undocumented features). You have a few options: A) You can store a (non-flexible) array larger than possibly needed with some blank / unused entries (easiest, most straightforward) B) You can implement a linked-list structure (relatively advanced for a lot of highschoolers) C) You can use Turing's classes to create your own version of a flexible array (pretty advanced knowledge of Turing required). |
Author: | evildaddy911 [ Thu Nov 10, 2011 9:17 am ] | ||
Post subject: | RE:Records, Part I: Declaration and other Introductory Concepts | ||
arright. fixed. now, of course, it highlights "type" and says syntax error, expected '..'
this is an older game i've made, i just wanted to clean up the code a bit |
Author: | Velocity [ Mon Jan 09, 2012 8:22 pm ] |
Post subject: | RE:Records, Part I: Declaration and other Introductory Concepts |
so types and records are an easier way to store data as a bank, just like an array? |
Author: | Dreadnought [ Mon Jan 09, 2012 9:37 pm ] |
Post subject: | Re: Records, Part I: Declaration and other Introductory Concepts |
Yes. There purpose is to help you (and others especially) understand your code by organizing data into structures that make sense to humans. |
Author: | Raknarg [ Tue Jan 10, 2012 11:36 am ] |
Post subject: | RE:Records, Part I: Declaration and other Introductory Concepts |
It makes more sense. For instance, I had this side scrolling shooting game (sort of like galaga), and the player and enemy both had about 20 or more different variables to use. Instead of having a big, ugly list of enemyHealth, enemyX, enemyY, etc. I could simply make a record of specs and assign that record to player and enemy. You can go a little deeper too, by having records within records. Take the enemy specs record. What if I also want a bullet specs record? I could make a record for that, and assign one of the elements in specs to the bullet record. |