ภาษาโปรแกรม C (ปัญหาของภาษา C)

 (hut.mearie.org)
15 คะแนน โดย dalinaum 2021-04-05 | 7 ความคิดเห็น | แชร์ทาง WhatsApp

  • ปัญหาเรื่องหน่วยความจำ: ไม่ได้รับความช่วยเหลือจากเครื่องมืออย่าง GC, static analysis ฯลฯ

  • พฤติกรรมที่ไม่ถูกกำหนด: มักถูกใช้งานในสภาพแวดล้อมระดับล่างเป็นหลัก และมีความต้องการด้านการปรับแต่งประสิทธิภาพสูง ทำให้มีพฤติกรรมที่ไม่ถูกกำหนดเพิ่มขึ้นเพื่อการ optimize ไม่สามารถได้ทั้งประสิทธิภาพระดับล่างและความสามารถในการพกพาข้ามแพลตฟอร์มพร้อมกัน

  • ไม่เหมาะกับการเขียนโปรแกรมขนาดใหญ่: ขาดโมดูลและตัวจัดการแพ็กเกจ แม้แต่สิ่งที่ใช้กันอย่างแพร่หลายอย่าง #pragma once ก็ยังไม่มีมาตรฐาน

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

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

 
ffdd270 2021-04-05

ขอบคุณที่แชร์บทความดีๆ ครับ แต่มีจุดเล็กน้อยที่ผมสงสัยเลยขอแสดงความคิดเห็นไว้

  • อาจจะยังไม่มีในตอนที่คุณเขียนครั้งแรกเมื่อปี 2011 แต่ตอนนี้มี C package manager ออกมาหลายตัวแล้ว มีทั้ง Conan และ vcpkg ของ Microsoft ด้วย แม้จะยังมีข้อด้อยอยู่บ้างเมื่อเทียบกับ npm (vcpkg การจัดการเวอร์ชันยังติดป้ายเบต้าอยู่ และ conan ก็มีข้อมูลน้อยกว่า vcpkg) แต่ก็ดีขึ้นมากเมื่อเทียบกับยุคที่ยังไม่มีเลย
 
lifthrasiir 2021-04-09

ผมเป็นคนเขียนบทความเองครับ (ฮ่าๆ...) ตอนนี้เว็บไซต์ยังอยู่ในสถานะ soft release และกำลังทดลองเขียนบทความอยู่ จึงขอความกรุณาเข้าใจว่าเนื้อหาอาจมีการแก้ไขอย่างต่อเนื่องได้ ผมติดตามเองโดยตรงด้วย แต่ก็รับความคิดเห็นที่ส่งมาทางอีเมลเช่นกัน เผื่อไว้เป็นข้อมูลครับ

อย่างที่คุณบอก vcpkg ดูจะเป็น package manager ที่มีอนาคตมากที่สุดในตอนนี้ และ Conan เองก็จริงๆ แล้วเป็นโปรเจกต์ที่มีมาตั้งแต่ค่อนข้างนานแล้วด้วย (ไม่ได้ห่างจากช่วงที่เขียนต้นฉบับนัก) แต่ลักษณะเด่นที่สุดของโปรเจกต์เหล่านี้คือ ตัวมันเองไม่มี build system ในตัว และเป็น meta build system แทน (ถ้าคิดว่า CMake ซึ่งเป็นเป้าหมายหลักที่รองรับอยู่แล้วก็เป็น meta build system เช่นกัน อาจเรียกได้ว่าเป็น meta-meta build system ก็ได้...) เพราะฉะนั้นจึงค่อนข้างยากที่จะไปแก้ปัญหาที่เกิดจากตัว build system เองโดยตรง vcpkg ดูมีร่องรอยของการคิดเผื่อเรื่องนี้มากกว่า เช่น ถ้าในโปรเจกต์เดียวกันจำเป็นต้องใช้ dependency เดียวกันคนละเวอร์ชัน (ผ่านเส้นทาง dependency ที่ต่างกัน) ก็สามารถแยก enlistment ออกได้ แต่นี่ก็เป็นเพียงวิธีอ้อมข้อจำกัดของตัว build system เองเท่านั้น ยกตัวอย่างเช่น Rust กับ Cargo ในกรณีนี้สามารถ build ทั้งสองเวอร์ชันและอ้างอิงจาก crate เดียวกันได้โดยไม่มีปัญหา

นอกจากนี้ ตอนนี้ vcpkg ใน Visual Studio ก็ดูเหมือนว่ายังไม่มีแม้แต่การผสานเครื่องมือระดับ NuGet เลย (มีเพียงการผสานกับ MSBuild เท่านั้น...) และการผสานกับ package manager ของดิสทริบิวชัน Linux/BSD ก็ดูจะยังไม่ค่อยมีเท่าไร ปัญหานี้จริงๆ แล้วก็เป็นปัญหาใหญ่ที่สุดที่ package manager รายภาษากำลังเผชิญอยู่ในตอนนี้ด้วย โดยภาษารุ่นใหม่อย่าง Rust ก็กำลังแก้กันไปทีละส่วน แต่ถ้าเป็น package manager สำหรับ C/C++ แล้ว ก็ควรมุ่งไปที่การผสานเข้ากับระบบเดิมอย่างหลีกเลี่ยงไม่ได้ ทว่าส่วนนี้ยังคืบหน้าได้ช้ามาก ต้องแก้ปัญหาตรงนี้ได้ก่อน จึงจะพูดได้ว่าเครื่องมือสาย vcpkg กลายเป็นเครื่องมือที่ใช้งานได้อย่างแพร่หลายในการพัฒนา C/C++ อย่างแท้จริง ไม่เป็นเช่นนั้นนี่เองจึงเป็นเหตุผลหลักที่ผมประเมินระบบ package ไว้ไม่สูงนักในบทความ (การที่ single-file library แพร่หลายอย่างที่ยกไว้ในบทความ ก็เป็นหลักฐานทางอ้อมด้วยว่า ระบบแนว vcpkg ยังดึงดูดได้ไม่มากนัก)
 
ffdd270 2021-04-12

ขอบคุณสำหรับคำตอบที่ละเอียดมากครับ/ค่ะ คิดดูแล้วก็เพราะพื้นฐานมันคือ = m =.. ระบบบิลด์ เลยคงมีข้อจำกัดที่ตามให้ทันแบบ npm หรือแพ็กเกจแมเนเจอร์อื่น ๆ ไม่ได้สินะครับ/คะ ช่วงนี้ดูเหมือน vcpkg จะกังวลเรื่องเวอร์ชันอยู่มากเหมือนกัน แต่ก็คงไม่ใช่เรื่องง่ายที่จะฝ่าข้ามไปได้

ก็แอบคิดเหมือนกันว่าระบบโมดูลของ C++20 อาจจะเป็นคำตอบของปัญหานี้ได้ไหม... แต่ถ้าเป็นแบบนั้นขอบเขตก็จะเลยไปไกลกว่า C แล้ว (...) สุดท้ายเส้นทางของภาษา C ก็คงเหลือแต่ทางขรุขระเท่านั้นสินะครับ/คะ ถึงตอนนี้จะกำหนดมาตรฐาน C20 ขึ้นมาก็ตาม แต่อัตราการเปลี่ยนผ่านเวอร์ชันก็คงไม่สูงเหมือน C++ อยู่ดี..
 
functor 2021-04-06

ขอบคุณสำหรับความเห็นที่ดีครับ

นี่คือความเห็นส่วนตัวของผมครับ การที่มี C package manager อยู่หลายตัวถือเป็นสัญญาณที่ดี แต่ปัญหาคือ package manager เหล่านี้ดูเหมือนจะยังไม่ได้ถูกใช้งานอย่างแพร่หลาย หากจะพูดให้แม่นยำขึ้นก็คือ ด้วยความที่มรดกตกค้างของ C มีมหาศาลอยู่แล้ว จึงรู้สึกว่าเราอาจเดินมาไกลเกินกว่าจะแก้ปัญหาที่กล่าวถึงข้างต้นได้ง่าย ๆ แล้ว เพราะแบบนี้จึงน่าจะมีความพยายามย้ายไปใช้ภาษาใหม่อย่าง Rust กันมากขึ้นไม่ใช่หรือครับ
 
ffdd270 2021-04-06

พอได้ฟังแล้วกลับมาคิดอีกที ก็รู้สึกว่า package manager ข้างต้นเหมือนจะไม่ได้โฟกัสที่การยืดอายุของภาษา C แต่โฟกัสที่การยืดอายุของโปรแกรมเมอร์ที่จำเป็นต้องใช้ภาษา C มากกว่า

ตอนนี้ถึงเวลาที่ต้องย้ายไปบ้านใหม่ (C++, Rust...) แล้ว พอถึงเวลาที่ต้องใช้เฟอร์นิเจอร์อย่าง OpenGL หรือ Lua ที่เคยอยู่ในบ้านเก่า ถ้าไม่มี package manager ก็ต้องย้ายเองด้วยมือ (ทั้งลิงก์ ทั้ง make แล้วก็ปวดหัวเพราะเวอร์ชันของ DLL หรือ lib ไม่ตรงกัน... นั่งดู LNK error จนอยากกระโดดตึก...) แต่ตอนนี้มี package manager แล้ว ก็เลยย้ายได้เรียบร้อยเหมือนใช้บริการขนย้ายแบบแพ็กครบวงจร เพราะสิ่งที่สร้างไว้มีเยอะมาก ก็ต้องมีตอนที่บ้านใหม่เองก็ยังต้องใช้เหมือนกัน...

พอมองว่าตอนนี้ข้อได้เปรียบไม่ได้อยู่ที่ตัวภาษาเองแล้ว แต่อยู่ที่คุณค่าของประสบการณ์และของสะสมที่กองพอกมาจนถึงตอนนี้มากกว่า ก็ยิ่งรู้สึกได้จริง ๆ ว่านี่เป็นภาษาที่กำลังจะตายแล้ว (...
 
galadbran 2021-04-08

ในหลายแง่มุม ดูเหมือนว่า Rust จะมีภาพลักษณ์ของการเป็น next C/C++ ที่ชัดเจนที่สุด (และในบรรดาภาษาไม่กี่ตัวที่ถูกมองว่าเป็น next ก็ดูมีภาพลักษณ์ว่าเป็นตัวที่ซับซ้อนที่สุดเมื่อเทียบกันด้วย... 55)
 
dalinaum 2021-04-10

ดูเหมือนว่าไม่ใช่แค่ภาพลักษณ์เท่านั้น แต่ Rust เองก็ยากจริง ๆ เช่นกัน