C ++ 11에서 어떤 C ++ 숙어가 더 이상 사용되지 않습니까?

C ++ 11에서 어떤 C ++ 숙어가 더 이상 사용되지 않습니까?

---

새로운 표준에는 새로운 방식의 일이 있으며 많은 방법이 기존 방식보다 훌륭하지만 기존 방식은 여전히 ​​낫습니다. 새로운 표준은 이전 버전과의 호환성을 위해 공식적으로 많이 사용되지 않습니다. 따라서 남아있는 질문은 다음과 같습니다.

어떤 오래된 코딩 방식이 C ++ 11 스타일보다 확실히 열등하지 않으며, 대신 무엇을 할 수 있습니까?

이에 대한 답으로 "자동 변수 사용"과 같은 명백한 것을 건너 뛸 수 있습니다.

---

1. 최종 클래스 : C ++ 11은 final클래스 파생을 방지하기 위해 지정자를 제공합니다.
2. C ++ 11 람다는 명명 된 함수 객체 (functor) 클래스의 필요성을 크게 줄입니다.
3. Move Constructor : std::auto_ptrrvalue 참조에 대한 일류 지원으로 인해 더 이상 작업이 필요하지 않은 마법의 방법 .
4. Safe bool : 앞에서 언급했습니다. C ++ 11의 명시 적 연산자는이 일반적인 C ++ 03 관용구를 제거합니다.
5. 열 박음 : 많은 C ++ 11 STL 컨테이너는 shrink_to_fit()멤버 함수를 제공 하므로 임시로 교체 할 필요가 없습니다.
6. 임시 기본 클래스 : 일부 오래된 C ++ 라이브러리는 다소 복잡한 관용구를 사용합니다. 이동 의미론을 사용하면 더 이상 필요하지 않습니다.
7. Type Safe Enum 열거 형은 C ++ 11에서 매우 안전합니다.
8. 힙 할당 금지 : = delete구문은 특정 기능이 명시 적으로 거부되었다는 훨씬 직접적인 방법입니다. 이는 힙 할당 방지 (예 : =deletemember operator new), 복사, 할당 방지 등에 적용됩니다.
9. 템플릿 화 된 typedef : C ++ 11의 별칭 템플릿 은 간단한 템플릿 화 된 typedef의 필요성을 줄입니다. 그러나 복잡한 형식 생성기는 여전히 메타 함수가 필요합니다.
10. 피보나치와 같은 일부 수치 컴파일 타임 계산은 일반화 된 상수 표현식을 사용하여 쉽게 대체 할 수 있습니다.
11. result_of: 클래스 템플릿 사용 result_of은로 대체해야합니다 decltype. 가능할 때 result_of사용 한다고 생각 합니다 decltype.
12. 클래스 내 멤버 이니셜 라이저는 비 정적 멤버의 기본값을 기본값으로 사용하여 입력을 저장합니다.
13. 새로운 C ++ 11 코드에서는 NULL로 재정의해야 nullptr하지만 STL의 강의에서 코드 에 대해 왜 결정했는지 알아보십시오.
14. 식 템플릿 광신자들은 C ++ 11에서 후행 리턴 타입 함수 구문 을 갖게되어 기쁩니다 . 더 이상 30 줄 길이의 리턴 유형이 없습니다!

거기서 멈출 것 같아요!

---

어느 시점에서 우리 const는 단지 가치가 아니라 가치에 의해 반환되어야한다고 주장했다 .

const A foo();
^^^^^

이것은 C ++ 98 / 03에서 대부분 무해했으며 다음과 같은 몇 가지 버그를 발견했을 수도 있습니다.

foo() = a;

그러나 constC ++ 11에서는 이동 의미를 금지하기 때문에 by by를 사용하는 것이 금기입니다.

A a = foo();  // foo will copy into a instead of move into it

휴식을 취하고 코딩하십시오.

A foo();  // return by non-const value

---

포기 0하고 NULL찬성 하자마자 nullptr그렇게하십시오!

제네릭이 아닌 코드에서 사용 0하거나 NULL그렇게 큰 것은 아닙니다. 그러나 일반 코드에서 null 포인터 상수를 전달하기 시작하면 상황이 빠르게 바뀝니다. 당신이 통과하면 0A를 template<class T> func(T) Tint로서 추론 도착 int하지 널 포인터 상수로. 그리고 그 후에 널 포인터 상수로 다시 변환 할 수 없습니다. 이것은 우주가 단지 사용했을 경우 존재하지 않는 문제에 대한 혼란으로 이어진다 nullptr.

C ++ (11)는 더 이상 사용하지 않는 0및 NULL널 포인터 상수있다. 그러나 마치 마치 마치 코딩해야합니다.

---

안전한 bool 관용구 → explicit operator bool().

개인 복사 생성자 (boost :: noncopyable) → X(const X&) = delete

개인 소멸자와 가상 상속으로 최종 클래스 시뮬레이션 →class X final

---

C ++ 11에서 기본 알고리즘을 작성하지 않도록하는 것 중 하나는 표준 라이브러리에서 제공하는 알고리즘과 함께 람다를 사용할 수 있다는 것입니다.

나는 지금 그것들을 사용하고 있으며, 얼마나 많은 루프를 다시 쓰지 않고 count_if (), for_each () 또는 다른 알고리즘을 사용하여 원하는 일을 얼마나 자주 말하는지 믿을 수 없다.

완전한 C ++ 11 표준 라이브러리와 함께 C ++ 11 컴파일러를 사용하고 나면 표준 알고리즘을 사용하여 빌드하지 않는 것에 대한 더 이상 변명의 여지가 없습니다 . 람다는 그냥 죽입니다.

왜?

실제로 (알고리즘을 작성하는이 방법을 사용한 후) 실제로 의미를 알기 위해 암호를 해독해야하는 일부 루프보다 수행되는 것을 의미하는 간단한 단어로 작성된 것을 읽는 것이 훨씬 쉽습니다. 즉, 람다 인수를 자동으로 추론하면 구문을 원시 루프와 더 쉽게 비교할 수 있습니다.

기본적으로 루프의 구현 세부 사항을 숨기는 단어가 많을수록 표준 알고리즘으로 작성된 알고리즘을 읽는 것이 훨씬 쉽습니다.

나는 우리가 더 낮은 수준의 알고리즘을 만들었 기 때문에 더 높은 수준의 알고리즘 만 생각해야한다고 생각합니다.

---

swap자주 사용하지 않는 사용자 정의 버전을 구현해야합니다 . C ++ 03에서는 swap값 비싸고 던지는 것을 피하기 위해 효율적인 비 투척 이 필요한 경우가 종종 있으며 std::swap, 두 개의 사본을 사용하므로 swap종종 사용자 정의해야합니다. C ++에서는을 std::swap사용 move하므로 효율적이고 던지지 않는 이동 생성자 및 이동 할당 연산자를 구현하는 데 중점을 둡니다. 이것들에 대한 기본값은 종종 괜찮 기 때문에 C ++ 03보다 훨씬 덜 효과적입니다.

일반적으로 어떤 관용구가 경험을 통해 만들어지기 때문에 어떤 관용구가 사용 될지 예측하기가 어렵습니다. 필요한 경험이 아직 없기 때문에 내년에 "Effective C ++ 11"과 "C ++ 11 코딩 표준"이 3 년 안에있을 것으로 예상 할 수 있습니다.

---

I do not know the name for it, but C++03 code often used the following construct as a replacement for missing move assignment:

std::map<Big, Bigger> createBigMap(); // returns by value

void example ()
{
  std::map<Big, Bigger> map;

  // ... some code using map

  createBigMap().swap(map);  // cheap swap
}

This avoided any copying due to copy elision combined with the swap above.

---

When I noticed that a compiler using the C++11 standard no longer faults the following code:

std::vector<std::vector<int>> a;

for supposedly containing operator>>, I began to dance. In the earlier versions one would have to do

std::vector<std::vector<int> > a;

To make matters worse, if you ever had to debug this, you know how horrendous are the error messages that come out of this.

I, however, do not know if this was "obvious" to you.

---

Return by value is no longer a problem. With move semantics and/or return value optimization (compiler dependent) coding functions are more natural with no overhead or cost (most of the time).

참고URL : https://stackoverflow.com/questions/9299101/which-c-idioms-are-deprecated-in-c11