Подключение dll к проекту Visual Studio 2010 (C++)

Добавлю, что если DLL содержит функции не в Си стиле, тогда можно прописать в .DEF через равно нужную нам функцию в Си стиле, убрав тем самым манглинг. Например:
@GetRandomNumbers$qipci = _GetRandomNumbers@12 @1

Да, тут у них даже в чем-то удобная система. Лично, правда, пользоваться не приходилось, не знаю, насколько полезная.

Пример того, что у меня выводит dumpbin и то что прописано в заголовочном файле (*.h):
void waitForData(int delayMs=0); == _ZN8Novorado10Parktronic11waitForDataEi
string libraryVersion() const; == _ZNK8Novorado10Parktronic14libraryVersionEv

Novorado — это namespace, Parktronic — класс, принадлежащий Novorado.

Ну вот Ei — это тип параметра int, а Ev — void. Но, по-моему, это не Microsoft'овский компилятор. Что-то даже с примерным описанием разных схем name mangling трудно сказать, чем это собрано. Вроде похоже на GCC, но не совсем.

Беда в том, что микрософтовские инструменты этого не поймут, потому как по тем же объявлениям будут искать функции с другим (своим) стилем name mangling. Добро пожаловать в C++ :) Единственный вариант, который можно попробовать — переопределять имена. Т. е. делать .lib так:

lib.exe /EXPORT:<имя в MS-стиле>=<реальное имя> mylib.dll

Попробуйте сначала с одной простой функцией. Чтобы выяснить имя в MS-стиле, можно написать свою (пустую) реализацию этой же библиотеки, скомпилировать ее в Visual Studio, и посмотреть, что выходит. Ну или аналитическим путем.

Да, узнал, что эта библиотека была написана на GCC (windows, minGW). Попробую переопределять имена, как Вы пишете. спасибо за помощь :) я так понял надо будет def — файл подсунуть MinGW, т.к. в нем была написана dll?

Вы знаете, скорее всего, ничего не выйдет. Может быть, конечно, что-то и выйдет, но шансы небольшие. Проблема в том, что библиотека экспортирует непосредственно С++ символы. У C++, в отличие от C не стандартизован ABI (application binary interface) и разные компиляторы реализуют его по-разному. То есть когда код, скомпилированный MS-компилятором, получит объект из кода, скомпилированного MinGW, очень может быть, что внутренняя его структура будет не такой, которую предполагает MS компилятор. Хотя объявления у объектов вроде бы одни и те же. Соответственно, работать с ним он не сможет.

Вроде бы Borland C++ в свое время озаботился тем, чтобы его C++ ABI совпадал с MS; в результате его C++ DLL можно было использовать с MS-продуктами и наборот. Что до GCC, у него даже между версиями ABI не совпадает. Добро пожаловать в C++, v2 :)

То есть даже если побороть name mangling, толку это не даст. Вариант только перекомпилировать dll под Visual Studio. Или на mingw сделать оболочку, чтобы завернуть C++ в обычный C.

А на вопрос-то я и не ответил: def-файл нужен для lib.exe, чтобы сделать .lib, обертку над DLL. См. первый пример в начальном ответе. MinGW, возможно, мог бы его использовать при линковке объектных файлов, но у вас не тот случай.

Вот что мне написал создатель библиотеки:
«Нужно сделать def файл (при помощи утилиты depends посмотрите экспорт имена в dll и руками пять строчек
напишите). Далее, сгенерить импорт библиотеку www.mingw.org/wiki/CreateImportLibraries
Задача встает достаточно часто когда разные компиляторы нужно состыковывать.»

Кстати, а по поводу C vs. C++ — если при вызове функций из библиотеки прописывать " extern «C» ", все равно толку не будет?

Если extern "C" не прописан, сейчас уже бессмысленно его прописывать. Это инструкция компилятору экспортировать одно только имя функции как оно есть (добавив только _ спереди) и не засовывать туда типы арументов и результата, чтобы можно было различать перегруженные функции. Если это не сделано при компиляции (а это не сделано), то имена уже не такие. Кроме того, у вас тут еще и классы имеются — их вообще нельзя в стиле С экспортировать. (Если нужно работать с С++ классом из С, обычно приходится писать раздельные заголовки, объявляя класс как структуру, давая другие сигнатуры функций — что-то вроде такого.)

Я несколько сомневаюсь, что автор библиотеки дает вам правильный совет. Хотя раз он так уверенно говорит, вдруг у него есть и C-интерфейс? Посмотрите, может быть в заголовочном файле уже есть extern "C", а среди невнятных имен, которые выдает dumpbin, есть называния таких функций? Если так, то да, эти имена вы сможете подцепить через def-файл и ссылка которую он приводит, как раз в тему.

Но если этого нет, то я очень удивлюсь, если проблема вдруг решится с помощью def-файла. Вот, например, страничка MinGW, описывающая, как создать DLL. Обратите внимание, что они используют extern "C" там, где могут, что пишут далее, что функция, не объявленная таким образом и C++ класс не будут доступными при вызове из другой среды (например, MS VC++):

The important and often overlooked consequence of this is that from the above DLL only the functions hello(const char *) and Double(int) are seamlessly callable from e.g. MS VC++ while CppFunc(void) is not (assuming the DLL is created by MinGW).

A similar statement goes for C++ classes exported in a DLL, i.e. for the class MyClass. For further reading search the Web for the keyword «ABI» and possible in conjunction with «C++».

Обратите внимание на «assuming the DLL is created by MinGW» — подразумевается, что если DLL будет скомпилирована MS VC++, то функция и класс будут доступны. Или, как они далее советуют, можно либо навертеть COM-объект, либо создать обертку в C-стиле:

A way to circumvent this problem is either using COM or create C-style wrapper functions to encapsulate the C++ ABI.