头文件的区别188金宝搏

观点1:

#include “” :
先到源文件所在文件夹去找,然后再到系统指定的某些目录中去找某些头文件。

更进一步:

/usr/local/include

在 strings.h 文件中给了我们明确的答案:

#define    LABEL

观点2:

的格式。其中LABEL为一个唯一的标号,命名规则跟变量的命名规则一样。常根据它所在的头文件名来命名,例如,如果头文件的文件名叫做hardware.h,那么可以这样使用:

strings.h comes from the BSD branch in the unix evolution. Its content
has been standardized by POSIX, but most of it is marked as legacy and
can be easily replaced with other functions

    gcc在默认情况下,都会指定到/usr/include文件夹寻找头文件。

188金宝搏 1

    3. 再找内定目录搜索,分别是

188金宝搏 2

/usr/lib/gcc-lib/i386-linux/2.95.2/include

Typically<strings.h>just adds some useful but non-standard additional
string functions to the standard header<string.h>. For maximum
portability you should only use<string.h>but if you need the functions
in<strings.h>more than you need portability then you can
use<strings.h>instead of<string.h>.

   

包括; index, rindex, strcasecmp, strncasecmp 这四个函数。

#ifndef    LABEL

偶然发现,string.h 的man page 中 出现了 strings.h
的说明。这引起的我的好奇,很奇怪这个strings 和 string
之间的关系。我上网搜了几个帖子,他们写的不够清楚,今天我进行重新整理一下吧:

最后一行是gcc程序的库文件地址,各个用户的系统上可能不一样。

今天使用 man string 来查看 string
文件的使用的方法(毕竟里面的函数名字和传入参数和发挥参数的类型,如果一段时间不使用,会产生遗忘。)

    2.
通过查找gcc的环境变量C_INCLUDE_PATH/CPLUS_INCLUDE_PATH/OBJC_INCLUDE_PATH来搜索头文件位置。

为了进一步搞清楚,我们到底在编程的使用string 还是 strings 头文件。我们在
linux 的 /usr/include 文件夹中打开strings 头文件来一窥究竟。

...

188金宝搏 3

    //代码部分

具体,这个 strings.h
头文件到底有没有被标准化,我们还需要考证。但是根据两个man page
的表现。我觉得有90% 的可能已经被标准化。因为 mac os 的 man page 中
已经把它归为 Standard C library. strings 与 string.h 不仅仅 只是多一个
s
的区别。结束.欢迎大家留言讨论。欢迎转载,转载时请注明出处参考链接:1..
Linux man page

#include <> : 直接到系统指定的某些目录中去找某些头文件。

为了进一步查看社区中的这两个文件的看法,我们在 stackoverflow 中
找到了这个话题的讨论。和我们的解释大同小异:

设当前路径为/root/test,include_test.c如果要包含头文件“include/include_test.h“,有两种方法:

我们使用命令: man string 命令,同样可见相同的内容。可见它已经是c
标准库中的头文件。

1) include_test.c中#include “include/include_test.h”或者#include
"/root/test/include/include_test.h",然后gcc include_test.c即可

首先我们看一下man string 里面的内容:

摘自 zhaoguoxian12345的专栏

为了一探这个头文件是不是只有macos 这种 Unix-like
系统中才出现。我在Linux下的ubuntu 系统中也进行了查看。

    4.
当#include使用相对路径的时候,gcc最终会根据上面这些路径,来最终构建出头文件的位置。如#include
<sys/types.h>就是包含文件/usr/include/sys/types.h

可见,strings 头文件中包含了部分函数,没有在 string.h
中出现的。上图的环境是 macOS Sierra 版本号为:10.12.6

#endif

进阶:我们到底该用哪个头文件呢?

 

大意为: 如果我们使用了string.h 这个头文件,那么我们不需要在进行包含这个
strings.h 这个文件。除非有一种情况。如果 没有定义
__USE_MISC这个变量,这个变量将会在 strings.h 头文件中进行定义。因为
string.h
中没有进行对这个变量进行定义。具体怎么定义的,大家可以在/usr/include/strings.h
这个文件中进行详细查看。

 

   
gcc还有一个参数:-nostdinc,它使编译器不再系统缺省的头文件目录里面找头文件,一般和-I联合使用,明确限定头文件的位置。在编译驱动模块时,由于非凡的需求必须强制GCC不搜索系统默认路径,也就是不搜索/usr/include要用参数-nostdinc,还要自己用-I参数来指定内核头文件路径,这个时候必须在Makefile中指定。

    1.
在gcc编译源文件的时候,通过参数-I指定头文件的搜索路径,如果指定路径有多个路径时,则按照指定路径的顺序搜索头文件。命令形式如:“gcc
-I /path/where/theheadfile/in
sourcefile.c“,这里源文件的路径可以是绝对路径,也可以是相对路径。eg:

本文介绍在linux中头文件的搜索路径,也就是说你通过include指定的头文件,linux下的gcc编译器它是怎么找到它的呢。在此之前,先了解一个基本概念。

#define    __HARDWARE_H__

2) include_test.c中#include <include_test.h>或者#include
<include_test.h>,然后gcc –I include include_test.c也可

   
一句话,头文件事实上只是把一些常用的命令集成在里面,你要用到哪方面的命令就载入哪个头文件就可以了。

   
头文件是一种文本文件,使用文本编辑器将代码编写好之后,以扩展名.h保存就行了。头文件中一般放一些重复使用的代码,例如函数声明、变量声明、常数定义、宏的定义等等。当使用#include语句将头文件引用时,相当于将头文件中所有内容,复制到#include处。#include有两种写法形式,分别是:

 

/usr/include

  //代码部分

这样写的意思就是,如果没有定义__HARDWARE_H__,则定义__HARDWARE_H__,并编译下面的代码部分,直到遇到#endif。这样当重复引用时,由于__HARDWARE_H__已经被定义,则下面的代码部分就不会被编译了,这样就避免了重复定义。

 

    gcc寻找头文件的路径(按照1->2->3的顺序)

   
#include文件可能会带来一个问题就是重复应用,如a.h引用的一个函数是某种实现,而b.h引用的这个函数却是另外一种实现,这样在编译的时候将会出现错误。所以,为了避免因为重复引用而导致的编译错误,头文件常具有:

#ifndef    __HARDWARE_H__

#endif

相关文章

Comment ()
评论是一种美德,说点什么吧,否则我会恨你的。。。