C++ coroutines เป็นที่รู้จักมาอย่างยาวนานในด้านความยืดหยุ่นและความซับซ้อน ซึ่งต้องการให้นักพัฒนาสร้าง task types และ execution frameworks ของตัวเอง อย่างไรก็ตาม ภูมิทัศน์นี้กำลังจะเปลี่ยนแปลงอย่างมีนัยสำคัญใน C++26 ซึ่งจะนำเสนอ default async runtime ผ่าน std::execution ที่นำมาซึ่งทั้งความตื่นเต้นและความขัดแย้งในชุมชน C++
คอมโพเนนต์ Default Runtime ที่จะมาใน C++26
มาตรฐาน C++26 ที่กำลังจะมาถึงจะรวมสามคอมโพเนนต์หลักที่สะท้อนฟังก์ชันการทำงานที่พบในระบบ async ของภาษาอื่นๆ ประการแรก default coroutine task type จะขจัดความจำเป็นที่นักพัฒนาต้องสร้าง Task implementations ของตัวเองตั้งแต่เริ่มต้น ประการที่สอง default executor จะจัดการการจัดตารางและการดำเนินการของ async operations ประการที่สาม ความสามารถในการ spawn tasks คล้ายกับ Tokio ใน Rust จะให้รูปแบบที่คุ้นเคยสำหรับการเขียนโปรแกรมแบบ concurrent
การเพิ่มเติมเหล่านี้แสดงถึงการเปลี่ยนแปลงที่สำคัญจากแนวทางดั้งเดิมของ C++ ที่มุ่งเน้นการให้ building blocks ระดับต่ำมากกว่าโซลูชันที่สมบูรณ์ เฟรมเวิร์ก std::execution มีเป้าหมายที่จะให้นักพัฒนามีระบบ async ที่พร้อมใช้งานในขณะที่ยังคงความยืดหยุ่นที่เป็นลักษณะเฉพาะของภาษา
คอมโพเนนต์ของ C++26 std::execution
| คอมโพเนนต์ | วัตถุประสงค์ | การเปรียบเทียบ |
|---|---|---|
| ประเภท task ของ coroutine แบบเริ่มต้น | ช่วยขจัดความจำเป็นในการสร้าง Task แบบกำหนดเอง | คล้ายกับประเภท Task ที่มีอยู่แล้วใน C |
| Executor แบบเริ่มต้น | จัดการการจัดตารางและการดำเนินการของ async operations | เปรียบได้กับ async runtimes ในภาษาอื่นๆ |
| ความสามารถในการสร้าง task | ช่วยให้สามารถสร้าง concurrent task ได้ | คล้ายกับฟังก์ชัน spawn ของ Tokio ใน Rust |
ชุมชนแบ่งแยกเรื่องปรัชญาการมาตรฐาน
การตัดสินใจที่จะรวม default async runtime ได้แบ่งแยกชุมชน C++ ตามแนวคิดปรัชญา ผู้สนับสนุนโต้แย้งว่าการมีทั้ง flexible coroutine specification สำหรับผู้ใช้ขั้นสูงและ default implementation สำหรับกรณีการใช้งานทั่วไปจะให้สิ่งที่ดีที่สุดจากทั้งสองโลก แนวทางนี้อาจลดอุปสรรคในการเข้าถึงการเขียนโปรแกรม async ใน C++ และลดการแยกส่วนที่มีอยู่ในปัจจุบันระหว่าง coroutine libraries ต่างๆ
นักวิจารณ์ชี้ไปที่แนวทางที่แตกต่างของ Rust เป็นเรื่องเตือนใจ Rust เลือกอย่างรอบคอบที่จะไม่รวม default async runtime ในไลบรารีมาตรฐาน ทำให้ระบบนิเวศสามารถพัฒนาทางเลือกอื่นๆ เช่น Embassy สำหรับระบบ embedded และป้องกันไม่ให้ API ถูกตรึงไว้ในการออกแบบที่อาจไม่เหมาะสมที่สุด
มันเป็นไปได้อย่างสมบูรณ์ที่ผู้คนจะค้นพบรูปแบบ async ใหม่ที่ทำงานได้ดีกว่า std::execution
ความกังวลมุ่งเน้นไปที่ว่าการทำให้แนวทางเฉพาะเป็นมาตรฐานเร็วเกินไปอาจขัดขวางนวัตกรรมในรูปแบบการเขียนโปรแกรม async ที่ยังไม่ได้ถูกค้นพบ
เส้นโค้งการเรียนรู้ยังคงสูงชัน
แม้จะมีการปรับปรุงที่กำลังจะมาถึง C++ coroutines ยังคงนำเสนอความท้าทายในการเรียนรู้อย่างมีนัยสำคัญ ระบบปัจจุบันต้องการความเข้าใจในแนวคิดที่เชื่อมโยงกันหลายอย่าง รวมถึง promise types, awaiters, awaitables และจุดปรับแต่งต่างๆ แหล่งข้อมูลการศึกษาเช่นซีรีส์ coroutine ที่ครอบคลุมของ Raymond Chen ได้กลายเป็นสิ่งที่จำเป็นต้องอ่าน แต่ความซับซ้อนยังคงน่ากลัวสำหรับนักพัฒนาหลายคน
ไวยากรณ์และศัพท์เทคนิครอบๆ C++ coroutines ต้องการการศึกษาอย่างรอบคอบ ด้วยแนวคิดที่ต้องการคำจำกัดความที่แม่นยำและตัวอย่างที่กว้างขวางเพื่อให้เข้าใจอย่างถูกต้อง ความซับซ้อนนี้เกิดจากแนวทางของภาษาที่ให้ความยืดหยุ่นสูงสุดผ่าน compiler transformations และ customization points มากกว่า abstractions ที่ง่ายกว่า
จุดปรับแต่งหลักใน C++ Coroutines
- promise_type: กำหนดพฤติกรรมของ coroutine สำหรับการเรียก การคืนค่า และการทำลาย
- initial_suspend: พฤติกรรมทันทีหลังจากที่ coroutine ถูกเรียก
- final_suspend: พฤติกรรมก่อนที่อายุการใช้งานของ coroutine จะสิ้นสุด
- await_transform: แปลงนิพจน์ใน co_await statements ให้เป็น awaitables
- awaiter objects: จัดการการหยุดชั่วคราวและการกลับมาทำงานต่อด้วยเมธอด await_suspend และ await_resume
การประยุกต์ใช้จริงแสดงให้เห็นความหวัง
การใช้งาน C++ coroutines ในโลกจริงแสดงให้เห็นคุณค่าของมันแม้จะมีเส้นโค้งการเรียนรู้ นักพัฒนารายงานการปรับปรุงที่สำคัญเมื่อแทนที่โค้ดเครือข่ายแบบ callback-based ด้วย coroutines โดยเฉพาะในสถานการณ์ที่เกี่ยวข้องกับการกระทำซ้ำๆ การจัดการข้อผิดพลาด และการจัดการอายุของข้อมูล ความสามารถในการเขียนโค้ดแบบ declarative แทนที่ state machines ที่ซับซ้อนดึงดูดใจโปรแกรมเมอร์หลายคนที่ต้องจัดการกับ network protocols และการจัดการข้อความ
การแทนที่ state machine แสดงถึงกรณีการใช้งานที่น่าสนใจอีกประการหนึ่ง ซึ่ง coroutines สามารถขจัดความจำเป็นในการใช้ state enums และ switch statements อย่างชัดเจนเพื่อให้มี control flow ที่เป็นธรรมชาติมากขึ้น สิ่งนี้พิสูจน์ให้เห็นคุณค่าโดยเฉพาะในการเขียนโปรแกรมเครือข่ายที่ protocols มักต้องการขั้นตอนการเจรจาหลายขั้นตอนก่อนที่จะเริ่มการถ่ายโอนข้อมูลจริง
การนำเสนอคอมโพเนนต์ async เริ่มต้นใน C++26 อาจเร่งการยอมรับโดยการลดภาระการดำเนินการเริ่มต้น แม้ว่าความซับซ้อนพื้นฐานของโมเดล coroutine จะยังคงเป็นปัจจัยในภูมิทัศน์การเขียนโปรแกรม async ของภาษา
อ้างอิง: A Mental Model for C++ Coroutine