[RESOLVED] Converting from VB to C++

[KidJavelin]

Hi everyone!

I'm a non-experienced C++ guy(still learning). Most of the stuff I've done till now has been in various Visual Basic versions. I finally got an application upgraded to VB 6.0, now it's time to think about overhauling it and putting it into C++(actually its C#(?) in Visual Studio). Is there an easy way to move forms and functions over, or will that all have to be done from scratch?

Thanks for any help!
John

[sunburnt]

C# and C++ are very different.

As for converting to C#, I would recommend running through Microsoft's VB6 to VB.NET upgrade wizard or whatever it's called, then converting to C# since as long as it's not using the legacy VB calls, the only changes should be syntactic.

Good luck!

PS, moved to the correct forum

[dreamvb]

You chould have a look around for a convertor. I know I have one that converts Visual Basic 6 to Visual C++ 6. do a serach on the net and you may find it called VB2VC++

http://www.sourceforge.net you can also find convertors.
good luck

[KidJavelin]

Does it have to be done on a .NET platform? I had to beg and plead to get Visual Studio 6.0 .

JOhn

[jmcilhinney]

Visual Studio 6 supports VB6 and VC++6, so unless you want to get a new IDE then you may as well migrate to VC++6. Visual Studio .NET 2002 supports VB.NET, C# and, if I'm not mistaken, Managed Extensions for C++, which is a pile of cr*p and best avoided from all reports. Visual Studio .NET 2003 supports VB.NET, C# and C++.NET. As said eralier, C# and C++ are two different languages, both derived from C and both supporting classes, but also quite different in many ways. I believe, although I'm not 100% sure, that you can also create unmanaged (read: non-.NET) C++ aplications in Visual Studio .NET as well.

You really need to decide which language you want to migrate to and why. A move from VB6 to C++ is a very big deal. Is there a particular reason you want to use C++? There are certainly valid reasons why you would, but I'd say that your easiest road would be to switch to VB.NET. It is quite capable of creating enterprise-level applications that are robust and efficient. The trick when coming from a VB6 background is to break out of the many bad habits that VB6 allows. VB.NET can help you to a degree in this regard but it is not as rigid as C# or C++ in enforcing good programming habits, so more resposibility falls to the developer. If you aren't sure what language you should switch to then by all means list your reasons for migrating and your requirements and see what advice people give. Frankly, a case could be made for VB.NET, C#, C++.NET and unmanaged C++, as well as other languages for that matter, but at least if you know what the pros and cons are you can make an informed decision.

[penagate]

C++ 7+ (.NET) supports the creation of both managed (.NET) and unmanaged applications. As jmcilhinney said, both support OO etc., although unmanaged C++ allows multiple inheritance, which .NET does not support. The Managed Extensions for C++ are indeed a pile of crap, but VC++.NET 2005 adds a proper syntax for managed applications, to the extent that it is a decent language in its own right (although quite different to unmanaged C++), and more powerful than C#.

After coming from VB6, I found it easier to work in C# than VB.NET. VB.NET is similar enough to VB6 to look familiar, but different enough that it requires re-learning, and is easily (and wrongly) confused with VB6. But that's just my personal opinion.

[jmcilhinney]

VB.NET is similar enough to VB6 to look familiar, but different enough that it requires re-learning, and is easily (and wrongly) confused with VB6.

I completely agree, and I've often advised people to assume that everything in VB.NET is different to VB6 and consider it a bonus if something turns out to be the same. Easier said than done though. If you switch to C# or something else then you are forced to abandon VB6 ways. By the easiest option I meant that the upgrade wizard could handle much of the work and then you could over time change the code that used the Microsoft.VisualBasic.Compatibility namespace, then start on the Microsoft.VisualBasic namspace if you wanted. Although I've never used it, I've not heard good things about the wizard when applied to entire projects, so maybe that would be false economy anyway.

[penagate]

I have tried various "Upgrade" wizards and usually they spit out error-ridden code that relies completely on the Compatiblity routines. I suggest, if you are going to learn .NET, do it properly and start from scratch. It's far easier and you will save yourself the hassle of gradually un-learning all the VB6 compatibility parts of the framework once you decide to move to core .NET routines.

The best the upgrade wizard does is show you examples of how things look in the new syntax, but that's a standard part of learning a new language anyway. And syntax isn't a big issue: once you know good programming techniques, picking up a new language is just a matter of applying those same techniques using the details of that language. Considering the .NET class library is fairly massive, getting used to using this is the biggest part of moving to .NET, but it's all pretty logically laid out really.

[KidJavelin]

The intent was originally to move the application to unmanaged C++. After we made the purchase of Visual Studio I was putting in serious thought about reccomending a move to the Visual C(++?) that it has.

Moving the app to unmanaged C++ was intended to "Free it" from certain version dependancies that could become pitfalls later on. And it was a preference by those in power, I suppose so it could be run on many O/Ss and platforms with minimal rewrites. While it's not an enterprise level application, it just may be used at a couple of different job sites in the future.

Am I making any sense to anyone?
John