เหตุใด C ++ ไม่สามารถใช้แนวทางของ D ในการนำแนวคิดไปใช้


19

อย่างที่พวกคุณหลายคนรู้แนวคิดแนวทางของ C ++ สำหรับการ จำกัด ประเภทที่เป็นไปได้สำหรับอาร์กิวเมนต์เท็มเพลตล้มเหลวที่จะรวมอยู่ใน C ++ 11

ฉันเรียนรู้ว่าภาษาการเขียนโปรแกรม D 2.0 มีคุณสมบัติคล้ายกันสำหรับการเขียนโปรแกรมทั่วไป การแก้ปัญหาดูเหมือนว่าฉันจะค่อนข้างหรูหราและเรียบง่าย

ดังนั้นคำถามของฉันทำไม C ++ ไม่สามารถใช้วิธีการที่คล้ายกัน

  • เป้าหมายของแนวคิด C ++ อาจใหญ่กว่าการนำไปใช้ของ D
  • หรือมรดกของ C ++ ป้องกันไม่ให้ใช้แนวทางดังกล่าว
  • หรืออื่น ๆ

ขอบคุณสำหรับคำตอบของคุณ

ps หากต้องการดูตัวอย่างพลังการเขียนโปรแกรมทั่วไปของ D โปรดอ้างอิงถึงสิ่งนี้: /programming/7300298/metaprogramming-in-c-and-in-d/7303534#7303534


2
คำถามนี้ควรถูกย้ายไปยังโปรแกรมเมอร์ (ฉันลงคะแนนสำหรับเรื่องนั้น แต่ 3 คะแนนสำหรับ "ไม่สร้างสรรค์")
iammilind

3
ฉันคิดว่าคำถามอาจไม่ได้ถูกเขียนอย่างสร้างสรรค์ แต่มีคุณค่ากับมัน ฉันจะรักใครสักคนที่อธิบายว่า D จัดการแนวคิดอย่างไรและสามารถเปรียบเทียบกับแนวทางหลักสองวิธีที่คณะกรรมการ C ++ ใช้กับแนวคิดก่อนที่พวกเขาจะตัดสินใจเลื่อนคุณลักษณะนี้ไปพร้อมกัน ... ถ้านี่จะต้องปิดก็ควรที่ อย่างน้อยที่สุดก็ย้ายไปโปรแกรมเมอร์
David Rodríguez - dribeas

2
@David: ฉันโหวตให้เปิดใหม่อีกครั้ง (และอาจจะสามารถย้ายไปยังไซต์โปรแกรมเมอร์)
Nawaz

1
เห็นด้วยกับเดวิด ฉันไม่เห็นเหตุผลใดที่จะพูดว่า "ไม่สร้างสรรค์" ก่อนใครก็สามารถลองสร้างบางสิ่งได้ ด้วย 0 คำตอบ "ความสร้างสรรค์" คือ 0/0 ดังนั้นจึงไม่ทราบแน่ชัด
Emilio Garavaglia

1
@ jj1: คุณช่วยอธิบายสั้น ๆ เกี่ยวกับแนวทางของ D สำหรับพวกเราที่ไม่เข้าใจภาษาได้ไหม?
David Rodríguez - dribeas

คำตอบ:


9

มาตรฐานของ C ++ เป็นเอกสารเชิงบรรทัดฐานซึ่งกำหนดกฎที่จะยังคงอยู่ (ส่วนใหญ่ไม่ได้รับผลกระทบ) ในเอกสารในอนาคต ดังนั้นคณะกรรมการจึงใช้ความระมัดระวังอย่างมากในการปรับปรุงข้อมูล

การเพิ่มเติมไปยังไลบรารีมาตรฐานนั้นค่อนข้างง่าย มีห้องสมุดหลายแห่งที่อยู่ใน Boost เป็นเวลานาน: ได้รับการพิสูจน์แล้วว่าใช้งานได้จริง

การเพิ่มเติมไปยังแนวคิดหลักในภาษานั้นยากกว่าการทดลองเพราะมันต้องมีการดัดแปลงคอมไพเลอร์ก่อน มีการระบุคุณลักษณะ C ++ 03 (การส่งออกเทมเพลต) โดยไม่สนับสนุนคอมไพเลอร์ ... ผลลัพธ์นั้นน่ากลัว ผู้ดำเนินการของส่วนต่อท้ายคอมไพเลอร์ EDG รายงานว่ามันเป็นงานที่ยิ่งใหญ่ (หลายคนหลายปี) เพื่อผลประโยชน์ที่น้อยมาก ไม่มีคอมไพเลอร์อื่น ๆ ที่พยายามจะใช้มัน มันไม่ใช่สถานการณ์ที่สะดวกสบาย

คุณสมบัติเหมือนconstexprหรือstatic_assertง่าย (และเลียนแบบแล้วโดยห้องสมุด) แลมบ์ดาค่อนข้างเข้าใจและนำไปใช้ในภาษาอื่นได้หลากหลายมีการวิจัยอย่างกว้างขวางอยู่แล้วดังนั้นจึงเป็นเรื่องของไวยากรณ์เป็นหลัก

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

ทำไมไม่ติดตาม D ไม่มีการบอกว่าจะไม่เป็น คณะกรรมการได้สนับสนุนให้ผู้คนคิดใหม่ตั้งแต่เริ่มต้นโดยไม่มีกำหนดเวลาและลองใช้มือของพวกเขารวมพวกเขาในคอมไพเลอร์เพื่อดูว่าพวกเขามีปฏิสัมพันธ์กับคุณสมบัติอื่น ๆ ในภาษาอย่างไร มีคำถามของการแยกแนวคิดและแผนที่แนวคิด: โดยเฉพาะพวกเขาควรรวมเป็นหนึ่งหรือไม่

FYI: ปัจจุบันมีสาขาของ Clang ที่อุทิศให้กับการทดลองนี้นำโดย Larisse Voufo จากมหาวิทยาลัยอินดีแอนา


ความคิดเห็นเล็กน้อย: คำหลักการส่งออกเป็นจริงคุณลักษณะ c ++ 98 (มาตรฐานดั้งเดิม) คอลเลคชั่น 2003 ส่งถึงคุณลักษณะของไลบรารีเป็นหลัก
ex0du5

@ ex0du5: ถูกต้อง '03 เป็นการแก้ไขมาตรฐาน C ++ 98 เล็กน้อยซึ่งการแก้ไขส่วนใหญ่เกี่ยวข้อง
Matthieu M.

3

สำหรับมาตรฐาน 2011 แนวคิดของ C ++ เป็นสิ่งที่กำลังดำเนินการอยู่และท้ายที่สุดพวกเขาก็หลุดออกจากมาตรฐานนั้นเพราะพวกเขาไม่ได้ "อบพอ" งานยังคงดำเนินต่อไปตามแนวคิดของ C ++ ซึ่งอาจนำไปสู่การทำให้เป็นมาตรฐานถัดไป อย่างไรก็ตามอาจเป็นไปได้ว่าบางคนจะทำงานกับข้อเสนอสำหรับมาตรฐานถัดไปซึ่งคล้ายกับข้อ จำกัด เทมเพลตของ D ไม่ว่าจะเกิดขึ้นหรือไม่คงที่จะเห็น เท่าที่ฉันทราบไม่มีข้อเสนอดังกล่าวสำหรับมาตรฐาน 2011 ดังนั้นจึงไม่มีโอกาสที่จะทำให้เป็นมาตรฐานนั้นโดยไม่คำนึงถึงข้อดีของมัน แต่สิ่งที่จะทำหรือไม่ทำให้เป็นมาตรฐานต่อไปไม่เป็นที่รู้จักอย่างสมบูรณ์ ณ จุดนี้.

ฉันไม่ทราบเหตุผลสำคัญว่าทำไมสิ่งที่คล้ายกับข้อ จำกัด เทมเพลตของ D ไม่สามารถนำมาใช้กับ C ++ ได้ แต่เนื่องจาก C ++ นั้นโดยทั่วไปมีข้อ จำกัด มากกว่าในสิ่งที่สามารถทำได้ในเวลาคอมไพล์ เช่นเดียวกับที่พวกเขาทำใน D (แม้ว่าการแนะนำสิ่งต่าง ๆ เช่นconstexprช่วยอย่างแน่นอน)

ดังนั้นฉันคิดว่าคำตอบสั้น ๆ ก็คือไม่มีเหตุผลทางเทคนิคว่าทำไมสิ่งที่คล้ายกับข้อ จำกัด เทมเพลตของ D ไม่สามารถอยู่ใน C ++ ได้

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


2

คุณหมายถึงแม่แบบของ D หรือไม่

เท่าที่ฉันรู้มีการเสนอแนวคิด C ++ ในนามของ boost :: concept ปัญหานี่คือการเพิ่มนั่นคือห้องสมุดที่เขียนขึ้นสำหรับ C ++ 03 C ++ 11 มีความสามารถด้านไวยากรณ์อื่น ๆ ที่อนุญาตให้ใช้สิ่งต่าง ๆ ในวิธีที่แตกต่างกันอนุญาตให้ C ++ 03 (ดังนั้นการเพิ่มตัวเองสามารถเขียนใหม่โดยใช้ข้อดีของไวยากรณ์ใหม่)

คณะกรรมการมาตรฐานลดแนวคิดเนื่องจากต้องใช้เวลานานเกินกว่าที่จะระบุ (ทำให้การอนุมัติ c ++ 11 ล่าช้าอีกครั้ง) พวกเขาอาจจะไปในรุ่น C ++ ต่อไป

ในขณะเดียวกันไวยากรณ์ D นั้นแตกต่างจาก C ++ และ D เองยังคงความสามารถในการประเมินผลการแสดงออกบางอย่างในเวลารวบรวม C ++ ไม่สามารถมีได้โดยไม่ต้องทำลายรหัสดั้งเดิมบางอย่าง ตอนนี้ C ++ มีอยู่แล้วstatic_assertและcostexprอนุญาตให้ปรับปรุงความสามารถในการประเมินเวลารวบรวม อาจเป็นในอนาคตจะถึงระดับใกล้เคียงกัน


2

นี่คือการประกันคุณภาพกับ Herb Sutter เขาพูดเกี่ยวกับแนวคิดที่เครื่องหมาย 15 นาที

http://channel9.msdn.com/Shows/Going+Deep/Herb-Sutter-C-Questions-and-Answers

ถ้าคุณชอบที่นี่เป็นอีกหนึ่ง: http://channel9.msdn.com/Shows/Going+Deep/Conversation-with-Herb-Sutter-Perspectives-on-Modern-C0x11

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

สำหรับสาเหตุที่ไม่รวมอยู่ใน C ++ 0x ก็เพราะมันใหญ่มาก ข้อเสนอมีความยาว 100 หน้าและใช้งานได้ยากมาก มีการตัดสินใจแล้วว่าคุณลักษณะนี้ต้องการเวลามากกว่าที่จะเติบโตจนกว่าจะรวมอยู่ในมาตรฐาน


2

ค่อนข้างง่าย C ++ มีกระเป๋าเดินทางในอดีตมากมายกว่า D มันจะง่ายกว่ามากหากจะนำสิ่งต่าง ๆ ที่น่ากลัวไปใช้งานหากไม่ใช่เพราะ C ++ มีรหัสทางประวัติศาสตร์จำนวนมากซึ่งต้องทำงานต่อไปอย่างถูกต้อง และเป็นไปตามคาด D ไม่มีปัญหานี้


บางทีคุณอาจใช้ถ้อยคำที่ผิด แต่ปัญหาไม่ใช่รหัสดั้งเดิมปัญหาคือว่าคุณลักษณะใหม่ใด ๆ ที่จะปรากฏในภาษามานานหลายทศวรรษและจะต้องได้รับการสนับสนุน นั่นหมายความว่าจะต้องเลือกคุณสมบัติใหม่แต่ละอย่างอย่างระมัดระวัง
Let_Me_Be

@Let_Me_Be: ใช่ปัญหาอยู่ในรหัสดั้งเดิมที่เราจะมีสิบปีลงบรรทัดถ้าเราโยนแนวความคิดในขณะนี้
David Thornley
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.