ฟีเจอร์ทดลองของ C ++ สมัยใหม่เชื่อถือได้สำหรับโครงการระยะยาวหรือไม่?


87

ฉันมีโปรเจ็กต์ที่ใช้ C ++ 11/14 อยู่ในขณะนี้ แต่มันต้องการบางอย่างเช่นstd::filesystemซึ่งมีเฉพาะใน C ++ 17 เท่านั้นดังนั้นฉันจึงไม่มีโอกาสใช้มันในตอนนี้ อย่างไรก็ตามฉันเห็นว่ามีอยู่ในคอมไพเลอร์ปัจจุบันของฉันในชื่อstd::experimental::filesystemไฟล์. เป็นความคิดที่ดีไหมที่จะใช้ฟีเจอร์ทดลองโดยสมมติว่าในอนาคตฉันสามารถเพิ่มสิ่งต่างๆเช่น:

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

ข้อกังวลของฉันคือ:

1. รับประกันหรือไม่ว่าคอมไพเลอร์ที่เข้ากันได้ทั้งหมดมีคุณสมบัติการทดลองเหมือนกัน?

2. ฟีเจอร์ทดลองมีแนวโน้มที่จะเกิดการเปลี่ยนแปลงครั้งใหญ่ที่ทำให้ไม่น่าเชื่อถือหรือไม่?

อาจจะมีอะไรให้สงสัยอีก เหตุใดฉันจึงควรหรือไม่ควรใช้ ฉันงงงวยกับโครงการใหม่และไม่รู้ว่าจะตัดสินใจอะไร


25
คำว่าการทดลองไม่ตอบคำถามของคุณ?
101010

6
ส่วนใหญ่เป็นเรื่องของรสชาติ #idef CXX17แต่ฉันจะหลีกเลี่ยงเพื่อถ่วงรหัสด้วย IMHO วิธีพกพาคือใส่โค้ดที่เกี่ยวข้องกับระบบไฟล์ทั้งหมดในหน่วยคอมไพล์เดียว (อาจเป็นคลาส) ใช้ตลอดส่วนที่เหลือของโค้ดโค้ดด้วยมาตรฐาน C ++ 11/14 ปัจจุบัน บันทึกว่าเหตุใดคุณจึงเขียนแบบนั้นและในที่สุดก็พอร์ตไปที่ C ++ 17 ในภายหลังระหว่างขั้นตอนการบำรุงรักษาหากเหมาะสม (แสดงความคิดเห็นในคำถามเดิม)
Serge Ballesta

4
เป็นเพียง "การทดลอง" ในฐานะผู้สมัครเพื่อเข้าสู่มาตรฐาน ไม่ใช่การสะท้อนคุณภาพของรหัส
Galik

5
มีการเปลี่ยนแปลงเล็กน้อยระหว่างเวอร์ชัน "ทดลอง" และ C ++ 17 สุดท้ายโปรดดูเอกสาร P0492R1
Bo Persson

7
ในกรณีของfilesystemคุณมีความเสี่ยงในการใช้งานน้อยกว่าสิ่งอื่น ๆ ดังที่คุณทราบอยู่แล้วว่าได้รับมาตรฐานใน C ++ 17 และข้อกำหนด C ++ 17 ที่แน่นอนของมันนั้นเปิดเผยต่อสาธารณะ ดังนั้นสิ่งที่คุณต้องทำคือตรวจสอบให้แน่ใจว่าคุณใช้เฉพาะexperimental::filesystemคุณสมบัติที่อยู่ในข้อกำหนด C ++ 17 เท่านั้น และแน่นอนคุณต้องรู้ว่าทุกแพลตฟอร์มเป้าหมายของคุณสนับสนุนการอย่างใดอย่างหนึ่งหรือซีexperimental::filesystem ++ 17 std::filesystem
Howard Hinnant

คำตอบ:


79
  1. รับประกันหรือไม่ว่าคอมไพเลอร์ที่เข้ากันได้ทั้งหมดมีคุณสมบัติการทดลองเหมือนกัน?

ไม่คุณลักษณะทดลองเป็นทางเลือก

  1. ฟีเจอร์ทดลองมีแนวโน้มที่จะเกิดการเปลี่ยนแปลงครั้งใหญ่ที่ทำให้ไม่น่าเชื่อถือหรือไม่

ใช่คณะกรรมการ C ++ อาจตัดสินใจที่จะละทิ้งคุณลักษณะหรือในกระบวนการกำหนดมาตรฐานข้อบกพร่องอาจเกิดขึ้นซึ่งจะบังคับให้คุณลักษณะเปลี่ยนแปลง

โดยทั่วไปไม่ควรใช้คุณลักษณะทดลอง คุณลักษณะการทดลองคือสิ่งที่คำพูด (กล่าวคือการทดลอง)


2
อ้างอิงถึงประเด็นที่สองโปรดทราบว่าฉันกำลังพูดถึงคุณลักษณะที่ได้รับการยอมรับแล้ว แต่อาจแตกต่างออกไป
นักฟิสิกส์ควอนตัม

14
@TheQuantumPhysicist: "ยอมรับแล้ว" เป็นแนวคิดที่ยุ่งยาก ทุกสิ่งสามารถลบออกได้ตลอดเวลาโดยยอมรับการเปลี่ยนแปลงในภายหลังเพื่อลบออกและสิ่งนี้เกิดขึ้นกับทุกมาตรฐาน คุณอาจต้องการรอจนกว่า Draft International Standard อย่างน้อยที่สุดก่อนที่ชุดคุณลักษณะจะมีความน่าเชื่อถือพอสมควร
Kerrek SB

1
@KerrekSB: คุณไม่ได้หมายถึงFinal Draft International Standard หรือที่เรียกว่า FDIS เหรอ? การร่างเป็นกระบวนการที่ค่อนข้างถาวร
MSalters

1
@MSalters: ไม่ DIS น่าจะดีพอถ้าคุณรีบร้อน และเราอาจไม่มี FDIS ในครั้งนี้
Kerrek SB

4
@KerrekSB: ฉันเคยเป็น National Body ของเนเธอร์แลนด์รอบ C ++ 03;) เรามีเลขาธิการแห่งชาติของ SC22 ซึ่งรู้เกี่ยวกับขั้นตอน ISO และวิธีตอบกลับ FDIS แต่ไม่ใช่อะไร นอกเหนือจากตัวแทน WG14 Randy Marques ของเรา) ไม่มีผู้ได้รับมอบหมาย SC22 คนใดรู้อะไรเกี่ยวกับ C ++ และแรนดี้ก็แค่สร้างความสนุกสนานให้กับความจริงที่ว่า C ++ ต้องการหน้าเว็บเพิ่มเติมเพื่อกำหนด UB ทั้งหมดมากกว่า C ที่จำเป็นสำหรับพฤติกรรมที่กำหนด - ไม่ต้องการให้เขาตอบกลับ FDIS นั้น)
MSalters

50

มีคนจากผู้ชมถามคำถามระหว่างการพูดคุย "C ++ Standard Library Panel" ที่ CppCon 2016 ( YouTube ) เกี่ยวกับความเป็นexperimentalไปได้ที่ชื่อจะทำให้ผู้ใช้กลัวจากการใช้อะไรก็ได้ภายในเนมสเปซ:

พวกคุณคิดว่า [เนื้อหาของstd::experimentalเนมสเปซ] พร้อมหรือยังและนั่นเป็นข้อโต้แย้งที่สามารถทำได้ [นั่น] มันพร้อมสำหรับการผลิตอย่างมีประสิทธิภาพในอีก 3 ปีข้างหน้าและบางทีคุณอาจต้องเปลี่ยนรหัสในอีก 3 ปีต่อมาหรือเปล่า?

Michael Wong (ประธาน SG5 และ SG14 และบรรณาธิการของ Concurrency TS) ให้คำถามก่อน:

ฉันคิดว่าคณะกรรมการมีความเห็นเป็นเอกฉันท์ว่าพร้อมผลิตจริง อย่างที่บอกไปก่อนหน้านี้ส่วนใหญ่ 99% ของมันจะหล่นลงมาในอากาศเราต้องการให้แน่ใจว่าคุณจะไม่ใช้มัน คุณสามารถเข้าใจได้ว่าเหตุใดเราจึงต้องการใส่ฟีเจอร์ขนาดใหญ่ฟีเจอร์กลุ่มใหญ่ในบริบทดังกล่าวเพื่อที่จะไม่รบกวนส่วนที่เหลือของระบบไลบรารีทั้งหมด แต่ยังทำให้คุณใช้งานได้ง่ายขึ้นด้วย ตอนนี้คุณสามารถเปิด GCC ด้วยการตั้งค่าสถานะเฉพาะสำหรับแนวคิดซึ่งทำให้คุณแบ่งกลุ่มออกได้ง่ายขึ้น

Alisdair Meredith (อดีตประธาน LWG) จากนั้นติดตาม:

ฉันจะเข้ารับตำแหน่งตรงกันข้ามที่นี่ สิ่งหนึ่งที่เฮิร์บ [ซัตเทอร์] กล่าวในฐานะผู้จัดงาน WG21 ซึ่งเป็นกลุ่มมาตรฐานเมื่อเราออกเดินทางไปตามเส้นทางของ TSes คือเขาไม่คิดว่า TSes จะประสบความสำเร็จจนกว่าเราจะล้มเหลวในการนำบางสิ่งไปข้างหน้าเพราะมัน หมายความว่าเราไม่ได้รับการทดลองเพียงพอเราไม่มีความทะเยอทะยานเพียงพอในสิ่งที่เราใช้ TSes เราต้องการอย่างนั้นจริงๆexperimentalเพื่อเป็นการบอกใบ้ว่าใช่สิ่งเหล่านี้อาจเปลี่ยนแปลงได้เราไม่ผูกมัดกับสิ่งนั้นและเราสามารถทำสิ่งผิดพลาดได้ นี่คือการลดอุปสรรคของเราสำหรับสิ่งที่เราคิดว่ามีความทะเยอทะยานและเข้าถึงได้มากที่สุด [... ] ตอนนี้มาตรฐานดูเหมือนจะอยู่ในรอบการเผยแพร่สามปีเราควรมีความทะเยอทะยานมากขึ้นในการวางคุณลักษณะทดลองจริงๆ เข้าสู่ TS และบางทีการพัฒนาสิ่งต่างๆให้เร็วขึ้นในมาตรฐานหลักนั้นเอง แต่อีกครั้งนี่จะเป็นหัวข้อสนุก ๆ สำหรับเราที่จะพูดคุยกันในการประชุม [C ++ standard Committee] สองสามครั้งถัดไป

Stephan T. Lavavej (ผู้ดูแลการใช้งาน STL ของ Microsoft) ตอบกลับล่าสุด:

สิ่งสำคัญคือต้องสร้างความแตกต่างระหว่างความสามารถในการทดลองของอินเทอร์เฟซและการทดลองของการนำไปใช้งานเพราะเมื่อคุณพูดว่า "พร้อมใช้งานจริง" หมายความว่าอย่างไร โดยปกติแล้ว "การผลิตพร้อม" คุณจะนึกถึงสิ่งนั้นโดยพูดถึงการนำไปใช้งาน ค่อนข้างเป็นไปได้ที่การใช้งาน [of something in std::experimental] จะเป็น [... ] bulletproof อย่างแน่นอน [... ] บางอย่างเช่น [... ] <random>ส่วนหัวใน TR1 [มัน] ดีจริงๆใน TR1 และคุณอาจมีการใช้สัญลักษณ์แสดงหัวข้อย่อยอย่างแน่นอน แต่กลับกลายเป็นว่าอินเทอร์เฟซปั่นป่วน อย่างมีนัยสำคัญ [ก่อนการเปิดตัว] C ++ 11 และ [... ] ถ้าเรารู้ในตอนนี้ว่าเราทำอะไรอยู่การexperimentalส่งสัญญาณที่ดีกว่าให้กับผู้คนว่า "เฮ้บางทีคุณอาจไม่ต้องการ ใช้std::experimental::variate_generator เพราะฮ่ามันจะหายไปใน C ++ 11 "

ดังนั้นจึงดูเหมือนว่ามีความปรารถนาในหมู่นักพัฒนาห้องสมุดมาตรฐานและสมาชิกคณะกรรมการว่าในอนาคตอย่างน้อยเนื้อหาของstd::experimentalnamespace ควรจะเป็นอย่างแท้จริง "ทดลอง" ในธรรมชาติและมันไม่ควรจะได้รับอนุญาตให้ว่าสิ่งที่อยู่ในstd::experimentalน้ำพระทัย ทำให้เป็นมาตรฐาน C ++

และไม่เท่าที่ฉันเข้าใจมันขึ้นอยู่กับผู้จำหน่ายห้องสมุดมาตรฐานว่าพวกเขามีการใช้งานสำหรับคุณสมบัติต่างๆภายในstd::experimentalหรือไม่


47
10 ปีหลังจากที่ฉันอ่านชื่อครั้งแรกความจริงที่ว่าผู้ดูแลระบบ STL ของ Microsoft ชื่อ STL ยังคงทำให้ฉันหัวเราะเบา ๆ
Jörg W Mittag

19
@ JörgWMittagคุณควรพบกับผู้ดูแลคอมไพเลอร์ของพวกเขา Michael Sam Victor Collins
MM

28

"Experimental" เป็นคำที่เกินจริงเล็กน้อย filesystemห้องสมุดมีถิ่นกำเนิดใน Boost และผ่านไปไม่กี่ซ้ำมีก่อนที่จะถูกส่งไปยัง ISO

อย่างไรก็ตามมาตรฐาน ISO มีเจตนา อนุรักษ์นิยมมาก การเรียกมันว่าการทดลองหมายความว่า ISO ไม่ได้สัญญาอย่างชัดเจนว่าการตั้งชื่อจะคงที่ เป็นที่ชัดเจนอย่างยิ่งว่าคุณจะต้องระบุที่อยู่รหัสของคุณอีกครั้งในอนาคต แต่เมื่อรู้ ISO แล้วก็มีแนวโน้มว่าจะมีคำแนะนำอย่างไร

สำหรับความเข้ากันได้ระหว่างคอมไพเลอร์คาดว่าจะสมเหตุสมผล แต่จะมีบางกรณี (เช่นคิดว่าเส้นทางที่สัมพันธ์กับไดรฟ์ของ Windows เป็นต้น) และนั่นคือสาเหตุที่มาตรฐานในอนาคตอาจทำลายรหัสที่มีอยู่ ตามหลักการแล้วมันจะทำลายรหัสของคุณก็ต่อเมื่อคุณต้องพึ่งพากรณีมุมนั้น แต่นั่นไม่ใช่การรับประกัน


8

อาจจะมีอะไรให้สงสัยอีก

บางประเด็นที่ควรพิจารณา:

  • โครงการของคุณมีหลายแพลตฟอร์มแค่ไหน? หากมีคอมไพเลอร์เพียงตัวเดียวที่เกี่ยวข้องคุณสามารถตรวจสอบการนำไปใช้งานและบันทึกการติดตามเพื่อตัดสินใจได้ หรือถามพวกเขา!

  • Codebase ของคุณใหญ่แค่ไหน? ผลกระทบของการเปลี่ยนแปลงจะใหญ่แค่ไหน?

  • คุณลักษณะพื้นฐานของโครงการของคุณมีให้โดย API / ไลบรารี / คุณลักษณะอย่างไร

  • ทางเลือกอื่นคืออะไร?

    • ใช้คุณลักษณะทดลองจากนั้นปรับโค้ดเพื่อแก้ไขเมื่อ / ถ้าเป็นมาตรฐาน อาจทำได้ง่ายพอ ๆ กับการลบexperimental::หรือยากพอ ๆ กับการบังคับใช้วิธีแก้ปัญหา
    • เพิ่มเลเยอร์นามธรรม (ความคิดเห็นของ Serge Ballesta) หากคุณลักษณะทดลองเปลี่ยนแปลงการเขียนซ้ำของคุณจะถูกแยกออก สำหรับคุณสมบัติมาตรฐานมันอาจจะ overkill (std :: filesystem เป็นเลเยอร์ที่เป็นนามธรรมอยู่แล้ว ... )
    • ใช้ API / ไลบรารีอื่น คำถามเดียวกัน: วุฒิภาวะ? ความแข็งแรง? ความมั่นคง? พกพา? สะดวกในการใช้? คุณสมบัติ?
  • ในกรณีของ std :: filesystem (หรือ Network TS) จะมี boost :: filesystem (resp. boost :: asio) เป็นทางเลือกหรือทางเลือกในกรณีที่ระบบexperimentalล้มเหลวหรือหมดไป
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.