Re: [Development] Qt LTS C++11 plans (CopperSpice)
On 6/30/15 1:01 PM, Thiago Macieira wrote: On Tuesday 30 June 2015 09:37:59 Ansel Sermersheim wrote: Our goal with CopperSpice is to use modern C++ internally to leverage everything we can from the language. We want developers of CopperSpice applications to have the full power of C++ available in all parts of their code. For example, with moc removed we support template classes that inherit from QObject. We support passing method pointers as signal arguments. You need to use -fvisibility-inlines-hidden and retry. I don't think your solution works under those circumstances. As we mentioned we have already changed parts of the CopperSpice registration system. This will be released within the next month or so. We are definitely aware of -fvisibility-inlines-hidden, and we will look into supporting it. We are going to fully support exceptions, and make exception safety guarantees where possible. Unless you're going to rewrite the entire GUI, widgets, networking and other libraries from scratch, you're not going to get exception-safety. Yes, many parts will need to be redone and we are starting with the container classes. These are some of the limitations that frustrated us when using Qt in an existing codebase. You're making trade-offs. One of them, given your presentation, is that there's no current version of MSVC that will work with your codebase. Another is that you're replacing a code generator by a lot of boilerplate macros. We do not feel that requiring a compiler to support C++11 is unreasonable. Our main issues with MSVC is with constexpr and expression SFINAE. MS has added partial support of constexpr for MSVC 2015, although they are still reported to have a few issues. They will get there eventually. No word yet on when expression SFINAE will be added. Yes, we make use of macros as macros were intended to be used. We strongly believe the syntax for our macros is concise and clean, and that this tradeoff is worthwhile. Ansel CopperSpice Co-Founder www.copperspice.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On Wednesday 01 July 2015 00:49:19 Olivier Goffart wrote: On Tuesday 30. June 2015 22:37:24 Bernhard wrote: For example, with moc removed we support template classes that inherit from QObject. Wow. I would (almost) kill for having that feature in Qt! You can do that with moc. https://codereview.qt-project.org/49864/ There was a discussion about it on the mailinglist at the time, but nobody expressed much interest in having that feature. The feature is probably affected by the -fvisibility-inlines-hidden issue too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On Tuesday 30 June 2015 19:40:55 Ansel Sermersheim wrote: Unless you're going to rewrite the entire GUI, widgets, networking and other libraries from scratch, you're not going to get exception-safety. Yes, many parts will need to be redone and we are starting with the container classes. You may be underestimating the effort required. You'll need to spend a couple of man-decades of work to get this done... These are some of the limitations that frustrated us when using Qt in an existing codebase. You're making trade-offs. One of them, given your presentation, is that there's no current version of MSVC that will work with your codebase. Another is that you're replacing a code generator by a lot of boilerplate macros. We do not feel that requiring a compiler to support C++11 is unreasonable. Our main issues with MSVC is with constexpr and expression SFINAE. MS has added partial support of constexpr for MSVC 2015, although they are still reported to have a few issues. They will get there eventually. No word yet on when expression SFINAE will be added. And that's where we disagree. We feel that we have to be pragmatic and support compilers that people have access to. This is exactly why this thread started. I'm not saying you can't do what you're doing. I'm simply saying it's a trade- off. You're trading a potentially large userbase for the ability to use those C++11 features. Yes, we make use of macros as macros were intended to be used. We strongly believe the syntax for our macros is concise and clean, and that this tradeoff is worthwhile. No doubt you do. But I still disagree. My opinion is that a code generator is far preferable to boilerplate macros. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans
On Friday 26. June 2015 08:41:11 Thiago Macieira wrote: On Friday 26 June 2015 11:59:11 Olivier Goffart wrote: However, it is questionable if even this works. We already rely on the standard library ABI in QException. And most users will have to recompile everything if they want to change standard library anyway. std::exception is compatible between libc++ and libstdc++, so that doesn't count. Ok. (But by luck... another version might not) Anyway, you did not answer the actual question. Are you against changing the policy or not? -- 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
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On 6/29/15 11:37 PM, Alejandro Exojo wrote: El Tuesday 30 June 2015, Ansel Sermersheim escribió: Our September release of CopperSpice will include changes to the contain library, reimplementation of atomic types, our new changes to the MetaObject System registration, full API documentation, ?? We would like to encourage developers to attend CPPCon to learn about modern C++ and where it is going. For more information please check out the following video. http://cppcon.org/2015promo/ Can you explain which are your long term plans? Given that you renamed all the classes and modules (or so I understood), this is full source incompatible, and it doesn't seem like you want to sync again with the original Qt (applications might include a large file full of typedefs, but applying to CopperSpice any bugfix patch found in Qt seems completely manual). Some developers experiment with their own branches to research or have fun, which is great, but seems like you are aiming to be a full new project. We renamed the libraries to avoid naming conflicts with the Qt libraries when CS and Qt are installed on the same system. We have not renamed the classes, and our intention is to keep source compatibility as much as possible. Some incompatible changes were unavoidable, particularly the signal / slot declaration syntax. Our goal with CopperSpice is to use modern C++ internally to leverage everything we can from the language. We want developers of CopperSpice applications to have the full power of C++ available in all parts of their code. For example, with moc removed we support template classes that inherit from QObject. We support passing method pointers as signal arguments. We would like to support multiple inheritance properly. We would like the CsGui classes to work seamlessly with STL containers, and to add things like reverse iterators to the CS container library to bring it in line with the STL. We are going to fully support exceptions, and make exception safety guarantees where possible. We are working on redesigning the QObject lifetime model so that it works smoothly with C++11 smart pointers. These are some of the limitations that frustrated us when using Qt in an existing codebase. Thank you very much for your question, Ansel Sermersheim CopperSpice Co-Founder www.copperspice.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
For example, with moc removed we support template classes that inherit from QObject. Wow. I would (almost) kill for having that feature in Qt! -- Regards Bernhard Lindner ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Non C++11 compilers
On Tuesday 30 June 2015 22:57:32 Jason H wrote: I was perusing the archive of this list so I would know what to expect tomorrow and saw that there was a suggestion to drop non C++11 compilers. Hello Jason Your discussion is better held in the developer mailing list. I'm Cc'ing it. Please drop the releasing mailing list when replying. As a former embedded developer, I have to be concerned about that. A number of legacy software projects in the embedded space have ancient compilers in the BSP (board support packages). The project I was formerly a part of had code from 1992, released in 1994 on a 68000, and had been ported through the years to various AMX-ish RTOSes. The code base is still alive and well, having been ported to a PPC 832e and now later PPC chip. I had been working on modernizing the code base to eventually port the GUI to Qt. This project has seen exactly 2 changes to the compilers in the 20 years it's been on the market. Both Metrowerks (Now Freescale). Do they use Qt 5.4 right now? When are they considering upgrading to Qt 5.7? While it may not be 'cool' or 'hip' I'd caution against the dropping of non C++11 compilers. These legacy systems are still out there. I don't know how anecdotal my experience is of other projects, but it was a $8B USD company. I know these systems aren't that sexy when a TI ARM7 has a GPU on it, and can be had for dollars, but I think plenty are out there. That boat has sailed. We will adopt C++11 in 2016. Meanwhile I've never used any C++11 feature, or typed any line of C++11 code. I personally am against the idea of C++11, as it fractures the code base of C++ into C++98 and C++11. I use Qt because it compiles everywhere and gets me past the limitations of C++98 in an easy way. I won't be able to do that if Qt drops C++98 support. So in summary, I think dropping C++98-only compilers will significantly detract from Qt features in unanticipated ways. We've considered all of that. We don't agree with your assessment. Of the compilers we support right now, only MSVC 2008 and 2010 have limited C++11 support. We'll also drop a few releases of GCC, all of them more than 5 years old by the time of the Qt 5.7 release. So we're talking about dropping those compilers only, after an LTS release. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On Tuesday 30 June 2015 09:37:59 Ansel Sermersheim wrote: Our goal with CopperSpice is to use modern C++ internally to leverage everything we can from the language. We want developers of CopperSpice applications to have the full power of C++ available in all parts of their code. For example, with moc removed we support template classes that inherit from QObject. We support passing method pointers as signal arguments. You need to use -fvisibility-inlines-hidden and retry. I don't think your solution works under those circumstances. We are going to fully support exceptions, and make exception safety guarantees where possible. Unless you're going to rewrite the entire GUI, widgets, networking and other libraries from scratch, you're not going to get exception-safety. We are working on redesigning the QObject lifetime model so that it works smoothly with C++11 smart pointers. I researched that 4 or 5 years ago and I found two problems: First, you must either choose to use smart pointers everywhere or not at all. You can't pick and choose, which is what caused most of the problems. Second, and most importantly, all the QWidget-derived classes share state with their parent widgets. You MUST delete the children when the parent is getting deleted, which is incompatible with smart pointers. Like I said above for exceptions, you'll need to redesign the entire stack to get support for smart pointers here. These are some of the limitations that frustrated us when using Qt in an existing codebase. You're making trade-offs. One of them, given your presentation, is that there's no current version of MSVC that will work with your codebase. Another is that you're replacing a code generator by a lot of boilerplate macros. And, critically, like I mentioned above, is that I don't think your solution works with -fvisibility-inlines-hidden, due to taking and comparing addresses of inline functions. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans
On Tuesday 30 June 2015 18:16:34 Olivier Goffart wrote: On Friday 26. June 2015 08:41:11 Thiago Macieira wrote: On Friday 26 June 2015 11:59:11 Olivier Goffart wrote: However, it is questionable if even this works. We already rely on the standard library ABI in QException. And most users will have to recompile everything if they want to change standard library anyway. std::exception is compatible between libc++ and libstdc++, so that doesn't count. Ok. (But by luck... another version might not) s/luck/design/ Anyway, you did not answer the actual question. Are you against changing the policy or not? I am, for several reasons. For the container types, please use the Qt ones, for API consistency and familiarity. I don't want to see API using std::vector, period. Since we're talking about *ABI*, it stands to reason we're talking about mandatory features, so outside of any #ifdefs that may change between Qt's build and the user application's. That means any such feature depending on a C++11 library feature should be protected by a configure-time check and a #define in qconfig.h. Given our horrible configure script and configure.exe source code, writing such checks are difficult and time-consuming. More likely than not, we'll get it wrong. And finally, I am against it because libc++ and libstdc++ co-existence is still a goal, even on OS X. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On Tue, Jun 30, 2015 at 10:01 PM, Thiago Macieira thiago.macie...@intel.com wrote: You're making trade-offs. One of them, given your presentation, is that there's no current version of MSVC that will work with your codebase. Another is that you're replacing a code generator by a lot of boilerplate macros. Visual Studio 2015 will have constexpr fixed [1] and it should compile CopperSpice. The replacement of qmake with autotools in CopperSpice makes things very hard to test with Visual Studio. It seems CMake is being under evaluation [2]. The combination of CMake and ninja is quite effective. Cheers, Cristian. [1] http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17-features-in-vs-2015-rc.aspx [2] http://forum.copperspice.com/viewtopic.php?f=10t=7 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On 6/29/15 10:59 PM, Thiago Macieira wrote: On Monday 29 June 2015 22:51:25 Ansel Sermersheim wrote: I would like to clarify, we did not use anything from the Woboq blog posting as others have speculated. We had moc removed from CopperSpice a year earlier than the release of this blog. We are also not associated with the Trinity Project. Out of curiosity: You've removed moc, but what's your replacement for rcc? I hope I understand your question correctly. By removing moc and not using qmake, we were able to remove all the bootstrap code from CsCore. This allowed us to build rcc simply linking with CsCore. We did not see any reason to replace rcc at this time. Our goal was to allow developers to use CopperSpice without altering their build systems. Since the resource system is not mandatory we did not feel like an alternative to rcc was required. We would like to encourage developers to attend CPPCon to learn about Maybe Meeting C++ will get better luck. Most of the Qt developers live in Europe. I encourage you to submit your session there. By the way, you're also welcome to discuss your ideas in this mailing list. We're not against new C++ techniques, but we want to support existing deployments, so we have to be a little more pragmatic on our choices. Thank you for your warm welcome and encouragement. Ansel Sermersheim CopperSpice Co-Founder www.copperspice.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On Monday 29 June 2015 22:51:25 Ansel Sermersheim wrote: I would like to clarify, we did not use anything from the Woboq blog posting as others have speculated. We had moc removed from CopperSpice a year earlier than the release of this blog. We are also not associated with the Trinity Project. Out of curiosity: You've removed moc, but what's your replacement for rcc? We would like to encourage developers to attend CPPCon to learn about Maybe Meeting C++ will get better luck. Most of the Qt developers live in Europe. I encourage you to submit your session there. By the way, you're also welcome to discuss your ideas in this mailing list. We're not against new C++ techniques, but we want to support existing deployments, so we have to be a little more pragmatic on our choices. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
El Tuesday 30 June 2015, Ansel Sermersheim escribió: Our September release of CopperSpice will include changes to the contain library, reimplementation of atomic types, our new changes to the MetaObject System registration, full API documentation, ?? We would like to encourage developers to attend CPPCon to learn about modern C++ and where it is going. For more information please check out the following video. http://cppcon.org/2015promo/ Can you explain which are your long term plans? Given that you renamed all the classes and modules (or so I understood), this is full source incompatible, and it doesn't seem like you want to sync again with the original Qt (applications might include a large file full of typedefs, but applying to CopperSpice any bugfix patch found in Qt seems completely manual). Some developers experiment with their own branches to research or have fun, which is great, but seems like you are aiming to be a full new project. -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On Tuesday 30 June 2015 23:09:59 Cristian Adam wrote: On Tue, Jun 30, 2015 at 10:01 PM, Thiago Macieira thiago.macie...@intel.com wrote: You're making trade-offs. One of them, given your presentation, is that there's no current version of MSVC that will work with your codebase. Another is that you're replacing a code generator by a lot of boilerplate macros. Visual Studio 2015 will have constexpr fixed [1] and it should compile CopperSpice. It's still not working in MSVC 2015 RC1. I'd be wary of relying on RTM fixing it if it's still not fixed yet. The replacement of qmake with autotools in CopperSpice makes things very hard to test with Visual Studio. It seems CMake is being under evaluation [2]. The combination of CMake and ninja is quite effective. Autotools is backwards direction. Everyone moves *away* from Autotools, not towards it (except people who had no buildsystem in the first place). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On Tuesday 30. June 2015 22:37:24 Bernhard wrote: For example, with moc removed we support template classes that inherit from QObject. Wow. I would (almost) kill for having that feature in Qt! You can do that with moc. https://codereview.qt-project.org/49864/ There was a discussion about it on the mailinglist at the time, but nobody expressed much interest in having that feature. -- 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
