C++ project for Beginner?

[wad67]

Currently i have a limited knowledge on how to program in c++. However after trying countless other languages (python,lua,javascript,Basic) I found that i was far more proficient at coding in c++,
I have made a few simple console applications, such as a calculator + - * /, Age getter, and one that spews out a rick astley cout depending on what you type in.

I am not sure if i want to try anything above a console application, but i am fresh out of ideas, can anyone suggest a realistic project for me?
I am using Codeblocks with a Gnu GCC Compiler. (I also have a Mingw shell with mysys installed for makefiles).

[Waffle99]

try making a financial program? You could integrate your calculator and a graph system. Just keeping track of basic information

[Sciyaps]

I'm quite new to programming, I know basically nothing about C++, I'm wanting to learn it myself. So everyone's idea's would help me out, I just need a basic idea for a first program or "game".

I don't know where to start...

[1solidsnake2]

[QUOTE=Sciyaps;34157832]I'm quite new to programming, I know basically nothing about C++, I'm wanting to learn it myself. So everyone's idea's would help me out, I just need a basic idea for a first program or "game".

I don't know where to start...[/QUOTE]

[url]http://www.cplusplus.com/doc/tutorial/[/url]

You must learn how to walk before you can run.

[wad67]

[QUOTE=Waffle99;34157484]try making a financial program? You could integrate your calculator and a graph system. Just keeping track of basic information[/QUOTE]
Would that require a gui of some description? and some sort of graphics for the graph?

[cinoisP]

[QUOTE=1solidsnake2;34158842][url]http://www.cplusplus.com/doc/tutorial/[/url]

You must learn how to walk before you can run.[/QUOTE]

I must learn how to crawl before walk so, i cant move at all..

[Kaarristu]

[url]http://www.youtube.com/user/antirtfm?blend=1&ob=4#p/c/1D10C030FDCE7CE0[/url]

This guy explains the basics of c++ pretty well

[AaRoNg11]

The best kind of project you can make is one that will actually be useful.

Back when I was in school one of the first programming projects I made on my own was one to do my physics homework for me. We had a shit ton of newtonian mechanics related problems to solve and I was really struggling with them. In the end I wrote a program that could solve pretty much all of the standard problems and print out the steps it had performed to get to the solution

In the long run it saved me a shit ton of time, and once i'd implemented all of the equations I actually understood the subject a hell of a lot better.

Edit -
If you are looking for something a bit more fun, you could also mess around with some procedural sound generation. If you are using Visual Studio, you can include the Windows.h library and invoke the "Beep" function providing it with a frequency and period. We made a networked version that had a slave program running on loads of different computers, and the master program could order individual computers to play certain notes. At one point we had about 12 computers playing "Never gonna give you up" in some kind of weird orchestra style arrangement.

[Tamschi]

[QUOTE=AaRoNg11;34201699]
If you are looking for something a bit more fun, you could also mess around with some procedural sound generation. If you are using Visual Studio, you can include the Windows.h library and invoke the "Beep" function providing it with a frequency and period. We made a networked version that had a slave program running on loads of different computers, and the master program could order individual computers to play certain notes. At one point we had about 12 computers playing "Never gonna give you up" in some kind of weird orchestra style arrangement.[/QUOTE]

This won't work on Vista x64. Starting with Windows 7, it plays on the normal speakers.

[Nielk1]

Fun little programs you might try are one of those card flipping and matching games (I did one way back using the lines for box drawing to make it look like the cards flipped) or the like.

The real fun comes when you start doing test programs for specific things like pointers or serializing large chunks of variables. One important thing to learn is how C++ works under the hood. For example, if you declare a chunk of variables in a straight line, you could treat it as an array (provided they are all the same size, thus all INTs or the like) and ram the chunk of binary data into a file and back to do a save/load.

Basically, come up with things you want to try, and then come up with programs that test that functionality. Oh, and learn how to use forms after a while, both ones built into windows and ones from other frameworks like wxWidgets and QT.

And I've done the beep thing too, I made one that loaded a quick input file with the note frequencies and lengths listed.

[gparent]

[QUOTE=Nielk1;34305492]One important thing to learn is how C++ works under the hood. For example, if you declare a chunk of variables in a straight line, you could treat it as an array (provided they are all the same size, thus all INTs or the like) and ram the chunk of binary data into a file and back to do a save/load.[/QUOTE]

I think it's more important to know that what you just said is wrong and could crash catastrophically than learning how C++ works under the hood. Learn how C++ works over the hood according to the ISO C++ standard instead, leads to much more accurate information, which you can then use to judge if your compiler is doing the appropriate things.

[Nielk1]

[QUOTE=gparent;34307285]I think it's more important to know that what you just said is wrong and could crash catastrophically than learning how C++ works under the hood. Learn how C++ works over the hood according to the ISO C++ standard instead, leads to much more accurate information, which you can then use to judge if your compiler is doing the appropriate things.[/QUOTE]

It's not wrong, unless I said it wrong or you misunderstood.

missiondll.h

class MissionDLL : public DLLBase
{
private:
...
	int i_first,
		m_TotalGameTime,
		m_RemainingGameTime,
		m_ElapsedGameTime,
		m_KillLimit,
		m_PointsForAIKill,
		m_KillForAIKill,
		i_last;
...
protected:
...
	int *i_array;
	int i_count;
...

missiondll.cpp

MissionDLL::MissionDLL(void)
{
...
	i_count = &i_last - &i_first - 1;
	i_array = &i_first + 1;
}
...
void MissionDLL::Init(void)
{
...
	if(i_array)
		memset(i_array, 0, i_count*sizeof(int));
...
}
...
bool MissionDLL::Load()
{
...
	// ints
	if (i_array != NULL)
		Read(i_array, i_count);
...
}
...
void MissionDLL::Save()
{
...
	// ints
	if (i_array != NULL)
		Write(i_array, i_count);
...
}
...

Its pretty standard stuff, its no more dangerous than using pointers (oh the horror). In the above case it is used to save/load an SP game and send/receive an MP gamestate (fresh joiner or resync).

Nothing remotely funny, odd, or off about it. Its in the very nature of how the language works, at least how I've seen it every time I've used it.

If something is wrong with this say so but I've seen the same code work for 10 years across several compilers.

[_Twitch_]

[QUOTE=gparent;34307285]I think it's more important to know that what you just said is wrong and could crash catastrophically than learning how C++ works under the hood. Learn how C++ works over the hood according to the ISO C++ standard instead, leads to much more accurate information, which you can then use to judge if your compiler is doing the appropriate things.[/QUOTE]

I understood C a lot better once I learned whats going on under the hood, the underlying assembly code and calling conventions. He's right, the variables are in a straight line in memory. It's not the safest thing to do, but if you do it right it'll work.

[ROBO_DONUT]

They [i]can be[/i] a bunch of consecutive values in stack memory. They can also optimized away in favor of keeping the value entirely in a register on the processor, or rearranged by the compiler just because it can.

It's a property that may be useful to keep in mind when debugging, reverse-engineering, or trying to break something (intentionally), but it's not something that you can depend on.

[Nielk1]

That said, odd things can happen in different languages and compilers. I forget which one it was, but I had a situation once where two different variables were constants set to the same value and the compiler optimized it so they pointed to the same value in memory. I don't recall if this was C++, Java, a scripting language like Python, or something else. I've used far too many different languages to guess at this point.
---
I think this (my code pasted above) is safe for the same reason arrays are safe. It might not be explicitly defined as an array, but that is exactly what it is. Just like how the name of an array with no index can give you the item at index 0 and adding the size of the type of the array to that can get you the item at index 1. If it somehow did mess it up it would have to happen at compile time, which would mean that the compiler was acting in a way unlike other compilers and there would probably be a pre-processor block or something to control it.

[gparent]

[QUOTE=Nielk1;34312053]If it somehow did mess it up it would have to happen at compile time, which would mean that the compiler was acting in a way unlike other compilers and there would probably be a pre-processor block or something to control it.[/QUOTE]

No, no, no. Good code would NOT depend on some stupid implementation detail that can change with every build of the compiler. You're right that bad, dangerous, poorly written code often relies on many compiler assumptions, but you don't strive to write shitty code, do you?

Using implementation defined behavior is not the same as guessing undefined behavior and hoping it works fine in other compilers. The latter relies on luck, the former relies on proper documentation and research. ROBO_DONUT hit the nail on the head. Your code could react completely differently. It's a silly example, but it's true: A fully compliant ISO C++ compiler could erase your file system upon dereferencing a null pointer, because it's undefined behavior and thus by definition, anything can happen.

[QUOTE=_Twitch_;34311561]I understood C a lot better once I learned whats going on under the hood, the underlying assembly code and calling conventions. He's right, the variables are in a straight line in memory.[/QUOTE]
It doesn't matter if he's right. He could be wrong tomorrow when VS11 comes out. As far as I know calling conventions aren't even defined by C++, so you basically have to rely on compiler defined behavior for that, so obviously for exporting libraries shit can start flying, but that's a very different situation than memsetting an array.

EDIT: Also, we're talking about a guy who made a calculator in C++. Does he really need to know the finer details of arrays, optimization and writing over random memory?

[jA_cOp]

[QUOTE=Nielk1;34310496]It's not wrong, unless I said it wrong or you misunderstood.

-code snip-
[/QUOTE]

Firstly, you insinuated declaring a series of consecutive [I]stack variables[/I] in a row could safely be accessed as an array. This is not only false, insofar that it's undefined behaviour, but it won't even work on popular platforms like x86-64, where stack variables are aligned on 16 byte boundaries.

Secondly, your example doesn't account for padding. Those fields can be aligned on any byte boundary the compiler sees fit. This is often 4 bytes, which means coincidentally, it will usually work with a list of 'int' (which is also often 4 bytes - but not always), but you're still implicitly relying on implementation specific behaviour (compilers usually have a pragma that let you pack the fields of a type - use it!).

It's also worth mentioning that those protected fields there can appear before the private fields - it's easy to break the code later by changing the access specifier of a certain field. It's best to use POD types when making assumptions about a type's memory layout.

[QUOTE=Nielk1;34310496]Its pretty standard stuff, its no more dangerous than using pointers (oh the horror).[/QUOTE]

Yes, because using pointers here gives you exactly the same problems.

[QUOTE=Nielk1;34310496]Nothing remotely funny, odd, or off about it.[/QUOTE]

Sounds more like you're trying to convince yourself.

[QUOTE=Nielk1;34310496]Its in the very nature of how the language works, at least how I've seen it every time I've used it.[/QUOTE]

No. It's the very nature of how a particular version of your compiler works on a particular OS targeting a particular processor architecture.

[QUOTE=Nielk1;34310496]If something is wrong with this say so but I've seen the same code work for 10 years across several compilers.[/QUOTE]

Sounds like cargo cult programming to me.

[Nielk1]

Actually I was leaving my post open to be corrected, not sliced apart and attacked. You started off giving good information and then moved on to attacking the post and me line by line.

I can understand if what I was saying was unclear, hence that either I said it wrong or you read it wrong.

I've used similar code across both 64 and 32 bit platforms on numerous OSs and as such numerous compilers since I discovered it and not had an issue, though it has now been over two years since I used C++ so I might have omitted something important in my above code. (Various iterations of MS's compiler, GCC, MINGW, etc)

I know pointers give the same problems, that is the entire reason why I said it, though I guess the lack of the classic RAZZ emoticon there made that point lost.

Of course you can break the code by changing it, its written the way it is on purpose. I can break and engine if I start swapping cylinders around (poor analogy).

Honestly I can't find how I accounted for the alignment. I learned a lot about these things way back in OS and it took me a while re-evaluating the code to see why it worked, an evaluation I can no longer recall.

So, how would you *fix* the code above?

To try to make it ANSI I guess you could actually declare them as arrays and then point the variable names you want to the addresses of the values in the arrays, but that is really messy and really ugly and you would be better off just writing each INT individually.

How would YOU handle this?

Thinking back to why it works, it might have been that this code required a specific compiler to always work (I could have gotten lucky with my other tests), which is just one of the sorts of hackish things you start to see in a kernel source code. (Well that and other nasties like ASM segments and unrolled loops.)

And I don't appreciate the cargo cult comment, I've participated in creating compilers as educational exercises, and I am not talking about wooden mockups hoping for spam from the sky, I mean real compilers (well, limited functionality compilers). Going after what I said where it's wrong is fine, going after me just makes [i]you[/i] look bad.

I wouldn't have posted it if I had not thought it correct and done tests that, at least in my luck, worked fine. I appreciate [i]correction[/i], but I don't appreciate ad hominem.

Addendum: This sort of spiraled off this topic and I haven't been on FP in, years, do you guys split topics?

[gparent]

[QUOTE=Nielk1;34317028]I can understand if what I was saying was unclear, hence that either I said it wrong or you read it wrong.[/QUOTE]
It is not an issue of being unclear or writing wrong or reading wrong. We just think you are factually wrong, and disagree with your opinion. No worries! We know how to read, write, and process text, acting otherwise is simply patronizing us.
[QUOTE=Nielk1;34317028]Honestly I can't find how I accounted for the alignment.[/QUOTE]
Well, that's because you didn't account for alignment in that code. [I]int[/I] happens to match the alignment requirements for many platforms, but even that could break.
[QUOTE=Nielk1;34317028]So, how would you *fix* the code above?[/QUOTE]
[QUOTE=Nielk1;34317028]you would be better off just writing each INT individually.[/QUOTE]
That way.
[QUOTE=Nielk1;34317028]I've participated in creating compilers as educational exercises, and I am not talking about wooden mockups hoping for spam from the sky, I mean real compilers (well, limited functionality compilers).[/QUOTE]
Then how can you not understand that relying on undefined behavior is bad?

How's this, imagine that there is a new programming language, C%. The inventor of C% was a very unique fellow. When you code with his language, using the character [I]%[/I] in your source code is [B]undefined behavior.[/B] Additionally, comments [B]MUST[/B] be preceded by the magic string 0xDEADBEEF, and there is no support for inline comments. A line beginning by 0xDEADBEEF starts as a comment and ends as a comment.

There are two major implementations of a compiler for your programming language. One is [B]MicroShaft[/B]'s Vigorous Companion% (MSVC%, version 6), and the other one is [B]GrossParent'[/B]s Crafting Compendium (GCCv4), a fork of MSVC% with a second front-end for C++.

GrossParent's compiler is very good! It supports every feature of the C% programming language. MicroShaft's compiler is acceptable, but is the only one that can compile Windows executables, so both compilers have an immense share of users.

For some weird reason, MicroShaft's compiler has a bug and whenever it encounters the character '%' twice, it turns anything in-between into "Fuckerlord". No one notices for years. GrossParent's compiler, based largely upon MicroShaft's, has received a patch for this bug and now carries on, and stripping the character from the source code when parsing. Due to implementation details, it happens that any string of character starting and ending by % are ignored.

A Linux programmer on FacePunch (nicknamed [B]std::pow(std::nullptr_t, 2)[/B]) writes his first program in the C% programming language. Not having read the standards document of C%, he discovers the power of the % character by random testing. Most happy about his discovery of the comment keyword, he writes his first program, Hello World!, and then decides to comment part of the string (Hello %World%!) to show one of his friends, [B]Bear X[/B]. He sends the source code to him, and his Windows-loving friend compiles the application, and then begins verbally assaulting the author for being so, so rude. He then sends the code to his Debian-loving friend, using GrossParent's compiler version 3, and his friend tells him to fuck off too.

Do you see what went wrong here? You're basically doing this when writing code that relies on undefined behavior. Our coder did, indeed, verify that the code worked on his compiler, and there are good chances that he has tried it on several early versions of the v4 series of his compiler too. But Debian has an older version of the GrossParent's compiler, which has the same bug as the Windows version that Bear X is using.

[B]But still, treating % as comments was dangerous[/B][B]. [/B]While my example is obviously a joke, the same process is happening whenever you dereference a null pointer, or make guesses as to the memory layout of classes, or act as if CHAR_BIT was always defined as 8 on embedded platforms. Programs that work fine can behave differently under different environments and compilers, sometimes leading to catastrophic results.

Now imagine if everyone started using % instead of [B]0xDEADBEEF[/B] (because, hey, it works fine in GrossParent`s, our leading vendor!). Fast forward 5 years. The entire source code of your programming language is now a one big unusable joke for anyone with a compiler that works differently, or using an older version of GrossParent`s, or anyone who uses MSVC%.

This, is why you must not rely on undefined behavior.
[QUOTE=Nielk1;34317028]Addendum: This sort of spiraled off this topic and I haven't been on FP in, years, do you guys split topics?[/QUOTE]
They close topics if it stops being civil, so we should be good.

[Nielk1]

Scary thought, I learned what I was doing from a game that went out 10 years ago and even though still being patched still does it the same way.

[gparent]

[QUOTE=Nielk1;34318571]Scary thought, I learned what I was doing from a game that went out 10 years ago and even though still being patched still does it the same way.[/QUOTE]

EDIT: I can't tell if you're finally realizing that it's a bad idea or not to do it like you did 10 years ago, so I took out my original post. But basically, it's still wrong and hurts new programmers to promote terrible code that depends on undefined behavior, which is why I mentioned it in the first place.

Video game code is usually pretty shit anyway from what I've seen. Too many performance concerns and lack of care about proper code and maintainability (ship it and fuck it) to use their source code as a good example most of the time.

[blankthemuffin]

[QUOTE=gparent;34318933]Video game code is usually pretty shit anyway from what I've seen. Too many performance concerns and lack of care about proper code and maintainability (ship it and fuck it) to use their source code as a good example most of the time.[/QUOTE]

One could also argue that application code has a tendency to get lost in needless abstraction, ignoring simplicity and usability for the mystical goal of re-usability. Not that it's related to the discussion at all.

[gparent]

[QUOTE=blankthemuffin;34319091]One could also argue that application code has a tendency to get lost in needless abstraction, ignoring simplicity and usability for the mystical goal of re-usability. Not that it's related to the discussion at all.[/QUOTE]
Most of the time I see that argument from people who just don't understand the abstractions, but yes, you're right that it's unrelated.

[Nielk1]

In the case of OSs you go for fast and ugly.

In the case of normal programs and utilities you tend to go for maintainability.

In the case of games, I have not the foggiest as my school decided to drop me in the LV2 course on that track without the LV1 one.

There are three types of efficiency, speed, space, and maintainability. I guess my code above might be ok in a situation where you are in control of what compiler you use and after speed over all else (granted, I don't see how it could be faster because I would think a good compiler would speed that bit up nicely even if each variable was written one by one).

What is ironic about all this is that in my classes I have always been the one who noted that you didn't actually know exactly what the compiler was going to do when given certain code when asked questions of safety or efficiency.

And I am not late to pick up anything, from the beginning I knew it was compiler dependent, I just thought that all compilers used were friendly to it. That, and I took a damn sleep between so one can't really argue I was "late".

EDIT:
I realized why they did it those 10 years ago. To make it easy to insert new vars when editing the mission dlls.
[url=http://www.matesfamily.org/bz2/BZ2_1.3b89_DLLSource.7z]-->Take a look<--[/url]
Which is funny because I've been writing all my mission code as functionality extensions via templates that use none of this. I use dynamic collections of structures of varying sizes (std::strings in there) and thus this code, which depends on static size, is useless.

[blankthemuffin]

[QUOTE=Nielk1;34319224]There are three types of efficiency, speed, space, and maintainability. I guess my code above might be ok in a situation where you are in control of what compiler you use and after speed over all else (granted, I don't see how it could be faster because I would think a good compiler would speed that bit up nicely even if each variable was written one by one).[/QUOTE]

The problem is it's not faster, smaller, or more maintainable, it's just a nasty hack.

Basically, if you're going to learn low level details (which you really should), learn them properly. Knowing how a struct is represented in memory isn't something that you're likely to need all the time, nor is it something you should abuse, but it's something you should learn anyway for the sake of not making obvious mistakes and being able to debug issues that are non-trivial.

This is all well beyond the calculator app level though, so I return to the OP and suggest writing an IRC bot. It's not trivial, and will stretch your skills significantly but hey that's the whole point. You get to learn about sockets too, which everybody loves.

[editline]21st January 2012[/editline]

[QUOTE=Nielk1;34305492]
The real fun comes when you start doing test programs for specific things like pointers or serializing large chunks of variables. One important thing to learn is how C++ works under the hood. For example, if you declare a chunk of variables in a straight line, you could treat it as an array (provided they are all the same size, thus all INTs or the like) and ram the chunk of binary data into a file and back to do a save/load.[/QUOTE]

OK I also have to note that this is not at all required to do store a block of PoD on disk. Depending on the lifetime of the data, writing it straight to disk may be all that's necessary (in which case you don't have to treat it as an array of integers, which is broken in pretty much every circumstance). If however your data needs to persist across multiple versions of the application you really need to control the padding manually for programmer sanity at the very least. If it has to be shared across multiple architectures you then need to make sure your types are all fixed width, and that you handle endianness properly.

[Genkaz]

I ultimately have the very same question myself. Recently I started messing around with SFML, but I am definitely getting a feeling that I should be working on a project that is actually functional (as opposed to me currently just working on a pong game) One of the main reasons why I became ridiculously bored with practical exercises from books was for the very same reason.

[LDTInsomniac]

Have you used the switch statemen before?

It's like the if statement, but a lot easier for larger blocks. You could try thinking up of a good way to use that, since it seems you haven't done it before (just looking at the examples you gave).

switch(variable)
{
case var1:
statement 1;
statement 2;
statement 3;
break;

case var2:
statement 1;
statement 2;
break;

default:
statement 1;
break;
}

An example of it:

#include <iostream>
#include <Windows.h>
using namespace std;

int main()
{
int option;

cout << "Options:\n\n";
cout << "1. Print hello\n";
cout << "2. Print durr\n";
cout << "3. Print hurr\n";

Sleep(1000);

cin >> option;
system("CLS");

switch( option )
{
case 1:
cout << "hello";
break;

case 2:
cout << "durr";
break;

case 3:
cout << "hurr";
break;

default:
cout << "Please select a valid option";
break;
}

return 0;
}

[gparent]

[QUOTE=genkaz92;34344450]I ultimately have the very same question myself. Recently I started messing around with SFML, but I am definitely getting a feeling that I should be working on a project that is actually functional (as opposed to me currently just working on a pong game) One of the main reasons why I became ridiculously bored with practical exercises from books was for the very same reason.[/QUOTE]
You don't get much more functional than a pong/tetris/breakout clone. You don't even focus on the design of the game, just making it work. If you find that boring, consider another career than game development. I'm not saying you should keep making that over and over, but if you can't get through a pong without getting bored, I can't imagine what it will be when you'll be making a bigger game.