You should add the directory where your compiled program is to your PATH.
For example if you are inside the /home/jimmy/cpp directory
type (leading $ is the prompt)
PATH=$PATH:`pwd`
$myprog
Read about exporting variables and the bashrc file to make this change permanent. (assuming bash as your shell)
You must learn the ways of the PATH if you're to come with me to Alderaan.
Personally, I use $HOME/bin as a personal collection point for utilities I wrote but that won't be of use to all users. Otherwise, /usr/local/bin is often the right place for locally written programs that are of use to all users. In any case, I have verified that the latter place was on my path and added $HOME/bin as well.
Unless you really are an installer, it is probably not a good idea to go dropping programs into /bin or /usr/bin despite temptation. That would be the moral equivalent of putting your programs in C:\Windows or C:\Windows\System32. It is effectively never the correct answer.
Learning more about the PATH environment variable and how the shell searches for programs to run is definitely recommended. Also, as pointed out in another comment, just don't add . to your PATH because it will come back to haunt you at some point.
Edit: Incidentally, I do a very similar thing on my Windows boxen. I always create a sibling to C:\Program Files named C:\Programs. In there, I make a folder named bin and add that to the system path. I use C:\programs\bin much like I use $HOME/bin on a *nix box, and put any hand-installed (i.e. no real Windows installer was used) programs or stuff ported from *nix that can't tolerate spaces in its path in there in other folders such as C:\Programs\mingw, C:\programs\MSYS, or C:\programs\cygwin.
Any small utilities primarily used from the command prompt usually end up in C:\programs\bin, but for anything I'm seriously planning to use on more than one PC I generally create a real Windows installer with InnoSetup and let it get installed in C:\Program Files.
A detailed discussion of why putting . (current directory) in the PATH is a bad idea.
Lets say you're being attacked by an adversary on your machine.
He authors a malicious program, and puts it in a directory, hoping that you'll stumble on it eventually. To increase his chances, he names it something common like mv.
If you have added . to the beginning of your path, and happen to be in the right directory when you type mv onefile twofile... then the local mv (./mv) gets run instead of the mv command we're all used too! This happens because . is in your path, and the local mv will be found before the /usr/bin/mv. Suddenly, your user account or the entire machine may be horribly compromised.
(note: mv might be one of the built-in commands, and immune to this. Not sure... but the principle is solid)
So, you learn the lesson, and now put . at the end of your path, so that all "official" directories will be searched before the local directory.
But the attacker is now on to you! Instead of the program mv, he creates in a program mc, which is a common typo for mv. Again, you intend to type mv onefile twofile, but make a simple typo to mc. Now all the "official" directories are searched, the program mc is not found, and finally it is found in the local directory. Malicious code is run, and again you lose.
The lesson is that your PATH should only cover known-good software, and since your current directory changes frequently, you never know exactly what software is there, and should never run it unless you're very explicit about it with the ./ prefix (eg. > ./IMeanToRunThis)