Programming Forums - Need some help

Programming Forums (http://www.programmingforums.org/forumindex.php)

- C (http://www.programmingforums.org/forum60.html)

- - Need some help (http://www.programmingforums.org/showthread.php?t=11335)

Hello I'm newbie in C programming. Iwant to make a simple contact book that have add, delete, edit, and display function. 2 out of 4 i've done which is add and delete. So I need some help from all of you in edit and list function. Here is my function for add and delete. I refer this from acidburn code and changed it a little bit and i don't want to use ctype.h because not familiar with it yet.

Code:

void Add()

{

char opt1;

do

{

Contactbook = fopen("Contactbook.txt","a+");

printf("Enter his/her Name:\n");

scanf("%s", contactbook.name);

printf("Enter his/her Birthday:\n");

scanf("%s", contactbook.birthday);

printf("Enter his/her Handphone No:\n");

scanf("%s", contactbook.hp);

printf("Enter his/her Address:\n");

scanf("%s", contactbook.address);

printf("Enter his/her Occupation\n");

scanf("%s", contactbook.occupation);

fprintf(Contactbook, "%s %s %s %s %s\n", contactbook.name, 

contactbook.birthday, contactbook.hp, contactbook.address, 

contactbook.occupation);

fclose(Contactbook);

 

printf("To Continue using this program type Y/y");

scanf("%c", &opt1);

}

}

 

void Del()

{

char opt2;

char Tar [SIZE];

int match = 0;

temp = fopen("temp.txt", "w");

if((Contactbook = fopen("Contactbook.txt","r")) == NULL)

printf("----The file is empty----\n");

else

printf("Enter his/her name:");

gets(Tar);

 

while (!feof(Contactbook))

{

fscanf(Contactbook,"%s %s %s %s %s", 

contactbook.name, contactbook.birthday, contactbook.hp, 

contactbook.address, contactbook.occupation);

if(feof(Contactbook))

break;

if(strcmp(Tar, contactbook.name) !=0)

fprintf(temp,"%s %s %s %s %s\n", contactbook.name, 

contactbook.birthday, contactbook.hp, contactbook.address, 

contactbook.occupation);

else

{

match = 1;

}

if (!match)

{

printf("The name does not exist\n");

printf("or it might had been deleted\n");

}

 

fclose(Contactbook);

fclose(temp);

remove("Contactbook.txt");

rename("temp.txt","Contacbook.txt");

 

}

So i need some help on edit and list function. At 1st i think i want to use the same code as delete but change remove to rename but it can't be done that's way. So your helps are highly appreciated. Ok. Thanks

I don't know C, and I didn't even read your question, but if you want responses, put your code in CODE tags.

It's still barely readable - there's no formatting. However, I did pick out something: using a space as a delimiter is a bad idea. Use something that you don't expect in a name or address, such as a pipe ( | ) to separate values. If I was a computer and I encountered the following string:

John Smith 12/11/94 291023943823 The Bungalow, London Road, Bristol AB1 2CD Programmer

I wouldn't know what was what. You'd need some damn clever algorithm to split things up there.

You also need to sort out some sort of standardization: how should dates, names, addresses etc. be stored? I personally prefer the YYYY-MM-DD format when storing dates in a text file. Will you store names as First Last or Last, First? Should addresses have commas between each "line"? Think about how you're going to store the data so you can pull it back up exactly as you saved it.

You may wish to look into a standard data container, such as a database or XML. They provide facilities to separate things up and reference them with each other without a lot of effort.

Quote:

Originally Posted by Ooble (Post 114403)

John Smith 12/11/94 291023943823 The Bungalow, London Road, Bristol AB1 2CD Programmer

Obviously he doesn't want to look into a standard data container or a database, he's having fun and learning to program with this as a project. C'mon, where's your sense of adventure?

OK, mine's off on a walkabout, but he's still got his! :)

You'll need to set up a standard format - how you want the fields for each record to be written to the file (the order), how you want each field to be sized in char's, and how you want each to be displayed on screen.

Normally, (as I understand it), you'd have an array of pointers for each string entry for variable length strings, which saves space - critical for a large database.

For a small contact book, and your experience level, I'd go with fixed fields. So names get 30 char's, dates get 06/09/16 = 8 char's, cell phone #'s get 123-456-7890 = either 10 or 12 if you include the hyphen in each phone field.

After you're squared away with what you want there, then there's 3 ways to work the data: 1) load the data into a linked list 2) load the data into an array or 3) just use the file.

List is nice, because it can grow or shrink, easily. Arrays are nice because you really learn a lot about using them better., and the file method is nice because it combines the best of the other two, at the cost of being a bit slower.

I'd recommend using the method you want to work with, and roll your own as much as possible. You'll learn a lot, and have maximum fun, also.

John Smith 12/11/94 291023943823 The Bungalow, London Road, Bristol AB1 2CD Programmer

Quote:

I wouldn't know what was what. You'd need some damn clever algorithm to split things up there.

There's already "something" that is normally used to split up the fields. Either they're fixed fields, so their position relative to the first char in the record/field is the key, or a combination of record separators and field separators are used. Look at your ASCII chart, on the low end of the scale for "RS" and "FS". Depending on your editor and font, they may or may not display (notepad), or may not display, but cause the editor to put subsequent data on another line, like a newline acts (wordpad).

I wouldn't recommend using "pipes". Save them for the plumber. :)

Once you decide where you want to work the data from, and what you want the standards to be, then we can be more helpful. One suggestion - give each record a unique record number - it just makes things easier down the road.

Great project!

Adak

I don't understand your comment regarding the 'possible' use of a file. :confused: I also disagree with including a record number. I also don't understand your comment about using pointers to save space. You have to save the data somewhere (that file) and to save a pointer would just increase the necessary space. With variable length records and a need to access individual records in the file directly, one might use pointers (positional indexes, actually). It's hardly a novice's technique.

This seems like a good place to get on the soapbox, as well as offer some opinions about how one would implement this project. There are any number of ways to implement it, so I will tailor my opinions, mostly, to implementation by a novice.

The soapbox part is this: novices almost always fail to design the project before beginning the coding. Why should you? You know what an address book is, right? Sure you do. The system does not. You are going to have to explain it in a very dumbed down manner. The first step in achieving this is to explain it to yourself in your natural language, in detail. To do otherwise creates a situation that is fraught with peril. You will have glitches out the kazoo and you will forget forty-leben considerations that will wind up breaking your program. (Never use f/s/scanf without checking its return – you’ll sail off the end of the world, sooner rather than later.)

Specify, to yourself, precisely what an address book is. It’s a structured collection of data of various forms and various sizes. C does not allow one to put things like this in one array. Arrays hold elements that are all of one type. The word, structure, is key, however. One can make an array of structures. One down.

How will the structure be implemented, when in memory, to accomplish the various manipulations? How will the structures be saved to a file, which is a cow with a different spot pattern? Will you shoot for maximum storage efficiency, or maximum ease of access? This will determine whether you use fixed- or variable-length records.

Define the essential structure. Let us say that it is Last Name, First Name, Street Address, Secondary Address (P.O. Box?), City, State, Postal Code, Telephone Number, and whatever else you like, maybe an email address. Now, let’s decide how that’s represented in both memory and in the file, and describe that. Because this is from the viewpoint of a novice, let us decry the use of dynamic memory allocation for the in-memory representation.

Next, let’s define the user interface. What can the user do? Add, Edit, Delete, and Display? Fine. How about Sort (a good reason not to have record numbers as part of the information, which isn't the same thing as having a unique key)? Surely most address books aren’t generated in sorted order, but it definitely makes it easier to access the information later, wouldn’t you say?

One doesn’t add to a linked list in the same way one adds to an array. It’s time to decide how the collection of records will be implemented in memory, as opposed to just the structure of the record. Personally, I would opt for a linked list. Even if one opts for a linked list, one might approach it differently. Consider just the sort. Do you want to move the whole dam’ record in a sort, or would you just like to sort pointers and use them to control the order of output for display (or, even, output to the file).

About the file. The use of fixed length fields will give you the capability of random access to records with some simple arithmetic. Are you really prepared to introduce seeks and tells into this exercise? Personally, were I a novice, I would opt for variable length records and do my searching and other manipulations in memory. Would I use invisible characters such as ASCII field and record separators? No. I would use separating mechanisms that would produce a readable file when dumped, raw, to the display. This ability would be a boon in checking things out, along the way. Were I a guru, rather than a novice, I might well choose to do otherwise.

Consider that you are not breaking new ground. What are the simplest approaches that other people tend to use? There is the ubiquitous .csv file, which can port directly into useful things like spreadsheets. It isn’t a perfect approach (if one uses commas for separators, how does one deal with commas in the data?). Many people have successfully addressed this problem.

I would recommend that you back up and try this approach. Should you do that, and tell us how you have decided to do it, then we will be able to make tons of suggestions for properly implementing your decisions, should you happen to stumble or run into a wall along the way.

There's a heap of good advice wrapped up in Dawei's last post.

A basic trap for newbies is to start with a simple description (eg "I want an address book that I can add, delete edit, and display entries from") and then cut code without thinking about some basic things (eg what each entry should contain). Asking for tips to improve the code or (although it hasn't happened this time) asking why it doesn't work tends to be counter-productive. Why? Because there are approximately a million and one ways of specifying what a contact book should contain, what you want to do with each entry, what you want to do with a collection of entries, how you want to save or retrieve them, etc etc. People who might try to help can't understand what you're trying to achieve before you describe it in a fair amount of detail. So, the most common response is that we look at threads like this one and move on.

Imagine you were a architect and I came to you for free advice saying "I want a house", but don't give you any information such as how many people would live in it, how many bedrooms, how many bathrooms, how many living areas, etc. You would probably suggest I need to go away and think about what I really want. It's the same here. A house needs to be designed to some level of detail before it can be built to anyone's satisfaction, and basic functional requirements need to be specified before it can be designed. Similarly, functional requirements of software need to be described in some detail before it can be designed, and the design is needed before the code can be written. By writing code first, you are like the house builder trying to put up the roof of a house before erecting the walls.

Here's an example. We'll presume that you just can't wait to get to the actual coding. Then, break up your design. Just don't get ahead of yourself.

There are three distinct hierarchical things associated with most contact lists. The collection, or Book, a member of that collection, or Record, and the parts of the record, or Fields. You can call those things 'objects' if you like, even though you are using C. Define their memory representation, bearing in mind all the while that there will be an external storage representation, also, whether you use a serialization technique or just roll your own.

Define those things along the lines discussed above. Let us say that you have decided to treat the book as a linked-list of records, and that the user will be able to load, add, edit, delete, display, sort, and save. At this point, if you're straining to write some code, and you're not drawing a paycheck for it, go ahead and write a little bit.

Eventually (right away, actually), you're going to have to define some user interface. Are you going to give the user a list of numbers and instruct him or her to select (1) for read the file, (2) for insert, etc.? Why not anticipate writing a little extra code so that he/she may enter a unique left subset of the command? 'L' for load, 'D' for delete, and so forth. Pamper your user; use things that make sense. Don't pamper your user with input methods that allow him/her to break your application.

At any rate, take a break if you must, and pound out some very minimal code. Maybe something like this:

#include <stdio.h>

#include <string.h>



typedef struct sBook *pBook;

typedef struct sRecord *pRecord;



typedef struct sBook

{

   pRecord head;

   int   numRecords;

   /* Would you want a tail pointer? */

   pRecord tail;

   /* Maybe a path to the file if you have multiple books? */

   char  bookName [255]; 

} Book;



typedef struct sRecord

{

   char last [20];

   char first [20];

   char street [30];

   char address [30];

   char city [20];

   char state [15];

   /* Postal codes are usually best treated as strings, not integers */

   /* Don't forget room for the terminating zero */

   char zip [6];

   char plusFour [5];

   char phone [20];

   char email [30];



   /* Handling support.  One could put these in a separate structure for */

   /* more efficient handling (sorting, etc.). */



   pBook parent;

   pRecord next;

   /* Make things a little easier, down the line */

   pRecord prev;

   /* In a separate structure, you'd want a */

   pRecord data; /* The current item */



} Record;



#define INITIALSIZE 50



/* Anticipated function declarations here */



int main (int argc, char *argv [])

{

   int i;

   /* Make a book.  No dynamic allocation until you're ready */

   Book firstBook;

   Record contacts [INITIALSIZE];

   /*

   The record storage exists, but it's empty.  Personally, I wouldn't

   point to it yet

   */

   firstBook.head = NULL;

   firstBook.tail = firstBook.head;

   firstBook.numRecords = 0;

   /* 

   No need for strncpy for this instruction.  However, if you decided to use

   it, you'd need to consider the terminal zero situation.  You could write,

   strncpy (firstBook.bookName, "", 1), or even just guarantee a null string

   with firstBook.bookName [0] = '\0';

   */

   strcpy (firstBook.bookName, "");

   /*

   Initialize the records to a 'safe' state (presuming you know to check your

   pointers for a NULL value).  This is repetetive because we're not getting

   them one at a time through dynamic allocation.

   */

   for (i = 0; i < INITIALSIZE; ++i)

   {

      contacts [i].parent = NULL;

      contacts [i].next = NULL;

      contacts [i].prev = NULL;

      contacts [i].data = NULL;

   }



   return 0;

}

Unfortunately, that isn't very satisfying. Looking at it might help you formulate the design of your insert and show functions, though, so you can carefully describe them in your native language. Doing that could very well cause you to realize something is missing in the definition (or that you have too much).

What you want to do immediately is write those two functions so that you can actually see something work. Wrong approach. You can't possibly write them until you design the user interface.

It's unfortunate that instant gratification and top-notch performance aren't compatible, but there you have it. I hope this helps.

Quote:

Originally Posted by DaWei (Post 114442)

Possible use of a file:
The data wouldn't be loaded into a long list or large array. Only a couple of records at a time would be in memory.

Record Numbers:
For sorting by index, it's been handy, for me.

Pointer Indicies:
Not a real beginner's technique, but he might take a liking to it quickly and make that jump. Just mentioned it, not recommending it for him. Wouldn't be used if he went directly from the file. That would be too much.

I recommended fixed length fields for him.

Adak