w***g
发帖数: 5958 | 1 就是写成跟java一样，所有的类只有.h文件，然后main.cpp #include所有的类。
我一直都是这么搞的，也没出过什么问题，除了编译速度超慢以外。实在受不了定义和
实现分开的写法，效率太低。
但我知道这么干肯定是有问题的。就是不知道最主要的问题在哪。 |
l********a
发帖数: 1154 | 2 在h/hpp中实现的的话,如果用户要基于你的代码进行二次开发,你的源码就暴露了 |
x****u
发帖数: 44466 | 3 没问题，ATL就是这么实现的。
不过编译会非常的慢。
【在 w***g 的大作中提到】
: 就是写成跟java一样，所有的类只有.h文件，然后main.cpp #include所有的类。
: 我一直都是这么搞的，也没出过什么问题，除了编译速度超慢以外。实在受不了定义和
: 实现分开的写法，效率太低。
: 但我知道这么干肯定是有问题的。就是不知道最主要的问题在哪。
|
x****u
发帖数: 44466 | 4 写在cpp里面一样，这里讨论的不是源代码vs库。
【在 l********a 的大作中提到】
: 在h/hpp中实现的的话,如果用户要基于你的代码进行二次开发,你的源码就暴露了
|
a****l
发帖数: 8211 | 5 楼上的意思是你可以把你的东西编译成binary，然后只给二次开发的人用头文件。
【在 x****u 的大作中提到】
: 写在cpp里面一样，这里讨论的不是源代码vs库。
|
x****u
发帖数: 44466 | 6 拿不到源代码时，发布Cpp的lib有很多潜在问题。
【在 a****l 的大作中提到】
: 楼上的意思是你可以把你的东西编译成binary，然后只给二次开发的人用头文件。
|
p*u
发帖数: 2454 | 7 its gonna b super hard 4 others 2 read ur code and grasp what methods u
declare in this class.
【在 w***g 的大作中提到】
: 就是写成跟java一样，所有的类只有.h文件，然后main.cpp #include所有的类。
: 我一直都是这么搞的，也没出过什么问题，除了编译速度超慢以外。实在受不了定义和
: 实现分开的写法，效率太低。
: 但我知道这么干肯定是有问题的。就是不知道最主要的问题在哪。
|
a****l
发帖数: 8211 | 8 well, it is THEIR problem, not YOUR problem.
【在 x****u 的大作中提到】
: 拿不到源代码时，发布Cpp的lib有很多潜在问题。
|
x****u
发帖数: 44466 | 9 在你的库里面崩溃，还是你的责任啊。
【在 a****l 的大作中提到】
: well, it is THEIR problem, not YOUR problem.
|
a****l
发帖数: 8211 | 10 同学,您不要这么软弱好吗?用户用的不对出了问题当然是用户的责任,怎么能怪到你头
上呢?比如说,你不给车换油,你能怪车子没设计好吗?
【在 x****u 的大作中提到】
: 在你的库里面崩溃，还是你的责任啊。
|
|
|
w***g
发帖数: 5958 | 11 如果不怕源代码暴露，这个倒是问题不大。可以通过doxygen解决（参考java，直接给
一个jar文件，都没有.h文件)
【在 p*u 的大作中提到】
: its gonna b super hard 4 others 2 read ur code and grasp what methods u
: declare in this class.
|
p*u
发帖数: 2454 | 12
then u will have a code bloat problem; many ppl include hundreds of header
files without thinking too much.
【在 w***g 的大作中提到】
: 如果不怕源代码暴露，这个倒是问题不大。可以通过doxygen解决（参考java，直接给
: 一个jar文件，都没有.h文件)
|
p*u
发帖数: 2454 | 13
ur library should handle users' bad behaviors and never crash; u can throw
exceptions or return error codes when user code tries to screw up.
【在 a****l 的大作中提到】
: 同学,您不要这么软弱好吗?用户用的不对出了问题当然是用户的责任,怎么能怪到你头
: 上呢?比如说,你不给车换油,你能怪车子没设计好吗?
|
y****e
发帖数: 23939 | 14 open source有很多就这么干的。boost里很多库就是这么干的，好处是基于它的开发不
再需要链接库文件。header only dependent。 |
N*****m
发帖数: 42603 | 15 boost也不是全部都是
【在 y****e 的大作中提到】
: open source有很多就这么干的。boost里很多库就是这么干的，好处是基于它的开发不
: 再需要链接库文件。header only dependent。
|
D*******a
发帖数: 3688 | 16 boost may be a different case due to its heavy template usage
【在 y****e 的大作中提到】
: open source有很多就这么干的。boost里很多库就是这么干的，好处是基于它的开发不
: 再需要链接库文件。header only dependent。
|
f*******n
发帖数: 12623 | 17 坏处就是每次用一个方法就会inline，所以一个方法的码可能重复几十遍
【在 w***g 的大作中提到】
: 就是写成跟java一样，所有的类只有.h文件，然后main.cpp #include所有的类。
: 我一直都是这么搞的，也没出过什么问题，除了编译速度超慢以外。实在受不了定义和
: 实现分开的写法，效率太低。
: 但我知道这么干肯定是有问题的。就是不知道最主要的问题在哪。
|
d***q
发帖数: 1119 | 18
boost大部分的库.hpp only。只要用了template的，因为实例化的问题，实现都写在.
hpp上。这个其实还好了。
【在 p*u 的大作中提到】
:
: ur library should handle users' bad behaviors and never crash; u can throw
: exceptions or return error codes when user code tries to screw up.
|
d***q
发帖数: 1119 | 19
它真正需要编译的 多半是需要用到系统api的。
例如thread, datetime, regex,system等。似乎只有8个需要编译。
其他基本上都是include .hpp就行了。
【在 N*****m 的大作中提到】
: boost也不是全部都是
|
t****t
发帖数: 6806 | 20 编译速度慢是一方面, 另一方面inline太多的话, binary size会变大, 有时不是一件
好事(e.g. cache efficiency). 当然如果是template那也没办法. 我一般的做法是把
常用的instantiation变成extern放在另一个.cpp里, 不常用的就当场实现.
不过我对你说的定义和实现分开写效率太低有问题. 你把所有的方法都写在头文件里面
效率就高了? 这根本没有关系的嘛. 你要说写习惯了java那是另一回事. 我还说阅读代
码时只看interface效率更高呢.
【在 w***g 的大作中提到】
: 就是写成跟java一样，所有的类只有.h文件，然后main.cpp #include所有的类。
: 我一直都是这么搞的，也没出过什么问题，除了编译速度超慢以外。实在受不了定义和
: 实现分开的写法，效率太低。
: 但我知道这么干肯定是有问题的。就是不知道最主要的问题在哪。
|
|
|
d****p
发帖数: 685 | 21 This is a bad practice in large C++ projects since it introduced unnecessary
build dependencies.
In theory, a change in the implementation of a module should NOT trigger
recompilation of dependee modules which only care about the module's
interface.
【在 w***g 的大作中提到】
: 就是写成跟java一样，所有的类只有.h文件，然后main.cpp #include所有的类。
: 我一直都是这么搞的，也没出过什么问题，除了编译速度超慢以外。实在受不了定义和
: 实现分开的写法，效率太低。
: 但我知道这么干肯定是有问题的。就是不知道最主要的问题在哪。
|
r****t
发帖数: 10904 | 22 赞一个
unnecessary
【在 d****p 的大作中提到】
: This is a bad practice in large C++ projects since it introduced unnecessary
: build dependencies.
: In theory, a change in the implementation of a module should NOT trigger
: recompilation of dependee modules which only care about the module's
: interface.
|
pv
发帖数: 83 | 23 i think the best explantion is given by BS in his book
the C++ programming language
【在 r****t 的大作中提到】
: 赞一个
:
: unnecessary
|
x****u
发帖数: 44466 | 24 编译器没那么傻
【在 f*******n 的大作中提到】
: 坏处就是每次用一个方法就会inline，所以一个方法的码可能重复几十遍
|
d*********n
发帖数: 43 | 25 有个最大的问题，dependency
第一是任何一个地方的一个小修改，会引起后面所有依赖文件都需要rebuild
这个在几十上百个project的时候是极大的代价
另一个问题很多时候class实现的时候依赖其他的库或者其他的第三方源代码
这样所有内联必然带来的效果是dependency tree末端的会依赖所有的东西
编译器估计会爆炸掉，dependency得冲突也必然发生
【在 t****t 的大作中提到】
: 编译速度慢是一方面, 另一方面inline太多的话, binary size会变大, 有时不是一件
: 好事(e.g. cache efficiency). 当然如果是template那也没办法. 我一般的做法是把
: 常用的instantiation变成extern放在另一个.cpp里, 不常用的就当场实现.
: 不过我对你说的定义和实现分开写效率太低有问题. 你把所有的方法都写在头文件里面
: 效率就高了? 这根本没有关系的嘛. 你要说写习惯了java那是另一回事. 我还说阅读代
: 码时只看interface效率更高呢.
|
h*******u
发帖数: 15326 | 26 inline函数compile的时候扩展，最后编译的可执行文件体积庞大。
你这是没写过太大的项目吧
【在 w***g 的大作中提到】
: 就是写成跟java一样，所有的类只有.h文件，然后main.cpp #include所有的类。
: 我一直都是这么搞的，也没出过什么问题，除了编译速度超慢以外。实在受不了定义和
: 实现分开的写法，效率太低。
: 但我知道这么干肯定是有问题的。就是不知道最主要的问题在哪。
|
h*******u
发帖数: 15326 | 27 人是template
【在 y****e 的大作中提到】
: open source有很多就这么干的。boost里很多库就是这么干的，好处是基于它的开发不
: 再需要链接库文件。header only dependent。
|
D*******a
发帖数: 3688 | 28 It's just a request and compilers are not obligated to respect this request.
【在 h*******u 的大作中提到】
: inline函数compile的时候扩展，最后编译的可执行文件体积庞大。
: 你这是没写过太大的项目吧
|
h*******u
发帖数: 15326 | 29 这就变成严重依赖编译器了
request.
【在 D*******a 的大作中提到】
: It's just a request and compilers are not obligated to respect this request.
|
l*********s
发帖数: 5409 | 30 yeap. In addition, there are plugin to automatically generate skeleton
implementations based on header files.
【在 t****t 的大作中提到】
: 编译速度慢是一方面, 另一方面inline太多的话, binary size会变大, 有时不是一件
: 好事(e.g. cache efficiency). 当然如果是template那也没办法. 我一般的做法是把
: 常用的instantiation变成extern放在另一个.cpp里, 不常用的就当场实现.
: 不过我对你说的定义和实现分开写效率太低有问题. 你把所有的方法都写在头文件里面
: 效率就高了? 这根本没有关系的嘛. 你要说写习惯了java那是另一回事. 我还说阅读代
: 码时只看interface效率更高呢.
|
|
|
t****t
发帖数: 6806 | 31 这个不用担心, 所有的编译器都知道太长的不做inline.
问题在这里, 如果把实现放在头文件里, 如果不是模板, 就必须是inline. 有些可
inline可不inline的, 就变成inline了, 这样必然会造成一些体积的增大.
【在 h*******u 的大作中提到】
: 这就变成严重依赖编译器了
:
: request.
|
m******h
发帖数: 1059 | 32 unable to handle circular dependency
large code size and duplication reduce cpu cache hit rate: slower |
x****u
发帖数: 44466 | 33 inline这个关键字还有什么实际作用么？
【在 t****t 的大作中提到】
: 这个不用担心, 所有的编译器都知道太长的不做inline.
: 问题在这里, 如果把实现放在头文件里, 如果不是模板, 就必须是inline. 有些可
: inline可不inline的, 就变成inline了, 这样必然会造成一些体积的增大.
|
t****t
发帖数: 6806 | 34 你想说什么?
【在 x****u 的大作中提到】
: inline这个关键字还有什么实际作用么？
|
x****u
发帖数: 44466 | 35 好像没有说法说放在header里面的东西编译器会优先内联吧。
【在 t****t 的大作中提到】
: 你想说什么?
|
r********n
发帖数: 7441 | 36 not necessary, the compiler will correct over-killed inline functions
【在 l********a 的大作中提到】
: 在h/hpp中实现的的话,如果用户要基于你的代码进行二次开发,你的源码就暴露了
|
k********u
发帖数: 148 | 37 看你inline的函数是不是简单了，简单的还好，复杂的一个运行都占内存，全部inline
不要太占内存哦~~~~~ |
t****t
发帖数: 6806 | 38 如果不是模板, 就一定要标inine, 否则多次include就是multiple definiton.
所以你想说的就是标了inline的并不会优先inline?
【在 x****u 的大作中提到】
: 好像没有说法说放在header里面的东西编译器会优先内联吧。
|
A*********l
发帖数: 2005 | 39 If user's input is pure data, like string/xml kind of stuff, yes, you code
should handle all that and should never crash. Just like a server receiving
request from client, no matter what kind of garbage data client throws at
your server, your server should not crash.
But at in-process API level? How can you avoid crash if in language like C/C
++, someone simply pass you a garbage pointer? You can check whether if the
pointer is NULL to avoid crash, but you can't really check whether that
pointer points to garbage. For lib API like memcpy(), if you pass it garbage
pointer, crash (or, more accurately, undefined behavior) is expected.
【在 p*u 的大作中提到】
:
: ur library should handle users' bad behaviors and never crash; u can throw
: exceptions or return error codes when user code tries to screw up.
|
x****u
发帖数: 44466 | 40 现在这个关键字对编译器还有效力么？
【在 t****t 的大作中提到】
: 如果不是模板, 就一定要标inine, 否则多次include就是multiple definiton.
: 所以你想说的就是标了inline的并不会优先inline?
|
|
|
t****t
发帖数: 6806 | 41 据我所知是有的, 当然从最开始这就是个hint, 所以肯定不总是有.
你有什么经验或证据说, 总是没有吗?
【在 x****u 的大作中提到】
: 现在这个关键字对编译器还有效力么？
|
o**o
发帖数: 3964 | 42 编译器优化比如icc的multi-file优化能彻底解决size问题，但是编译速度会更慢。
不过说到底是编译器或者make不够聪明。如果智能地判断接口变化，或者dependency到
函数级别，很多文件不用重编。
【在 t****t 的大作中提到】
: 编译速度慢是一方面, 另一方面inline太多的话, binary size会变大, 有时不是一件
: 好事(e.g. cache efficiency). 当然如果是template那也没办法. 我一般的做法是把
: 常用的instantiation变成extern放在另一个.cpp里, 不常用的就当场实现.
: 不过我对你说的定义和实现分开写效率太低有问题. 你把所有的方法都写在头文件里面
: 效率就高了? 这根本没有关系的嘛. 你要说写习惯了java那是另一回事. 我还说阅读代
: 码时只看interface效率更高呢.
|
x****u
发帖数: 44466 | 43 最开始的时候，inline或者register都有意义，我的印象是最近的编译器都忽略这些参
数。没什么编程指南说，class的函数不要放在h里面写。ATL/WTL就是一个cpp也没有的
库。
【在 t****t 的大作中提到】
: 据我所知是有的, 当然从最开始这就是个hint, 所以肯定不总是有.
: 你有什么经验或证据说, 总是没有吗?
|
x****u
发帖数: 44466 | 44 C/C++的所谓头文件就是特定历史时期遗留的缺陷。用别的语言写个helloworld，3行代
码的就编译三行。用C或者C++写的，include一个头就是几千行。
不过话说回来了，标准的C版helloworld根本不写include，这才是本来的设计出发点。
【在 o**o 的大作中提到】
: 编译器优化比如icc的multi-file优化能彻底解决size问题，但是编译速度会更慢。
: 不过说到底是编译器或者make不够聪明。如果智能地判断接口变化，或者dependency到
: 函数级别，很多文件不用重编。
|
h**********c
发帖数: 4120 | 45 A good s/w product should have the best possible CPU hit rate, given you
have full-filled 0. it does not crash 1. functional requirements.
hit-rate is NFR.
inline function will improve hit-rate for CPU given the code length is small.
if ( i>20)
incr(i);
else
decr(i);
inline void incr (int & i) {
i += 1;
}
inline void decr (int & i) {
i -= 1;
}
From CPU architecture view, inline function greatly increase the chance the
subroutine is within the same cache block as the caller -- a hit. If incr or
decr is not in the cache -- a miss. CPU performance greatly reduced.When
the CPU load the non-inline function from program memory, not only the
incr or decr only, but the same size as the cache segment.
But, inline, can not be too big. If it is bigger than cache segment, misses
will happen again. You gain may be bigger than you lose.
inline segment, as I remember can not do heap ops. e.g., malloc. not sure.
For short, anything done in inline, can not change the inline function size
in program memory space. So probably, you can't use functor. |
pv
发帖数: 83 | 46 that's a compilers' job
I prefer
to optimize code like this
small.
【在 h**********c 的大作中提到】
: A good s/w product should have the best possible CPU hit rate, given you
: have full-filled 0. it does not crash 1. functional requirements.
: hit-rate is NFR.
: inline function will improve hit-rate for CPU given the code length is small.
: if ( i>20)
: incr(i);
: else
: decr(i);
: inline void incr (int & i) {
: i += 1;
|
pv
发帖数: 83 | 47 you can create a header smaller by your own.
【在 x****u 的大作中提到】
: C/C++的所谓头文件就是特定历史时期遗留的缺陷。用别的语言写个helloworld，3行代
: 码的就编译三行。用C或者C++写的，include一个头就是几千行。
: 不过话说回来了，标准的C版helloworld根本不写include，这才是本来的设计出发点。
|
h**********c
发帖数: 4120 | 48 In fact it is profiler's job.
Rarely see someone profile a single c/c++/java/etc class.
Only the product prerealse, someone will run some benchmark tools.
The benchmarker may not write program at all.
【在 pv 的大作中提到】
: that's a compilers' job
: I prefer
: to optimize code like this
:
: small.
|
x****u
发帖数: 44466 | 49 std的头搞那么长是有原因的，自己搞个替代，那还不如直接裸奔。
到了CPP，语法检查严格了，裸奔也不可能了。
【在 pv 的大作中提到】
: you can create a header smaller by your own.
|
k*******d
发帖数: 1340 | 50 有的， 不是template的话，如果函数定义没有inline，就是redefinition
【在 x****u 的大作中提到】
: 现在这个关键字对编译器还有效力么？
|
|
|
o**o
发帖数: 3964 | 51 h/c后缀文件的区分完全是为了协助记忆，方便读程序的人理解接口和实现。功能上两
类文件应该没有区别。从预编译的过程来看，如果include一个.c文件肯定也编译，虽
然我并不这样用。
不include header的helloworld能编译执行？如果真是这样，一定有地方隐含设置了声
明外部函数。这也算的话，所有c程序都可以。
【在 x****u 的大作中提到】
: C/C++的所谓头文件就是特定历史时期遗留的缺陷。用别的语言写个helloworld，3行代
: 码的就编译三行。用C或者C++写的，include一个头就是几千行。
: 不过话说回来了，标准的C版helloworld根本不写include，这才是本来的设计出发点。
|
t****t
发帖数: 6806 | 52 ATL是template, 当然必须在头文件里写, 而且我前面说得很清楚, "如果不是模板",
意思就是说, 如果是模板, 那就可以不是inline
你的印象是有证据还是仅仅是你的印象而已?
【在 x****u 的大作中提到】
: 最开始的时候，inline或者register都有意义，我的印象是最近的编译器都忽略这些参
: 数。没什么编程指南说，class的函数不要放在h里面写。ATL/WTL就是一个cpp也没有的
: 库。
|
t****t
发帖数: 6806 | 53 这个是两件事, 我们说的是inline对优化的作用, 不是语法上的.
【在 k*******d 的大作中提到】
: 有的， 不是template的话，如果函数定义没有inline，就是redefinition
|
i***c
发帖数: 301 | |
x****u
发帖数: 44466 | 55 class里面的函数，可以省略这个关键字默认内联。
现在讨论的是，这个inline对编译器是否有强制作用。我印象中看过哪里的介绍，说不
要依赖这个关键词，这个事情应该交给优化处理。
【在 t****t 的大作中提到】
: ATL是template, 当然必须在头文件里写, 而且我前面说得很清楚, "如果不是模板",
: 意思就是说, 如果是模板, 那就可以不是inline
: 你的印象是有证据还是仅仅是你的印象而已?
|
t****t
发帖数: 6806 | 56 从语法上来说, 不管是不是在头文件里, 成员总是可以写在class外面或里面. 但是如
果不是模板, 那就一定要标inline, 不管是显式的还是隐式的, 理由说过了.
如果是模板, 那class外的可以不标inline, 并且不违犯ODR.
从优化上来说, inline从来都没有强制作用, 从来都是一个提示. 但是不依赖这个关键
字和这个关键字有没有(优化上的)作用, 还是有区别的. 现代的编译器用的策略应该是
对可做可不做的依靠提示.
【在 x****u 的大作中提到】
: class里面的函数，可以省略这个关键字默认内联。
: 现在讨论的是，这个inline对编译器是否有强制作用。我印象中看过哪里的介绍，说不
: 要依赖这个关键词，这个事情应该交给优化处理。
|
x****u
发帖数: 44466 | 57 inline如果可能有效果，那么编程指南上是否该说用inline提高速度？
【在 t****t 的大作中提到】
: 从语法上来说, 不管是不是在头文件里, 成员总是可以写在class外面或里面. 但是如
: 果不是模板, 那就一定要标inline, 不管是显式的还是隐式的, 理由说过了.
: 如果是模板, 那class外的可以不标inline, 并且不违犯ODR.
: 从优化上来说, inline从来都没有强制作用, 从来都是一个提示. 但是不依赖这个关键
: 字和这个关键字有没有(优化上的)作用, 还是有区别的. 现代的编译器用的策略应该是
: 对可做可不做的依靠提示.
|
t****t
发帖数: 6806 | 58 这个没道理, inline又不是没有副作用, 不能盲目乱用啊. 编程指南是什么东西?
【在 x****u 的大作中提到】
: inline如果可能有效果，那么编程指南上是否该说用inline提高速度？
|
x****u
发帖数: 44466 | 59 不是说乱用，是说某些地方要写某些地方不要写。
可我的印象是，只要指定编译器的优化策略就足够了。
【在 t****t 的大作中提到】
: 这个没道理, inline又不是没有副作用, 不能盲目乱用啊. 编程指南是什么东西?
|
f*****e
发帖数: 2992 | 60 这个够全面吗？
http://www.parashift.com/c++-faq/inline-functions.html
【在 x****u 的大作中提到】
: 不是说乱用，是说某些地方要写某些地方不要写。
: 可我的印象是，只要指定编译器的优化策略就足够了。
|
|
|
t****t
发帖数: 6806 | 61 除了满足ODR的需要以外, 所有的地方都不写或者所有的都写, 都是可以的. 编译器的
开关一般有更高的优先级. 但是: (1)所有的地方都不写或所有的地方都不写并非最佳
策略. (2)不管程序员用什么策略, inline关键字(隐含或显式)仍然对编译器有提示的
作用.
【在 x****u 的大作中提到】
: 不是说乱用，是说某些地方要写某些地方不要写。
: 可我的印象是，只要指定编译器的优化策略就足够了。
|
x****u
发帖数: 44466 | 62 这里讨论的是，这个提示是存在的么？
这个问题有实际意义，比如说写工具类的话，省略全部的cpp可以减少使用上的问题。
【在 t****t 的大作中提到】
: 除了满足ODR的需要以外, 所有的地方都不写或者所有的都写, 都是可以的. 编译器的
: 开关一般有更高的优先级. 但是: (1)所有的地方都不写或所有的地方都不写并非最佳
: 策略. (2)不管程序员用什么策略, inline关键字(隐含或显式)仍然对编译器有提示的
: 作用.
|
t****t
发帖数: 6806 | 63 我说是存在的, 你说不存在. 有文档说明不存在么?
【在 x****u 的大作中提到】
: 这里讨论的是，这个提示是存在的么？
: 这个问题有实际意义，比如说写工具类的话，省略全部的cpp可以减少使用上的问题。
|
d****p
发帖数: 685 | 64 C/C++, as a static language, compiles translation units separately and
header files make sure different object files talk with each other via
correct calling conventions.
Until the C/C++ compilation model changes, header files will be always there.
And your comparison between "other languages" and C/C++ doesn't make much
sense since so called "other languages" are usually based on C/C++
components.
【在 x****u 的大作中提到】
: C/C++的所谓头文件就是特定历史时期遗留的缺陷。用别的语言写个helloworld，3行代
: 码的就编译三行。用C或者C++写的，include一个头就是几千行。
: 不过话说回来了，标准的C版helloworld根本不写include，这才是本来的设计出发点。
|
x****u
发帖数: 44466 | 65 你这话说的。。
现在所有的文档都是强调编译器可以忽略，不过从MS在ATL中的表现来看，在VC里面没
什么实际作用的可能性存在。
【在 t****t 的大作中提到】
: 我说是存在的, 你说不存在. 有文档说明不存在么?
|
x****u
发帖数: 44466 | 66 PASCAL啊。这个header文件也是C++语法提示难做的一大原因。
there.
【在 d****p 的大作中提到】
: C/C++, as a static language, compiles translation units separately and
: header files make sure different object files talk with each other via
: correct calling conventions.
: Until the C/C++ compilation model changes, header files will be always there.
: And your comparison between "other languages" and C/C++ doesn't make much
: sense since so called "other languages" are usually based on C/C++
: components.
|
t****t
发帖数: 6806 | 67 好吧, 说来说去没什么营养. 不然你去作个试验吧. 上次是我给的实际example, 这次
轮到你了.
【在 x****u 的大作中提到】
: 你这话说的。。
: 现在所有的文档都是强调编译器可以忽略，不过从MS在ATL中的表现来看，在VC里面没
: 什么实际作用的可能性存在。
|
x****u
发帖数: 44466 | 68 这里讨论的是一个很实际的问题，inline关键字对优化是否产生影响。
你东拉西扯那么多话没一点新意，现在开始叫我举证了。
【在 t****t 的大作中提到】
: 好吧, 说来说去没什么营养. 不然你去作个试验吧. 上次是我给的实际example, 这次
: 轮到你了.
|
t****t
发帖数: 6806 | 69 那你想要怎么解决呢, 说来说去你也没证据我也没证据. 这问题本来就没新意, 说出花
来也没新意.
本来我举证也问题不大, 但是上次是我举证的而且正确, 好歹我也应该有benefit of
the doubt吧. 所以轮到你了.
【在 x****u 的大作中提到】
: 这里讨论的是一个很实际的问题，inline关键字对优化是否产生影响。
: 你东拉西扯那么多话没一点新意，现在开始叫我举证了。
|
x****u
发帖数: 44466 | 70 你真是很无聊。
关于VC，找到了MSDN的说法: inline仅在编译器认为对整体优化有益的情况下才执行，
如果希望尽可能的展开，有另一个关键字叫__forceinline。当然这个forceinline在无
法inline的时候还是被忽略。
所以说，完全不用担心class的函数全部隐含inline会影响效率。
【在 t****t 的大作中提到】
: 那你想要怎么解决呢, 说来说去你也没证据我也没证据. 这问题本来就没新意, 说出花
: 来也没新意.
: 本来我举证也问题不大, 但是上次是我举证的而且正确, 好歹我也应该有benefit of
: the doubt吧. 所以轮到你了.
|
|
|
t****t
发帖数: 6806 | 71 这个回答和我们的问题不是一回事吧? 这并没有完全回答, inline关键字会不会对是否
inline产生影响. 这个只是说, 标了inline的函数不一定会被inline, 但是这一点所有
人都知道.
同样的一个函数, 在语法允许的情况下编译两次, 一次标inline, 另一次不标, 如果任
何情况下两次编译器运行的结果都一样, 这个叫做inline关键字对优化没影响. 我认为
that's not the case.
【在 x****u 的大作中提到】
: 你真是很无聊。
: 关于VC，找到了MSDN的说法: inline仅在编译器认为对整体优化有益的情况下才执行，
: 如果希望尽可能的展开，有另一个关键字叫__forceinline。当然这个forceinline在无
: 法inline的时候还是被忽略。
: 所以说，完全不用担心class的函数全部隐含inline会影响效率。
|
x****u
发帖数: 44466 | 72 别的地方说了，不标inline的函数也可能被auto－inline。
加起来就是说，不管是不是inline，只要你不用别的内部关键字，编译器只会从全局角
度做决定。
【在 t****t 的大作中提到】
: 这个回答和我们的问题不是一回事吧? 这并没有完全回答, inline关键字会不会对是否
: inline产生影响. 这个只是说, 标了inline的函数不一定会被inline, 但是这一点所有
: 人都知道.
: 同样的一个函数, 在语法允许的情况下编译两次, 一次标inline, 另一次不标, 如果任
: 何情况下两次编译器运行的结果都一样, 这个叫做inline关键字对优化没影响. 我认为
: that's not the case.
|
t****t
发帖数: 6806 | 73 这个我也知道, 但是仍然不能说明inline关键字对优化策略没影响是不是?
【在 x****u 的大作中提到】
: 别的地方说了，不标inline的函数也可能被auto－inline。
: 加起来就是说，不管是不是inline，只要你不用别的内部关键字，编译器只会从全局角
: 度做决定。
|
x****u
发帖数: 44466 | 74 对于加这个关键字的函数，只有全局分析有必要时才展开；
不加这个关键字的函数，只有全局分析有必要时才展开。
【在 t****t 的大作中提到】
: 这个我也知道, 但是仍然不能说明inline关键字对优化策略没影响是不是?
|
t****t
发帖数: 6806 | 75 ok, you win, I do the experiment for you.
One of the results is inlined, the other is not.
I'll omit the comments.
******30.C*******
#include
#include
using namespace std;
IL double foo(double x)
{
double a=10;
for (int i=0; i<10; i++) {
a=a+sin(i*x);
}
return a;
}
int main()
{
double g;
cin>>g;
cout<
}
$ g++ -O2 -S -D IL="" 30.C -o - | c++filt >! 30_noinline.s
$ g++ -O2 -S -D IL="inline" 30.C -o - | c++filt > ! 30_inline.s
$ g++ -v
使用内建 specs。
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.6.0/lto-wrapper
目标：x86_64-redhat-linux
配置为：../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/
share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
线程模型：posix
gcc 版本 4.6.0 20110603 (Red Hat 4.6.0-10) (GCC)
【在 x****u 的大作中提到】
: 对于加这个关键字的函数，只有全局分析有必要时才展开；
: 不加这个关键字的函数，只有全局分析有必要时才展开。
|
t****t
发帖数: 6806 | 76 一个运动员, 每天饿了要吃饭.
一个正常人, 每天饿了要吃饭.
所以是不是运动员, 和饭量没关系.
【在 x****u 的大作中提到】
: 对于加这个关键字的函数，只有全局分析有必要时才展开；
: 不加这个关键字的函数，只有全局分析有必要时才展开。
|
n******t
发帖数: 4406 | 77 不知道你在较什么劲.就算是hint和没有也是不一样的.
就算你用了较低的优化级别,你还是可能希望对某些函数inline.
【在 x****u 的大作中提到】
: 别的地方说了，不标inline的函数也可能被auto－inline。
: 加起来就是说，不管是不是inline，只要你不用别的内部关键字，编译器只会从全局角
: 度做决定。
|
x****u
发帖数: 44466 | 78 回帖之前要看贴
【在 n******t 的大作中提到】
: 不知道你在较什么劲.就算是hint和没有也是不一样的.
: 就算你用了较低的优化级别,你还是可能希望对某些函数inline.
|
b*****n
发帖数: 2324 | 79 exaclty.
做大项目的肯定都知道cpp（definition）跟h file（declaration）的内容分开很重要。
【在 D*******a 的大作中提到】
: boost may be a different case due to its heavy template usage
|
b*****n
发帖数: 2324 | 80 for a second, i thought you meant BS = bullshit
【在 pv 的大作中提到】
: i think the best explantion is given by BS in his book
: the C++ programming language
|
|
|
b*****n
发帖数: 2324 | 81 如果有header guard的话，在同一个binary里不会。在不同的binary里就会有各自的实
现。link起来以后就出现多个binary copy了。如果用来global variable就更SB了。
【在 x****u 的大作中提到】
: 编译器没那么傻
|
b*****n
发帖数: 2324 | 82 inline跟definition放在header是两回事。
即使后者也可以不inline的。
【在 h*******u 的大作中提到】
: inline函数compile的时候扩展，最后编译的可执行文件体积庞大。
: 你这是没写过太大的项目吧
|
b*****n
发帖数: 2324 | 83 你搞错了。把实现放在头文件并不等于inline。要不为什么还要有inline这个keyword
，直接放头文件不就行了。
【在 t****t 的大作中提到】
: 这个不用担心, 所有的编译器都知道太长的不做inline.
: 问题在这里, 如果把实现放在头文件里, 如果不是模板, 就必须是inline. 有些可
: inline可不inline的, 就变成inline了, 这样必然会造成一些体积的增大.
|
t****t
发帖数: 6806 | 84 if the definition is not template, it must be inline, otherwise it's against
ODR. strictly speaking, you should make it internal linkage to satisfy ODR;
that means you can make it static if you don't want inline. but IMO that's
even worse than inline.
of course, if it is only included by one compilation unit, it doesn't have
to be inline -- but what's the point of putting it in header file?
keyword
【在 b*****n 的大作中提到】
: 你搞错了。把实现放在头文件并不等于inline。要不为什么还要有inline这个keyword
: ，直接放头文件不就行了。
|
h*c
发帖数: 1859 | 85 the class definition in header is an exception
it does not violate ODR
as I remembered
against
ODR;
s
【在 t****t 的大作中提到】
: if the definition is not template, it must be inline, otherwise it's against
: ODR. strictly speaking, you should make it internal linkage to satisfy ODR;
: that means you can make it static if you don't want inline. but IMO that's
: even worse than inline.
: of course, if it is only included by one compilation unit, it doesn't have
: to be inline -- but what's the point of putting it in header file?
:
: keyword
|
t****t
发帖数: 6806 | 86 yes, class definition does not violate ODR. but member function is no
exception. and member function inside class definition is implicit inline
anyway. member function outside class definition has to be inline to be ODR.
【在 h*c 的大作中提到】
: the class definition in header is an exception
: it does not violate ODR
: as I remembered
:
: against
: ODR;
: s
|
r***e
发帖数: 1840 | 87 Not necessary. With the #ifdef guard. The header file will be included only
once in one translation unit. So only one definition.
ODR.
【在 t****t 的大作中提到】
: yes, class definition does not violate ODR. but member function is no
: exception. and member function inside class definition is implicit inline
: anyway. member function outside class definition has to be inline to be ODR.
|
t****t
发帖数: 6806 | 88 你这都不知道我们在说什么, 还是先搞清楚ODR是控制什么东西再说吧.
only
【在 r***e 的大作中提到】
: Not necessary. With the #ifdef guard. The header file will be included only
: once in one translation unit. So only one definition.
:
: ODR.
|
