Archived

This topic is now archived and is closed to further replies.

Is it possible to combine C/C++ with Visual Basic?

This topic is 5649 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

One day I read a forum discussion about how much faster C and C++ are as compared to Visual Basic 6. In the thread, an avid VB programmer said that a VB appication can run just as fast as any C/C++ program as long as you optimize the program with C code. That''s my question: How does one do that? Is it possible? The reason I''m asking this is because I''m making a game in C/C++. The game will be in Windows, and I''m hesitant in learning the Win32 API. So, I want to make my life a tad easier by mixing the procedural code written in C with the Windows code written in VB. Please, if anyone knows how this is done, let me know. Thank you

Share this post


Link to post
Share on other sites
You can inter-operate between different languages on Windows using COM or the .NET framework. The technique of using a high-level language with lower-level optimisations is known as Alternate Hard And Soft Layers, and is a viable technique. In fact, I advocate the technique, although I''d recommend Python (or maybe Ruby) as the scripting language of choice. Using Python, the means of language integration is not quite as convoluted as COM and is portable, particularly using something like the Boost Python Library.

Share this post


Link to post
Share on other sites
The two primary ways to mix VB and C are DLLs and COM objects (which are basically DLLs with a bunch of extra stuff to handle true late binding and name discovery, etc).

So you could create your C code as DLLs and then have VB import and call into them.

Overall I think this isn''t the best way to go. Win32 API isn''t as hard to understand as people make it out to be, and you still really have to deal with it in VB. It might be simplified a bit, but not enough to take the performance hit and the hassle of having to possibly distribute the VB runtime with your game.

In the long run your life will be easier by picking one or the other. Go fully VB for ease of use or fully C/C++ for speed. Trying to mix them too much will bring out the worst of both worlds, IMO.

You might, however, want to check out SDL (www.libsdl.org) or Allegro (http://www.talula.demon.co.uk/allegro/) as both do a fair job of minimizing the amount you need to muck with low-level Win32 code.

Share this post


Link to post
Share on other sites
Wow, thanks guys! I''ll try these techniques out right away. And gmcbay, I''m only using this for myself (I''m a hobbyist) so I won''t have to worry about distributing a VB run-time. Also, game performance isn''t an issue, as this game is text only . As for using C/C++ indefinitely for Win32, I''ll give Allegro and/or SDL a look. Thank you very much guys!

Share this post


Link to post
Share on other sites
quote:
Original post by gmcbay
Win32 API isn''t as hard to understand as people make it out to be...

Just. Plain. Wrong.

Not that the API is hard to understand, but it''s inelegant and convoluted (it''s a legacy API that has grown organically). If you have easier alternatives with no drawbacks, use them.

quote:

In the long run your life will be easier by picking one or the other. Go fully VB for ease of use or fully C/C++ for speed. Trying to mix them too much will bring out the worst of both worlds, IMO.

The general consensus seems to be that using the best tool for the task simplifies development. That principle is the justification for the MSIL in .Net, and clearly the rationale for the increasing popularity of this age-old concept (mixed-language development dates back to C and FORTRAN and C and assembler). But you''re entitled to your opinions.

Share this post


Link to post
Share on other sites
If the game is text-only, just make a console application in C/C++.

Mixing VB6< & C is harder than just using C, and harder than just using VB. If you can''t get the job done in just VB... just use C. You have to understand how VB works internally, and how to code it using C. The VB crap is way more complicated than what you would do otherwise (have to use SAFEARRAYs, have to use BSTRs, can''t use unsigned types...).

If you want to do the COM thing, have a look at ATL COM tutorial
The ATL makes it pretty easy.


quote:
Original post by Oluseyi
Not that the API is hard to understand, but it''s inelegant and convoluted (it''s a legacy API that has grown organically). If you have easier alternatives with no drawbacks, use them.


Like what? X?

I thought Fortran & C linking was motivate by laziness, in that converting all the Fortran code to C would suck.

Share this post


Link to post
Share on other sites