เหตุใด C ++ มาตรฐานจึงไม่ใช้เทมเพลตนิพจน์

17

เป็นความเข้าใจของฉันหรือไม่ว่าเทมเพลตนิพจน์เป็นเทคนิคถูกค้นพบอย่างมีนัยสำคัญก่อนมาตรฐาน C ++ ดั้งเดิมในปี 1998 เหตุใดพวกเขาจึงไม่ใช้เพื่อปรับปรุงประสิทธิภาพของคลาสมาตรฐานเช่นstd::stringและสตรีม

c++ history

— DeadMG
แหล่งที่มา

@ChrisLively: ถ้าฉันจะส่งข้อเสนอแนะการเปลี่ยนแปลงเช่นนั้นมันจะเป็นปัญหาที่ฉันไม่รู้ว่าทำไมมันไม่ได้ทำครั้งแรกและมันเป็นเรื่องที่เกี่ยวข้องกับการเขียนโปรแกรมและคำตอบนั้นดีมาก โดยเฉพาะ

— DeadMG

คุณจะทำอะไรกับเทมเพลตนิพจน์เพื่อเพิ่มความเร็วสตริง?

— jalf

5

@jalf: ถ้าคุณจะนำไปใช้operator+คุณสามารถบรรลุO(n)และไม่มีการจัดสรรซ้ำซ้อนสำหรับการจัดสรรซ้ำสิ่งที่ยังเร็วกว่าการอ้างอิง rvalue นอกจากนี้คุณสามารถปรับให้เหมาะสมสำหรับการใช้งาน COW โดยการคัดลอกเมื่อเขียนไม่ใช่แค่ "บนดัชนีไปยังที่ไม่ใช่ const" มีแอปพลิเคชันอื่นด้วยเช่นกันซึ่งทั้งประสิทธิภาพและความหมายสามารถปรับปรุงได้ด้วยเทมเพลตนิพจน์

— DeadMG

ฉันรู้ว่าคำถามนี้ได้รับการถามมานานแล้ว แต่โปรดอธิบายรายละเอียดบางอย่างเกี่ยวกับเทมเพลตการแสดงออกและ / หรือลิงก์ไปยังเนื้อหาที่เกี่ยวข้อง

— einpoklum

17

เทมเพลตการแสดงออกได้รับการตีพิมพ์เป็นครั้งแรกโดย Todd Veldhuizen ในเดือนมิถุนายน1995ในบทความในนิตยสารC ++ Report ตามเวลานั้นคณะกรรมการมาตรฐานมีส่วนเกี่ยวข้องอย่างมากกับการเพิ่ม STLลงในมาตรฐาน C ++ ซึ่งเป็นงานที่ตัวเองต้องเลื่อนมาตรฐานออกไปหนึ่งหรือสองปี (STL ถูกนำเสนอต่อคณะกรรมการในปี 1993 และเสนออย่างเป็นทางการในปี 1994 ใช้เวลาอีกสี่ปีกว่าจะเสร็จสิ้นมาตรฐาน)
เนื่องจากคณะกรรมการกำหนดมาตรฐาน C ++ เป็นอาสาสมัครบางกลุ่มไม่ได้รับการสนับสนุนจาก บริษัท ที่จ่ายเงิน ค่าใช้จ่ายฉันไม่คิดว่าใครมีทรัพยากรที่จะใช้ในการเพิ่มความคิดอื่นให้กับมาตรฐาน C ++

นอกจากนี้ 1995 เป็นเพียงบทความของ Veldhuizen ที่ตีพิมพ์ สำหรับเทคนิคที่จะกลายเป็นที่รู้จักและได้รับการยอมรับก็จะได้ดำเนินการอีกไม่กี่ปี (ความคิดของ STL ย้อนหลังไปถึงยุค 70 มีการนำ Ada มาใช้ในช่วงปลายยุค 80 การทำงานที่ C ++ จะต้องเริ่มต้นประมาณปี 1990 และใช้เวลาอีกสามปีกว่าที่แนวคิดจะหาทางไปสู่มาตรฐาน C ++ คณะกรรมการ.)
มี แต่เพียงสามปีนับจากบทความของ Todd จนกว่าจะมีการลงคะแนนเสียงรอบสุดท้ายในมาตรฐาน นั่นเป็นเวลาที่น้อยเกินไปที่จะรวมแนวคิดที่ยังใหม่เอี่ยมและยังไม่ผ่านการทดสอบ

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

— SBI
แหล่งที่มา

1

แต่std::stringและ iostreams ไม่ได้อยู่ใน STL

— R. Martinho Fernandes

@ R.MartinhoFernandes: นั่นไม่ได้หมายความว่าอย่างไรก็ตามคณะกรรมการมีทรัพยากรที่จะสำรอง (และเปลี่ยนstd::string เป็นเปลี่ยนเป็นคอนเทนเนอร์ STL, BTW)

— sbi

2

ฉันคิดว่าฉันต้องเชื่อมโยงนี้: std :: string ส่วนหนึ่งของ STL หรือไม่

— Xeo

@sbi ah, เหมาะสมแล้ว

— R. Martinho Fernandes

10

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

ไลบรารีมาตรฐานมีอยู่แล้วstd::valarrayและตระกูลซึ่งมีวัตถุประสงค์เพื่อสนับสนุนรูปแบบเทมเพลตนิพจน์ของการใช้งาน เท่าที่ฉันสามารถบอกได้ว่ามันไม่ได้ค่อนข้างตัด ปัญหาหนึ่งที่ทำให้เกิดปัญหานี้ก็คือผู้คนที่ชักชวนให้รับรุ่นที่เบ็นรวมอยู่ในมาตรฐานหยุดทำงานในขณะที่มันรวมอยู่ด้วย มีความพยายามที่จะช่วยเหลือ (เช่น David Vandevoorde, Matt Austern และฉันทำงานอยู่หนึ่งวันหรือมากกว่านั้นในการประชุมสตอกโฮล์ม) แต่ในท้ายที่สุดไม่มีใครสนใจพอ

— Dietmar Kühl
แหล่งที่มา

8

คุณเริ่มต้นด้วยความไม่ยุติธรรมเล็กน้อยเพราะ DeadMG ไม่สามารถล็อบบี้ได้เนื่องจากข้อเท็จจริงง่ายๆที่ว่าเขามีผ้าอ้อมที่โตเกินแทบจะไม่ทันและอาจไม่ถึงจุดที่เขาสามารถออกเสียง "C ++" ได้อย่างเหมาะสม :)

— sbi

7

ขอโทษอย่างยิ่งที่เป็นเด็กวัยหัดเดินฉันไม่ได้วิ่งเต้น: P

— DeadMG

1

ฉันรู้ว่าไม่ใช่ทุกคนที่มีโอกาสมีอิทธิพลต่อมาตรฐาน แม้ว่าฉันจะเข้าร่วมประชุมคณะกรรมการอย่างสม่ำเสมอตั้งแต่ประมาณ 15 ปีอิทธิพลของฉันที่มีต่อมาตรฐานนั้นมี จำกัด อย่างไรก็ตามประเด็นของฉันคือ: ถ้ามีคนต้องการบางสิ่งในมาตรฐานที่พวกเขาต้องใช้ความพยายาม! สิ่งที่ไม่ได้อยู่ที่นั่นเป็นสิ่งสำคัญสำหรับผู้ที่มีลำดับความสำคัญอื่น ๆ ไม่ว่าจะเป็นด้านเทคนิคหรืออื่น ๆ (เช่นมุ่งเน้นที่การเติบโตอย่างเต็มที่)

— Dietmar Kühl

การใช้ libgcc ของฐาน valarray บนเทมเพลตนิพจน์

— phresnel

3

เทคนิคที่รู้จักกันในชื่อ "เทมเพลตการแสดงออก" ถูกค้นพบ (อย่างอิสระ) อย่างน้อยก็ย้อนกลับไปเมื่อปี 1994 โดยทั้งทอดด์เวลด์ฮุยเซ็นและตัวฉันเอง (บทความของทอดด์มาจากปี 1995 แต่ใช้เวลาสักครู่ ถูกแสดงครั้งแรกใน comp.lang.c ++)

ฉันเริ่มเข้าร่วมการประชุมคณะกรรมการ C ++ จริง ๆ เพราะปัญหานี้ ฉันนำเสนอเทคนิคและการออกแบบใหม่ทั้งหมดของ std :: valarray ต่อคณะกรรมการในการประชุมซานตาครูซครั้งแรกในเดือนมีนาคม 2539 ถือว่าเป็นการเปลี่ยนแปลงที่ใหญ่เกินไป แต่เนื่องจาก Dietmar alludes ถึงเราได้รับคำพูดในการประชุมครั้งต่อไป ในสตอกโฮล์มที่เปิดใช้งานเทมเพลตนิพจน์สำหรับการนำ std :: valarrray ไปใช้ ที่แปลกใจของคำเหล่านั้นยังคงมี: ดูย่อหน้าที่ 3-6 ของหมวด [valarray.syn] 29.7.1 ในhttp://wg21.link/N4727

— Daveed V.
แหล่งที่มา

1

สงสัยว่ามีจุดประสงค์อะไรในการใช้ตัวย่อลิงก์แทน URL จริง

— gnat

3

@gnat: หากคุณรู้หมายเลขเอกสารมันเป็นเรื่องง่ายที่จะเขียน URL wg21.link นั่นคือสิ่งที่ฉันทำที่นี่ มันช่วยให้ฉันมองหาการส่งจดหมาย / ปีโดยเฉพาะที่เอกสารถูกปล่อยออกมานอกจากนี้ฉันหวังว่าถ้า / เมื่อ WG21 ตัดสินใจย้าย URL การโฮสต์ wg21.link จะได้รับการอัปเดตตามลำดับจึงหลีกเลี่ยงการอ้างอิงค้าง (นั่นคือประเด็นไม่ได้สั้นลง แต่สามารถอ่านได้)

— เดฟ V.

0

สิ่งที่ดีที่สุดที่ฉันคาดเดาได้คือไม่มีคอมไพเลอร์จะสามารถรวบรวมเทมเพลตนิพจน์กลับมาในปี 1998

— fredoverflow
แหล่งที่มา

1

Todd Veldhuizen ทำงานเทมเพลตการแสดงออกของเขาก่อนปี 1996 โดยใช้คอมไพเลอร์ C ++ ของ KAI เหตุผลดูหมิ่นมากขึ้น ...

1

ชุมชน C ++ ส่วนใหญ่นั้นไม่สามารถใช้ STL ได้อย่างเต็มศักยภาพจนถึงปี 2003 (ฉันกำลังมองคุณ Microsoft!) และนั่นไม่ได้หยุดคณะกรรมการที่จะรวม STL เข้ากับมาตรฐาน

— sbi

2

จริงๆแล้ว bth กับฉันเดิมมีเทคนิคการแสดงเทมเพลตเพื่อทำงานกับคอมไพเลอร์ Borland C ++ 4 (ซึ่งเปิดตัวในปี 1993) ฉันเชื่อว่านั่นเป็นคอมไพเลอร์ตัวแรกที่ทำให้ STL ทำงานได้อย่างสมบูรณ์ หลังจากนั้นฉันก็ย้ายไลบรารีเทมเพลตนิพจน์ไปยังคอมไพเลอร์อื่น ๆ ที่หลากหลาย (รวมถึงคอมไพเลอร์ที่ใช้ Cfront ของซันในเวลานั้น!) คอมไพเลอร์ KAI C ++ ในเวลาต่อมา

— Daveed V.

@DaveedV BCC4 เป็นคอมไพเลอร์ที่ดีมากสำหรับเวลาและดีกว่า VC เวอร์ชันในเวลานั้นมาก ! มันมีนิสัยแปลก ๆ บางอย่างเช่น "ข้อผิดพลาดยิ้ม" ที่น่าอับอาย :->นอกจากนี้พวกเขาไม่สามารถปรับปรุงได้เร็วพอดังนั้นจึงกลายเป็นเรื่องยากขึ้นและยากขึ้นในการใช้เทคนิคแม่แบบที่ปรับปรุงอย่างรวดเร็วด้วย เมื่อ VC7.1 ได้รับการปล่อยตัวและปฏิบัติตามได้มากขึ้นนั่นทำให้บอร์แลนด์เสียชีวิต

— sbi