E D R , A S I H C RSS

Internal Linkage

MoreEffectiveC++의 Item 26 'Limiting the number of objects of a class. λΌ λ³΄λ©΄ λ‹€μŒκ³Ό 같은 뢀뢄이 μžˆλ‹€.
{{|
The second subtlety has to do with the interaction of inlining and static objects inside functions. Look again at the code for the non-member version of thePrinter: Β€ Item M26, P17

Printer& thePrinter()
{
static Printer p;
return p;
}

Except for the first time through this function (when p must be constructed), this is a one-line function — it consists entirely of the statement "return p;". If ever there were a good candidate for inlining, this function would certainly seem to be the one. Yet it's not declared inline. Why not? Β€ Item M26, P18

Consider for a moment why you'd declare an object to be static. It's usually because you want only a single copy of that object, right? Now consider what inline means. Conceptually, it means compilers should replace each call to the function with a copy of the function body, but for non-member functions, it also means something else. It means the functions in question have internal linkage.

You don't ordinarily need to worry about such linguistic mumbo jumbo, but there is one thing you must remember: functions with internal linkage may be duplicated within a program (i.e., the object code for the program may contain more than one copy of each function with internal linkage), and this duplication includes static objects contained within the functions. The result? If you create an inline non-member function containing a local static object, you may end up with more than one copy of the static object in your program! So don't create inline non-member functions that contain local static data.(9)

9) In July 1996, the Β°ISO/ANSI standardization committee changed the default linkage of inline functions to external, so the problem I describe here has been eliminated, at least on paper. Your compilers may not yet be in accord with Β°the standard, however, so your best bet is still to shy away from inline functions with static data. Β€ Item M26, P61

|}}

C++ μ—μ„œ SingletonPattern 을 κ΅¬ν˜„ν• λ•Œ λ‹€μŒκ³Ό 같은 방식을 μ‚¬μš©ν•˜κ³ λŠ” ν•œλ‹€.

~cpp 
Object& theObject() // 이 ν•¨μˆ˜λŠ” 클래슀의 정적 λ©”μ†Œλ“œλ‚˜
                    // friend ν•¨μˆ˜μ—μ„œ ν˜ΈμΆœλœλ‹€.
{
 static Object obj;
 return obj;
}
처음 선언될 λ•ŒλΌ μ œμ™Έν•˜κ³ λŠ” μ € ν•¨μˆ˜λŠ”

~cpp 
Object& theObject()
{
 return obj;
}
와 같은 의λΈκ°€ λœλ‹€. 이것은 inline 으둜 선언할거리가 될것 같기도 ν•˜μ§€λ§Œ inline 으둜 μ„ μ–Έλ˜μ§€ μ•Šμ•˜λ‹€. μ™œμΌκΉŒ? (Except for the first time through this function (when p must be constructed), this is a one-line function — it consists entirely of the statement "return p;". If ever there were a good candidate for inlining, this function would certainly seem to be the one. Yet it's not declared inline. Why not? )

그것은 λ°”λ‘œ InternalLinkage λ•Œλ¬Έμ΄λ‹€. InternalLinkage λž€, 컴파일 λ‹¨μœ„(translation unit -> Object Code둜 생각해 보자) λ‚΄μ—μ„œ κ°μ²΄λ‚˜ ν•¨μˆ˜μ˜ 이름이 κ³΅μœ λ˜λŠ” 방식을 μΌμ»«λŠ”λ‹€. 즉, 객체의 μ΄λ¦„μ΄λ‚˜ ν•¨μˆ˜μ˜ 이름은 주어진 컴파일 λ‹¨μœ„ μ•ˆμ—μ„œλ§Œ 의λΈλΌ 가진닀.

예λΌλ“€μ–΄, ν•¨μˆ˜ fκ°€ InternalLinkageλΌ κ°€μ§€λ©΄, λͺ©μ μ½”λ“œ(Translation Unit) a.obj 에 λ“€μ–΄μžˆλŠ” ν•¨μˆ˜ f와 λͺ©μ μ½”λ“œ c.obj 에 λ“€μ–΄μžˆλŠ” ν•¨μˆ˜ fλŠ” λ™μΌν•œ μ½”λ“œμž„μ—λ„ λ³„κ°œμ˜ ν•¨μˆ˜λ‘œ μΈμ‹λ˜μ–΄ μ€‘λ³΅λœ μ½”λ“œκ°€ μƒμ„±λœλ‹€.
DeleteMe 이 말도 이해가 μ•ˆκ°‘λ‹ˆλ‹€. 주제둜 μ‹œμž‘ν•œ inline은 쀑볡 μ½”λ“œλΌ κ°μ•ˆν•˜κ³  μ„±λŠ₯을 μœ„ν•΄μ„œ μ“°λŠ” 것이 μ•„λ‹ˆ μ—ˆλ˜κ°€μš”? 무엇이 λ¬Έμ œμΈκ°€μš”? inline 이 μ•„λ‹Œ ν•¨μˆ˜λ“€μ€ ExternalLinkage둜 μ „μ œ λ˜μ—ˆλ‹€κ³  볼수 μžˆλŠ”λ°, 지적해야 할것은 inline의 operation에 ν•΄λ‹Ήν•˜λŠ” μ½”λ“œκ°€ μ•„λ‹ˆλΌ, static 같은 λ³€μˆ˜κ°€ 쀑볡을 예둜 λ“€μ–΄μ•Ό 할것을... --NeoCoin

ν•˜μ§€λ§Œ InternalLinkageκ°€ 초λ€ν•˜λŠ” λ¬Έμ œλŠ” 1996 ~cpp ISO/ANSI C++ ν‘œμ€ν™” μž‘μ—…μ—μ„œ μΈλΌμΈν•¨μˆ˜(InlineFunction)λΌ ExternalLinkage 둜 λ³€κ²½ν•΄μ„œ λ¬Έμ œκ°€ λ˜μ§€ μ•ŠλŠ”λ‹€.(졜근의 μ»΄νŒŒμΌλŸ¬λ“€μ€ μ§€μ›ν•œλ‹€.).

(->)즉.. static 이라해도 각각의 obj νŒŒμΌμ— μ½”λ“œκ°€ λ”°λ‘œ λ“€μ–΄κ°€.. 객체가 쀑볡 μƒμ„±λœλ‹€λŠ” 이야기인가..?

μ•”νŠΌ,결둠이 μ–΄λ–»κ²Œ λ˜λ‚˜μš”? singleton 을 κ΅¬ν˜„ν•˜λŠ” μš©λ„λ‘œ 자주 μ“°λŠ” static λ³€μˆ˜λΌ μ‚¬μš©ν•˜λŠ” (주둜 getInstanceλ₯˜) λ©”μ†Œλ“œμ—μ„œλŠ” inline 을 쓰지 말자 μΈκ°€μš”? --1002
- κ΅¬ν˜• μ»΄νŒŒμΌλŸ¬μ—μ„œλŠ” λ¬Έμ œκ°€ 될 수 μžˆμ§€λ§Œ 졜근의 μ»΄νŒŒμΌλŸ¬μ—λŠ” 문제될게 μ—†λ‹€κ³  λ§ν•˜λŠ”κ²ƒ κ°™μŠ΅λ‹ˆλ‹€. 제 생각이 잘λͺ»λœ 것이라면 κ±°μΉ¨μ—†λŠ” 지적을..^^; - μž„μΈνƒ
μ—¬κΈ°μ„œ λ§ν•˜λŠ” κ΅¬ν˜•μ΄λž€, 1996년에 λ³€κ²½λœ ν‘œμ€μ„ 지킀지 μ•Šμ€ 컴파일 것이닀. 99년에 이책을 처음 μ ‘ν• λ•Œ μ˜€λž˜λ˜μ—ˆλ‹€λŠ” 생각은 μ•ˆλ“€μ—ˆλŠ”λ°... MEC++ λŠ” 고전이 λ μˆ˜λŠ” μ—†λŠ”κ±ΈκΉŒ.. --NeoCoin

InternalLinkageλ¬Έμ œκ°€ λ“±μž₯ν•˜λŠ” λ‹€λ₯Έ μΌ€μ΄μŠ€

Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2021-02-07 05:23:28
Processing time 0.0276 sec