Jakie są niebezpieczne zakątki Qt? [Zamknięte]

10

Pod słońcem nie ma nic idealnego. Qt nie jest wyjątkiem i ma ograniczenia: nie możemy używać pixmap w wątku innym niż GUI, nie możemy używać QImage z formatem obrazu 16-bit na kanał itp.

Które sytuacje zmusiły cię do zepsucia projektu z powodu ograniczeń Qt?
Jakie są najbardziej znienawidzone dziwactwa?
Jakich decyzji projektowych należy unikać podczas korzystania z Qt w jego projektach?

qt design-decisions

— winorośl
źródło

Można powiedzieć w Qt? Jeśli go rozwinąć do „Q Toolkit”, można dodać „the” przed nim, ale jest to poprawić / dobrych praktyk powiedzieć o Qt? Po prostu ciekawy.

— Anto

@Anto: Przypuszczam, że thejest cornerstutaj związany , nie Qt, ale to tylko moje intuicyjne wyczucie, ponieważ jestem Rosjaninem :)

— winorośl

Jedną z możliwych niebezpiecznych krzywych jest to, że projekt może mieć kłopoty finansowe. Nokia niedawno podpisała umowę z Microsoftem (na Win7 na swoich telefonach), która stawia przyszłość Qt na niepewnym gruncie.

— Peter Rowell,

jestem bardzo zainteresowany poznaniem tej odpowiedzi, ponieważ jestem noob programowania w języku C ++: D

— Shaheer

@Vines: Co powiesz na „Jakie są niebezpieczne zakątki QT?”?

— Chris

12

Jak na ironię powiedziałbym, że moc Qt jest również jedną z wad. Jest tak wiele potężnych konstrukcji i rozszerzeń, że kod, który piszesz w Qt, łatwo się mocno zakorzenia w „sposób Qt”. Próba wyodrębnienia funkcjonalności w innym języku oznacza nie tylko ponowne napisanie, musisz znać wiele technologii specyficznych dla Qt.

Szerokość Qt oznacza, że zatrudnienie programistów oznacza albo zaangażowanie kogoś, kto ma doświadczenie w Qt, albo szkolenie w zakresie tej wiedzy. Przyspieszenie i przyspieszenie kontrahenta jest trudniejsze niż waniliowe C ++.

Kiedy Qt zmieniło się z 3.x na 4.x, nasz zespół potrzebował prawie 9 miesięcy na wykonanie portu, w tym czasie dodano niewiele nowych funkcji. Masz nadzieję, że do końca nadrobisz ten znaczny koszt aktualizacji w celu zwiększenia wydajności rozwoju. (Uwaga, pominąłem zalety Qt, których jest również wiele)

— James Creasy
źródło

2

Port Qt3 do Qt4 był trudny dla większości ludzi, których znam. Martwię się tym QML i podobnymi rzeczami, które zostały wprowadzone w nowszych wersjach, ponieważ może to oznaczać kolejny skomplikowany port.

— Vitor Py

10

Qt nie korzysta ze standardowej biblioteki C ++ , ale ma własną QString, QVector, QMap, ...

Oznacza to, że musisz podjąć ważną decyzję projektową: które części aplikacji będą używać QString, a które części będą używać std :: string?

Użycie std :: string w niektórych częściach i QString w innych częściach oznacza, że będziesz musiał przekonwertować między QString i std :: string na granicach.

Aby uniknąć tego narzutu, można zdecydować się na użycie QString w całej aplikacji. Ale to znacznie utrudnia korzystanie z bibliotek stron trzecich, które nie są oparte na Qt, np. Boost.

(Należy zauważyć, że to samo dotyczy std :: map vs QMap, std :: vector vs QVector itd.)

Decyzja, które części wykorzystują typy Qt, a które wykorzystują STL, jest ważną decyzją projektową, mającą poważne konsekwencje. I tylko dlatego, że Qt odmawia użycia standardowej biblioteki C ++.

IMHO, ta decyzja może pójść w obie strony, w zależności od projektu. Nie mogę więc odpowiedzieć na pytanie, którego należy unikać.

— Sjoerd
źródło

1

Zgadzam się, ale chciałbym powiedzieć, że QString (itp.) Jest również jedną z mocnych stron, ponieważ miło jest z nimi pracować.

— Johan

1

Ponadto nie jest wcale tak trudno korzystać z biblioteki, która nie korzysta z QString. Istnieje prosta metoda konwersji QString na std :: string i odwrotnie. Niewiele.

@Glenn Nelson: Tak, obecnie istnieją funkcje konwersji QString; bardzo przydatne i wygodne! Ale szczególnie w przypadku QVectora i QMapy będzie występować narzut podczas konwersji (a proste rozwiązania nie będą działać np. Dla QVectora <QString>); Narzut ten należy wziąć pod uwagę podczas projektowania, aby uniknąć problemów z wydajnością w dalszej linii.

— Sjoerd,

3

To nie odpowiada bezpośrednio na pytanie, ale myślę, że warto o tym wspomnieć: być może najbardziej „niebezpiecznym” aspektem Qt jest to, że Nokia weszła do łóżka z MSoft ...

— Wektor
źródło

2

Ale porzucili Qt, aby to zrobić.

— Martin Beckett,

1

Dla kompletności - część komercyjna Qt jest teraz własnością Digia, podczas gdy Qt przeszedł na system „otwartego zarządzania”, w którym inni mogą z łatwością wnieść swój wkład. Istnieje również podstawa KDE Free Qt, która chroni Qt przed zamknięciem źródła.

— Vishesh Handa

2

Niedawno dowiedziałem się, że QChar, pomimo swojej nazwy, w rzeczywistości nie odpowiada jednemu znakowi, ale jednostce kodu UTF-16. Tak więc, jeśli chcesz skanować dowolny znak tekstowy Unicode po znaku, musisz dodać algorytmy do radzenia sobie z wysokimi i niskimi surogatami, łączenia znaków i tym podobnych.

— Sebastian Negraszus
źródło