เหตุใดห้องสมุดสมัยใหม่จึงไม่ใช้ OOP

20

ฉันเป็นโปรแกรมเมอร์ C ++ ระดับต้น แต่ฉันเข้าใจแนวคิดของภาษาค่อนข้างดี เมื่อฉันเริ่มเรียนรู้ไลบรารี C ++ ภายนอกเช่น SDL, OpenGL (อาจเป็นอย่างอื่น) ด้วยความประหลาดใจที่ยิ่งใหญ่ของฉันฉันพบว่าพวกเขาไม่ได้ใช้แนวคิด C ++ เลย

ตัวอย่างเช่นทั้ง SDL และ OpenGL ไม่ใช้คลาสหรือข้อยกเว้นเลือกฟังก์ชั่นและรหัสข้อผิดพลาด ใน OpenGL ฉันเคยเห็นฟังก์ชั่นเช่น glVertex2f ซึ่งใช้ตัวแปรลอย 2 ตัวเป็นอินพุตและน่าจะดีกว่าเทมเพลต นอกจากนี้บางครั้งห้องสมุดเหล่านี้ใช้มาร์กอสในขณะที่ดูเหมือนว่าเป็นข้อตกลงทั่วไปที่ใช้มาโครไม่ดี

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

คำถามคือเหตุใดห้องสมุดสมัยใหม่จึงไม่ใช้ข้อดีของภาษาที่เขียน

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

1

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

— Jeanne Boyarsky

5

นอกจากนั้นแล้วทั้ง OpenGL และ "ทันสมัย" ในแง่ที่ว่าพวกเขายังเด็กหรืออย่างน้อยก็สามารถนำมาใช้ใหม่ faetures แฟนซี ทั้งสองมีประวัติอันยาวนาน (OpenGL 1.1: 1997; SDL: 1998) และข้อ จำกัด ด้านความเข้ากันได้ย้อนหลัง

1

เพียงแค่มีการกล่าวว่า: DirectX เป็นสิ่งที่ถกเถียงกันมากขึ้น (หากระดับต่ำลงไปอีกหน่อย)

— cHao

1

ไลบรารี Native C ++ เช่น stl และ Boost อย่าใช้แนวคิด OOP ที่ล้าสมัยและไร้ประโยชน์เช่นกัน

— SK-logic

5

ฉันคิดว่าคุณเข้าใจผิดนี่คือ SDL และ OpenGL เป็นตัวแทนของ "ห้องสมุดที่ทันสมัย" มากมาย ยกตัวอย่างเช่นไลบรารี่ Qt ที่เป็นที่นิยมอย่างมากนั้นจะมีการวางอ็อบเจกต์อย่างสมบูรณ์ ชื่อคำถามของคุณดีขึ้นควรเป็น "ทำไม SDL และ OpenGL ไม่ใช้ OOP"

— Doc Brown

31

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

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

ในขณะที่ C และ C ++ เป็นภาษาที่แตกต่างกันมากพวกเขาไม่ใช่ "ไม่เข้ากัน" ในความเป็นจริง C ++ เป็น superset ขนาดใหญ่ C มีความเข้ากันไม่ได้บางอย่าง แต่ไม่มากดังนั้นการใช้ C อินเตอร์เฟสจาก C ++ เป็นสิ่งที่ง่ายมาก ทำ.

— Timo Geusch
แหล่งที่มา

อ้อเข้าใจแล้ว. ถ้าอย่างนั้นคำถามต่อไป: มีพูดห้องสมุดกราฟิกสำหรับ C ++ ที่มีประสิทธิภาพเป็น OpenGL? หรืออาจเป็น wrapper มากกว่า OpenGL ที่ใช้ข้อดีทั้งหมดของ C ++ และให้การจัดการทรัพยากรที่ดี? API จะดูสะอาดตากว่าเดิมและฉันไม่คิดว่าโอเวอร์เฮดของหน่วยความจำ / cpu จะสูงเกินไป

— Saage

มีประสิทธิภาพหรือมีประสิทธิภาพ ไม่ว่าจะด้วยวิธีใดก็ควรหาตัวห่อหุ้ม C ++ สำหรับ SDL หรือ OpenGL อย่างง่ายดาย Google ฉบับย่อนำเสนอ wrapper นี้สำหรับ OpenGL: oglplus.org - ไม่รู้ว่ามันดีแค่ไหนฉันไม่ได้ใช้

— Timo Geusch

1

ใช่มีโครงการไม่กี่แห่งที่พยายามล้อม OpenGL ด้วยอินเทอร์เฟซ C ++ ish เพิ่มเติม (ฉันมีตัวเองด้วยซ้ำถึงแม้ว่าฉันจะละเว้นคุณลักษณะหลายอย่างและเพิ่มการโอเวอร์โหลดและส่วนใหญ่) ความประทับใจของฉันคือการเพิ่มสัมภาระจำนวนมากซึ่งทำให้ยากต่อการแปลตัวอย่างของ OpenGL ที่บริสุทธิ์และยากที่จะใช้การเพิ่มประสิทธิภาพมาตรฐาน (มองหาการออกแบบที่เน้นข้อมูล; บางเกม devs สาบาน) แต่โดยทั้งหมดแล้วอย่าปล่อยให้สิ่งนั้นขัดขวางคุณ หรือคุณอาจโชคดีกว่าในการใช้เอนจิ้นเกมทั้งหมด (เช่น Irrlicht หรือ Ogre) แทนที่จะเป็น API กราฟิคเปลือย

เอาล่ะฉันคิดว่าฉันมีคำตอบทั้งหมดที่ฉันต้องการ ขอบคุณทุกคน!

— Saage

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

— David Cowden

10

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

C และ C ++ ไม่ใช่ระบบที่ต่างกันโดยสิ้นเชิง C ++ ถูกสร้างขึ้นที่ด้านบนของ C และ a) สามารถใช้รหัส C และ b ได้อย่างง่ายดาย) สามารถให้ API แบบ C ได้อย่างสมบูรณ์
ข้อได้เปรียบของส่วนต่อประสาน C คือสามารถบริโภคได้ง่ายในส่วนอื่น ๆ ของโลก มีเลเยอร์ interop ที่อนุญาตให้ใช้ C API จากภาษาใดก็ได้ (python, java, c #, php ... ) ซึ่งเป็นส่วนต่อประสาน C ++ ที่สามารถใช้ได้จาก ..... ดีบางที C ++ และยังไม่เสมอไป ( คอมไพเลอร์ต่างกันคอมไพเลอร์รุ่นเดียวกันต่างกันจะทำให้เกิดปัญหา)

ในอดีตการทดลองในหนึ่งในโครงการที่ทำงานฉันตัดสินใจที่จะเปิดเผยส่วนติดต่อ "OO" จาก C ++ DLL เพื่อซ่อนรายละเอียดภายในและหลีกเลี่ยงสิ่งอื่น ๆ ฉันเกือบจะจบลงด้วยการสร้าง Windows COM ขึ้นมาใหม่ (โมเดลวัตถุส่วนประกอบ) หลังจากโปรเจ็กต์นั้นฉันรู้ว่า COM นั้นไม่เลวร้ายอย่างที่คนทำกันเพราะ a) มันเปิดเผยอินเตอร์เฟส OOP, b) ดูแลทุกปัญหาที่ฉันพบและ c) เป็นมาตรฐานพอที่จะสิ้นเปลืองจากจำนวน ภาษาอื่น ๆ.

แต่ COM ก็ยังไม่ได้โดยไม่มีสัมภาระ ในหลายกรณีปกติ C-style API แผนยังคงเป็นทางเลือกที่ดีกว่ามาก

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

7

ทั้ง OpenGL และ SDL เป็นไลบรารี C ไม่ใช่ไลบรารี C ++ คุณสามารถใช้พวกเขาจาก C ++ แต่พวกเขาเขียนใน C และมี C API (ซึ่งสามารถเข้าถึงได้จากภาษาอื่น ๆ C ++ เป็นความเจ็บปวดในการเข้าถึงผ่าน FFI) ดูBoostสำหรับชุดเอนกประสงค์ขนาดใหญ่ (และบางอัน) ไลบรารี C ++ และSFMLสำหรับไลบรารี่มัลติมีเดีย C ++

3

เมื่อพูดถึง OpenGL โดยเฉพาะ OpenGL เดิมเป็นส่วนหนึ่งของ APIs - OpenGL มี API ระดับต่ำประสิทธิภาพที่เข้าถึงได้จาก C (หรือ Fortran) ในขณะที่ OpenInventor มี API เชิงวัตถุระดับสูงที่ออกแบบมา ที่จะใช้จาก C ++ และจัดเตรียมทั้งซีนซีนกราฟระดับสูงและ abstractions สำหรับการบันทึก / อ่านฉากไปยัง / จากไฟล์และการรวม GUI

จบลงด้วย OpenGL ไกลเกินกว่า OpenInventor (เต็มไปด้วยความต้องการเร่งด่วนทำให้ผู้ผลิตฮาร์ดแวร์วิดีโอสามารถปรับให้เหมาะสมและจัดหา API ระดับต่ำที่คนทั่วไปสามารถกำหนดเป้าหมายได้แทนที่จะจัดการกับฮาร์ดแวร์เร่งความเร็ว 3 มิติโดยตรง) แต่ OpenInventor ยังคงอยู่ที่นั่นและมีการใช้งานโอเพนซอร์ซที่ดี - Coin3D - พร้อมรองรับ Unix / X11, Windows และ MacOS X / Cocoa

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

-2

ห้องสมุดเหล่านั้นไม่ได้ทันสมัยจากระยะไกลเลย พวกมันคือ C APIs และตัวร้ายนั้น หลักฐานของคุณมีข้อบกพร่อง

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

OpenGL ไม่ทันสมัยอย่างไร

— James

1

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

— 1118321