Archived

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

Flaight

VC++ & VB together?

Recommended Posts

This may be a stupid question for some of you, but here goes... Is it possible to write a function / module in one language and use it in the other? Say, like, if you write a CPU intensive code in VC++, then call that function in VB which you use to make UI. Or something like that. Or is it a profoundly stupid idea I should not have mentioned?

Share this post


Link to post
Share on other sites
Yes. Most people do it by writing a dll in C++ which they call from within VB. Remember that there is a little bit of overhead when calling a dll, so if you don''t design it properly, it can end up being slower. A lot of the time it is better to just optimise it a lot in VB.

Trying is the first step towards failure.

Share this post


Link to post
Share on other sites
That was a primary motivation for the development of COM & ActiveX.

.Net takes this a step further, and further integrates inter-language operability.

Magmai Kai Holmlor

"Oh, like you''ve never written buggy code" - Lee

[Look for information | GDNet Start Here | GDNet Search Tool | GDNet FAQ | MSDN RTF[L] | SGI STL Docs | STFW | Asking Smart Questions ]

[Free C++ Libraries | Boost | ACE | Loki | MTL | Blitz++ | wxWindows| Spirit(xBNF)]

Share this post


Link to post
Share on other sites
Thank you to both of you, things make a lot more sense now.


quote:
Original post by Magmai Kai Holmlor
That was a primary motivation for the development of COM & ActiveX.

.Net takes this a step further, and further integrates inter-language operability.



I understand that .net is a new innovation, but regarding the DLLs, COM and Activex which I do know have been around for ages now, what are the pros and cons of using them as the means of inter-language programming? I mean, are there any guidelines on how to decide what to use?

Share this post


Link to post
Share on other sites
Straight .DLL calls have lower overhead than COM calls, but are easier to mess up.

If you create a COM DLL for use in Visual Basic, make sure you early bind (declare your object as the type of the object, instead of type Variant), and if you're using Visual Basic 6, make sure you split up your declaration and object creation.

In other words, do this:

Dim MyObject As CMyObject
MyObject = New CMyObject

instead of:

Dim MyObject As New CMyObject

In VB6, the first one adds object creation code once. If you do the latter, it adds object creation code to every reference to the object, and every time you reference the object, it checks to see if that object variable is a valid reference, and if it isn't, it creates the object.

In VB.NET, you can do it either way without worrying about the overhead.

Finally, to optimize your calls, make chunky instead of chatty calls. In other words, pass lots of data to be processed at once instead of calling your DLL/COM object once for each little piece of data.

[Edit: Fixed syntax issue.]

[edited by - RomSteady on August 18, 2002 1:06:45 AM]

Share this post


Link to post
Share on other sites
RomSteady: I haven''t played with VB.NET at all, but I''m just wondering how it can avoid the overhead. I''m guessing it creates the object as soon as it is declared, or is it something more high tech than that?

Trying is the first step towards failure.

Share this post


Link to post
Share on other sites
Ahuh ... *sweats*

Hmmm ... I think I might stick to straight VC++ and do this in MFC. To cut long story short, I''ve been planning to make a scenary editor and save as my own format. C/C++ has been the language of my choice for years now.

It''s just that lately I was suggested by someone something along the line of "why not write UI in VB? VB is so much easier to use when it comes to UI.". Programming is only a hobby so I never really had the necessity to do this so I didn''t know. but I thought I would take this oppotunity to "venture" out into areas unknown to me.

Thanks all for the clues... I still don''t know whats best to be honest, but it sounds like a load of hassle to bother mix the two. Or is there a clear advantage in doing different components in different language?

I guess there is... otherwise it would not exist, would it. God this is confusing. lol.

Share this post


Link to post
Share on other sites
flipcode.com: A lesson on interfacing VC++ and VB using DLL''s. This should get you started http://www.flipcode.com/articles/article_vbdlls.shtml

Share this post


Link to post
Share on other sites
quote:
Original post by Kyo
flipcode.com: A lesson on interfacing VC++ and VB using DLL''s. This should get you started http://www.flipcode.com/articles/article_vbdlls.shtml


Many thanks Kyo, I will take a look =)

So how regular or good practice is it to make a front-end with VB then? It''s that common?

Share this post


Link to post
Share on other sites
quote:
Original post by ragonastick
RomSteady: I haven''t played with VB.NET at all, but I''m just wondering how it can avoid the overhead. I''m guessing it creates the object as soon as it is declared, or is it something more high tech than that?


Let''s say you have an object called MyObject which you declare in VB6 and VB.NET as:

Dim Obj As New MyObject

MyObject has a method called Blah, which takes a single parameter. In both VB6 and VB.NET, you would call it like this:

Obj.Blah(x)

In VB.NET, the code generated would be exactly what you entered. In VB6, however, the code generated would end up like this:

If Obj Is Nothing Then
Set Obj = New MyObject
End If
Obj.Blah(x)

There is extra code placed before each call to Obj to ensure that Obj is actually created, since in VB6, when an object is Dimmed as a new object, the object isn''t created until it is first used. In VB.NET, it''s created as soon as it''s Dimmed.

In VB6, it is best to split references like this to get rid of that overhead:
Dim Obj As MyObject
Set Obj = New MyObject
Obj.Blah(x)



RomSteady - Test Locally, Test Globally, Test Early, Test Often

Share this post


Link to post
Share on other sites