c++ help in visual studio please!

[monoman]

Hi,

First off, i'll explain that I know absolutely nothing about c++, I've programmed in vb6 and have taught myself vb.net recently.

I need to create a c++ dll that a vb.net project can access. It will pass it a string filename and the dll will return a string result.

I found a c++ program (*minihost) on the internet that I managed to get working that provides the information I want.

This is what's in *minihost

Folder = interfaces
aeffect.h
aeffectx.h
vstfxstore.h

Folder = SourceFiles
minihost.h

It's a stand alone program, though, and I need to convert it into a dll so that instead of writing the output to screen, it will put it in a property that I can acces in my vb.net project.

So.... I found an example CLR Class library on the internet that adds some maths functions. Here's some sample code from it:-

MathFuncAssembly.h


using namespace System;

namespace MathFuncs {

public ref class MyMathFuncs
{
public:
// Returns a + b
static double Add(double a, double b);

etc MathFuncAssembly.cpp

namespace MathFuncs
{
double MyMathFuncs::Add(double a, double b)
{

return a + b;
}

etc (This has nothing to do with what i'm after but i'm just trying to get it to work)

Next I added my class minihost.cpp and aeffect.h, aeffectx.h & vstfxstore.h

This compiles fine.

The next step is to try and call the main function in minihost.cpp to get the output I need. I've no idea how to do this. Do i need to add a minihost.h so I can reference it?

Sorry this is vague. If you need some code samples i'll copypasta them in.

Cheers

[shadron]

All you need to do is to separate the dll source into a separate project (create a new project within the solution, and move the source for the dll into that project). You will move the interface (.h) file as well, but remember you are only moving references to those files. The reference to the .h file will also remain in the main project, though the source code reference (.c) will not. In the dll project, you need to edit the project's property to create a .dll instead of a library or executable. In my copy of MSVS .net (2004 - a bit old, I'm afraid) the setting is on the project's General tab, called "Configuration Type". You also need to select a compatible source type in the C++->code generation tab, select one of the dll forms of code - if it is set to single thread debug, switch it to single thread debug dll, for instance. Compile them both, and you should now have project.exe and project.dll. Test it in that configuration.

The one thing you have to be careful about is that classes that are shared by the main and the dll don't reside in the same memory space, so passing those classes by reference or by pointer won't work. See, for example, http://msdn.microsoft.com/en-us/library/aa263530(VS.60).aspx (http://msdn.microsoft.com/en-us/library/aa263530%28VS.60%29.aspx) or google up other explanations about what you want on the web.

I've never tried to interface vb with c++; you may have to consult the web for the proper code generation settings. Good luck with our class - at least, I can't think of why anyone would want to unnecessarily use a dll unless it was assigned in a class. :)

[monoman]

Thanks shadron,

I've managed to create the dll and reference to it in a vb.net app.

I just can't believe i managed to do it. It's taken hours just to find out how to do the equivalent of:

Dim myString as String!

As it happens, I went with - System::String^ myString;

Is this correct?

[aggle-rithm]

I need to create a c++ dll that a vb.net project can access. It will pass it a string filename and the dll will return a string result.


Ha, ha! Good luck!

[aggle-rithm]

Thanks shadron,

I've managed to create the dll and reference to it in a vb.net app.

I just can't believe i managed to do it. It's taken hours just to find out how to do the equivalent of:

Dim myString as String!

As it happens, I went with - System::String^ myString;

Is this correct?

I haven't attempted to do this for a few years, but I've found that you need some sort of binary structure in Visual Basic to read a string from C++...I assume you're using a C-string and not a string object in the unmanaged code. That would almost certainly not work.

The problem is that Visual Basic does its best to shield you from the pointers that are the bread-and-butter of C++. Any kind of low-level work with individual bytes/bits is like trying to thread a needle with boxing gloves on.

[shadron]

It works for me, except I don't recognize the ^ operator - sure you're not using C# rather than C++? Better yet, do you understand what it all means, rather than just parrotting it from somewhere else? That's the key.

If you're going to use a language you have to get used to the syntax conventions they use. I went from C to VB, and find DIM... to be incredibly wordy, particularly when you can't make four variables strings without repeating "as String, " four times. Incredible.

[aggle-rithm]

Dim myString as String!



This declaration really excited you, didn't it?

;)

[aggle-rithm]

It works for me, except I don't recognize the ^ operator - sure you're not using C# rather than C++?


Yes, there is a HUGE difference between C++ and C#. There shouldn't be any trouble at all mixing VB and C# code; I do it all the time.

[shadron]

I haven't attempted to do this for a few years, but I've found that you need some sort of binary structure in Visual Basic to read a string from C++...I assume you're using a C-string and not a string object in the unmanaged code. That would almost certainly not work.

The problem is that Visual Basic does its best to shield you from the pointers that are the bread-and-butter of C++. Any kind of low-level work with individual bytes/bits is like trying to thread a needle with boxing gloves on.

I'd concur on that. In C you can grab a character out of the middle of a string (actually a zero-terminated character array) with a single dereference operation , and I can understand that. Having to use mid$ to do the same thing seems very arcane, but as Aggle says, VB is trying to make it easy on the casual user by making it clumsy for the knowledgeable users - or at least, that's the way some of us chauvinists look at it. :)

[monoman]

It works for me, except I don't recognize the ^ operator - sure you're not using C# rather than C++? Better yet, do you understand what it all means, rather than just parrotting it from somewhere else? That's the key.

If you're going to use a language you have to get used to the syntax conventions they use. I went from C to VB, and find DIM... to be incredibly wordy, particularly when you can't make four variables strings without repeating "as String, " four times. Incredible.

Well, it says Visual C++ 2008 Express at the top so I guess so. Though I did install C# first and then when I installed C++ it seemed to overwrite my C#.

I have no idea what it all means, I'm just parroting. I don't have the time or inclination to learn C++, I just needed to create this dll because it's impossible to do what I needed to do in VB.Net.

In VB.Net you can declare Dim str1, str2, ...., strn as String
In old VB, you couldn't because it stupidly declared the first lot as variants.

[monoman]

I haven't attempted to do this for a few years, but I've found that you need some sort of binary structure in Visual Basic to read a string from C++...I assume you're using a C-string and not a string object in the unmanaged code. That would almost certainly not work.

The problem is that Visual Basic does its best to shield you from the pointers that are the bread-and-butter of C++. Any kind of low-level work with individual bytes/bits is like trying to thread a needle with boxing gloves on.

What's this C-string? I tried to use it earlier but the compiler didn't recoginize it. Do i need a #Include <somestringstuff.h> ?

(I think you're beginning to realise how little I know about this - which makes it all the more surprising that it ****** worked!)

[aggle-rithm]

What's this C-string? I tried to use it earlier but the compiler didn't recoginize it. Do i need a #Include <somestringstuff.h> ?

(I think you're beginning to realise how little I know about this - which makes it all the more surprising that it ****** worked!)

No, a C-string is just a pointer to a string of 1-byte unsigned characters. I think the standard header file that it requires is usually included as a default.

With a string object where you would do this:

Dim myStr as String = "Hello, World"

You would have to do this with a c-string:

char myStr [] = "Hello, World";

or

char *myStr = new char[12];
strcpy(myStr, "Hello, World");

The variable myStr in C++ would be of a fixed size. If you wanted to assign something else to it you would have to make sure the string can accommodate the new value; if not, you would have to manually allocate more memory.

String objects have wrappers around them that hide the complexity from the user, but it makes it more difficult to toss them around between modules. With C strings, you just have an array of raw data that is readable from many different platforms.

[Terry]

The ^ thingie means it is managed C++ not native C++, it denotes a managed pointer. At least, that's my limited understanding. I use C# for managed code, and only do "real binary" C++.

[ddt]

What's this C-string? I tried to use it earlier but the compiler didn't recoginize it. Do i need a #Include <somestringstuff.h> ?


No, a C-string is just a pointer to a string of 1-byte unsigned characters. I think the standard header file that it requires is usually included as a default.

With a string object where you would do this:

Dim myStr as String = "Hello, World"

You would have to do this with a c-string:

char myStr [] = "Hello, World";

or

char *myStr = new char[12];
strcpy(myStr, "Hello, World");

As soon as you use a standard library function like strcpy, you indeed have to start your file with

#include <string.h>

That means you include some so-called prototypes of the functions from the standard library. Those prototypes tell the compiler what types the arguments of the functions have.

This stuff, btw, is basic C stuff and not special to C++. The whole business with character arrays as told by aggle-rithm is unneeded in C++, as it has a special 'string' class which takes care of all that cruft. I guess the class System::String you're using is similar to that, but then a Microsoft extension. (and I know nothing about that).

[shadron]

No, a C-string is just a pointer to a string of 1-byte unsigned characters. I think the standard header file that it requires is usually included as a default.

With a string object where you would do this:

Dim myStr as String = "Hello, World"

You would have to do this with a c-string:

char myStr [] = "Hello, World";

or

char *myStr = new char[12];
strcpy(myStr, "Hello, World");

The variable myStr in C++ would be of a fixed size. If you wanted to assign something else to it you would have to make sure the string can accommodate the new value; if not, you would have to manually allocate more memory.

String objects have wrappers around them that hide the complexity from the user, but it makes it more difficult to toss them around between modules. With C strings, you just have an array of raw data that is readable from many different platforms.

Ummmmm, Aggle, I hate to be the first to point this out but the string is 13 long, not 12. Null byte. :D

[shadron]

The ^ thingie means it is managed C++ not native C++, it denotes a managed pointer. At least, that's my limited understanding. I use C# for managed code, and only do "real binary" C++.

Thanks, Terry. I do mainly SDK C++ and stay away from the yucky parts of C++ arcania. Of course, that means I'm always behind trying to pick them up later. I understand that .net programming is managed, so it's probably in my future, willy-nilly.

[shadron]

As soon as you use a standard library function like strcpy, you indeed have to start your file with

#include <string.h>

That means you include some so-called prototypes of the functions from the standard library. Those prototypes tell the compiler what types the arguments of the functions have.

This stuff, btw, is basic C stuff and not special to C++. The whole business with character arrays as told by aggle-rithm is unneeded in C++, as it has a special 'string' class which takes care of all that cruft. I guess the class System::String you're using is similar to that, but then a Microsoft extension. (and I know nothing about that).

Yeah - the "System" is a namespace or class identifier, and String is essentially the equivalent to the older MFC CString class. As ddt says it "removes the cruft", but it also moves you one step away from the native C baseline, trying to get you to stop using pointers, which are only used by Real Debuggers.

[wuschel]

aeffect.h
aeffectx.h
vstfxstore.h


Just a pointer (ignore pun):

http://www.kvraudio.com/forum/viewforum.php?f=33

...for all your VST programming needs.

ETA: ...unless you're "piman", of course, and this is old news to you

[a_unique_person]

Why does it have to be C++? In .net, most of what you can do in C++ can be done in C# or VB now.

[monoman]

Just a pointer (ignore pun):

http://www.kvraudio.com/forum/viewforum.php?f=33

...for all your VST programming needs.

ETA: ...unless you're "piman", of course, and this is old news to you

That would be too much of a coincidence!

That's me. I actually removed those interface headers because they weren't needed. No idea why they were there in the first place - maybe just for reference?

[monoman]

Why does it have to be C++? In .net, most of what you can do in C++ can be done in C# or VB now.

I'm accessing some classes written in C++. As far as I can tell, reading on the internet, this needs to be done in C++.
The classes are uncompiled in the form of aeffectx.h, aeffectx.cpp etc.

They're old classes written by steinberg for the cubase VST plugin specification.

Have I just wasted a day??????

Anyway, it's been a good learning experience and I have a fully working dll I can now reference in VB.Net and retrieve all the Plugin info I need.

[a_unique_person]

I'm accessing some classes written in C++. As far as I can tell, reading on the internet, this needs to be done in C++.
The classes are uncompiled in the form of aeffectx.h, aeffectx.cpp etc.

They're old classes written by steinberg for the cubase VST plugin specification.

Have I just wasted a day??????

Anyway, it's been a good learning experience and I have a fully working dll I can now reference in VB.Net and retrieve all the Plugin info I need.

Yes, it does have to be C++ then. Unless you feel like recoding them, but if you have it already working, then that's probably good enough.

[aggle-rithm]

Ummmmm, Aggle, I hate to be the first to point this out but the string is 13 long, not 12. Null byte. :D

Sorry, using .NET for so long has softened my brain.

[aggle-rithm]

This stuff, btw, is basic C stuff and not special to C++. The whole business with character arrays as told by aggle-rithm is unneeded in C++, as it has a special 'string' class which takes care of all that cruft.

I always used C-strings with C++, at least on low-level processing of text. I only used string classes for high-level, user-interface stuff.

There are just some cases where it's easier to deal with raw data than with wrappers, and I think interfacing with a C-style DLL is one of them.

[aggle-rithm]

Why does it have to be C++? In .net, most of what you can do in C++ can be done in C# or VB now.

Speed? Machine code runs about ten times faster than the jitter.

[wuschel]

That's me.
Thought so. I've also seen your comment over there at KVR summarizing your feelings about C++ (or C for that matter) ;-)

VST is pretty much a real time API and if you're going to dive deeper into this kind of stuff, you better get accustomed to the concept of pointers that point to real memory, the obligation to do your own memory management instead of having an automatic garbage collector doing the dirty work for you... and so on.

Usage of C++ is not compulsory, as it is not the only OO language that can be used to generate native code.

Anyway, there also is a reward to coping with all this "low level"(*) stuff: After a while, you will get a better understanding as towards how computers really work.

(*) I'm writing mainly assembler code for a living, and henceforth calling C++ "low level" is a bit in the eye of the beholder, so to speak...

[BigR]

The ^ thingie means it is managed C++ not native C++, it denotes a managed pointer. At least, that's my limited understanding. I use C# for managed code, and only do "real binary" C++.

You are correct. I believe the OP's code is in Microsoft's C++/CLI implementation, which is not standard C++.


char *myStr = new char[12];
strcpy(myStr, "Hello, World");

The variable myStr in C++ would be of a fixed size. If you wanted to assign something else to it you would have to make sure the string can accommodate the new value; if not, you would have to manually allocate more memory.


FYI, the C++ Standard Template Library provides a string class that performs memory management internally. If you include the header file <string>, you could write the above with a string object; you could also assign a longer string to the variable without reallocating, and if you need a C-style character pointer, string provides the c_str() method:


#include <string>

void foo()
{
std::string my_string( "Hello World!" );
my_string = "This is a much longer string than Hello World!";
const char *some_pointer = myStr.c_str();
}


I've found a good rule of thumb is to use string over the the C-style strings unless absolutely necessary, as it removes the possibility of potential buffer overrun and other pointer gotchas.

[NewtonTrino]

C++ is still pretty low level for the most part. I can mostly guess what the asm output is going to be like from looking at it. Some C++ code that is crazy heavy with templates, auto conversions etc can of course run like a pig. Using c-strings these days is pretty stupid just due to the amount of security bugs you will create. Best to use a standard string class and if you need to pass it into something external pass it as a .c_str(). If you need a lot of speed you can create a custom implementation of a string that handle allocations in a way specific to your application.

Overall unmanaged C++ is dying from what I can tell.

[BigR]

C++ is still pretty low level for the most part. I can mostly guess what the asm output is going to be like from looking at it. Some C++ code that is crazy heavy with templates, auto conversions etc can of course run like a pig. Using c-strings these days is pretty stupid just due to the amount of security bugs you will create. Best to use a standard string class and if you need to pass it into something external pass it as a .c_str(). If you need a lot of speed you can create a custom implementation of a string that handle allocations in a way specific to your application.

Overall unmanaged C++ is dying from what I can tell.

C++ code is only low level if you write it to be low level. Using classes, the STL, and RAII coding practices, you can write applications that are as "high level" as any managed language. (Conversely, you can write code that is very low level using the same techniques.) Garbage collection is available through several libraries, if that's a requirement.

I've seen the claim that "C++ is one its way out" for 10 years now, but it's not going anywhere. In fact, a brand new ISO standard is slated to be released next year, greatly increasing the capabilities of the language.

Like all languages, C++ is merely a tool. Sometimes it is the best tool for a job. Other times, C# or Java or some other language is. Don't get drawn into marketing hype for any particular language. The trick is knowing what language is best for each particular problem.

[aggle-rithm]

FYI, the C++ Standard Template Library provides a string class that performs memory management internally.


Yeah, but I was using Borland C++ Builder when I did most of my C/C++ development, and it made it difficult to use templates (at any rate, templates weren't part of its "culture" of libraries).

[aggle-rithm]

Like all languages, C++ is merely a tool. Sometimes it is the best tool for a job. Other times, C# or Java or some other language is. Don't get drawn into marketing hype for any particular language. The trick is knowing what language is best for each particular problem.

The last time I used C++ was to get access to MAPI folders without having a security message box pop up, as it does when using the .NET libraries.

[monoman]

Thought so. I've also seen your comment over there at KVR summarizing your feelings about C++ (or C for that matter) ;-)

VST is pretty much a real time API and if you're going to dive deeper into this kind of stuff, you better get accustomed to the concept of pointers that point to real memory, the obligation to do your own memory management instead of having an automatic garbage collector doing the dirty work for you... and so on.

Usage of C++ is not compulsory, as it is not the only OO language that can be used to generate native code.

Anyway, there also is a reward to coping with all this "low level"(*) stuff: After a while, you will get a better understanding as towards how computers really work.

(*) I'm writing mainly assembler code for a living, and henceforth calling C++ "low level" is a bit in the eye of the beholder, so to speak...

I used to program in assembly language years ago on my acorn electron. Since then it got easier with pascal at uni and RPG at work. I've taught myself vb6 and now vb.net.
I'm not planning on writing any VST plugins just yet for which i'd probably need C++ for the speed.
At the moment i'm just adding some functionality to a utility I wrote a couple of years ago.

To be honest, C++ scares the **** out of me but I think that's mainly down to the unfamiliar syntax!

Anyway, back to me needing help :)

I have a vb.net program that loops through an array of files and calls my dll (written in c++) for each file.
This works except I get a screen that pops up saying:

"[MyProgram].vshost.exe" has encountered a problem and needs to close...etc"

Please tell Microsoft about this problem blah blah.

Now, the wierd thing is:-

(1) I can ignore the window and leave my program running and it will complete just fine.
(2) If I debug and step through a couple of the array items where the problem occurs, there is no problem. After a few I press F5 and it completes.

It seems like something's filling up before it has time to empty??? I have a feeling I've had a wierd bug like this before where it went away if I slowly debugged it but I can't for the life of me remember what it could have been.

Please tell me someone has had this problem!

Cheers

Jules

[ddt]

To be honest, C++ scares the **** out of me but I think that's mainly down to the unfamiliar syntax!

I know next to nothing about the peculiarities of Microsoft's extensions to C++. But when it comes to core C++, I'd advise to pick up a book on it to get familiar with it. The obvious choice is Bjarne Stroustrup's "The C++ programming language" - he invented the language, and it the next authoritative next to the official (unreadable) standard.

[aggle-rithm]

Now, the wierd thing is:-

(1) I can ignore the window and leave my program running and it will complete just fine.


The error is being generated by the dll, not the main program, so it's memory space isn't affected.


(2) If I debug and step through a couple of the array items where the problem occurs, there is no problem. After a few I press F5 and it completes.

It seems like something's filling up before it has time to empty??? I have a feeling I've had a wierd bug like this before where it went away if I slowly debugged it but I can't for the life of me remember what it could have been.

Please tell me someone has had this problem!

Cheers

Jules


It sounds like the problem is the rapid-fire calling of the dll without waiting for each one to complete. If you step through the code, the dll has time to execute between each iteration, but if not, the calls pile up on each other. (This is assuming that the calls are asynchronous, as they probably would be unless you set up a callback function.)

I'm not sure exactly how this would be causing the problem, it depends on how the dll is written.

[monoman]

The error is being generated by the dll, not the main program, so it's memory space isn't affected.




It sounds like the problem is the rapid-fire calling of the dll without waiting for each one to complete. If you step through the code, the dll has time to execute between each iteration, but if not, the calls pile up on each other. (This is assuming that the calls are asynchronous, as they probably would be unless you set up a callback function.)

I'm not sure exactly how this would be causing the problem, it depends on how the dll is written.

That sounds promising but i'm not creating any new threads.

It goes something like this

1. For each PluginPath
2.
3. Dim PluginInfo as New VstHelpers.VstInfo(PluginPath)
4.
5. PluginName = PluginInfo.Name
6. PluginCategory = PluginInfo.Category

etc

Next PluginPathVstHelpers.VstInfo is the c++ dll.

Am i wrongly assuming that Line 5 won't execute until the dll has finished executing on line 3?
Actually thinking about it, it must wait, at least for that instance. But maybe it's creating multiple copies of the loop and ..... erm...i'm lost :confused:

ETA: I'll try putting in a couple of seconds delay between calls and see what happens

[monoman]

Ok, putting the delay in helped me see that it's always the same plugin that causes the problem.
If I delete this plugin, the rest are analysed with no problem.

So, it seems it's not some wierd stacking up issue.

However, the strange behaviour still exists that if I break the code when on this plugin and step through the c++ dll, it doesn't crash.

Wierd!

Any thoughts?

[monoman]

I've narrowed it down slightly.

In the code below:

1 ~PluginLoader ()
2 {
3 if (module)
4 {
5 FreeLibrary ((HMODULE)module);
6 }
7 }
If I put a line break on line 5 and step through it then it won't crash. If I put the break on 7 then it'll crash.

WTF!!! Anyone who can solve this one is a genius.

Basically, what's the difference between stepping through and just executing? I thought it was supposed to identical.

ETA: I didn't put that thumbs up at the top of the post - I haven't solved anything. Hopefully it's prescient.

[GodMark2]

Basically, what's the difference between stepping through and just executing? I thought it was supposed to identical.

The biggest difference is events. When stepping through the code in the debugger, events in the dll (which isn't being debugged) will be allowed to fire. When running the code normally, events will only be allowed to fire if you specify they can (DoEvents() or Sleep() or similar). If events couldn't fire, then the IDE couldn't catch keypresses or mouse moves and clicks.

Your code is probably still waiting for some event to occur (from a previous call) before the unload happens, but it isn't happening when you run it normally. More than likely, this is causing the event to try and fire after the module (and it's memory) is unloaded, so the event now has an illegal location when it starts to execute: instant crash.

[monoman]

The biggest difference is events. When stepping through the code in the debugger, events in the dll (which isn't being debugged) will be allowed to fire. When running the code normally, events will only be allowed to fire if you specify they can (DoEvents() or Sleep() or similar). If events couldn't fire, then the IDE couldn't catch keypresses or mouse moves and clicks.

Your code is probably still waiting for some event to occur (from a previous call) before the unload happens, but it isn't happening when you run it normally. More than likely, this is causing the event to try and fire after the module (and it's memory) is unloaded, so the event now has an illegal location when it starts to execute: instant crash.

Hi,

I am debugging the dll. It's in the dll that the FreeLibrary call occurs.
I start with debugging my vb program which steps through to my c++ dll program - which I found pretty amazing!

[aggle-rithm]

Am i wrongly assuming that Line 5 won't execute until the dll has finished executing on line 3?

That's the part I can't remember...it's been a while since I called Win32 dll's from Visual Basic. However, I think that if the dll is called directly, it's difficult for VB to know when it has completed. It depends on how the call is made in the background, below the code level.

[aggle-rithm]

I start with debugging my vb program which steps through to my c++ dll program - which I found pretty amazing!

It is pretty amazing...however, I have known the C++ debugger to "lie" to you. You think one thing is going on, and suddenly something else entirely is happening. (For instance, a crucial object will suddenly go NULL for no apparent reason.)

[GodMark2]

Hi,

I am debugging the dll. It's in the dll that the FreeLibrary call occurs.

And the 'module' that you're freeing is yet another DLL. It's that DLL that is loosing it's memory. If 'module' has a thread waiting to execute (timer, beginthread,etc), and you free the library out from underneath it, then execution will try to begin in an invalid memory region.

Try adding a DoEvents() or Sleep(0) just before the FreeLibrary.

I start with debugging my vb program which steps through to my c++ dll program - which I found pretty amazing! That is one very cool thing about having a common IDE, which was sorely lacking in VS6.

[aggle-rithm]

That is one very cool thing about having a common IDE, which was sorely lacking in VS6.

Of course, Borland had it long before Microsoft.

I'm just saying...