I'd call that "7 years experience". If you're going to take a C++ job, just let them know there will be a short ramp-up period. If they're a good employer, they'll be fine with that. If they'll be a shitty employer, they'll not offer you the job and you didn't want it in the first place because they would make your life hell.

Measuring competency is hard. It's the same sort of thing as asking a mechanic, "How much experience do you have with wrenches?" or, "How much experience do you have with jack stands?" It's wholly possible to work with C++ exclusively for ten years and still be bad at it. Furthermore, a good mechanic can get dropped into an unfamiliar shop, and within a day or two they'll be humming away nicely, where a shit mechanic would never quite get his footing no matter how much he's got going for him.

My personal recommendation, in this case, is to try to quantify your experience in achievements instead of in 'years' or 'volume' of experience. Providing specific examples of stuff you've done in C++, explaining the domain of the problem you solved--those things tend to be the things that really raise eyebrows.

For myself, for example, I would discuss my most recent work by saying that I 'began educating myself in functional programming as soon as Swift was announced by Apple, and began applying my knowledge to the app on which I work immediately. When Swift 2.0 was announced the following year, I applied its new features to the software I had been writing, and we began integrating my code as the basis of the application the day after Xcode 7.0 Final was released".

That explains how I recognized the applicability of a new tool to an old task, how I went about validating my knowledge while still doing my day job, and how ultimately my solution was recognized as useful by my colleagues and superiors and went into production. Soon, once we've released the code, I'm going to chase down some numbers about how my code's improved our stability.

In your case, as a consultant, I would go back and ask your clients. Ask them, "could you tell me a little bit about how the work I did on _______ project helped you out?" You'll find, if you've done a good job and worked with nice people, that they'll happily tell you about how you did great work that really helped their business. Then, somebody reading your code isn't thinking in terms of, "This guy gets up and running in new languages pretty quick, I bet he could handle this". They're thinking in terms of, "This guy boosted the profits of every company he worked with, and now he's going to boost mine."

It's a two-way street. The recruiter should make sure they get the information they need from the applicant. For example in interviews, in the C++ case, we ask about the systems, the size of the code base, how many in the team, the individuals role in the team, then we focus on language specifics like design patterns. Together with all the other questions we should get a good idea as to the competence of people. In short, the CV should be the entry point to the interview and the experience should be explained in context.