I'll echo Rob first and say congrats!
I think your idea to use C/C++ is a good one. Experience in those languages will serve you well. You should also get experience with some non-imperative eventually, but C/C++ knowledge will always serve you well. Now, as for what projects to work on, I have a few recommendations.
Write some plugins
Find a program that you like, and figure out what feature it's missing. Then create that feature. Obviously, this will work a lot better if the program is actually extensible. I learned a lot by writing plugins for some applications I liked. It gave me exposure to good code written by others, and it gave me a chance to build something useful, without being overwhelmed.
Writing a plugin is a lot like adding features directly to an open source program, except that you're working with a cleaner interface, so you don't need to learn the entire source yet. It can also be a good way to get exposure to the program if you would like to eventually become a direct contributor eventually.
Oh, and writing plugins also taught me the value of backups and versioning, when an accident destroyed the bulk of my code. Don't make that mistake.
Make your class projects big
Most people just scrape by in class. Don't be most people. You should pick projects which are larger than they need to be, and you will learn a lot more. When people were putting together 300 line class projects, I was putting together a 3000 line project to teach myself C#. I even added plugin support. Why? Because it taught me a lot more than doing the bare minimum.
Of course, what I built at the time would actually be quite unimpressive now. I'm sure it could have been written much better (and with fewer lines). Still, it was a big project at the time, at it taught me a lot of things. Small projects just cannot stretch you the way large projects will.
Build a library
I'm going to be honest. Putting together another windowing library, or a container library, or a networking library, or any other kind of library, is going to be a waste of time in most senses. In all likelihood, you won't get a ton of use out of any libraries you build. However, if you do take the time to build a library, you will learn a lot.
You'll get a deeper knowledge of the domain that your library addresses. You'll become a lot more familiar with the low-level APIs exposed by the OS, since that's what you'll be building on. You'll learn a lot of new tricks if you take the time to learn about similar libraries. And finally, you'll learn a lot about structuring code to make the library clean. You'll learn about making better interfaces, making consistent interfaces. You will also have to face design tradeoffs. Composition or inheritance? Abstract classes or interfaces? All of this is very good practice. You will probably mess up a lot and restructure several times, but that's why you'll learn.
Build a compiler
This is an old standby. If you haven't written a compiler, you should. It'll get you so much closer to the metal. It doesn't have to be a full-featured compiler. It doesn't even have to compile all the way to x86 assembler (or machine code). Writing for a virtual machine is perfectly fine. You'll learn a lot regardless of the target platform. At the very least, you'll have a lot more respect for the magic that goes into modern compilers.
Whatever you decide, I wish you good luck, and keep us updated with any good project ideas you come up with or try.