My C homework

[Piru]

Also, there are various things to consider for "good" implementation of the stage three:

- It should not be limited to some fixed size maximum word length.
- It should not get exponentally slower when number of different words grows.

However, these are points for the advanced class. I have such implementation ready and I'll provide it later.

[Piru]

@Karlos

A hash map satisfies the second point nicely. That would be trivial to implement in C++/STL but it requires some thinking about to do from first principles in C. But then, that is the aim of the exercise.
Certainly you don't want to be iterating over the entire list of known words for each word read.

True. There's IMO a better data structure for this particular case: a binary tree. Hash tables are boring... ;-)

[Piru]

Ah indeed, this would be the perfect use for a trie ;-)

[Piru]

That's not bad at all.

[Piru]

When the source text file contains words that might have some european characters it causes the program to think one word is several.

Assuming character set ISO 8859-1 (latin1), here is a routine that should work relatively well:

Code: [Select]


int isalpha_int(unsigned char c)
{
        c &= ~0x20;
        return (c >= 'A' && c <= 'Z') ||
               (c >= 192 && c <= 222 && c != 215);
}


[Piru]

I just wonder why you choose C, as that a language is old and on it's way out.

How is age of the language relevant? Regardless, C is not going anywhere.

IMO C is probably the best choice for overall programming skills. When you know C, it is easy to extend your knowlege to other languages.

[Piru]

@guru-666

You guy's know that python has this kind of function built in already.

That doesn't help when learning C though.

[Piru]

@mel_zoom

You got it right there. I think you should first implement it using the slow (list) method. When that works you can look into some faster ways to manage the words, such as trie, binary tree or hash table.

If you keep your program well structured, and separate the "lookup" and "insert" into separate routines you should have no problems changing the implementation when/if desired.

I do this quite a lot: I get all the simpler parts going first, and those work okay I tackle the bigger problem. It is easy to overwhelm yourself with tons of work, it helps if you keep things organized, and don't try to solve everything at once.

In my solution to stage 3 I have both binary tree and trie routines, toggleable with a #define. I could code the simple binary tree out of memory, and since I had set of simple functions for it, it was trivial to add conditional trie routines later on.

I guess what I am trying to say is: Don't be too hard on yourself and don't demand perfection from the beginning. Allow yourself to use simple(r) solutions, it is enough to recognize that better solutions exist. You can always improve the code after the basics work. (And in case you can't get the advanced solution working, at least you have the simpler one that DOES ;-))