Sticking with C++ is like saying "I've learnt to drive, and now I'm only ever going to drive a Mustang".
Part of being a good programmer is knowing what each language is like and the kinds of problems people typically use that language to solve. That doesn't mean you have to learn all of the syntax for it, but just enough to be able to say "Yeah, I could use perl to solve that" kinda thing.
Other aspects you can look at are design (
http://en.wikipedia.org/wiki/Unified_Modeling_Language)
If you can't create an effective design for large-scale programs, then you'll remain a cubicle grunt. At least you would be expected to be able to contribute and understand such design methodologies in the beginning, before being let loose to design your own system.
Anything over 1K lines is an ideal time to start thinking about generating small design diagrams for.
http://en.wikipedia.org/wiki/Source_control
Knowing about this will certainly help when you get to working in teams of people.
At least enough to check out, check in, branch and merge.
Learn about testing, profiling, test coverage.
Learn about Dictionary of Algorithms and Data Structures
http://www.itl.nist.gov/div897/sqg/dads/
Picking the right A+DS is critical to producing something which runs in an acceptable amount of time.
Or being able to show that whatever is proposed just isn't going to happen before the universe ends.
Learn about different methodologies, who knows which one you might end up working in.
http://en.wikipedia.org/wiki/List_of...t_philosophies