Redian新闻
>
Power electronics engineer research position (转载)
avatar
Power electronics engineer research position (转载)# EE - 电子工程
i*3
1
1.[合集] 请推荐个炒锅
☆─────────────────────────────────────☆
paulga (paul) 于 (Wed May 28 15:12:43 2008) 提到:
要求不太重 热的快 不粘 无油烟
现在正在用的锅(carbon streel)已经用了快一年了,太重 每次炒菜都粘 擦洗太费事
☆─────────────────────────────────────☆
treexlx (树书鼠数叔) 于 (Wed May 28 20:44:01 2008) 提到:
好锅一般都重
轻的就肯定有油烟

☆─────────────────────────────────────☆
ibad23 (好好的小坏坏) 于 (Wed May 28 22:33:50 2008) 提到:
大家经常讨论这处问题,你用关键字往前搜一下吧,可以搜到的,希望对你有帮助
☆─────────────────────────────────────☆
paulga (paul) 于 (Thu May 29 15:10:07 2008) 提到:
搜过,只搜到一个推荐的锅
htt
avatar
m*b
2
Description
Provide support to the sales team and channel partners in pursuit of
business opportunities. Provide technical recommendations to develop a
business relationship for MileWeb and its channel partners with customers.
Expected to help define, accelerate and close transactional and enterprise
business within business territory or defined set of accounts. Must perform
a variety of tasks, including product overviews, customized presentations
and demonstrations, complex solution design, infrastructure surveys,
proposal development, advanced product evaluations and product feature/
benefit discussions. Duties include:
Must be able to describe MileWeb's key messages and vision and discuss key
benefits for our customers
Must be recognized and utilized as a technical resource
Must maintain current knowledge of complete product set and be able to
describe key features and benefits of each
Establish positive working relationships, internal and external
Proactively seek out new sales opportunities by developing new and existing
technical relationships within accounts
Document client feature requests and issues
Drive the design of customer oriented solutions
The role, responsibilities and area of focus will change and develop over
time along with the company's rapid growth.
Required Skills
Technical understanding of CDN technology
Strong relationship building skills
Communicates effectively verbally; communicates clearly in writing
Excellent presentation skills with an ability to build and present high
quality product demonstrations (to both technical and executive audiences)
Must be fluent in English
Demonstrates high ethics and integrity
Ability to travel up to 10-20 percent of the time, including international
if necessary
We offer competitive salaries with demonstrated experience. Employee
benefits include:
US company stock options
Medical, Dental and Vision Plan
Paid vacations and holidays
401K
Please send your resume to: [email protected]
/* */
avatar
j*i
3
1. Chase Freedom Card - $150 Bonus Cash Back + Cashback on Purchases
懒人直接点以下链接
http://goo.gl/uZ69X
或进入blog查看
http://bankbonus.blog.163.com/
2.Discover More Card $100 bonus 最适合中美间使用的多彩卡片or no balance
transfer fee
http://goo.gl/hQiX1
3. Chase 力作 continental onepass信用卡 首笔消费就送30000miles(无金额限制)
+$50免费bonus 最新优惠 信用卡首选 都有详尽的每个步骤申请和使用兑换积分的
细节
http://bankbonus.blog.163.com/
4. United Mileage Plus Card 30000miles offer+$50bonus 只需要任意一笔消费无金
额限制
5. 免费的Marriott Hotel 四晚酒店入住 只需消费一笔无金额限制
6.免费的美国国内往返机票和美国往返中国机票建议
http://bankbonus.blog.163.com/
最近申请chase家的这个信用卡会弹出一个页面,写着Before you go…We hope you
will reconsider 难不成他们家最近被人拿太多这个免费机票了 不用对它客气,
赶紧点击Return&Apply, 拿到落袋为安。
。。。。都有详尽的每个步骤申请和使用兑换积分的细节和相应链接,请收藏转发
http://bankbonus.blog.163.com/
avatar
C*0
4
准备代理国内电子产品在美销售,厂家接受两种方式:1。使用原厂品牌。2。使用我们
自己的品牌。
想咨询一下有经验的XDJM和前辈,这两种方式各自的优缺点。如果使用自己的品牌是否
会风险大一些,投入更多?多大程度?如果一旦有责任事故,怎样处理?
多谢!
avatar
w*g
5
就是写成跟java一样,所有的类只有.h文件,然后main.cpp #include所有的类。
我一直都是这么搞的,也没出过什么问题,除了编译速度超慢以外。实在受不了定义和
实现分开的写法,效率太低。
但我知道这么干肯定是有问题的。就是不知道最主要的问题在哪。
avatar
s*s
6
【 以下文字转载自 JobHunting 讨论区 】
发信人: shenms (shenms), 信区: JobHunting
标 题: Power electronics engineer research position
发信站: BBS 未名空间站 (Fri Feb 25 21:49:43 2011, 美东)
Power electronics engineer research position in corporate research center,
multiple opening
skill set (any of the following):
DSP/FPGA programming
power converter design
motor control
Modeling and simulation
motor design
Requirement:
PhD or MS with related experience
If interested, please send resume to c***********[email protected]
avatar
q*2
7
牛摆!N年前做过的事,911 以后逐年放手到彻底放弃。 不过是很有意义的一件事
这两个方案都有利有弊,看你的实力和长期计划,合作方式,个人兴趣与专长,市场前
景,研发实力等等。
贴个牌很容易,费用也不高。
但要做成名牌就难了,取决于太多因数。。。
事故吗,一是产品要认证,二是要保险。。。但要是出了大事,就脱不了干系了

【在 C**********0 的大作中提到】
: 准备代理国内电子产品在美销售,厂家接受两种方式:1。使用原厂品牌。2。使用我们
: 自己的品牌。
: 想咨询一下有经验的XDJM和前辈,这两种方式各自的优缺点。如果使用自己的品牌是否
: 会风险大一些,投入更多?多大程度?如果一旦有责任事故,怎样处理?
: 多谢!

avatar
l*a
8
在h/hpp中实现的的话,如果用户要基于你的代码进行二次开发,你的源码就暴露了
avatar
E*a
9
地方?薪水,职位。。。

【在 s****s 的大作中提到】
: 【 以下文字转载自 JobHunting 讨论区 】
: 发信人: shenms (shenms), 信区: JobHunting
: 标 题: Power electronics engineer research position
: 发信站: BBS 未名空间站 (Fri Feb 25 21:49:43 2011, 美东)
: Power electronics engineer research position in corporate research center,
: multiple opening
: skill set (any of the following):
: DSP/FPGA programming
: power converter design
: motor control

avatar
C*0
10
Could you give more detail?
Thanks a lot!

【在 q***2 的大作中提到】
: 牛摆!N年前做过的事,911 以后逐年放手到彻底放弃。 不过是很有意义的一件事
: 这两个方案都有利有弊,看你的实力和长期计划,合作方式,个人兴趣与专长,市场前
: 景,研发实力等等。
: 贴个牌很容易,费用也不高。
: 但要做成名牌就难了,取决于太多因数。。。
: 事故吗,一是产品要认证,二是要保险。。。但要是出了大事,就脱不了干系了

avatar
x*u
11
没问题,ATL就是这么实现的。
不过编译会非常的慢。

【在 w***g 的大作中提到】
: 就是写成跟java一样,所有的类只有.h文件,然后main.cpp #include所有的类。
: 我一直都是这么搞的,也没出过什么问题,除了编译速度超慢以外。实在受不了定义和
: 实现分开的写法,效率太低。
: 但我知道这么干肯定是有问题的。就是不知道最主要的问题在哪。

avatar
s*s
12
地点在Connecticut, 另外两项因人而异

【在 E*****a 的大作中提到】
: 地方?薪水,职位。。。
avatar
C*0
13
能说说放弃的原因吗?看了你很多帖子,前辈呀!如果用自己的牌子,是否需要注册‘
trademark'?
多谢!

【在 q***2 的大作中提到】
: 牛摆!N年前做过的事,911 以后逐年放手到彻底放弃。 不过是很有意义的一件事
: 这两个方案都有利有弊,看你的实力和长期计划,合作方式,个人兴趣与专长,市场前
: 景,研发实力等等。
: 贴个牌很容易,费用也不高。
: 但要做成名牌就难了,取决于太多因数。。。
: 事故吗,一是产品要认证,二是要保险。。。但要是出了大事,就脱不了干系了

avatar
x*u
14
写在cpp里面一样,这里讨论的不是源代码vs库。

【在 l********a 的大作中提到】
: 在h/hpp中实现的的话,如果用户要基于你的代码进行二次开发,你的源码就暴露了
avatar
g*t
15
UTRC? 不错的地方.

地点在Connecticut, 另外两项因人而异

【在 s****s 的大作中提到】
: 地点在Connecticut, 另外两项因人而异
avatar
B*D
16
你做的啥产品?
能说说么?

【在 C**********0 的大作中提到】
: 能说说放弃的原因吗?看了你很多帖子,前辈呀!如果用自己的牌子,是否需要注册‘
: trademark'?
: 多谢!

avatar
a*l
17
楼上的意思是你可以把你的东西编译成binary,然后只给二次开发的人用头文件。

【在 x****u 的大作中提到】
: 写在cpp里面一样,这里讨论的不是源代码vs库。
avatar
b*y
18
I guess the corp. is Carrier
good location, hehe

【在 g****t 的大作中提到】
: UTRC? 不错的地方.
:
: 地点在Connecticut, 另外两项因人而异

avatar
C*0
19
电子产品,用于检测数据。
谢谢!

【在 B*D 的大作中提到】
: 你做的啥产品?
: 能说说么?

avatar
x*u
20
拿不到源代码时,发布Cpp的lib有很多潜在问题。

【在 a****l 的大作中提到】
: 楼上的意思是你可以把你的东西编译成binary,然后只给二次开发的人用头文件。
avatar
gr
21
康州那里很好么?房价会不会很贵?

【在 b***y 的大作中提到】
: I guess the corp. is Carrier
: good location, hehe

avatar
p*u
22
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所有的类。
: 我一直都是这么搞的,也没出过什么问题,除了编译速度超慢以外。实在受不了定义和
: 实现分开的写法,效率太低。
: 但我知道这么干肯定是有问题的。就是不知道最主要的问题在哪。

avatar
g*u
23
那边不是成天下雪民不聊生的么/

【在 b***y 的大作中提到】
: I guess the corp. is Carrier
: good location, hehe

avatar
a*l
24
well, it is THEIR problem, not YOUR problem.

【在 x****u 的大作中提到】
: 拿不到源代码时,发布Cpp的lib有很多潜在问题。
avatar
x*u
25
在你的库里面崩溃,还是你的责任啊。

【在 a****l 的大作中提到】
: well, it is THEIR problem, not YOUR problem.
avatar
a*l
26
同学,您不要这么软弱好吗?用户用的不对出了问题当然是用户的责任,怎么能怪到你头
上呢?比如说,你不给车换油,你能怪车子没设计好吗?

【在 x****u 的大作中提到】
: 在你的库里面崩溃,还是你的责任啊。
avatar
w*g
27
如果不怕源代码暴露,这个倒是问题不大。可以通过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.

avatar
p*u
28

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文件)

avatar
p*u
29

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 的大作中提到】
: 同学,您不要这么软弱好吗?用户用的不对出了问题当然是用户的责任,怎么能怪到你头
: 上呢?比如说,你不给车换油,你能怪车子没设计好吗?

avatar
y*e
30
open source有很多就这么干的。boost里很多库就是这么干的,好处是基于它的开发不
再需要链接库文件。header only dependent。
avatar
N*m
31
boost也不是全部都是

【在 y****e 的大作中提到】
: open source有很多就这么干的。boost里很多库就是这么干的,好处是基于它的开发不
: 再需要链接库文件。header only dependent。

avatar
D*a
32
boost may be a different case due to its heavy template usage

【在 y****e 的大作中提到】
: open source有很多就这么干的。boost里很多库就是这么干的,好处是基于它的开发不
: 再需要链接库文件。header only dependent。

avatar
f*n
33
坏处就是每次用一个方法就会inline,所以一个方法的码可能重复几十遍

【在 w***g 的大作中提到】
: 就是写成跟java一样,所有的类只有.h文件,然后main.cpp #include所有的类。
: 我一直都是这么搞的,也没出过什么问题,除了编译速度超慢以外。实在受不了定义和
: 实现分开的写法,效率太低。
: 但我知道这么干肯定是有问题的。就是不知道最主要的问题在哪。

avatar
d*q
34

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.

avatar
d*q
35

它真正需要编译的 多半是需要用到系统api的。
例如thread, datetime, regex,system等。似乎只有8个需要编译。
其他基本上都是include .hpp就行了。

【在 N*****m 的大作中提到】
: boost也不是全部都是
avatar
t*t
36
编译速度慢是一方面, 另一方面inline太多的话, binary size会变大, 有时不是一件
好事(e.g. cache efficiency). 当然如果是template那也没办法. 我一般的做法是把
常用的instantiation变成extern放在另一个.cpp里, 不常用的就当场实现.
不过我对你说的定义和实现分开写效率太低有问题. 你把所有的方法都写在头文件里面
效率就高了? 这根本没有关系的嘛. 你要说写习惯了java那是另一回事. 我还说阅读代
码时只看interface效率更高呢.

【在 w***g 的大作中提到】
: 就是写成跟java一样,所有的类只有.h文件,然后main.cpp #include所有的类。
: 我一直都是这么搞的,也没出过什么问题,除了编译速度超慢以外。实在受不了定义和
: 实现分开的写法,效率太低。
: 但我知道这么干肯定是有问题的。就是不知道最主要的问题在哪。

avatar
d*p
37
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所有的类。
: 我一直都是这么搞的,也没出过什么问题,除了编译速度超慢以外。实在受不了定义和
: 实现分开的写法,效率太低。
: 但我知道这么干肯定是有问题的。就是不知道最主要的问题在哪。

avatar
r*t
38
赞一个

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.

avatar
pv
39
i think the best explantion is given by BS in his book
the C++ programming language

【在 r****t 的大作中提到】
: 赞一个
:
: unnecessary

avatar
x*u
40
编译器没那么傻

【在 f*******n 的大作中提到】
: 坏处就是每次用一个方法就会inline,所以一个方法的码可能重复几十遍
avatar
d*n
41
有个最大的问题,dependency
第一是任何一个地方的一个小修改,会引起后面所有依赖文件都需要rebuild
这个在几十上百个project的时候是极大的代价
另一个问题很多时候class实现的时候依赖其他的库或者其他的第三方源代码
这样所有内联必然带来的效果是dependency tree末端的会依赖所有的东西
编译器估计会爆炸掉,dependency得冲突也必然发生

【在 t****t 的大作中提到】
: 编译速度慢是一方面, 另一方面inline太多的话, binary size会变大, 有时不是一件
: 好事(e.g. cache efficiency). 当然如果是template那也没办法. 我一般的做法是把
: 常用的instantiation变成extern放在另一个.cpp里, 不常用的就当场实现.
: 不过我对你说的定义和实现分开写效率太低有问题. 你把所有的方法都写在头文件里面
: 效率就高了? 这根本没有关系的嘛. 你要说写习惯了java那是另一回事. 我还说阅读代
: 码时只看interface效率更高呢.

avatar
h*u
42
inline函数compile的时候扩展,最后编译的可执行文件体积庞大。
你这是没写过太大的项目吧

【在 w***g 的大作中提到】
: 就是写成跟java一样,所有的类只有.h文件,然后main.cpp #include所有的类。
: 我一直都是这么搞的,也没出过什么问题,除了编译速度超慢以外。实在受不了定义和
: 实现分开的写法,效率太低。
: 但我知道这么干肯定是有问题的。就是不知道最主要的问题在哪。

avatar
h*u
43
人是template

【在 y****e 的大作中提到】
: open source有很多就这么干的。boost里很多库就是这么干的,好处是基于它的开发不
: 再需要链接库文件。header only dependent。

avatar
D*a
44
It's just a request and compilers are not obligated to respect this request.

【在 h*******u 的大作中提到】
: inline函数compile的时候扩展,最后编译的可执行文件体积庞大。
: 你这是没写过太大的项目吧

avatar
h*u
45
这就变成严重依赖编译器了

request.

【在 D*******a 的大作中提到】
: It's just a request and compilers are not obligated to respect this request.
avatar
l*s
46
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效率更高呢.

avatar
t*t
47
这个不用担心, 所有的编译器都知道太长的不做inline.
问题在这里, 如果把实现放在头文件里, 如果不是模板, 就必须是inline. 有些可
inline可不inline的, 就变成inline了, 这样必然会造成一些体积的增大.

【在 h*******u 的大作中提到】
: 这就变成严重依赖编译器了
:
: request.

avatar
m*h
48
unable to handle circular dependency
large code size and duplication reduce cpu cache hit rate: slower
avatar
x*u
49
inline这个关键字还有什么实际作用么?

【在 t****t 的大作中提到】
: 这个不用担心, 所有的编译器都知道太长的不做inline.
: 问题在这里, 如果把实现放在头文件里, 如果不是模板, 就必须是inline. 有些可
: inline可不inline的, 就变成inline了, 这样必然会造成一些体积的增大.

avatar
t*t
50
你想说什么?

【在 x****u 的大作中提到】
: inline这个关键字还有什么实际作用么?
avatar
x*u
51
好像没有说法说放在header里面的东西编译器会优先内联吧。

【在 t****t 的大作中提到】
: 你想说什么?
avatar
r*n
52
not necessary, the compiler will correct over-killed inline functions

【在 l********a 的大作中提到】
: 在h/hpp中实现的的话,如果用户要基于你的代码进行二次开发,你的源码就暴露了
avatar
k*u
53
看你inline的函数是不是简单了,简单的还好,复杂的一个运行都占内存,全部inline
不要太占内存哦~~~~~
avatar
t*t
54
如果不是模板, 就一定要标inine, 否则多次include就是multiple definiton.
所以你想说的就是标了inline的并不会优先inline?

【在 x****u 的大作中提到】
: 好像没有说法说放在header里面的东西编译器会优先内联吧。
avatar
A*l
55
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.

avatar
x*u
56
现在这个关键字对编译器还有效力么?

【在 t****t 的大作中提到】
: 如果不是模板, 就一定要标inine, 否则多次include就是multiple definiton.
: 所以你想说的就是标了inline的并不会优先inline?

avatar
t*t
57
据我所知是有的, 当然从最开始这就是个hint, 所以肯定不总是有.
你有什么经验或证据说, 总是没有吗?

【在 x****u 的大作中提到】
: 现在这个关键字对编译器还有效力么?
avatar
o*o
58
编译器优化比如icc的multi-file优化能彻底解决size问题,但是编译速度会更慢。
不过说到底是编译器或者make不够聪明。如果智能地判断接口变化,或者dependency到
函数级别,很多文件不用重编。

【在 t****t 的大作中提到】
: 编译速度慢是一方面, 另一方面inline太多的话, binary size会变大, 有时不是一件
: 好事(e.g. cache efficiency). 当然如果是template那也没办法. 我一般的做法是把
: 常用的instantiation变成extern放在另一个.cpp里, 不常用的就当场实现.
: 不过我对你说的定义和实现分开写效率太低有问题. 你把所有的方法都写在头文件里面
: 效率就高了? 这根本没有关系的嘛. 你要说写习惯了java那是另一回事. 我还说阅读代
: 码时只看interface效率更高呢.

avatar
x*u
59
最开始的时候,inline或者register都有意义,我的印象是最近的编译器都忽略这些参
数。没什么编程指南说,class的函数不要放在h里面写。ATL/WTL就是一个cpp也没有的
库。

【在 t****t 的大作中提到】
: 据我所知是有的, 当然从最开始这就是个hint, 所以肯定不总是有.
: 你有什么经验或证据说, 总是没有吗?

avatar
x*u
60
C/C++的所谓头文件就是特定历史时期遗留的缺陷。用别的语言写个helloworld,3行代
码的就编译三行。用C或者C++写的,include一个头就是几千行。
不过话说回来了,标准的C版helloworld根本不写include,这才是本来的设计出发点。

【在 o**o 的大作中提到】
: 编译器优化比如icc的multi-file优化能彻底解决size问题,但是编译速度会更慢。
: 不过说到底是编译器或者make不够聪明。如果智能地判断接口变化,或者dependency到
: 函数级别,很多文件不用重编。

avatar
h*c
61
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.
avatar
pv
62
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;

avatar
pv
63
you can create a header smaller by your own.

【在 x****u 的大作中提到】
: C/C++的所谓头文件就是特定历史时期遗留的缺陷。用别的语言写个helloworld,3行代
: 码的就编译三行。用C或者C++写的,include一个头就是几千行。
: 不过话说回来了,标准的C版helloworld根本不写include,这才是本来的设计出发点。

avatar
h*c
64
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.

avatar
x*u
65
std的头搞那么长是有原因的,自己搞个替代,那还不如直接裸奔。
到了CPP,语法检查严格了,裸奔也不可能了。

【在 pv 的大作中提到】
: you can create a header smaller by your own.
avatar
k*d
66
有的, 不是template的话,如果函数定义没有inline,就是redefinition

【在 x****u 的大作中提到】
: 现在这个关键字对编译器还有效力么?
avatar
o*o
67
h/c后缀文件的区分完全是为了协助记忆,方便读程序的人理解接口和实现。功能上两
类文件应该没有区别。从预编译的过程来看,如果include一个.c文件肯定也编译,虽
然我并不这样用。
不include header的helloworld能编译执行?如果真是这样,一定有地方隐含设置了声
明外部函数。这也算的话,所有c程序都可以。

【在 x****u 的大作中提到】
: C/C++的所谓头文件就是特定历史时期遗留的缺陷。用别的语言写个helloworld,3行代
: 码的就编译三行。用C或者C++写的,include一个头就是几千行。
: 不过话说回来了,标准的C版helloworld根本不写include,这才是本来的设计出发点。

avatar
t*t
68
ATL是template, 当然必须在头文件里写, 而且我前面说得很清楚, "如果不是模板",
意思就是说, 如果是模板, 那就可以不是inline
你的印象是有证据还是仅仅是你的印象而已?

【在 x****u 的大作中提到】
: 最开始的时候,inline或者register都有意义,我的印象是最近的编译器都忽略这些参
: 数。没什么编程指南说,class的函数不要放在h里面写。ATL/WTL就是一个cpp也没有的
: 库。

avatar
t*t
69
这个是两件事, 我们说的是inline对优化的作用, 不是语法上的.

【在 k*******d 的大作中提到】
: 有的, 不是template的话,如果函数定义没有inline,就是redefinition
avatar
i*c
70
请参考水木c++版
avatar
x*u
71
class里面的函数,可以省略这个关键字默认内联。
现在讨论的是,这个inline对编译器是否有强制作用。我印象中看过哪里的介绍,说不
要依赖这个关键词,这个事情应该交给优化处理。

【在 t****t 的大作中提到】
: ATL是template, 当然必须在头文件里写, 而且我前面说得很清楚, "如果不是模板",
: 意思就是说, 如果是模板, 那就可以不是inline
: 你的印象是有证据还是仅仅是你的印象而已?

avatar
t*t
72
从语法上来说, 不管是不是在头文件里, 成员总是可以写在class外面或里面. 但是如
果不是模板, 那就一定要标inline, 不管是显式的还是隐式的, 理由说过了.
如果是模板, 那class外的可以不标inline, 并且不违犯ODR.
从优化上来说, inline从来都没有强制作用, 从来都是一个提示. 但是不依赖这个关键
字和这个关键字有没有(优化上的)作用, 还是有区别的. 现代的编译器用的策略应该是
对可做可不做的依靠提示.

【在 x****u 的大作中提到】
: class里面的函数,可以省略这个关键字默认内联。
: 现在讨论的是,这个inline对编译器是否有强制作用。我印象中看过哪里的介绍,说不
: 要依赖这个关键词,这个事情应该交给优化处理。

avatar
x*u
73
inline如果可能有效果,那么编程指南上是否该说用inline提高速度?

【在 t****t 的大作中提到】
: 从语法上来说, 不管是不是在头文件里, 成员总是可以写在class外面或里面. 但是如
: 果不是模板, 那就一定要标inline, 不管是显式的还是隐式的, 理由说过了.
: 如果是模板, 那class外的可以不标inline, 并且不违犯ODR.
: 从优化上来说, inline从来都没有强制作用, 从来都是一个提示. 但是不依赖这个关键
: 字和这个关键字有没有(优化上的)作用, 还是有区别的. 现代的编译器用的策略应该是
: 对可做可不做的依靠提示.

avatar
t*t
74
这个没道理, inline又不是没有副作用, 不能盲目乱用啊. 编程指南是什么东西?

【在 x****u 的大作中提到】
: inline如果可能有效果,那么编程指南上是否该说用inline提高速度?
avatar
x*u
75
不是说乱用,是说某些地方要写某些地方不要写。
可我的印象是,只要指定编译器的优化策略就足够了。

【在 t****t 的大作中提到】
: 这个没道理, inline又不是没有副作用, 不能盲目乱用啊. 编程指南是什么东西?
avatar
f*e
76
这个够全面吗?
http://www.parashift.com/c++-faq/inline-functions.html

【在 x****u 的大作中提到】
: 不是说乱用,是说某些地方要写某些地方不要写。
: 可我的印象是,只要指定编译器的优化策略就足够了。

avatar
t*t
77
除了满足ODR的需要以外, 所有的地方都不写或者所有的都写, 都是可以的. 编译器的
开关一般有更高的优先级. 但是: (1)所有的地方都不写或所有的地方都不写并非最佳
策略. (2)不管程序员用什么策略, inline关键字(隐含或显式)仍然对编译器有提示的
作用.

【在 x****u 的大作中提到】
: 不是说乱用,是说某些地方要写某些地方不要写。
: 可我的印象是,只要指定编译器的优化策略就足够了。

avatar
x*u
78
这里讨论的是,这个提示是存在的么?
这个问题有实际意义,比如说写工具类的话,省略全部的cpp可以减少使用上的问题。

【在 t****t 的大作中提到】
: 除了满足ODR的需要以外, 所有的地方都不写或者所有的都写, 都是可以的. 编译器的
: 开关一般有更高的优先级. 但是: (1)所有的地方都不写或所有的地方都不写并非最佳
: 策略. (2)不管程序员用什么策略, inline关键字(隐含或显式)仍然对编译器有提示的
: 作用.

avatar
t*t
79
我说是存在的, 你说不存在. 有文档说明不存在么?

【在 x****u 的大作中提到】
: 这里讨论的是,这个提示是存在的么?
: 这个问题有实际意义,比如说写工具类的话,省略全部的cpp可以减少使用上的问题。

avatar
d*p
80
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,这才是本来的设计出发点。

avatar
x*u
81
你这话说的。。
现在所有的文档都是强调编译器可以忽略,不过从MS在ATL中的表现来看,在VC里面没
什么实际作用的可能性存在。

【在 t****t 的大作中提到】
: 我说是存在的, 你说不存在. 有文档说明不存在么?
avatar
x*u
82
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.

avatar
t*t
83
好吧, 说来说去没什么营养. 不然你去作个试验吧. 上次是我给的实际example, 这次
轮到你了.

【在 x****u 的大作中提到】
: 你这话说的。。
: 现在所有的文档都是强调编译器可以忽略,不过从MS在ATL中的表现来看,在VC里面没
: 什么实际作用的可能性存在。

avatar
x*u
84
这里讨论的是一个很实际的问题,inline关键字对优化是否产生影响。
你东拉西扯那么多话没一点新意,现在开始叫我举证了。

【在 t****t 的大作中提到】
: 好吧, 说来说去没什么营养. 不然你去作个试验吧. 上次是我给的实际example, 这次
: 轮到你了.

avatar
t*t
85
那你想要怎么解决呢, 说来说去你也没证据我也没证据. 这问题本来就没新意, 说出花
来也没新意.
本来我举证也问题不大, 但是上次是我举证的而且正确, 好歹我也应该有benefit of
the doubt吧. 所以轮到你了.

【在 x****u 的大作中提到】
: 这里讨论的是一个很实际的问题,inline关键字对优化是否产生影响。
: 你东拉西扯那么多话没一点新意,现在开始叫我举证了。

avatar
x*u
86
你真是很无聊。
关于VC,找到了MSDN的说法: inline仅在编译器认为对整体优化有益的情况下才执行,
如果希望尽可能的展开,有另一个关键字叫__forceinline。当然这个forceinline在无
法inline的时候还是被忽略。
所以说,完全不用担心class的函数全部隐含inline会影响效率。

【在 t****t 的大作中提到】
: 那你想要怎么解决呢, 说来说去你也没证据我也没证据. 这问题本来就没新意, 说出花
: 来也没新意.
: 本来我举证也问题不大, 但是上次是我举证的而且正确, 好歹我也应该有benefit of
: the doubt吧. 所以轮到你了.

avatar
t*t
87
这个回答和我们的问题不是一回事吧? 这并没有完全回答, inline关键字会不会对是否
inline产生影响. 这个只是说, 标了inline的函数不一定会被inline, 但是这一点所有
人都知道.
同样的一个函数, 在语法允许的情况下编译两次, 一次标inline, 另一次不标, 如果任
何情况下两次编译器运行的结果都一样, 这个叫做inline关键字对优化没影响. 我认为
that's not the case.

【在 x****u 的大作中提到】
: 你真是很无聊。
: 关于VC,找到了MSDN的说法: inline仅在编译器认为对整体优化有益的情况下才执行,
: 如果希望尽可能的展开,有另一个关键字叫__forceinline。当然这个forceinline在无
: 法inline的时候还是被忽略。
: 所以说,完全不用担心class的函数全部隐含inline会影响效率。

avatar
x*u
88
别的地方说了,不标inline的函数也可能被auto-inline。
加起来就是说,不管是不是inline,只要你不用别的内部关键字,编译器只会从全局角
度做决定。

【在 t****t 的大作中提到】
: 这个回答和我们的问题不是一回事吧? 这并没有完全回答, inline关键字会不会对是否
: inline产生影响. 这个只是说, 标了inline的函数不一定会被inline, 但是这一点所有
: 人都知道.
: 同样的一个函数, 在语法允许的情况下编译两次, 一次标inline, 另一次不标, 如果任
: 何情况下两次编译器运行的结果都一样, 这个叫做inline关键字对优化没影响. 我认为
: that's not the case.

avatar
t*t
89
这个我也知道, 但是仍然不能说明inline关键字对优化策略没影响是不是?

【在 x****u 的大作中提到】
: 别的地方说了,不标inline的函数也可能被auto-inline。
: 加起来就是说,不管是不是inline,只要你不用别的内部关键字,编译器只会从全局角
: 度做决定。

avatar
x*u
90
对于加这个关键字的函数,只有全局分析有必要时才展开;
不加这个关键字的函数,只有全局分析有必要时才展开。

【在 t****t 的大作中提到】
: 这个我也知道, 但是仍然不能说明inline关键字对优化策略没影响是不是?
avatar
t*t
91
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 的大作中提到】
: 对于加这个关键字的函数,只有全局分析有必要时才展开;
: 不加这个关键字的函数,只有全局分析有必要时才展开。

avatar
t*t
92
一个运动员, 每天饿了要吃饭.
一个正常人, 每天饿了要吃饭.
所以是不是运动员, 和饭量没关系.

【在 x****u 的大作中提到】
: 对于加这个关键字的函数,只有全局分析有必要时才展开;
: 不加这个关键字的函数,只有全局分析有必要时才展开。

avatar
n*t
93
不知道你在较什么劲.就算是hint和没有也是不一样的.
就算你用了较低的优化级别,你还是可能希望对某些函数inline.

【在 x****u 的大作中提到】
: 别的地方说了,不标inline的函数也可能被auto-inline。
: 加起来就是说,不管是不是inline,只要你不用别的内部关键字,编译器只会从全局角
: 度做决定。

avatar
x*u
94
回帖之前要看贴

【在 n******t 的大作中提到】
: 不知道你在较什么劲.就算是hint和没有也是不一样的.
: 就算你用了较低的优化级别,你还是可能希望对某些函数inline.

avatar
b*n
95
exaclty.
做大项目的肯定都知道cpp(definition)跟h file(declaration)的内容分开很重要。

【在 D*******a 的大作中提到】
: boost may be a different case due to its heavy template usage
avatar
b*n
96
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

avatar
b*n
97
如果有header guard的话,在同一个binary里不会。在不同的binary里就会有各自的实
现。link起来以后就出现多个binary copy了。如果用来global variable就更SB了。

【在 x****u 的大作中提到】
: 编译器没那么傻
avatar
b*n
98
inline跟definition放在header是两回事。
即使后者也可以不inline的。

【在 h*******u 的大作中提到】
: inline函数compile的时候扩展,最后编译的可执行文件体积庞大。
: 你这是没写过太大的项目吧

avatar
b*n
99
你搞错了。把实现放在头文件并不等于inline。要不为什么还要有inline这个keyword
,直接放头文件不就行了。

【在 t****t 的大作中提到】
: 这个不用担心, 所有的编译器都知道太长的不做inline.
: 问题在这里, 如果把实现放在头文件里, 如果不是模板, 就必须是inline. 有些可
: inline可不inline的, 就变成inline了, 这样必然会造成一些体积的增大.

avatar
t*t
100
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
: ,直接放头文件不就行了。

avatar
h*c
101
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

avatar
t*t
102
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

avatar
r*e
103
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.

avatar
t*t
104
你这都不知道我们在说什么, 还是先搞清楚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.

相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。