Member Avatar for winrawr

So, supposing I do manage to compile a DLL with exports, how does the DLL work with my code? How would I check for the DLL on the system, and then, how would I link to it?
Also, Can a DLL written in C++ be used in a VB application?
I'm trying to write a script interpreter... sort of like python actually... Basically I want a DLL that a program can link to that will parse lines of code, or run through a script and parse each line, etc. and for each function that the script calls, there will be an equivalent function that the program calls to carry out that function. But I want the ability to add functions to the language from the application that will be using the DLL, would functions of different languages be compatible?
Like,

vb program                dll
----------------------------------------------------
send code to dll----->    parse code
                              |
                              v
                          code contains a function,
                          that isn't contained in the DLL
                              |
list of functions in   <------/
program
      |
      v
corresponding function,
user-defined in the
VB program--process the
passed argument here
      |
      \-------------->    return value sent back
                          to the parsing function

am I able to call functions between DLL and program, regardless of the language the program using the DLL is written in? Is there anything special about returning values back and forth between DLLs? can it be just like if the functions were all contained in the same code?
What can I not do if I expect the DLL to be portable between languages?
My main concern is like, if I have the parse function in the DLL, int parse(char* value); and then try and call it from visual basic, which doesn't (to the extent of my knowledge) have a char data type, what would happen? are the C++ string data type and the VB string data type interchangeable?

What if, in the DLL, I had a

class interpreter01{
...
} interpreter;

when I linked to the DLL, would "interpreter" of type "interpreter01" be available to the program already?
Right now my basic idea of a DLL is more or less equivalent to an #include statement.

  • 3 Contributors
  • 4 Replies
  • 105 Views
  • 2 Days Discussion Span
  • Latest Post Latest Post by Freaky_Chris

Dani AI

Generated

A concise, practical primer that fills the gaps in the thread (building on and ):

C++ DLLs can be used from VB, but the interoperability rules matter. The common, robust patterns are (a) export a plain C-style API (no C++ objects in the ABI), or (b) expose a COM/ActiveX object, or (c) provide a managed wrapper (C++/CLI) for .NET. Exporting raw C++ classes is brittle (name-mangling, compiler/CRT differences) and should be avoided if you want language portability.

A recommended, simple pattern is the opaque-handle wrapper: keep your interpreter as a C++ class inside the DLL, and export C functions that create/destroy the object and call methods. This hides C++ ABI details and is easy to call from VB or any language that can call native DLLs:

/* native DLL (C++) */
class Interpreter { public: int Eval(const char* src); };

extern "C" __declspec(dllexport) void* __stdcall Interpreter_Create()
{ return new Interpreter(); }

extern "C" __declspec(dllexport) void __stdcall Interpreter_Destroy(void* h)
{ delete static_cast<Interpreter*>(h); }

extern "C" __declspec(dllexport) int __stdcall Interpreter_Eval(void* h, const char* src)
{ return static_cast<Interpreter*>(h)->Eval(src); }

Call patterns from the host:

' VB6
Declare Function Interpreter_Create Lib "Interpreter.dll" () As Long
Declare Sub   Interpreter_Destroy Lib "Interpreter.dll" (ByVal handle As Long)
Declare Function Interpreter_Eval Lib "Interpreter.dll" (ByVal handle As Long, ByVal src As String) As Long
' VB.NET
<DllImport("Interpreter.dll", CallingConvention:=CallingConvention.StdCall, CharSet:=CharSet.Ansi)>
Shared Function Interpreter_Eval(handle As IntPtr, src As String) As Integer
End Function

Practical cautions: match bitness (32/64) or the DLL will not load; avoid passing STL objects or C++-allocated memory across the boundary; pick and document string encoding (ANSI vs Unicode); use extern "C" and a stable calling convention (stdcall or cdecl) to avoid name-mangling issues; consider LoadLibrary/GetProcAddress for optional/late binding. For extensibility (user-defined functions) expose a registration API that accepts function pointers (or use COM/delegates for .NET), rather than trying to expose C++ methods directly. These patterns let your interpreter be language-agnostic and safe to use from VB.

Recommended Answers

All 4 Replies

Member Avatar for Stefano Mtangoo

I'm not too far in C++ but most DLL stuffs, I read when I was learning Python's ctypes. Many of your questions seems to have Yes answer but again not solid in C++ and DLL. One question I can boldly answer

Can a DLL written in C++ be used in a VB application?
Answer is YES but I remember there is a little declaration stuffs.

Member Avatar for winrawr

hmm that's good...how would I implement it though?

Member Avatar for winrawr

anyone know just the basics of compiling a dll which exports a class and a function? Just like a short code? Also how to write the exports file

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.