On Tuesday 09 June 2015 00:27:40 Thiago Macieira wrote:
> But Qt API that doesn't explicitly need an array for the data should
> continue to use QList.
I disagree insofar as it concerns new types.
Either a new type put into a QList is optimally efficient (sizeof == sizeof
void* and at least Q_M
On Mon, Jun 8, 2015 at 3:27 PM, Thiago Macieira
wrote:
> On Tuesday 09 June 2015 00:12:47 Milian Wolff wrote:
> > Sorry Thiago, but imo your answers are not on topic: The documentation is
> > /wrong/. QList is _not_ the right container class to use "for most
> > purposes". If, inside Qt, it is cu
On Tuesday 09 June 2015 00:12:47 Milian Wolff wrote:
> Sorry Thiago, but imo your answers are not on topic: The documentation is
> /wrong/. QList is _not_ the right container class to use "for most
> purposes". If, inside Qt, it is currently (ab)used for historical reasons,
> well then fine. But ca
On Monday 08 June 2015 17:50:31 Thiago Macieira wrote:
> On Monday 08 June 2015 15:40:01 Milian Wolff wrote:
> > On Monday 08 June 2015 09:32:42 Thiago Macieira wrote:
> > > On Monday 08 June 2015 14:57:19 Joerg Bornemann wrote:
> > > > On 08-Jun-15 15:38, Marc Mutz wrote:
> > > > > QList should be
On Monday 08 June 2015 15:40:01 Milian Wolff wrote:
> On Monday 08 June 2015 09:32:42 Thiago Macieira wrote:
> > On Monday 08 June 2015 14:57:19 Joerg Bornemann wrote:
> > > On 08-Jun-15 15:38, Marc Mutz wrote:
> > > > QList should be QVector
> > >
> > > Speaking of that, should we adjust the foll
On Monday 08 June 2015 15:38:21 Marc Mutz wrote:
> > +QList supportedViewfinderResolutions(
> > +const QCameraViewfinderSettings &settings =
> > QCameraViewfinderSettings()) const;
>
> QList should be QVector
We know that QList is defective, but let's keep it in API. We'll get a c
On Monday 08 June 2015 09:32:42 Thiago Macieira wrote:
> On Monday 08 June 2015 14:57:19 Joerg Bornemann wrote:
> > On 08-Jun-15 15:38, Marc Mutz wrote:
> > > QList should be QVector
> >
> > Speaking of that, should we adjust the following recommendation in the
> > docs?
> >
> > "For most purpose
On Monday 08 June 2015 14:57:19 Joerg Bornemann wrote:
> On 08-Jun-15 15:38, Marc Mutz wrote:
> > QList should be QVector
>
> Speaking of that, should we adjust the following recommendation in the docs?
>
> "For most purposes, QList is the right class to use. Its index-based API
> is more conveni
On Mon, Jun 08, 2015 at 01:17:26PM +, Lopes Yoann wrote:
>
> > On 08 Jun 2015, at 15:38, Marc Mutz wrote:
> >
> > On Friday 05 June 2015 10:10:52 Frederik Gladhorn wrote:
> >> +typedef QPair FrameRateRange;
> >
> > Should be a struct, not a QPair:
> >
> > FrameRateChange chg = ...;
>
> On 08 Jun 2015, at 15:38, Marc Mutz wrote:
>
> On Friday 05 June 2015 10:10:52 Frederik Gladhorn wrote:
>> +typedef QPair FrameRateRange;
>
> Should be a struct, not a QPair:
>
> FrameRateChange chg = ...;
> chg.first... // what's first???
> chg.second... // what's second???
It’s
On 08-Jun-15 15:38, Marc Mutz wrote:
> QList should be QVector
Speaking of that, should we adjust the following recommendation in the docs?
"For most purposes, QList is the right class to use. Its index-based API
is more convenient than QLinkedList's iterator-based API, and it is
usually faste
On Friday 05 June 2015 10:10:52 Frederik Gladhorn wrote:
> +typedef QPair FrameRateRange;
Should be a struct, not a QPair:
FrameRateChange chg = ...;
chg.first... // what's first???
chg.second... // what's second???
> enum Status {
> UnavailableStatus,
> Unloa
On Friday 05 June 2015 10:10:52 Frederik Gladhorn wrote:
>
Looks good.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.q
diff --git a/src/multimedia/audio/qaudio.h b/src/multimedia/audio/qaudio.h
index 7e9793f..6395314 100644
--- a/src/multimedia/audio/qaudio.h
+++ b/src/multimedia/audio/qaudio.h
@@ -47,6 +47,7 @@
#include
#include
#include
+#include
#include
@@ -76,6 +77,8 @@ class Q_MULTIMEDIA_EXPORT Q
14 matches
Mail list logo
