========================================================================= Date: Mon, 24 Jan 2000 14:43:51 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: CS2604 listserv test MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is a test message to verify that the CS2604 listserv has been set up correctly. Note that, while the CS2604 listserv is unmoderated and postable by all participants, you can ONLY post to the listserv if you originate the email from the account that you are registered under (normally your VT PID account). If you need to be registered under a different account to be able to post, contact your instructor. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science FAX: (540) 231-6075 Virginia Tech, Blacksburg, VA 24061-0106 Email: shaffer@cs.vt.edu ----------------------------------------------------------------------- ========================================================================= Date: Mon, 24 Jan 2000 13:47:16 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Ben Keller Subject: test MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit appologies for filling your mailboxes. -- Ben Keller email: keller@cs.vt.edu Visiting Assistant Professor phone: 540-231-9367 Computer Science Dept (0106) web: www.cs.vt.edu/~keller Virginia Tech Blacksburg, VA 24061 USA ========================================================================= Date: Mon, 24 Jan 2000 14:51:36 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Another test MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Please ignore. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science FAX: (540) 231-6075 Virginia Tech, Blacksburg, VA 24061-0106 Email: shaffer@cs.vt.edu ----------------------------------------------------------------------- ========================================================================= Date: Mon, 24 Jan 2000 15:06:04 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Ali Asghar Zafer Subject: test..listserv MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi This is a test message to the listserv. Please ignore it. Thanks Ali Asghar Zafer ========================================================================= Date: Mon, 24 Jan 2000 16:51:24 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Dmitry Shiraev Subject: test MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Just a test, please ignore. Thanks, Dmitry Shiryaev ========================================================================= Date: Mon, 24 Jan 2000 18:48:49 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brandon McKelvey Subject: question MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit I got a question... the spec says that we are to store the integers in the list as a character. Can someone please explain to me how this will work. A 32-bit it can be a variable amount of characters. So how does this work? How many characters will the integer take up in the character array, moreover I guess you can just cast up and cast down and then it will be a constant amount of space. Can someone please shed some light on this? Brandon ----- Original Message ----- From: Cliff Shaffer To: Sent: Monday, January 24, 2000 2:51 PM Subject: Another test > Please ignore. > > -- > Cliff Shaffer, Associate Professor Phone: (540) 231-4354 > Department of Computer Science FAX: (540) 231-6075 > Virginia Tech, Blacksburg, VA 24061-0106 Email: shaffer@cs.vt.edu > ----------------------------------------------------------------------- ========================================================================= Date: Mon, 24 Jan 2000 19:21:25 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Stephen Hoskins Subject: casting question MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit For each block in the freelist block we are supposed to have two pointers. Since everything is a char in the memory pool how are we supposed to convert some of the chars in the char array into char pointers??? I've been testing various methods of casting however I haven't had much success. I'm having the same problem with ints. We are supposed to store ints into the char array. In class today I believe that it was somewhat suggested that the chars in the array be casted as ints. Well, I'm having the same problem with this. To be honest I have never attempted to do such a thing before -ie, casting chars into ints. This seems very strange to me. I find myself doing things which I consider to be abnormal practice in this program. Can someone clear things up for me? Thanks alot. ========================================================================= Date: Mon, 24 Jan 2000 20:03:46 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Peter Huene Subject: Re: question In-Reply-To: <001301bf66c5$9f5e2180$ebd8c026@parklink.net> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit I have not yet read the spec (simply because as we all know College Park's Ethernet is 10 times worse than a 14.4 and I can barely ping a VT server, let alone download a pdf). I'm assuming that the list (memory pool?) is an array of characters. ANSI characters are 1 byte in length, and thus would require 4 characters to store a 32 bit integer (which is 4 bytes) in them. Easiest way to copy a 4 byte integer into an array of characters is to use memcpy() ( memcpy((void *) &charlist[index], (void *)&myint, sizeof(int)); //Copy 4 bytes from myint into the array at the given index), although you could cast masking operations as well into 4 separate indices. Not sure if Dr. Shaffer wants us to use memcpy() or to do it another way. If the list you are referring to is the memory pool, you should consider it a linear buffer of bytes and not a linear buffer of characters (or as a string). To extract the integer from the array, you just reverse the memcpy() call, memcpy((void *) &myint, (void *) &charlist[index], sizeof(int));. memcpy() could be used for ANSI strings as well as ints: memcpy((void *) &charlist[index], (void *) string, strlen(string)); this will copy the string without copying the terminating NULL. Hope this helps and was on the right track. As soon as my connection picks up I'll check the spec and correct my assumptions if I am wrong. Regards, Peter Huene -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Brandon McKelvey Sent: Monday, January 24, 2000 6:49 PM To: CS2604@LISTSERV.VT.EDU Subject: question I got a question... the spec says that we are to store the integers in the list as a character. Can someone please explain to me how this will work. A 32-bit it can be a variable amount of characters. So how does this work? How many characters will the integer take up in the character array, moreover I guess you can just cast up and cast down and then it will be a constant amount of space. Can someone please shed some light on this? Brandon ----- Original Message ----- From: Cliff Shaffer To: Sent: Monday, January 24, 2000 2:51 PM Subject: Another test > Please ignore. > > -- > Cliff Shaffer, Associate Professor Phone: (540) 231-4354 > Department of Computer Science FAX: (540) 231-6075 > Virginia Tech, Blacksburg, VA 24061-0106 Email: shaffer@cs.vt.edu > ----------------------------------------------------------------------- ========================================================================= Date: Mon, 24 Jan 2000 20:43:30 -0700 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Ben Keller Subject: Re: question MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Don't think of the array of char as an array of characters. Think of it as an array of bytes, which it really is. So, a 32-bit int takes up four bytes, which is four chars. So, an int always takes up the same amount of space in the array. Brandon McKelvey wrote: > > I got a question... the spec says that we are to store the integers in the > list as a character. Can someone please explain to me how this will work. > A 32-bit it can be a variable amount of characters. So how does this work? > How many characters will the integer take up in the character array, > moreover I guess you can just cast up and cast down and then it will be a > constant amount of space. Can someone please shed some light on this? > > Brandon -- Ben Keller email: keller@cs.vt.edu Computer Science Department phone: 1-540-231-9367 Virginia Tech Blacksburg, VA 24061-0106 USA ========================================================================= Date: Mon, 24 Jan 2000 21:07:14 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Stephen Hoskins Subject: Re: casting question MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit The reason I want to cast some of the elements of the char array into char pointers is because I want to be able to reference the next and previous blocks that are free. This is how it seems to be suggested in the description of the free block list. Sort of an embedded list within the char array. Am I correct in what I am saying or am I going about this the wrong way? Thanks! "Bryan R. Deehring" wrote: > > > -----Original Message----- > From: Stephen Hoskins [SMTP:shoskins@VT.EDU] > Sent: Monday, January 24, 2000 7:21 PM > To: CS2604@LISTSERV.VT.EDU > Subject: casting question > > For each block in the freelist block we are supposed to have two pointers. > Since everything is a char in the memory pool how are we supposed to > convert > some of the chars in the char array into char pointers??? > > [Bryan R. Deehring] --->Why do you want to cast an element of the char > array to a char pointer? That would turn your data into an address. > > I've been testing > various methods of casting however I haven't had much success. I'm having > the > same problem with ints. We are supposed to store ints into the char array. > In > class today I believe that it was somewhat suggested that the chars in the > array be casted as ints. Well, I'm having the same problem with this. To > be > honest I have never attempted to do such a thing before -ie, casting chars > into > ints. This seems very strange to me. > > [Bryan R. Deehring] ---> Think about your memory pool, and its structure. > You have to make the decision on how you want to store the int in the char > array. You can do it in any number of ways. Don't depend on casting and > converting if you are having trouble with it. Just think of everything in > bits. In bits its all the same. All you are essencially doing is storing > 4-bytes (32-bits) to 4-bytes of your memory pool. For example, if you know > your X-coord is going to be stored in MemoryPool[1024], then cast the > address of MemoryPool[1024] to an int and copy the int to that pointer > location. You just wrote an int in the 4 'char' bytes (MemoryPool[1024] - > MemoryPool[1027]. So then when you want to read it, you read from > MemoryPool[1024] as an int. > > I find myself doing things which I > consider to be abnormal practice in this program. Can someone clear things > up > for me? Thanks alot. ========================================================================= Date: Mon, 24 Jan 2000 21:27:18 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Matt Subject: Implementation Question MIME-version: 1.0 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_ok73rFVtuMn6k2IwM/PS9Q)" This is a multi-part message in MIME format. --Boundary_(ID_ok73rFVtuMn6k2IwM/PS9Q) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable I have a question about how exactly you are supposed to implement = the memory pool for the characters. Can you store each character as a node = in a linked list, and then assume the if you store an integer, it should = count as 4 characters? Or can you store the number simply as a direct character translation, so that the integer might take up 9 spaces( for a 32 bit integer)? Or do the characters have to be in an old fashioned array, so = that it is declared like: char temp[2000] ? In that case, would you have to use type casting to hold the integer, or could you simply translate it into a character, so again it would take = up 9 spots. And, if you typecast an integer as a character in the array, = would the integer automatically take up 4 spots in the array, or would you = have to just know that it's taking up 4 times the memory of a character? Please clarify this issue for me. I seem to be a little shaky on the = whole thing. --------------------------------------------------------------- Matt Blair www.cslab.vt.edu/~mablair/ --Boundary_(ID_ok73rFVtuMn6k2IwM/PS9Q) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
    I have a question = about how=20 exactly you are supposed to implement the
memory pool for the = characters. Can=20 you store each character as a node in a
linked list, and then assume = the if=20 you store an integer, it should count as
4 characters? Or can you = store the=20 number simply as a direct character
translation, so that the integer = might=20 take up 9 spaces( for a 32 bit
integer)? Or do the characters have to = be in=20 an old fashioned array, so that
it is declared like:

char = temp[2000]=20 ?

In that case, would you have to use type casting to hold the = integer,=20 or
could you simply translate it into a character, so again it would = take up=20 9
spots. And, if you typecast an integer as a character in the array, = would
the integer automatically take up 4 spots in the array, or = would you=20 have to
just know that it's taking up 4 times the memory of a=20 character?

Please clarify this issue for me. I seem to be a = little shaky=20 on the=20 whole
thing.
------------------------------------------------------= ---------
Matt=20 Blair
www.cslab.vt.edu/~mablair/=
--Boundary_(ID_ok73rFVtuMn6k2IwM/PS9Q)-- ========================================================================= Date: Mon, 24 Jan 2000 21:27:40 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brian Subject: many questions In-Reply-To: <001301bf66c5$9f5e2180$ebd8c026@parklink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" OK, I have a few rather detailed questions for the GTA's / profs.: 1) There is no input file given on the command line, rather input is to be read from standard input. Therefore, should we code an 'exit' command, or can we assume you will be piping in a file and look for an EOF on STDIN (or both?)? 2) The spec does NOT require us to make the x and y coords a constant length. (it says one 'option' would be to make them fixed length, but doesn't specifically require it) Prof. Roach told us in class today that we had our choice as to whether to cast or to leave them as chars. I just wanted to check this with everyone so I won't get points taken off for leaving my x&y coords as variable length chars in the memory pool. 3) The spec also doesn't specify what type of linked list we should implement. Are you expecting some specific type of linked list format, or are we allowed to design our own? 4) If we insert a new record over top of an old record, the spec says to remove the old one first. What if, after removing the old record, there is not enough space for the new record anywhere in the pool? Should we somehow un-remove the old record, or leave that record space as removed (since the old record is gone, but the insert failed)? Here are some questions that we answered in class today, just thought I throw them out to make sure I didn't hear something correctly: 1) We can assume the commands will not contain syntax errors. (Like a letter for a coordinate) 2) There will be NO spaces or blanks (whitespace) of anykind in the city name. 3) The pool size and the number of records (the record array size) will not be larger than a 'long'. ========================================================================= Date: Mon, 24 Jan 2000 21:38:30 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Michael Witczak Subject: testing question MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Is there going to be a file for which we can test our output against, and if so when can that be available? Thanks in advance MW ========================================================================= Date: Mon, 24 Jan 2000 21:46:52 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: James Moniz Subject: Re: question Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Okay, I'll raise my hand and say I'm the stupid one. >Don't think of the array of char as an array of characters. Think of it >as an array of bytes, which it really is. So, a 32-bit int takes up >four bytes, which is four chars. So, an int always takes up the same >amount of space in the array. The profs keep mentioning this like we were taught how to do this. Now, I attended every class and paid close attention, but I, for one, don't remember hearing how, _specifically_, this is done. If it's something obvious, well, it ain't, or I wouldn't be wasting my time and ya'll's mailbox space writing this. How do you get a 32-bit integer to wrangle itself into an 8-bit char array? I find it in no book and no set of notes. Thank you. James Moniz jmoniz@vt.edu ========================================================================= Date: Mon, 24 Jan 2000 21:50:33 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jonathan Pryor Subject: Re: question In-Reply-To: <388D1BE2.E63581A3@cs.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit This still leaves the question (which I'm guessing will be asked) of "how do we convert an array of bytes into an int"? Through the use of either * gratuitous (but necessary) casts * memcpy() Both of these are demonstrated in the sample below, in which: * an array of ``byte'' (unsigned chars) is allocated with enough storage to hold a ``long'' * a value is assigned to the long * The value of the long is copied into the array of ``byte''. Notice that ``reinterpret_cast'' (or a C-style cast) is needed to do this. * Instead of using the "cast to a pointer and dereference" trick, you can memcpy() the contents of the long over the byte array. * The byte array is interpreted as a long, and displayed to the screen. The value displayed is the same as the value displayed when the `long' was displayed. The sample code: #include // cout #include // hex #include // memset using namespace std; void print (void* pv, unsigned int n) {char* pach = reinterpret_cast(pv); for (int i = 0; i < n; i++, ++pach) cout << "\t" << i << ": " << *pach << " (" << hex << int(*pach) << ")" << endl; cout.unsetf(ios::hex);} int main () {typedef unsigned char byte; // stores enough memory to hold a ``long'' byte ab[sizeof(long)]; long l = 42; cout << "uninitialized array:" << endl; print (ab, sizeof(ab)); cout << "long value: " << l << endl;; *(reinterpret_cast(ab)) = l; cout << "array after copying an int into it:" << endl; print (ab, sizeof(ab)); memset (ab, 0, sizeof(ab)); cout << "cleared array:" << endl; print (ab, sizeof(ab)); memcpy (ab, &l, sizeof(ab)); cout << "array after using ``memcpy'' to initialize it:" << endl; print (ab, sizeof(ab)); cout << "printing out the array as an int: "; cout << *((long*)ab) << endl; return 0;} Moderately ugly? A little. However, I know of no other way than to use casts or memcpy() to "reinterpret" a byte array into the desired type--be it a long or some user defined type. A word of warning about the "Reading and Writing Complex Data" section in the "C++ Binary File I/O" section of the course web site: copying the contents of a structure directly into an output stream is moderately "evil" because the compiler typically inserts "space" between the data members in structures for alignment purposes--and the space may vary from between compiler versions and platforms. Therefore, printing out a structure tends to be compiler-specific. However, given that the sizes of the types also tend to vary between platforms, this may not matter. If portability of data files across platforms is a design goal, however, plain text tends to be the only safe encoding scheme. See "The Practice of Programming" by Brian W. Kernighan and Rob Pike, page 203 (section 8.5: Data Exchange). Hope all this is of some usefulness. Jonathan Pryor jonpryor@vt.edu > -----Original Message----- > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > Ben Keller > Sent: Monday, January 24, 2000 10:44 PM > To: CS2604@LISTSERV.VT.EDU > Subject: Re: question > > > Don't think of the array of char as an array of characters. Think of it > as an array of bytes, which it really is. So, a 32-bit int takes up > four bytes, which is four chars. So, an int always takes up the same > amount of space in the array. > > Brandon McKelvey wrote: > > > > I got a question... the spec says that we are to store the > integers in the > > list as a character. Can someone please explain to me how this > will work. > > A 32-bit it can be a variable amount of characters. So how > does this work? > > How many characters will the integer take up in the character array, > > moreover I guess you can just cast up and cast down and then it > will be a > > constant amount of space. Can someone please shed some light on this? > > > > Brandon > > -- > Ben Keller email: keller@cs.vt.edu > Computer Science Department phone: 1-540-231-9367 > Virginia Tech > Blacksburg, VA 24061-0106 > USA ========================================================================= Date: Mon, 24 Jan 2000 22:19:51 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "Bryan R. Deehring" Subject: Re: question MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII int* myintPtr = (int*) &MemoryPool[some_index]; myintPtr now points to 4-bytes in the char MemoryPool array. -----Original Message----- From: Jonathan Pryor [SMTP:jopryor@VT.EDU] Sent: Monday, January 24, 2000 9:51 PM To: CS2604@LISTSERV.VT.EDU Subject: Re: question This still leaves the question (which I'm guessing will be asked) of "how do we convert an array of bytes into an int"? Through the use of either * gratuitous (but necessary) casts * memcpy() Both of these are demonstrated in the sample below, in which: * an array of ``byte'' (unsigned chars) is allocated with enough storage to hold a ``long'' * a value is assigned to the long * The value of the long is copied into the array of ``byte''. Notice that ``reinterpret_cast'' (or a C-style cast) is needed to do this. * Instead of using the "cast to a pointer and dereference" trick, you can memcpy() the contents of the long over the byte array. * The byte array is interpreted as a long, and displayed to the screen. The value displayed is the same as the value displayed when the `long' was displayed. The sample code: #include // cout #include // hex #include // memset using namespace std; void print (void* pv, unsigned int n) {char* pach = reinterpret_cast(pv); for (int i = 0; i < n; i++, ++pach) cout << "\t" << i << ": " << *pach << " (" << hex << int(*pach) << ")" << endl; cout.unsetf(ios::hex);} int main () {typedef unsigned char byte; // stores enough memory to hold a ``long'' byte ab[sizeof(long)]; long l = 42; cout << "uninitialized array:" << endl; print (ab, sizeof(ab)); cout << "long value: " << l << endl;; *(reinterpret_cast(ab)) = l; cout << "array after copying an int into it:" << endl; print (ab, sizeof(ab)); memset (ab, 0, sizeof(ab)); cout << "cleared array:" << endl; print (ab, sizeof(ab)); memcpy (ab, &l, sizeof(ab)); cout << "array after using ``memcpy'' to initialize it:" << endl; print (ab, sizeof(ab)); cout << "printing out the array as an int: "; cout << *((long*)ab) << endl; return 0;} Moderately ugly? A little. However, I know of no other way than to use casts or memcpy() to "reinterpret" a byte array into the desired type--be it a long or some user defined type. A word of warning about the "Reading and Writing Complex Data" section in the "C++ Binary File I/O" section of the course web site: copying the contents of a structure directly into an output stream is moderately "evil" because the compiler typically inserts "space" between the data members in structures for alignment purposes--and the space may vary from between compiler versions and platforms. Therefore, printing out a structure tends to be compiler-specific. However, given that the sizes of the types also tend to vary between platforms, this may not matter. If portability of data files across platforms is a design goal, however, plain text tends to be the only safe encoding scheme. See "The Practice of Programming" by Brian W. Kernighan and Rob Pike, page 203 (section 8.5: Data Exchange). Hope all this is of some usefulness. Jonathan Pryor jonpryor@vt.edu > -----Original Message----- > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > Ben Keller > Sent: Monday, January 24, 2000 10:44 PM > To: CS2604@LISTSERV.VT.EDU > Subject: Re: question > > > Don't think of the array of char as an array of characters. Think of it > as an array of bytes, which it really is. So, a 32-bit int takes up > four bytes, which is four chars. So, an int always takes up the same > amount of space in the array. > > Brandon McKelvey wrote: > > > > I got a question... the spec says that we are to store the > integers in the > > list as a character. Can someone please explain to me how this > will work. > > A 32-bit it can be a variable amount of characters. So how > does this work? > > How many characters will the integer take up in the character array, > > moreover I guess you can just cast up and cast down and then it > will be a > > constant amount of space. Can someone please shed some light on this? > > > > Brandon > > -- > Ben Keller email: keller@cs.vt.edu > Computer Science Department phone: 1-540-231-9367 > Virginia Tech > Blacksburg, VA 24061-0106 > USA ========================================================================= Date: Mon, 24 Jan 2000 22:27:01 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jordan Chavez Subject: Re: casting question In-Reply-To: <388CEC85.9791F8F1@vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Like Dr. Keller said, think of memory block as an array of bytes. Since an integer takes up four bytes in memory, it looks like this: . . |------| |byte 3| offset x+3 |------| |byte 2| offset x+2 |------| |byte 1| offset x+1 |------| |byte 0| offset x |------| . . Cast the pointer to your memory block as an int* _before_ you index it, and then store the coordinate: ((int*)mem_ptr)[some_offset] = x_coordinate; This stores the integer coordinate in the memory block in little endian format like in the picture(least significant byte first). The same thing works with pointers, which are also 4 bytes, although you have to cast them as reference pointers: ((char**)mem_ptr)[some_offset] = next_node; You can of course use a plain old integer as your next/prev "pointer", treating it as an untyped index rather than as a typed pointer. This makes more sense to me because it's referencing an essentially untyped block of memory. Then again, you might feel that using a char* is more correct than using an integer. Compare dereferencing some field of the next node in the free block list with each approach: *(current_mem_block[NEXT_NODE_OFFSET]+some_other_offset) = blahblah // using char* mem_ptr[current_mem_block[NEXT_NODE_OFFSET]+some_other_offset] = blahblah // using int Both require two dereferences, so the only difference is with a pointer you store the system memory block address while with an integer you store the block's index into your simulated memory block. It's really a matter of personal preference. Jordan Chavez jchavez@vt.edu At 07:21 PM 1/24/00 -0500, you wrote: >For each block in the freelist block we are supposed to have two pointers. >Since everything is a char in the memory pool how are we supposed to convert >some of the chars in the char array into char pointers??? I've been testing >various methods of casting however I haven't had much success. I'm having the >same problem with ints. We are supposed to store ints into the char array. In >class today I believe that it was somewhat suggested that the chars in the >array be casted as ints. Well, I'm having the same problem with this. To be >honest I have never attempted to do such a thing before -ie, casting chars into >ints. This seems very strange to me. I find myself doing things which I >consider to be abnormal practice in this program. Can someone clear things up >for me? Thanks alot. > ========================================================================= Date: Mon, 24 Jan 2000 22:38:46 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jonathan Pryor Subject: Re: question In-Reply-To: <01BF66B9.23319C60.bdeehrin@vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Well, you should make sure that you're not exceeding the bounds of ``MemoryPool''... :-) Additionally, in order to assign to ``myintPtr'' you'd still need to dereference it, resulting in: int* myintPtr = (int*) &MemoryPool[some_index]; *myintPtr = 42; Which is analogous to: *((int*)&MemoryPool[some_index]) = 42; Which is basically another form of rewriting (after changing the types to be consistent with you): byte ab[sizeof(int)]; int l = 42; *(reinterpret_cast(ab)) = l; Which is what I had originally. Buried inside surrounding code, certainly, but it's effectively the same. So I'll stay by my comment: "I know of no other way than to use casts or memcpy() to "reinterpret" a byte array into the desired type." - Jon > -----Original Message----- > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > Bryan R. Deehring > Sent: Monday, January 24, 2000 10:20 PM > To: CS2604@LISTSERV.VT.EDU > Subject: Re: question > > > int* myintPtr = (int*) &MemoryPool[some_index]; > > myintPtr now points to 4-bytes in the char MemoryPool array. > ========================================================================= Date: Mon, 24 Jan 2000 22:56:23 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jordan Chavez Subject: Re: question In-Reply-To: <01BF66B9.23319C60.bdeehrin@vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii My angry retort follows Please don't be offended =) Whatever you do, do *NOT* use memcpy whenever you want to cast something! The overhead is like five times the actual work done: a CALL, three 32-bit PUSHes, a RET, plus the loop setup and the loop counter increment just to copy 4 bytes? int* ip = (int*)&memptr[index]; requires a two dereferences and a single MOV. Much more efficient. With regard to reinterpret_cast<>, if all it boils down to is a regular c-style cast with no side effects, then it seems a wordier, more annoying way to do a regular cast(I hate typing those angle brackets!). reinterpret_casta_char_ptr <--------FINGER-INEFFICIENT (int*)a_char_ptr <------ FINGER-EFFICIENT Seriously though, they both do the same thing, I think =) Jordan Chavez jchavez@vt.edu >From: Jonathan Pryor [SMTP:jopryor@VT.EDU] >Sent: Monday, January 24, 2000 9:51 PM >To: CS2604@LISTSERV.VT.EDU >Subject: Re: question > >This still leaves the question (which I'm guessing will be asked) of >"how do we convert an array of bytes into an int"? Through the use >of either > * gratuitous (but necessary) casts > * memcpy() > >Both of these are demonstrated in the sample below, in which: > * an array of ``byte'' (unsigned chars) is allocated with enough > storage to hold a ``long'' > > * a value is assigned to the long > > * The value of the long is copied into the array of ``byte''. > Notice that ``reinterpret_cast'' (or a C-style cast) is needed > to do this. > > * Instead of using the "cast to a pointer and dereference" trick, > you can memcpy() the contents of the long over the byte array. > > * The byte array is interpreted as a long, and displayed to the > screen. The value displayed is the same as the value displayed > when the `long' was displayed. > >The sample code: > > #include // cout > #include // hex > #include // memset > using namespace std; > > void print (void* pv, unsigned int n) > {char* pach = reinterpret_cast(pv); > for (int i = 0; i < n; i++, ++pach) > cout << "\t" << i << ": " << *pach << " (" << hex << int(*pach) > << ")" << endl; > cout.unsetf(ios::hex);} > > int main () > {typedef unsigned char byte; > // stores enough memory to hold a ``long'' > byte ab[sizeof(long)]; > long l = 42; > cout << "uninitialized array:" << endl; > print (ab, sizeof(ab)); > cout << "long value: " << l << endl;; > *(reinterpret_cast(ab)) = l; > cout << "array after copying an int into it:" << endl; > print (ab, sizeof(ab)); > memset (ab, 0, sizeof(ab)); > cout << "cleared array:" << endl; > print (ab, sizeof(ab)); > memcpy (ab, &l, sizeof(ab)); > cout << "array after using ``memcpy'' to initialize it:" << endl; > print (ab, sizeof(ab)); > cout << "printing out the array as an int: "; > cout << *((long*)ab) << endl; > return 0;} > >Moderately ugly? A little. However, I know of no other way than >to use casts or memcpy() to "reinterpret" a byte array into the >desired type--be it a long or some user defined type. > >A word of warning about the "Reading and Writing Complex Data" >section in the "C++ Binary File I/O" section of the course web >site: copying the contents of a structure directly into an output >stream is moderately "evil" because the compiler typically inserts >"space" between the data members in structures for alignment >purposes--and the space may vary from between compiler versions >and platforms. Therefore, printing out a structure tends to be >compiler-specific. However, given that the sizes of the types >also tend to vary between platforms, this may not matter. > >If portability of data files across platforms is a design goal, >however, plain text tends to be the only safe encoding scheme. >See "The Practice of Programming" by Brian W. Kernighan and >Rob Pike, page 203 (section 8.5: Data Exchange). > >Hope all this is of some usefulness. > > ========================================================================= Date: Mon, 24 Jan 2000 22:59:14 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jordan Chavez Subject: Re: question In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii I think his point was that regular casts are simpler to use. At 10:38 PM 1/24/00 -0500, you wrote: >Well, you should make sure that you're not exceeding the bounds of >``MemoryPool''... :-) > >Additionally, in order to assign to ``myintPtr'' you'd still need >to dereference it, resulting in: > > int* myintPtr = (int*) &MemoryPool[some_index]; > *myintPtr = 42; > >Which is analogous to: > > *((int*)&MemoryPool[some_index]) = 42; > >Which is basically another form of rewriting (after changing >the types to be consistent with you): > > byte ab[sizeof(int)]; > int l = 42; > *(reinterpret_cast(ab)) = l; > >Which is what I had originally. Buried inside surrounding code, >certainly, but it's effectively the same. > >So I'll stay by my comment: "I know of no other way than >to use casts or memcpy() to "reinterpret" a byte array into the >desired type." > > - Jon > >> -----Original Message----- >> From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of >> Bryan R. Deehring >> Sent: Monday, January 24, 2000 10:20 PM >> To: CS2604@LISTSERV.VT.EDU >> Subject: Re: question >> >> >> int* myintPtr = (int*) &MemoryPool[some_index]; >> >> myintPtr now points to 4-bytes in the char MemoryPool array. >> > > ========================================================================= Date: Mon, 24 Jan 2000 23:01:37 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Peter Huene Subject: Re: question In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Its ugly and completely impractical given other alternatives, but here's another way just for fun =): //Same way of doing it but with shift masks //Basically we're doing all the work ourselves array[index] = (char) ( someint & 0xFF); array[index + 1] = (char) ( (someint >> 8) & 0xFF); array[index + 2] = (char) ( (someint >> 16) & 0xFF); array[index + 3] = (char) ( (someint >> 24) & 0xFF); int someintback = int( array[index] | (array[index + 1] << 8) | (array[index + 2] << 16) | (array[index + 3] << 24) ); The AND with 0xFF is unnecessary since its being cast to char, but might help demonstrate to people what its actually doing, so I left it in there. A dereference of a casted pointer is probably easiest, but I think memcpy() has extra readability for people looking at your code. Regards, Peter Huene -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Jonathan Pryor Sent: Monday, January 24, 2000 10:39 PM To: CS2604@LISTSERV.VT.EDU Subject: Re: question Well, you should make sure that you're not exceeding the bounds of ``MemoryPool''... :-) Additionally, in order to assign to ``myintPtr'' you'd still need to dereference it, resulting in: int* myintPtr = (int*) &MemoryPool[some_index]; *myintPtr = 42; Which is analogous to: *((int*)&MemoryPool[some_index]) = 42; Which is basically another form of rewriting (after changing the types to be consistent with you): byte ab[sizeof(int)]; int l = 42; *(reinterpret_cast(ab)) = l; Which is what I had originally. Buried inside surrounding code, certainly, but it's effectively the same. So I'll stay by my comment: "I know of no other way than to use casts or memcpy() to "reinterpret" a byte array into the desired type." - Jon > -----Original Message----- > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > Bryan R. Deehring > Sent: Monday, January 24, 2000 10:20 PM > To: CS2604@LISTSERV.VT.EDU > Subject: Re: question > > > int* myintPtr = (int*) &MemoryPool[some_index]; > > myintPtr now points to 4-bytes in the char MemoryPool array. > ========================================================================= Date: Mon, 24 Jan 2000 23:03:07 -0800 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Todd Hayton Subject: linked list of free blocks MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Does the linked list of free memory blocks necessarily need to be implemented within the memory pool? Professor Roach seemed to suggest that an easier approach might be to simply create a linked list independent of the memory pool and keep track of the free memory blocks that way. todd ========================================================================= Date: Mon, 24 Jan 2000 23:30:56 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jonathan Pryor Subject: Re: question In-Reply-To: <3.0.6.32.20000124225623.008fb220@mail.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit I'm not offended. You're correct: the cast is more efficient. However, that doesn't prevent memcpy() from *working*, which was the intent of the original reply. Besides, casting can't solve everything (but memcpy() can't either, so...). As for which is better...I'm not sure. Careful reading of my posted will show that I used both forms at different places. :-) Personally, I'd probably use the C-style casting in "real" code, even if C++-style casts are generally better style. - Jon > -----Original Message----- > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > Jordan Chavez > Sent: Monday, January 24, 2000 10:56 PM > To: CS2604@LISTSERV.VT.EDU > Subject: Re: question > > > My angry retort follows > Please don't be offended =) > > > Whatever you do, do *NOT* use memcpy whenever you want to cast something! > > The overhead is like five times the actual work done: > a CALL, three 32-bit PUSHes, a RET, plus the loop setup and the loop > counter increment just to copy 4 bytes? > > int* ip = (int*)&memptr[index]; > requires a two dereferences and a single MOV. Much more efficient. > > With regard to reinterpret_cast<>, if all it boils down to is a regular > c-style cast > with no side effects, then it seems a wordier, more annoying way to do a > regular > cast(I hate typing those angle brackets!). > > reinterpret_casta_char_ptr <--------FINGER-INEFFICIENT > (int*)a_char_ptr <------ FINGER-EFFICIENT > > Seriously though, they both do the same thing, I think =) > > Jordan Chavez > jchavez@vt.edu > > > > > >From: Jonathan Pryor [SMTP:jopryor@VT.EDU] > >Sent: Monday, January 24, 2000 9:51 PM > >To: CS2604@LISTSERV.VT.EDU > >Subject: Re: question > > > >This still leaves the question (which I'm guessing will be asked) of > >"how do we convert an array of bytes into an int"? Through the use > >of either > > * gratuitous (but necessary) casts > > * memcpy() > > > >Both of these are demonstrated in the sample below, in which: > > * an array of ``byte'' (unsigned chars) is allocated with enough > > storage to hold a ``long'' > > > > * a value is assigned to the long > > > > * The value of the long is copied into the array of ``byte''. > > Notice that ``reinterpret_cast'' (or a C-style cast) is needed > > to do this. > > > > * Instead of using the "cast to a pointer and dereference" trick, > > you can memcpy() the contents of the long over the byte array. > > > > * The byte array is interpreted as a long, and displayed to the > > screen. The value displayed is the same as the value displayed > > when the `long' was displayed. > > > >The sample code: > > > > #include // cout > > #include // hex > > #include // memset > > using namespace std; > > > > void print (void* pv, unsigned int n) > > {char* pach = reinterpret_cast(pv); > > for (int i = 0; i < n; i++, ++pach) > > cout << "\t" << i << ": " << *pach << " (" << hex << > int(*pach) > > << ")" << endl; > > cout.unsetf(ios::hex);} > > > > int main () > > {typedef unsigned char byte; > > // stores enough memory to hold a ``long'' > > byte ab[sizeof(long)]; > > long l = 42; > > cout << "uninitialized array:" << endl; > > print (ab, sizeof(ab)); > > cout << "long value: " << l << endl;; > > *(reinterpret_cast(ab)) = l; > > cout << "array after copying an int into it:" << endl; > > print (ab, sizeof(ab)); > > memset (ab, 0, sizeof(ab)); > > cout << "cleared array:" << endl; > > print (ab, sizeof(ab)); > > memcpy (ab, &l, sizeof(ab)); > > cout << "array after using ``memcpy'' to initialize > it:" << endl; > > print (ab, sizeof(ab)); > > cout << "printing out the array as an int: "; > > cout << *((long*)ab) << endl; > > return 0;} > > > >Moderately ugly? A little. However, I know of no other way than > >to use casts or memcpy() to "reinterpret" a byte array into the > >desired type--be it a long or some user defined type. > > > >A word of warning about the "Reading and Writing Complex Data" > >section in the "C++ Binary File I/O" section of the course web > >site: copying the contents of a structure directly into an output > >stream is moderately "evil" because the compiler typically inserts > >"space" between the data members in structures for alignment > >purposes--and the space may vary from between compiler versions > >and platforms. Therefore, printing out a structure tends to be > >compiler-specific. However, given that the sizes of the types > >also tend to vary between platforms, this may not matter. > > > >If portability of data files across platforms is a design goal, > >however, plain text tends to be the only safe encoding scheme. > >See "The Practice of Programming" by Brian W. Kernighan and > >Rob Pike, page 203 (section 8.5: Data Exchange). > > > >Hope all this is of some usefulness. > > > > ========================================================================= Date: Mon, 24 Jan 2000 23:31:19 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Peter Huene Subject: Re: question In-Reply-To: <3.0.6.32.20000124225623.008fb220@mail.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Granted memcpy() does have a lot more overhead compared to a simple cast-deref-assignment, and I certainly wouldn't recommend using it in an algorithm or an area of code that stresses the amount of ops performed, but one could argue that memcpy() is intrinsically easier to understand what's going on if one didn't know how to copy bytes around. I basically gave it as an example that you could copy an int into an array of bytes so anyone who didn't know how could get the point. Anyway, your point is completely valid. Just want to point out for anyone reading my shift mask email, I don't on purpose write code that's inefficient, I just like to find different solutions =). Regards, Peter Huene -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Jordan Chavez Sent: Monday, January 24, 2000 10:56 PM To: CS2604@LISTSERV.VT.EDU Subject: Re: question My angry retort follows Please don't be offended =) Whatever you do, do *NOT* use memcpy whenever you want to cast something! The overhead is like five times the actual work done: a CALL, three 32-bit PUSHes, a RET, plus the loop setup and the loop counter increment just to copy 4 bytes? int* ip = (int*)&memptr[index]; requires a two dereferences and a single MOV. Much more efficient. With regard to reinterpret_cast<>, if all it boils down to is a regular c-style cast with no side effects, then it seems a wordier, more annoying way to do a regular cast(I hate typing those angle brackets!). reinterpret_casta_char_ptr <--------FINGER-INEFFICIENT (int*)a_char_ptr <------ FINGER-EFFICIENT Seriously though, they both do the same thing, I think =) Jordan Chavez jchavez@vt.edu >From: Jonathan Pryor [SMTP:jopryor@VT.EDU] >Sent: Monday, January 24, 2000 9:51 PM >To: CS2604@LISTSERV.VT.EDU >Subject: Re: question > >This still leaves the question (which I'm guessing will be asked) of >"how do we convert an array of bytes into an int"? Through the use >of either > * gratuitous (but necessary) casts > * memcpy() > >Both of these are demonstrated in the sample below, in which: > * an array of ``byte'' (unsigned chars) is allocated with enough > storage to hold a ``long'' > > * a value is assigned to the long > > * The value of the long is copied into the array of ``byte''. > Notice that ``reinterpret_cast'' (or a C-style cast) is needed > to do this. > > * Instead of using the "cast to a pointer and dereference" trick, > you can memcpy() the contents of the long over the byte array. > > * The byte array is interpreted as a long, and displayed to the > screen. The value displayed is the same as the value displayed > when the `long' was displayed. > >The sample code: > > #include // cout > #include // hex > #include // memset > using namespace std; > > void print (void* pv, unsigned int n) > {char* pach = reinterpret_cast(pv); > for (int i = 0; i < n; i++, ++pach) > cout << "\t" << i << ": " << *pach << " (" << hex << int(*pach) > << ")" << endl; > cout.unsetf(ios::hex);} > > int main () > {typedef unsigned char byte; > // stores enough memory to hold a ``long'' > byte ab[sizeof(long)]; > long l = 42; > cout << "uninitialized array:" << endl; > print (ab, sizeof(ab)); > cout << "long value: " << l << endl;; > *(reinterpret_cast(ab)) = l; > cout << "array after copying an int into it:" << endl; > print (ab, sizeof(ab)); > memset (ab, 0, sizeof(ab)); > cout << "cleared array:" << endl; > print (ab, sizeof(ab)); > memcpy (ab, &l, sizeof(ab)); > cout << "array after using ``memcpy'' to initialize it:" << endl; > print (ab, sizeof(ab)); > cout << "printing out the array as an int: "; > cout << *((long*)ab) << endl; > return 0;} > >Moderately ugly? A little. However, I know of no other way than >to use casts or memcpy() to "reinterpret" a byte array into the >desired type--be it a long or some user defined type. > >A word of warning about the "Reading and Writing Complex Data" >section in the "C++ Binary File I/O" section of the course web >site: copying the contents of a structure directly into an output >stream is moderately "evil" because the compiler typically inserts >"space" between the data members in structures for alignment >purposes--and the space may vary from between compiler versions >and platforms. Therefore, printing out a structure tends to be >compiler-specific. However, given that the sizes of the types >also tend to vary between platforms, this may not matter. > >If portability of data files across platforms is a design goal, >however, plain text tends to be the only safe encoding scheme. >See "The Practice of Programming" by Brian W. Kernighan and >Rob Pike, page 203 (section 8.5: Data Exchange). > >Hope all this is of some usefulness. > > ========================================================================= Date: Mon, 24 Jan 2000 23:33:25 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jonathan Pryor Subject: Re: question In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Actually, your approach has one advantage that the other approaches don't: it'll work the same way regardless of the platform you're on (big-endian or little-endian), and thus would be suitable for transport over a network. None of the other approaches would be suitable unless platforms sharing the same "endian-ness" were used. Similar code comes in handy converting Unicode to UTF-8. I don't think it's as efficient as the cast, though. BTW, code similar to yours can be found in "The Practice of Programming". - Jon > -----Original Message----- > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > Peter Huene > Sent: Monday, January 24, 2000 11:02 PM > To: CS2604@LISTSERV.VT.EDU > Subject: Re: question > > > Its ugly and completely impractical given other alternatives, but here's > another way just for fun =): > > //Same way of doing it but with shift masks > //Basically we're doing all the work ourselves > array[index] = (char) ( someint & 0xFF); > array[index + 1] = (char) ( (someint >> 8) & 0xFF); > array[index + 2] = (char) ( (someint >> 16) & 0xFF); > array[index + 3] = (char) ( (someint >> 24) & 0xFF); > > int someintback = int( array[index] | (array[index + 1] << 8) | > (array[index > + 2] << 16) | (array[index + 3] << 24) ); > > The AND with 0xFF is unnecessary since its being cast to char, but might > help demonstrate to people what its actually doing, so I left it in there. > A dereference of a casted pointer is probably easiest, but I > think memcpy() > has extra readability for people looking at your code. Regards, > > Peter Huene > > -----Original Message----- > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > Jonathan Pryor > Sent: Monday, January 24, 2000 10:39 PM > To: CS2604@LISTSERV.VT.EDU > Subject: Re: question > > > Well, you should make sure that you're not exceeding the bounds of > ``MemoryPool''... :-) > > Additionally, in order to assign to ``myintPtr'' you'd still need > to dereference it, resulting in: > > int* myintPtr = (int*) &MemoryPool[some_index]; > *myintPtr = 42; > > Which is analogous to: > > *((int*)&MemoryPool[some_index]) = 42; > > Which is basically another form of rewriting (after changing > the types to be consistent with you): > > byte ab[sizeof(int)]; > int l = 42; > *(reinterpret_cast(ab)) = l; > > Which is what I had originally. Buried inside surrounding code, > certainly, but it's effectively the same. > > So I'll stay by my comment: "I know of no other way than > to use casts or memcpy() to "reinterpret" a byte array into the > desired type." > > - Jon > > > -----Original Message----- > > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > > Bryan R. Deehring > > Sent: Monday, January 24, 2000 10:20 PM > > To: CS2604@LISTSERV.VT.EDU > > Subject: Re: question > > > > > > int* myintPtr = (int*) &MemoryPool[some_index]; > > > > myintPtr now points to 4-bytes in the char MemoryPool array. > > > ========================================================================= Date: Mon, 24 Jan 2000 23:49:49 -0800 Reply-To: tannerb@vt.edu Sender: CS2604 discussion list From: Tanner Bonig Subject: Re: linked list of free blocks In-Reply-To: <0FOV00ELJHZLWM@gkar.cc.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Prof Shaffer said not to.. Tanner -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Todd Hayton Sent: Monday, January 24, 2000 11:03 PM To: CS2604@LISTSERV.VT.EDU Subject: linked list of free blocks Does the linked list of free memory blocks necessarily need to be implemented within the memory pool? Professor Roach seemed to suggest that an easier approach might be to simply create a linked list independent of the memory pool and keep track of the free memory blocks that way. todd ========================================================================= Date: Mon, 24 Jan 2000 23:46:31 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Stephen Hoskins Subject: Re: linked list of free blocks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit if we implemented it that way then the varying size in the blocks wouldn't be an issue Todd Hayton wrote: > Does the linked list of free memory blocks necessarily need to be > implemented within the memory pool? Professor Roach seemed to > suggest that an easier approach might be to simply create a linked > list independent of the memory pool and keep track of the free > memory blocks that way. > > todd ========================================================================= Date: Tue, 25 Jan 2000 01:58:38 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: IMPORTANT: Spec clarifications MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Below are some clarifications to the spec. If this appears to you to contradict the spec, then the statements below take priority. See especially (3) which contains the statement that I promised to my class regarding tightening the specs on record structure design. 1) The X and Y coordinates for the record MUST be stored in the memory pool as 32-bit ints, NOT as the original ASCII characters. See (3) below. 2) You MUST use a linked list whose nodes are separate from the memory pool to store the list of free blocks. You may NOT integrate the linked list nodes into the space of the memory pool itself in any way. 3) The spec contains a discussion on design choices related to how the record gets stored in the memory manager's memory. Disregard that discussion. You are REQUIRED to store records as follows: a) Each record, as passed to the memory manager class, will first contain a 4 byte field for the X coord, followed by a 4 byte field for the Y coord, followed by the name, with NO terminating null character. b) The memory manager will prepend a 4 byte value containing the length of the record being stored. If the record is length N, then the value stored will be N and the total length of memory required is N+4 (to store the length field for the record). So, if the memory request is 50 bytes, 54 byte are actually required and stored. c) Note that some of the alternatives suggested in the spec would not have worked, since the memory manager would not have known the length of a block being freed. The method described here solves that problem as well. d) You must NOT store the length of the record in the client's record array. The memory manager now has all of the information necessary to get the length of the record without being told by the client. e) If you like, feel free to implement a convenience function that returns the length of the record associated with a handle. I doubt you will need it, though. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science FAX: (540) 231-6075 Virginia Tech, Blacksburg, VA 24061-0106 Email: shaffer@cs.vt.edu ----------------------------------------------------------------------- ========================================================================= Date: Tue, 25 Jan 2000 02:21:31 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brian Subject: Re: IMPORTANT: Spec clarifications In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >Below are some clarifications to the spec. If this appears to you to >contradict the spec, then the statements below take priority. See >especially (3) which contains the statement that I promised to my class >regarding tightening the specs on record structure design. I know this probably doesn't matter, but what about those of us who have already coded this part of the program? Will the spec magically change again? Should we stop coding all together untill all the problems have been worked out? Alright, enough venting anger, sorry about that. :-) Since it apears my implementation is no longer allowed, I find no honor reasons not to discuss it, so here is my question: I was storing my record as 2 4byte ints and then a variable length name WITH a terminating NULL. If we store the record this way, wouldn't that take less memory space than storing a third 4byte int with the length of the record? A NULL is only one byte, whereas an int is 4. The length of the record can be stored in the linked list of memory blocks. Using this scheme, it takes less instructions also, since we don't need to do an extra read to determine how long the memory block is. It also simplifies the process of re-joining blocks after records are deleted. I agree that 3 bytes of saved space is totally insugnifigant, but consider this also: Leaving the terminating NULL is a better abstraction. This way the main program can simply ask the memory manager for a certain amount of memory, and then not have to deal with the memory manager any further untill the main program is ready to return the memory to free space. If we leave the length as the first int in the record, then the main program would (probably) have to ask the memory manager to retrieve the record! (as in the spec with the function void get()). Why should the memory manager know what type of record it is storing? My personal vote would be store the 2ints (fixed length) and then the city name with a terminating NULL. IT's less overhead, and the main program can access it directly without having to ask the memory manager about a record it shouldn't understand. Thanks for the consideration, -brian- PS: any word on the questions in my previous e-mail? Specifically, what if we try to copy over another record, but we don't have room for the insert? ========================================================================= Date: Tue, 25 Jan 2000 09:25:57 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "Michael S. Moulton" Subject: Re: IMPORTANT: Spec clarifications In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii At 01:58 AM 1/25/00 -0500, you wrote: >2) You MUST use a linked list whose nodes are separate from the memory >pool to store the list of free blocks. You may NOT integrate the linked >list nodes into the space of the memory pool itself in any way. Dr. Roach discussed the possibility of using something similar to figure 12.14 in the textbook-- storing the linked list pointers in free space with tags at the beginning and end of each block designating whether they are free blocks or in use blocks. Am I misinterpreting this spec clarification, or are we truly not allowed to use that implementation? --Mike --- Michael S. Moulton UZ 541+UUD Lord Bodak msmoulton@iname.com VT Class of 2001 http://www.ee.vt.edu/~mmoulton/ ========================================================================= Date: Tue, 25 Jan 2000 09:29:38 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jordan Chavez Subject: Re: IMPORTANT: Spec clarifications In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii I had the project 70% done using a list integrated into the memory block. Crap! At 01:58 AM 1/25/00 -0500, you wrote: >Below are some clarifications to the spec. If this appears to you to >contradict the spec, then the statements below take priority. See >especially (3) which contains the statement that I promised to my class >regarding tightening the specs on record structure design. > >1) The X and Y coordinates for the record MUST be stored in the memory >pool as 32-bit ints, NOT as the original ASCII characters. See (3) below. > >2) You MUST use a linked list whose nodes are separate from the memory >pool to store the list of free blocks. You may NOT integrate the linked >list nodes into the space of the memory pool itself in any way. > >3) The spec contains a discussion on design choices related to how the >record gets stored in the memory manager's memory. Disregard that >discussion. You are REQUIRED to store records as follows: > >a) Each record, as passed to the memory manager class, will first contain >a 4 byte field for the X coord, followed by a 4 byte field for the Y >coord, followed by the name, with NO terminating null character. > >b) The memory manager will prepend a 4 byte value containing the length of >the record being stored. If the record is length N, then the value stored >will be N and the total length of memory required is N+4 (to store the >length field for the record). So, if the memory request is 50 bytes, 54 >byte are actually required and stored. > >c) Note that some of the alternatives suggested in the spec would not have >worked, since the memory manager would not have known the length of a >block being freed. The method described here solves that problem as well. > >d) You must NOT store the length of the record in the client's record >array. The memory manager now has all of the information necessary to get >the length of the record without being told by the client. > >e) If you like, feel free to implement a convenience function that returns >the length of the record associated with a handle. I doubt you will need >it, though. > >-- >Cliff Shaffer, Associate Professor Phone: (540) 231-4354 >Department of Computer Science FAX: (540) 231-6075 >Virginia Tech, Blacksburg, VA 24061-0106 Email: shaffer@cs.vt.edu >----------------------------------------------------------------------- > ========================================================================= Date: Tue, 25 Jan 2000 11:00:06 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: IMPORTANT: Spec clarifications In-Reply-To: <3.0.5.32.20000125092557.0097f100@mail.vt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII You are truely not allowed to use that implementation. You will get your chance in Project 4. :-) -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science FAX: (540) 231-6075 Virginia Tech, Blacksburg, VA 24061-0106 Email: shaffer@cs.vt.edu ----------------------------------------------------------------------- On Tue, 25 Jan 2000, Michael S. Moulton wrote: > At 01:58 AM 1/25/00 -0500, you wrote: > >2) You MUST use a linked list whose nodes are separate from the memory > >pool to store the list of free blocks. You may NOT integrate the linked > >list nodes into the space of the memory pool itself in any way. > > Dr. Roach discussed the possibility of using something similar to figure > 12.14 in the textbook-- storing the linked list pointers in free space with > tags at the beginning and end of each block designating whether they are > free blocks or in use blocks. Am I misinterpreting this spec > clarification, or are we truly not allowed to use that implementation? > > --Mike > > --- > Michael S. Moulton UZ 541+UUD Lord Bodak > msmoulton@iname.com VT Class of 2001 > http://www.ee.vt.edu/~mmoulton/ > ========================================================================= Date: Tue, 25 Jan 2000 11:06:30 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: IMPORTANT: Spec clarifications In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 25 Jan 2000, Brian wrote: > I was storing my record as 2 4byte ints and then a variable length name > WITH a terminating NULL. If we store the record this way, wouldn't that > take less memory space than storing a third 4byte int with the length of > the record? A NULL is only one byte, whereas an int is 4. The length of the > record can be stored in the linked list of memory blocks. Using this > scheme, it takes less instructions also, since we don't need to do an extra > read to determine how long the memory block is. It also simplifies the > process of re-joining blocks after records are deleted. Actually, your question is not as interesting as it might be, since you propose to in fact save the length, just somewhere else. So you don't save any space (or time since you read it anyway). To make it interesting, consider the tradeoff of not storing the length, and recognizing the end of the string by its null terminator. Here, with some cost in time, you could deduce the length of the record. But, here is the important issue: The only reason you can do that is because you are requiring the memory manager to make an assumption about the semantics of the record being stored. There is no reason at all why the record need be storing a string, and the memory manager can't and shouldn't know that there is anything special about the bytes it received from the client. Note also that I was being somewhat arbitrary when I specified the length field to be 4 bytes. In fact, 1 is probably enough, given the input restrictions, though 2 would be more general-purpose. I made it 4 to simplify things for those people having trouble with casting/copying. This way all of the values are the same length. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science FAX: (540) 231-6075 Virginia Tech, Blacksburg, VA 24061-0106 Email: shaffer@cs.vt.edu ----------------------------------------------------------------------- ========================================================================= Date: Tue, 25 Jan 2000 09:55:26 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jordan Chavez Subject: Re: IMPORTANT: Spec clarifications In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii A few questions... >3) The spec contains a discussion on design choices related to how the >record gets stored in the memory manager's memory. Disregard that >discussion. You are REQUIRED to store records as follows: I'm assuming we can store a free block however we want..??? > >a) Each record, as passed to the memory manager class, will first contain >a 4 byte field for the X coord, followed by a 4 byte field for the Y >coord, followed by the name, with NO terminating null character. > >b) The memory manager will prepend a 4 byte value containing the length of >the record being stored. If the record is length N, then the value stored >will be N and the total length of memory required is N+4 (to store the >length field for the record). So, if the memory request is 50 bytes, 54 >byte are actually required and stored. If all that's stored is the size then how are we to distinguish free blocks from reserved blocks for purposes of deallocation? i.e. there is no tag field in a reserved memory block, so when we free up a block, how can we tell whether or not to merge adjacent free blocks? Clarifications are greatly appreciated. Thanks, Jordan Chavez jchavez@vt.edu ========================================================================= Date: Tue, 25 Jan 2000 11:11:03 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: IMPORTANT: 2nd Clarification to the Spec MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The question has been asked about what to do on an insert that a) is to the same position in the record array as an existing record, and b) is too big to fit into the memory pool. You should treat an insert to a position in the record array that already contains an existing record as IDENTICAL to i) deleting the original record, followed by ii) inserting the new record. Thus, if I had a record at position 5, and I insert a new record to position 5, the following would result: i) Delete the record whose handle is already stored at position 5. This deletion puts the memory pool into a certain state. ii) Attempt to insert the new record. If that attempt fails (due to lack of memory), then the state of memory pool should be identical to what it was at the END of step (i). -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science FAX: (540) 231-6075 Virginia Tech, Blacksburg, VA 24061-0106 Email: shaffer@cs.vt.edu ----------------------------------------------------------------------- ========================================================================= Date: Tue, 25 Jan 2000 11:15:07 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: IMPORTANT: Spec clarifications In-Reply-To: <3.0.6.32.20000125095526.008fe180@mail.vt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 25 Jan 2000, Jordan Chavez wrote: > A few questions... > > >3) The spec contains a discussion on design choices related to how the > >record gets stored in the memory manager's memory. Disregard that > >discussion. You are REQUIRED to store records as follows: > > I'm assuming we can store a free block however we want..??? Free blocks don't actually contain any information. The linked list tells you where the freeblocks are, and how long they are. > >a) Each record, as passed to the memory manager class, will first contain > >a 4 byte field for the X coord, followed by a 4 byte field for the Y > >coord, followed by the name, with NO terminating null character. > > > >b) The memory manager will prepend a 4 byte value containing the length of > >the record being stored. If the record is length N, then the value stored > >will be N and the total length of memory required is N+4 (to store the > >length field for the record). So, if the memory request is 50 bytes, 54 > >byte are actually required and stored. > > If all that's stored is the size then how are we to distinguish free blocks > from > reserved blocks for purposes of deallocation? i.e. there is no tag field > in a > reserved memory block, so when we free up a block, how can we tell whether > or not > to merge adjacent free blocks? Recall that the linked list stores the free blocks in sequential order as they appear in the memory pool. When you are freeing a block, work your way down the linked list until you find the ones immediately preceding and following the block you are freeing. Merge adjacent blocks as appropriate. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science FAX: (540) 231-6075 Virginia Tech, Blacksburg, VA 24061-0106 Email: shaffer@cs.vt.edu ----------------------------------------------------------------------- ========================================================================= Date: Tue, 25 Jan 2000 11:20:07 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: many questions In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 24 Jan 2000, Brian wrote: > 1) There is no input file given on the command line, rather input is to be > read from standard input. Therefore, should we code an 'exit' command, or > can we assume you will be piping in a file and look for an EOF on STDIN (or > both?)? Commands come from stdin, and you write your output to stdout. There is no "exit" command -- you must recognize EOF. > 2) The spec does NOT require us to make the x and y coords a constant > length. (it says one 'option' would be to make them fixed length, but > doesn't specifically require it) Prof. Roach told us in class today that we > had our choice as to whether to cast or to leave them as chars. I just > wanted to check this with everyone so I won't get points taken off for > leaving my x&y coords as variable length chars in the memory pool. This has been superceded by the first clarification, sent shortly after your email message. > 3) The spec also doesn't specify what type of linked list we should > implement. Are you expecting some specific type of linked list format, or > are we allowed to design our own? You may design your own. Personally, I'll choose a doubly-linked list every time. :-) > 4) If we insert a new record over top of an old record, the spec says to > remove the old one first. What if, after removing the old record, there is > not enough space for the new record anywhere in the pool? Should we somehow > un-remove the old record, or leave that record space as removed (since the > old record is gone, but the insert failed)? This was answered by the second clarification, that I just sent. > Here are some questions that we answered in class today, just thought I > throw them out to make sure I didn't hear something correctly: > > 1) We can assume the commands will not contain syntax errors. (Like a > letter for a coordinate) Yes. You may assume that the commands have no SYNTAX errors. You MUST test for semantic errors. An example of a semantic error (which might appear in the test case) is an illegal position in the record array. Note that integers too big/small to fit in an int variable is considered a syntax error, so will not occur. A test data file will go up this week. > 2) There will be NO spaces or blanks (whitespace) of anykind in the city name. Correct. Underscores, etc., are valid, however. > 3) The pool size and the number of records (the record array size) will not > be larger than a 'long'. Correct. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science FAX: (540) 231-6075 Virginia Tech, Blacksburg, VA 24061-0106 Email: shaffer@cs.vt.edu ----------------------------------------------------------------------- ========================================================================= Date: Tue, 25 Jan 2000 11:29:09 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Reading the PDF file MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Be sure that you have Acroread 4.0 to be able to read the PDF files that I post. I hear some people with 3.x have trouble. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science FAX: (540) 231-6075 Virginia Tech, Blacksburg, VA 24061-0106 Email: shaffer@cs.vt.edu ----------------------------------------------------------------------- ========================================================================= Date: Tue, 25 Jan 2000 10:27:01 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "Michael S. Moulton" Subject: Re: IMPORTANT: Spec clarifications In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Not to be rude, but is this going to happen all semester long? One professor telling us we can do it one way and another telling us we can't? I'm certain that _many_ students started their designs last night (and some probably got a lot done)-- and now they have to go back and start over? --Mike At 11:00 AM 1/25/00 -0500, you wrote: >You are truely not allowed to use that implementation. You will get your >chance in Project 4. :-) > > >On Tue, 25 Jan 2000, Michael S. Moulton wrote: > >> At 01:58 AM 1/25/00 -0500, you wrote: >> >2) You MUST use a linked list whose nodes are separate from the memory >> >pool to store the list of free blocks. You may NOT integrate the linked >> >list nodes into the space of the memory pool itself in any way. >> >> Dr. Roach discussed the possibility of using something similar to figure >> 12.14 in the textbook-- storing the linked list pointers in free space with >> tags at the beginning and end of each block designating whether they are >> free blocks or in use blocks. Am I misinterpreting this spec >> clarification, or are we truly not allowed to use that implementation? --- Michael S. Moulton UZ 541+UUD Lord Bodak msmoulton@iname.com VT Class of 2001 http://www.ee.vt.edu/~mmoulton/ ========================================================================= Date: Tue, 25 Jan 2000 11:48:44 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: IMPORTANT: Spec clarifications In-Reply-To: <3.0.5.32.20000125102701.007a6100@mail.vt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 25 Jan 2000, Michael S. Moulton wrote: > Not to be rude, but is this going to happen all semester long? Yes. Get used to it. You should expect that, during the first week after the spec is posted, there will be some clarification or modification. After that, it is highly unlikely that an actual change will be made. Note that spec changes or clarifications will be clearly labeled as such, and are binding on students in all sections. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science FAX: (540) 231-6075 Virginia Tech, Blacksburg, VA 24061-0106 Email: shaffer@cs.vt.edu ----------------------------------------------------------------------- ========================================================================= Date: Tue, 25 Jan 2000 10:56:26 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jonathan Pryor Subject: Re: IMPORTANT: Spec clarifications In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Depending on the design tradeoffs involved, the use of a terminating null on the string requires nothing from the memory manager. For example, with most C/C++ memory managers I've seen, the memory manager has "private" memory, but when a request for memory comes in (from malloc() or operator new()), the memory manager returns a pointer pointing *inside* the internal memory pool. For an example, see "The C++ Programming Language, Third Edition" by Bjarne Stroustrup on page 571 (for a discussion on adapting an existing memory pool for use as an "allocator"), and "Effective C++, Second Edition" by Scott Meyers, pages 39-49 (for overloading ``operator new'' and ``operator delete''). If using this scheme, the memory manager needs to know how long each memory block is (so that it can correctly free the memory); however, it doesn't need to know anything about the data stored in the memory block. The "client" just requests memory and throws two ints and a null-terminated string into the recently allocated memory; to get the string back, it just looks for the terminating null. Simple and straightforward. However, there are a few problems with this approach. As anyone who has programmed in C and C++ can tell you, it's easy to write past array boundaries. Returning a pointer to internal data offers no protection against this kind of memory violation, and could possibly go unnoticed. Additionally, it requires that what the client knows about always be "in memory"; there's no way for the memory manager to know if the client has written to memory unless the client tells it (fat chance), so the memory manager can't swap out the memory (unless it's the OS, which can set memory read-only, and do copy-on-write when a program attempts to write to read-protected memory; however, we're not the OS, so this isn't an option). There's one final problem with this approach: when I spoke with Shaffer about using this approach, I was effectively told that we're not supposed to do this. Keeping in mind that what we learn now is supposed to be applicable for later projects, and for Project 4 we'll be doing (close to) everything on disk, and the disk isn't "in memory" (unless you use mmap() or something), this approach can't be used. This is why the project spec suggests the interface it does, with read() and write(). Effectively, the memory that the memory manager is wholly separate from the client--the client shouldn't refer to memory inside of it, *ever*. Since the client can't refer to memory in the memory manager now, the entire approach of using a null-terminated string effectively falls apart. As the client, you have to request ``n'' bytes of memory from the manager (which gets copied into a local buffer), but you don't know how much to ask for. You could always grab more then necessary, and scan the memory for the terminating null, but there's a chance that you'll request memory that goes into a neighboring block. If a decent memory manager is in use, it will give an error condition, as you (as a client) aren't supposed to be accessing memory you never requested in the first place. This is why there's all this talk about either having the length of the string available before the string, or making the length of the buffer available to the client (and several other approaches). Choices, choices...though it was made for us in the spec clarifications: the memory manager needs to prefix the size of the memory block, and the client will need to ask the memory manager for the size of the block... Hope this clarifies some things... - Jon > -----Original Message----- > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > Cliff Shaffer > Sent: Tuesday, January 25, 2000 11:07 AM > To: CS2604@LISTSERV.VT.EDU > Subject: Re: IMPORTANT: Spec clarifications > > > On Tue, 25 Jan 2000, Brian wrote: > > > I was storing my record as 2 4byte ints and then a variable length name > > WITH a terminating NULL. If we store the record this way, wouldn't that > > take less memory space than storing a third 4byte int with the length of > > the record? A NULL is only one byte, whereas an int is 4. The > length of the > > record can be stored in the linked list of memory blocks. Using this > > scheme, it takes less instructions also, since we don't need to > do an extra > > read to determine how long the memory block is. It also simplifies the > > process of re-joining blocks after records are deleted. > > Actually, your question is not as interesting as it might be, since you > propose to in fact save the length, just somewhere else. So you don't > save any space (or time since you read it anyway). > > To make it interesting, consider the tradeoff of not storing the > length, and recognizing the end of the string by its null terminator. > Here, with some cost in time, you could deduce the length of the record. > But, here is the important issue: The only reason you can do that is > because you are requiring the memory manager to make an assumption about > the semantics of the record being stored. There is no reason at all why > the record need be storing a string, and the memory manager can't and > shouldn't know that there is anything special about the bytes it received > from the client. > > Note also that I was being somewhat arbitrary when I specified the length > field to be 4 bytes. In fact, 1 is probably enough, given the input > restrictions, though 2 would be more general-purpose. I made it 4 to > simplify things for those people having trouble with casting/copying. > This way all of the values are the same length. > > > -- > Cliff Shaffer, Associate Professor Phone: (540) 231-4354 > Department of Computer Science FAX: (540) 231-6075 > Virginia Tech, Blacksburg, VA 24061-0106 Email: shaffer@cs.vt.edu > ----------------------------------------------------------------------- ========================================================================= Date: Tue, 25 Jan 2000 21:14:50 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: David Cook Subject: Commenting macro MIME-version: 1.0 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_UHdzpX8WRKQeQ309bGUmJg)" This is a multi-part message in MIME format. --Boundary_(ID_UHdzpX8WRKQeQ309bGUmJg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Last semester in OOP someone posted a macro for MS VC 5/6 to the = listserv which "comments" a function call for you, I have since = formatted my HD and lost it but I had become quite fond of this macro so = if anyone has it could they send it to me personally, not the listserv = (We have to much mail already!!) Thanks -Dave C --Boundary_(ID_UHdzpX8WRKQeQ309bGUmJg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Last semester in OOP someone posted a = macro for MS=20 VC 5/6 to the listserv which "comments" a function call for you, I have = since=20 formatted my HD and lost it but I had become quite fond of this macro so = if=20 anyone has it could they send it to me personally, not the listserv (We = have to=20 much mail already!!)
 
Thanks
-Dave C
--Boundary_(ID_UHdzpX8WRKQeQ309bGUmJg)-- ========================================================================= Date: Tue, 25 Jan 2000 22:02:10 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Chuck Holbrook Subject: Re: Commenting Macro MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Heres the commenting Macro again. I changed a few things to it, so it might be slightly different. === BEGIN MACRO HERE ==== '--------------------------------------------------------------------------- --- 'FILE DESCRIPTION:Documentation Macro '--------------------------------------------------------------------------- --- Dim CustParamArr () ' Dynamic array to store function arguments. 'Strips the leading tab spaces. Function StripTabs (ByVal MyStr) Do While InStr(MyStr, vbTab) <> 0 MyStr = Right(MyStr, Len(MyStr) - InStr(MyStr, vbTab)) Loop StripTabs = Trim(MyStr) End Function Sub AddFunctionDescriptionCustom() 'DESCRIPTION: Creates a comment block for the currently selected C/C++ function prototype 'Throughout this file, ActiveDocument.Selection is used in place 'of ActiveDocument.Selection.Text. The two are equivalent, and can 'be used interchangeably. The reason for the equivalence is that 'Text is regarded as the default property to use. All uses of 'ActiveDocument.Selection without any other property default to the Text 'property. if ActiveDocument.Language = dsCPP Then Header = StripTabs(Trim(ActiveDocument.Selection)) 'Get the function return type. if Header <> "" then Reti = InStr(Header, " ") Loc = InStr(Header, "(") if Reti < Loc Then RetTp = Left(Header, Reti) Header = Right(Header, Len(Header) - Reti) End If 'Get the function name. Loc = InStr(Header, "(") - 1 Loc2 = InStr(Header, ")") if Loc > 0 And Loc2 > 0 then 'make sure there is a '(' and a ')' fcName = Left(Header, Loc) Header = Right(Header, Len(Header) - Len(fcName)) 'Do we have storage type on the return type? Trim (fcName) If InStr(fcName," ") <> 0 Then retTp = retTp + Left(fcName,InStr (fcName," ")) fcName = Right(fcName, Len(fcName) - InStr(fcName," ")) End If 'Get the function parameters. iPrm = 0 iPrmA = 0 prms = Trim(Header) if Trim(Mid(prms,2, len(prms) - 2)) = "void" then Header = "()" end if 'Count the number of parameters. Do While InStr(prms, ",") <> 0 iPrm = iPrm + 1 prms = Right(prms, Len(prms) - InStr(prms, ",")) Loop 'Store the parameter list in the array. If iPrm > 0 Then ' If multiple params. iPrm = iPrm + 1 iPrmA = iPrm Redim CustParamArr(iPrm) Do While InStr(header, ",") <> 0 CustParamArr(iPrm) = Left(Header, InStr (Header, ",") - 1) 'Remove brace from first parameter. If InStr(CustParamArr(iPrm), " (") <> 0 Then CustParamArr(iPrm) = Right(CustParamArr(iPrm), _ Len(CustParamArr(iPrm))-InStr(CustParamArr(iPrm)," (")) Trim(CustParamArr(iPrm)) End If Header = Right(Header, Len(Header) - InStr(Header,",")) iPrm = iPrm - 1 Loop CustParamArr(iPrm) = Header 'Remove trailing brace from last parameter. If InStr(CustParamArr(iPrm), ")") <> 0 Then CustParamArr(iPrm) = Left(CustParamArr(iPrm), _ InStr(CustParamArr(iPrm), ")") - 1) Trim(CustParamArr(iPrm)) End If Else 'Possibly one param. Redim CustParamArr(1) Header = Right(Header, Len(Header) - 1) ' Strip the first brace. Trim(Header) CustParamArr(1) = StripTabs(Header) If InStr(CustParamArr(1), ")") <> 1 Then CustParamArr(1) = Left(CustParamArr(1), InStr(CustParamArr(1), ")") - 1) Trim(CustParamArr(1)) iPrmA = 1 End If End If if Trim(RetTp) = "" then RetTp = "void" end if 'Position the cursor one line above the selected text. ActiveDocument.Selection.LineUp ActiveDocument.Selection.LineDown ActiveDocument.Selection.StartOfLine ActiveDocument.Selection = vbLf Descr = "/************************************************************************** ****" + _ vbLf + fcName + _ vbLf + "DESCRIPTION OF ALGORITHM: " + _ vbLf + "RETURN TYPE: " + RetTp + _ vbLf + "CALLS: None" + vbLf + _ vbLf + "PARAMETERS: " 'Print the parameter list. Last = iPrmA if iPrmA = 0 then Descr = Descr + "None" & vbLf end if Do While iPrmA <> 0 'Remove a line feed from any of the arguments. If InStr(CustParamArr(iPrmA), vbLf) <> 0 Then CustParamArr(iPrmA) = Right(CustParamArr(iPrmA), _ (Len(CustParamArr(iPrmA)) - _ InStr(CustParamArr(iPrmA), vbLf))) Trim(CustParamArr(iPrmA)) End If CustParamArr(iPrmA) = StripTabs(CustParamArr(iPrmA)) 'If there are 2+ parameters, the first parameter will 'have a '(' prepended to it, remove it here: if iPrmA = Last AND Last <> 1 then CustParamArr(iPrmA) = Right(CustParamArr(iPrmA), _ Len(CustParamArr(iPrmA)) - 1) End If if iPrmA = Last Then WhiteSpace = "" Else WhiteSpace = " " End if Descr = Descr + WhiteSpace + _ CustParamArr(iPrmA) + " - " + vbLf iPrmA = iPrmA - 1 Loop Descr = Descr + vbLf + "AUTHOR: Your Name" + _ vbLf + "*************************************************************************** ***/" + vbLf ActiveDocument.Selection = Descr Else MsgBox("It is possible that the function you are trying to"+_ " work with has a syntax error.") End if End If Else MsgBox("You need to have an active C/C++ document open"+ _ vbLF+"with the function prototype selected.") End If End Sub ========================================================================= Date: Wed, 26 Jan 2000 11:05:11 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Steve Subject: I/O Question In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii If we are supposed to read in all the commands (insert, remove, print) from a file, are we supposed to prompt the user for a filename after they enter "memman " from the command line? Also, are we supposed to print the output to a specified file as well? I am confused about this. Thanks! -Steve > ========================================================================= Date: Wed, 26 Jan 2000 12:26:27 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: I/O Question In-Reply-To: <3.0.6.32.20000126110511.0120be48@mail.vt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The commands are read from the standard input, and your output is written to the standard output. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- On Wed, 26 Jan 2000, Steve wrote: > If we are supposed to read in all the commands (insert, remove, print) > from a file, are we supposed to prompt the user for a filename after they > enter "memman " from the command line? Also, are we > supposed to print the output to a specified file as well? I am confused > about this. Thanks! > -Steve > > ========================================================================= Date: Wed, 26 Jan 2000 13:17:23 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jonathan Graf Subject: Re: I/O Question In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit So does this mean there is no input or output file? We just accept commands from the command line and spit out responses to the screen? <> -----Original Message----- <> From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of <> Cliff Shaffer <> Sent: Wednesday, January 26, 2000 12:26 PM <> To: CS2604@LISTSERV.VT.EDU <> Subject: Re: I/O Question <> <> <> The commands are read from the standard input, and your output is written <> to the standard output. <> <> -- <> Cliff Shaffer, Associate Professor Phone: (540) 231-4354 <> Department of Computer Science Email: shaffer@cs.vt.edu <> Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer <> ------------------------------------------------------------------------- <> <> <> On Wed, 26 Jan 2000, Steve wrote: <> <> > If we are supposed to read in all the commands <> (insert, remove, print) <> > from a file, are we supposed to prompt the user for a filename <> after they <> > enter "memman " from the command line? <> Also, are we <> > supposed to print the output to a specified file as well? I <> am confused <> > about this. Thanks! <> > -Steve > <> > <> ========================================================================= Date: Wed, 26 Jan 2000 13:50:31 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jordan Chavez Subject: Re: I/O Question In-Reply-To: <000201bf6829$97ab3170$564f52c6@campus.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Input could always be piped to the program from a file through standard input. At 01:17 PM 1/26/00 -0500, you wrote: >So does this mean there is no input or output file? We just accept commands >from the command line and spit out responses to the screen? > ><> -----Original Message----- ><> From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of ><> Cliff Shaffer ><> Sent: Wednesday, January 26, 2000 12:26 PM ><> To: CS2604@LISTSERV.VT.EDU ><> Subject: Re: I/O Question ><> ><> ><> The commands are read from the standard input, and your output is written ><> to the standard output. ><> ><> -- ><> Cliff Shaffer, Associate Professor Phone: (540) 231-4354 ><> Department of Computer Science Email: shaffer@cs.vt.edu ><> Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ><> ------------------------------------------------------------------------- ><> ><> ><> On Wed, 26 Jan 2000, Steve wrote: ><> ><> > If we are supposed to read in all the commands ><> (insert, remove, print) ><> > from a file, are we supposed to prompt the user for a filename ><> after they ><> > enter "memman " from the command line? ><> Also, are we ><> > supposed to print the output to a specified file as well? I ><> am confused ><> > about this. Thanks! ><> > -Steve > ><> > ><> > ========================================================================= Date: Wed, 26 Jan 2000 14:38:43 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "mail.vt.edu" Subject: Re: I/O Question MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit How do you do EOF for standard out? What is the key sequence? Jason Roberts ----- Original Message ----- From: "Jordan Chavez" To: Sent: Wednesday, January 26, 2000 1:50 PM Subject: Re: I/O Question > Input could always be piped to the program from a file through standard > input. > > At 01:17 PM 1/26/00 -0500, you wrote: > >So does this mean there is no input or output file? We just accept commands > >from the command line and spit out responses to the screen? > > > ><> -----Original Message----- > ><> From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > ><> Cliff Shaffer > ><> Sent: Wednesday, January 26, 2000 12:26 PM > ><> To: CS2604@LISTSERV.VT.EDU > ><> Subject: Re: I/O Question > ><> > ><> > ><> The commands are read from the standard input, and your output is written > ><> to the standard output. > ><> > ><> -- > ><> Cliff Shaffer, Associate Professor Phone: (540) 231-4354 > ><> Department of Computer Science Email: shaffer@cs.vt.edu > ><> Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer > ><> ------------------------------------------------------------------------ - > ><> > ><> > ><> On Wed, 26 Jan 2000, Steve wrote: > ><> > ><> > If we are supposed to read in all the commands > ><> (insert, remove, print) > ><> > from a file, are we supposed to prompt the user for a filename > ><> after they > ><> > enter "memman " from the command line? > ><> Also, are we > ><> > supposed to print the output to a specified file as well? I > ><> am confused > ><> > about this. Thanks! > ><> > -Steve > > ><> > > ><> > > ========================================================================= Date: Wed, 26 Jan 2000 15:25:14 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brian Subject: Re: I/O Question In-Reply-To: <001501bf6834$f43bc890$9b3a52c6@lefty> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >How do you do EOF for standard out? What is the key sequence? try if(!cin.eof()) { //program here } ========================================================================= Date: Wed, 26 Jan 2000 16:17:13 -0500 Reply-To: bbooker@vt.edu Sender: CS2604 discussion list From: Brandon Booker Organization: Va Tech Subject: Re: I/O Question MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I think its F6, but I'm not sure. "mail.vt.edu" wrote: > > How do you do EOF for standard out? What is the key sequence? > > Jason Roberts > ----- Original Message ----- > From: "Jordan Chavez" > To: > Sent: Wednesday, January 26, 2000 1:50 PM > Subject: Re: I/O Question > > > Input could always be piped to the program from a file through standard > > input. > > > > At 01:17 PM 1/26/00 -0500, you wrote: > > >So does this mean there is no input or output file? We just accept > commands > > >from the command line and spit out responses to the screen? > > > > > ><> -----Original Message----- > > ><> From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf > Of > > ><> Cliff Shaffer > > ><> Sent: Wednesday, January 26, 2000 12:26 PM > > ><> To: CS2604@LISTSERV.VT.EDU > > ><> Subject: Re: I/O Question > > ><> > > ><> > > ><> The commands are read from the standard input, and your output is > written > > ><> to the standard output. > > ><> > > ><> -- > > ><> Cliff Shaffer, Associate Professor Phone: (540) 231-4354 > > ><> Department of Computer Science Email: shaffer@cs.vt.edu > > ><> Virginia Tech, Blacksburg, VA 24061-0106 WWW: > www.cs.vt.edu/~shaffer > > > ><> ------------------------------------------------------------------------ > - > > ><> > > ><> > > ><> On Wed, 26 Jan 2000, Steve wrote: > > ><> > > ><> > If we are supposed to read in all the commands > > ><> (insert, remove, print) > > ><> > from a file, are we supposed to prompt the user for a filename > > ><> after they > > ><> > enter "memman " from the command line? > > ><> Also, are we > > ><> > supposed to print the output to a specified file as well? I > > ><> am confused > > ><> > about this. Thanks! > > ><> > -Steve > > > ><> > > > ><> > > > -- "All you touch and all you see is all your life will ever be" - Pink Floyd www.vegasector.com bbooker.campus.vt.edu ========================================================================= Date: Wed, 26 Jan 2000 17:46:59 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: I/O Question In-Reply-To: <000201bf6829$97ab3170$564f52c6@campus.vt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 26 Jan 2000, Jonathan Graf wrote: > So does this mean there is no input or output file? We just accept commands > from the command line and spit out responses to the screen? Not quite. You do NOT accept commands from the command line. The command line contains the two parameters stated in the spec. You accept commands from stdin. Functionally, this means that you can type data to your program, and spit it back out to the screen. Alternatively, you can redirect stdin and/or stdout, such as: myprog 10 10 outfile -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Wed, 26 Jan 2000 20:25:09 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: jobowyer@VT.EDU Subject: what if all memory is used? MIME-version: 1.0 Content-type: text/plain; charset=us-ascii what if insertions take place to the point where there are NO free blocks at all left? what happens to the free block list? what does it point to? ========================================================================= Date: Wed, 26 Jan 2000 23:06:24 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jason Roberts Subject: What does them memory pool consist of? MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Now that we are required to store 4 byte integers into our memory pool how should the basic memory pool look like? Is it still an array of characters as was described in the original spec, or is it more like a simple record 2 - 4 byte integers and a variable length character array)? A clarification on this would help, as I don't really know how to go about making a character array for the memory pool and then going in and storing integers. I guess that is what people were talking about type casting but I think that somewhere I am missing something. Any clarification would be necessary. Thanks, Jason Roberts ========================================================================= Date: Wed, 26 Jan 2000 23:46:10 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Fang Huang Subject: The minimum size of a free block? MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Hi, Since the memory manager will allocate some space from the free block, if the free block size is larger than the require size, we need to cut that size of space then we still have some leftover, now I want to know what is the minimum size of a free block that we can keep it for later use. Best wishes! ========================================================================= Date: Wed, 26 Jan 2000 23:46:17 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brandon McKelvey Subject: question MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit The input file says delete the spec says remove. Which one will it be... The input file is from unix therefore there is no eof in it. My program crashs on it because of that. Is there going to be an EOF char at the end of each of the input files? Will we be getting anymore test files? brandon ========================================================================= Date: Thu, 27 Jan 2000 00:25:35 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: MIN LIANG Subject: Re: The minimum size of a free block? MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Since we use a linked list whose nodes are separate from the memory pool, the free block will be totally empty. So its minimum size should be 1, although in this case it is no use for saving record. But after some merge, it can be reuse again. ----- Original Message ----- From: Fang Huang To: Sent: Wednesday, January 26, 2000 11:46 PM Subject: The minimum size of a free block? > Hi, > Since the memory manager will allocate some space from the free > block, if the free block size is larger than the require size, we need to > cut that size of space then we still have some leftover, now I want to know > what is the minimum size of a free block that we can keep it for later use. > > Best wishes! ========================================================================= Date: Thu, 27 Jan 2000 00:06:12 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "Michael S. Moulton" Subject: Re: question In-Reply-To: <000701bf6881$7b6f12d0$ebd8c026@parklink.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii At 11:46 PM 1/26/00 -0500, you wrote: >The input file says delete the spec says remove. Which one will it be... >The input file is from unix therefore there is no eof in it. My program >crashs on it because of that. Is there going to be an EOF char at the end >of each of the input files? Will we be getting anymore test files? My program has no problem dealing with EOF. There's nothing special about EOF in Unix-- the difference between Unix and DOS text files is in the EOL character(s). --Mike --- Michael S. Moulton UZ 541+UUD Lord Bodak msmoulton@iname.com VT Class of 2001 http://www.ee.vt.edu/~mmoulton/ ========================================================================= Date: Thu, 27 Jan 2000 00:18:01 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: MIN LIANG Subject: Re: what if all memory is used? MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Print some suitable message like "There is no enough room for this record" and disgard this insert command. ----- Original Message ----- From: To: Sent: Wednesday, January 26, 2000 8:25 PM Subject: what if all memory is used? > what if insertions take place to the point where there are NO free blocks > at all left? what happens to the free block list? what does it point to? ========================================================================= Date: Thu, 27 Jan 2000 00:18:58 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: MIN LIANG Subject: Re: What does them memory pool consist of? MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit It is still an array of characters. ----- Original Message ----- From: Jason Roberts To: Sent: Wednesday, January 26, 2000 11:06 PM Subject: What does them memory pool consist of? > Now that we are required to store 4 byte integers into our memory pool how > should the basic memory pool look like? Is it still an array of characters > as was described in the original spec, or is it more like a simple record > 2 - 4 byte integers and a variable length character array)? A > clarification on this would help, as I don't really know how to go about > making a character array for the memory pool and then going in and storing > integers. I guess that is what people were talking about type casting but I > think that somewhere I am missing something. Any clarification would be > necessary. > > Thanks, > > Jason Roberts ========================================================================= Date: Thu, 27 Jan 2000 01:44:12 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: The minimum size of a free block? In-Reply-To: <0FOZ00DCD98X3Q@gkar.cc.vt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is a good question, and if you had to keep info inside the memory pool itself about the freelist, etc, it would be a serious issue. Since you are using an external freelist, the answer is a simpleminded one. Don't treat it special. Little blocks just won't be used. Eventually they will merge back with something else. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- On Wed, 26 Jan 2000, Fang Huang wrote: > Hi, > Since the memory manager will allocate some space from the free > block, if the free block size is larger than the require size, we need to > cut that size of space then we still have some leftover, now I want to know > what is the minimum size of a free block that we can keep it for later use. > > Best wishes! > ========================================================================= Date: Thu, 27 Jan 2000 11:23:21 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: question In-Reply-To: <000701bf6881$7b6f12d0$ebd8c026@parklink.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The GTA will correct the test data file to use the correct command. Regarding EOL/EOF, be sure to download the test data (and any other ascii data file) in ascii mode. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- On Wed, 26 Jan 2000, Brandon McKelvey wrote: > The input file says delete the spec says remove. Which one will it be... > The input file is from unix therefore there is no eof in it. My program > crashs on it because of that. Is there going to be an EOF char at the end > of each of the input files? Will we be getting anymore test files? > > brandon > ========================================================================= Date: Thu, 27 Jan 2000 11:33:11 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: what if all memory is used? In-Reply-To: <3.0.6.32.20000126202509.007ca370@mail.vt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In that case (which is a good boundary condition to test for!) you would have a linked list with no data nodes. Depending on how you implement your freelist, you might have a head pointer that points to NULL, or, if you use the implementation from the textbook, you might have a linked list with nothing but a dummy header node left. But, you certainly do still have a linked list object -- it just has no data. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- On Wed, 26 Jan 2000 jobowyer@VT.EDU wrote: > what if insertions take place to the point where there are NO free blocks > at all left? what happens to the free block list? what does it point to? > ========================================================================= Date: Thu, 27 Jan 2000 10:33:41 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Ali Asghar Zafer Subject: CSLab Account MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Any student who does not have an account in the CSlab and wishes have it must fill a yellow "CSlab Account Request form" and give it to me. I will do the needful. Thanks Ali Asghar Zafer ========================================================================= Date: Thu, 27 Jan 2000 11:43:06 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Shalaka Tendulkar Subject: Curator MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, The curator is up for all the sections. Please try submitting P0, and let me know if you have any problems. -Shalaka ========================================================================= Date: Thu, 27 Jan 2000 14:09:21 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Website posting of spec changes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The two "official" spec change messages, distributed previously, have now been collected together and posted to the assignments page on the website. Should any other changes be made (hopefully unlikely at this point), they will also be added to that link. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Thu, 27 Jan 2000 15:47:36 -0500 Reply-To: Ines Khelifi Sender: CS2604 discussion list From: Ines Khelifi Subject: curator MIME-version: 1.0 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_DQajAQ/i08yk3yox+xJR7Q)" This is a multi-part message in MIME format. --Boundary_(ID_DQajAQ/i08yk3yox+xJR7Q) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi When I try donloading the Curator Client application, a window pops = ups and it says: An unspecified error occured while connecting..... Any help would be appreciated! Thanks --Boundary_(ID_DQajAQ/i08yk3yox+xJR7Q) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Hi
 
    When I try donloading the Curator = Client=20 application, a window pops ups and it says:
 
          &nbs= p;    An=20 unspecified error occured while connecting.....
 
    Any help would be = appreciated!
 
 
        =    =20            =20 Thanks
--Boundary_(ID_DQajAQ/i08yk3yox+xJR7Q)-- ========================================================================= Date: Thu, 27 Jan 2000 16:00:02 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: James Moniz Subject: Can coordinates be negative? Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Hello, Just wanted to see in writing...can coordinates be negative, or is it considered an error? Just want to know what, exactly, coordinate system we are working with here. Thanks. James Moniz jmoniz@vt.edu ========================================================================= Date: Thu, 27 Jan 2000 17:16:40 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Can coordinates be negative? In-Reply-To: <200001272054.PAA18979@smtp-out1.bellatlantic.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 27 Jan 2000, James Moniz wrote: > Hello, > > Just wanted to see in writing...can coordinates be negative, or is > it considered an error? Just want to know what, exactly, coordinate > system we are working with here. The spec says: "All coordinates will be signed values small enough to fit in a 32-bit int variable." That should pretty definitive. Note that you are not doing any spatial processing in this project -- the coordinates are just data with no semantics at this point. So, if it isn't big enough to screw up your parser (which you have been promised it won't), you don't care about the sign or magnitude. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Thu, 27 Jan 2000 16:20:03 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "Bryan R. Deehring" Subject: Re: Can coordinates be negative? MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII X,Y coord. system. This question was asked in Dr. Roach's section. Coordinates can be negative. -----Original Message----- From: James Moniz [SMTP:jmoniz@VT.EDU] Sent: Thursday, January 27, 2000 4:00 PM To: CS2604@LISTSERV.VT.EDU Subject: Can coordinates be negative? Hello, Just wanted to see in writing...can coordinates be negative, or is it considered an error? Just want to know what, exactly, coordinate system we are working with here. Thanks. James Moniz jmoniz@vt.edu ========================================================================= Date: Thu, 27 Jan 2000 16:22:58 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Alan Lattimer Subject: Re: Can coordinates be negative? MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit From the spec at the bottom of page 1, it says: "...all coordinates will be SIGNED int values that will fit into a 32-bit int variable." Since they used the word 'signed', it seems you need to store positive or negative values. Also the example input file has negative values in it. So I would say that coordinates can be negative. If you hear something different, let me know. Hope this helps. Alan ----- Original Message ----- From: James Moniz To: Sent: Thursday, January 27, 2000 4:00 PM Subject: Can coordinates be negative? > Hello, > > Just wanted to see in writing...can coordinates be negative, or is > it considered an error? Just want to know what, exactly, coordinate > system we are working with here. > > Thanks. > > > James Moniz > jmoniz@vt.edu ========================================================================= Date: Thu, 27 Jan 2000 16:39:55 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Shalaka Tendulkar Subject: curator MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, The curator seems to be having some problems except for section 1370. So if you are in any one of the other sections please hold on for some time to submit P0. I will send out an email when it starts working. Sorry for that, Shalaka ========================================================================= Date: Thu, 27 Jan 2000 18:01:39 -0600 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: George Tjoumas Subject: Posted Files MIME-version: 1.0 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_Jb1J26N0w2q6F4NQPPJsaQ)" This is a multi-part message in MIME format. --Boundary_(ID_Jb1J26N0w2q6F4NQPPJsaQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable This is taken from the output file posted on the web: =20 file://Second Part: Handle and Size of Free Blocks 17 22 57 39 174 46(current) I took a look at the posted word file which shows the memory pool and I = don't really see how at array index 17 there is a free block of size 22 = (actually I don't see how any of them match). Is there something I am = missing? Also, where are we supposed to store the record ID because the = record array contains the handles, the memory pool contains the record = itself, and the free list contains information about what memory is = free. Can we store the record ID anywhere? Thanks, George=20 --Boundary_(ID_Jb1J26N0w2q6F4NQPPJsaQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
This is taken from the output file = posted on the=20 web:
   
file://Second Part:=20 Handle and Size of Free=20 Blocks
17 22
57 39
174 46(current)
 
I took a look at the posted word file = which shows=20 the memory pool and I don't really see how at array index 17 there is a = free=20 block of size 22 (actually I don't see how any of them match).  Is = there=20 something I am missing? Also, where are we supposed to store the record = ID=20 because the record array contains the handles, the memory pool contains = the=20 record itself, and the free list contains information = about what=20 memory is free.  Can we store the record ID anywhere?
 
    Thanks,
       =20     George 
--Boundary_(ID_Jb1J26N0w2q6F4NQPPJsaQ)-- ========================================================================= Date: Thu, 27 Jan 2000 17:59:57 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jordan Chavez Subject: Question regarding design considerations and dump() function In-Reply-To: <000901bf690c$af242990$c6ba52c6@rdp.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii The spec suggests that we have a function in our memory manager called dump(), which displays the contents of memory. I'm assuming this function maps to the command print read from standard input, displaying the contents of reserved blocks followed by a list of free blocks. If the memory manager is able to print out it's contents in some meaningful way then it must know something about it's contents, which seems like a violation of the data encapsulation we are trying to achieve. I realize that this dump function is only for the purpose of having a way to test the program, but wouldn't it be better to have the memory manager only do things that aren't contingent on the content of it's data? For instance, the memory manager could display the free memory blocks without knowing anything about the content, then the client could actually interperet the data and display what's in those reserved blocks. It bothers me that the "suggested interface", which I've seen interpereted by graders as "do it this way or lose points", is recommending a violation of SE principles. Am I in the wrong here, or has anyone else had this concern? Enlightenment from the professors/TAs would be greatly appreciated. Thanks, Jordan Chavez jchavez@vt.edu ========================================================================= Date: Thu, 27 Jan 2000 18:23:17 -0500 Reply-To: jcovin@vt.edu Sender: CS2604 discussion list From: Jon Covin Subject: Re: Posted Files In-Reply-To: <002c01bf6923$03716c40$7332ad80@computer> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT > This is taken from the output file posted on the web: > > file://Second Part: Handle and Size of Free Blocks > 17 22 > 57 39 > 174 46(current) > > I took a look at the posted word file which shows the memory pool and I don't really see how at array index 17 there is a free block of size 22 (actually I don't see how any of them match). Is there something I am missing? You're right they dont match, the first index is off by 4 (interesting since the length of 4 bytes for a record is a new addition) and the other 3 indices are off, but the sizes are correct. The memory map seems to have the correct indices and sizes. Also, where are we supposed to store the record ID because the record array contains the handles, the memory pool contains the record itself, and the free list contains information about what memory is free. Can we store the record ID anywhere? As I understand it the Record ID is the index in the array, you dont have to store it explicitly because it's already there. So record 1 has index (ID) 1, record 16 has index (ID) 16 etc... You can also store a record 0 as was done in the input file. -Jon (still trying to figure out how to put those damn 32bit integers into 4 byte form) ========================================================================= Date: Thu, 27 Jan 2000 18:27:29 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brian Subject: Re: Question regarding design considerations and dump() function In-Reply-To: <3.0.6.32.20000127175957.008fe920@mail.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" HA! I agree with you totally! BUT your main program can't touch the data once the memory manager has control of it. Once the main program has passed the data to the manager, main can only store the handle of the data. Thinking about making the handle the memory address of the data? Sounds like a good idea to me, but you can't! You have to ask the memory manager for the data back using the handle. If the main program touches the stored data directly then there go your points. I think this implementation is more of a record manager than a memory manager. Just my 2 cents. >The spec suggests that we have a function in our memory manager called >dump(), which displays the contents of memory. I'm assuming this function >maps to the command print read from standard input, displaying the contents >of reserved blocks followed by a list of free blocks. If the memory >manager is able to print out it's contents in some meaningful way then it >must know something about it's contents, which seems like a violation of >the data encapsulation we are trying to achieve. > >I realize that this dump function is only for the purpose of having a way >to test the program, but wouldn't it be better to have the memory manager >only do things that aren't contingent on the content of it's data? For >instance, the memory manager could display the free memory blocks without >knowing anything about the content, then the client could actually >interperet the data and display what's in those reserved blocks. It >bothers me that the "suggested interface", which I've seen interpereted by >graders as "do it this way or lose points", is recommending a violation of >SE principles. > >Am I in the wrong here, or has anyone else had this concern? Enlightenment >from the professors/TAs would be greatly appreciated. > >Thanks, >Jordan Chavez >jchavez@vt.edu ========================================================================= Date: Thu, 27 Jan 2000 18:41:29 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: jobowyer@VT.EDU Subject: question about syntax of converting ints to bytes MIME-version: 1.0 Content-type: text/plain; charset=us-ascii yes, i know this question has been answered but i still am not grasping the SYNTAX. i understand the concept, but what is the syntax of inserting a int into the char array and returning it? ========================================================================= Date: Thu, 27 Jan 2000 19:07:41 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Peter Huene Subject: Re: question about syntax of converting ints to bytes In-Reply-To: <3.0.6.32.20000127184129.007d4810@mail.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit The storing of a 4 byte int into a char array is done easiest as mentioned before as a cast operation. The following code will cast a pointer to a character into a pointer to an int, dereference the pointer, and then assign a value like just any ol' int. Please note: when the assignment is complete, the operation will copy data into 4 separate indices in the array (since its copying 4 bytes). Storing: *( (int *) &array[index]) = someint; //This will cast a pointer to some //index in the array to an int //pointer and then dereference //the pointer for assignment. Retrieval: someint = *( (int *) &array[index]); //Same thing only assigns to an int //instead of into the array. You'll want to use memcpy() for the sting most likely. Regards, Peter Huene -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of jobowyer@VT.EDU Sent: Thursday, January 27, 2000 6:41 PM To: CS2604@LISTSERV.VT.EDU Subject: question about syntax of converting ints to bytes yes, i know this question has been answered but i still am not grasping the SYNTAX. i understand the concept, but what is the syntax of inserting a int into the char array and returning it? ========================================================================= Date: Thu, 27 Jan 2000 19:19:32 -0800 Reply-To: tannerb@vt.edu Sender: CS2604 discussion list From: Tanner Bonig Subject: Re: question about syntax of converting ints to bytes In-Reply-To: <3.0.6.32.20000127184129.007d4810@mail.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Well, a fellow student and I conversed about this today... this is what we came up with, but please, since we both plan on using this, correct us if this is wrong... char* buffer; buffer = new char[80]; int hi = 5; buffer[2] = hi; cout << int(Buffer[3]) << endl; //this will print 5. delete Buffer; -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of jobowyer@VT.EDU Sent: Thursday, January 27, 2000 3:41 PM To: CS2604@LISTSERV.VT.EDU Subject: question about syntax of converting ints to bytes yes, i know this question has been answered but i still am not grasping the SYNTAX. i understand the concept, but what is the syntax of inserting a int into the char array and returning it? ========================================================================= Date: Thu, 27 Jan 2000 19:16:57 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jordan Chavez Subject: Re: Question regarding design considerations and dump() function In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii hrm...the client program can always call the get() funtion to retrieve the data associated with the handle, and then interpret/print that out however it wants. You actually _can_ make the handle be the absolute memory address of the reserved data block, then when you pass it back to the memmanager for a get() or dealloc() or whatever have the memmanager subtract the starting address of the memory array from the handle to obtain the relative offset into the memory array. That way the client could call alloc() and get back a regular pointer it could use to write to the memory block etc, then free it with dealloc. Just like malloc() and free(). But of course this simulation has the memory manager's byte array representing _all_ machine memory, so you're right, it would be a bad idea to pass a direct pointer to the client, since the value of that pointer would be meaningless in reference to the simulation. I guess that's why the memmanager interface is so restrictive, having all reads and write to simulated memory going through it. >HA! I agree with you totally! BUT your main program can't touch the data >once the memory manager has control of it. Once the main program has passed >the data to the manager, main can only store the handle of the data. >Thinking about making the handle the memory address of the data? Sounds >like a good idea to me, but you can't! You have to ask the memory manager >for the data back using the handle. If the main program touches the stored >data directly then there go your points. I think this implementation is >more of a record manager than a memory manager. Just my 2 cents. > >>The spec suggests that we have a function in our memory manager called >>dump(), which displays the contents of memory. I'm assuming this function >>maps to the command print read from standard input, displaying the contents >>of reserved blocks followed by a list of free blocks. If the memory >>manager is able to print out it's contents in some meaningful way then it >>must know something about it's contents, which seems like a violation of >>the data encapsulation we are trying to achieve. >> >>I realize that this dump function is only for the purpose of having a way >>to test the program, but wouldn't it be better to have the memory manager >>only do things that aren't contingent on the content of it's data? For >>instance, the memory manager could display the free memory blocks without >>knowing anything about the content, then the client could actually >>interperet the data and display what's in those reserved blocks. It >>bothers me that the "suggested interface", which I've seen interpereted by >>graders as "do it this way or lose points", is recommending a violation of >>SE principles. >> >>Am I in the wrong here, or has anyone else had this concern? Enlightenment >>from the professors/TAs would be greatly appreciated. >> >>Thanks, >>Jordan Chavez >>jchavez@vt.edu > ========================================================================= Date: Thu, 27 Jan 2000 19:56:00 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Peter Huene Subject: Re: question about syntax of converting ints to bytes In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Tanner, my misguided friend :). I'll assume in your code that you meant to use the same index into the array. What you're actually doing is casting the int into a char directly, which will shave off 3 bytes, to an 8 bit char. So instead of storing the value of the entire 32 bit integer, you're storing the first 8 bits. This is ok for the value 5 (an 8 bit signed char has the values -128 to 127) where the left most 3 bytes are 0's, but what about a value of 1000000? Try that and see what happens :). See my previous post titled "Re: question about syntax of converting ints to bytes" and ICQ me if you have any questions. Also you should note that you are leaking memory, since when you allocate an array using the new operator, you must also use the [] syntax when calling delete, as such "delete [] buffer;". Regards. Peter Huene -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Tanner Bonig Sent: Thursday, January 27, 2000 10:20 PM To: CS2604@LISTSERV.VT.EDU Subject: Re: question about syntax of converting ints to bytes Well, a fellow student and I conversed about this today... this is what we came up with, but please, since we both plan on using this, correct us if this is wrong... char* buffer; buffer = new char[80]; int hi = 5; buffer[2] = hi; cout << int(Buffer[3]) << endl; //this will print 5. delete Buffer; -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of jobowyer@VT.EDU Sent: Thursday, January 27, 2000 3:41 PM To: CS2604@LISTSERV.VT.EDU Subject: question about syntax of converting ints to bytes yes, i know this question has been answered but i still am not grasping the SYNTAX. i understand the concept, but what is the syntax of inserting a int into the char array and returning it? ========================================================================= Date: Thu, 27 Jan 2000 21:59:34 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: MIN LIANG Subject: Re: Posted Files MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Right. The old output file is wrong and it has been corrected. The memory map is right. Now, look at the new output file please. Thanks. ----- Original Message ----- From: Jon Covin To: Sent: Thursday, January 27, 2000 6:23 PM Subject: Re: Posted Files > > This is taken from the output file posted on the web: > > > > file://Second Part: Handle and Size of Free Blocks > > 17 22 > > 57 39 > > 174 46(current) > > > > I took a look at the posted word file which shows the memory pool and I don't > really see how at array index 17 there is a free block of size 22 (actually I don't > see how any of them match). Is there something I am missing? > > You're right they dont match, the first index is off by 4 (interesting > since the length of 4 bytes for a record is a new addition) and the > other 3 indices are off, but the sizes are correct. The memory map > seems to have the correct indices and sizes. > > Also, where are we supposed to store the record ID because the record array contains the > handles, the memory pool contains the record itself, and the free list contains > information about what memory is free. Can we store the record ID anywhere? > > As I understand it the Record ID is the index in the array, you dont > have to store it explicitly because it's already there. So record 1 > has index (ID) 1, record 16 has index (ID) 16 etc... You can also > store a record 0 as was done in the input file. > > -Jon (still trying to figure out how to put those damn 32bit integers > into 4 byte form) ========================================================================= Date: Sun, 28 Feb 1999 07:08:39 -0800 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: john gordon Subject: Re: question about syntax of converting ints to bytes MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit I dont know about everyone else, but im just implimenting a struct containing the values to be stored in the right order as a "message token" to be passed from the client to the memmanager class, then im having the memmanager process it (search for space and then memcpy() the whole struct... it should put them into the array in the order they were input into the struct... length, x,y, city name) it simplifies the copying to one line once youve found the space and is fairly easy to conceptualize once you read the code... try that. Tell me if im wrong by the way, im not too far to change my implimentation. ----- Original Message ----- From: "Peter Huene" To: Sent: Thursday, January 27, 2000 4:56 PM Subject: Re: question about syntax of converting ints to bytes > Tanner, my misguided friend :). I'll assume in your code that you meant to > use the same index into the array. What you're actually doing is casting > the int into a char directly, which will shave off 3 bytes, to an 8 bit > char. So instead of storing the value of the entire 32 bit integer, you're > storing the first 8 bits. This is ok for the value 5 (an 8 bit signed char > has the values -128 to 127) where the left most 3 bytes are 0's, but what > about a value of 1000000? Try that and see what happens :). See my > previous post titled "Re: question about syntax of converting ints to bytes" > and ICQ me if you have any questions. Also you should note that you are > leaking memory, since when you allocate an array using the new operator, you > must also use the [] syntax when calling delete, as such "delete [] > buffer;". Regards. > > Peter Huene > > -----Original Message----- > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > Tanner Bonig > Sent: Thursday, January 27, 2000 10:20 PM > To: CS2604@LISTSERV.VT.EDU > Subject: Re: question about syntax of converting ints to bytes > > > Well, a fellow student and I conversed about this today... > this is what we came up with, but please, since we both plan on using this, > correct us if this is wrong... > > char* buffer; > buffer = new char[80]; > int hi = 5; > buffer[2] = hi; > cout << int(Buffer[3]) << endl; file://this will print 5. > delete Buffer; > > > > -----Original Message----- > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > jobowyer@VT.EDU > Sent: Thursday, January 27, 2000 3:41 PM > To: CS2604@LISTSERV.VT.EDU > Subject: question about syntax of converting ints to bytes > > > yes, i know this question has been answered but i still am not grasping the > SYNTAX. i understand the concept, but what is the syntax of inserting a int > into the char array and returning it? ========================================================================= Date: Sun, 28 Feb 1999 07:14:43 -0800 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: john gordon Subject: Re: IMPORTANT: Spec clarifications MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit I need just one more clarification.... i understand that this is first fit, from the CURRENT free block right? So my question is when do we incriment the free block? On allocation of memory, freeing of memory, searching of memory, etc. Or do we always set currPtr to be the pointer pointing to the last indexed node regardless of the operation? I ask this because i just wrote my return_memory type function and am wondering what currPtr points to at the end of that removal if : a.) we can merge the new free node or b.) the new free node has to stay individual. Where, in those cases does the current free node lie? ----- Original Message ----- From: "Cliff Shaffer" To: Sent: Tuesday, January 25, 2000 8:15 AM Subject: Re: IMPORTANT: Spec clarifications > On Tue, 25 Jan 2000, Jordan Chavez wrote: > > > A few questions... > > > > >3) The spec contains a discussion on design choices related to how the > > >record gets stored in the memory manager's memory. Disregard that > > >discussion. You are REQUIRED to store records as follows: > > > > I'm assuming we can store a free block however we want..??? > > Free blocks don't actually contain any information. The linked list tells > you where the freeblocks are, and how long they are. > > > >a) Each record, as passed to the memory manager class, will first contain > > >a 4 byte field for the X coord, followed by a 4 byte field for the Y > > >coord, followed by the name, with NO terminating null character. > > > > > >b) The memory manager will prepend a 4 byte value containing the length of > > >the record being stored. If the record is length N, then the value stored > > >will be N and the total length of memory required is N+4 (to store the > > >length field for the record). So, if the memory request is 50 bytes, 54 > > >byte are actually required and stored. > > > > If all that's stored is the size then how are we to distinguish free blocks > > from > > reserved blocks for purposes of deallocation? i.e. there is no tag field > > in a > > reserved memory block, so when we free up a block, how can we tell whether > > or not > > to merge adjacent free blocks? > > Recall that the linked list stores the free blocks in sequential order as > they appear in the memory pool. When you are freeing a block, work your > way down the linked list until you find the ones immediately preceding and > following the block you are freeing. Merge adjacent blocks as > appropriate. > > -- > Cliff Shaffer, Associate Professor Phone: (540) 231-4354 > Department of Computer Science FAX: (540) 231-6075 > Virginia Tech, Blacksburg, VA 24061-0106 Email: shaffer@cs.vt.edu > ----------------------------------------------------------------------- ========================================================================= Date: Fri, 28 Jan 2000 11:18:34 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Question regarding design considerations and dump() function In-Reply-To: <3.0.6.32.20000127191657.00905770@mail.vt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 27 Jan 2000, Jordan Chavez wrote: > hrm...the client program can always call the get() funtion to retrieve the > data associated with the handle, and then interpret/print that out however > it wants. > > You actually _can_ make the handle be the absolute memory address of the > reserved data block, then when you pass it back to the memmanager for a > get() or dealloc() or whatever have the memmanager subtract the starting > address of the memory array from the handle to obtain the relative offset > into the memory array. That way the client could call alloc() and get back > a regular pointer it could use to write to the memory block etc, then free > it with dealloc. Just like malloc() and free(). But of course this > simulation has the memory manager's byte array representing _all_ machine > memory, so you're right, it would be a bad idea to pass a direct pointer to > the client, since the value of that pointer would be meaningless in > reference to the simulation. I guess that's why the memmanager interface > is so restrictive, having all reads and write to simulated memory going > through it. This is essentially correct. Note that the spec talks about "two parts" of the dump command. The idea is to let each side do what it knows. The memory manager dumps the list of free blocks. The client goes through its record array, and for each non-empty position, it gets the record back from the memory manager and prints out the (logical) record. So, nobody knows what they shouldn't. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------ ========================================================================= Date: Fri, 28 Jan 2000 11:24:08 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: IMPORTANT: Spec clarifications In-Reply-To: <008901be632d$12099a90$7d6d52c6@disorganized> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 28 Feb 1999, john gordon wrote: > I need just one more clarification.... > i understand that this is first fit, from the CURRENT free block right? So > my question is when do we incriment the free block? On allocation of > memory, freeing of memory, searching of memory, etc. Or do we always set > currPtr to be the pointer pointing to the last indexed node regardless of > the operation? I ask this because i just wrote my return_memory type > function and am wondering what currPtr points to at the end of that removal > if : a.) we can merge the new free node or b.) the new free node has to stay > individual. Where, in those cases does the current free node lie? Yes, it is important that everybody get this right. You ONLY change which block is current on an insert command, and then ONLY when the current block is too small to satisfy the command. So, there are basically three ways to affect a block, and only ONE of them changes the current pointer. To summarize: 1) What if the current block merges with an adjacent (newly freed) block? It becomes bigger and remains the current block. Note that the start address of the current block might change due to the merge. 2) What if the current block is partly used to satisfy a request? It becomes smaller, and remains the current block. Note that the start address will change, since you should whack the bytes being reserved off the front of the block. 3) What if the current block cannot satisfy a request? Then the current pointer moves on to the next block. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Fri, 28 Jan 2000 11:27:41 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: question about syntax of converting ints to bytes In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 27 Jan 2000, Peter Huene wrote: > Storing: > *( (int *) &array[index]) = someint; //This will cast a pointer to some > //index in the array to an int > //pointer and then dereference > //the pointer for assignment. > Retrieval: > someint = *( (int *) &array[index]); //Same thing only assigns to an int > //instead of into the array. This is correct, and perhaps most general, but better in this particular situation might be: ((int *)array)[0] = x; ((int *)array)[1] = y; since you will probably always be putting the x and y coordinates at the front of array. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Fri, 28 Jan 2000 12:42:52 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: James Moniz Subject: Re: IMPORTANT: Spec clarifications Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Hello, >2) What if the current block is partly used to satisfy a request? It >becomes smaller, and remains the current block. Note that the start >address will change, since you should whack the bytes being reserved off >the front of the block. This has to do with my question, which is "Are we going to be graded on where out information/records end up being stored in the memory pool?" Are the GTA's going to take a list of where a record "should" be stored and where a free block "should" be and if ours does not match, will take points off? Or are we free to set it up the way we see fit, as long as it works properly. Possible differences can be... 1). Do you give an insert call the memory at the end of a free block (an idea I got from whoever the guy who wrote our textbook is) or the beginning, changing the size field of the free block node or the position? 2). Do you check the size of the block starting at current or curr->next because... a) Having just taken memory previous from current, odds are (or not, depending on what you believe) that the current block will be short, so go immediately to the next. b) You're using a single-link list and want to stay on step behind the free block node you end up using. ...blah,blah,blah, it can go on. So, what I want to know is, are we going to be graded on where our memory ends up beginning used, or the fact that we get the job done correctly & effeciently, however it gets done. Thanks James Moniz jmoniz@vt.edu ========================================================================= Date: Fri, 28 Jan 2000 14:55:04 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: IMPORTANT: Spec clarifications In-Reply-To: <200001281736.MAA26316@smtp-out2.bellatlantic.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 28 Jan 2000, James Moniz wrote: > This has to do with my question, which is "Are we going to be graded > on where out information/records end up being stored in the memory pool?" > Are the GTA's going to take a list of where a record "should" be stored > and where a free block "should" be and if ours does not match, will take > points off? Or are we free to set it up the way we see fit, as long as it > works properly. Our intention is to define the spec precisely enough so that there is only one correct way to store data in the memory pool. If there are still ambiguities, we need to hear about them. > Possible differences can be... > > 1). Do you give an insert call the memory at the end of a free > block (an idea I got > from whoever the guy who wrote our textbook is) or the > beginning, changing the > size field of the free block node or the position? The email you just replied to defined this. Pull the bytes off the front of the current block. > 2). Do you check the size of the block starting at current or > curr->next because... > > a) Having just taken memory previous from current, odds > are (or not, depending > on what you believe) that the current block will be > short, so go > immediately to the next. The email you just replied to defines this. You do not change the current block if the current block statisfies the current request. > b) You're using a single-link list and want to stay on > step behind the free > block node you end up using. Don't confuse your physical implementation for linked lists with the logical definition of the task you are trying to accomplish. There is a logical "current" block. What your pointers point to internally within the linked list is your own business. For example, the implementation in the textbook has the current pointer actually point to the node ahead of the logical current node, for implementation convenience. This does not change the definition of the logical current node, just the physical value of the pointer. In conclusion, I am currently unaware of any ambiguities in the spec. Doesn't mean there aren't any. :-) -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Fri, 28 Jan 2000 15:01:03 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Update to the spec clarifications MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have now updated the posted spec clarifications/modifications page to reflect the clarifications regarding what happens to the "current" block on inserts and frees. I'm trying to make sure that all of the clarifications are posted to that one place to make it easy on everybody. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Thu, 28 Jan 0100 14:42:12 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brian Wagner Subject: CS2604: Linux OO drawing program Content-Type: text Anyone know of a drawing program for Linux (X) that's good for drawing OO diagrams? (eg, inheritance diags, class diags, etc) Basically, I've used PowerPoint in the past in Windows to do these things. Thanks. -- // http://www.bigfoot.com/~datatroi Richard's tale about encounter with Australian customs officers: He was asked all the usual questions; "How long are you staying?", "Are you carrying any illegal drugs?" etc. But when asked if he had ever been convicted of a felony, Richard replied "What! Is that still an entry requirement?". ========================================================================= Date: Fri, 28 Jan 2000 16:08:03 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: CS2604: Linux OO drawing program In-Reply-To: <200001281942.OAA00544@www.geocities.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 28 Jan 100, Brian Wagner wrote: > Anyone know of a drawing program for Linux (X)... Personally, I use xfig for all my picture drawing needs. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Fri, 28 Jan 2000 18:47:37 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: jobowyer@VT.EDU Subject: about piping input data MIME-version: 1.0 Content-type: text/plain; charset=us-ascii the gta's are going to test our program by piping an input file into our exe, right? can anyone tell me how we can do that in windows ourselves? is it something like memmanager | sampleinput.txt ? thanx kevyn ========================================================================= Date: Fri, 28 Jan 2000 18:58:54 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Dennis Kryway II Subject: Re: about piping input data MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit I think you do it like this: yourprogram < sample.txt jobowyer@VT.EDU wrote: > the gta's are going to test our program by piping an input file into our > exe, right? can anyone tell me how we can do that in windows ourselves? is > it something like > memmanager | sampleinput.txt > ? > thanx > kevyn ========================================================================= Date: Fri, 28 Jan 2000 19:00:43 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jordan Chavez Subject: Re: about piping input data In-Reply-To: <3.0.6.32.20000128184737.007c6c30@mail.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii memmanager 256 25 output.txt At 06:47 PM 1/28/00 -0500, you wrote: >the gta's are going to test our program by piping an input file into our >exe, right? can anyone tell me how we can do that in windows ourselves? is >it something like >memmanager | sampleinput.txt >? >thanx >kevyn > ========================================================================= Date: Fri, 28 Jan 2000 19:10:33 +0000 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Kaiyan Xiao Subject: project 1 MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Does anyone know if we can store the position handles in the linked list nodes so we can traverse the memory pool? thanks, Kaiyan ========================================================================= Date: Sat, 29 Jan 2000 14:45:48 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Chris Kelly Subject: command lne args for sample input file? MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit anyone know what the command line arguments were for the sample input file that is posted on the web page? -Chris Kelly ckelly@vt.edu ========================================================================= Date: Sat, 29 Jan 2000 14:56:10 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brandon McKelvey Subject: Re: command lne args for sample input file? MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit 256 and 26 i think.... it is at the top of the output file if you look at that.... brandon ----- Original Message ----- From: Chris Kelly To: Sent: Saturday, January 29, 2000 2:45 PM Subject: command lne args for sample input file? > anyone know what the command line arguments were for the sample input file > that is posted on the web page? > > -Chris Kelly > ckelly@vt.edu ========================================================================= Date: Sat, 29 Jan 2000 14:58:49 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Scott Walker Subject: unkown size errors with memcpy() MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit When trying to use memcpy() to copy x bytes of data from one location to another I get an unkown size error. for instance, something like this will give me the error described above: void insert(void* space, size){ memcpy((void *) &space[0], (void *) &mempool[recHandle], sizeof(4)); } Any helpful hints/tips out there? ========================================================================= Date: Sat, 29 Jan 2000 15:14:42 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Scott Walker Subject: unknown size error again! (more specifics) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit When trying to use memcpy() to copy x bytes of data from one location to another I get an unkown size error like C:\School Work\CS2604\memman\memmanager.cpp(111) : error C2036: 'void *' : unknown size on the line that actually trys to perform the copy. for instance, something like this will give me the error described above: void insert(void* space, size){ memcpy((void *) &space[0], (void *) &mempool[recHandle], sizeof(4)); } Any helpful hints/tips out there? ========================================================================= Date: Sat, 29 Jan 2000 15:16:34 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Chris Kelly Subject: Re: command lne args for sample input file? In-Reply-To: <000701bf6a92$e3e776f0$ebd8c026@parklink.net> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit ahh yes. thanks. didn't see that there... :) -Chris -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Brandon McKelvey Sent: Saturday, January 29, 2000 2:56 PM To: CS2604@LISTSERV.VT.EDU Subject: Re: command lne args for sample input file? 256 and 26 i think.... it is at the top of the output file if you look at that.... brandon ----- Original Message ----- From: Chris Kelly To: Sent: Saturday, January 29, 2000 2:45 PM Subject: command lne args for sample input file? > anyone know what the command line arguments were for the sample input file > that is posted on the web page? > > -Chris Kelly > ckelly@vt.edu ========================================================================= Date: Sat, 29 Jan 2000 15:26:07 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Fang Huang Subject: sample input file MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Hi, It seems I saw a message it said that we need save the sample input file as ascii file, can somebody tell me how to do it? Thanks a lot! Fang ========================================================================= Date: Sat, 29 Jan 2000 16:40:45 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Ali Asghar Zafer Subject: Re: unknown size error again! (more specifics) In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Why dont you try memcpy((void *) &space[0], (void *) &mempool[recHandle], sizeof(int)); ----- On Sat, 29 Jan 2000, Scott Walker wrote: > When trying to use memcpy() to copy x bytes of data from > one location to another I get an unkown size error like > > C:\School Work\CS2604\memman\memmanager.cpp(111) : error C2036: 'void *' : > unknown size > > on the line that actually trys to perform the copy. > > for instance, something like this will give me the error described above: > > void insert(void* space, size){ > memcpy((void *) &space[0], (void *) &mempool[recHandle], sizeof(4)); > } > > > Any helpful hints/tips out there? > ========================================================================= Date: Sat, 29 Jan 2000 17:44:10 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Will Boyle Subject: Debug Error MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Hi, I declare a record array to hold the handles and i try to assign the values, but when i run the program and When it tries to exit I get Debug Error DAMAGE: after Normal Block (#49) at 0X003002D0 I don't what this message means and how to go about fixing it. Any Suggestions? Will ========================================================================= Date: Sat, 29 Jan 2000 17:46:47 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Ago Sukanovic Subject: Program arguments - solution! MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII For everybody that doesn't know how to redirect the program's stdin - stdout: If you are using Visual C++ 6.0 interface all you have to do is go to: Project -> Settings (Dialog box will pop up) There will be some tags on top. Click on the Debug tag. Category should be set to General. In the textbox under the Program Arguments enter something like: 256 26 output.txt where input.txt is an ASCII file containing the commands, and output.txt will receive all the output. This will work if you add both input.txt and output.txt to your project, otherwise you must be sure that both files are in the same directory as the executable file. The above arguments will work even if you are testing your program from the command line (MS-DOS). Ago Sukanovic P.S. For the guy that doesn't know how to create an ASCII file - switch your major!!! ========================================================================= Date: Sat, 29 Jan 2000 18:15:43 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Webb Pinner Subject: Removing a record MIME-version: 1.0 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_JLDX6n/szqx1uPIzZwio5w)" This is a multi-part message in MIME format. --Boundary_(ID_JLDX6n/szqx1uPIzZwio5w) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable If a request is given to remove a record from the pool, does the newly = created free space become the current freeblock in the freeblock list = from where a search will start to fill the next memory request? --Boundary_(ID_JLDX6n/szqx1uPIzZwio5w) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
If a request is given to remove a = record from the=20 pool, does the newly created free space become the current freeblock in = the=20 freeblock list from where a search will start to fill the next memory=20 request?
--Boundary_(ID_JLDX6n/szqx1uPIzZwio5w)-- ========================================================================= Date: Sat, 29 Jan 2000 19:11:19 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Saam Tariverdi Subject: Re: Program arguments - solution! MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Do we have to redirect the input/output? In other words, can't we just manually type in the commands from the prompt? Saam Tariverdi ----- Original Message ----- From: Ago Sukanovic To: Sent: Saturday, January 29, 2000 5:46 PM Subject: Program arguments - solution! > For everybody that doesn't know how to redirect the program's stdin - > stdout: > If you are using Visual C++ 6.0 interface all you have to do is go to: > Project -> Settings (Dialog box will pop up) > There will be some tags on top. Click on the Debug tag. > Category should be set to General. > In the textbox under the Program Arguments enter something like: > 256 26 output.txt > where input.txt is an ASCII file containing the commands, and output.txt > will receive all the output. > > This will work if you add both input.txt and output.txt to your project, > otherwise you must be sure that both files are in the same directory as the > executable file. > > The above arguments will work even if you are testing your program from the > command line (MS-DOS). > > Ago Sukanovic > > P.S. For the guy that doesn't know how to create an ASCII file - switch your > major!!! ========================================================================= Date: Sat, 29 Jan 2000 19:30:01 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Richard Bowman Subject: Re: Program arguments - solution! In-Reply-To: <003501bf6ab6$8957fba0$124723d0@ntc.offcampus.vt.edu> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 8bit No, the input MUST come from standard in. the output MUST go to the standard out. Just follow the spec... its not that hard!! Richard On Sat, 29 Jan 2000, you wrote: > Do we have to redirect the input/output? In other words, can't we just > manually type in the commands from the prompt? > > Saam Tariverdi > > > > ----- Original Message ----- > From: Ago Sukanovic > To: > Sent: Saturday, January 29, 2000 5:46 PM > Subject: Program arguments - solution! > > > > For everybody that doesn't know how to redirect the program's stdin - > > stdout: > > If you are using Visual C++ 6.0 interface all you have to do is go to: > > Project -> Settings (Dialog box will pop up) > > There will be some tags on top. Click on the Debug tag. > > Category should be set to General. > > In the textbox under the Program Arguments enter something like: > > 256 26 output.txt > > where input.txt is an ASCII file containing the commands, and output.txt > > will receive all the output. > > > > This will work if you add both input.txt and output.txt to your project, > > otherwise you must be sure that both files are in the same directory as > the > > executable file. > > > > The above arguments will work even if you are testing your program from > the > > command line (MS-DOS). > > > > Ago Sukanovic > > > > P.S. For the guy that doesn't know how to create an ASCII file - switch > your > > major!!! ========================================================================= Date: Sat, 29 Jan 2000 21:49:54 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Scott Walker Subject: memcpy() problems STILL MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Still having no luck getting the memcpy() function to work for me. I've tried countless variations on the function, but so far have had no luck. I can get it to copy just fine assuming I am copying starting from the beginning of the array, but if I try to perform a memcpy() starting at a specific index in the array it generates errors. The example below works fine assuming I am copying FROM the memory pool into a buffer array, but if I try to go the other way (from buffer to memory pool) it will not work. On Sat, Jan 29, 2000 at 03:14:42PM -0500, Scott Walker wrote: > When trying to use memcpy() to copy x bytes of data from > one location to another I get an unkown size error like > > C:\School Work\CS2604\memman\memmanager.cpp(111) : error C2036: 'void *' : > unknown size > > on the line that actually trys to perform the copy. > > for instance, something like this will give me the error described above: > > void insert(void* space, size){ > memcpy((void *) &space[0], (void *) &mempool[recHandle], sizeof(4)); > } memcpy(space,&mempool[recHandle],4); > > > Any helpful hints/tips out there? -- Lally Singh----------------------------Death_To_NT@VT.EDU "I've lost faith in nihilism" ========================================================================= Date: Sat, 29 Jan 2000 22:38:44 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Peter Huene Subject: Re: memcpy() problems STILL In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit This might clean some things up for you. MSDN has the following to say about memcpy(): memcpy Copies characters between buffers. void *memcpy( void *dest, const void *src, size_t count ); Try this to copy data to a specific memory pool location: memcpy((void*) &mempool[recHandle], space, size); Try this to copy memory pool data to a buffer: memcpy(space, (void*) &mempool[recHandle], size); Remember to use the size passed to your function, and not sizeof. That's just the memcpy() syntax. Looking over your initial email I'd like to point out the following. Ali Asghar Zafer was wrong (no offense) in saying the error was being caused by sizeof(4). sizeof(4) is actually the same thing as sizeof(int) since the 4 is being interpreted as a literal int (at least in VC, couldn't tell you if that's ANSI). The error was actually do to the following: &space[0]. space is a void* and the compiler does not know its type, therefore it can't index into the pointer (the compiler doesn't know how many bytes each index adds, therefore can't do the pointer math required). Also, here's a few reminders. You should be offsetting the coping of the memory pool data to account for the 4 bytes at the beginning of the memory block that contains the length of the memory block. The second memcpy() call above should also determine the size to copy by looking at that 4 byte segment (I assume you'd want this in your get() function). Hope some of this helps, regards. Peter Huene -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Scott Walker Sent: Saturday, January 29, 2000 9:50 PM To: CS2604@LISTSERV.VT.EDU Subject: memcpy() problems STILL Still having no luck getting the memcpy() function to work for me. I've tried countless variations on the function, but so far have had no luck. I can get it to copy just fine assuming I am copying starting from the beginning of the array, but if I try to perform a memcpy() starting at a specific index in the array it generates errors. The example below works fine assuming I am copying FROM the memory pool into a buffer array, but if I try to go the other way (from buffer to memory pool) it will not work. On Sat, Jan 29, 2000 at 03:14:42PM -0500, Scott Walker wrote: > When trying to use memcpy() to copy x bytes of data from > one location to another I get an unkown size error like > > C:\School Work\CS2604\memman\memmanager.cpp(111) : error C2036: 'void *' : > unknown size > > on the line that actually trys to perform the copy. > > for instance, something like this will give me the error described above: > > void insert(void* space, size){ > memcpy((void *) &space[0], (void *) &mempool[recHandle], sizeof(4)); > } memcpy(space,&mempool[recHandle],4); > > > Any helpful hints/tips out there? -- Lally Singh----------------------------Death_To_NT@VT.EDU "I've lost faith in nihilism" ========================================================================= Date: Sat, 29 Jan 2000 23:12:12 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Peter Huene Subject: Re: memcpy() problems STILL In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit My typos: clean = clear. do = due. coping = copying. (I didn't proofread, my girlfriend made me dinner and I was beckoned away). Sorry ;) Peter Huene -----Original Message----- From: Peter Huene [mailto:phuene@vt.edu] Sent: Saturday, January 29, 2000 10:39 PM To: CS2604 discussion list Subject: RE: memcpy() problems STILL This might clean some things up for you. MSDN has the following to say about memcpy(): memcpy Copies characters between buffers. void *memcpy( void *dest, const void *src, size_t count ); Try this to copy data to a specific memory pool location: memcpy((void*) &mempool[recHandle], space, size); Try this to copy memory pool data to a buffer: memcpy(space, (void*) &mempool[recHandle], size); Remember to use the size passed to your function, and not sizeof. That's just the memcpy() syntax. Looking over your initial email I'd like to point out the following. Ali Asghar Zafer was wrong (no offense) in saying the error was being caused by sizeof(4). sizeof(4) is actually the same thing as sizeof(int) since the 4 is being interpreted as a literal int (at least in VC, couldn't tell you if that's ANSI). The error was actually do to the following: &space[0]. space is a void* and the compiler does not know its type, therefore it can't index into the pointer (the compiler doesn't know how many bytes each index adds, therefore can't do the pointer math required). Also, here's a few reminders. You should be offsetting the coping of the memory pool data to account for the 4 bytes at the beginning of the memory block that contains the length of the memory block. The second memcpy() call above should also determine the size to copy by looking at that 4 byte segment (I assume you'd want this in your get() function). Hope some of this helps, regards. Peter Huene -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Scott Walker Sent: Saturday, January 29, 2000 9:50 PM To: CS2604@LISTSERV.VT.EDU Subject: memcpy() problems STILL Still having no luck getting the memcpy() function to work for me. I've tried countless variations on the function, but so far have had no luck. I can get it to copy just fine assuming I am copying starting from the beginning of the array, but if I try to perform a memcpy() starting at a specific index in the array it generates errors. The example below works fine assuming I am copying FROM the memory pool into a buffer array, but if I try to go the other way (from buffer to memory pool) it will not work. On Sat, Jan 29, 2000 at 03:14:42PM -0500, Scott Walker wrote: > When trying to use memcpy() to copy x bytes of data from > one location to another I get an unkown size error like > > C:\School Work\CS2604\memman\memmanager.cpp(111) : error C2036: 'void *' : > unknown size > > on the line that actually trys to perform the copy. > > for instance, something like this will give me the error described above: > > void insert(void* space, size){ > memcpy((void *) &space[0], (void *) &mempool[recHandle], sizeof(4)); > } memcpy(space,&mempool[recHandle],4); > > > Any helpful hints/tips out there? -- Lally Singh----------------------------Death_To_NT@VT.EDU "I've lost faith in nihilism" ========================================================================= Date: Sun, 30 Jan 2000 10:54:06 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Ali Asghar Zafer Subject: Re: memcpy() problems STILL In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Yeah! Peter Huene, i guess what you said makes sense...It could be because of the void * stuff. On Sat, 29 Jan 2000, Peter Huene wrote: > This might clean some things up for you. MSDN has the following to say > about memcpy(): > > memcpy > Copies characters between buffers. > void *memcpy( void *dest, const void *src, size_t count ); > > Try this to copy data to a specific memory pool location: > memcpy((void*) &mempool[recHandle], space, size); > > Try this to copy memory pool data to a buffer: > memcpy(space, (void*) &mempool[recHandle], size); > > Remember to use the size passed to your function, and not sizeof. > > That's just the memcpy() syntax. Looking over your initial email I'd like > to point out the following. Ali Asghar Zafer was wrong (no offense) in > saying the error was being caused by sizeof(4). sizeof(4) is actually the > same thing as sizeof(int) since the 4 is being interpreted as a literal int > (at least in VC, couldn't tell you if that's ANSI). The error was actually > do to the following: &space[0]. space is a void* and the compiler does not > know its type, therefore it can't index into the pointer (the compiler > doesn't know how many bytes each index adds, therefore can't do the pointer > math required). Also, here's a few reminders. You should be offsetting the > coping of the memory pool data to account for the 4 bytes at the beginning > of the memory block that contains the length of the memory block. The > second memcpy() call above should also determine the size to copy by looking > at that 4 byte segment (I assume you'd want this in your get() function). > Hope some of this helps, regards. > > Peter Huene > > -----Original Message----- > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > Scott Walker > Sent: Saturday, January 29, 2000 9:50 PM > To: CS2604@LISTSERV.VT.EDU > Subject: memcpy() problems STILL > > > Still having no luck getting the memcpy() function > to work for me. I've tried countless variations on the function, > but so far have had no luck. I can get it to copy just fine assuming > I am copying starting from the beginning of the array, but if > I try to perform a memcpy() starting at a specific index in the array > it generates errors. The example below works fine assuming I am copying > FROM the memory pool into a buffer array, but if I try to go the other > way (from buffer to memory pool) it will not work. > > > > > On Sat, Jan 29, 2000 at 03:14:42PM -0500, Scott Walker wrote: > > When trying to use memcpy() to copy x bytes of data from > > one location to another I get an unkown size error like > > > > C:\School Work\CS2604\memman\memmanager.cpp(111) : error C2036: 'void *' : > > unknown size > > > > on the line that actually trys to perform the copy. > > > > for instance, something like this will give me the error described above: > > > > void insert(void* space, size){ > > memcpy((void *) &space[0], (void *) &mempool[recHandle], > sizeof(4)); > > } > memcpy(space,&mempool[recHandle],4); > > > > > > > Any helpful hints/tips out there? > > -- > Lally Singh----------------------------Death_To_NT@VT.EDU > "I've lost faith in nihilism" > ========================================================================= Date: Sun, 30 Jan 2000 11:47:23 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: David Subject: what to do when freeblock list empty MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Say you have a free-block list of size 100, and 0-94 are allocated, leaving only the last 5 spaces free. In the record array of size 10, handles 0-6 are allocated, leaving 7-9 free. You get a request to insert a record into the memory pool, say size 18 into record 6 (6 is already occupied) The way Im reading the spec, you first check the memory pool to see if the current block is large enough to satisfy the request. It is not. Do I *then* delete the record handle 6 and then re-check the memory pool for a block large enough to satisfy the request? (18 in this case) Or should the sequence be: 1) first check the record array to see if a record is alreay stored in the record requested by insert 2) remove that record, and add the freed up memory to the memory pool 3) NOW check if there is enough memory in the memory pool to satisfy the request It sounds like the 2nd way is better (check if the record to insert will "overwrite" another record, if it does, free that memory and check if the pool is large enough now) Any input will be helpful David ========================================================================= Date: Sun, 30 Jan 2000 11:55:24 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: David MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Ignore my last message- I found the revisions on the web-site. ========================================================================= Date: Sun, 30 Jan 2000 13:57:10 -0800 Reply-To: tannerb@vt.edu Sender: CS2604 discussion list From: Tanner Bonig Subject: EXIT command?? MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit The spec says that the program must take input from stdin (keyboard) and I know we are piping files.. but has anyone noticed there is no QUIT command... if we write this program to take input from the keyboard (as the spec says: "Your program will read from standard input a series of commands...") then how do we know when to quit the program... can we just write one in if we decided to do typed command testing (I personally hate just piping a file in...) Thanks Tanner ========================================================================= Date: Sun, 30 Jan 2000 14:19:55 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Peter Huene Subject: Re: EXIT command?? In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Input should be read from stdin until EOF is reached. To duplicate EOF when typing in commands try ^Z (Control-Z in Windows, probably different for nix, ^D? I can't remember). Hope this helps foo. Msg me on IRC if you still have questions about this. Later, Peter -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Tanner Bonig Sent: Sunday, January 30, 2000 4:57 PM To: CS2604@LISTSERV.VT.EDU Subject: EXIT command?? The spec says that the program must take input from stdin (keyboard) and I know we are piping files.. but has anyone noticed there is no QUIT command... if we write this program to take input from the keyboard (as the spec says: "Your program will read from standard input a series of commands...") then how do we know when to quit the program... can we just write one in if we decided to do typed command testing (I personally hate just piping a file in...) Thanks Tanner ========================================================================= Date: Sun, 30 Jan 2000 14:49:53 -0800 Reply-To: tannerb@vt.edu Sender: CS2604 discussion list From: Tanner Bonig Subject: Added bit to last question... MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit YES YES, I know about ctrl-c.. but won't that quit the program exactly where I hit ctrl-C.. which will not do memory clean up (any code I have after that line) besides, that and it seems awfully bad practice to make the user hit CTRL-C to exit your program!!! Tanner ========================================================================= Date: Sun, 30 Jan 2000 15:03:58 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jonathan Pryor Subject: Re: Added bit to last question... In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Under Unix, type Ctrl+D. Under Windows, type Ctrl+Z. These are effectively EOF characters, and will cause the input stream to close, allowing the program to quit normally. - Jon > -----Original Message----- > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > Tanner Bonig > Sent: Sunday, January 30, 2000 5:50 PM > To: CS2604@LISTSERV.VT.EDU > Subject: Added bit to last question... > > > YES YES, I know about ctrl-c.. but won't that quit the program > exactly where > I hit ctrl-C.. which will not do memory clean up (any code I have > after that > line) > > besides, that and it seems awfully bad practice to make the user > hit CTRL-C > to exit your program!!! > > > Tanner ========================================================================= Date: Sun, 30 Jan 2000 15:16:16 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Peter Huene Subject: Re: Added bit to last question... In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit I said ^Z, not Control-C momo =). Give it a try. And think of this as an automated system which would rarely have human interaction directly, and more likely have input and output almost always redirected. Later, Peter -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Tanner Bonig Sent: Sunday, January 30, 2000 5:50 PM To: CS2604@LISTSERV.VT.EDU Subject: Added bit to last question... YES YES, I know about ctrl-c.. but won't that quit the program exactly where I hit ctrl-C.. which will not do memory clean up (any code I have after that line) besides, that and it seems awfully bad practice to make the user hit CTRL-C to exit your program!!! Tanner ========================================================================= Date: Sun, 30 Jan 2000 15:23:54 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Peter Huene Subject: Re: Added bit to last question... In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Apologies tan, I just realized the listserv which either goes really fast, or crawls, hasn't posted my previous post yet. Although I did post it more than an hour ago... stupid system. Peter -----Original Message----- From: Peter Huene [mailto:phuene@vt.edu] Sent: Sunday, January 30, 2000 3:16 PM To: CS2604@LISTSERV.VT.EDU Subject: RE: Added bit to last question... I said ^Z, not Control-C momo =). Give it a try. And think of this as an automated system which would rarely have human interaction directly, and more likely have input and output almost always redirected. Later, Peter -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Tanner Bonig Sent: Sunday, January 30, 2000 5:50 PM To: CS2604@LISTSERV.VT.EDU Subject: Added bit to last question... YES YES, I know about ctrl-c.. but won't that quit the program exactly where I hit ctrl-C.. which will not do memory clean up (any code I have after that line) besides, that and it seems awfully bad practice to make the user hit CTRL-C to exit your program!!! Tanner ========================================================================= Date: Mon, 31 Jan 2000 11:29:15 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: project 1 In-Reply-To: <3.0.5.32.20000128191033.007b8680@mail.vt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII That is fine. Note that these are positions for FREE blocks (since that is what the linked list is storing). -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- On Fri, 28 Jan 2000, Kaiyan Xiao wrote: > Does anyone know if we can store the position handles in the linked list > nodes so we can traverse the memory pool? > > thanks, > Kaiyan > ========================================================================= Date: Mon, 31 Jan 2000 10:26:08 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Andy Strassburg Subject: Design Question In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Hi, I just want to make sure my design is crystal clear before I code this thing up. Can someone let me know what exactly the freeblock list is supposed to store? I know that it isn't supposed to store the actual memory pool space, but is it supposed to just store the length of the freeblock in each node that corresponds to a block? Also, should the memory pool start off as one big freeblock, and then when records get inserted, broken down to smaller freeblocks? Can someone clue me in? Please reply directly to me, because I don't want to pollute the listserv. Thanks in advance- Andy ========================================================================= Date: Mon, 31 Jan 2000 11:37:40 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Program arguments - solution! In-Reply-To: <003501bf6ab6$8957fba0$124723d0@ntc.offcampus.vt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII It is the same thing. You read from stdin. That means if you redirect when you actually invoke the program, the input comes from a file. If you don't redirect, it comes from the keyboard. Pretty flexible. :-) -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- On Sat, 29 Jan 2000, Saam Tariverdi wrote: > Do we have to redirect the input/output? In other words, can't we just > manually type in the commands from the prompt? > > Saam Tariverdi > > > > ----- Original Message ----- > From: Ago Sukanovic > To: > Sent: Saturday, January 29, 2000 5:46 PM > Subject: Program arguments - solution! > > > > For everybody that doesn't know how to redirect the program's stdin - > > stdout: > > If you are using Visual C++ 6.0 interface all you have to do is go to: > > Project -> Settings (Dialog box will pop up) > > There will be some tags on top. Click on the Debug tag. > > Category should be set to General. > > In the textbox under the Program Arguments enter something like: > > 256 26 output.txt > > where input.txt is an ASCII file containing the commands, and output.txt > > will receive all the output. > > > > This will work if you add both input.txt and output.txt to your project, > > otherwise you must be sure that both files are in the same directory as > the > > executable file. > > > > The above arguments will work even if you are testing your program from > the > > command line (MS-DOS). > > > > Ago Sukanovic > > > > P.S. For the guy that doesn't know how to create an ASCII file - switch > your > > major!!! > ========================================================================= Date: Mon, 31 Jan 2000 11:54:51 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Curator MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The GTA tells me that the curator should be up and running now for all sections. I STRONGLY urge you to try to submit something to "Project 0" in the near future -- WELL before you intend to submit Project 1. We won't make exceptions to the late policy because you couldn't get the curator to work -- you have more than a week now to get the kinks worked out. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Mon, 31 Jan 2000 14:19:28 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: UPE Tutoring Program (fwd) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ---------- Forwarded message ---------- Date: Mon, 31 Jan 2000 13:00:00 -0500 From: James Fogarty To: faculty@cs.vt.edu Subject: UPE Tutoring Program The UPE tutoring program will start this Wednesday, the 2nd, at 7:00, in McBryde 133 and will continue throughout the semester. Please announce the program to students in your 1000 and 2000 level courses. As in the past, the program will provide free individual tutoring to any students in these courses. Thank you, James Fogarty Chair, UPE Tutoring Program ========================================================================= Date: Mon, 31 Jan 2000 18:12:49 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: r e duffy Subject: GTA hours MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit at what time tomorrow (tuesday) will there be gtas in McB 128? thanks- duffy icq #17707214 ========================================================================= Date: Mon, 31 Jan 2000 18:21:22 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Pratima Aiyagari Subject: Re: GTA hours In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 9 - 10 : 30 : Min Liang 11 - 2 : Pratima 2:30 - 6 : Min Liang - Pratima On Mon, 31 Jan 2000, r e duffy wrote: > at what time tomorrow (tuesday) will there be gtas in McB 128? > > thanks- > duffy > > icq #17707214 > _/ _/_/ _/ _/_/ _/ _/_/_/_/ _/ _/ _/ _/ _/_/ _/ _/ _/_/ _/ _/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ ========================================================================= Date: Sun, 30 Jan 2000 21:13:52 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Garrett Berneche Subject: proper use of char* in get function MIME-version: 1.0 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_7N38bfPGnPqcUUBk2TCvNQ)" This is a multi-part message in MIME format. --Boundary_(ID_7N38bfPGnPqcUUBk2TCvNQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable the spec recomends that we use a get function that i believe should = appear similar to this. void get(char* space, int posHandle, int size){ /* assume int length is declared and is correctly set to the length of = the record/* for(int i =3D 0; i <=3D length; i++){ space[i] =3D MemoryPool[i + posHandle]; } } i am unsure wether this code is safe or not, i have a feeling that it = will run through memory sequentially, starting at the cell which space = points to and just overwrite values until the for loop exits. please = correct me if i am wrong... to avoid this problem i could pass a constant sized array into the = function that would be of big enough size to hold the record, but i am = not sure if this violates the spec.=20 any help with this would be greatly aprecciated thank you=20 garrett =20 --Boundary_(ID_7N38bfPGnPqcUUBk2TCvNQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
the spec recomends that we use a get = function that=20 i believe should appear similar to this.
 
void get(char* space, int posHandle, = int=20 size){
/* assume int length is declared and is = correctly=20 set to the length of the record/*
 
    for(int i =3D 0; i = <=3D length;=20 i++){
        space[i] =3D = MemoryPool[i +=20 posHandle];
    }
}
 
i am unsure wether this code is safe or = not, i have=20 a feeling that it will run through memory sequentially, starting = at the=20 cell which space points to and just overwrite = values until the=20 for loop exits. please correct me if i=20 am wrong...
 
to avoid this problem i could pass = a constant=20 sized array into the function that would be of big enough size to hold = the=20 record, but i am not sure if this violates the spec.
 
any help with this would be greatly=20 aprecciated
 
thank you
garrett
 
 
 
--Boundary_(ID_7N38bfPGnPqcUUBk2TCvNQ)-- ========================================================================= Date: Mon, 31 Jan 2000 21:34:36 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Matt Stec Subject: dynamically alloc. array deletion Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Ok... I'm having trouble deleting dynamically allocated arrays. I have a feeling this is something very obvious...but I've been staring at it for awhile and have managed to confuse myself. Any help is appreciated. Given the following function: int function(int argument){ int* array = new int[argument]; for(int i=0; i <= argument; i++) array[i] = i; delete [] array; return 0; } and main: void main(){ int x = 3; char* A = new char[x]; A[0] = 'a'; A[1] = 'b'; A[2] = 'c'; delete [ ] A; int* y = new int[x]; delete [ ] y; int z = function(9); } the deletion of A and y seems to go fine. But the deletion of the array inside of function is giving me a debug error. thanks...matt ========================================================================= Date: Mon, 31 Jan 2000 21:55:57 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Peter Huene Subject: Re: dynamically alloc. array deletion In-Reply-To: <3.0.6.32.20000131213436.007b1490@mail.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Check your for(). You're going from 0 to argument in the loop, while you're allocating "argument" number of ints in the array. Hence the array goes from 0 to (argument - 1) in indices. Try for(int i = 0; i < argument; i++) { ... } delete [] array; Regards, Peter Huene -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Matt Stec Sent: Monday, January 31, 2000 9:35 PM To: CS2604@LISTSERV.VT.EDU Subject: dynamically alloc. array deletion Ok... I'm having trouble deleting dynamically allocated arrays. I have a feeling this is something very obvious...but I've been staring at it for awhile and have managed to confuse myself. Any help is appreciated. Given the following function: int function(int argument){ int* array = new int[argument]; for(int i=0; i <= argument; i++) array[i] = i; delete [] array; return 0; } and main: void main(){ int x = 3; char* A = new char[x]; A[0] = 'a'; A[1] = 'b'; A[2] = 'c'; delete [ ] A; int* y = new int[x]; delete [ ] y; int z = function(9); } the deletion of A and y seems to go fine. But the deletion of the array inside of function is giving me a debug error. thanks...matt ========================================================================= Date: Mon, 31 Jan 2000 21:56:14 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jonathan Pryor Subject: Re: dynamically alloc. array deletion In-Reply-To: <3.0.6.32.20000131213436.007b1490@mail.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit ``function'' has an off-by-one error in the loop. Ask yourself, if I create an array of size ``n'', what are the valid indexes into that array? const int SIZE = 5; char a[SIZE]; a[SIZE] = ' '; // legal? Look closely at ``function'', and you should see the problem... - Jon > -----Original Message----- > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > Matt Stec > Sent: Monday, January 31, 2000 9:35 PM > To: CS2604@LISTSERV.VT.EDU > Subject: dynamically alloc. array deletion > > > Ok... > > I'm having trouble deleting dynamically allocated arrays. I have > a feeling > this is something very obvious...but I've been staring at it for > awhile and > have managed to confuse myself. Any help is appreciated. > > Given the following function: > > int function(int argument){ > int* array = new int[argument]; > for(int i=0; i <= argument; i++) > array[i] = i; > delete [] array; > return 0; > } > > and main: > > void main(){ > int x = 3; > char* A = new char[x]; > A[0] = 'a'; > A[1] = 'b'; > A[2] = 'c'; > delete [ ] A; > > int* y = new int[x]; > delete [ ] y; > > int z = function(9); > } > > the deletion of A and y seems to go fine. But the deletion of the array > inside of function is giving me a debug error. > > thanks...matt