Mini project suggestions

[Michael Strorm]

Hi,
I'm in the middle of "teaching" myself C++. Having skimmed some of
the "Teach Yourself C++ in 21 Days" book, I got a feel for the
language, at least. Then I bought "The C++ Programming Language"
because it was on offer, and I'd have ended up buying it at some stage
anyway.
Skimmed some of that, but there's too much detail (for now) and I
know I won't take it in if I don't get some practice in actually
*writing* programs in C++. I'm getting the very strong impression that
(much more so than in C) learning to write "proper" C++ programs can't
just be done through short question exercises.
To get to the point, I'm wanting to start a moderately-sized
project that would take a week (working full time on it, which I won't
be ) to do reasonably, cover a decent subset of the language, be
interesting to do, and workable under (say) gcc on Linux (without too
much nonstandard code). It'd also be interesting to get some practice
in software design in there.
So, I'd be interested to get some suggestions, because I feel like
doing *something* with all this knowledge (and more importantly,
finding out what I don't know well). Thanks!

Michael Strorm
(e-mail address removed)

 

[Mike Wahler]

Hi,
I'm in the middle of "teaching" myself C++. Having skimmed some of
the "Teach Yourself C++ in 21 Days" book, I got a feel for the
language, at least. Then I bought "The C++ Programming Language"
because it was on offer, and I'd have ended up buying it at some stage
anyway.

Yes, as your knowledge grows, I think you'll find this
book quite valuable. Make sure it's the 3rd or 'special'
edition though. Previous additions are essentially
obsolete.

Another very good book, especially for those who have
previous experience with other languages, is Koenig
& Moo's "Accelerated C++". www.acceleratedcpp.com

Skimmed some of that, but there's too much detail (for now)

Yes, it's infoage ratio is quite dense. I also needed
to supplement it with other 'lighter' material when learning
C++.

and I
know I won't take it in if I don't get some practice in actually
*writing* programs in C++.

Yes, good that you realize that. Learn by doing.

I'm getting the very strong impression that
(much more so than in C) learning to write "proper" C++ programs can't
just be done through short question exercises.

Short exercises are good start, especially to prove to
yourself you understand a particular concept(s).

To get to the point, I'm wanting to start a moderately-sized
project that would take a week (working full time on it, which I won't
be )

Don't be too optimistic with your time estimates. Don't
worry if something takes far longer than you expect. Even
for professionals, one of the most difficult tasks is making
(and meeting!) time estimates. Only practice and experience
will help with this. And having built up a 'code base' of
useful functions helps a lot toward 'speed of development'.
The concept of code reuse. When writing a function, keep
in mind "can this be 'generalized' to be useful in other
contexts?" This won't always be the case, but often is,
given a bit of forethought before deciding e.g. what
the parameters should be, if any. E.g. if you write a
function to output the contents of an object, you could
'hard code' it to use 'cout', or you could defined a
parameter of type std:stream&, in which case the
function could operate upon a file (std:fstream) as
well as on 'cout'.

to do reasonably, cover a decent subset of the language, be
interesting to do,

Only you can know what you find 'interesting'. E.g. many
are eager to write 'cool graphics games' etc. (which btw
is a far too advanced topic when learning the language,
especially since you'll need platform-specific 'extensions'
and special purpose libraries). E.g. Games don't interest
me at all, graphical or otherwise -- I have more fun with
databases and text manipulation. But that's just me.

and workable under (say) gcc on Linux (without too
much nonstandard code).

When learning, you should stay away from all nonstandard
(e.g. platform-specific) constructs. Learn the language
first. Then it matters not what your platform is (C++
is a 'platform-independent' language.)

It'd also be interesting to get some practice
in software design in there.

Design isn't really topical here, but we can help you
organize your code to best take advantage of the
language's power, prevent common errors etc. Software
design itself would be better discussed in groups such
as comp.programming and/or comp.algorithms, etc.
Often specific algorithm categories have their own
groups, e.g. cryptography.

So, I'd be interested to get some suggestions, because I feel like
doing *something* with all this knowledge

Yes, it is very satisfying to actually build something
useful and/or interesting with your new found skills.

(and more importantly,
finding out what I don't know well). Thanks!

The first 'nontrivial' thing I did with C++ (after
many small exercises) was a small 'contacts' database with
e.g. names, addresses, phone numbers, etc. That's because
I'm interested in databases, and that's an area where I
already have skill with other languages, and have the most
experience.

Hint: Use the standard library. It is *very* powerful,
and lets you start applying 'code reuse' immediately.
Spend some time learning about containers, iterators,
and the algorithms declared by header <algorithm>
which uses them. *Very* powerful and flexible things can
be done with them. Which reminds me: A very good book to have is
Josuttis' "The C++ Standard Library" www.josuttis.com/libbook


HTH,
-Mike

 

[Gene Wirchenko]

On 1 Oct 2003 15:30:14 -0700, (e-mail address removed) (Michael Strorm)
wrote:

[snip]

So, I'd be interested to get some suggestions, because I feel like
doing *something* with all this knowledge (and more importantly,
finding out what I don't know well). Thanks!

You could write a small text adventure. It need not do much, but
just to bring it up to framework level, you are going to have to do a
lot of work with I/O and string manipulation. There are plenty of
opportunities to define classes or use STL. After you have the
framework, you can bolt on a lot of other stuff that fits your fancy.

Sincerely,

Gene Wirchenko

 

[Jonathan Mcdougall]

[snip]

You could write a small text adventure. It need not do much, but
just to bring it up to framework level, you are going to have to do a
lot of work with I/O and string manipulation. There are plenty of
opportunities to define classes or use STL. After you have the
framework, you can bolt on a lot of other stuff that fits your fancy.

But PLEASE, before you ask, there is no way in C++ to clear the screen or
change the colour of the output


Jonathan

 

[Richard Heathfield]

[Just clearing up a tiny nit]

But PLEASE, before you ask, there is no way in C++ to clear the screen or
change the colour of the output

.....unless you are prepared to use extensions to the language (such as
libraries - ncurses, SDL, OpenGL, whatever) which may not be available on
all your target platforms, and discussion of which is off-topic in both
these newsgroups but not in platform-specific newsgroups.

 

[Gene Wirchenko]

On Wed, 1 Oct 2003 23:19:44 -0400, "Jonathan Mcdougall"

[snip]

But PLEASE, before you ask, there is no way in C++ to clear the screen or
change the colour of the output

<EG>

The best response I ever saw to the clear screen question was
"Which screen?"

Sincerely,

Gene Wirchenko

 

[Default User]

You could write a small text adventure. It need not do much, but
just to bring it up to framework level, you are going to have to do a
lot of work with I/O and string manipulation. There are plenty of
opportunities to define classes or use STL. After you have the
framework, you can bolt on a lot of other stuff that fits your fancy.

That's a pretty good project, if you like TA games. It was my learning
program for C many moons ago. It's probably even better for C++, because
the OO approach is natural for a game like that.




Brian Rodenborn

 

[Mike Wahler]

On Wed, 1 Oct 2003 23:19:44 -0400, "Jonathan Mcdougall"

[snip]

But PLEASE, before you ask, there is no way in C++ to clear the screen or
change the colour of the output

<EG>

The best response I ever saw to the clear screen question was
"Which screen?"

I like "use glass cleaner".

-Mike

 

[WW]

On Wed, 1 Oct 2003 23:19:44 -0400, "Jonathan Mcdougall"

[snip]

But PLEASE, before you ask, there is no way in C++ to clear the
screen or change the colour of the output

<EG>

The best response I ever saw to the clear screen question was
"Which screen?"

I like "use glass cleaner".

Or if you need fast code and aggresive optimization there is the
hammer-fast-forward followed by a circle-to-remove-remainder (aka modulus)
method. And it is a time tested pattern used by burlgars and fireman all
around the world. ;-)

 

[Ron Natalie]

The best response I ever saw to the clear screen question wasI just tell them to turn the computer upside down and shake.

 

[WW]

I just tell them to turn the computer upside down and shake.

That's a good one.

 

[Gene Wirchenko]

That's a pretty good project, if you like TA games. It was my learning
program for C many moons ago. It's probably even better for C++, because
the OO approach is natural for a game like that.

Quite. There are OO languages for writing these games. See
rec.art.int-fiction.

Sincerely,

Gene Wirchenko

 

[jeffc]

To get to the point, I'm wanting to start a moderately-sized
project that would take a week (working full time on it, which I won't
be ) to do reasonably, cover a decent subset of the language, be
interesting to do, and workable under (say) gcc on Linux (without too
much nonstandard code). It'd also be interesting to get some practice
in software design in there.

I thought writing a Blackjack (21) simulator was a great exercise. It was a
little more than that for me, because I wanted to understand more about
betting strategies. (It's a fascinating game, mathematically.) You don't
have to take it very far (you can bet the same each time, and never change
the rules), but you can quickly understand it (the "problem domain" is easy
to understand, and fun.) The concepts are quite simple - not to be mistaken
for easy! It really makes you think about overall program design. You will
have to think about performance and efficiency, because to get statistically
valid feedback you will have to run millions of hands. You have to think
about randomness. The difference between generating any old random number,
and generating a random shuffle with a real card deck is interesting. You
will have to think about data structures. And of course I/O.

 

[jeffc]

I thought writing a Blackjack (21) simulator was a great exercise.

You didn't mention OO, but in addition I found this to be an outstanding
exercise in OO design. It's not complex, but at the same time makes you
think quite about the relationships between the objects involved. Obviously
you need a deck of cards, but who has it? If the dealer has it, then how
much access to it does he have? Do you need a card table? Do you need a
casino? Who gets your chips when you lose, the dealer or the casino? When
you are dealt a hand, where does the hand go? (In a real casino, the hand
is "yours", but you can't touch the cards - only the dealer can. At the
same time, only you can make decisions about changing your hand, and the
dealer can't. So who "owns" or "has" the hand - you or the dealer?) Do you
even need a deck of cards? Can't you just deal a "card" as a random number
"out of thin air", from an "infinite deck"? (Before deciding, note that the
odds of getting a blackjack are higher in real life when using 1 deck of
cards than with 2!!)

 

[Default User]

Quite. There are OO languages for writing these games. See
rec.art.int-fiction.

That doesn't provide any instruction in C++ programming. There are two
different, related but distinct ideas:


1. If you want to learn C++, writing a TA game is a good exercise.

2. If you want to write TA games, TADS, Inform or another dedicated
language would be a better choice than C++.




Brian Rodenborn

 

[Josh Sebastian]

I thought writing a Blackjack (21) simulator was a great exercise.

Games in general and card games in particular are good, I think. The first
non-trivial graphical program I wrote was a version of Set (a card game
made by MENSA) for Windows.

Josh

 

[jeffc]

Games in general and card games in particular are good, I think. The first
non-trivial graphical program I wrote was a version of Set (a card game
made by MENSA) for Windows.

Actually, mine was non-graphical. It was not a game per se, but a
simulation of what your results would be after so many hands of blackjack,
with different betting strategies. e.g., if you split 10s rather than
staying with 20, would you do better or worse in the long run? (worse, by
the way

 

[Gene Wirchenko]

^^^
"arts".

That doesn't provide any instruction in C++ programming. There are two
different, related but distinct ideas:


1. If you want to learn C++, writing a TA game is a good exercise.

2. If you want to write TA games, TADS, Inform or another dedicated
language would be a better choice than C++.

Agreed.

Sincerely,

Gene Wirchenko

 

[jeffc]

I think Solitaire might be fun, just the computational aspects, no graphics.
Besides I would really like to know what the probability of winning that
game is, no cheating. I think the classic form is called Klondike.

It shouldn't be too hard to figure it out pretty closely. When you play for
money, it costs $52, and you get $5 back for every card you place. placing
10 cards is about the break even point. That's for 1 card at a time, once
through the deck. The house has to retain a slight edge. Most games you'll
make significantly less than $52 (place fewer than 10 cards). That's to
balance breaking the bank.

Blackjack sounds too easy to use up a week.

Sure, getting the game to work. But writing a real simulation that
calculates percentage of return for the betting strategy you choose is not
too easy. There's more to it than asking "hit or stay". And there are
quite a few rules, not to mention rules variations, that have to be taken
into account. Like most things, it's more complicated than you think. An
excellent exercise.

 

[osmium]

I thought writing a Blackjack (21) simulator was a great exercise.

I think Solitaire might be fun, just the computational aspects, no graphics.
Besides I would really like to know what the probability of winning that
game is, no cheating. I think the classic form is called Klondike.
Blackjack sounds too easy to use up a week.