최신 C ++의 실험적 기능은 장기 프로젝트에서 신뢰할 수 있습니까?

87

현재 C ++ 11 / 14를 사용하는 프로젝트가 있지만 std::filesystemC ++ 17에서만 사용할 수 있는와 같은 것이 필요 하므로 현재 사용할 기회가 없습니다. 그러나 현재 컴파일러에서 std::experimental::filesystem. 미래에 다음과 같은 것을 추가 할 수 있다고 가정하고 실험적 기능을 사용하는 것이 좋은 생각입니까?

#ifdef CXX17 //if this is C++17
std::filesystem::something ...;
#else
std::experimental::filesystem::something ...;
#endif

내 관심사는 다음과 같습니다.

1. 모든 호환 컴파일러가 동일한 실험 기능을 가지고 있다는 것이 보장됩니까?

2. 실험적 기능이 크게 변경되어 신뢰할 수없는 기능이 있습니까?

궁금한 점이 더있을 수 있습니다. 왜 사용하거나 사용하지 말아야합니까? 나는 새로운 프로젝트에 의아해하고 무엇을 결정해야할지 모르겠습니다.

c++  c++11  portability  c++17  c++-standard-library 
— 양자 물리학 자
소스
25
실험 이라는 단어가 당신의 질문에 답 하지 않습니까?
— 101010
6
주로 맛의 문제이지만 코드를 #idef CXX17. IMHO, 이식 가능한 방법은 모든 파일 시스템 관련 코드를 하나의 단일 컴파일 단위 (클래스 일 수 있음)에 넣고 코드의 나머지 부분에서 사용하고 현재 C ++ 11 / 14 표준으로 코딩하는 것입니다. 왜 그렇게 작성했는지 문서화하고 나중에 유지 관리 단계에서 나중에 C ++ 17로 포팅하십시오. (원래의 질문에 주석)
— 서지 Ballesta
4
표준에 들어가는 것은 후보로서 단지 "실험적"이었습니다. 코드의 품질을 반영하지 않습니다.
— Galik
5
"실험용"버전과 최종 C ++ 17 버전 간에는 상당한 변경이있었습니다. 문서 P0492R1
— Bo Persson
7
의 경우 filesystem당신이 이미 C ++ 17에서 표준화됩니다 것을 알고, 무엇보다 그것을 사용하여 훨씬 덜 위험을 초래하고, 정확한 C ++ 17 사양은 공개적으로 사용할 수 있습니다. 따라서 experimental::filesystemC ++ 17 사양에 있는 기능 만 사용하는지 확인하기 만하면됩니다. 물론 모든 대상 플랫폼이 experimental::filesystem또는 C ++ 17 중 하나를 지원한다는 사실을 알아야합니다 std::filesystem.
— Howard Hinnant 2017-04-10

답변:

79
  1. 모든 호환 컴파일러가 동일한 실험 기능을 가지고 있다는 것이 보장됩니까?

아니요, 실험적 기능은 선택 사항입니다.

  1. 실험적 기능이 큰 변화를 일으키기 쉬운가요?

예, C ++위원회는 기능을 포기하기로 결정하거나 표준화 과정에서 기능을 변경해야하는 결함이 발생할 수 있습니다.

일반적으로 실험적 기능에 의존하는 것은 좋은 생각이 아닙니다. 실험적 기능은 단어가 말하는 그대로입니다 (즉, 실험하기 위해).

— 101010
소스
2
두 번째 요점을 참조하면 이미 수용되었지만 다를 수 있는 기능에 대해 이야기하고 있습니다 .
— 양자 물리학 자
14
@TheQuantumPhysicist : "이미 승인 됨"은 까다로운 개념입니다. 나중에 변경 사항을 수락하여 언제든지 제거 할 수 있으며 이는 모든 표준에 적용되었습니다. 기능 세트가 합리적으로 신뢰할 수 있기 전에 최소한 국제 표준 초안이 나올 때까지 기다리는 것이 좋습니다.
— Kerrek SB
1
@KerrekSB : FDIS로 알려진 최종 초안 국제 표준 을 의미하지 마십시오 . ? 제도는 매우 영구적 인 프로세스입니다.
— MSalters
1
@MSalters : 아니요, 급한 경우 DIS로 충분할 것입니다. 어쨌든 이번에는 FDIS가 없을 수도 있습니다.
— Kerrek SB
4
@KerrekSB : 저는 C ++ 03을 중심으로 네덜란드의 국가기구였습니다.). 우리는 ISO 절차와 FDIS에 응답하는 방법에 대해 알고 있지만 무엇을 알지 못하는 SC22 국가 비서가있었습니다. WG14 대표 Randy Marques 외에는 SC22 대표 중 누구도 C ++에 대해 아는 사람이 없었습니다. 그리고 랜디 그냥 C ++은 C는 정의 된 동작을 위해 필요한 것보다 모든 UB를 정의하기 위해 더 많은 페이지를해야한다는 사실의 재미를 만들고 있었다 - 그 회신 싶지 않을 것이다 FDIS 그)
— MSalters
50

청중 중 누군가가 CppCon 2016 ( YouTube ) 의 "C ++ 표준 라이브러리 패널"강연에서 이름 experimental이 네임 스페이스 내에서 어떤 것을 사용하지 못하도록 사용자를 놀라게 할 수 있는지에 대해 질문했습니다 .

여러분은 [ std::experimental네임 스페이스 의 내용 ] 생산 준비가되었다고 생각하십니까? 그리고 그것이 만들어 질 수있는 논쟁이고, [그] 그것은 다음 3 년 동안 효과적으로 생산 준비가되어 있고, 아마도 3 년 후에 코드를 변경해야 할 것입니까?

Michael Wong (SG5 및 SG14의 회장이자 Concurrency TS의 편집자)이 먼저 질문을 던졌습니다.

위원회 내에서 실질적으로 생산 준비가되었다는 강한 합의가 있다고 생각합니다. 이전에 말했듯이 대부분의 경우 99 %가 에어 드롭됩니다. 사용하는 데 방해가되지 않도록합니다. 전체 라이브러리 시스템을 방해하지 않고 더 쉽게 사용할 수 있도록 이러한 컨텍스트에 큰 기능, 큰 기능 그룹을 배치하려는 이유를 이해할 수 있습니다. 이제 개념에 대한 특정 플래그를 사용하여 GCC를 켤 수 있습니다. 실제로 세그먼트를 더 쉽게 분할 할 수 있습니다.

Alisdair Meredith (전 LWG 의장)는 다음과 같이 후속 조치를 취했습니다.

여기서는 반대 입장을 취하겠습니다. Herb [Sutter]가 표준 그룹 인 WG21의 컨 비너로 말한 것 중 하나는 TSes의 길을 시작했을 때 TSes가 성공할 것이라고 생각하지 않았습니다. 우리가 충분히 실험적이지 않고 TS를 사용하는 것에 대해 충분히 야심적이지 않다는 것을 의미합니다. 우리는 정말로 그것을 원합니다experimental예, 이러한 것들은 변경 될 수 있으며, 우리는 그것에 구속력이 없으며, 일이 잘못 될 수 있다는 힌트가됩니다. 이것은 우리가 할 수있는 한 야심 차고 도달한다고 생각하는 것들에 대한 우리의 장벽을 낮추는 것입니다. [...] 이제 표준은 3 년의 릴리스주기에있는 것 같습니다. 우리는 실제로 실험적인 기능을 넣는 데 훨씬 더 야심을 가져야합니다. TS로 들어가고 아마도 주요 표준 자체로 더 빠르게 발전 할 수 있습니다. 그러나 이것은 우리가 다음 몇 번의 [C ++ 표준위원회] 회의에서 논의 할 재미있는 주제가 될 것입니다.

Stephan T. Lavavej (Microsoft의 STL 구현 관리자)가 마지막으로 응답했습니다.

인터페이스의 실험 성과 구현의 실험 성을 구분하는 것이 중요합니다. "생산 준비 완료"라는 말은 무엇을 의미합니까? 일반적으로 "프로덕션 준비"라고하면 구현에 대해 이야기한다고 생각할 것입니다. [무언가의 std::experimental] 구현 이 절대적으로 [...] 방탄이 될 수 있습니다. [...] [...] <random>TR1 의 헤더 와 같은 것 , [그것은] TR1에서 정말, 정말 좋았습니다. 그리고 당신은 그것의 절대적인 방탄 구현을 가질 수 있었지만, 인터페이스가 흔들렸다는 것이 밝혀졌습니다. 실질적으로 [출시 전] C ++ 11 및 [...] 우리가 지금 무엇을하는지 알고 experimental있었다면 사람들에게 "이봐 요, 아마도 당신은 사용하다std::experimental::variate_generator 왜냐하면, 하하, 그것은 C ++ 11에서 사라질 것입니다. "

따라서 표준 라이브러리 개발자와위원회 위원들 사이에는 적어도 미래에는 std::experimental네임 스페이스 의 내용이 본질적으로 진정으로 "실험적"이어야하며 std::experimental의지에 있는 무언가를 당연하게 여겨서는 안된다는 소망이 있는 것 같습니다. C ++ 표준으로 만듭니다.

그리고 내가 이해하는 한, .NET 내부의 다양한 기능에 대한 구현을 제공하는지 여부는 표준 라이브러리 공급 업체에 달려 있습니다 std::experimental.

— 조셉 톰슨
소스
47
이름을 처음 읽은 지 10 년이 지났지 만 Microsoft의 STL 관리자가 STL이라는 사실은 여전히 ​​저를 웃게 만듭니다.
— Jörg W Mittag
19
@ JörgWMittag 컴파일러 관리자 인 Michael Sam Victor Collins를 만나야합니다
— MM
28

"Experimental"은 약간 과장된 용어입니다. filesystem라이브러리는 부스트에서 유래와 ISO에 제출되기 전에, 거기에 몇 가지 반복을 통해 갔다.

그러나 ISO 표준은 의도적으로 매우 보수적입니다. 실험적이라고 부르는 것은 ISO가 이름이 안정적이라는 것을 명시 적으로 약속하지 않는다는 것을 의미합니다. 앞으로 언젠가 코드 주소를 다시 지정해야 할 것임이 분명합니다. 그러나 ISO를 알면 방법에 대한 지침이있을 것입니다.

컴파일러 간의 호환성에 관해서는 합리적이라고 기대하십시오. 그러나 코너 케이스 (예 : Windows 드라이브 상대 경로를 생각해보십시오)가있을 것이며, 이것이 바로 미래 표준이 기존 코드를 손상시킬 수있는 이유입니다. 이상적으로는 해당 코너 케이스에 의존하는 경우에만 코드가 손상되지만 보장되지는 않습니다.

— MSalters
소스
8

궁금한 점이 더있을 수 있습니다.

고려해야 할 몇 가지 사항 :

  • 귀하의 프로젝트는 얼마나 다중 플랫폼입니까? 컴파일러가 하나만 관련된 경우 구현 및 추적 기록을 검사하여 결정할 수 있습니다. 아니면 그들에게 물어보세요!

  • 코드베이스는 얼마나 큽니까? 변경의 영향은 얼마나됩니까?

  • API / 라이브러리 / 기능에서 제공하는 기능이 프로젝트에 얼마나 기본적인가요?

  • 대안은 무엇입니까?

    • 실험적 기능을 사용한 다음 표준화 될 때 코드를 수정에 적용합니다. 삭제하는 것만 큼 쉬울 수도 있고 experimental::해결 방법을 강제하는 것만 큼 어려울 수도 있습니다 .
    • 추상화 레이어를 추가합니다 (Serge Ballesta 주석). 실험 기능이 변경되면 재 작성이 격리됩니다. 표준 기능의 경우 과잉 일 수 있습니다 (std :: filesystem은 이미 추상화 계층입니다 ...).
    • 다른 API / 라이브러리를 사용하십시오. 같은 질문 : 성숙? 견고성? 안정? 휴대 성? 사용의 용이성? 풍모?
  • std :: filesystem (또는 네트워킹 TS)의 경우 대체 또는 대체로 boost :: filesystem (각각 boost :: asio)이 experimental있습니다.
— 파블로 H
소스
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.