There is a difference between theoretical knowledge and applied knowledge.
Programming is not just a matter of knowing the right words, its knowing how to use them.
Software is not just a bunch of munged together syntax, its problem solving encoding to instruct a computer how to execute the solution.
Writing a (non-trivial) application is not just a matter of knowing how to do it, its having the perseverance to work it to completion.
In the same way, knowing a natural language such as English "very well" does not mean that you would be able to write a good book in that language if you lack the ability to construct a convincing narrative with plausible dialogue or apply the labor necessary to produce it.
Having said that, in a more practical vein, I would suggest that rather than attempt to solve problems / write software in C++ by just opening an IDE and coding you instead spend some time off the computer thinking, and write out in your natural language a step by step solution to that problem on paper. Spend some time on paper trying to reduce your step by step solution as much as possible, removing duplication, looking for any easy abstraction, and honing it down to the bare minimum necessary to make it work. You might want to try using a modeling technique to further refine the ideas, or not, until you have a clear mental picture of the entire solution.
Only then open your IDE of choice and translate your solution into C++ (or whatever language you like). Just code it top to bottom; don't spend undo time on idiomatic expressions or premature optimizations; just get the most straightforward solution you can working as fast as you can. Test it for completeness; I like doing Unit Tests / TDD, but if that is outside your comfort zone just get some kind of feedback loop around your nascent program so you can interact with it.
Once it works, commit it to version control (or make a backup copy). Now start applying your advanced language skills (C++, whatever) and refactoring the working logic into a better design. Your test mechanism should be sufficient to allow you to feel confident you are not changing the functionality, only the implementation.
Once you get more comfortable, have a few completed applications under your belt, and have learned some things about which language features you really ended up using in the end and which didn't seem worth it or weren't really necessary you will have much more confidence and should be more able to start off at a good design rather than brute forcing and incrementally improving as you progress in your career.
All in my opinion, and your mileage may vary, of course.