3 ms·

I'm in the same camp. It makes porting difficult, indeed; but frankly, I'd use QThis and QThat over STL any day.

• drone 13y ago
  Interesting, I'm wondering how Qt types make porting more difficult? My experience has been that if I only used standard-C and Qt types, I had no issues in porting. A recent project I worked on only had a handful of platform checks (and all but one of them were in the project file), and compiled fine on all platforms. In fact, I developed it entirely on OSX first, and then simply adjusted the build to support the different OSes later, and didn't have a single problem. Mind you, I -only- used Qt standard libraries (except QExtSerialPort which was the best option for serial access at the time I started the project). I definitely agree with preferring Q-types to STL. Combined with Creator as an IDE, it's brain-dead simple and I spend my time on higher-level concerns. (FWIW, I wish Creator had more languages supported, I've never had such a wonderful experience in any other IDE. I want to shoot XCode every time I open it, mostly because Creator has spoiled me on how good auto-complete can be.)
  • xarball 13y ago
    KDevelop won my heart over QtCreator a while back. Templates.
  • weland 13y ago
    If you already have a codebase that's littered with STL, you need to make a few changes here and there. I was thinking about "porting your codebase to Qt", which isn't quite a correct usage. Sorry, it was kind of late in the evening :(.
• xarball 13y ago
  Exactly. Today I was astounded when I found out that passing NULL to std::string::operator=() results in a crash. Qt's QString and QByteArray classes run null checks on practically everything.
  • abcd_f 13y ago
    Why were you astounded? I don't think I follow.