libcxx가 __forceinline 또는 GCC가 이미 숨겨진 인라인 함수와 동등한 이유는 무엇입니까?

Question

인라인 함수에 대한 libC++ 가시성 매크로가 __forceinline 또는 __attribute__((__always_inline__)) 인라인 함수와 관련된 속성의 일부로 사용되는 이유를 정확히 알고 싶습니다. 배경에 대한

참조 :

• The libcxx visibility design document
• The definition of INLINE_VISIBILITY

이 인라인 함수 어쨌든 __visibility__("hidden")로 표시하려는 경우, 왜 추가를 인라인 컴파일러를 강제로 필요하다 ?

나는 그것에 대해 조금 생각했습니다, 나는 몇 가지 가설을 가지고 있지만 아무도 나에게 완전히 만족 보인다 :

• 그것은 기호가 실수로 ABI의 일부가되지 않도록하는 것입니다. 라이브러리를 빌드하는 동안 컴파일러가 함수를 인라인하지 않기로 선택하면 잠재적으로 외부 기호가 될 수 있으므로 ABI의 일부가 될 수 있습니다. 그러나 hidden 속성으로 충분하지 않습니까? 마찬가지로, 라이브러리를 빌드 할 때 함수를 인라인 할 필요가 없습니까? 소비자는 신경 쓰지 않아야합니다.
• ODR 문제를 피하기 위해 컴파일러가 라이브러리 자체에서 함수를 인라인하지 않도록 선택하고 클라이언트가 생성 한 코드의 함수에서 인라인하지 않기로 선택한 경우 함수에 정의가 없음을 보장합니다. 두 개의 서로 다른 정의가되는 라이브러리. 그러나 visibility("hidden")을 사용하면 예상되는 (받아 들여지는) 결과가 아닌가요?
• 이것은 표준 라이브러리의 구현으로 libC++의 설계에 특정한 것입니다.

나는 언젠가 ABI를 표준화하기를 희망하는 C++ 라이브러리를 만들고 있으며 libC++를 가이드로 사용하고 있기 때문에이 질문을 받는다. 지금까지는 효과가 있었지만이 문제로 인해 머리가 긁혔습니다.

특히 우리는 MSVC가 __forceinline 속성을 기리는 것을 거부하여 경고를 받았다는 사용자의 신고를 받았습니다. 우리의 제안 된 해결책은 INLINE_VISIBILITY에 대한 우리의 아날로그 확장이 위의 첫 번째 설명을 가정 할 때, 라이브러리를 빌드 할 때 __forceinline (또는 GCC와 동등한 것)을 포함시키는 것입니다.

그러나 처음에는 인라인 함수가 __forceinline 또는 __attribute__((__always_inline__))이되어야한다는 추론을 완전히 이해하지 못했기 때문에이 솔루션을 채택하는 데는 다소 주저합니다.

libC++에서 이미 인라인 함수를 인라인해야 할 필요가 있다고 느끼는 이유에 대해 확실한 답을 줄 수 있습니까?

Answer 1

저는이 문제를 해결 한 가장 좋은 위치에있을 것입니다. 그리고 그 대답을 좋아하지 않을 수도 있습니다. :-)

libC++를 만들 때 유일한 대상은 macOS (OS X)입니다. 이것은 libC++가 오픈 소스가되기 이전의 방식이었습니다. 그리고 인라인으로 강제하는 주요 동기는 OS 릴리스로 밀려 나올 dylib의 ABI를 제어하는 ​​것이 었습니다. 강제 인라인 기능은 결코 dylib에 나타나지 않으므로 헤더 (OS 릴리스와는 다른 전달 시스템을 가짐)에 독점적으로 살고 있습니다.

간단히 말해서 불필요한 합병증 이었기 때문에이 결정의 일부로 "숨김"속성을 추가로 고려하지 않았습니다. 나는이 기능을 헤더에 넣고 dylib에 넣지 않기를 바랐다. 그래서 첫 번째 총알은 내가 옳다고 믿습니다.

libC++가 원래의 범위를 넘어서서 매우 기쁩니다. 최선을 다해 노력하겠습니다. 나는 당신의 목표에 도움이 될 수있는 추가 정보를 제공하게되어 기쁩니다.