Since I work on it, I'm about as biased as you could get when it comes to EA code engineering, but I've had success with forward engineering C++.
How you need to work will vary if you choose to synchronise or overwrite files.
If you're synchronising you have the advantage that not everything in each file needs to be modelled, but EA won't maintain your #includes and your templates have to match what the parser imports or you can run into trouble. You'll also find that modifying attribute/method signatures requires you to tell EA what to do. This is also dependant on an option (Tools | Options | Attribute/Operations | On forward synch, prompt to delete code features not in model) although the need can be aleviated by enabling live code generation for your package.
If you're overwriting you need to model more, use more customized templates and there is probably more risk of losing work. However, it is an advantage if everything is generated straight from the model. My standard procedure for doing this is to create a diagram for each class to show its relationship to everything. Dependencies for #includes in .cpp file, add an <<extern>> stereotype to define an extern. I add the class and incrementally add attributes/links/methods and generate. For generating the method body I cheat a bit. After generating I'll write the method body in code, and reverse engineer it. (With the relevant option turned on.) That way when I next generate from the model all method bodies are generated as I last had them, and I don't need to use the 'initial code' field in EA.
The EA user group has my templates for generating namespace members (attributes/methods), I also have some modified templates for MFC specific generation and a bit of other stuff, I can put these up too if needed.
I've used both of these methods with success. I'm generally only modifying one or two classes at a time, so the total size of the project doesn't make much difference.
I hope you'll find my comments useful. If you have any more questions let me know.
