Thread: Anybody up for a game?

*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".

Macro's are not allowed.

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

cout << "Ok guys, the next few lines should recursively call the aggregation function while accumulating the total in the variable 'total'. Don't forget to check the base case of an empty structure and initialize the memory for the return data\n";

I'm out. Those rules ensure failure. If that is the point of the the program then you do not even need to start to prove it is not going to end well.

Originally Posted by VirtualAce

I'm out. Those rules ensure failure. If that is the point of the the program then you do not even need to start to prove it is not going to end well.

I posted these rules so that people would comment on it so that we could improve it. It was a proposal. Rather than saying "no, they suck, I'm out" you could say what you don't like so that it can be worked on.

Phantomotap; I'm quite happy you started it, I've been too busy the last couple of days to start it. But I do believe the rules aren't quite clear yet. Well, read my post in the other thread for the most important thing: I think it's no fun unless you can only add to the bottom. Of course corrections are different and can be done anywhere, but additions definitely shouldn't.

Rather than saying "no, they suck, I'm out" you could say what you don't like so that it can be worked on.

If you will carefully review my post you will find that I did not use any of those words. I merely stated I'm not going to contribute and gave my reasons for it. I do not have time to waste on various projects that I feel, for one reason or another, are DOA from the word go. I feel you have limited the success of the project by creating rules that are more for an obfuscated code contest than a group programming project. But perhaps I misunderstood the point of the project in the first place.