为什么gcc忘了引用头文件也能编译成功

2024-11-05

使用部分函数时并未include其所在头文件，但是能编译成功且能运行，为什么？

最近在看APUE,试了上面的一些例子,其中有个例子是使用getpid函数获取进程id,但是在我写demo时,并未引入其所在的头文件unistd.h,结果也能编译成功,也能运行,于是就琢磨下为啥. Environment info: Ubuntu 18.04.2 LTS, gcc (Ubuntu 4.8.5-4ubuntu8) 4.8.5 示意代码如下: int main (int argc, char *argv[]) { long pid = (long)getpid(); long test

关于Dev-C++一种引用头文件<iostream>问题(暴力解决)

问题情况如下,因个人水平有限,不知道具体原因是啥,当引用头文件<iostream>时会出现如下问题,经排查,并不是头文件本身的问题,有可能是Dev哪一个文件被改动了,或者设置出了问题(前者概率更大)还有一个可能就是Windows和Dev存在小小的不合(仅代表个人观点),不多说方法如下解决方法: 去正规渠道下载新的安装包,假如你对自己的安装包有信心可以用自己原先下载好的点击安装包进行安装,选择安装路径(安装地址)的时候,尽量选择一个较大的硬盘完成安装就可以直接使用了推荐下载链接: http

C++头文件中预编译宏的目的

C++头文件中预编译宏的目的 eg: #ifndef _FACTORY_H_#define _FACTORY_H_......#endif //~_FACTORY_H_ 防止头文件被重复包含,导致变量或类型被重复定义

c++中，保证头文件只被编译一次，避免多重包含的方法

保证头文件只被编译一次 #pragma once这是一个比较常用的C/C++杂注,只要在头文件的最开始加入这条杂注,就能够保证头文件只被编译一次. #pragma once是编译器相关的,有的编译器支持,有的编译器不支持,具体情况请查看编译器API文档,不过现在大部分编译器都有这个杂注了. 避免多重包含 #ifndef,#define,#endif是C/C++语言中的宏定义,通过宏定义避免文件多次编译.所以在所有支持C++语言的编译器上都是有效的,如果写的程序要跨平台,最好使用这种方式. 在

ASP.NET MVC 在子页中引用头文件

在很多时候我们把网站公共的js.css文件放在模板页中,这样在具体的每一个页面里面就不需要单独引用. ASP.NET WebForm里面使用.site文件. 而在ASP.NET MVC 中使用了类似下面的定义 _Layout.cshtml: <!DOCTYPE html> <html> <head> <title>@ViewBag.Title</title> <link href="@Url.Content("~/Con

linux下gcc默认搜索的头文件及库文件路径

转自:https://blog.csdn.net/fd315063004/article/details/7925854 一.头文件 gcc 在编译时如何去寻找所需要的头文件:※所以header file的搜寻会从-I开始※然后找gcc的环境变量 C_INCLUDE_PATH,CPLUS_INCLUDE_PATH,OBJC_INCLUDE_PATH※再找内定目录/usr/include/usr/local/include/usr/lib/gcc-lib/i386-linux/2.95.2/inc

使用CocoaPods，文档中出现引用头文件找不到的问题。

现在很多人都会使用CocoaPods来管理自己使用的第三方开源代码,这两天我的工程中碰到了这样一个问题,当我使用CocoaPods来进行三方源码的引入,但是在实际的工程当中引入出现了这样一个问题,就是头文件找不到!!!头文件居然找不到!!!可是他明明好好的躺在那里啊,为什么找不到,这时候想到肯定是路径或者引用的问题. 研究了半天,终于摸到了门路,流程就是PROJECT -> info -> Configurations ->Debug/Release -> AppTests 后面的

C++----练习--引用头文件

1.创建头文件和源文件 touch /tmp/tools.h touch /tmp/main.cpp 2.各文件的内容如下: tools.h #include<iostream> void print_hello_world() { std::cout<<"hello world ..."<<std::endl; } main.cpp #include<iostream> #include<cstdlib> #include

Win32:引用头文件

1.首先,在代码文件头部使用#include来包含任何头文件(扩展名为.h或者.hpp的文件)都不会“产生”额外的函数. 我们可以说,包含一个头文件之后,该头文件内部已经定义的一些变量,宏,函数等等资源,将可以在后面的代码中可以直接拿来使用,比如,当我们包含process.h之后,就可以在代码中使用system()函数来调用系统控制台的命令,比如cls,.pause等等. 同理,包含了windows.h之后,在该文件中定义的一些资源我们可以直接使用,其中包括大部分的Win32 API函数,以及一

Qt 引用头文件 QT_BEGIN_NAMESPACE QT_END_NAMESPACE

Qt里面引入头文件的两种方式: 1. #include <QMdiArea> #include<QSplashScreen> 2. QT_BEGIN_NAMESPACE class QMdiArea; class QSplashScreen QT_END_NAMESPACE 关于QT_BEGIN_NAMESPACE 和QT_END_NAMESPACE 比较好的解释: 比较好的解释: QT_BEGIN_NAMESPACE其实就是个宏,以前Qt4是没有Qt命名空间的,后来才加上的,编译

测试build出来的dist文件夹是否编译成功

一.先用webpack执行 npm run build 成功后会生成dist文件夹. 二.把dist文件夹推到SVN项目指定位置.注意:因为build后会生成很多的js css font文件并没用加入到SVN版本管理器中, 所以在提交代码前需要手动把新的文件加入到SVN中. 三.找到eclipse中的 cfin(项目名称)/Deployed Resources/webapp,把编译好的dist文件夹paste到webapp中. 四.重新启动项目Servers. 五.如果eclipse配置的端口是

cocoaspod使用引用头文件找不到

使用cocoasPod做第三方类库管理非常方便,但是在使用的过程之中会遇到一些小问题!比如初次使用会遇到引入类库,说找不到文件 target--build settings---user search path----user head search path 添加 ${SRCROOT} 后面选择 recursive

eclipse引用头文件报错问题-解决方法

最近在做一个U-BOOT相关的项目,经过几天的折腾最终放弃使用VIM和一堆附加插件.最终的出的结论是对于中大型工程项目还是要启用一些专业的IDE比较稳妥,尽管VIM提供的各种插件累加在一起足以实现专业IDE的功能,但对于项目管理的复杂程度有所增加.总之一句话,尺有缩长,寸有缩短,按需求选择吗.不可否认的是,VIM对于SLOC小于10K的项目还是比较适用的,因为其灵活性和可控性真的让人忍不住用了还想用. 贴一张Eclipse图,配合GDB+OpenOCD+JLINK,调试起来非常方便.

引用头文件顺序问题 error C2039

建的WTL工程,用到CString和DataExchange 因为WTL和ATL都有对CString的定义当先包含 atlstr.h 再包含 atlddx.h 时会出现以下错误 error C2039: 'CString' : is not a member of 'WTL' c:\program files\microsoft visual studio 10.0\vc\wtl\atlddx.h 解决办法是先包含 atlddx.h 再包含 atlstr.h ,详细原因待分析.

C语言 Include指令（引用头文件）

#include "one.h" #include "two.h" int main(int argc, const char * argv[]) { one(); two(); ; }

删除moduleCache下文件解决预编译头文件相关的编译错误

之前有在代码全部正确的情况下,遇到过下面的编译错误: fatal error: file '.....h' has been modified since the precompiled header '.....' was built. note: please rebuld precompiled header '....'. 解决方法是删除文件夹下/Users/username/Library/Developer/Xcode/DerivedData/ModuleCache下的所有文件,然后

如何指定GCC的默认头文件路径

如何指定GCC的默认头文件路径网上偶搜得之,以之为宝:)原地址:http://blog.chinaunix.net/u/28781/showart.php?id=401631=============================================================================== 在交叉编译的时候我们需要用到其他的库,在config时候可以通过“-l”来指定目录,但是每次都需要设置的话难免有些麻烦,找到一个简单的方法.看下文的红色部分. 有大

gcc编译时头文件和库文件搜索路径

特殊情况:用户自定义的头文件使用#include"mylib"时,gcc编译器会从当前目录查找头文件一.头文件 gcc 在编译时寻找所需要的头文件 : ※搜寻会从-I开始(gcc 参数,指定头文件搜索位置) ※然后找gcc的环境变量 C_INCLUDE_PATH,CPLUS_INCLUDE_PATH,OBJC_INCLUDE_PATH ※再找内定目录 /usr/include /usr/local/include /usr/lib/gcc-lib/i386-li

c++头文件重复引用问题

引子----之前写C++ 时遇到的坑之前由于Java实在太好用了,C++的工程代码几乎没怎么碰,真的写起来的时候总会有些小bug,这里就对其中的一个进行个总结 a.h #include "b.h" class a{ public: a(); ~a(); } a.cpp #incldue "a.h" a::a(){ .... }; a::~a(){ .... }; b.h #include "a.h" class b{ public: b();

ArcCore重构-头文件引用问题的初步解决

基于官方arc-stable-9c57d86f66be,AUTOSAR版本3.1.5 基本问题 1. 头文件引用混乱,所有头文件通过从搜索路径(-I)中引用,存在名称污染问题,需加入路径信息: ArcCore代码的编译系统中,定义了大量的inc-y路径,最后使用-I参数将这些路径加入到编译器的命令行参数中.而代码文件中,引用头文件时都是直接使用 #include "xxx.h" 的形式. 这样有几个问题: 1. 编译系统负担过重,需要加入大量的头文件搜索路径: 2. 导致头

一个C++引用库的头文件预编译陷阱

写在前面老胡最近在工作中,有个场景需要使用一个第三方库,引用头文件,链接库,编译运行,一切都很正常,但是接下来就遇到了一个很诡异的问题,调用该库的中的一个对象方法为对象修改属性的时候,会影响到对象的另外一个属性,当时百思不得其解,直呼灵异事件. 但后面静下心来细细看了一下代码和各种配置,发现了问题所在,现在把这个问题分享在这里,希望大家在以后的工作中如果遇到了类似的情况知道应该如何处理. 场景还原库当时引用的是一个第三方的静态链接库,场景非常简单,在项目中包含头文件,链接器指定路径和静态库

为什么gcc忘了引用头文件也能编译成功

热门专题