Em sex 21 fev 2014, às 12:49:08, Thiago Macieira escreveu:
> 1) keep a non-null d for an empty-but-not null object (size == 0)
> a) d points to a read-write section of memory where we can ref up and down
> drawback: slowness due to atomic operations in multiple cores
>
> b) d points to another
Em sex 21 fev 2014, às 10:48:18, Matthew Woehlke escreveu:
> On 2014-02-21 04:20, Koehne Kai wrote:
> > This is a heads up that you should avoid using qPrintable() together
> > with qDebug/QDebug for localized strings.
> >
> > The issue is that qPrintable() does '.toLocal8Bit()', while
> > QDebug/
Em sex 21 fev 2014, às 20:11:20, Marc Mutz escreveu:
> On Thursday 20 February 2014 08:32:54 Thiago Macieira wrote:
> > Please raise your hand if you knew we had that feature.
>
> I'm sure you know that COW implementations that hand out references to
> shared state need the sharable flag[1]. So ar
Em sex 21 fev 2014, às 16:49:39, Oswald Buddenhagen escreveu:
> ah, you are thinking qt 6 here.
Yes. I'd rather do the deprecation as soon as possible so we can have a
smoother transition when we come to it.
> > Obviously, if the d-pointer is null, neither the pointer to the data nor
> > the si
On Thursday 20 February 2014 08:32:54 Thiago Macieira wrote:
> Please raise your hand if you knew we had that feature.
I'm sure you know that COW implementations that hand out references to shared
state need the sharable flag[1]. So are we talking about removing the public
part of the API?
Than
Em sex 21 fev 2014, às 11:31:32, Nowacki Jedrzej escreveu:
> I agree that the code is fragile and it is not the best api ever, that is
> why I believe we could deprecate it.
>
> I remember the idea of injecting allocator into containers, I do not
> remember why it died (was it memory expensive?).
On 21 February 2014 01:15, Thiago Macieira wrote:
> Em qui 20 fev 2014, às 22:32:35, Sze Howe Koh escreveu:
>> QAbstractOpenGLFunctions::initializeOpenGLFunctions()
>
> That's an internal function.
>
>> QByteArray::setNum()
>
> Those are documented.
>
>> QString::Data
>
> Internal type
On 21 February 2014 06:22, Samuel Gaist wrote:
> Hi !
>
> On 20 févr. 2014, at 15:32, Sze Howe Koh wrote:
>
>> Hi all,
>>
>> The following functions/types need documenting. (This list excludes
>> constructors, destructors, and operators). Could those who are
>> familiar with these functions/types
On Thu, Feb 20, 2014 at 12:07:44PM -0800, Thiago Macieira wrote:
> Em qui 20 fev 2014, às 19:56:42, Oswald Buddenhagen escreveu:
> > what are you planning to do?
>
> This is the first step: remove setSharable so we have one fewer state to
> check
> during ref up & down. Keeping isSharedWith is n
On 2014-02-21 04:20, Koehne Kai wrote:
> This is a heads up that you should avoid using qPrintable() together
> with qDebug/QDebug for localized strings.
>
> The issue is that qPrintable() does '.toLocal8Bit()', while
> QDebug/qDebug and friends nowadays expect const char * arguments to
> be UTF-8
I agree that the code is fragile and it is not the best api ever, that is why I
believe we could deprecate it.
I remember the idea of injecting allocator into containers, I do not remember
why it died (was it memory expensive?). From api perspective it would be a
better solution.
Cheers,
Ję
> >QString::Data
> Internal type, doesn't need documentation.
Missing documentation is not equal to marking something as internal. QDoc will
complain. To make it proper you are expected to use \internal tag.
QString::Data is a public typedef.
Od: dev
Hi,
This is a heads up that you should avoid using qPrintable() together with
qDebug/QDebug for localized strings. E.g.
qWarning("%s", qPrintable(tr("Localized error")));
is bound to break on some setups (e.g. Russian windows versions).
The issue is that qPrintable() does '.toLocal8Bit()', whi
13 matches
Mail list logo
