Guys, this thread is for QStringView. Could we keep it on-topic, please? There are more than enough bits floating around to create your own threads (with a tip of the hat to Kai).
Thanks, Marc On Thursday 15 October 2015 23:02:09 Bubke Marco wrote: > On October 15, 2015 00:27:45 Thiago Macieira <thiago.macie...@intel.com> wrote: > > On Wednesday 14 October 2015 21:51:23 Bubke Marco wrote: > >> On October 14, 2015 23:10:26 Thiago Macieira <thiago.macie...@intel.com> > > > > wrote: > >> > Do it on your own. You just said that ICU has the function you want, > >> > so use > >> > it. > >> > >> So Qt is always shipping with ICU? > > > > It can be disabled on Windows. On OS X there's no point since it's part > > of the system. On Linux, if you disable it, you're going to have some > > other features reduced, so don't disable it. > > > >> > Qt does not have to provide a comparator that operates on something > >> > other than its native string type. > >> > >> Isn't Qt a framework to help developers? Sorry your argumentation is > >> sounds not very empirical. > > > > Yes, it is. But Qt's goal is not to support every single use-case and > > corner- case out there. Qt should make 90% easy and 9% possible. That > > means there's a 1% of the realm of possibilities that Qt does not > > address. If your use-case calls into this group, use the fact that Qt is > > native code and just call other libraries. > > Actually I think Qt is not main developing library people use. It is there > to make the boring stuff easy, to hide the different interfaces between > different platforms. That is why many people use Qt, they want to have a > GUI but don't want to invest to much time in it. The interesting stuff > which is differentiating you from others is mostly home grown in > connection with much more specialized libraries. And this libraries are > much more important to the users. So we should support them, their > interfaces and not force our interfaces on them. How many users use the > standard library too, especially the new features, why don't we support > them not much better. Why do we have to reinvent the wheel again and > again. I know binary compatibility is important for you but is it really > that important outside of the special linux distribution cocoon. Is it > important under Windows, is it important under Mac, is it important under > embedded Linux? I think the advantages are smaller than the drawbacks. > > > That's one of the two main advantages of native code. There's no sandbox > > to escape from. > > > > Qt already supports doing locale-aware comparison. We even have a class > > for it, so it can be done efficiently: QCollator and it supports our > > native string type (QString). > > Do you like to live on a native island? > > > Providing extra support for a character encoding that is not what QString > > uses falls in that 1%. Just use ICU. > > You arguments sounds very tautological. Because it is unimportant we don't > have it a string class for it. It is unimportant because QString is not > supporting it. > > I know you love plationian argumentation but it would be much more > effective if you would try to get in the context of other and understand > their arguments in their context. Showing in your own context that their > arguments "makes no sense" is not very useful. > > >> Lets describe an example. I send the QTextDocument content to an library > >> which expect utf8 content and gives me back positions. This gets > >> interesting if you use non ASCII signs. Actually the new clang code > >> model works that way. > > > > That example shows how UTF-16 is better. See above on seekability of > > UTF-16 vs UTF-8. > > > > The solution for this is to fix the library to accept UTF-16. When we > > were doing Qt 5.0, we needed PCRE to support UTF-16. Their developers > > were very welcoming and wrote the version that supports UTF-16, so Qt > > does not need to reallocate. > > You have ever heard of Pippi Longstocking: "Widdiwiddiwitt, we make the > world like we wish it should be. " or how it is translated to english. > You really think that you can force other larger projects to use utf16 > instead of utf8 if it has disadvantages for them. > > And the PCRE is now supporting both at runtime? Especially for large text > it would be very helpful if you don't need to convert them to QString > before you use regular expressions on it. > > >> > Even if we provide UTF-8 support classes, those will not propagate to > >> > the GUI. Forget it. > >> > >> What about compressing UTF 16 like python is doing it for UTF 32. If you > >> are only using ascii you set a flag and you can remove all that useless > >> zeros. It would be have implications for data() but maybe we should not > >> provide access to the internal representation. If you use UTF 32 as a > >> base you don't need anymore surrogates. > > > > That's what Lars called a "hybrid solution" and vetoed. I second that. > > > > Way too much code would break if we did that because we allow people > > access to the data pointer in QString and to iterate directly > > (std::{,w,u16}string don't allow that, which makes parsing them actually > > a lot more cumbersome). > > I don't see the disadvantage if you have special iterators. That is the > power of iterators and with the new features of C++ they get really > useful. But anyway, I don't say that we have to change everything. The > last time we did that we broke our event system which is still not working > like it was before we introduced QWindow. I think we should have an > evolutionary process to adapt to the changing environment and not try to > reiterate what was successful in the past. > > And we should memory why we have done things and if that decision would be > the same today. And in the end we have to decide if it is worth to change > that decision again. _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development