C++ library question?

Question

Hi,

I've been searching a lot on the internet and I've found lots of bits and pieces about how to write a library but overall, I can't fully get it to work. I'd appreciate some help.

Here's what I've got so far:

// test_library.h

#pragma once

using namespace System;

namespace test_library
{

public ref class Class1
{
int adds(int, int);
int times(int, int);
};
}

// This is the main DLL file.

#include "stdafx.h"

#include "test_library.h"

namespace test_library
{
int Class1::adds (int a, int b)
{
return a + b;
}

int Class1::times (int a, int b)
{
return a * b;
}
}

Then I compile it and get a DLL file. My issue is, once I have the DLL file, I try adding it to some random new project that I create, but I can't get Visual Studio to see it. Also, I don't know if I'm supposed to have a DLL file in the end. I thought a .h file would be needed.

The other thing is, I can't work out how to create class member variables for Class1. I would like some class member variables so that I can then have my own constructor.

If someone could point me into the right direction, that'd be great.

Thanks.

Answer 1

DLLs are a pain in the butt because you have to monkey with your source code, adding a __declspec(dllimport) attribute to every class, method and class data variable (or other extern data that you want to link to). Usually you do this with a macro so you can maybe recompile for static linking or port the code to Mac or Unix.



Then there's the header file(s) and import library. The code using your library may not need the binary code at compile and link time, but it needs to know what classes, functions and data exist and which libraries to find them in. You provide the header files. The linker creates the import library when the DLL is created. These need to be put someplace where they can be found. The INCLUDE environment variable has a list of places to look for headers, and the LIB environment variable has a list of places to look for static and import libraries. If you are going to share one set with a lot of projects, put the headers and import libraries in a fixed place and point INCLUDE & LIB at them. Otherwise, you can just include them in each project.



Take a look a the MSDN docs for more information:

http://msdn.microsoft.com/en-US/library/d14wsce5%28v=VS.90%29.aspx



Static linking always seemed much easier to me.

Answer 2

I have been working with dll's quite a bit recently (had to be compatible with C#, VS 2008 & 2005 & 6.0 C++). My advice is to stick with C functions for your interface (not classes). Use only primitives for parameter and return types (int, float, bool, etc). Always put a function in the interface to return the version number of the dll (unsigned getVersion()). There are a variety of ways to link in a dll. I strongly advise sticking to the tried and true GetProcAddress and LoadLibrary routines. This allows you to check for dll existence and versions and handle the error gracefully (rather than getting some cryptic message from Windows about it being a corrupt program or some other nonsense).



http://msdn.microsoft.com/en-us/library/ms683212(v=vs.85).aspx



good luck!

Answer 3

C++ STL contains some products no longer recent in C known Library, which incorporates iostream, string for string products, quite some packing containers like vector, record and so on., and exception. C++ STL also contains some products that are quickly copied from C known Library, which incorporates cstdio (stdio.h), cmath, cstdlib, and so on. i do not understand of any C known Library products which aren't any more in C++ STL, however that's no longer quite chance-free to assert that's merely a sub-set. There do exist C functional elements no longer in C++, so it will be the same with the libraries. yet maximum of it really is actual coated. C is so a lot extra lax about at the same time with headers for known library purposes. see you later as a function returns an "int" form, there is not any compiler mistakes for using a function without at the same time with its prototype. or perhaps in circumstances the position that's no longer "int", in case you ignore concerning the go back fee, no mistakes will happen. yet C++ is a lot extra strict. in case you take advantage of a function, even a known library function, you're able to furnish a prototype, many times in type of at the same time with the header report for that function.