*shrug*
I'm in; it sounds like fun, but I do have some suggestions.
Let's start small; all the way around. We have several people who've joined. Let's start a simple first attempt with those guys and a simple project. Actually playing the game will attract more attention than just talking about it. While playing the first game, rotating off a list unless someone hasn't posted within 24 hours where upon that name is skipped, people can sign up for the next round.
Let's start with a profile. For example, a great C++ jumping off would be something like what I've posted here. It covers a lot of ground fast.
Start a new post noting that round one has started with the rotation list. If the discussion goes on to long, the interest will drop to those who've not bothered to follow everything.
Code:
#include <algorithm>
#include <cmath>
#include <cstdlib>
#include <fstream>
#include <iostream>
#include <sstream>
#include <string>
int main
(
int argc
, char ** argv
)
{
return(0);
}
sorting is always classic (especially if you don't say which algo in advance)
If this is done in C++, this may be perfect.
Compute word frequencies in a file, output sorted list.
My vote is for this; at least, for a first attempt.
Compute word to document associations in a directory of files (inverted index)
This can't be done without stepping outside of C++ standard libraries unless a list of files is provided.
An addition may only be appended to the source code; changing is not allowed.
We will never be able to fix broken code; one bad addition destroys the game. It doesn't have to be a logic bug to break source you know.
The use of the "comma operator" is forbidden. Comma's are allowed of course in function definitions, function calls and to declare more than one variable on a single line.
We can police ourselves easier without fine grained rules like that. We all know what one statement means; we don't need to get complicated. For example, if I start a statement with any expression evaluating to an `lvalue', I can chain any number of expressions using the logic operators by forcing those expressions to evaluate to a value.
So, let's just stick with "one simple/complex statement", accounting for the constructs necessary to do something useful with control constructs in one shot instead of three. Also, if you don't allow some complex additions, initializing some variables is right out.
Comments are not allowed, nor is communicating the purpose of certain additions in any other method to the other participants.
Okay, so no one will follow my code if I don't want them to follow it. I'm out.
Is that seriously what you want? Again, one participant has a bad day and garages the game just because he is cranky making the addition as convoluted as possible?
How about "self describing code only" or "consider changing the addition if a comment would be necessary".
That's silly. If you consider that creating a macro would take multiple expressions, no one could game that path, and using the macro would also count towards the "one simple/complex statement" rule.
At every addition, one may also add a single "#include" statement any place in the code.
That's actually not bad, but I think if we stick to the standard library and other rules simply allowing free additions to the include list is fine.
Any person making an addition that makes it impossible to successfully complete the application because of a logic error, the person loses and no longer participates; the application is restored to the version before his last change and the game continues. Syntax errors are exempted from this for typo's and the like.
Again, not a bad rule, but I don't want to play that kind of game, and with the above referenced "no communication" rule I can force most people following me to lose.
If we our going to play something like this, can't we just have a little fun with it?
Why not? Isn't this standard compliant?
That code can compile, but why impose such bad design decisions?
It also prevents a lot of class and template conventions.
Soma
