Question

:D

That's funny!

A few thoughts on the notion of translating C++ into VB.NET.

Why? I can think of a few reasons, sure, but what it your motivation?

The objects in C++ aren't always directly translatable into Visual Basic concepts, so a lot depends on the nature of the C++ design as to how smooth or rough the experience may be.

I think, too, that the act may be labeled less of a 'translation' and more of a 'rewrite'.

Translation into Java or C# might be a little easier, but much still depends on the nature of the C++ design. Templates, for example, wouldn't translate that well, so a considerable amount of redesign might come into play.

It seems to me, too, that one must understand C++ fairly well in order to 'read' source code such that a translation or redesign can be expressed as C# or Visual Basic code, which then raises an issue. If the primary motivation to translate were greater familiarity with VB, the familiarity required with C++ favors the notion of, perhaps, moving the C++ into C++/CLI - a much more direct move that subsequently brings .NET access into the application.

I image a scenario where a C++ programmer is hired to produce a product, and completes a substantial portion but the end result is not complete, or there is now an interest to produce an updated version.

The original C++ developer isn't available, and the new developer or staff thereof isn't as familiar with C++, or thinks C++ was the wrong choice, and wants to move into a .NET language, Visual Basic being one of the natural choices for many.

The choice boils down to cost. In my view, anyone very familiar with a .NET language would do about as well to interpret the application by it's operation, redeploying the application in the target language, rather than perusing the source and making a translation from that perspective. There may be occasional references to the source for some difficult algorithm, if any exist, but the general approach to making an application is different enough between these paradigms that, if I were engaged in the reverse (making a C++ version of a Visual Basic application), that's the approach I'd be motivated to use.