引用:

原帖由 xphi 于 2010-11-6 14:04 发表
常常要考虑“修改一个头文件后重新编译时，只选择性地编译那些与该头文件有关的源码文件”这样的问题，说明代码组织或者结构设计多半有问题

说实话这个实在是真不能接受了。。。我觉得我被侮辱了，随便找个像样的项目，开关某些宏，这些操作都是改在头文件里的啊

引用:

原帖由 利多卡因 于 2010-11-6 19:22 发表

说实话这个实在是真不能接受了。。。我觉得我被侮辱了，随便找个像样的项目，开关某些宏，这些操作都是改在头文件里的啊

开关某些宏恰好应该是放在Makefile里面，在不同的规则下由gcc的开关传进去的，过了调试期后，需要发布版的时候才实际写进头文件里面去，每次调试make的时候都要修改头文件，等待缓慢的编译无数源文件，那还要头文件作甚。

引用:

原帖由 xphi 于 2010-11-6 19:44 发表


开关某些宏恰好应该是放在Makefile里面，在不同的规则下由gcc的开关传进去的，过了调试期后，需要发布版的时候才实际写进头文件里面去，每次调试make的时候都要修改头文件，等待缓慢的编译无数源文件，那还要头文 ...

我明白了，你并不发布源码，只发布二进制文件，用户看不见源码，所以用户不会修改头文件

引用:

原帖由 利多卡因 于 2010-11-6 19:50 发表

我明白了，你并不发布源码，只发布二进制文件，用户看不见源码，所以用户不会修改头文件

源代码发布版也是含Makefile一起发布的……，而且需要在本库调试中不断修改的宏开关一般很少需要下级用户修改，除非是不能确定，需要反复试验的常量等等，但是那样的东西为什么要放在宏里面，那些东西应该放在配置文件里面。
用户即便要修改头文件，也不会常常去修改，除非决定大改，即使要大改也应该有一个预先的设计和计划，不是在每次make的时候才来调来调去。

当然，这个属于软件设计的思想问题，每个人都有不同的风格，不必强求。

[ 本帖最后由 xphi 于 2010-11-6 20:01 编辑 ]

你把宏作为编译参数传入源码比用头文件传入到底高明在什么地方呢？连编译参数都修改的话，难道还不用重新编译？我实在是困惑。宏是在预处理阶段就处理掉的，远远早于编译流程

不是所有的项目都有所谓的配置文件的，因为不是所有的程序都是跑在操作系统下的

引用:

原帖由 利多卡因 于 2010-11-6 20:07 发表
你把宏作为编译参数传入源码比用头文件传入到底高明在什么地方呢？连编译参数都修改的话，难道还不用重新编译？我实在是困惑。宏是在预处理阶段就处理掉的，远远早于编译流程

这个我确实记错了，跟着你的关于宏的用法跑偏了，通常情况下头文件里面用预处理宏，要不是和编译环境相关的开关，要不就是Debug本身的开关，这些都是不需要在每次调试时修改的。所以我说不应该在头文件中包含了需要在每次调试时都需要修改的开关，如果有那样的开关，要么避免出现在头文件中，要么放在配置文件里，这就是我为什么说存在程序结构设计上不合理的地方。

[ 本帖最后由 xphi 于 2010-11-6 20:21 编辑 ]

没有配置文件也有很多办法获得全局支持的，虽然全局变量有点丑陋，但是仍然是可以用的；就算是在板子上跑程序，至少还有几块ROM地址可供放配置数据把。

说来说去还是鸡同鸭讲啊，你没有接触过裸板程序

我再举个例子好了，就拿debug开关来说，假设我们现在只调试某一个模块，所以只需要打开这个模块的debug开关就可以了，这当然是代码中该模块设的宏。你说这种情况下，我是改编译参数把整个工程重编一遍好呢还是在该模块的主头文件里打开debug宏好呢？当然，你可以说，我们计划调试一个模块是属于预先的设计和计划，重编一次无所谓

另外，我说的开关宏，当然指的是开关代码中的某些功能，我发现你完全误会了。一个正常人是不会把诸如mac地址啊ip地址啊开机画面存储地址啊写死在代码里的，这代码当然也包括头文件

引用:

原帖由 利多卡因 于 2010-11-6 20:28 发表
说来说去还是鸡同鸭讲啊，你没有接触过裸板程序

我再举个例子好了，就拿debug开关来说，假设我们现在只调试某一个模块，所以只需要打开这个模块的debug开关就可以了，这当然是代码中该模块设的宏。你说这种情况下 ...

是的，我们谈的不是一种情况，从一开始我只是想谈谈关于make是不是半成品这个问题。我并不针对你的这种裸板程序，虽然我也看过几个裸板程序，不过我确实没有写过，不知道我们写裸板程序的小组是不是也这么郁闷。

其实拿linux kernel作为例子就更好说了，比如说spin_lock这个宏，在单核非抢占的情况下，丫就是一个空宏，只有在多核或开抢占的情况下spin_lock才是有意义的。那么这个宏的内容本身就是被宏所选择的，而且这个选择权也是要交到用户手里，由用户的配置来决定的。所以，在用户对内核不同的配置情况下，spin_lock的内容会被修改，并导致所有使用过该宏的源码文件被修改，从而被重编，这只能靠头文件来实现

引用:

原帖由 利多卡因 于 2010-11-6 20:41 发表
其实拿linux kernel作为例子就更好说了，比如说spin_lock这个宏，在单核非抢占的情况下，丫就是一个空宏，只有在多核或开抢占的情况下spin_lock才是有意义的。那么这个宏的内容本身就是被宏所选择的，而且这个选择权 ...

在游戏论坛讨论旋转锁是在是有点蛋痛，我觉得这已经基本说明我的看法了，我没有说头文件中不能用宏，说是说在头文件不能有总要在调试的时候修改的宏，头文件不应该是需要经常改来改去的东西，就算是旋转锁，我的调试机也不是一会多路一会单路吧。而且make可以流畅的处理这所有的头文件依赖问题，没有任何半成品的样子。

Makefile处理头文件的时候，先是利用gcc的参数导出各个源文件的依赖关系，其中包括头文件，但不包括.d文件本身，然后用一个sed去修改.d文件，把.d文件本身添加到目标项中，修改后的.d文件再被include到Makefile中。就是这样一个过程，这是GNUmake官方给出的解决方案，我对此嗤之以鼻

引用:

原帖由 eos 于 2010-11-3 20:54 发表
如果不玩游戏的话这个系统很不错的，win的软件可以通过wine或者虚拟机来实现。linux对内存的利用率很高的。

不觉得，上次一边编译一遍上网，结果系统卡死，最后一看是内存占用问题，2G的内存吃满。但问题是我关了除了编译以外的各种东西，内存占用还没下来。10.04 x64版本，很FT