DLL我觉的应该不会太难,我却这么难掌握它,请帮帮我,高手!

ren20 2000-06-27 08:24:00
我用Win32 Dynamic-Link Library ,选A DLL that exports some symbols.
创建了一个ddd.dll。
以下是我加的代码:
ddd.cpp中:

__declspec(dllexport) int mmm()
{
return 55;
}
连接成功。但我创建了一个调用DLL对话框程序。将ddd.lib和ddd.h ddd.cpp添加进去后,
build时提示如下:

C:\vc\ddd\ddd.cpp(25) : error C2491: 'nDdd' : definition of dllimport data not allowed
C:\vc\ddd\ddd.cpp(29) : error C2491: 'fnDdd' : definition of dllimport function not allowed
C:\vc\ddd\ddd.cpp(36) : warning C4273: 'CDdd::CDdd' : inconsistent dll linkage. dllexport assumed.

请问是怎么回事? 为什么不能在定义 mmm()时加extern "c"
如下:
extern "c"__declspec(dllexport) int mmm()
{
return 55;
}

但编译出错,提示如下:
c:\VC\ddd\ddd.cpp(40) : error C2537: 'c' : illegal linkage specification
Error executing cl.exe.

extern "c" 到底在什么情况下添加? 非常感谢
...全文
360 13 打赏 收藏 转发到动态 举报
写回复
用AI写文章
13 条回复
切换为时间正序
请发表友善的回复…
发表回复
ren20 2000-06-29
  • 打赏
  • 举报
回复
哈哈,

忘了,今天下午给分吧! ;)
ren20 2000-06-29
  • 打赏
  • 举报
回复
jy 您好,

没想到你这么晚你还在网上,你知道我是谁吗?

还记的 《有感于... ...》吗?

谢谢你的帮助,我现在都明白了,明天给分。

交个朋友吧!

rfs001@371.net






jy 2000-06-29
  • 打赏
  • 举报
回复
是啊!
我忘记详细说明了。应该是把extern "C"放在头文件中,如果这个函数需要在头文件中包含一份声明快照的话。所以,您最后的写法对极!
但很多情况下,也可能函数不需要快照的;或者它被直接声明在头文件中(C++),例如:
//.h
extern "C" inline int __declspec(dllexport) mmm()
{
return 55;
}

不过上述的写法值得在具体编译器上测试通过,否则,为了安全,还是写成这样比较好:
#ifdef __cplusplus //注意!小写
extern "C" {
#endif

inline int ... yourFunc();
int ... yourFunc2();

#ifdef __cplusplus //注意!小写
}
#endif
这种写法既避免不同编译器处理限定符(inline, __declspec, etc.)的顺序问题,也保证编译器的开发环境配置问题,是比较安全的做法。

那么,最后仍然强调:还是不用extern "C"的为好,毕竟是C++,也没有特别精细的速度要求,通常也不太有混合编程的需要。
ren20 2000-06-29
  • 打赏
  • 举报
回复
to jy :

I am rfa20 ! ~0~
jy 2000-06-29
  • 打赏
  • 举报
回复
关于halfdream的是否问题,也不知道我理解对没有。请参考如下的代码(援引自另一回答:“我刚开始学习DLL内容,请帮帮我”):
不是,__declspec(dllexport)应该在头文件中申明。保证正确引出符号,这个作用和2.中相同,但更方便。
当在其他的计划中使用时,__declspec(dllimport)用于告诉其他计划应该引入该符号,显然它也应该用在头文件中。

由于上述原因,为了使用同一个头文件mydll.h,使得既用在mydll计划中,同时又能不加修改地用在其他计划中,我推荐的是:
in MyDLL stdafx.h, insert:
#define MY_DLL_PRIVATE

in MyDLL MyDLL.h begin, insert
#ifdef MY__DLL_PRIVATE
# define MY_DLL_CLASS __declspec(dllexport)
#else
# define MY_DLL_CLASS __declspec(dllimport)
# ifdef _DEBUG
# pragma comment(lib, "MyDLLd.lib")
# else
# pragma comment(lib, "MyDLL.lib")
# endif
#endif

这样,在任何需要的地方加入MyDLL.h就行,甚至也通知了Linker自动寻找正确的连接库(注意,我习惯为调试版的DLL以後缀d结束,所以.lib也带有d后缀)。

至于要引出的函数,则可以申明成:
void MY_DLL_CLASS MyFunction(...);

实现成(在cpp中):
void MyFunction(...){
}
jy 2000-06-29
  • 打赏
  • 举报
回复
XiXi, 看糊涂了。我这才上网的啦,或者说这才是我一天的真正开始?
ren20 2000-06-28
  • 打赏
  • 举报
回复
to jy:

加extern "c" 直接加在.h头文件中就可以了,
不用加在.cpp实现文件中。
//.h
extern "c" _ _declspec(dlexport) int My();

//.cpp

int my()
{
...
}

我运行通过,您认为呢?
谢谢jy, halfdream & ta

马上要给分了 !
halfdream 2000-06-28
  • 打赏
  • 举报
回复
>>但我创建了一个调用DLL对话框程序。将ddd.lib和ddd.h ddd.cpp添加进去后,
~~~~~~~~~~~~ 使用DLL 怎么把源程序也加上去? ;)
INCLUDE头文件也不要。
只需要使用前照样作一个类似的引入声明不就行了?


同意jy.
不过建议最好加上extern "C"
~~~~\注意这是大写!

jy 2000-06-28
  • 打赏
  • 举报
回复
一定要加的话,这样写:
extern "C" int __declspec(dllexport) mmm()
{
return 55;
}

通常情况下,extern "C" 可以完全不加。
加上代表着不论IDE环境如何,这个函数的调用总是使用C协定;不加呢,则一般是C协定,但也可能使用PASCAL协定,或者C++协定,视你的环境如何配置而定。
C和PASCAL协定的区别主要在于参数的压栈顺序上,一般可以不考虑。
C和C++协定基本上是完全一样的,然而C++编译器会为函数的引出符号附加上参数类型的表示字符,而C协定呢,一般就是函数名称前面加上下划线。同样的,现在通常也不必再其中伤脑筋,不加就是。

但如果你的程序会存在比较复杂的开发环境,用extern "C"可以限定快照的一致性。
ren20 2000-06-27
  • 打赏
  • 举报
回复
请大家都来帮我呀!
strangecat 2000-06-27
  • 打赏
  • 举报
回复
1.我觉得现在使用VC IDE的向导创建DLL工程非常方便,为什么不试试?
2.extern "C"好象应该用来说明函数的PROTOTYPE.
ta 2000-06-27
  • 打赏
  • 举报
回复
这个问题我遇到过. 原因是有一个决定DLL宏翻译的方向宏不正确. 我没有查到他在那里出现的. 不过我用以下的方法解决了这个问题.
DLL part
dll*.h
int __declspec(dllexport) myfunction(); //注意它的位置是含义的 dllexport

dll*.cpp
int myfuction()
{
return anyValume;
}

EXE part // 注意工程类型

dll*.h
int __declspec(dllimport) myfunction(); //注意 dllimport

exe*.h
int getvalue();

myexe.cpp
int getvalue()
{
int a;
a=myfunction();
//textout it;
}


true_hero 2000-06-27
  • 打赏
  • 举报
回复
关注

16,467

社区成员

发帖
与我相关
我的任务
社区描述
VC/MFC相关问题讨论
社区管理员
  • 基础类社区
  • Web++
  • encoderlee
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……

试试用AI创作助手写篇文章吧