On Wednesday 11 February 2015 07:11:26 Hausmann Simon wrote:
> Hi,
>
> The short answer to your question is that the meta object system isn't
> really designed for this. In theory this could be implemented but it would
> come at a high cost for something that rarely happens. The qml engine
> suppo
To settle this, I am also with Andre and Simon.
I’m fine with keeping our headers warning free, so go ahead and use
Q_NULLPTR there (until we at some point can require c++11 and can replace
it with nullptr). But I don’t like littering our code with macros. Where
it’s use makes things clearer as in
Hi,
The short answer to your question is that the meta object system isn't really
designed for this. In theory this could be implemented but it would come at a
high cost for something that rarely happens. The qml engine supports this, but
in qml this happens at type compilation time, not fully
I suppose that it is absolutely unlikely that we are going to find a consensus
on what is purely an aesthetic issue.
I for one am entirely with André and I do not like UPPERCASE macros in my face
unless I can avoid them. It's aesthetics and I suppose there is little that
will change that.
As a
On Wednesday 11 February 2015 01:59:40 Olivier Goffart wrote:
> Unless it is a buffer of std::atomic, it is an undefined behavior, so not
> only the contents of the buffer is unpredictable, but anything, really.
>
> (A sufficiently smart conforming compiler could see that you are writing at
> the
On Wednesday 11 February 2015 01:38:12 Olivier Goffart wrote:
> > Eh... have you tried to convert a UTF-8 or UTF-16 or UCS-4 string to the
> > locale's narrow character set without using QString?
>
> with std::ctype::tonarrow?
That's std::ctype::narrow, which I didn't realise existed until now. B
On Tuesday 10 February 2015 19:10:29 Matthew Woehlke wrote:
> On 2015-02-10 18:40, Marc Mutz wrote:
> > On Tuesday 10 February 2015 22:26:50 Thiago Macieira wrote:
> >> It's not insurmountable. I can think of two solutions:
> >> 1) pre-allocate enough space for the UTF-16 data (strlen(utf8) * 2),
On Tuesday 10 February 2015 19:07:09 Matthew Woehlke wrote:
> Heh. That reminds me, when will Qt classes get emplace methods?
I added those methods to my local refactor of QVector, but..
> Or the ability to accept movable-but-not-copyable types?
... they aren't useful because we'll never accept
On Wednesday 11 February 2015 00:40:28 Marc Mutz wrote:
> On Tuesday 10 February 2015 22:26:50 Thiago Macieira wrote:
> > It's not insurmountable. I can think of two solutions:
> > 1) pre-allocate enough space for the UTF-16 data (strlen(utf8) * 2), so
> >
> > that the const functions can implic
On Wednesday 11 February 2015 04:05:02 Konstantin Ritt wrote:
> Previously you said QString::data() must return QChar* (and not a generic
> uchar*), so that QString with an adaptive storage would have to silently
> convert the internal encoding into the one represented by QChar.
> If QString has a
On Tuesday 10 February 2015 15:33:12 Thiago Macieira wrote:
> On Tuesday 10 February 2015 23:17:21 Allan Sandfeld Jensen wrote:
> > Maybe with C++11 we don't need QString that much anymore. Use std::string
> > with UTF8 and std::u32string for UCS4.
> >
> > For Qt6 it would be worth considering how
On 2015-02-10 18:40, Marc Mutz wrote:
> On Tuesday 10 February 2015 22:26:50 Thiago Macieira wrote:
>> It's not insurmountable. I can think of two solutions:
>> 1) pre-allocate enough space for the UTF-16 data (strlen(utf8) * 2), so
>> that the const functions can implicitly write to the UTF-16 b
On 2015-02-10 18:33, Thiago Macieira wrote:
> Eh... have you tried to convert a UTF-8 or UTF-16 or UCS-4 string to the
> locale's narrow character set without using QString?
Yup... we would need to standardize libiconv (or an equivalent) for that
:-).
> Have you tried to convert a number to stri
Previously you said QString::data() must return QChar* (and not a generic
uchar*), so that QString with an adaptive storage would have to silently
convert the internal encoding into the one represented by QChar.
If QString has a UCS-4 indexes and length() that counts the amount of UCS-4
codepoints,
test:
class Test : public QObject {
Q_OBJECT
public slots:
QObject* createQObject() { return new QObject(); }
void checkQObjectMetaObject(QObject* obj)
{
for(int i=0; i < object->metaObject()->methodCount(); i++)
{
qDebug() << "introspecting: " << object->metaObject()->method(i
Marc, I'm not sure if you're arguing for or against nullptr :-)...
On 2015-02-10 18:23, Marc Mutz wrote:
> On Tuesday 10 February 2015 20:13:12 André Pönitz wrote:
>> Can't you simply wait until 'nullptr' is available?
>
> No.
>
> For a simple reason: using nullptr (Q_ or not) is more expressive
On Tuesday 10 February 2015 22:26:50 Thiago Macieira wrote:
> It's not insurmountable. I can think of two solutions:
> 1) pre-allocate enough space for the UTF-16 data (strlen(utf8) * 2), so
> that the const functions can implicitly write to the UTF-16 block when
> needed. Since the original UTF-
On Wednesday 11 February 2015 02:19:59 Konstantin Ritt wrote:
> Can QChar represent a 32 bits codepoint, then?
Yes, it could be widened. But what's the advantage in using UCS-4?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
__
On Tuesday 10 February 2015 23:17:21 Allan Sandfeld Jensen wrote:
> Maybe with C++11 we don't need QString that much anymore. Use std::string
> with UTF8 and std::u32string for UCS4.
>
> For Qt6 it would be worth considering how many of our classes still makes
> sense. Those we want CoW semantics
On Tuesday 10 February 2015 20:13:12 André Pönitz wrote:
> On Tue, Feb 10, 2015 at 07:53:23PM +0100, Marc Mutz wrote:
> > On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote:
> > > On Tuesday 10 February 2015 15:34:45 Knoll Lars wrote:
> > > > +1. I’m ok with us making sure our headers are c
On 2015-02-10 17:44, André Pönitz wrote:
> On Tue, Feb 10, 2015 at 05:15:03PM -0500, Matthew Woehlke wrote:
>> On 2015-02-08 16:42, André Pönitz wrote:
>>> I.e. in case of a simple pointer initialization, why should one *ever*
>>> prefer
>>>
>>> void something()
>>> {
>>> Foo *f = Q_NULLPTR;
On 2015-02-09 15:05, Marc Mutz wrote:
> On Monday 09 February 2015 20:10:44 André Pönitz wrote:
>> On Mon, Feb 09, 2015 at 09:36:46AM +0100, Marc Mutz wrote:
>>> I find Q_NULLPTR *beautiful* (bautyful is deeper than pretty), because I
>>> know at some point we will be able to just s/Q_NULLPTR/nullp
On Tuesday 10 February 2015 23:17:21 Allan Sandfeld Jensen wrote:
> Maybe with C++11 we don't need QString that much anymore. Use std::string
> with UTF8 and std::u32string for UCS4.
>
> For Qt6 it would be worth considering how many of our classes still makes
> sense. Those we want CoW semantics
On Tue, Feb 10, 2015 at 05:15:03PM -0500, Matthew Woehlke wrote:
> On 2015-02-08 16:42, André Pönitz wrote:
> > I.e. in case of a simple pointer initialization, why should one *ever*
> > prefer
> >
> > void something()
> > {
> > Foo *f = Q_NULLPTR;
> > ...
> > }
> >
> > over
> >
> > vo
On Tue, Feb 10, 2015 at 11:25:52PM +0100, Mathias Hasselmann wrote:
>
>
> Am 10.02.2015 um 20:13 schrieb André Pönitz:
> >On Tue, Feb 10, 2015 at 07:53:23PM +0100, Marc Mutz wrote:
> >>On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote:
> >>>On Tuesday 10 February 2015 15:34:45 Knoll Lars
On 2015-02-09 15:30, André Pönitz wrote:
> Will you propose to use 'auto' instead of 'int' whenever it compiles?
> Just because 'auto' *sometimes* makes sense?
Personally, I'm a fan of AAA :-). However that's not an option for Qt
because there is no reasonable way to use it while still supporting
Am 10.02.2015 um 20:13 schrieb André Pönitz:
> On Tue, Feb 10, 2015 at 07:53:23PM +0100, Marc Mutz wrote:
>> On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote:
>>> On Tuesday 10 February 2015 15:34:45 Knoll Lars wrote:
+1. I’m ok with us making sure our headers are clean against war
Can QChar represent a 32 bits codepoint, then?
Regards,
Konstantin
2015-02-11 2:11 GMT+04:00 Thiago Macieira :
> On Wednesday 11 February 2015 01:52:34 Konstantin Ritt wrote:
> > 2015-02-11 1:26 GMT+04:00 Thiago Macieira :
> > > On Wednesday 11 February 2015 00:37:41 Konstantin Ritt wrote:
> > >
On Tuesday 10 February 2015, Oswald Buddenhagen wrote:
> On Wed, Feb 11, 2015 at 12:37:41AM +0400, Konstantin Ritt wrote:
> > Yes, that would be an ideal solution. Unfortunately, that would also
> > break a LOT of existing code.
>
> i was thinking of making it explicit with a smooth migration path
On Tuesday 10 February 2015 23:10:01 André Pönitz wrote:
> > > Can't you simply wait until 'nullptr' is available? Do you really *need*
> > > to use macros instead of the core language?
> >
> > We go back to the discussion of VS2008. That's the only major compiler we
> > still care about that does
On 2015-02-08 16:42, André Pönitz wrote:
> I.e. in case of a simple pointer initialization, why should one *ever* prefer
>
> void something()
> {
> Foo *f = Q_NULLPTR;
> ...
> }
>
> over
>
> void something()
> {
> Foo *f = 0;
> ...
> }
>
> ?
For the same reason that *any* styl
On Wednesday 11 February 2015 01:52:34 Konstantin Ritt wrote:
> 2015-02-11 1:26 GMT+04:00 Thiago Macieira :
> > On Wednesday 11 February 2015 00:37:41 Konstantin Ritt wrote:
> > > Yes, that would be an ideal solution. Unfortunately, that would also
> >
> > break
> >
> > > a LOT of existing code.
On Tue, Feb 10, 2015 at 01:17:25PM -0800, Thiago Macieira wrote:
> On Tuesday 10 February 2015 20:13:12 André Pönitz wrote:
> > On Tue, Feb 10, 2015 at 07:53:23PM +0100, Marc Mutz wrote:
> > > On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote:
> > > > On Tuesday 10 February 2015 15:34:45 K
Err, s/utf8Data/utf16Data/
Regards,
Konstantin
2015-02-11 1:52 GMT+04:00 Konstantin Ritt :
>
> 2015-02-11 1:26 GMT+04:00 Thiago Macieira :
>
>> On Wednesday 11 February 2015 00:37:41 Konstantin Ritt wrote:
>> > Yes, that would be an ideal solution. Unfortunately, that would also
>> break
>> > a
2015-02-11 1:26 GMT+04:00 Thiago Macieira :
> On Wednesday 11 February 2015 00:37:41 Konstantin Ritt wrote:
> > Yes, that would be an ideal solution. Unfortunately, that would also
> break
> > a LOT of existing code.
> > In Qt4 times, I was doing some experiments with the QString adaptive
> > stor
On Tuesday 10 February 2015 13:26:50 Thiago Macieira wrote:
> But given the choice, I would choose to do nothing. Instead, I have a patch
> pending for Qt 6 that caches the Latin1 version of the QString in an extra
> block past the UTF-16 data.
Sorry, I remembered wrong. I have a patch that sets
On Wednesday 11 February 2015 00:37:41 Konstantin Ritt wrote:
> Yes, that would be an ideal solution. Unfortunately, that would also break
> a LOT of existing code.
> In Qt4 times, I was doing some experiments with the QString adaptive
> storage (similar to what NSString does behind the scenes).
I
On Wed, Feb 11, 2015 at 12:37:41AM +0400, Konstantin Ritt wrote:
> Yes, that would be an ideal solution. Unfortunately, that would also
> break a LOT of existing code.
>
i was thinking of making it explicit with a smooth migration path - add
QUtf8String (basically QByteArray, but don't permit impli
On Tuesday 10 February 2015 20:13:12 André Pönitz wrote:
> On Tue, Feb 10, 2015 at 07:53:23PM +0100, Marc Mutz wrote:
> > On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote:
> > > On Tuesday 10 February 2015 15:34:45 Knoll Lars wrote:
> > > > +1. I’m ok with us making sure our headers are c
Yes, that would be an ideal solution. Unfortunately, that would also break
a LOT of existing code.
In Qt4 times, I was doing some experiments with the QString adaptive
storage (similar to what NSString does behind the scenes).
Konstantin
2015-02-11 0:22 GMT+04:00 Oswald Buddenhagen <
oswald.budde
Thanks. That's what I assumed, but it's nice to have it confirmed.
On Tue, Feb 10, 2015 at 9:24 PM, Hausmann Simon
wrote:
> Hi,
>
> Friedemann made a fix: https://codereview.qt-project.org/#/c/105750/
>
> Simon
>
> Original Message
> From: Robin Burchell
> Sent: Tuesday, February 10, 2015 21:1
Hi,
Friedemann made a fix: https://codereview.qt-project.org/#/c/105750/
Simon
Original Message
From: Robin Burchell
Sent: Tuesday, February 10, 2015 21:15
To: development@qt-project.org
Subject: [Development] QtDeclarative CI failures on Windows
Can someone with Windows please take a look
On Tue, Feb 10, 2015 at 10:58:58PM +0400, Konstantin Ritt wrote:
> Despite of what http://utf8everywhere.org/#conclusions says, UTF-16 is not
> the worst choice; it is a trade-off between the performance and the memory
> consumption in the most-common use case (spoken languages and mixed
> scripts)
Can someone with Windows please take a look at unblocking
qtdeclarative/dev, or give an update if you know what's going on? It's
been failing since February 5[1](!).
The failures are consistent. See some examples: [2][3][4].
In light of it being just under a week since the last successful
integra
On Tuesday 10 February 2015 22:58:58 Konstantin Ritt wrote:
> 16 bits is completely enough for most spoken languages (see the
s/most/all/
All *living* languages are encoded in the BMP. The SMP and other planes
contain only dead languages (Egyptian hieroglyphs, Linear A, Linear B, etc.),
plus so
On Tue, Feb 10, 2015 at 07:53:23PM +0100, Marc Mutz wrote:
> On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote:
> > On Tuesday 10 February 2015 15:34:45 Knoll Lars wrote:
> > > +1. I’m ok with us making sure our headers are clean against warnings (if
> > > possible), but I don’t see a real
16 bits is completely enough for most spoken languages (see the
Unicode's Blocks.txt and/or Scripts.txt for an approximated list), whereas
8 bits encoding only covers ASCII.
Despite of what http://utf8everywhere.org/#conclusions says, UTF-16 is not
the worst choice; it is a trade-off between the pe
On Tuesday 10 February 2015 16:33:23 Knoll Lars wrote:
> Not a whole lot? That Atomic COW is around 10% slower than a Plain string
> (does Atomic COW use a fast allocator?) in the use case where you copy
> strings once and modify them in 2/3 of the cases ;-)
I guess the slowdown from -fexceptions
On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote:
> On Tuesday 10 February 2015 15:34:45 Knoll Lars wrote:
> > +1. I’m ok with us making sure our headers are clean against warnings (if
> > possible), but I don’t see a real need to enforce it’s usage in
> > implementations.
>
> Fair enoug
On Feb 10, 2015, at 17:08, Julien Blanc wrote:
> On 10/02/2015 16:33, Knoll Lars wrote:
>> IMO there’s simply too many questions that this one example doesn’t answer
>> to conclude that what we are doing is bad.
>
> Two arguments :
> - implicit sharing is convenient, and really developer friend
On Tuesday 10 February 2015 18:01:09 Christian Kandeler wrote:
> On 02/10/2015 05:33 PM, Olivier Goffart wrote:
> > Note that some STL implementation (most notably the GNU one) use implicit
> > sharing for std::string
>
> I thought that was prohibited in C++11?
It is. But the C++98 mode std::stri
On Tuesday 10 February 2015 18:01:09 Christian Kandeler wrote:
> On 02/10/2015 05:33 PM, Olivier Goffart wrote:
> > Note that some STL implementation (most notably the GNU one) use implicit
> > sharing for std::string
>
> I thought that was prohibited in C++11?
That's right, but GCC did not want
On 10/02/2015 17:33, Olivier Goffart wrote:
> On Tuesday 10 February 2015 17:08:55 Julien Blanc wrote:
>> On 10/02/2015 16:33, Knoll Lars wrote:
>>> IMO there’s simply too many questions that this one example doesn’t answer
>>> to conclude that what we are doing is bad.
>> Two arguments :
>> - impl
On 02/10/2015 05:33 PM, Olivier Goffart wrote:
> Note that some STL implementation (most notably the GNU one) use implicit
> sharing for std::string
I thought that was prohibited in C++11?
Christian
___
Development mailing list
Development@qt-project.
On Tuesday 10 February 2015 17:08:55 Julien Blanc wrote:
> On 10/02/2015 16:33, Knoll Lars wrote:
> > IMO there’s simply too many questions that this one example doesn’t answer
> > to conclude that what we are doing is bad.
>
> Two arguments :
> - implicit sharing is convenient, and really develop
On Tuesday 10 February 2015 15:34:45 Knoll Lars wrote:
> +1. I’m ok with us making sure our headers are clean against warnings (if
> possible), but I don’t see a real need to enforce it’s usage in
> implementations.
Fair enough. But how about allowing people to change zeroes to Q_NULLPTR?
--
Thia
Hello,
I have made a patch in qt installer framework and created a merge request.
I now sassigned reviewers to it. When should i expect some sort of feedback?
Thank you in advance!
Best regards,
Caspar Romot
___
Development mailing list
Development@qt-
On 10/02/2015 16:33, Knoll Lars wrote:
> IMO there’s simply too many questions that this one example doesn’t answer
> to conclude that what we are doing is bad.
Two arguments :
- implicit sharing is convenient, and really developer friendly. It is
probably a good idea since strings are really pre
On 09/02/15 22:50, "André Pönitz" wrote:
>On Mon, Feb 09, 2015 at 01:28:18PM -0800, Thiago Macieira wrote:
>> On Monday 09 February 2015 22:10:09 André Pönitz wrote:
>> > On Mon, Feb 09, 2015 at 12:58:45PM -0800, Thiago Macieira wrote:
>> > > On Monday 09 February 2015 21:21:12 André Pönitz wrote
On 09/02/15 15:56, "Oswald Buddenhagen"
wrote:
>On Mon, Feb 09, 2015 at 03:30:06PM +0100, Marc Mutz wrote:
>> On Monday 09 February 2015 14:21:44 Rutledge Shawn wrote:
>> > But the advantage of Qt data structures is the implicit sharing.
>>
>> Cough, cough.
>>
>> http://www.gotw.ca/publications
Marc Mutz schreef op 10-2-2015 om 14:19:
> On Tuesday 10 February 2015 13:05:32 Olivier Goffart wrote:
>> I think using a QMap is fine in most case.
> Sorry, no.
>
> I know you don't believe me. Maybe you believe your own eyes:
>
> https://www.youtube.com/watch?v=ApLLVY6MZaI&list=PLHxtyCq_WDLXFAEA-
On Tuesday 10 February 2015 13:05:32 Olivier Goffart wrote:
> I think using a QMap is fine in most case.
Sorry, no.
I know you don't believe me. Maybe you believe your own eyes:
https://www.youtube.com/watch?v=ApLLVY6MZaI&list=PLHxtyCq_WDLXFAEA-
lYoRNQIezL_vaSX-&index=7 start at 30:00
for the r
On Tuesday 10 February 2015 12:37:28 Smith Martin wrote:
> >For those guys, no amount of documentation will save them from writing
> >bad code, so I don't think we should concern ourselves much with this
> >case.
> >
> >I'm happy with the documentation if an educated developer reads it, and
> >is
Hi,
>Ok, now at least all widgets with a desktop widget as parent are
created on the correct screen. But as soon as I open a child window
(e.g. the file open dialog on my example) this is >created on the
applications primary screen. Should I fill a bug report for this?
Yes please, with a smal
On Tuesday 10 February 2015 11:37:28 Smith Martin wrote:
> >For those guys, no amount of documentation will save them from writing
> >bad code, so I don't think we should concern ourselves much with this case.
> >
> >I'm happy with the documentation if an educated developer reads it, and
> >is able
10.02.2015, 14:37, "Smith Martin" :
>> For those guys, no amount of documentation will save them from writing
>> bad code, so I don't think we should concern ourselves much with this case.
>> I'm happy with the documentation if an educated developer reads it, and
>> is able to make the correct
>For those guys, no amount of documentation will save them from writing
>bad code, so I don't think we should concern ourselves much with this case.
>I'm happy with the documentation if an educated developer reads it, and
>is able to make the correct decision on which container class to use.
Yo
>I'm not saying that the docs should not contain some information. I'm saying
>that this is not about our users, it's about us, the developers.
I'm just adding that for some of the points you raised, if they have to be
raised for us, the developers, it's a good bet they our users will benefit fr
On Tuesday 10 February 2015 11:01:50 Smith Martin wrote:
> >So, no, I don't think we should discuss everthing ever written about C++
> >efficiency in the Qt docs. But we need to point it out to each other in
> >code reviews and become better at not writing sloppy code.
>
> The suggestion was not
>So, no, I don't think we should discuss everthing ever written about C++
>efficiency in the Qt docs. But we need to point it out to each other in code
>reviews and become better at not writing sloppy code.
The suggestion was not to discuss everything about C++ efficiency but to
discuss the tra
On Tuesday 10 February 2015 08:41:47 Ziller Eike wrote:
> > On Feb 9, 2015, at 3:40 PM, Marc Mutz wrote:
> >
> > On Monday 09 February 2015 09:54:12 Smith Martin wrote:
> >> This is the kind of thing we should add to the documentation, but can
> >> you elaborate? I mean, illustrate the meaning of
> Von: "Christian Ehrlicher"
> Am 09.02.2015 um 15:35 schrieb Friedemann Kleint:
> > Hi,
> >
> > >we've multiple X-screens configured (:0.0 ... :0.3) but Qt5 seems to
> > have lost the ability to display something on another screen than the
> > default
> > > QMainWindow *wm = new QMainWindow(dw->s
72 matches
Mail list logo
