在c++里怎么调用c??在现等待

nilong 2004-01-08 09:17:43
我用mfv调用c的代码!,提示总是引用的不对!
ejpeg.c

include <stdlib.h>
#include <stdio.h>
#include "ejpeg.h"


void main(int argc,char* argv[])
{
FILE *infile;
BYTE Head[54];
BYTE *Buff;
DWORD ImgWidth,ImgHeight,i,j,p;
BYTE bt0,bt1,bt2;
BYTE stuff[4];

if(argc<3)
{ printf("Usage: %s inputfile outputfile\n",argv[0]); return;}
infile=fopen(argv[1],"rb");
if(infile==NULL)
{ printf("Open 24 bit bitmap file failed!"); return;}

fread(Head,54,1,infile);
ImgWidth =*(Head+18)+(*(Head+19))*256;
ImgHeight=*(Head+22)+(*(Head+23))*256;
p=(ImgWidth*3)%4;

printf("Image width: %d height: %d \n",ImgWidth,ImgHeight);
Buff = (BYTE *)malloc(ImgWidth*ImgHeight*3);
if(!Buff) { printf("Malloc memory failed!\n"); return;}

for(i=0;i<ImgHeight;i++) // read bitmap pixels array to buffer
{
for(j=0;j<ImgWidth;j++)
{
fread((BYTE *)&bt0,1,1,infile);
fread((BYTE *)&bt1,1,1,infile);
fread((BYTE *)&bt2,1,1,infile);
*(Buff+i*ImgWidth*3+j*3+0)= bt0;
*(Buff+i*ImgWidth*3+j*3+1)= bt1;
*(Buff+i*ImgWidth*3+j*3+2)= bt2;
}
if(p!=0) fread(stuff,1,(4-p),infile);
}
fclose(infile);
RGBtoJPEGFile(Buff,ImgWidth,ImgHeight,argv[2]);
}
ejpeg.h
typedef unsigned char BYTE;
typedef unsigned short uint16;
typedef unsigned long DWORD;

void RGBtoJPEGBuff(BYTE* Buff,DWORD ImageWidth,DWORD ImageHeight,BYTE *outJPEGBuff,DWORD *BuffLen);

void RGBtoJPEGFile(BYTE* Buff,DWORD ImageWidth,DWORD ImageHeight,char* outFileName);

我就是想在我的c++里调用RGBtoJPEGBuff,RGBtoJPEGFile
可是我在我的程序里声明,就是说引用错误!
大家说怎么调用才行呢!


...全文
163 15 打赏 收藏 转发到动态 举报
写回复
用AI写文章
15 条回复
切换为时间正序
请发表友善的回复…
发表回复
alfwolf 2004-01-10
  • 打赏
  • 举报
回复
呵呵,我来了
代码还好用吗?
nilong 2004-01-08
  • 打赏
  • 举报
回复
http://www.pcvc.net/oldcode/
里这个东西ejpeg.zip

我想在vc mfc的程序里调用这个
RGBtoJPEGFile(Buff,ImgWidth,ImgHeight,argv[2]);
函数怎么调用啊!怎么声明啊
最好 把调试完的代码发给我!
zdy-0811@sohu.com

sursun 2004-01-08
  • 打赏
  • 举报
回复
up
nilong 2004-01-08
  • 打赏
  • 举报
回复
兄弟们给我邮箱,我给你们发代码,看看怎么在 mfc里调用哪个RGBtoJPEGBuff
loose_went 2004-01-08
  • 打赏
  • 举报
回复
可以到我的网站去看看,也许会对你有所帮助,VC在线(www.vczx.com)
曾经的猎狐 2004-01-08
  • 打赏
  • 举报
回复
你那函数我没有用过
你可以对照着上面找找原因
victor_cui 2004-01-08
  • 打赏
  • 举报
回复
需要project->setting->link->libary modules中添加这个jpeg.lib,否则连接器不知道你的这个函数实现在哪里,所以回报连接错误
曾经的猎狐 2004-01-08
  • 打赏
  • 举报
回复
无法解析的外部符号“symbol”

代码引用了链接器无法在库和对象文件中找到的内容(如函数、变量或标签)。

可能的原因

代码请求的内容不存在(例如,符号拼写错误或使用错误的大小写)。
代码请求的内容错误(使用的是混合版本的库,一些库来自产品的一个版本,而其他则来自另一个版本)。
该错误信息之后为致命错误 LNK1120。

具体原因

代码问题

成员模板的定义超出了类的范围。Visual C++ 的一个限制是,成员模板的定义必须完全位于封闭类内。有关 LNK2001 和成员模板的更多信息,请参阅知识库文章 Q239436。
代码或模块定义 (.def) 文件中的大小写不匹配会导致 LNK2001。例如,当在一个 C++ 源文件中将一个变量命名为 var1,并试图在另一个源文件中以 VAR1 访问该变量时。
如果项目使用函数内联,但在 .cpp 文件而非头文件中定义函数,则会导致 LNK2001。
从 C++ 程序调用 C 函数但不使用 extern "C"(这导致编译器使用 C 命名约定)会导致 LNK2001。编译器选项 /Tp 和 /Tc 使编译器将文件分别编译为 C 或 C++,与文件扩展名无关。这些选项会导致函数名与您所期望的名称不同。
试图引用没有外部链接的函数或数据会导致 LNK2001。在 C++ 中,内联函数和 const 数据具有内部链接,除非被显式指定为 extern。
缺少函数主体或变量会导致 LNK2001。如果只有函数原型或 extern 声明,编译器继续运行而不会出现任何错误,但由于没有保留函数代码或变量空间,链接器将无法解析地址调用或变量引用。
调用参数类型与函数声明中的参数类型不匹配的函数会导致 LNK2001。名称修饰将函数参数合并到最终的修饰函数名中。
错误包含的原型导致编译器需要没有提供的函数体,这样会导致 LNK2001。如果同时具有函数 F 的类实现和非类实现,请注意 C++ 范围解析规则。
在使用 C++ 时,将函数原型包含在类定义中但未能包含实现(该类的此函数的实现)会导致 LNK2001。
试图从抽象基类的构造函数或析构函数调用纯虚函数会导致 LNK2001。纯虚函数没有基类实现。
试图从包含静态变量声明的文件外部访问该静态变量会导致 LNK2001。根据定义,用 Static 修饰符声明的函数具有文件范围。静态变量具有相同的限制。
试图在函数范围外使用用该函数声明的变量(局部变量)会导致 LNK2001。
试图在多个文件中使用 C++ 全局常数会导致 LNK2001。与 C 不同,在 C++ 中全局常数具有 static 链接。若要避免此限制,可以将 const 初始化包括在头文件中,并将此头包括在 .cpp 文件中,也可以使变量成为非常数,然后使用常数引用访问它。
在生成 ATL 项目的发布版本时,指示需要 CRT 启动代码。若要修复,请执行下列操作之一:
将 _ATL_MIN_CRT 从预处理器定义列表中移除,以允许包括 CRT 启动代码。有关更多信息,请参阅常规配置设置属性页。
如果可能,移除对需要 CRT 启动代码的 CRT 函数的调用,而是使用它们的 Win32 等效函数。例如,使用 lstrcmp 取代 strcmp。需要 CRT 启动代码的已知函数是一些字符串和浮点函数。
编译和链接问题

当运行时库和 MFC 库的名称包含在对象文件模块中时使用 /NOD 会导致 LNK2001。如果使用 /NOD (/NODEFAULTLIB) 选项,这些库将不会链接到项目中,除非显式包含了它们。
使用 Unicode 和 MFC 时,如果没有创建 wWinMainCRTStartup 的入口点,将在 _WinMain@16 上得到无法解析的外部对象;请使用 /ENTRY。请参阅 Unicode 编程摘要。
有关更多信息,请参阅下列位于 MSDN 库中的知识库文章。在 MSDN 库中,单击“搜索”选项卡,将文章编号或文章标题粘贴在文本框中,然后单击“列出主题”。如果按文章编号搜索,确保清除“仅搜索标题”选项。

Q125750 “PRB: Error LNK2001: '_WinMain@16': Unresolved External Symbol”
Q131204 “PRB: Wrong Project Selection Causes LNK2001 on _WinMain@16”
Q100639 “Unicode Support in the Microsoft Foundation Class Library”
Q291952 “PRB: Link Error LNK2001: Unresolved External Symbol _main”
将用 /MT 编译的代码与库 LIBC.lib 链接会在 _beginthread、_beginthreadex、_endthread 和 _endthreadex 上导致 LNK2001。
链接需要多线程库的代码(任何 MFC 代码或用 /MT 编译的代码)会在_beginthread、_beginthreadex、_endthread 和 _endthreadex 上导致 LNK2001。有关更多信息,请参阅下列知识库文章:
Q126646“PRB: Error Msg: LNK2001 on __beginthreadex and __endthreadex”
Q128641“INFO: /Mx Compiler Options and the LIBC, LIBCMT, MSVCRT Libs”
Q166504“PRB: MFC and CRT Must Match in debug/release and static/dynamic”
在用 /MD 进行编译时,因为所有的运行库现在都存放在 DLL 中,所以源中的“func”引用在对象中变为“__imp__func”引用。如果试图与静态库 LIBC.lib 或 LIBCMT.lib 链接,则将在 __imp__func 上得到 LNK2001。当不用 /MD 进行编译时,如果试图与 MSVCxx.lib 链接,则并非总是得到 LNK2001,但可能会有其他问题。
将用显式或隐式 /ML 编译的代码链接到 LIBCMT.lib 时将在 _errno 上导致 LNK2001。
在生成应用程序的调试版本时与发布模式库链接会导致 LNK2001。同样,使用 /Mxd 选项(/MLd、/MTd 或 /MDd)并/或定义 _DEBUG,然后与发布库链接将带来潜在的无法解析的外部对象(以及其他问题)。将发布模式生成与调试库链接同样会导致类似问题。
将 Microsoft 库版本和编译器产品版本混合可能会有问题。新编译器版本的库可能包含早期版本的库中没有的新符号。可能需要更改搜索路径中的目录顺序,或将它们更改为指向当前版本。
在“工具”|“选项”|“项目”|“VC++ 目录”对话框中,“库文件”选项允许更改搜索顺序。项目的“属性页”对话框中的“链接器”文件夹可能也包含可能已过期的路径。

当安装了新的 SDK(可能在不同的位置),但没有将搜索顺序更新为指向新位置时,可能会出现此问题。通常情况下,应将新 SDK 的 include 目录和 lib 目录的路径放在默认 Visual C++ 位置的前面。另外,包含嵌入路径的项目可能仍然指向旧路径,这些路径是有效的,但对于安装到不同位置的新版本所添加的新功能已过期。

编译器供应商之间、甚至同一编译器的不同版本之间当前没有 C++ 命名标准。因此,链接用其他编译器编译的对象文件可能无法生成相同的命名方案,从而导致错误 LNK2001。
在不同模块上混合内联和非内联编译选项会导致 LNK2001。如果创建 C++ 库时打开了函数内联(/Ob1 或 /Ob2),但描述函数的相应头文件的内联是关闭的(没有 inline 关键字),将发生此错误。若要防止此问题,请在要包含到其他文件中的头文件中用 inline 定义内联函数。
如果使用 #pragma inline_depth 编译器指令,请确保具有设置为 2 或更大的值,并确保使用 /Ob1 或 /Ob2 编译器选项。
在创建纯资源 DLL 时省略 LINK 选项 /NOENTRY 将导致 LNK2001。
使用不正确的 /SUBSYSTEM 或 /ENTRY 设置会导致 LNK2001。例如,如果编写基于字符的应用程序(控制台应用程序)并指定 /SUBSYSTEM:WINDOWS,您将得到无法解析的 WinMain 外部对象。有关这些选项和入口点的更多信息,请参见 /SUBSYSTEM 和 /ENTRY 链接器选项。
导出问题

当将应用程序从 16 位移植到 32 位时,会发生 LNK2001。当前的 32 位模块定义 (.def) 文件语法要求 __cdecl、__stdcall 和 __fastcall 函数列在 EXPORTS 节中,并且不带下划线(不修饰)。这不同于 16 位语法,这些函数在 16 位语法中列出时必须带下划线(修饰)。有关更多信息,请参阅模块定义文件 EXPORTS 节的说明。
在 .def 文件中列出但未找到的任何导出将导致 LNK2001。这可能是因为导出不存在、拼写错误或使用了 C++ 修饰名(.def 文件不采用修饰名)。
解释输出

如果符号无法解析,通过下列指南可获得有关函数的信息:

在 x86 平台上,用 C 编译的名称或 C++ 中的 extern "C" 名称的调用约定修饰是:

__cdecl
函数具有下划线 (_) 前缀。
__stdcall
函数具有下划线 (_) 前缀和 @ 后缀,后跟堆栈上参数的双倍字长对齐大小。
__fastcall
函数具有 @ 前缀和 @ 后缀,后跟堆栈上参数的双倍字长对齐大小。
使用 undname.exe 获取修饰名的未修饰格式。

nilong 2004-01-08
  • 打赏
  • 举报
回复
BMP.obj : error LNK2001: unresolved external symbol "void __cdecl RGBtoJPEGFile(unsigned char *,unsigned long,unsigned long,char *)" (?RGBtoJPEGFile@@YAXPAEKKPAD@Z)
nilong 2004-01-08
  • 打赏
  • 举报
回复
不是的,是这么个 事!
我有一个代码,是用c写的,他在他的程序里从jpeg.lib里调用了一个RGBtoJPEGFile(Buff,ImgWidth,ImgHeight,argv[2]);
它在头文件里声明
ejpeg.h
typedef unsigned char BYTE;
typedef unsigned short uint16;
typedef unsigned long DWORD;

void RGBtoJPEGBuff(BYTE* Buff,DWORD ImageWidth,DWORD ImageHeight,BYTE *outJPEGBuff,DWORD *BuffLen);

void RGBtoJPEGFile(BYTE* Buff,DWORD ImageWidth,DWORD ImageHeight,char* outFileName);

现在我想在我的代码里也要用RGBtoJPEGBuff这个函数,我怎么声明,和调用啊!
sandy110 2004-01-08
  • 打赏
  • 举报
回复
extern "c"
c中调用c++也是extern "c"
c++中调用fortan
就是extern "fortan"以此类推
weakwater 2004-01-08
  • 打赏
  • 举报
回复
extern "C"
weakwater 2004-01-08
  • 打赏
  • 举报
回复
project->add to project->c++ soruce file->ok

copy *.c-->soruce file

<file call *.c's function> include <*.c>
byry 2004-01-08
  • 打赏
  • 举报
回复
如果C++程序要调用已经被编译后的C函数,该怎么办?
假设某个C函数的声明如下:
void foo(int x, int y);
该函数被C编译器编译后在库中的名字为_foo,而C++编译器则会产生像_foo_int_int之类的名字用来支持函数重载和类型安全连接。由于编译后的名字不同,C++程序不能直接调用C函数。C++提供了一个C连接交换指定符号extern“C”来解决这个问题。例如:
extern “C”
{
void foo(int x, int y);
… // 其它函数
}
或者写成
extern “C”
{
#include “myheader.h”
… // 其它C头文件
}
这就告诉C++编译译器,函数foo是个C连接,应该到库中找名字_foo而不是找_foo_int_int。C++编译器开发商已经对C标准库的头文件作了extern“C”处理,所以我们可以用#include 直接引用这些头文件。
victor_cui 2004-01-08
  • 打赏
  • 举报
回复
应该是没有把c加入到工程吧,最好把错误也贴进来

16,551

社区成员

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

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

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