On Tuesday 19 January 2016 00:41:35 Thiago Macieira wrote:
> On Monday 18 January 2016 23:11:14 Marc Mutz wrote:
> > QString foo() { return QStringLiteral("foo"); }
> > QString bar() { return Q3DeepCopy(QStringLiteral("foo")); }
> >
> > You will _never_ have the plugin-unloading problem with 'bar'
Hi,
As Lars mentioned in his email about KDE Free Qt foundation agreement and
changes, we’re pushing sources of Qt Virtual Keyboard to codereview.
I’d like to propose the Qt Virtual Keyboard module to be taken as part of Qt
add-on modules,it has been part of commercial Qt releases for some tim
On Monday 18 January 2016 15:39:11 Thiago Macieira wrote:
> On Monday 18 January 2016 23:43:37 Marc Mutz wrote:
> > a) std::string is not a movable type (at least I get a heap corruption
> > when
> > marking it as such in GCC 5.3)
>
> It used to be in C++98 and it is with libc++. The new C++11 std
On Monday 18 January 2016 23:11:14 Marc Mutz wrote:
> QString foo() { return QStringLiteral("foo"); }
> QString bar() { return Q3DeepCopy(QStringLiteral("foo")); }
>
> You will _never_ have the plugin-unloading problem with 'bar', only with
> 'foo', and the reason is CoW: suggesting value semanti
On Monday 18 January 2016 23:43:37 Marc Mutz wrote:
> a) std::string is not a movable type (at least I get a heap corruption when
> marking it as such in GCC 5.3)
It used to be in C++98 and it is with libc++. The new C++11 std::string from
libstdc++ is not relocatable. They implemented SSO by sto
On Monday 18 January 2016 18:47:42 Matthew Woehlke wrote:
> Not really. There is a huge difference between a relocatable type (many,
> if not most), and a trivially copyable type (a lot fewer). Operations
> such as growing the buffer can be vastly more expensive if the item type
> is not relocatabl
On Monday 18 January 2016 19:06:36 Matthew Woehlke wrote:
> On 2016-01-18 12:47, Giuseppe D'Angelo wrote:
> > On Mon, Jan 18, 2016 at 6:09 PM, Matthew Woehlke wrote:
> >> On 2016-01-17 07:55, Marc Mutz wrote:
> >>> Another argument against CoW is that it creates non-local
> >>> dependencies. In tha
On Mon, Jan 18, 2016 at 8:28 PM, Thiago Macieira
wrote:
>
> Here's what a vector could when resizing do for:
>
> a) regular type
> allocate new block, copy-construct then destroy each element, free old
> block
>
> b) regular type with move constructor
> ditto, but move-construct instead
>
> c)
On Monday 18 January 2016 19:17:25 Bubke Marco wrote:
> >> So how many people define there objects as relocatable?
> >
> > Only Qt users. C++ proper doesn't have such a concept (yet) :'(.
>
> I mean how many Qt users using that feature. ;-)
That depends. Do you include people who use the feature
On Monday 18 January 2016 13:57:23 Matthew Woehlke wrote:
> I'll still assert that C++ needs relocatability :-).
The discussion on std-proposals was quite favourable to adding the concept.
Just note that it mutated from "relocatable" to "destructive move", which
isn't the same thing.
Here's wha
On January 18, 2016 19:57:48 Matthew Woehlke wrote:
> On 2016-01-18 13:40, Bubke Marco wrote:
>>> On 2016-01-16 07:06, Bubke Marco wrote:
std::is_trivially_copyable and other type traits are your friends.
>>>
>>> Not really. There is a huge difference between a relocatable type (many,
>>> if
On 2016-01-18 13:40, Bubke Marco wrote:
>> On 2016-01-16 07:06, Bubke Marco wrote:
>>> std::is_trivially_copyable and other type traits are your friends.
>>
>> Not really. There is a huge difference between a relocatable type (many,
>> if not most), and a trivially copyable type (a lot fewer). Oper
Hi Matthew,
Your whole point was relocation but my point was traversing. Relocation can be
easily fixed by reserve but if traversing is slow it is much harder to remove
the convenience structures. I don't say we should not provide them, I only say
they should be on top.
On January 18, 2016 1
On Mon, Jan 18, 2016 at 6:47 PM, Matthew Woehlke
wrote:
>
> Now, imagine a std::vector where both
> the vector and strings are very large. When the vector needs to resize,
> it will have to do a deep copy of ever single item, allocating and
> freeing lots of memory in the process.
Nitpicking: not
On 2016-01-18 12:47, Giuseppe D'Angelo wrote:
> On Mon, Jan 18, 2016 at 6:09 PM, Matthew Woehlke wrote:
>> On 2016-01-17 07:55, Marc Mutz wrote:
>>> Another argument against CoW is that it creates non-local
>>> dependencies. In that, it's like having global variables. With
>>> pretty much the same
On 2016-01-16 07:06, Bubke Marco wrote:
> On January 16, 2016 06:08:14 Kevin Kofler wrote:
>> I suspect we would lose at least some optimizations from
>> Q_DECLARE_TYPEINFO.
>
> std::is_trivially_copyable and other type traits are your friends.
Not really. There is a huge difference between a re
On Mon, Jan 18, 2016 at 6:09 PM, Matthew Woehlke
wrote:
> On 2016-01-17 07:55, Marc Mutz wrote:
> > Another argument against CoW is that it creates non-local dependencies.
> In
> > that, it's like having global variables. With pretty much the same
> problems,
> > cf. the QStringLiteral-in-unloade
On Montag, 18. Januar 2016 17:41:38 CET Oswald Buddenhagen wrote:
> On Mon, Jan 18, 2016 at 03:48:54PM +0100, Andreas Hartmetz wrote:
> > Gerrit is somehow much more detail-oriented, and criticizing "too
> > subjective" stuff is frowned upon.
>
> anyone who complains about such aspects of a review
On 2016-01-16 00:07, Kevin Kofler wrote:
> I suspect we would lose at least some optimizations from
> Q_DECLARE_TYPEINFO
C++ desperately needs something like this. There was talk a while back
about destructive moves, but I don't believe it ever materialized into a
proposal.
I'd rather see the go
On 2016-01-17 07:55, Marc Mutz wrote:
> Another argument against CoW is that it creates non-local dependencies. In
> that, it's like having global variables. With pretty much the same problems,
> cf. the QStringLiteral-in-unloaded-plugins problems.
Ah... no? The problem with QStringLiteral is th
On Mon, Jan 18, 2016 at 03:48:54PM +0100, Andreas Hartmetz wrote:
> Gerrit is somehow much more detail-oriented, and criticizing "too
> subjective" stuff is frowned upon.
>
anyone who complains about such aspects of a review clearly didn't quite
get https://wiki.qt.io/Qt_Contribution_Guidelines -
I'm surprised as well that this slipped through. Looks like MSVC 2010 supports
this bit as well.
It is true however that we require devtoolset 3 for RHEL 6. Does anyone
remember the reason?
Simon
Original Message
From: Olivier Goffart
Sent: Monday, January 18, 2016 16:26
To: development@qt-
I don't really understand the question you're asking. :D
> -Original Message-
> From: Development [mailto:development-boun...@qt-project.org] On Behalf Of
> Andreas Hartmetz
> Sent: Monday, 18 January 2016 3:49 PM
> To: qt-dev
> Subject: [Development] API review and API quality
>
[snip]
On Montag, 18. Januar 2016 08:31:01 CET Rex Dieter wrote:
> I'm trying to build(bootstrap) qt-5.6.0-beta stack on rhel6, and have run
> into a build failure in qtdeclarative,
> beta/tools/qmlimportscanner/main.cpp:376: error: no matching function for
> call to 'find_if(QList::const_iterator,
std
Rex Dieter wrote:
> I'm trying to build(bootstrap) qt-5.6.0-beta stack on rhel6, and have run
> into a build failure in qtdeclarative,
...
> Is this some platform/compiler issue?
>
> fwiw, using gcc-4.4.7-16.el6.
It would appear that
http://doc.qt.io/QtSupportedPlatforms/index.html
references a
Hello,
Due to a recent problem I had with an API addition (solved while writing
the E-Mail about it, the rubber duck technique worked!) I noticed, not
for the first time, something missing...
the Trolltech API review process.
The thing that ensured that (almost) all new API made sense to humans
I'm trying to build(bootstrap) qt-5.6.0-beta stack on rhel6, and have run
into a build failure in qtdeclarative,
make[2]: Entering directory `/builddir/build/BUILD/qtdeclarative-opensource-
src-5.6.0-beta/x86_64-redhat-linux-gnu/tools/qmlimportscanner'
g++ -c -pipe -O2 -g -pipe -Wall -Wp,-D_FORTI
Hi,
Mostly to have an idea about likelihoods and timescales:
How easy (or not) is it to get extensions for QtMacExtras accepted, and how
likely that such extensions actually become available in an upcoming release?
One thing that's really missing from Qt at the moment is a way for an
applicati
28 matches
Mail list logo
