มุมอันตรายของ Qt คืออะไร? [ปิด]


10

ไม่มีอะไรสมบูรณ์แบบภายใต้ดวงอาทิตย์ Qt นั้นไม่มีข้อยกเว้นและมีข้อ จำกัด : เราไม่สามารถใช้ pixmaps ในเธรดอื่นนอกเหนือจาก GUI เราไม่สามารถใช้ QImage ด้วยรูปแบบภาพ 16 บิตต่อช่อง ฯลฯ

สถานการณ์ใดที่บังคับให้คุณต้องเสียการออกแบบเนื่องจากข้อ จำกัด ของ Qt
นิสัยใจคอที่เกลียดที่สุดคืออะไร?
การตัดสินใจออกแบบแบบใดที่ควรหลีกเลี่ยงขณะใช้ Qt ในโครงการของเขา


คุณสามารถพูดQt? ถ้าคุณขยาย to "เครื่องมือ" คุณสามารถเพิ่ม "ว่า" ในด้านหน้าของมัน แต่มันคือการแก้ไข / การปฏิบัติที่ดีที่จะพูดQt? แค่สงสัย.
Anto

@Anto: ฉันคิดว่าtheถูกผูกไว้กับcornersที่นี่ไม่ได้Qtแต่มันก็เป็นเพียงความรู้สึกที่ใช้งานง่ายของฉันตั้งแต่ฉันรัสเซีย :)
องุ่น

เส้นโค้งที่เป็นอันตรายอย่างหนึ่งที่เป็นไปได้คือโครงการอาจประสบปัญหาทางการเงิน Nokia เพิ่งลงนามในข้อตกลงกับ Microsoft (เพื่อใช้ Win7 บนโทรศัพท์ของพวกเขา) ซึ่งทำให้อนาคตของ Qt บนพื้นดินสั่นคลอน
Peter Rowell

ฉันสนใจที่จะรู้คำตอบนี้เพราะฉันเป็น noob to C ++ visual programming: D
Shaheer

@Vines: แล้ว "อะไรคือมุมอันตรายของ QT"
Chris

คำตอบ:


12

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

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

เมื่อ Qt เปลี่ยนจาก 3.x เป็น 4.x ทีมของเราต้องใช้เวลาเกือบ 9 เดือนในการทำพอร์ตในระหว่างนี้มีการเพิ่มฟังก์ชันการทำงานใหม่เล็กน้อย คุณหวังว่าจะใช้ต้นทุนการอัพเกรดที่สำคัญในการพัฒนาประสิทธิภาพที่เพิ่มขึ้นในเวลาที่เหลือ (หมายเหตุฉันไม่สนใจข้อดีของ Qt ซึ่งมีอยู่มากมาย)


2
พอร์ต Qt3 ถึง Qt4 นั้นยากสำหรับคนส่วนใหญ่ที่ฉันรู้จัก QML นี้และสิ่งที่คล้ายกันซึ่งได้รับการแนะนำในเวอร์ชั่นใหม่ทำให้ฉันกังวลเพราะอาจหมายถึงพอร์ตที่ซับซ้อนอีกครั้ง
Vitor Py

10

Qt ไม่ได้ใช้ไลบรารี C ++ มาตรฐานแต่มี QString ของตัวเอง, QVector, QMap, ...

ซึ่งหมายความว่าคุณต้องตัดสินใจออกแบบที่สำคัญ: ส่วนใดของแอปพลิเคชันที่จะใช้ QString และส่วนใดที่จะใช้ std :: string

ใช้ std :: string ในบางส่วนและ QString ในส่วนอื่น ๆ หมายความว่าคุณจะต้องแปลงระหว่างสตริง QString และ std :: ในขอบเขต

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

(โปรดทราบว่าเช่นเดียวกันกับ std :: map vs QMap, std :: vector vs QVector และอื่น ๆ )

การตัดสินใจว่าส่วนใดใช้ประเภทของ Qt และส่วนใดที่ใช้ STLเป็นการตัดสินใจออกแบบที่สำคัญโดยมีนัยสำคัญ และเนื่องจาก Qt ปฏิเสธที่จะใช้ libb C ++ มาตรฐาน

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


1
ฉันเห็นด้วย แต่ฉันจะออกไปที่ขอบและพูดว่า QString (ฯลฯ ฯลฯ ) ก็เป็นหนึ่งในจุดแข็งเพราะมันดีที่ได้ทำงานกับพวกเขา
Johan

1
นอกจากนี้ยังไม่ใช่เรื่องยากที่จะใช้ห้องสมุดที่ไม่ได้ใช้ QString มีวิธีง่าย ๆ ในการแปลง QString เป็น std :: string และในทางกลับกัน ไม่มากไป

@Glenn Nelson: ใช่ทุกวันนี้มีฟังก์ชั่นการแปลงสำหรับ QString; มีประโยชน์และสะดวกมาก! แต่โดยเฉพาะอย่างยิ่งสำหรับ QVector และ QMap จะมีค่าใช้จ่ายในการแปลง (และวิธีแก้ปัญหาอย่างง่ายจะไม่ทำงานเช่น QVector <QString>); ค่าโสหุ้ยนั้นควรได้รับการพิจารณาในระหว่างการออกแบบเพื่อหลีกเลี่ยงปัญหาด้านประสิทธิภาพในบรรทัด
Sjoerd

3

นี่ไม่ได้ตอบคำถามโดยตรง แต่ฉันคิดว่ามันควรค่าแก่การกล่าวถึง: บางทีสิ่งที่อันตรายที่สุดของ Qt คือ Nokia ได้เข้านอนกับ MSoft ...


2
แต่พวกเขาละทิ้ง Qt เพื่อทำมัน
Martin Beckett

1
เพื่อความสมบูรณ์ - ส่วนการค้าของ Qt ปัจจุบันเป็นเจ้าของโดย Digia ในขณะที่ Qt ได้ย้ายไปยังระบบของ "การกำกับดูแลแบบเปิด" ที่ผู้อื่นสามารถมีส่วนร่วมได้อย่างง่ายดาย นอกจากนี้ยังมีรากฐาน QT ของ KDE Free ซึ่งป้องกัน Qt จากการปิดแหล่งที่มา
Vishesh Handa

2

เมื่อเร็ว ๆ นี้ฉันพบว่า QChar แม้จะมีชื่อของมันไม่สอดคล้องกับตัวละครตัวหนึ่ง แต่กับหน่วยรหัส UTF-16 ดังนั้นเมื่อคุณต้องการสแกนอักขระข้อความ Unicode ตามตัวอักษรคุณต้องเพิ่มอัลกอริธึมสำหรับการจัดการกับตัวแทนสูงและต่ำรวมตัวละครและสิ่งที่คล้ายกัน

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