On Tuesday 14. April 2015 08.33.06 Mathias Hasselmann wrote:
> So we finally have reached the turning point at which we have no chance
> but to make C++11 mandatory for public Qt headers:
You might think you're trolling, but I think requiring C++11 would be an
excellent goal for Qt 6.
- Paul
___
On 14/04/15 08:36, "Mathias Hasselmann" wrote:
>Am 10.04.2015 um 17:51 schrieb Thiago Macieira:
>> On Friday 10 April 2015 15:03:04 André Somers wrote:
>>> I do think it needs a bit of work on the documentation side of things
>>>to
>>> make it clear that really any QList now behaves as/is a
>>> QB
Am 10.04.2015 um 17:51 schrieb Thiago Macieira:
> On Friday 10 April 2015 15:03:04 André Somers wrote:
>> I do think it needs a bit of work on the documentation side of things to
>> make it clear that really any QList now behaves as/is a
>> QByteArrayList. The documentation still says it is a cla
Am 10.04.2015 um 17:51 schrieb Thiago Macieira:
> On Friday 10 April 2015 09:51:42 Christian Kandeler wrote:
>> On 04/09/2015 08:51 PM, Thiago Macieira wrote:
>>> The objective is to make Qt6 QStringList be a typedef to QList,
>>> not a separate class.
>>
>> Uh-oh, that will break all forward dec
On Monday 13 April 2015 09:05:06 André Somers wrote:
> Marc Mutz schreef op 11-4-2015 om 14:33:
> > On Friday 10 April 2015 14:06:18 André Somers wrote:
> >> Marc Mutz schreef op 10-4-2015 om 13:29:
> > [...]
> >
> >>> For one, you're not supoosed to inherit from value classes. For
> >>> another..
Marc Mutz schreef op 11-4-2015 om 14:33:
> On Friday 10 April 2015 14:06:18 André Somers wrote:
>> Marc Mutz schreef op 10-4-2015 om 13:29:
> [...]
>>> For one, you're not supoosed to inherit from value classes. For
>>> another... Oh, I think that's enough reasons :)
>> That a religious argument in
On Friday 10 April 2015 15:59:06 Olivier Goffart wrote:
> On Friday 10. April 2015 13:38:55 Simon Hausmann wrote:
> > Yes, over time we will accumulate cruft. We must indeed be very careful
> > what we put into public header files.
>
> A possibility would be to put them in a
>
> #if Q_DEPRECATED_
On Friday 10 April 2015 14:06:18 André Somers wrote:
> Marc Mutz schreef op 10-4-2015 om 13:29:
[...]
> > For one, you're not supoosed to inherit from value classes. For
> > another... Oh, I think that's enough reasons :)
>
> That a religious argument instead of a technical one.
Avoiding undefine
On Thursday 09 April 2015, Thiago Macieira wrote:
> On Thursday 09 April 2015 11:20:30 Frank Osterfeld wrote:
> > > My vote obviously goes to allowing them.
> >
> > I had to fix includes when building client code with 5.5 branch (coming
> > from 5.4.1), so this is an actual issue right now, not ju
I think that would be a good compromise.
Simon
Original Message
From: Olivier Goffart
Sent: Friday, April 10, 2015 15:56
To: development@qt-project.org
Cc: Hausmann Simon
Subject: Re: [Development] Are SiCs through #include cleanups considered
acceptable?
On Friday 10. April 2015 13:38:55
On Thursday 09 April 2015 11:45:20 Thiago Macieira wrote:
> It wasn't a gratuitous change, though. It was required so I could move some
> QStringList methods to QList. Since qlist.h needs to include
> qstringlist.h to ensure the full specialisation of
> QListSpecialMethods is present before QList
On Thursday 09 April 2015 13:20:41 Matthew Woehlke wrote:
> Slightly off-topic: included ? Ick, that's one
> change I'm glad to see.
Yes, because it had inline operator>>(QDataStream&, const QStringList &) and
qdatastream.h requires qiodevice.h.
However, that operator was useless, since qdatast
On 2015-04-09 07:04, André Somers wrote:
> I think it *is* reasonable to remove such indirect includes if they are
> not needed for Qt itself. However, it is worth looking into how the
> thing was documented to begin with. In the case of qHash(), the
> documentation for that one actualy says the
On Thursday 09 April 2015 11:20:30 Frank Osterfeld wrote:
> > My vote obviously goes to allowing them.
>
> I had to fix includes when building client code with 5.5 branch (coming from
> 5.4.1), so this is an actual issue right now, not just a theoretical one. I
> can do more research which headers
On Thursday 09 April 2015 12:46:11 Simon Hausmann wrote:
> > So, by this line of reasoning, the list of #includes in a public header
> > file must be a monotonically increasing function of the Qt version.
> > Since we're keeping SC even across major versions these days, we'll thus
> > slowly conver
On Thursday 09 April 2015 13:04:21 André Somers wrote:
> I think it is reasonable to remove such indirect includes if they are
> not needed for Qt itself. However, it is worth looking into how the
> thing was documented to begin with. In the case of qHash(), the
> documentation for that one actu
Simon Hausmann schreef op 9-4-2015 om 10:39:
> On Wednesday 8. April 2015 14.34.03 Olivier Goffart wrote:
>> On Wednesday 08 April 2015 13:13:19 Marc Mutz wrote:
>>> Hi,
>>>
>>> I have in the past fixed #include mistakes such as #include
>>> for QSharedDataPointer, and even though each time the
>>
On Thursday 9. April 2015 12.34.17 Marc Mutz wrote:
> On Thursday 09 April 2015 10:39:57 Simon Hausmann wrote:
> > On Wednesday 8. April 2015 14.34.03 Olivier Goffart wrote:
> > > On Wednesday 08 April 2015 13:13:19 Marc Mutz wrote:
> > > > Hi,
> > > >
> > > > I have in the past fixed #include mis
On Thursday 09 April 2015 10:39:57 Simon Hausmann wrote:
> On Wednesday 8. April 2015 14.34.03 Olivier Goffart wrote:
> > On Wednesday 08 April 2015 13:13:19 Marc Mutz wrote:
> > > Hi,
> > >
> > > I have in the past fixed #include mistakes such as #include
> > > for QSharedDataPointer, and even t
> On 08 Apr 2015, at 13:13, Marc Mutz wrote:
>
> Hi,
>
> I have in the past fixed #include mistakes such as #include
>
> for QSharedDataPointer, and even though each time the issue came up that this
> is a SiC change (but only for users that unduly rely on indirect includes),
> so
> far t
On Wednesday 8. April 2015 14.34.03 Olivier Goffart wrote:
> On Wednesday 08 April 2015 13:13:19 Marc Mutz wrote:
> > Hi,
> >
> > I have in the past fixed #include mistakes such as #include
> > for QSharedDataPointer, and even though each time the
> > issue came up that this is a SiC change (but
On Wednesday 08 April 2015 13:13:19 Marc Mutz wrote:
> Hi,
>
> I have in the past fixed #include mistakes such as #include
> for QSharedDataPointer, and even though each time the
> issue came up that this is a SiC change (but only for users that unduly
> rely on indirect includes), so far they we
Hi,
I have in the past fixed #include mistakes such as #include
for QSharedDataPointer, and even though each time the issue came up that this
is a SiC change (but only for users that unduly rely on indirect includes), so
far they were always accepted.
When splitting off qHash() from qhash.h i
23 matches
Mail list logo
