ชุมชน C++ กำลังอภิปรายกันอย่างกระตือรือร้นเกี่ยวกับ CXXStateTree ซึ่งเป็นไลบรารี hierarchical state machine ใหม่สำหรับ C++20 โดยเฉพาะอย่างยิ่งเน้นไปที่การอ้างสิทธิ์เรื่องการจัดสรรหน่วยความจำและการเปรียบเทียบกับโซลูชันที่มีอยู่แล้ว แม้ว่าไลบรารีนี้จะสัญญาว่าจะมีฟีเจอร์ที่ทันสมัยและประโยชน์ด้านประสิทธิภาพ แต่ก็มีข้อกังวลทางเทคนิคหลายประการที่เกิดขึ้นจากฟีดแบ็กของนักพัฒนา
คุณสมบัติหลักของไลบรารี
- Fluent builder API พร้อม lambda-based DSL
- การเปลี่ยนสถานะแบบ event-based
- guards และ actions เสริมสำหรับการเปลี่ยนสถานะ (ไม่บังคับ)
- รองรับการทำงานร่วมกับ Google Test
- รองรับ code coverage ด้วย Codecov
- การใช้งานแบบ header-only
- ใช้สัญญาอนุญาต MPL2.0
ความขัดแย้งเรื่องการจัดสรรหน่วยความจำจุดประกายความกังวลในการพัฒนาระบบฝังตัว
การอ้างสิทธิ์ของไลบรารีว่าไม่มีการจัดสรร heap allocation เลยได้ดึงดูดการตรวจสอบอย่างละเอียดจากนักพัฒนาที่สังเกตเห็นว่าโค้ดใช้ standard containers เช่น lists และ unordered maps ผู้ดูแลโปรเจ็กต์ได้ชี้แจงว่าสิ่งนี้หมายถึงการไม่มีการจัดสรรหลังจากการสร้าง state tree แต่ความแตกต่างนี้ได้ทำให้เกิดคำถามสำคัญสำหรับนักพัฒนาระบบฝังตัว แอปพลิเคชันที่มีความสำคัญต่อความปลอดภัย โดยเฉพาะอย่างยิ่งที่ปฏิบัติตามแนวทาง MISRA มักต้องการการกำจัด heap allocation อย่างสมบูรณ์และการจัดสรรหน่วยความจำล่วงหน้าตอนเริ่มต้นระบบ สิ่งนี้ได้นำไปสู่การร้องขอฟีเจอร์สำหรับเวอร์ชันที่ไม่มีการจัดสรรจริงๆ ซึ่งจะเหมาะสำหรับอุปกรณ์ฝังตัวที่มีทรัพยากรจำกัด
MISRA: แนวทาง Motor Industry Software Reliability Association สำหรับความปลอดภัยของซอฟต์แวร์ยานยนต์
การแข่งขันกับไลบรารีที่มีชื่อเสียงทำให้เกิดคำถามเรื่องความแตกต่าง
สมาชิกชุมชนได้ตั้งคำถามว่า CXXStateTree แตกต่างจากทางเลือกที่มีชื่อเสียงแล้วเช่น Boost.Ext.SML (State Machine Language) อย่างไร การเปรียบเทียบนี้ได้จุดประกายการอภิปรายทางเทคนิคเกี่ยวกับแนวทางการใช้งาน โดยนักพัฒนาบางคนสังเกตเห็นความแตกต่างที่น่าสนใจในวิธีที่ไลบรารีเหล่านี้จัดการกับ string literals และการปรับแต่งให้เหมาะสมในเวลาคอมไพล์ ในขณะที่ SML ใช้ user-defined literals ที่ซับซ้อนเพื่อประมวลผล strings ในเวลาคอมไพล์ CXXStateTree ดูเหมือนจะใช้แนวทางที่ตรงไปตรงมากว่าซึ่งอาจมีลักษณะประสิทธิภาพที่แตกต่างกัน
การอภิปรายมาตรฐานโค้ดเกิดขึ้นเรื่องการใช้ Pragma Once
การอภิปรายที่ไม่คาดคิดแต่เต็มไปด้วยความหลงใหลได้เกิดขึ้นรอบการใช้ #pragma once ของไลบรารีสำหรับ include guards ชุมชนแบ่งออกเป็นสองฝ่ายระหว่างผู้ที่มองว่าเป็นมาตรฐานสมัยใหม่ที่รองรับโดยคอมไพเลอร์หลักทั้งหมด (GCC, Clang, MSVC) และผู้ที่ยึดมั่นในประเพณีที่ชอบ include guards ที่สอดคล้องกับมาตรฐาน การอภิปรายนี้สะท้อนความตึงเครียดที่กว้างขึ้นในชุมชน C++ ระหว่างความสะดวกในทางปฏิบัติและการปฏิบัติตามมาตรฐานอย่างเคร่งครัด โดยนักพัฒนาบางคนโต้แย้งว่าฟีเจอร์ที่ไม่ใช่มาตรฐานสร้างความเสี่ยงที่ไม่จำเป็น
ข้อกำหนดของคอมไพเลอร์
- ต้องการการรองรับคอมไพเลอร์ C++20
- GCC >= 10
- Clang >= 11
- MSVC >= 2019
- GoogleTest (ดาวน์โหลดอัตโนมัติผ่าน CMake )
การพัฒนาในอนาคตและการมีส่วนร่วมของชุมชน
ผู้ดูแลโปรเจ็กต์ได้แสดงการตอบสนองต่อฟีดแบ็กของชุมชน โดยสนับสนุนให้ผู้ใช้เปิด GitHub issues สำหรับข้อเสนอแนะต่างๆ รวมถึง vcpkg packaging, Python bindings และ compilation switches สำหรับ embedded targets แผนงานของไลบรารีแสดงแผนการที่ทะเยอทะยานรวมถึงการรองรับ coroutine และเอกสารฉบับสมบูรณ์ ซึ่งบ่งบอกถึงการพัฒนาที่กระตือรือร้นแม้จะมีความท้าทายในปัจจุบัน
การอภิปรายเหล่านี้เน้นย้ำถึงความซับซ้อนของการสร้างไลบรารี C++ ใหม่ในระบบนิเวศที่เป็นผู้ใหญ่ ซึ่งการอ้างสิทธิ์ด้านประสิทธิภาพ การปฏิบัติตามมาตรฐาน และความแตกต่างจากโซลูชันที่มีอยู่แล้ว ล้วนต้องเผชิญกับการตรวจสอบอย่างเข้มข้นจากชุมชน
อ้างอิง: CXXStateTree