STL สำหรับเกมใช่หรือไม่? [ปิด]

144

ภาษาโปรแกรมทุกภาษามีไลบรารีมาตรฐานของคอนเทนเนอร์อัลกอริทึมและสิ่งอื่น ๆ ด้วยภาษาเช่น C #, Java, และ Python มันแทบจะนึกไม่ถึงว่าจะใช้ภาษาโดยไม่ใช้ lib มาตรฐาน

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

ดังนั้น ... STL เหมาะสมหรือไม่

c++

— เอื้อเฟื้อเผื่อแผ่
แหล่งที่มา

14

EASTL เป็นการอ่านที่ดีopen-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html

— Matias Valdenegro

1

ใช่นั่นคือสิ่งที่ฉันหมายถึงโดย "ใช้การดำเนินการของเราเอง" :)

— เอื้อเฟื้อเผื่อแผ่

3

หากคุณมีโอกาสค้นหาและซื้อ Best of Game Programming Gems ให้ทำ มีชื่อบทความว่า "การใช้ STL ในการเขียนโปรแกรมเกม" โดย James Boer, ArenaNet ซึ่งทำให้เขาเป็นกรณีที่ดีมากในการใช้ STL

— chiguire

จริงๆแล้วการใช้ Java โดยไม่มี lib มาตรฐานเป็นไปได้สวยเรียกว่า J2ME: p

— Bart van Heukelom

1

เป็นคำถามที่ดีมาก!

— อลัน

191

ย้อนกลับไปเมื่อฉันทำงานในการพัฒนาเกมมืออาชีพ STL นั้นยังเด็กเกินไปและอ้วนเกินไป แต่นั่นคือ> 10 ปีที่แล้ว

ตอนนี้ฉันทำงานในสถานการณ์จำลองทางทหารซึ่งมีข้อกำหนดด้านประสิทธิภาพที่เข้มงวดกว่า (เช่นอัตราเฟรมไม่สามารถต่ำกว่า FPS บางส่วน) ในการจำลองทางทหาร STL ถูกนำมาใช้ทั่วทุกสถานที่

บางคนที่บอกคุณว่าอย่าใช้ STL ใช้อาร์กิวเมนต์ที่ว่าไม่ใช่วิธีที่สมบูรณ์แบบหรือแม้แต่วิธีที่ดีที่สุดในการแก้ไขปัญหา แต่นั่นไม่ใช่คำตอบสำหรับคำถาม คำถามควรจะเป็น: มีอะไรผิดปกติกับการใช้ STL ในเกมหรือไม่? ฉันจะบอกว่าไม่ STL เป็นส่วนใหญ่การใช้งานที่ดีกว่าสิ่งที่ผู้ใช้จะเกิดขึ้นด้วยตัวเอง

เพียงให้แน่ใจว่าคุณรู้วิธีใช้ STL และใช้ในเกมของคุณ อ่านหนังสือและดูรหัสการนำไปใช้ใน STL ที่คุณกำลังใช้

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

49

นี่เป็นคำแนะนำที่มั่นคง meme "STL ช้า" ไม่เป็นความจริงเป็นเวลาอย่างน้อยห้าปีและอาจนานกว่านั้น มันจะยังคงอยู่ต่อไปเช่นเดียวกับ "Java ช้า" และ ". NET ช้า" ไร้สาระจนกว่ามันจะปรากฏให้ทุกคนเห็นว่ามันไม่ได้เป็นกรณีอีกต่อไป STL ช่วยให้คุณเขียนโปรแกรมได้ดีขึ้น ฉันจะไปไกลถึงจะบอกว่าไม่ได้ใช้มันในกรณีส่วนใหญ่ (นอกเหนือจากนั้น 0.1% ที่ใดที่หนึ่ง) เป็นความรับผิดชอบ (. เรียกร้องว่ามันไม่พอดีกับปัญหาโดเมนที่ได้รับมักจะมีมากขึ้นของคำฟ้องของวิธีการปัญหาถูก tackled ที่ไม่ STL ตัวเองแก้ไขของคุณรหัส folks.)

— เอ็ด Ropple

5

@Ed Ropple: ฉันคิดว่าปัญหาไม่ใช่ว่า STL ไม่เหมาะกับปัญหาที่กำหนดปัญหาคือว่ามันเหมาะกับปัญหามากเกินไปซึ่งทำให้รหัสในมันซับซ้อนเกินไป มันน่ากลัวที่ผู้คนใช้ STL มากเกินไปและฉันคิดว่านั่นเป็นหนึ่งในสาเหตุที่ทำให้หลายคน (รวมถึงตัวเอง) ละเว้นการใช้งานเลย เช่นเดียวกับตัวอย่างที่ฉันเห็นเมื่อไม่นานมานี้ที่คำถามคือทำอย่างไรให้ได้จำนวนที่มากที่สุดจาก 3 ตัวคำตอบหนึ่งในนั้นก็ผลักพวกมันให้เป็น std :: vector แล้ว std: sort นั่นคือการบังคับให้โซลูชันที่ไม่จำเป็นมาสู่ปัญหาที่ง่ายมาก

— Simon

22

@Simon: ด้วยความเคารพอย่างดีที่สุดตัวอย่างสุดท้ายคือสัญลักษณ์ของความไร้มารยาทและไม่มีอะไรเกี่ยวข้องกับ STL ... บุคคลนั้นจะทำสิ่งเดียวกันในภาษาอื่นที่มีรายการที่สามารถเรียงลำดับได้ มันเป็นความคิดของเขาที่พัง

— ggambett

@EdRopple พยายามใช้ตัวแยกวิเคราะห์ STL สำหรับไฟล์รูปภาพ PPM (รวมรหัสน้อยกว่า 100 บรรทัดหากกำหนดเป้าหมายเฉพาะ P6 หรือ P3 เท่านั้น) ครึ่งหนึ่งของโค้ดที่ได้นั้นเป็นเพียงการข้ามบรรทัดความคิดเห็นเพราะ STL ไม่ได้ให้สิ่งที่ต้องการif(stream.nextCharacter() == '#') stream.skipLine();

— GameDeveloper

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

— Ed Ropple

63

ฉันจะบอกว่าที่ด้านบนของหัวของฉันมันเป็นความคิดที่ดีกว่าที่จะใช้ STL เว้นแต่คุณจะรู้ว่าทำไมคุณไม่ต้องการใช้มัน

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

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

— เอ็ด Ropple
แหล่งที่มา

4

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

— zebrabox

2

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

— Ed Ropple

20

ฉันจะบอกว่า gamedev เกี่ยวกับการทำเกมแต่ตกลง หากสมมติฐานของคุณแย่มากจนคุณได้รับการเจาะในการจัดสรรทรัพยากรแบบนั้นใช่คุณต้องถอยกลับและประเมินใหม่ แต่คุณสามารถสร้างแอพพลิเคชั่นที่รวดเร็วซึ่งใช้ STL ได้เช่นกันและแน่นอนว่าการใช้งานอื่น ๆ - เมื่อคุณรู้ว่าคุณกำลังทำอะไรอยู่ เรียนรู้สิ่งที่คุณกำลังทำ> ปฏิเสธคำสั่ง STL ไม่มีใครพูดว่า STL เป็นคำตอบที่ดีที่สุดเสมอ สิ่งที่ฉันพูดคือถ้าคุณไม่สามารถอธิบายได้อย่างชัดเจนว่าทำไมมันถึงไม่ใช่หลักสูตรที่ดีที่สุดคุณควรใช้ STL

— Ed Ropple

11

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

— Ed Ropple

4

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

— Kaj

35

ฉันเห็นเหตุผลน้อยมากที่ไม่ใช้ STL สำหรับเกม

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

แน่นอนถ้าคุณกำลังใช้ STL และทำสิ่งที่โง่เช่นแผนที่ของสตริงไปยังประเภทที่ไม่ใช่ตัวชี้ขนาดใหญ่แสดงว่าคุณมีปัญหาใหญ่ในมือของคุณ

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

จริง ๆ แล้วการใช้ชนิดตัวชี้ที่ไม่ใช่ขนาดใหญ่ในแผนที่เป็นกรณีการใช้งานที่ดีเนื่องจากแผนที่ stdlib มีความต้องการในการไม่ใช้ตัววนซ้ำซึ่งบังคับให้มีการนำไปใช้งานโดยใช้ตัวชี้และองค์ประกอบที่แมปที่จัดสรรเป็นรายบุคคล ทางออกที่ดีที่สุดสำหรับเกมคือการใช้google::sparse_mapหรือเขียนด้วยตัวเอง

— v.oddou

ทำไมไม่หนาแน่นแผนที่?

— GameDeveloper

23

STL ที่เป็นค่าเริ่มต้นมีปัญหาจำนวนพอสมควรที่ทำให้ยากต่อการใช้งานกับเกม

ชุดปรับแต่งที่กำหนดเองเช่นEA STLออกแบบมาเป็นพิเศษสำหรับเกมและสามารถเพิ่มประสิทธิภาพหน่วยความจำและการใช้งานคอนโซลได้ดียิ่งขึ้น มันก็กลายเป็นที่มาเปิดในปี 2016 ภายใต้ข้อ BSD-3 มีพื้นที่เก็บข้อมูลบน GitHub

— เบ็น Zeigler
แหล่งที่มา

19

ปัญหาเกี่ยวกับการใช้หน่วยความจำของ STL และเกมสามารถแก้ไขได้ด้วยคลาสตัวจัดสรรแบบกำหนดเอง อันที่จริงที่งานก่อนหน้านี้ของฉัน "กำหนดเอง" ชั้นเวกเตอร์ของเราเป็นเพียงเสื้อคลุมบาง ๆ รอบstd::vectorที่ลบล้างจัดสรรเป็นค่าเริ่มต้น

— แบลร์ฮอลโลเวย์

1

@Blair Holloway: "ตัวจัดสรรแบบกำหนดเองนั้นใช้แบบคลาสไม่อิงตามอินสแตนซ์ตัวจัดสรรจะต้องสร้างและทำลายออบเจ็กต์เช่นเดียวกับการจัดสรรพวกมันสิ่งนี้เป็นการบังคับให้เกิดการผสมกันของแนวคิดที่แยกกันสองอย่าง: การจัดสรรและการสร้าง ปัญหาเกี่ยวกับ stl-allocators โชคไม่ดี " EA STL ให้เหตุผลที่ถูกต้องมากกว่าเดิมว่าทำไมตัวจัดสรร STD ไม่ถูกต้อง ไม่ใช่แค่ "ไม่ว่าพวกเขาจะถูกแทนที่"

— Simon

@Simon - ฉันจะไม่เถียงว่าระบบการจัดสรรของ STL นั้นสมบูรณ์แบบเพราะไม่ใช่ เราใช้เวลานานในการหาวิธีแก้ปัญหาที่ใช้งานได้ สิ่งที่ฉันพูดคือในบางกรณีเป็นไปได้ที่จะได้โซลูชันที่เป็นมิตรกับเกมโดยใช้ STL และทำงานกับตัวจัดสรรแบบกำหนดเองเล็กน้อย

— แบลร์ฮอลโลเวย์

@Simon - การทำอย่างละเอียด: ในขณะที่ STL อาจจะยุ่งยาก แต่ก็เป็นโค้ดที่ผ่านการทดสอบและปราศจากข้อผิดพลาดเป็นอย่างดี หากคุณสามารถใช้งานได้คุณจะประหยัดเวลาในการแก้ปัญหาแบบกำหนดเองได้ไม่กี่ชั่วโมง งานปัจจุบันของฉันแสดงให้เห็นถึง STL ในความโปรดปรานของผู้จัดสรรบ้านและฉันต้องใช้เวลาในการดีบั๊กและ refactoring โค้ดบางส่วนเพราะมันไม่ได้อยู่ในระดับเดียวกับ STL

— แบลร์ฮอลโลเวย์

1

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

— BRaffle

21

นี่คือสิ่งที่ไมค์แอคตัน (กรรมการเครื่องยนต์ที่ Insomniac เกมสไปโรมังกร & เฟืองโซ่และการต่อต้านยี่ห้อ) ได้กล่าวเกี่ยวกับเรื่องนี้เมื่อถามว่าที่นี่ หมายเหตุเขาถูกถามเกี่ยวกับทั้ง STL และ Boost โดยทั่วไปเกี่ยวกับการใช้งานในเกม dev

STL / Boost มันเป็นของ gamedev หรือไม่ ถ้าเพียงส่วนหนึ่งของสิ่งที่คน?

คุณถามถึงสองสิ่งที่แตกต่างกันที่นี่ใช่ไหม STL และ Boost แยกกัน แต่จริงๆแล้วคำตอบของฉันเหมือนกัน: ไม่มีอะไรผิดปกติกับคำตอบเดียวแต่ฉันก็ไม่แนะนำให้ใช้ การใช้งานของทั้งส่งเสริมให้คนที่เหมาะสมกับวิธีการแก้ปัญหามากกว่าที่จะหาวิธีการแก้ปัญหา โซลูชันควรเหมาะสมสำหรับข้อมูลในมือและข้อ จำกัด ของฮาร์ดแวร์ ฯลฯ ทั้ง STL และ Boost มีมุมมองที่แคบมากเกี่ยวกับ "โลก" และการใช้งานที่เหมาะสมมี จำกัด จริง ๆ ฉันไม่แนะนำพวกเขาเพราะพวกเขานำโปรแกรมเมอร์ไปสู่ทิศทางที่ผิดทันทีฉันมักจะพูดว่าถ้าคุณรู้สึกว่าคุณต้องการคนที่คุณอาจไม่เข้าใจปัญหาที่คุณ

ฉันได้สังเกตเห็นด้วยว่าผู้พัฒนาเกมมืออาชีพส่วนใหญ่พยายามมุ่งไปที่ C มากกว่า C ++

— คีย์เฟรม
แหล่งที่มา

18

ฉันไม่เห็นด้วยกับความพยายามที่มีต่อ C. นักพัฒนาเกมส่วนใหญ่รวมถึงนักเขียน SDK ใช้ C ++ ในความเป็นจริงผู้ใช้ C รายใหญ่คนสุดท้ายเป็น id และแม้กระทั่ง Carmack ได้ไปที่ C ++ แล้ว ...

— Goz

82

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

— Ed Ropple

50

ประสบการณ์ของฉันกับ STL เกือบจะตรงกันข้าม มันมีประสิทธิภาพและประหยัดเวลา ถ้าคุณรู้สึกว่าจำเป็นต้องม้วนไลบรารีแม่แบบของคุณเองหรือไลบรารีคอนเทนเนอร์นั่นก็ใช้ได้ แต่อย่าแสร้งว่า STL (หรือเพิ่มพลังเพื่อเรื่องนั้น) ไม่ดี ฉันใช้ STL อย่างกว้างขวางในเกม iPhone เชิงพาณิชย์, Nintendo DS, Wii, PC, Mac และ Xbox ทุกครั้งที่ฉันถูกบังคับให้ใช้ห้องสมุด "ดีกว่า" ของคนอื่นฉันพบว่ามันขาดและบั๊กกี้

— BRaffle

5

มันใช้งานได้ดีกับ DS เหมือนกับแพลตฟอร์มอื่น ๆ ที่ฉันเคยใช้ ฉันใช้ STL ไปทั่ว UI และรหัส AI เกมนี้เป็นds.ign.com/articles/832/832147p1.html ฉันทำงานที่สตูดิโอขนาดเล็กซึ่งเป็นส่วนหนึ่งของ Amaze ซึ่งเป็นส่วนหนึ่งของมูลนิธิ 9

— BRaffle

7

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

— Dan Olson

19

หากคุณพบว่าตัวเองเขียนอะไรบางอย่างที่มีอยู่แล้วใน STL ด้วยเหตุผลใด ๆหยุด ใช้ STL

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

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

7

map <> แทบไม่เคยเป็นสิ่งที่คุณต้องการใช้สำหรับหน่วยความจำอะไรหรือซีพียูที่มีประสิทธิภาพในบริบทของเกม hash_map <> เป็นตัวเลือกที่ดีกว่าเกือบทุกครั้งแม้ว่าประสิทธิภาพของ hash_map จะแตกต่างกันอย่างมากกับผู้ขาย หากคุณกำลังสร้างเกมที่มีทั้งสำหรับคอนโซลหรือฟีเจอร์การเล่นเน็ตเวิร์กที่ปรับขนาดได้ STL อาจช้าเกินไปหรือบวมเกินไปสำหรับจุดประสงค์ของคุณ

— Ben Zeigler

3

unordered_map <> สามารถใช้ได้อย่างกว้างขวางและมีข้อกำหนดด้านประสิทธิภาพที่เข้มงวดอย่างมากในร่าง TR1 ปัจจุบัน (จนถึงจุดที่เกินจริงฉันคิดว่า - แม้จะห้ามการแฮ็กแบบเปิดและในขณะที่มักจะช้ากว่าฉันไม่คิดว่ามันควรถูกห้ามโดยเด็ดขาดตามมาตรฐาน)

5

STL เสนออัลกอริทึมเช่นเดียวกับคอนเทนเนอร์ ไม่เคยมีเหตุผลที่จะไม่ใช้อัลกอริทึมรุ่น stl ตัวอย่างเช่นstd::sortโดยทั่วไปใช้ introsort ด้านล่างอย่างรวดเร็วและซับซ้อนพอที่คุณจะไม่ต้องการทำมันด้วยตัวเอง

— deft_code

ความจริงก็คือunordered_mapC ++ 11 หรือบูสเตอร์ช้าเกินไปสิ่งที่คุณต้องการคือแผนที่แฮชเปิดที่อยู่เช่น google :: sparse_map หรือของคุณเอง

— v.oddou

16

STL เหมาะสมกับเกมหรือไม่? อย่างแน่นอน. เกมเป็นซอฟต์แวร์ที่ซับซ้อนส่วน STL มีคุณสมบัติที่ช่วยจัดการความซับซ้อนดังนั้นจึงเป็นเรื่องดี

มันเป็นแบบที่ดีสำหรับแพลตฟอร์มของคุณ? ไม่จำเป็น. หากคุณกำลังเขียนสำหรับคอนโซลคุณจะต้องระมัดระวังเกี่ยวกับการใช้หน่วยความจำและแคช STL ไม่ได้ทำให้เป็นเรื่องง่ายมาก

ฉันคิดว่าบ่อยครั้งที่เราเข้าใจผิดว่า "เกม" สำหรับ "เกมเรียลไทม์ประสิทธิภาพสูงที่ทำงานบนฮาร์ดแวร์แบบฝังหรือเรียกร้อง" แต่สิ่งสำคัญคือการสร้างความแตกต่าง หากคุณกำลังเขียนเกม Windows ที่ไม่ได้พยายามเล่นเต็มหน้าจอด้วยความเร็วคงที่ 60fps ดังนั้นจึงไม่มีเหตุผลที่จะหลีกเลี่ยงเครื่องมือที่ไลบรารีมาตรฐานมอบให้คุณ

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

10

ฉันรู้ว่ามันสายไปงานปาร์ตี้ แต่การเปลี่ยนแปลงเวลาและคำตอบอยู่รอบ ๆ C ++ 11 มีการเปลี่ยนแปลงอย่างรวดเร็วซึ่งส่วนใหญ่เป็นการเพิ่มประสิทธิภาพของ C ++ และไลบรารี่มาตรฐาน ดูเหมือนว่าคนที่ไม่ได้ใช้ STL หรือ Boost มีแนวโน้มที่จะไม่ทำตามมาตรฐานใหม่อย่างใดอย่างหนึ่งออกจากการแก้ปัญหาการปั่นที่บ้านขาดการปรับปรุงที่สำคัญแน่นอนว่านี่ไม่ใช่กรณี

ฉันใช้ STL ในทุกโครงการตั้งแต่ช่วงกลางยุค 90 จนถึงปัจจุบันยกเว้นช่วงเวลาสั้น ๆ ที่ EA ฉันคิดว่าฝ่ายต่อต้าน STL มีเหตุผลบางอย่างที่ไม่ควรใช้ ส่วนใหญ่จะหายไป ตัวจัดสรรแบบกำหนดเองเป็นวิธีการหนึ่งโดยใช้การสำรองเป็นอีกวิธีหนึ่งและไม่ผ่านสิ่งต่าง ๆ ตามค่าคือหนึ่งในสาม แต่สิ่งเหล่านี้ค่อนข้างเรียบง่ายและโปรแกรมเมอร์ทุกคนควรรู้สิ่งเหล่านี้ ที่สำคัญกว่านั้นคือการใช้อัลกอริทึม ผู้เขียนคอมไพเลอร์รู้อย่างแน่นอนว่า for_each () ทำอะไรและสามารถปรับรหัสให้เหมาะสม ที่ไม่สามารถเกิดขึ้นได้กับการวนกลับบ้าน for_each () บนวัตถุ const ดียิ่งขึ้น Microsoft เพิ่มประสิทธิภาพ for_each ในหลาย ๆ วิธีรวมถึงการทำให้เป็นอนุกรม พวกเขายังมีห้องสมุด AMP ซึ่งมี parallel_for_each () หากคุณมีโอกาสพูดคุยกับวิศวกรคอมไพเลอร์เกี่ยวกับเรื่องนี้ คอมไพเลอร์ของคอนโซลจะปรับสิ่งที่ได้ใช้ให้เหมาะสมดังนั้น เป็นปัญหาไก่และไข่ Microsoft กำลังหนักมากด้วย C ++ 11 และ XBox ถัดไปจะไม่แตกต่างกัน ฉันไม่รู้เกี่ยวกับ PS4 เรายังไม่ได้รับ

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

แนวคิดที่ว่า Boost และ STL มีมุมมองที่แคบในการแก้ปัญหาคือความวิกลจริตอย่างแท้จริง ฉันตกตะลึงกับสิ่งต่าง ๆ ใน STL และ Boost ที่สามารถปรับแต่งได้ตามลักษณะและนโยบาย มองหาการเปรียบเทียบสตริงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่เป็นตัวอย่าง

เกี่ยวกับเวลาเชื่อมโยงที่ยาวนานและการขยายโค้ดเทมเพลต externใหม่ควรช่วยในเรื่องนี้ โดยทั่วไปฉันพบว่าเวลาในการคอมไพล์นานมาจากการมีเพศสัมพันธ์มากเกินไปและการใช้ pch ในทางที่ผิด

เหตุผลที่น่าสนใจที่สุดในการใช้ STL เหนือบ้านคือมีคนหลายล้านคนที่สามารถช่วยเหลือ STL ให้คุณ เช่นเคยอย่าเพิ่มประสิทธิภาพก่อนเวลาอันควรและทดสอบทดสอบทดสอบ

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

แนวคิดที่น่าสนใจ คุณหมายถึงอะไรโดย " ใช้คลาสตามใหม่และลบ "? คุณหมายถึงเร่งกระบวนการโดยใช้วัตถุที่มีอยู่แล้วในกอง?

— johnbakers

9

นี่เป็นประเด็นร้อนในการพัฒนาเกม ฉันไม่แนะนำโดยส่วนตัวยกเว้น EASTL ตามที่กล่าวไว้ข้างต้น ฉันมีปัญหาหลักสองประการเกี่ยวกับ STL (ในทางเทคนิค "The C ++ Standard Library" เนื่องจาก STL ไม่มีชื่อแล้ว) ในเกม 1) การจัดสรรหน่วยความจำแบบไดนามิกมักจะสิ้นเปลืองเวลารันไทม์จำนวนมากในเกมเมื่อใช้ STL 2) การใช้ STL สนับสนุนแนวทางอาเรย์โครงสร้างของเกมในขณะที่วิธีโครงสร้างแบบอะเรย์นั้นเป็นมิตรกับแคชมากกว่า

— เทอเรนซ์โคเฮน
แหล่งที่มา

ดังที่กล่าวไว้ในที่อื่นคุณสามารถให้ตัวปันส่วนที่กำหนดเองให้กับคลาสคอนเทนเนอร์ - สิ่งเหล่านี้อาจใช้ฟรีแลนซ์ได้หากคุณต้องการ (อาร์เรย์ที่จัดสรรล่วงหน้า) array-of-structs vs struct-of-arrays นั้นขึ้นอยู่กับว่าคุณกำลังพยายามทำอะไรมาก - ไม่มีกฎที่ยากและรวดเร็วว่าอันไหนดีกว่ากัน

— Skizz

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

— Terrance Cohen

5

มันขึ้นอยู่กับ. โครงการมีขนาดเท่าใดแพลตฟอร์มใดและไทม์ไลน์คืออะไร

หากคุณกำลังทำงานในโครงการขนาดใหญ่บนแพลตฟอร์มที่มีทรัพยากร จำกัด ด้วยระยะเวลาและงบประมาณที่สำคัญคุณสามารถช่วยตัวเองได้หลายปัญหาด้วยการหลีกเลี่ยงนรกที่หลีกเลี่ยงไม่ได้ซึ่งจะมองไปที่ฐานรหัสครึ่งล้าน ที่ทิ้งกระจุยกระจายกับ STL, ไม่สามารถเก็บเฟรมที่สูงกว่า 30, กิน RAM ให้พอดีกับสินทรัพย์อื่น ๆ อีกมากมายและใช้เวลาสร้าง 2 ชั่วโมง

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

รู้ว่าเมื่อใดควรแลกเปลี่ยนประสิทธิภาพเพื่อความสะดวก!

— Jason Kozak
แหล่งที่มา

1

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

— gkimsey

4

IMHO ฉันว่ามันเหมาะสมดีเนื่องจาก STL ทำงานได้ดีและเหมาะสำหรับงานที่ทำ นอกจากนี้คุณกำลังทำงานกับเกมดังนั้นให้ใช้เครื่องมือที่มีอยู่ในมือซึ่งทำให้ชีวิตของคุณง่ายขึ้นและโค้ดของคุณมีแนวโน้มที่จะเป็นโรคจิตน้อย

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

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

2

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

— Terrance Cohen

2

แต่ถ้าคุณไม่ต้องการการจัดสรรหน่วยความจำแบบไดนามิกคุณไม่ควรใช้ STL นั่นคือการจัดเรียงของจุด รหัสของคุณจะไม่ดีขึ้นและอาจแย่ลงไปอีก ตัดสินใจการออกแบบผิด STL เป็นปัญหาที่นี่ไม่ STL, ความสามารถของตนหรือลักษณะ perf ของมัน คุณกำลังโจมตีส่วนที่ผิดของปัญหา

— Ed Ropple

4

STL นั้นใช้งานได้ดีในเกมตราบใดที่คุณเข้าใจดี เครื่องยนต์ของเราใช้งานได้อย่างกว้างขวางและไม่เคยมีปัญหามาก่อน ฉันไม่มีประสบการณ์ใด ๆ กับการพัฒนาคอนโซลซึ่งอาจเป็นเรื่องที่แตกต่างไปจากเดิมอย่างสิ้นเชิง แต่ได้รับการสนับสนุนอย่างดีบนแพลตฟอร์มพีซีทั้งหมด (Windows / Mac / Linux)

สิ่งสำคัญที่สุดคือการเข้าใจว่าจุดแข็งและจุดอ่อนของภาชนะแต่ละประเภทคืออะไรและเลือกภาชนะที่ถูกต้องสำหรับงานที่คุณกำลังทำ

— เจสันโมราเลส
แหล่งที่มา

4

อดีตนายจ้างของฉันเปลี่ยนจากการใช้คลาสคอนเทนเนอร์แบบกำหนดเองที่มีประสิทธิภาพเป็น STL เวลาในการสร้างเพิ่มขึ้นและความสะดวกในการดีบั๊กลดลงทั้งคู่ค่อนข้างเด่นชัด หากเราเริ่มต้นจากศูนย์ STL (อาจจะใช้ดีกว่า) น่าจะสมเหตุสมผล แต่ก็ไม่ชัดเจนสำหรับฉันว่าเราได้รับอะไรเลยในการสลับไปใช้ STL ที่จะแสดงให้เห็นถึงการเลิกใช้งานโค้ดที่รวดเร็วและ debuggable

สำหรับโครงการส่วนบุคคลของฉันไม่ว่า STL จะเหมาะหรือไม่ขึ้นอยู่กับโครงการ ถ้าฉันกำลังพยายามทำงานที่ได้รับการปรับแต่งข้อมูลตามสไตล์ของ Mike Acton บางอย่างได้รับการปรับให้เหมาะสมกับหน่วยความจำและการเข้าถึงแคชฉันอย่างน้อยฉันก็จะคิดถึงโครงสร้างข้อมูลที่กำหนดเองของฉันเอง หากฉันสร้างต้นแบบอัลกอริทึมหรือการเล่นเกมและไม่สนใจประสิทธิภาพความสามารถในการปรับขยายแพลตฟอร์มเป้าหมาย ฯลฯ ฉันจะคว้า STL โดยอัตโนมัติ

— ทอมฮัดสัน
แหล่งที่มา

4

2 เซนต์ของฉันในเรื่องนี้คือ STL ทำงานได้ดี ฉันพัฒนาเอนจิ้นเกมสามมิติ (ไม่ใช่คุณภาพ AAA แต่ก้าวหน้ามากพอ - ประเภทเอนทิตีสคริปต์, ตัวเรนเดอร์ที่รอรับรู้, Bullet Bullet แบบรวม) สำหรับพีซีและฉันยังไม่เห็นว่าคอนเทนเนอร์กลายเป็นคอขวดหลัก การใช้ 3D API ที่ไม่ถูกต้องและอัลกอรึทึมที่แย่นั้นเป็นเป้าหมายที่ดีที่สุด (พิจารณาจากการทำโปรไฟล์!) ทุกครั้งที่ฉันเข้าไปข้างในและพยายามหาประสิทธิภาพที่เพิ่มขึ้นอีกเล็กน้อย

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

3

ฉันสร้างเกมโดยใช้ STL และฉันชอบและดูเหมือนว่าจะทำงานได้ดี

— เควินไลตี้
แหล่งที่มา

3

คำถามที่ดี! คำถามที่เฉพาะเจาะจงมากขึ้นคือข้อกำหนดทั่วไปที่เกมจะมีที่ไม่สามารถทำได้กับ STL และ Boost

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

นอกจากนี้การใช้เทมเพลตมากเกินไปอาจทำให้เวลาในการคอมไพล์นานมากและจะขยายขนาดของการปฏิบัติการของคุณเพื่อไม่ให้พอดีกับแคชของแคชแกนเสริมบน ps3 อีกต่อไป

อย่างไรก็ตามสำหรับการพัฒนาบนพีซีเท่านั้นฉันคิดว่า STL และ Boost นั้นดีมาก ในขณะที่การแก้ปัญหากรณีทั่วไปไม่เหมาะเสมอไป แต่ก็มักจะดีพอ วิธีแก้ไขปัญหาแรกของคุณแทบไม่เคยเป็นไปในอุดมคติและคุณปรับปรุงหรือแทนที่ความไม่เพียงพอจนกว่าจะดีพอ

— Evan Rogers
แหล่งที่มา

2

STL เหมาะสำหรับเกมของคุณถ้า STL เหมาะสมกับเกมของคุณ

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

ผู้คนไม่ควรหลีกเลี่ยงการใช้ STL ในเกมของพวกเขาเพราะคนอื่น ๆ หลีกเลี่ยงการใช้ STL ในเกม พวกเขาควรหลีกเลี่ยงการใช้มันหากพวกเขาชั่งน้ำหนักตัวเลือกทั้งหมดและพวกเขาเชื่ออย่างแท้จริงว่าการใช้งานอื่นจะปรับปรุงคุณภาพของผลิตภัณฑ์ของตน

— แบลร์ Holloway
แหล่งที่มา

2

ฉันเห็นด้วย 100% กับส่วนสุดท้ายของความคิดเห็นของคุณ แต่ฉันจะไปให้ไกลกว่านี้: หากคุณสามารถแสดงให้เห็นอย่างชัดเจนว่าทำไม STL ถึงไม่ใช่ตัวเลือกที่ดีอย่าใช้ STL มิฉะนั้นทำ Cargo ลัทธิ (ทุกอย่างจาก "โอ้ผู้พัฒนาเกมใช้ C ++!" ถึง "โอ้ผู้พัฒนาเกมไม่ได้ใช้ STL!") นั้นไม่แข็งแรง อย่างไรก็ตามฉันจะเอาประเด็นเล็กน้อยกับย่อหน้าที่สองของคุณ: มันไม่น่าเป็นไปได้เลยที่คนที่ยังไร้เดียงสามากพอที่จะคิดว่าการปรับใช้ STL นั้นเป็นความคิดที่ดีจะสร้างดีvectorกว่าคน STL ตามเวลาที่คุณสามารถทำได้คุณไม่คิดว่าคุณจะต้อง! :-)

— Ed Ropple

2

เช่นเดียวกับคำถามส่วนใหญ่คำตอบคือไม่เคย "ใช่หรือไม่ก็" สีดำหรือสีขาว STL เป็นแบบที่ดีสำหรับปัญหาบางอย่างใช้มันสำหรับปัญหาเหล่านั้นควรจะดี มันเป็นความผิดพลาดที่จะสมมติว่ามันไร้ประโยชน์ แต่ก็เป็นความผิดพลาดที่จะสมมติว่ามันเหมาะสมที่จะใช้ในทุกสถานการณ์

ปัญหาที่ใหญ่ที่สุดที่ต้องระวังเมื่อใช้ STL ในการพัฒนาเกมคือการจัดสรรหน่วยความจำ ผู้จัดสรรเริ่มต้นของ STL ดูเหมือนจะไม่เหมาะกับกลยุทธ์การจัดสรรที่ต้องการสำหรับการพัฒนาเกม แน่นอนว่าสามารถใช้ตัวจัดสรรแบบกำหนดเองได้ แต่สิ่งนี้ทำให้ความคิดทั้งหมดน่าสนใจน้อยลงหากคุณกำลังพิจารณาว่าจะเพิ่ม STL ลงในฐานข้อมูลที่ไม่ใช่ STL หรือไม่

เพิ่มในส่วนนี้หาก codebase ของคุณไม่ใช่แบบ STL คุณอาจไม่มีใครคุ้นเคยกับ STL หรือแนวคิดของเทมเพลตในการใช้งานตัวจัดสรรแบบกำหนดเองได้อย่างถูกต้อง

— แดนโอลสัน
แหล่งที่มา

2

ฉันคิดว่าการสนทนานี้สามารถสรุปได้ดังนี้

รหัส specfic แอปพลิเคชันที่เขียนแบบปานกลาง ๆ <รหัสวัตถุประสงค์ทั่วไปที่เขียนดี <รหัสเฉพาะแอปพลิเคชันที่เขียนอย่างดี

ทุกคนที่มีวิธีแก้ปัญหาที่บ้านจะตกอยู่ในหมวดหมู่ 3 แน่นอนรู้คำตอบสำหรับคำถามเดิมสำหรับปัญหาเฉพาะของพวกเขา STL อยู่ในหมวดที่ 2 ดังนั้นสำหรับคนที่ต้องการถามคำถาม " ฉันควรใช้ STL" คำตอบน่าจะใช่

2

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

— มุสตาฟาเอกิชิ
แหล่งที่มา

1

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

สิ่งที่ยอดเยี่ยมเกี่ยวกับซอฟต์แวร์ซึ่งแตกต่างจากสาขาวิชาอื่น ๆ คือคุณสามารถเปลี่ยนแปลงสิ่งต่าง ๆ ได้ในภายหลังหากคุณพบว่ามันไม่ทำงานตามที่คุณต้องการ คุณทราบภายหลังว่า STL ไม่ทำงานสำหรับคุณในโครงการนี้หรือไม่ ดึงมันออกมาใส่อย่างอื่นแทน ไม่ชอบวิธีแบ่งหน้าที่ระหว่างวัตถุของคุณหรือไม่ refactor ไม่ชอบที่คุณใช้วัตถุหรือไม่ แทนที่ด้วยวิธี C ตรง ไม่ชอบทุกสิ่งที่ถูกจัดเก็บใน structs และวิธีการจัดการพวกเขาใช่ไหม แทนที่ด้วยวัตถุ C ++

— เดนนิสมันซี
แหล่งที่มา

1

ในขณะที่คุณพูดถูกอาจมีบทลงโทษอย่างมากสำหรับการปรับโครงสร้างใหม่ ดังนั้นการตัดสินใจล่วงหน้าอย่างชาญฉลาดแทนที่จะเป็นการตัดสินใจโดยพลการจะช่วยให้คุณประหยัดเวลาในระยะยาว

— อลัน

1

ฉันพูดไม่ได้กับ STL เหตุผลของฉันค่อนข้างง่าย:

คุณไม่จำเป็นต้องใช้ STL เพื่อเขียนเกม ไม่ได้มีขนาดใหญ่
STL เพิ่มเวลาการคอมไพล์ของคุณอย่างมาก
เวลาในการรวบรวมจำนวนมากนำไปสู่การทำซ้ำน้อยกว่าการพัฒนาของคุณ

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

การทำซ้ำที่มีราคาสูงนำไปสู่ทีมพัฒนาขนาดใหญ่ของคนที่พยายามทำสิ่งต่างๆให้สำเร็จโดยที่เกิดขึ้นน้อยมาก ฉันเคยเห็นและได้ยินมันและหนึ่งในผู้ร้ายดูเหมือนจะรวบรวมเวลาสำหรับเทมเพลตไลบรารี

— ริชาร์ดเฟเบียน
แหล่งที่มา

1

ฉันเห็นด้วยเกี่ยวกับเวลารวบรวม เวลารวบรวมที่สำคัญใด ๆ จะเพิ่มปริมาณงานที่สูญเสียไปสองเท่า เช่นถ้าคอมไพล์ใช้เวลา 5 นาทีคุณจะใช้เวลา 10 นาทีในการรับกาแฟทุกครั้ง ;)

— Ipsquiggle

ในขณะที่ฉันเห็นการโต้แย้งทั้งสองด้านนี้ฉันต้องบอกว่าฉันเห็นด้วยอย่างยิ่งกับการโต้แย้งของคุณริชาร์ด +1

— วิศวกร