c++ extern

转自:http://hi.baidu.com/wewe39/item/f713d14da69acce11381dae4

 

http://tech.163.com/06/0118/09/27O66HCC0009159Q.html

时常在cpp的代码之中看到这样的代码:


#ifdef __cplusplus
extern "C" {
#endif

//一段代码

#ifdef __cplusplus
}
#endif
  这样的代码到底是什么意思呢?首先,__cplusplus是cpp中的自定义宏,那么定义了这个宏的话表示这是一段cpp的代码,也就是说,上面的代码的含义是:如果这是一段cpp的代码,那么加入extern "C"{和}处理其中的代码。

  要明白为何使用extern "C",还得从cpp中对函数的重载处理开始说起。在c++中,为了支持重载机制,在编译生成的汇编码中,要对函数的名字进行一些处理,加入比如函数的返回类型等等.而在C中,只是简单的函数名字而已,不会加入其他的信息.也就是说:C++和C对产生的函数名字的处理是不一样的.

  比如下面的一段简单的函数,我们看看加入和不加入extern "C"产生的汇编代码都有哪些变化:

int f(void)
{
return 1;
}
  在加入extern "C"的时候产生的汇编代码是:

.file "test.cxx"
.text
.align 2
.globl _f
.def _f; .scl 2; .type 32; .endef
_f:
pushl %ebp
movl %esp, %ebp
movl $1, %eax
popl %ebp
ret
  但是不加入了extern "C"之后

.file "test.cxx"
.text
.align 2
.globl __Z1fv
.def __Z1fv; .scl 2; .type 32; .endef
__Z1fv:
pushl %ebp
movl %esp, %ebp
movl $1, %eax
popl %ebp
ret
  两段汇编代码同样都是使用gcc -S命令产生的,所有的地方都是一样的,唯独是产生的函数名,一个是_f,一个是__Z1fv。

  明白了加入与不加入extern "C"之后对函数名称产生的影响,我们继续我们的讨论:为什么需要使用extern "C"呢?C++之父在设计C++之时,考虑到当时已经存在了大量的C代码,为了支持原来的C代码和已经写好C库,需要在C++中尽可能的支持C,而extern "C"就是其中的一个策略。

  试想这样的情况:一个库文件已经用C写好了而且运行得很良好,这个时候我们需要使用这个库文件,但是我们需要使用C++来写这个新的代码。如果这个代码使用的是C++的方式链接这个C库文件的话,那么就会出现链接错误.我们来看一段代码:首先,我们使用C的处理方式来写一个函数,也就是说假设这个函数当时是用C写成的:

//f1.c
extern "C"
{
void f1()
{
return;
}
}
  编译命令是:gcc -c f1.c -o f1.o 产生了一个叫f1.o的库文件。再写一段代码调用这个f1函数:

// test.cxx
//这个extern表示f1函数在别的地方定义,这样可以通过
//编译,但是链接的时候还是需要
//链接上原来的库文件.
extern void f1();

int main()
{
f1();

return 0;
}
  通过gcc -c test.cxx -o test.o 产生一个叫test.o的文件。然后,我们使用gcc test.o f1.o来链接两个文件,可是出错了,错误的提示是:

test.o(.text + 0x1f):test.cxx: undefine reference to 'f1()'
  也就是说,在编译test.cxx的时候编译器是使用C++的方式来处理f1()函数的,但是实际上链接的库文件却是用C的方式来处理函数的,所以就会出现链接过不去的错误:因为链接器找不到函数。

  因此,为了在C++代码中调用用C写成的库文件,就需要用extern "C"来告诉编译器:这是一个用C写成的库文件,请用C的方式来链接它们。

  比如,现在我们有了一个C库文件,它的头文件是f.h,产生的lib文件是f.lib,那么我们如果要在C++中使用这个库文件,我们需要这样写:

extern "C"
{
#include "f.h"
}
  回到上面的问题,如果要改正链接错误,我们需要这样子改写test.cxx:

extern "C"
{
extern void f1();
}

int main()
{
f1();

return 0;
}
  重新编译并且链接就可以过去了.

  总结


  C和C++对函数的处理方式是不同的.extern "C"是使C++能够调用C写作的库文件的一个手段,如果要对编译器提示使用C的方式来处理函数的话,那么就要使用extern "C"来说明。

### U-Boot 设备模型 (dm) 驱动文档和实例 #### 理解 U-Boot 的设备模型框架 U-Boot 中引入了设备模型(Device Model, DM),旨在提供种统的方式来管理和配置硬件资源。DM 提供了种抽象层,使得不同类型的设备可以被致地处理[^1]。 #### 初始化过程中的角色 当 U-Boot 进入其主要执行阶段时,会经历系列复杂的初始化操作,在此期间设备模型扮演着重要角色。特别是对于那些需要早期启动支持的组件来说,DM 能够确保这些外设得到恰当设置并准备就绪[^2]。 #### 编写自定义驱动程序指南 为了创建个新的基于 DM 架构下的驱动模块,开发者应当遵循如下原则: - **注册新平台数据结构**:通过 `uclass_driver` 结构体来描述特定类别的通用行为; - **实现 probe 函数**:这是每个具体设备都必需提供的入口点之;它负责完成实际硬件资源配置工作以及任何必要的软件状态初始化。 - **利用宏简化开发**:如 `DECLARE_GLOBAL_DATA_PTR` 可帮助访问全局变量而无需显式传递指针参数。 下面给出段简单的 LED 控制器驱动代码片段作为例子: ```c // drivers/led/uclass.c static int led_bind(struct udevice *dev) { printf("Binding %s\n", dev->name); return 0; } static const struct udevice_id led_ids[] = { { .compatible = "example-led" }, { } }; U_BOOT_DRIVER(led_example) = { .name = "led_example", .id = UCLASS_LED, .of_match = led_ids, .bind = led_bind, }; ``` 上述代码展示了如何声明个名为 `"led_example"` 的驱动,并将其绑定到兼容字符串为 `"example-led"` 的节点上。这里还实现了基本的日志输出功能用于调试目的。 #### 使用命令行接口测试驱动 旦完成了驱动编写之后,则可以通过 U-Boot 命令提示符来进行交互式的验证。例如,假设已经加载了个 SPI NOR Flash 存储芯片的支持库,则可通过输入相应指令查看当前连接情况或者读取指定地址处的数据内容。 ```shell => sf probe 0 # 探测第零号SPI flash设备 SF: Detected w25q80bv with page size 256 Bytes, erase size 4 KiB, total 1 MiB. ``` 以上命令将会尝试识别编号为 0 的 SPI NOR Flash 并打印出检测结果摘要信息。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值