สิ่งที่ชัดเจนที่ภาษา C ควรทำ

 (digitalmars.com)
2 คะแนน โดย GN⁺ 2025-01-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

  • จุดที่ภาษา C ควรปรับปรุงอย่างชัดเจน

    • มาตรฐาน C23: ภาษา C มีการปรับปรุงอย่างสม่ำเสมอและปัจจุบันมาถึง C23 แล้ว อย่างไรก็ตามยังคงมีปัญหาที่ไม่ได้รับการแก้ไขอยู่
    • ความพยายามของชุมชน Dlang: มีการฝังคอมไพเลอร์ C (ImportC) เข้าไว้ในคอมไพเลอร์ของภาษาโปรแกรม D เพื่อเปิดโอกาสในการแก้ปัญหาเหล่านี้

  • การประเมินนิพจน์ค่าคงที่

    • ปัญหา: C สามารถคำนวณนิพจน์ง่าย ๆ ได้ในช่วงคอมไพล์ แต่ไม่สามารถเรียกใช้ฟังก์ชันได้
    • ทางแก้ของ ImportC: ImportC อนุญาตให้เรียกใช้ฟังก์ชันในช่วงคอมไพล์ เพื่อก้าวข้ามข้อจำกัดนี้

  • การทดสอบหน่วยในช่วงคอมไพล์

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

  • การอ้างอิงประกาศล่วงหน้า

    • ข้อจำกัดของ C: C ไวต่อ ลำดับของการประกาศ และไม่อนุญาตให้อ้างอิงล่วงหน้า
    • ข้อดีของ ImportC: ImportC ไม่ยึดติดกับลำดับของการประกาศ และอนุญาตให้มีการประกาศแบบโกลบอลในลำดับใดก็ได้

  • การนำเข้าการประกาศ

    • ปัญหาของวิธีเดิม: มีความยุ่งยากจากการต้องเขียนไฟล์ .h สำหรับทุกโมดูลภายนอก
    • ทางแก้ของ ImportC: ImportC สามารถนำเข้าการประกาศได้โดยไม่ต้องใช้ไฟล์ .h จึงมีประสิทธิภาพกว่า

  • เอกสารอ้างอิง

    • เอกสาร ImportC: ให้ข้อมูลโดยละเอียดเกี่ยวกับ ImportC
    • เอกสารภาษา D: ให้ข้อมูลเพิ่มเติมเกี่ยวกับภาษา D

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-01-13
ความคิดเห็นใน Hacker News

  • ไฟล์เฮดเดอร์ของภาษา C ดีตรงที่แยกส่วนสาธารณะกับไม่สาธารณะ, อินเทอร์เฟซกับอิมพลีเมนต์ได้อย่างชัดเจน ทำให้ดูวิธีใช้ไลบรารีได้ง่ายผ่านไฟล์ .h

    • เอกสารถูกรวมไว้ที่ไฟล์ .h เป็นหลัก จึงดูต่างจากไฟล์ .c
    • จะใส่เอกสารไว้ในไฟล์ .c ก็ได้ แต่จะทำให้อ่านอินเทอร์เฟซได้ไม่สะดวก

  • มีความเห็นว่าภาษา C ควรรันฟังก์ชันได้ในช่วงคอมไพล์ แต่ฟังก์ชันที่ใช้เวลารันนานอาจเป็นปัญหาได้

    • ตัวอย่างคือฟังก์ชัน busybeaver

  • มีข้อสงสัยว่าจะแก้ปัญหาเรื่องการประเมิน constant expression, การทำ unit test ตอนคอมไพล์, forward reference ของ declaration และการ import declaration ได้อย่างไร

    • การประเมิน constant expression: ถ้าทำภายใน translation unit จะค่อนข้างง่าย แต่ต้องแลกกับการเขียนโค้ดซ้ำ
    • unit test ตอนคอมไพล์: ถ้าแสดงด้วยแมโครก็พอทำได้ แต่ถ้ามีข้อแรกเพิ่มเข้ามาจะทำได้ง่ายขึ้น
    • forward reference ของ declaration: จะทำให้คอมไพเลอร์ต้องพาสสองรอบ ซึ่งอาจกระทบประสิทธิภาพ
    • การ import declaration: อาจทำให้วิธีทำเทมเพลตใน C พังได้

  • การเขียน unit test สำหรับโค้ด C ทำได้ด้วย build system ที่ดีและ boilerplate เล็กน้อย

    • มีตัวอย่างเป็นโค้ดทดสอบของไลบรารี npy

  • ถ้าการประเมิน constant expression ซับซ้อน คอมไพเลอร์อาจช้าลงและอาจต้องมี VM

    • มีความเห็นว่าควรไปทางการ import โมดูลเป็นสัญลักษณ์มากกว่านิยามแบบ C++20

  • unit test ตอนคอมไพล์ดึงการควบคุมออกจากนักพัฒนา และบังคับให้ต้องผ่านขั้นตอนที่ไม่จำเป็นเพื่อให้งานเสร็จ

    • การทดสอบแบบ build failure เหมาะกับบิลด์สุดท้าย แต่ไม่เหมาะกับบิลด์ระหว่างทาง

  • มีการถกเถียงว่าการเขียนนิยามฟังก์ชันแบบ "บนลงล่าง" ดีกว่าหรือไม่

    • แม้แต่ภาษาอย่าง Python ก็ยังนิยมการนิยามแบบบนลงล่าง
    • มีคำถามว่าการนิยามแบบบนลงล่างเหมาะกับโค้ดบางประเภทมากกว่าหรือไม่

  • ฟีเจอร์ที่อยากให้เพิ่มในภาษา C

    • รองรับ slice type ที่เข้ารหัสพอยน์เตอร์และความยาวไว้ด้วยกัน
    • API ที่ reentrant และ thread-safe
    • ทำให้ฟีเจอร์แบบ defer ของ Go และ Zig เป็นมาตรฐาน
    • รองรับ Unicode และ UTF-8 แบบพกพาได้

  • จุดแข็งของ C คืออิมพลีเมนเตชันที่เรียบง่าย และการขยายขอบเขตครั้งใหญ่อาจไม่ใช่ความคิดที่ดี

    • อาจมีสเปกเวอร์ชัน "เล็ก" และเวอร์ชัน "ใหญ่" เหมือน Scheme

  • เหตุผลที่การนิยามฟังก์ชันจากบนลงล่างอาจดีกว่า

    • คล้ายกับวิธีที่เขียนโค้ดภายในฟังก์ชัน
    • ตำแหน่งของฟังก์ชันในโมดูลชัดเจน
    • มองเห็นการพึ่งพาแบบวนซ้ำได้ชัดเจน
    • การพึ่งพาแบบวนซ้ำทำให้โค้ดเบสซับซ้อนและทำความเข้าใจโมดูลได้ยาก
    • OCaml ไม่อนุญาตให้มีการพึ่งพาแบบวนซ้ำระหว่างฟังก์ชัน