Re: [Development] QtCS: Notes from Modern C++ session

On Tuesday 01 December 2015 10:00:29 Marc Mutz wrote: > On Tuesday 16 June 2015 22:31:51 Thiago Macieira wrote: > > MSVC 2012 and 2013 have a parsing bug with them, so you need to > > > > compile your code with one of those two versions if you're introducing new > > range fors. > > Do you have s

Re: [Development] QtCS: Notes from Modern C++ session

On Tuesday 16 June 2015 22:31:51 Thiago Macieira wrote: > MSVC 2012 and 2013 have a parsing bug with them, so you need to > compile your code with one of those two versions if you're introducing new > range fors. Do you have specifics here? IIRC, it was something like while (...) for

Re: [Development] QtCS: Notes from Modern C++ session

nt-bounces+louai.al-khanji=theqtcompany.com@qt- > project.org [mailto:development-bounces+louai.al- > khanji=theqtcompany@qt-project.org] On Behalf Of Thiago Macieira > Sent: Sunday, June 14, 2015 8:08 PM > To: development@qt-project.org > Subject: Re: [Development] QtCS: Notes from Modern C++

Re: [Development] QtCS: Notes from Modern C++ session

> Am 16.06.2015 um 22:49 schrieb Ziller Eike : > > >> On Jun 16, 2015, at 16:52, Matthew Woehlke >> wrote: >> >> On 2015-06-12 17:45, Thiago Macieira wrote: >>> On Friday 12 June 2015 10:49:38 Matthew Woehlke wrote: > On Friday 12 June 2015 08:08:51 André Somers wrote: >> Not availabl

Re: [Development] QtCS: Notes from Modern C++ session

On Tuesday 16 June 2015 23:32:28 Olivier Goffart wrote: > On Tuesday 16. June 2015 13:31:51 Thiago Macieira wrote: > > Please don't use the CI for the test. Compile with MSVC first and only > > submit your code if it compiled. > > > > If you don't have access to MSVC, either get someone to test fo

Re: [Development] QtCS: Notes from Modern C++ session

On Tuesday 16. June 2015 13:31:51 Thiago Macieira wrote: > Please don't use the CI for the test. Compile with MSVC first and only > submit your code if it compiled. > > If you don't have access to MSVC, either get someone to test for you or > don't submit. Isn't the new CI allowing to easily test

Re: [Development] QtCS: Notes from Modern C++ session

> On Jun 16, 2015, at 16:52, Matthew Woehlke > wrote: > > On 2015-06-12 17:45, Thiago Macieira wrote: >> On Friday 12 June 2015 10:49:38 Matthew Woehlke wrote: On Friday 12 June 2015 08:08:51 André Somers wrote: > Not available for use are: > * = default, > * = deleted, >>> >>

Re: [Development] QtCS: Notes from Modern C++ session

On Tuesday 16 June 2015 10:52:16 Matthew Woehlke wrote: > On 2015-06-12 17:45, Thiago Macieira wrote: > > On Friday 12 June 2015 10:49:38 Matthew Woehlke wrote: > >>> On Friday 12 June 2015 08:08:51 André Somers wrote: > Not available for use are: > * = default, > * = deleted, > >>

Re: [Development] QtCS: Notes from Modern C++ session

On Friday 12 June 2015 08:08:51 André Somers wrote: > Available for use then: > * Auto > * decltype > * nullptr > * r-value ref > * lambda > * class enum > * explicit overrides > > Not available for use are: > * uniform initialization and constexpr (is broken in VS2013.) > * Explicit conversions,

Re: [Development] QtCS: Notes from Modern C++ session

On 2015-06-12 17:45, Thiago Macieira wrote: > On Friday 12 June 2015 10:49:38 Matthew Woehlke wrote: >>> On Friday 12 June 2015 08:08:51 André Somers wrote: Not available for use are: * = default, * = deleted, >> >> Where are these not supported? I have code that (AFAIK) has been usi

Re: [Development] QtCS: Notes from Modern C++ session

> -Original Message- > From: development-bounces+kai.koehne=theqtcompany.com@qt- > [..] > Depends whether or not we make the choice to break the "no stl in abi" rule. As I am looking at the advantages versus the the disadvantages in using the standard library I opting for using it. For ex

Re: [Development] QtCS: Notes from Modern C++ session

> -Original Message- > From: development-bounces+kai.koehne=theqtcompany.com@qt- > [..] > Depends whether or not we make the choice to break the "no stl in abi" rule. I understood the rule has miniscule practical value, and hinders us from providing the best Qt API possible. So I'm all f

Re: [Development] QtCS: Notes from Modern C++ session

On Monday 15. June 2015 21:30:25 Marc Mutz wrote: > On Monday 15 June 2015 17:43:58 Olivier Goffart wrote: > > On Unix: Clang and GCC build are compatible, > > Yes. > > > C++03/C++11/C++14 builds are compatible. > > No. [... std::list ...] Yes. I was talking about Qt build, and since Qt does no

Re: [Development] QtCS: Notes from Modern C++ session

On Monday 15 June 2015 13:03:55 Thiago Macieira wrote: > b) Linux distributions that properly compile libc++ [*] > > > > [*] provided, of course, that the two share their base C++ ABI, which > > > some > > > Linux distros have not yet learned to do. By the way, the list of Linux distributions tha

Re: [Development] QtCS: Notes from Modern C++ session

On Monday 15 June 2015 22:12:46 Marc Mutz wrote: > > I disagree. I understand what you said, but right now it is possible to > > switch from libstdc++ to libc++ with no ill effects[*]. So the question > > is should be asked the other way around: do we knowingly remove this > > currently-working ab

Re: [Development] QtCS: Notes from Modern C++ session

On Monday 15 June 2015 17:33:35 Thiago Macieira wrote: > On Monday 15 June 2015 17:24:39 Marc Mutz wrote: > > Qt's binary compatibility is between Qt versions, not between toolchains, > > and as such, I don't see a problem saying that if you change the > > toolchain (STL (version)), then the BC gu

Re: [Development] QtCS: Notes from Modern C++ session

On Monday 15 June 2015 17:43:58 Olivier Goffart wrote: > On Unix: Clang and GCC build are compatible, Yes. > C++03/C++11/C++14 builds are > compatible. No. On C++98, std::list is required to have O(1) splice(), in C++11+, O(1) size() instead. The two are mutually exclusive, so std::list cannot

Re: [Development] QtCS: Notes from Modern C++ session

On Monday 15. June 2015 17:24:39 Marc Mutz wrote: > On Monday 15 June 2015 11:49:40 Olivier Goffart wrote: > > On Friday 12. June 2015 14:42:44 Thiago Macieira wrote: > > > On Friday 12 June 2015 18:58:59 Marc Mutz wrote: > > > > On Friday 12 June 2015 16:37:15 Thiago Macieira wrote: > > > > > On F

Re: [Development] QtCS: Notes from Modern C++ session

On Monday 15 June 2015 17:24:39 Marc Mutz wrote: > Qt's binary compatibility is between Qt versions, not between toolchains, > and as such, I don't see a problem saying that if you change the toolchain > (STL (version)), then the BC guarantees are voided. That's just what we > have now already. I

Re: [Development] QtCS: Notes from Modern C++ session

On Monday 15 June 2015 11:49:40 Olivier Goffart wrote: > On Friday 12. June 2015 14:42:44 Thiago Macieira wrote: > > On Friday 12 June 2015 18:58:59 Marc Mutz wrote: > > > On Friday 12 June 2015 16:37:15 Thiago Macieira wrote: > > > > On Friday 12 June 2015 12:12:17 Olivier Goffart wrote: > > > > >

Re: [Development] QtCS: Notes from Modern C++ session

On Friday 12. June 2015 14:42:44 Thiago Macieira wrote: > On Friday 12 June 2015 18:58:59 Marc Mutz wrote: > > On Friday 12 June 2015 16:37:15 Thiago Macieira wrote: > > > On Friday 12 June 2015 12:12:17 Olivier Goffart wrote: > > > > Which mean using things like std::function, std::unique_ptr, in

Re: [Development] QtCS: Notes from Modern C++ session

On Sunday 14 June 2015 14:00:03 Marc Mutz wrote: > So, we might as well remove Q_DECL_EQ_DEFAULT, I think. Agreed, since it does not mean the same thing to have and not to have it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center

Re: [Development] QtCS: Notes from Modern C++ session

On Saturday 13 June 2015 19:33:14 Gunnar Roth wrote: > Not available for use are: > * = default, > * = deleted, > >> > >> Where are these not supported? I have code that (AFAIK) has been using > >> these already, and IIRC our compiler requirements are lower. > > > > GCC requires 4.

Re: [Development] QtCS: Notes from Modern C++ session

On Sunday 14 June 2015 12:06:21 Knoll Lars wrote: [ regarding = default, = delete ] > The main place where we use this feature is anyway with Q_DISABLE_COPY. So > for now, I don't think it's a huge problem if we can't use those. That's = delete, yes, and you can always make those into linker error

Re: [Development] QtCS: Notes from Modern C++ session

On 13/06/15 19:33, "development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of Gunnar Roth" mailto:development-bounces+lars.knoll=theqtcompany@qt-project.org> on behalf of gunnar.r...@gmx.de

Re: [Development] QtCS: Notes from Modern C++ session

> Not available for use are: * = default, * = deleted, >> >> Where are these not supported? I have code that (AFAIK) has been using >> these already, and IIRC our compiler requirements are lower. > > GCC requires 4.7 for this. I think we were discussing whether our minimum is >

Re: [Development] QtCS: Notes from Modern C++ session

On Friday 12 June 2015 10:49:38 Matthew Woehlke wrote: > On 2015-06-12 04:17, Marc Mutz wrote: > > On Friday 12 June 2015 08:08:51 André Somers wrote: > >> Available for use then: > > range-for? > > variadic macros (these we already use in tests/ and no-one complained so > > far). > André, you ment

Re: [Development] QtCS: Notes from Modern C++ session

On Friday 12 June 2015 18:58:59 Marc Mutz wrote: > On Friday 12 June 2015 16:37:15 Thiago Macieira wrote: > > On Friday 12 June 2015 12:12:17 Olivier Goffart wrote: > > > Which mean using things like std::function, std::unique_ptr, in our ABI. > > > Should we allow that? > > > > The problem is dec

Re: [Development] QtCS: Notes from Modern C++ session

On 2015-06-12 13:02, Marc Mutz wrote: > On Friday 12 June 2015 16:49:38 Matthew Woehlke wrote: >> On 2015-06-12 04:17, Marc Mutz wrote: >>> On Friday 12 June 2015 08:08:51 André Somers wrote: For now, don’t put std lib ABI into Qt ABI, except for nulltpr_t. >>> >>> Too late: QException inherit

Re: [Development] QtCS: Notes from Modern C++ session

On Friday 12. June 2015 07:37:15 Thiago Macieira wrote: > On Friday 12 June 2015 12:12:17 Olivier Goffart wrote: > > Which mean using things like std::function, std::unique_ptr, in our ABI. > > Should we allow that? > > The problem is deciding between std::function and std::__1::function. That's

Re: [Development] QtCS: Notes from Modern C++ session

On Friday 12 June 2015 16:49:38 Matthew Woehlke wrote: > >> For now, don’t put std lib ABI into Qt ABI, except for nulltpr_t. > > > > > > > > Too late: QException inherits std::exception (for a looong time already), > > and by virtue of various exported subclasses of QVector and QList, we > > exp

Re: [Development] QtCS: Notes from Modern C++ session

On Friday 12 June 2015 16:37:15 Thiago Macieira wrote: > On Friday 12 June 2015 12:12:17 Olivier Goffart wrote: > > Which mean using things like std::function, std::unique_ptr, in our ABI. > > Should we allow that? > > The problem is deciding between std::function and std::__1::function. Is __1 n

Re: [Development] QtCS: Notes from Modern C++ session

On 2015-06-12 04:17, Marc Mutz wrote: > On Friday 12 June 2015 08:08:51 André Somers wrote: >> Available for use then: > > range-for? > variadic macros (these we already use in tests/ and no-one complained so far). André, you mentioned 'auto'... does that include return type deduction? What about

Re: [Development] QtCS: Notes from Modern C++ session

On Friday 12 June 2015 10:17:21 Marc Mutz wrote: > Hi Andre, > > thanks for the write-up! > > On Friday 12 June 2015 08:08:51 André Somers wrote: > > Available for use then: > range-for? Nope and they are the ones that are bad for our containers until extended lifetime references show up, proba

Re: [Development] QtCS: Notes from Modern C++ session

On Friday 12 June 2015 12:12:17 Olivier Goffart wrote: > Which mean using things like std::function, std::unique_ptr, in our ABI. > Should we allow that? The problem is deciding between std::function and std::__1::function. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect

Re: [Development] QtCS: Notes from Modern C++ session

On Friday 12. June 2015 10:17:21 Marc Mutz wrote: > Hi Andre, > > thanks for the write-up! > > On Friday 12 June 2015 08:08:51 André Somers wrote: > > Available for use then: > range-for? > variadic macros (these we already use in tests/ and no-one complained so > far). > > No for now: std::for_e

Re: [Development] QtCS: Notes from Modern C++ session

Hi Andre, thanks for the write-up! On Friday 12 June 2015 08:08:51 André Somers wrote: > Available for use then: range-for? variadic macros (these we already use in tests/ and no-one complained so far). > No for now: std::for_each (issues with leaks) Which leaks? > For now, don’t put std lib

[Development] QtCS: Notes from Modern C++ session

Hi, I made notes in the Modern C++ session. You can also find them on the Wiki here: https://wiki.qt.io/QtCS2015_ModernCpp but I was requested to also post them here on the ML. If you were there and remember things differently, please edit and post a reply with corrections. == Sunday June