Wyatt's suggestions: He says: "would a title ever be this long?". I say: What are you going to do if it is? He talks about an end tag. I see a few problems with this: 1. If you already have the length of the message, why do you need an end tag? 2. If you just go ahead searching for an end tag, then, what happens if you find an end tag in the middle of the text? 3. You'll have to update the message length every time the message is edited. Again, about the message length. He says (and I know) that a message will never be longer than 4 billion characters. But, you should never restrict what a program can do. If you really want a world-class app, it normally has no restrictions except the ones imposed by memory. Many, many Unix apps had lots of limits. They wouldn't work with bigger files. Notepad (in Windows) couldn't work with files bigger than 64K for a long time. (That was for a different reason, anyway. I don't know if it still does) This was because memory was scarce and that was necessary. It isn't now. Let the maximum size of the message be dictated by the file system (how big a file can be) and memory (how much of memory can be allocated). You're writing a C++ app and Wyatt uses FILE *, which is distinctly a C thing. Don't use that!! The C++ way of doing it is streams. You can google for and read about them, if you haven't. (ifstream, ofstream) Binary and text: Normally, each and every Unix app opens a file as text and not binary. In fact the fopen(3) implementation on my system does not even mention the "b" mode except as a footnote. It says: The mode string can also include the letter ``b'' either as a last character or as a character between the characters in any of the two-character strings described above. This is strictly for compatibility with ANSI X3.159-1989 (``ANSI C'') and has no effect; the ``b'' is ignored on all POSIX conforming systems, including Linux. (Other systems may treat text files and binary files differently, and adding the ``b'' may be a good idea if you do I/O to a binary file and expect that your program may be ported to non-Unix environments.) That settles it if you're opening a file (using fopen, in C) on Linux. Do NOT get into the habit of using binary mode on a Unix system (primarily because it's useless as the above paragraph suggests). If you know how to use the text mode, it doesn't cause bugs. Binary input and output is done using fread and fwrite (or even read and write) in C, on Linux (and probably other POSIX conforming systems). Wyatt seems to use a Windows system (he assumes an int is 2 bytes). If you're programming on a Windows system (which I don't think you are), then, you can think about his suggestions. I don't know why, but he uses waaaay too many bitwise operators. I'm not criticizing him. He might have a reason. But, they are normally not used unless you're playing around with the bits (which is when they are EXTERMELY useful). Er, I seem to have shot down every suggestion Wyatt made. Sorry, Wyatt. There are some differences between programming for Unix and Windows. I think this is the reason I had to say what I did. ------ Matt's line counter: I like the fact that he uses strings. I recommend using them too. I doubt if the "std::ios::binary" makes any difference on a Linux system. I don't see anything wrong with the code, except for the assumption that a message takes only one line. There are (supposedly) better ways of parsing command line options, see getopt(3). (You do know what I'm talking about when I say getopt(3), don't you. It means, type "man 3 getopt" on the command-line). The idea of one program to do everything (in this context) is good. ------ My recommendations: * No limits. There should be no arbitrary numbers (called "magic" numbers) in your program. They are very hard to understand, believe me. * Use string class of C++. It's very useful. You won't have to worry about message size limit (as in LavaDevil's program). There is a small performance lag, but in a project of this scale, it shouldn't matter. Don't mess around with character arrays. If you don't want to take the easy way out and use strings, then, learn about new and delete and use character pointers. This is the C way (well, using malloc and free) and it's very VERY useful. Still no static arrays (I mean char abc[100]) * Think about a suitable format for the text. Something like this shouldn't be bad: ---%<--->%--- Title: .... Date: .... % Message goes here, where each line in the message is prefixed by a "%" % or any suitable prefix. The advantage of this is that the delimiter, % ie, "---%<--->%---" (or anything else) cannot appear in the middle of % the text to confuse the program. That is, even if the user types the % delimiter on a seperate line, it'll be prefixed with the prefix (%), % like so: % ---%<--->%--- % So no worries about it. ---%<--->%--- Title: .... Date: .... % Next message goes here ... The actual body of the message is the part prefixed by "% ". Yes, I know, it (---%<...) is exactly like Wyatt's end tag, but, it's a delimiter. There are many advantages of such a format. One of them is detailed in the body of the first message (ie, delimiter in text). The next advantage is that your "count" function becomes as simple as going through the file, matching lines with "---%<--->%---", and counting the number of such lines. (In fact, it's easier. Think about it.) When printing out the message, you can read it one line at a time and stop reading when you reach a line with no % prefix, or an empty line, whichever you prefer. See, no message length needed! * One last suggestion: The user config need not have what to display on startup. Well, you could have it, but it's not needed. A script will call grim (at startup) and it can pass the required parameters. Arvind