On Tuesday 10 February 2015 23:17:21 Allan Sandfeld Jensen wrote: > Maybe with C++11 we don't need QString that much anymore. Use std::string > with UTF8 and std::u32string for UCS4. > > For Qt6 it would be worth considering how many of our classes still makes > sense. Those we want CoW semantics on would make sense, but if we don't > really want that on strings, maybe every framework having its own string > class is finally obsolete in C++?
Not as long as we have a rule stating we should not use the STL as part of our ABI. This allows us to keep binary compatibility even when the STL changes. For example, this allow to compile Qt with GNU's libstdc++ and an application using LLVM's libc++ (or vice-versa). It will also let Qt be compiled with GCC 4.9, and the application be compiled with GCC 5.0. Indeed, imagine we had something like QLabel::setText(std::string). The real symbol name is something like QLabel::setText(std::basic_string<...>) with current libstdc++, but with libc++ or GCC5.0, it would have a different name due to the different namespace (something like QLabel::setText(std::__1::basic_string<...>)) The symbol name would be different, and not found in the binary. And even if the namespace was the same, we would crash because the layout might be different. Of course, we can decide that using the STL containers is better and that we don't support binary compatibility accross different implementation of the std library. But anyway, we have no reason to discuss that at this point of time and we'll see when Qt6 comes. (Another thing to keep in mind is that we should probably use more of what we call QStringRef. I like the llvm::StringRef for example, or std::experimental::string_view. And in the mean time we still don't have QByteArrayRef) -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development