 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Kevin Wampler wrote:
>> How about a program that takes a multivariate polynomial as input and
>> determines if it has any roots over the integers ;-)
>
> I know you're joking, but I'm not sure how that would be more useful in
> learning C++ than in learning C.
It wouldn't really, I was just unable to resist giving an undecidable
problem as a programming suggestion.
As a more serious suggestion, and somewhat graphics related, you could
implement an inverse-kinematics system. It lends itself well to an OO
approach, and IIRC there's a clever technique to perform automatic
differentiation using C++ templates that might give you some practice there.
Alternatively, how about implementing the Barnes-Hut algorithm for
N-body simulations? It should give pretty animations and I don't think
is terribly difficult.
In terms of the STL perhaps writing a simple calculator would be a
reasonable task. You can add whatever interesting functionality you
like (variables, complex numbers, exact rationals, matrices, tensors,
symbolic expressions, etc) so you can probably craft it to work whatever
data structures you're least familiar with.
I'm not a C++ expert though, so others may have better suggestions.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Sadly, I'm utterly uninspired about what to write past my first usual
> program, namely "Jotto". Any suggestions?
How about something to solve/play a game, like Sudoku, checkers, connect 4,
poker etc. Not a huge OO-based project, but certainly something to get
started with.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Sadly, I'm utterly uninspired about what to write past my first usual
> program, namely "Jotto". Any suggestions?
I was in the exact same situation as you. It depends on your past
programming experience. I knew Assembly and C and wanted to learn C++. I
first started a simple physics simulation "game". It showed bunch of
balls bouncing on the screen. Then I turned it into a 3D path tracing
renderer.
So: write a rendering engine!
Writing a chess engine was also fun.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> How about a program that takes a multivariate polynomial as input and
>>> determines if it has any roots over the integers ;-)
>>
>> I know you're joking, but I'm not sure how that would be more useful
>> in learning C++ than in learning C.
>
> It wouldn't really, I was just unable to resist giving an undecidable
> problem as a programming suggestion.
Question: Why is this undecidable?
Surely it's a trivial matter of iterating over all integers and testing
whether any of them is a root?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> Sadly, I'm utterly uninspired about what to write past my first usual
> program, namely "Jotto". Any suggestions?
Coding a small game is always fun, and a good environment for
object-oriented design (there are so many things in a typical game that
can be naturally expressed with classes, such as for example a sprite,
level data, etc.)
OTOH one small problem with C++ is that there is no standard way of
drawing any graphics. Thus you'll have to resort to some third-party
library. The quality (as in C++ design quality) of existing libraries
is very varied, from usable to absolutely horrible. In my experience very
few C++ graphical libraries employ the same level of code design quality
as eg. the STL or the Boost libraries do, and they are often quite hard
to use, error-prone, and in some cases even buggy (there may be memory
leaks inside the library itself).
There are two popular 2D engine libraries for Windows which I know of:
http://hge.relishgames.com/
http://developer.popcap.com/forums/pop_index.php
I have only extensive experience on the latter one, and while it's not
horrible, it's not STL-level-of-quality either, and probably not the
easiest possible to use. From the example codes I have seen of the HGE
library, it might not be the easiest possible to use either.
You could consider this one too, which would make your program much
more portable:
http://www.libsdl.org/
However, I unfortunately have absolutely no experience in using it, nor
do I know how easy it is to integrate in Visual Studio. Being a C library
it will most probably be of a much lower level library than an abstract
high-quality C++ library would be, and consequently probably hard to use.
(OTOH, you said you do have a lot of experience with C.)
You could try making DirectX or OpenGL code directly, but that would be
even lower-level code, and might become a nightmare. And you should forget
trying to program with the Windows API directly, unless you have *tons* of
experience with it, or you want to die prematurely.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Coding a small game is always fun
This is the one thing I have never implemented. I'd like to do it at
least once before I die...
> OTOH one small problem with C++ is that there is no standard way of
> drawing any graphics.
...and this is the reason why. Almost *no* languages have the capability
to easily draw graphics these days.
(Back when I was a kid, you could just say "plot 4, 7" and it would draw
a dot there. Ah, I had no idea how good I had it!)
> And you should forget
> trying to program with the Windows API directly, unless you have *tons* of
> experience with it, or you want to die prematurely.
This made me actually laugh out loud. For real. Such a glowing
recommendation of the Win32 API! :-D
(OTOH, I understand that the raw X Windows bindings are even harder...
apparently... I guess that's why there's so many toolkits!)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> even lower-level code, and might become a nightmare. And you should forget
> trying to program with the Windows API directly, unless you have *tons* of
> experience with it, or you want to die prematurely.
My first C program was a program that used the Windows API directly...
Your assessment is about accurate, though.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> > OTOH one small problem with C++ is that there is no standard way of
> > drawing any graphics.
> ...and this is the reason why. Almost *no* languages have the capability
> to easily draw graphics these days.
Some languages, such as Java, come with standard libraries for drawing
graphics, but in general the no-graphics-libraries trend is probably
because languages want to be portable, and it's very hard to make portable
yet efficient generic graphic libraries.
OpenGL is a very good, cross-language attempt, but you can't do
*everything* with it. Its target application range is rather narrow
(basically only hardware-accelerated 3D and 2D graphics, but it doesn't
have any support for eg. windowing systems).
> (Back when I was a kid, you could just say "plot 4, 7" and it would draw
> a dot there. Ah, I had no idea how good I had it!)
In those days portability was not an issue for the people who made the
compilers.
> > And you should forget
> > trying to program with the Windows API directly, unless you have *tons* of
> > experience with it, or you want to die prematurely.
> This made me actually laugh out loud. For real. Such a glowing
> recommendation of the Win32 API! :-D
> (OTOH, I understand that the raw X Windows bindings are even harder...
> apparently... I guess that's why there's so many toolkits!)
I once tried to look how I would create a simple dialog which contained
some radio buttons, textfields and buttons directly with the Win32 API, and
I was absolutely horrified at how horrendously difficult it is.
With a graphical toolkit such as GTK you simply say that you want a modal
window, it's composed of some elements eg. arranged vertically, and then
you simply add those elements to it. You don't have to specify how they
should look like, their coordinates on the window, or anything. You just
tell it *what* you want, and how it should be arranged. It's surprisingly
simple even though it's a C library, once you get used to it.
With the Win32 API you have to define *absolutely* everything by hand.
Every pixel coordinate, every width and height, every color. Everything.
And often in the hardest possible way.
The standard answer to this is "you don't create windows with the Win32
API directly, you use a graphical GUI creation software, and it will
generate the coordinates for you".
The only problem in this particular case is that, AFAIK, VS Express does
*not* come with such a GUI creation module. (At least VS 2005 Express didn't.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> The only problem in this particular case is that, AFAIK, VS Express does
> *not* come with such a GUI creation module. (At least VS 2005 Express didn't.)
>
It is missing MFC. I think it does have the resource editor, though. So
you can define dialogs visually, but you'll have to do your own coding
to manage the dialog.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Some languages, such as Java, come with standard libraries for drawing
> graphics
But using it is still nowhere near the level of "plot a pixel here please".
> but in general the no-graphics-libraries trend is probably
> because languages want to be portable, and it's very hard to make portable
> yet efficient generic graphic libraries.
Yeah, that's about the size of it.
> OpenGL is a very good, cross-language attempt, but you can't do
> *everything* with it. Its target application range is rather narrow
> (basically only hardware-accelerated 3D and 2D graphics, but it doesn't
> have any support for eg. windowing systems).
Indeed. Without having a way to talk to the native graphics control
system to set up a drawing surface, OpenGL is no help. (There also seems
to be some disagreement above whether you can use GLUT on Windows...)
>> (Back when I was a kid, you could just say "plot 4, 7" and it would draw
>> a dot there. Ah, I had no idea how good I had it!)
>
> In those days portability was not an issue for the people who made the
> compilers.
In those days, nobody had multitasking either (so you don't have to
*share* the framebuffer with anybody). That probably helps.
>> This made me actually laugh out loud. For real. Such a glowing
>> recommendation of the Win32 API! :-D
>
> I once tried to look how I would create a simple dialog which contained
> some radio buttons, textfields and buttons directly with the Win32 API, and
> I was absolutely horrified at how horrendously difficult it is.
>
> With the Win32 API you have to define *absolutely* everything by hand.
> Every pixel coordinate, every width and height, every color. Everything.
> And often in the hardest possible way.
Well, I guess that means you have lots of control over what it does. On
the other hand... tedious, much?
> The standard answer to this is "you don't create windows with the Win32
> API directly, you use a graphical GUI creation software, and it will
> generate the coordinates for you".
Indeed. I typically use GTK - because I can't get SDL to work. (Which is
a pitty, because SDL does way more stuff!)
> The only problem in this particular case is that, AFAIK, VS Express does
> *not* come with such a GUI creation module. (At least VS 2005 Express didn't.)
*My* problem is that... well GTK isn't something you usually find on
Windows. :-S
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
