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

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?

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)

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ć.

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 ...

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.