게터와 세터를 인라인으로 만드는 것이 좋은 습관입니까?

게터와 세터를 인라인으로 만드는 것이 좋은 습관입니까?

---

public:
     inline int GetValue() const {
          return m_nValue;
     }
     inline void SetValue(int nNewValue) {
          this -> m_nValue = nNewValue;
     }

에 C를 알아보기 ++ , 그들은 빠르게 실행 것이라고 말했다. 그래서 나는 게터와 세터에 사용하는 것이 좋을 것이라고 생각했습니다. 그러나 아마도 몇 가지 단점이 있습니까?

---

프로파일 러가 인라인하지 않으면 성능 문제가 발생한다고 구체적으로 말할 때까지는 인라인하지 않습니다.

C ++ 컴파일러는 매우 영리하며 이와 같은 간단한 함수를 거의 자동으로 인라인합니다. 그리고 일반적으로 그것은 당신보다 똑똑하고 인라인되어야 할 것인지 말 것인지를 결정하는 데 훨씬 더 나은 일을 할 것입니다.

인라인으로 할 것인지 말 것인지 생각하지 않고 솔루션에 집중할 것입니다. inline나중에 키워드를 추가 하는 것은 (인라인 BTW를 보장하지 않음) 매우 쉽게 할 수 있으며 프로파일 러를 사용하여 잠재적 인 위치를 쉽게 찾을 수 있습니다.

---

정의 내에 작성하면 inline 기본적으로 고려 됩니다 .

그들은 여러 컴파일 단위에서 허용 될 것이다이 방법은, (클래스 정의부터 자체는 일반적으로 여러 컴파일 단위로 표시) 하지 실제로 것이라고 할 수 인라인.

---

이는 공용 API의 나쁜 관행입니다. 이러한 함수를 변경하려면 모든 클라이언트를 다시 컴파일해야합니다.

일반적으로 게터와 세터가 있으면 추상화가 좋지 않습니다. 다른 클래스의 원시 데이터로 계속 이동하는 경우 클래스를 다시 정렬해야 할 가능성이 높습니다. 대신 클래스 내에서 데이터를 조작 할 방법을 고려하고 적절한 방법을 제공해야합니다.

---

부정적인 점 :

1. 컴파일러는 당신을 무시할 수 있습니다.

2. 이러한 기능을 변경하려면 모든 클라이언트를 다시 컴파일해야합니다.

3. 좋은 컴파일러는 적절할 때 인라인되지 않은 함수를 인라인합니다.

---

또한 프레임 당 수백만 개의 가져 오기 / 세트를 수행하지 않는 한, 인라인 여부에 관계없이 거의 관련이 없음을 추가하고 싶습니다. 솔직히 잠을 잃을 가치가 없습니다.

또한 선언 + 정의 앞에 '인라인'이라는 단어를 넣는다 고해서 컴파일러가 코드를 인라인한다는 의미는 아닙니다. 다양한 경험적 방법을 사용하여 의미가 있는지 여부를 알아 내는데, 이는 종종 속도 대 크기의 고전적인 균형입니다. 그러나 VC ++에는 무차별 대입 '__forceinline'키워드가 있습니다 (GCC에있는 것이 무엇인지 모르겠습니다). 나는 그것을 전혀 권장하지 않으며, 일단 다른 아키텍처로 포팅하면 틀릴 가능성이 높습니다.

모든 함수 정의를 구현 파일에 넣고 헤더에 대한 순수한 선언을 남겨 둡니다 (물론 템플릿 메타 프로그래밍 (STL / BOOST / etc)이 아니라면 거의 모든 것이 헤더에 있습니다;))

사람들이 인라인하기를 좋아하는 고전적인 장소 중 하나는 (적어도 내가 출신 인 비디오 게임에서) 수학 헤더에 있습니다. Cross / dot product, vector lengths, matrix clearing 등은 종종 머리글에 배치되는데, 이것은 불필요하다고 생각합니다. 9/10은 성능에 차이가 없으며, 큰 벡터 배열을 일부 행렬로 변환하는 것과 같이 엄격한 루프를 수행해야하는 경우에는 수학 인라인을 수동으로 수행하거나 코딩하는 것이 더 좋습니다. 플랫폼 별 어셈블러.

아, 그리고 또 다른 요점은, 코드보다 더 많은 데이터가 될 클래스가 정말로 필요하다고 생각한다면, 추상화의 OO 수하물을 가져 오지 않는 좋은 오래된 구조체를 사용하는 것을 고려하십시오. 그것이 바로 그 이유입니다. :)

죄송합니다. 그렇게 많이 진행할 생각은 없었지만 실제 사용 사례를 고려하는 것이 도움이되었다고 생각하고 현명한 컴파일러 설정에 너무 매달리지 마십시오 (저를 믿으십시오.

행운을 빕니다.

셰인

---

코드가 약간 더 오래 컴파일되고 캡슐화가 손실됩니다. 모든 것은 프로젝트의 규모와 성격에 달려 있습니다. 대부분의 경우 복잡한 논리가없는 경우 인라인으로 만드는 것이 좋습니다.

BTW, inline클래스 정의에서 직접 구현하는 경우 건너 뛸 수 있습니다.

---

헤더에 코드를 삽입하면 내부 클래스 작업이 노출됩니다. 클라이언트는 이것을보고 수업이 어떻게 작동하는지 가정 할 수 있습니다. 이로 인해 클라이언트 코드를 손상시키지 않고 나중에 클래스를 변경하기가 더 어려워 질 수 있습니다.

---

나는 당신이 그것을 귀찮게 할 필요가 없다고 말하고 싶습니다. 인라인에 대한 FAQ 섹션을 읽어보십시오 .

---

최소한 그러한 최적화를 위해 컴파일러를 신뢰하기 시작하십시오!
"하지만 항상 그런 것은 아니다"

---

귀하의 경우 인라인 키워드는 의미가 없습니다.

컴파일러는 키워드에 관계없이 가능하고 원하는 경우 함수를 인라인합니다.

키워드 인라인은 인라인이 아닌 연결에 영향을줍니다. 약간 혼란 스럽지만 읽어보십시오.

정의가 호출과 다른 컴파일 단위 (기본적으로 전 처리기 이후의 소스 파일)에있는 경우 전체 프로젝트 최적화 및 링크 타임 코드 생성이 활성화 된 경우에만 인라인이 가능합니다. 활성화하면 연결 시간이 크게 증가하지만 (실제로 링커의 모든 것을 다시 컴파일하므로) 성능이 향상 될 수 있습니다. GCC 및 VS에서 기본적으로 켜져 있는지 꺼져 있는지 확실하지 않습니다.

---

나는이 스레드의 다른 사람들이 가지고있는 것처럼 보이는이 관행에 대한 강한 혐오감을 가지고 있지 않다고 말해야합니다. 나는 인라이닝으로 인한 성능 향상이 가장 많이 사용되는 경우를 제외하고 모두 미미하다는 데 동의합니다. (그리고 그래, 내가 한 실제로 이러한 경우가 발생했습니다.) 나는 인라인 이런 종류의 할 경우, 나는 편의를 위해 그것을 할, 일반적으로 그냥이 같은 한 - 라이너. 대부분의 사용 사례에서 변경 한 경우 클라이언트 측에서 재 컴파일을 피해야하는 필요성은 그다지 강력하지 않습니다.

예, inline구현 배치에 의해 암시되는대로을 삭제할 수 있습니다 .

Also, I'm a little surprised at the vehemence against accessors. You can hardly sneeze at a class in any OO language without blowing a few down, and they are after all a valid technique to abstract implementation from interface, so it's a bit masochistic to claim them as bad OO practice. It is good advice not to write accessors indiscriminately, but I also advise you not to get carried away in the zeal to eradicate them.

Take that, purists. :-)

참고URL : https://stackoverflow.com/questions/3017264/is-it-good-practice-to-make-getters-and-setters-inline