Learning C++
After reading a paper about how C++ should be taught. I was motivated to try and get the following construction:
string s; while(cin >> s){ cout << s << '\n'; }
to read one line of '\n' terminated input at a time.
But cin is eating the newlines and whitespace, and splitting there too.
My C++ book is telling me that that is what the >> operator is supposed to do (ignore leading whitespace, read a whitespace delimited word). And that if I want to read a line I should use the getline() function.
and indeed getline does everything I want:
string s; while(getline(cin,s,'\n')){ cout << s << '\n'; }
But then the >> operator is useless, because "split words on whitespace", when whitespace is not configurable is useless...
Better programs, but better how?
I don't know if the above has anything to do with anything, but it tells me one thing: you can't tell if a language is good based on a 3 line program and some randomly selected library routine.
Picking real programs I use, let's choose a couple of email clients: thunderbird (C++), mutt (C) and squirrelmail (PHP). Now let's compare them.
Criteria? (better how? part 2)
What are the criteria for comparison. This question is about as difficult as our original goal of telling how good a particular language is.
I'll look at it through the narrow lens of wanting to use these programs to develop my own email client. Something I am somewhat interested in doing.
On the other hand I'll also be looking through the wide lens of wanting to use these programs to read and write mail. Something I do every day.
The first criteria is our main one. Why? Because you can't tell how good a language is by the quality of programs written in it. At least not directly. That is an indirect measure. Whatever you can do in one language you can technically do in another. At least if you want it bad enough, and are willing to do the hacking.
So being able to use the code for another purpose tells you two main things. Namely: 1. how readable and understandable the code is, and 2. how structured vs inbred and non-orthogonal it is.
versions
Specifically I'm looking at mutt 1.5.something, thunderbird 2 (the last version before the unbearable suckiness of 3), and whatever version of squirrelmail I'm running on my server because it just works and I don't ever have to touch it.
The source code
Mutt is a couple of megs gzipped, and about 200 .c and .h files in total.
Thunderbird is 37 megs of bz2, and it's just finished uncompressing after what seems like an appreciable part of an hour. I don't know if the command line to grep all the cpp files will ever terminate. Let's just say it is big.
Squirrelmail lies on my mail server. The source is what I run. It is an html/script as all php is, but it's still got some structure to it. And it's a little over 200 php files, excluding themes and locales.
Oh ok the count is finally in, thunderbird has 4617 .cpp files. Who knows how much of anything else is lying around in its folders.
Oh and while we're at it squirrelmail is under a meg when gzipped.
imap
I'm going to be focusing on the code to deal with imap. IMAP is a protocol for accessing multiple folders of email on a remote server.
The main reason I am focusing on this back end issue is that these programs vary in their amount of graphical user interface. Thunderbird is a full GUI, WYSIWOG, windows, point and drag, experience. Mutt is a version of vi that only reads mail. Squirrelmail takes mail and converts it to and from html.
And while you can compare apples, pork chops and tooth picks, I would rather not.
Orders of magnitude?
How much code are we talking about? The grossest of grep's tells me that there is about 3k lines of imap code in squirrelmail, 7k in mutt and 40k in thunderbird. In the last two cases this is .c and .h files, in the first case it is .php files.
So we have about an order of magnitude.
For mozilla over half the code is contained in the 3 or 4 largest .cpp files. For mutt the same applies to the 2 or 3 largest .c files, and for squirrelmail the 3 top files make up almost 90% of the code.
Baby steps
The first thing to do is start out slow. How slow? Hello world? No that is too slow. That has nothing to do with IMAP. We'll have to do much more than that, but still much less than the whole thing.
We'll try the following: connect to the server, authenticate, and find out how many messages we have in our inbox.
Is this the least we can do? No. The least we can do is nothing. But this is about the least useful thing we can do, that is not entirely useless.
This site best viewed with Lynx or Mozilla or Konqueror or any standards compliant browser!
and also. The all-powerful ed has also contributed!.